![[BIG]](../icons/zoom18.gif){kind=icon}
![[Normal]](../icons/zoom14.gif){kind=icon}
![[small]](../icons/zoom10.gif){kind=icon}
Next: Part II: Programming and Utilization Standards Up: 1 General Prev: 1.6 Data Structures Index Contents
Next: Part II: Programming and Utilization Standards
Up: 1 General
Prev: 1.6 Data Structures
Index
Contents
This corresponds to dissociating the external (or functional) aspect of a module from the internal aspect.
The equations of a problem put in play mathematical operators. A module is the computational realization of such an operator. It is materialized by a subroutine, which reads one or several Input Data Structures (IDS) and generates one or several Output Data Structures (ODS) (figure 1.4).
Figure 1.4: External aspect of a module
During the development of a new module, some principles must be respected (figure 1.5):
Figure 1.5: Internal aspect of a module
In general, a module calls DS management utilities, dynamic arrays, as well as algorithms (independent of the utilities). In no case does an algorithm call a utility. The utility calls are reserved for modules.
Respecting this rule has the advantage of making the modules more reliable and readable. In addition, a subroutine materializing an algorithm manipulates classical Fortran arrays, which facilitates its programming and allows it to be used like a traditional subroutine.
Mathematical operators can sometimes be expressed as a combination of more elementary operators. It is thus advisable to program as many modules.
For example, the solution of a linear system by the Cholesky method for a skyline matrix, can be decomposed into the following series of operators:
During programming, a decomposition into as many modules is respected, i.e. in this case 5 modules (1. PREPAC, 2. ASSMUA, 3. CLIMPC, 4. CHOLPC, 5. DRCHPC). The modularity is thus preserved, ensuring ample utilization suppleness. For example, when solving an interactive system with a constant matrix, operators 1 to 4 are used only once whereas operator 5 is used as many times as there are iterations.
A module cannot ask data from the user. In fact, it must be able to be used in different contexts, in particular in an iteration loop. It would therefore be particularly laborious to enter as many data items as there are iterations. The solution recommended is to employ processors situated at the level above the module level (section 1.2). The processor reads the user data into the arrays only once, and then passes them to the modules via parameters.
The small number of rules which follow are designed to make the programs more readable, and not to constrain the user! This objective necessitates a minimum of standardization.
All subprograms start with a SUBROUTINE
or
[4] FUNCTION command, followed by comments indicating the aim of the
subprogram and the significance of the parameters
(figure 1.5).
It is desirable to separate the input parameters, the output parameters, and those whose
contents are modified.
Lastly, it is also useful to add information regarding the
programmer (name, organization, date, ...).
The reading of program is facilitated by the presence of significant and clear comments. The outline of the algorithm should be apparent by merely reading these comments.
The names of subprograms must be as simple and descriptive as possible (in spite of the Fortran limit of 6 characters!). Before naming a program, it is necessary to ensure that the name does not exist already (by consulting a listing or the procedure data base, PROIMP, see [MODULEF User Guide - 1] Appendix C).
The names of variables must be the same as those used in the documentation of the module and, if possible, respect the MODULEF "habits". For example, the number of elements is designated by NE rather than NELEM, NEL, etc...
When an error is detected, it must be signaled by a clear error message, which contains the subprogram name where the error was detected and, if possible, indicate the remedy.
Try to avoid astute programming. If not, give clear explanations in terms of visible comments!