|
|
 |
 |
 |
 |
Fortran Programming Language
|
 |
 |
 |
 |
|
|
|
|
pre-processor include vs. F77-MIL-STD include
I've been working on a legacy code which is written in F77 with the US military
extenstions (include statements and end do's etc.).
I've encountered many problems while working with this old code, perhaps mainly
because it has implicit definitions and is about 20,000 lines long.
Anyway, my most recent woes stem from trying to add some pre-processor checks
for different builds (#ifdef ... #endif, that sort of thing) and due to some
source files being included with " include 'eos.cmn' ", for example, I found the
pre-processor wouldn't process the included files unless they were included with
the C style " #include 'eos.cmn' ". Fine. Or so I thought. It seems just the
difference between the two inclusion mechanisms causes some subtle difference in
the computations carried out causing some very noticeable differences in the
numeric output after about 25 time-steps (this is a hydrodynamics code).
Anyone got any suggestions for why there should be *any* difference in the
results?
Thanks,
Richard.
===========================================
R. A. Archibald
School of Mathematics
University of Edinburgh
===========================================
On May 15, 10:35 am, Richard Archibald <R.Archib@ed.ac.uk> wrote:
> I've been working on a legacy code which is written in F77 with the US military > extenstions (include statements and end do's etc.). > I've encountered many problems while working with this old code, perhaps mainly
> because it has implicit definitions and is about 20,000 lines long.
> Anyway, my most recent woes stem from trying to add some pre-processor checks
> for different builds (#ifdef ... #endif, that sort of thing) and due to some
> source files being included with " include 'eos.cmn' ", for example, I found the
> pre-processor wouldn't process the included files unless they were included with
> the C style " #include 'eos.cmn' ". Fine. Or so I thought. It seems just the
> difference between the two inclusion mechanisms causes some subtle difference in
> the computations carried out causing some very noticeable differences in the
> numeric output after about 25 time-steps (this is a hydrodynamics code).
two inclusion methods? Which compiler and operating system are you
using?
In article
<Pine.LNX.4.63.0705151527430.6@pythagoras.maths.ed.ac.uk>,
Richard Archibald <R.Archib@ed.ac.uk> wrote:
> Anyone got any suggestions for why there should be *any* difference in the
> results?
Someone mentioned just a couple of weeks ago that on some platforms
the c preprocessor is invoked before the fortran compiler steps, so
if your include file includes further c preprocessor directives,
they may be either processed differently or not at all when done
with INCLUDE rather than #include.
When I need to work on code like this, I usually try to clean it up
beforehand. If you are sharing code with other programmers, then
this may not be possible. But if you can, then you can eliminate
the implicit declarations of variables, which is a huge source of
subtle errors with legacy codes. Moving external routines into
modules will give you explicit interfaces, which allows the compiler
to eliminate another huge source of errors. If you are using
INCLUDE for common blocks, then it is a small step to eliminate
those common blocks entirely and replace them with modules, which
also has some advantages for future maintenance.
$.02 -Ron Shepard
"Ron Shepard" <ron-shep @NOSPAM.comcast.net> wrote in message
> In article > <Pine.LNX.4.63.0705151527430.6 @pythagoras.maths.ed.ac.uk>, > Richard Archibald <R.Archib @ed.ac.uk> wrote: >> Anyone got any suggestions for why there should be *any* difference in
>> the
>> results?
> Someone mentioned just a couple of weeks ago that on some platforms
> the c preprocessor is invoked before the fortran compiler steps, so
> if your include file includes further c preprocessor directives,
> they may be either processed differently or not at all when done
> with INCLUDE rather than #include.
> When I need to work on code like this, I usually try to clean it up
> beforehand. If you are sharing code with other programmers, then
> this may not be possible. But if you can, then you can eliminate
> the implicit declarations of variables, which is a huge source of
> subtle errors with legacy codes. Moving external routines into
> modules will give you explicit interfaces, which allows the compiler
> to eliminate another huge source of errors. If you are using
> INCLUDE for common blocks, then it is a small step to eliminate
> those common blocks entirely and replace them with modules, which
> also has some advantages for future maintenance.
> $.02 -Ron Shepard
to
clean up the code, my first reaction would be to work out why the legacy
code doesn't work, and make only minimal changes while I was doing that
exploration. After all, Fortran 77 is still valid Fortran 95, and if it ever
worked,
it should still work! Maybe it never worked ...
For example, if the solutions diverge after 25 iterations, it is, of course,
possible that when the program was written, it was never actually run
beyond that point! (It might be that the 25 iterations that run in a few
seconds
on your desktop PC originally ran for hours on the hardware of 20-30 years
ago).
Eddie B
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc