Fortran - Maintaining a Dusty Deck

Author

Maintaining a Dusty Deck

rih5342

2004-10-13, 8:56 pm

Hi Fortraners,

I've been maintaining an old code, ~500 subroutines and
~90000 lines and have run into a problem.

I'm using CVF V6.6(b?) and the MS IDE.

When the subroutines are arranged 1 subroutine per file,
the program compiles, links, and runs okay.

I'd like to organize the code into modules.

As a first step, I have written some fortran source files using only
"include" statements with the names of the subroutines intended to be used
in the modules.

Just to be clear, I'm not using modules yet.

Compiling this source generates countless errors.

I mean countless.

Any change seems to trigger a cascade of different errors.

If the code generates reasonable output for the test cases,
am I fooling myself by thinking the code has some integrity.

I find it suprising that the way the code is presented to the compiler
would matter like this.

My dilemna is: should I leave the code as is (1 sub/file), or force the
organization.

Thanks, all comment appreciated.

Rob

Richard E Maine

2004-10-13, 8:56 pm

"rih5342" <rob.hickey@nospam.alum.mit.edu> writes:

> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.

I don't quite understand that. One includes files - not subroutines.
I think showing an actual sample woudl work better than trying to
explain it in words, even if it were an incomplete sample.

> Compiling this source generates countless errors.
>
> I mean countless.

Well, how about showing us at least one of them?

I think we need some specifics here. Show us Fortran instead of
English. I just don't see any hard data to work with.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Gordon Sande

2004-10-13, 8:56 pm

rih5342 wrote:
> Hi Fortraners,
>
> I've been maintaining an old code, ~500 subroutines and
> ~90000 lines and have run into a problem.
>
> I'm using CVF V6.6(b?) and the MS IDE.
>
> When the subroutines are arranged 1 subroutine per file,
> the program compiles, links, and runs okay.
>
> I'd like to organize the code into modules.
>
> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.
>
> Just to be clear, I'm not using modules yet.
>
> Compiling this source generates countless errors.
>
> I mean countless.
>
> Any change seems to trigger a cascade of different errors.
>
> If the code generates reasonable output for the test cases,
> am I fooling myself by thinking the code has some integrity.
>
> I find it suprising that the way the code is presented to the compiler
> would matter like this.
>
> My dilemna is: should I leave the code as is (1 sub/file), or force the
> organization.
>
> Thanks, all comment appreciated.
>
> Rob
>

As a first step you can try to get many of the benefits of F90 for
little effort. A scheme that worked for me was to change the main
program into subroutine main and include everything after a "contains".
So

program NEW
implicit none
call main
contains
include "first file"
...
include "last file"
end

and fix bugs. The gotchas are that external statements "hide" the
functions so passed subroutine names will not work. This will
clean out bad calls (amazing how many are still there!) and
allow a start on use of assumed shape (":") rather than assumed size
("*"). One of the effects of modules is to have explicit interfaces
built for you. This also gets those interfaces built for you.
A module of interface blocks is a recipe for trouble and not
suggested by or for anyone (other than for some library builders under
other sorts of duress!).

Tim Prince

2004-10-13, 8:57 pm

"rih5342" <rob.hickey@nospam.alum.mit.edu> wrote in message
news:b952c0555b0dfa9ed41893ce18724b97@lo
calhost.talkaboutprogramming.com...
>
> Hi Fortraners,
>
> I've been maintaining an old code, ~500 subroutines and
> ~90000 lines and have run into a problem.
>
> I'm using CVF V6.6(b?) and the MS IDE.
>
> When the subroutines are arranged 1 subroutine per file,
> the program compiles, links, and runs okay.
>
> I'd like to organize the code into modules.
>
> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.
>
> Just to be clear, I'm not using modules yet.
>
> Compiling this source generates countless errors.
>
CVF performs call interface checking by default when everything is compiled
together. With separate compilation, you would get checking only at run
time, only if you asked for it. If you use modules, you will force the
compiler to perform some of these checks. When checking, CVF does reject
some things which are dangerous but wouldn't necessarily cause failure.

2004-10-14, 3:59 pm

rih5342 wrote:
>
> My dilemna is: should I leave the code as is (1 sub/file), or force the
> organization.

Forget about modules and set your mind on dlls - a headache free
transition that will keep your dusty deck speeding along, while the
"misguided" would still be poking around their silly interfaces.

beliavsky@aol.com

2004-10-14, 3:59 pm

bv <bvoh@Xsdynamix.com> wrote:
>rih5342 wrote:
>
>Forget about modules and set your mind on dlls - a headache free
>transition that will keep your dusty deck speeding along, while the
>"misguided" would still be poking around their silly interfaces.
>

Quoting Catherine Rees Lay from a recent message here with subject "Re: Problem
with double precision function":

"Whether or not he uses a DLL has absolutely nothing to do with whether
he should use a module.

DLLs are OS-specific file types, and whether you get one or not depends
on how you link your object files, module files, lib files etc.

Modules, on the other hand, are a type of source code, and can be built
into libraries, DLLs, executables and I've no doubt a wide variety of
other system-dependent things.

I like DLLs for a lot of situations. Generally mine have modules in
them."

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

beliavsky@aol.com

2004-10-14, 3:59 pm

"rih5342" <rob.hickey@nospam.alum.mit.edu> wrote:
>
>Hi Fortraners,
>
>I've been maintaining an old code, ~500 subroutines and
>~90000 lines and have run into a problem.
>
>I'm using CVF V6.6(b?) and the MS IDE.
>
>When the subroutines are arranged 1 subroutine per file,
>the program compiles, links, and runs okay.
>
>I'd like to organize the code into modules.
>
>As a first step, I have written some fortran source files using only
>"include" statements with the names of the subroutines intended to be used
>in the modules.
>
>Just to be clear, I'm not using modules yet.
>
>Compiling this source generates countless errors.
>
>I mean countless.
>
>Any change seems to trigger a cascade of different errors.
>
>If the code generates reasonable output for the test cases,
>am I fooling myself by thinking the code has some integrity.
>
>I find it suprising that the way the code is presented to the compiler
>would matter like this.
>
>My dilemna is: should I leave the code as is (1 sub/file), or force the
>organization.
>
>Thanks, all comment appreciated.
>
>Rob

Programming in F77 without MODULEs or INTERFACEs, if you compile each source
file into an object file and then link the object files to create an executable,
the compiler may not catch certain errors, in particular procedures called
with the wrong number or type of arguments. When compiling the entire program
at once, in your case using INCLUDE, the compiler may catch those errors.
How much checking is done depends on the compiler. Do the compiler error
messages point to real problems in your code?

I suggest trying the free Fortran 77 static analysis tool FTNCHEK.

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

John C. Bollinger

2004-10-14, 3:59 pm

Gordon Sande wrote:

> rih5342 wrote:
>

[...]
[color=darkred]
> As a first step you can try to get many of the benefits of F90 for
> little effort. A scheme that worked for me was to change the main
> program into subroutine main and include everything after a "contains".
> So
>
> program NEW
> implicit none
> call main
> contains
> include "first file"
> ...
> include "last file"
> end
>
> and fix bugs. The gotchas are that external statements "hide" the
> functions so passed subroutine names will not work. This will
> clean out bad calls (amazing how many are still there!) and
> allow a start on use of assumed shape (":") rather than assumed size
> ("*"). One of the effects of modules is to have explicit interfaces
> built for you. This also gets those interfaces built for you.

On the other hand, this approach runs a significant risk of introducing
new bugs because of subroutines acquiring variables by host association.
That risk would be reduced or eliminated if one could be certain that
each subprogram declared all the variables it uses, but in my experience
that is not the case in a typical dusty deck. If a subroutine and the
main program happen to use different variables with the same name, and
if the subroutine's is not declared, then the program semantics are
different when the subroutine is contained in the main program than when
it is external.

My first step in these cases is usually to try to clean up the code and
bring it into conformance with Fortran 77. FTNCHEK is my workhorse
here. In light of my comments above, one of the things FTNCHEK can do
is to generate declarations for undeclared variables, which can be a big
time saver. But it can do much, much more.

