Over the past five years we have converted a fairly large program from
FORTRAN 77 to Fortran 90/95. It comprises well
over one thousand units (files), several thousand procedures and about
100,000 lines of source code. (The downward
compatibility of Fortran 90/95 has made the conversion easy and allowed us
to fit it in as time was available.)

 Briefly, we've found we've had to weigh three considerations in organizing
our code: execution speed,
maintainability, and compilation speed. We've developed the following
guidelines:

--- Don't place all procedures in modules and use modules only when needed

 We find we often define a derived data type in a module; this is one of the
best uses of one. We declare the type
components private and use module procedures to access them. This is a
standard data hiding practice and we use it in code
that does not have to run particularly quickly. We end up with many such
modules, each for a different derived type. Where do
you place a procedure that needs variables of two or more of these types? A
procedure in one module can reference a procedure
in another only if it uses it. In our large program we've often found
ourselves in a situation in which we wish a procedure
in module A to call one in module B and one in module B to call one in
module A. Both require access to the derived types
defined in each. This type of circular dependence is not allowed. One
solution is to break out the calling procedures in both
modules as external; both use modules A and B. We've found it easy to
organize and reorganize our code if many procedures are
external like this.

--- Always use interface blocks for external routines.

 We've found the easiest method of organizing this is to use what we call an
include argument or include interface
file. Put all the interfaces in one or more modules. An example shows this
best. Say you have an external procedure like
this:

 function MyFunc (Arg1, Arg2, Arg3) result (FuncResult)

 implicit none
 integer, intent(in) :: Arg1
 real, intent(in) :: Arg2(:)
 logical, intent(in), optional :: Arg3
 real :: FuncResult

 .
 .
 .

 end function MyFunc

Note that the assumed shape array argument and the optional argument make an
explicit interface block necessary.
Break this up as follows:
First create a file containing the following code

 implicit none
 integer, intent(in) :: Arg1
 real, intent(in) :: Arg2(:)
 logical, intent(in), optional :: Arg3
 real :: FuncResult

and call this file MyFunc.a90. Modify the original file to read

 function MyFunc (Arg1, Arg2, Arg3) result (FuncResult)
 include "MyFunc.a90"

 .
 .
 .

 end function MyFunc

and in a third unit you have

 module AllMyInterfaces

 interface
   function MyFunc (Arg1, Arg2, Arg3) result (FuncResult)
   include "MyFunc.a90"
   end function MyFunc
 end interface

 end module AllMyInterfaces

and you use this last module in every unit that needs to reference MyFunc.
There might be hundreds of these, but if you
change the interface to MyFunc you need modify these three files only. For
this to work you must make the compiler do its
job, and to do this you should always specify implicit none, specify the
intent of every argument, and use the result form of
the function declaration.

 One potential problem with this arises in self-reference but is easily
remedied. In the above example say MyFunc
references a second external procedure whose interface block is also in
module AllMyInterfaces. In the use statement in
MyFunc you should dummy out the self-reference as follows:

 use AllMyInterfaces, Dummy => MyFunc

The compiler we use issues a warning if this isn't done. Others may be more
stringent.

 Another potential problem occurs if you throw all the interface blocks into
one module as implied in the above
example. You can easily be in a situation where hundreds or thousands of
program units would use this module, and a change in
only one interface will trigger a massive time-consuming rebuild. If this is
a problem, creating several different interface
modules, arranged perhaps by functionality, would be fruitful.

--- Isolate modules and avoid lengthy compilations by placing a second
module between it and the remainder of the code.
Again, an example shows this best:

 Say you have a module containing procedures that will be referenced
throughout your program. The module is large and
you anticipate modifiying it frequently. If directly used by everyone
referencing it, each modification triggers a large
make. Call this module A

 module A
 .
 .
 .
 contains

 function A1 (ArgA1, ... ) result (A1Result)

 .
 . ! lots of code
 .

 end function A1

 subroutine A2 (ArgA2, ...)

 .
 . ! lots of code
 .

 end subroutine A1

 .
 . ! many more procedures
 .

 end module A


Create a second module as follows:

 module RefA

 use A

 contains

 function RefA1 (ArgA1, ...) result (A1Result)
   A1Result = A1 (ArgA1, ...)
 end function RefA1

 subroutine RefA1 (ArgA2, ...)
   call A2 (ArgA2, ...)
 end subroutine RefA2

 .
 .
 .

 end module RefA

(This is a skeleton; the type and kinds of all entities would of course have
to be declared.) All program units that need to
reference the module procedures in module A should use module RefA, not
module A, and reference its module procedures, not
those in module A. Now you can modify module A as often as required, but
RefA needs to be modified only when an interface in
module A is changed; otherwise it's static and no large program
recompilation is required. Module RefA is the only one that
uses module A.

 The obvious large drawback here is you're slowing down the program, making
two procedure calls where one would
suffice. We use this technique for the parts of our program that are not
time-critical.

--- Use the only clause sparingly.

 Recommendations have appeared that the only clause be used extensively to
speed up the compilation, the justification
being it aids the compiler in resolving all the entity references. This is
certainly true, but we've run into the following
maintenance problem: We design a module, say module A, that contains entity
EntB, and we have four hundred other units that
contain the statement

 use A, only : EntB

What happens if a program redesign dictates EntB be moved to module A: you
have to edit all four hundred program units.

Hope this will help.

Norm Clerman
OPCON Associates, Inc.
www.opconassociates.com
[log in to unmask]



----- Original Message -----
From: Harvey Richardson - Sun UK Principal Systems Engineer
<[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, March 06, 2000 8:22 AM
Subject: Use of Modules in large Fortran applications


> I was wondering if there is a consensus on how to use modules in
> the context of building a large Fortran application.
> There was some previous discussion of the issues surrounding this
> but some time has now passed and my search of the archives did not
> reveal much of that discussion.
>
> If I recall correctly some of the issues were:
>
>  * Avoid forced recompilation of large sections of code due to
>    dependencies.
>
>  * Avoid defining interfaces separately from the implementation
>    as this can lead to mismatch of the interface and implementation.
>
> No doubt various approaches can help
>
>  Use nested modules
>
>  Use automatic interface generation (are there public tools to do this?)
>
> I would be interested in any experiences relating to the above.
>
> Harvey Richardson
> Sun UK Performance Centre
>
>



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%