This is my first excursion into the openSUSE forums, and I apologize if I am putting this in the wrong place (its not apparent to me whether this is a hardware or software question).
I have openSUSE 11.2 on two machines: the 32-bit version on a Lenovo tablet, and the 64-bit version on a Dell T1500. On Friday I took a fortran program that I had been running under Windows XP, made the minimum necessary changes (e.g. to paths, \ to / and so on), and compiled on the Lenovo (using gfortran). It ran fine. I worked with this program all weekend. Today I transferred the source file onto the Dell system, where it compiles without error and runs — but produces a radically different (and wrong) outcome.
I expect I am making some naive error. Any hints? Thanks, jdw.
Yes, wrong numerically… inexplicably inconsistent from machine to machine. I should give a little background. The program simulates the atmospheric boundary layer (as function of time and height). It does so by way of equations that, loosely speaking, resemble the heat equation. It is not a high fidelity treatment, but it is behaving in a manner I can more or less comprehend. Focusing on the specific diagnostic that alerts me to the problem, I compute the difference in total heat content from one time to the next (i.e. over one timestep) and (physically) this has to balance heat supplied from the ground or from the overlying “free” atmosphere. On the Lenovo (32-bit) that sum is good, on the Dell (64) it is completely wrong. I don’t want to waste peoples’ time on this, and no, I haven’t declared variables differently… its exactly the same source code (if I assume the file is not disturbed in its passage via gFTP to a server whence I grab it on the other machine). Thanks for taking the time to respond. jdw
But it could be that REAL on a 32-bit machine is REAL4 but on a 64-bit machine is REAL8. So it would depend on whether your numerical algorithm is sensitive to representational accuracy. This is out of my league so the rest is up to you to investigate.
On 05/03/2010 05:56 PM, ken yap wrote:
>
> But it could be that REAL on a 32-bit machine is REAL4 but on a 64-bit
> machine is REAL8. So it would depend on whether your numerical
> algorithm is sensitive to representational accuracy. This is out of my
> league so the rest is up to you to investigate.
Differing default lengths could very well be the problem. Do not use any
default-length definitions - make everything be explicit by
REAL => REAL4
INTEGER => INTEGER4
One other thing to check - is the same version of gfortran being used?
Thanks to both for your input. I shall make these declarations explicit, and see if that makes a difference. I think my two versions of gfortran differ (but they should, shouldn’t they?). It gives me a headache to even think of all the decisions (more wrong than right I suppose) made these past few weeks, and I haven’t written everything down – but I believe YAST offered up a version appropriate for the 64 bit machine. jdw
On 05/03/2010 06:56 PM, j1d1w1 wrote:
>
> Thanks to both for your input. I shall make these declarations explicit,
> and see if that makes a difference. I think my two versions of gfortran
> differ (but they should, shouldn’t they?). It gives me a headache to
> even think of all the decisions (more wrong than right I suppose) made
> these past few weeks, and I haven’t written everything down – but I
> believe YAST offered up a version appropriate for the 64 bit machine.
The version should be gcc-fortran-XY-xxxxx. You need XY to be the same
in both 32- and 64-bit versions.
> On 05/03/2010 06:56 PM, j1d1w1 wrote:
>>
>> Thanks to both for your input. I shall make these declarations explicit,
>> and see if that makes a difference. I think my two versions of gfortran
>> differ (but they should, shouldn’t they?). It gives me a headache to
>> even think of all the decisions (more wrong than right I suppose) made
>> these past few weeks, and I haven’t written everything down – but I
>> believe YAST offered up a version appropriate for the 64 bit machine.
>
> The version should be gcc-fortran-XY-xxxxx. You need XY to be the same
> in both 32- and 64-bit versions.
Having fought this issue since the Intel 4040 was high tech, I’m not
surprised at the potential for divergence in any simulation that uses
iterative algorithms - which basically all my thermo and aero programs do.
If you can find them, there were several very good papers written on error
control back in the early 70’s where a major focus was on truncation vs.
roundoff error that dealt extensively with the effects of word size
(precision) of numerical processors. Of course, we were just reaching the
pointy where real people could afford the computing power to transfer
dynamic simulations from analog to digital processors but the information
is still very germane to simulations using iterative algorithms, especially
if there is a concurrent need for increased speed.
I think I have a couple of the papers on real paper but I have no idea
whether or not the University makes those papers available that far back.
Pity if not for they still impact many of my simulations.
Thanks for the comments. How do I confirm the version of gfortran that is installed (as in gcc-fortran-XY-xxxxx)? I don’t know where in the file structure to look for this, and the YAST software manager is not explicit.
Yast software manager indicates that I have installed on my 64-bit machine the package:
gcc-fortran
The system GNU Fortran Compiler
and my own notes indicate that when I installed this I had chosen a 64-bit version (though the description above does not confirm that)
Searching the installed packages under “gfortran” I see
libgfortran41
libgfortran44
which are runtime libraries (hopefully 64-bit since other packages that are not installed have an explicit extension, e.g. “libgfortran44-32bit”).
On 05/04/2010 10:26 AM, j1d1w1 wrote:
>
> Thanks for the comments. How do I confirm the version of gfortran that
> is installed (as in gcc-fortran-XY-xxxxx)? I don’t know where in the
> file structure to look for this, and the YAST software manager is not
> explicit.
>
> Yast software manager indicates that I have installed on my 64-bit
> machine the package:
>
> gcc-fortran
> The system GNU Fortran Compiler
>
> and my own notes indicate that when I installed this I had chosen a
> 64-bit version (though the description above does not confirm that)
>
> Searching the installed packages under “gfortran” I see
>
> libgfortran41
> libgfortran44
>
> which are runtime libraries (hopefully 64-bit since other packages that
> are not installed have an explicit extension, e.g.
> “libgfortran44-32bit”).
You can usually find the version with the --version option, i.e. enter
> On 05/04/2010 10:26 AM, j1d1w1 wrote:
>>
>> Thanks for the comments. How do I confirm the version of gfortran
>> that
>> is installed (as in gcc-fortran-XY-xxxxx)? I don’t know where in the
>> file structure to look for this, and the YAST software manager is not
>> explicit.
>>
>> Yast software manager indicates that I have installed on my 64-bit
>> machine the package:
>>
>> gcc-fortran
>> The system GNU Fortran Compiler
>>
>> and my own notes indicate that when I installed this I had chosen a
>> 64-bit version (though the description above does not confirm that)
>>
>> Searching the installed packages under “gfortran” I see
>>
>> libgfortran41
>> libgfortran44
>>
>> which are runtime libraries (hopefully 64-bit since other packages
>> that are not installed have an explicit extension, e.g.
>> “libgfortran44-32bit”).
>
> You can usually find the version with the --version option, i.e. enter
>
> gfortran --version
Some 64-bit fortran compilers use 8-byte integers by default (and often
have a command-line argument to use 4-byte instead). This is mostly
harmless, but breaks the common fortran assumption that INTEGER and
REAL are the same length (since REAL is still usually 4 byte by
default, and DOUBLE PRECISION is 8). I would look for something like
(shudder) EQUIVALENCE statements, that might be sensitive to this.
*********** To reply by e-mail, make w single in address **************
On 05/04/2010 11:33 AM, Ian Gay wrote:
>
> Some 64-bit fortran compilers use 8-byte integers by default (and often
> have a command-line argument to use 4-byte instead). This is mostly
> harmless, but breaks the common fortran assumption that INTEGER and
> REAL are the same length (since REAL is still usually 4 byte by
> default, and DOUBLE PRECISION is 8). I would look for something like
> (shudder) EQUIVALENCE statements, that might be sensitive to this.
Aw, come on! EQUIVALENCE is just a union. I agree that it can be abused
and that Fortran is generally not conducive to proper programming
practice, and I coded in Fortran for 20 years before I ever tried
anything in C.
If I were to try to sort out this problem, I would make sure that every
program unit started with an ‘IMPLICIT NONE’ statement, and then use
REAL4 and INTEGER4 as appropriate for everything except the REAL*8
variables. I would also put the common block definitions in include
files so that no misalignment can occur there.
> Larry Finger wrote:
>
>> On 05/04/2010 10:26 AM, j1d1w1 wrote:
>>>
>>> Thanks for the comments. How do I confirm the version of gfortran
>>> that
>>> is installed (as in gcc-fortran-XY-xxxxx)? I don’t know where in the
>>> file structure to look for this, and the YAST software manager is not
>>> explicit.
>>>
>>> Yast software manager indicates that I have installed on my 64-bit
>>> machine the package:
>>>
>>> gcc-fortran
>>> The system GNU Fortran Compiler
>>>
>>> and my own notes indicate that when I installed this I had chosen a
>>> 64-bit version (though the description above does not confirm that)
>>>
>>> Searching the installed packages under “gfortran” I see
>>>
>>> libgfortran41
>>> libgfortran44
>>>
>>> which are runtime libraries (hopefully 64-bit since other packages
>>> that are not installed have an explicit extension, e.g.
>>> “libgfortran44-32bit”).
>>
>> You can usually find the version with the --version option, i.e. enter
>>
>> gfortran --version
>
> Some 64-bit fortran compilers use 8-byte integers by default (and often
> have a command-line argument to use 4-byte instead). This is mostly
> harmless, but breaks the common fortran assumption that INTEGER and
> REAL are the same length (since REAL is still usually 4 byte by
> default, and DOUBLE PRECISION is 8). I would look for something like
> (shudder) EQUIVALENCE statements, that might be sensitive to this.
An even more subtle question is the equivalence (lower case description, not
the statement within the libraries. I don’t know how you would find
the settings used to compile those libraries but they could actually
obviate any program-level optimizations you might make. I’ve not seen this
specifically with math routines but I have seen far more incompatibilities
than I care to recall when library internals differed from program
compilation re. optimization, word size, etc.
Just a thought: have you tried the 32-bit code on the 64-bit hardware? the
X86_64 hardware is quite happy running ix86 code. This will open up memory
for you.
Thanks for that… I had happened to bump into my colleague Carlos who gave me the same tip. Yes
>gfortran --version
confirmed I am using the same version of gfortran on both machines (namely GNU Fortran (SUSE Linux) 4.4.1 gcc-4_4-branch revision 150839).
I made my declarations of the variables explicit (e.g. real (kind=4)), and that has solved the problem. I am getting very consistent results from both machines. Thanks to all who have helped me on this. jdw
PS. Will if I interpret your statement correctly, you’re suggesting one could compile the source code on the Lenovo (32-bit machine) and run the executable file on the Dell (64-bit)? I certainly hadn’t tried that, and as I just wrote, my problem is solved'' (I hate to say understood’’ in this context!). I’m surprised and interested to heat that is possible. Thanks again, John.
>
> Hmm, it’s a worry if your numerical algorithm is sensitive to the extra
> precision.
Classic problem. The extra precision changes comparisons by altering the
results where the differences are in the LSD of the longer data type - what
was lost to truncation in the 32 bit version causes equality to become
inequality when the extra bits are retained in the longer data word.
consider the decimal equivalent: A = 12344339, B = 12344337 to 8
significant digits. A != B. Cut the resolution to 4 significant digits
and you get A = 1.234, B = 1.234. A = B, regardless of whether you round or
truncate.
Even disregarding the precision, solutions of any long-running algorithms
requiring integrals are problematic without careful attention to the error
management. Errors are cumulative over time and Mother Nature is not a big
fan of statistically random distributions. I had a co-worker grumble once
that it was a wonder that any ballistic system using digital control could
hit the ground, much less a specific target. I spent a lot of time doing
sensitivity analysis trying to cope with those tiny errors - as witnessed
by my bald head.
hello
i was running a fortran program on a 64 bit machine (red hat linux as operating system)
and i m gettin segmentation fault after executing . i m compling it using f95 command.
hw to fix this problem???
please help:X:X:X:X