John Bollinger
jobollin@indiana.edu

Kevin G. Rhoads

2004-10-14, 3:59 pm

>My dilemna is: should I leave the code as is (1 sub/file), or force the
>organization.

Neither -- as others have suggested, there are many possible intermediate
steps that you can and should try first.

1) present organization - make sure all variables are declared
2) start regrouping in a small way, find, understand and fix all
problems found
3) code checkers are helpful
4) compiling with alternate compilers can also be helpful (OpenWatcom,
G77 & possilbe the "free, personal" versions of various F77 compilers)

Do not attempt to get everything in one file as the first step, it
is too much at once.

Once strict F77 conformance is achieved and confirmed, rewriting
interfaces to F95 module style can be started (if you want).

Jan Vorbrüggen

2004-10-14, 3:59 pm

> On the other hand, this approach runs a significant risk of introducing
> new bugs because of subroutines acquiring variables by host association.

I di not think this can happen here - the program is empty except for the
CALL MAIN. Subroutines on the same level of containment, as it were, do not
share variables.

Jan

James Parsly

2004-10-14, 3:59 pm

One of the things that would cause "countless errors" would be passing
variables with
the wrong type to subroutines. This would not be caught if subroutines are
not compiled
together, since the compiler would not "see" the caller and callee at the
same time. When
compiled together, the compiler will spit out errors. You can turn this
off: Project...
Settings... Fortran....Compiler, then uncheck the box that says Argument
Mismatch.

Why would someone do this? I have seen it used in older programs as a way
to get
around a lack of allocatable arrays. The technique involves creating a
single large
array in the main program, then doling out slices to subroutines, without
regard to the
type. For example

DIMENSION ARRAY(10000)
C
C read some inputs describing problem, determine that subroutine needs 3000
integer
C values in array IARRAY, and 2000 integer elements in array BARRAY
C and suppose that this causes variable IASTART to be set to 1 and IBSTART
to
C be set to 3001
C
call sub1(array(IASTART),array(IBSTART))
C
Eventually you will see subroutine SUB1
SUBROUTINE SUB1(IARRAY,BARRAY)
C
C you also see this a lot in older programs, declaring passed arrays
C with a dimension of 1.
c
dimension IARRAY(1),BARRAY(1)
C
C at this point IARRAY is actually starting at the same location as
ARRAY(1)
C and you can use up through IARRAY(3000)
C BARRAY(1) is at the same location as ARRAY(3001)

This assumes that integers and reals take up the same space, and that
subroutine arguments
are passed by reference.

If these assumptions are true, everything will generally work ok.

Perhaps this is what is happening in your case, but we'd need to see some
error messages
and code to make a better diagnosis.

"rih5342" <rob.hickey@nospam.alum.mit.edu> wrote in message
news:b952c0555b0dfa9ed41893ce18724b97@lo
calhost.talkaboutprogramming.com...
>
> Hi Fortraners,
>
> I've been maintaining an old code, ~500 subroutines and
> ~90000 lines and have run into a problem.
>
> I'm using CVF V6.6(b?) and the MS IDE.
>
> When the subroutines are arranged 1 subroutine per file,
> the program compiles, links, and runs okay.
>
> I'd like to organize the code into modules.
>
> As a first step, I have written some fortran source files using only
> "include" statements with the names of the subroutines intended to be used
> in the modules.
>
> Just to be clear, I'm not using modules yet.
>
> Compiling this source generates countless errors.
>
> I mean countless.
>
> Any change seems to trigger a cascade of different errors.
>
> If the code generates reasonable output for the test cases,
> am I fooling myself by thinking the code has some integrity.
>
> I find it suprising that the way the code is presented to the compiler
> would matter like this.
>
> My dilemna is: should I leave the code as is (1 sub/file), or force the
> organization.
>
> Thanks, all comment appreciated.
>
> Rob
>
>
>
>
>
>
>
>

Richard E Maine

2004-10-14, 3:59 pm

"James Parsly" <japarsly@nospam.tva.gov> writes:

> One of the things that would cause "countless errors"...

