 |
 |
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 > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%