Another even more trivial possibility ocurred to me. It is part of
why I'd really like to see some code. This whole thing could be
nothing but a trivial misunderstanding of a kind that I *HAVE* seen
before. Namely, I've seen people do

program main
... code of the main program
include 'sub1.f'
include 'sub2.f'
end

Note in particular that the includes are before the end statement and
that this is for f77 code - no internal procedures involved here. That
will indeed cause "countless errors" and is trivially fixed by moving
the "end" statement.

I don't know whether this is the cause, but it could be, and we could
easily waste an awful lot of time speculating about things that are
far more complicated and completely irrelevant.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

rih5342

2004-10-14, 8:56 pm

My real problem is that I over estimated the "quality"
of the code and under estimated the amount of time
needed to improve it.

The countless errors are reasonable, understandable
and fixable, but always times 500, just about every file
needing attention, and many times.

Show some code, good point point, speak with data.

I planned on organizing the code roughly as follows.

c typical contents of file
c module one
c contains
include "sub1.for"
include "sub2.for"

John C. Bollinger

2004-10-15, 3:56 am

Jan Vorbrüggen wrote:
>
>
> I di not think this can happen here - the program is empty except for the
> CALL MAIN. Subroutines on the same level of containment, as it were, do not
> share variables.

Ah, I see. I missed the critical point that the main program becomes
another subroutine instead of the host. You're quite right that in that
case the host association problem is not applicable. I still maintain,
however, that bringing the code into at least approximate compliance
with a suitable standard is a valuable first step, and the standard
likely to be the most useful for such a code is Fortran 77.

John Bollinger
jobollin@indiana.edu

Gordon Sande

2004-10-15, 3:56 am

John C. Bollinger wrote:
> Jan Vorbrüggen wrote:
>
>
>
> Ah, I see. I missed the critical point that the main program becomes
> another subroutine instead of the host. You're quite right that in that
> case the host association problem is not applicable. I still maintain,
> however, that bringing the code into at least approximate compliance
> with a suitable standard is a valuable first step, and the standard
> likely to be the most useful for such a code is Fortran 77.
>

This is a classic demonstration of the fact that the best is often an
enemy of the good. A battery of external tools is proposed as better.
The F90 compiler is merely good with the advantage that it is ready
to accept all F90 features as the code is migrated from F77 to F90.

The Fortran 90 compiler is both a very effective tool and an immediately
available tool. If one had a collection of Fortran analysis tools at
hand then one would use them. The bother is that folks in trouble
tend to not have a collection of analysis tools at hand. The OP seems
to have indicated that there is a fair bit of argument mismatch in
the original collection. An F90 compiler will catch that just like
FtnCheck, or the SoftTools, or the NAGWare Tools or other analysis
sets. But the F90 compiler has the unique property that it is built
into the F90 compiler and also analyzes both F77 and F90.

Fixing argument mismatches is a real bother particularly as some
standard F77 idioms for dynamic storage rely on them. Other bothers
are some standard idioms for character handling.

>
> John Bollinger
> jobollin@indiana.edu

2004-10-15, 3:56 am

"beliavsky@aol.com" wrote:
>
> Quoting Catherine Rees Lay from a recent message here with subject "Re: Problem
> with double precision function":

As irrelevant today as it (probably) was when posted. You should really
reexamine the OP, and you might even come up with a more constructive
advice -- in this case parceling code into modules is not the way to go.
In fact, it's a prescription for disaster!

Richard E Maine

2004-10-15, 3:58 pm

"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> writes:

> Quoting Catherine Rees Lay from a recent message here with subject
> "Re: Problem with double precision function":
>
> "Whether or not he uses a DLL has absolutely nothing to do with whether
> he should use a module.

Ah. But you clearly don't realize that DLL's are the solution to
everything. The reason we didn't find any WMDs in Iraq is obviously
that Saddam realized that DLLs would be much more effective. :-) :-)

And certainly DLLs will fix whatever compilation errors the OP is
seeing. You can't have compilation errors with DLLs, partly because
if you are smart enough to know to use DLLs for everything, then you
are obviously will be above the level of those who sometimes make
mistakes in writing code. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links