submodules?

A while back I asked about the best strategy for replacing common blocks
with module variables. In a package with about a dozen routines,
various groups of variables are needed by 2, 3, 4, 5, 6 etc routines.
(Those needed by only 1 routine are just internal variables in that
routine, of course.) Up until now, I had declared the appropriate
variables and common blocks in the routines which needed them.

One approach would be to put all these variables in one module and USE
that or, probably better, make them module variables in the module which
contains all the routines. I don't like this for the same reason I
didn't have them all in one common block: I want each routine to see
only the variables it actually needs.

Another approach would be to translate the common blocks to modules. In
some sense this is equivalent, since both modules and common blocks are
global objects. However, common blocks are declared only in the
routines which need them (and perhaps in a BLOCKDATA routine for
initialization) while a module is declared at a higher level, i.e. at
the same level as the module which contains all the routines---at least
visually if not actually in terms of implementation. I don't like the
idea of writing a module with a dozen routines, several thousand lines
of code, and then 6--10 auxiliary modules of just a few lines each.

The approach I adopted was to put all these shared variables in one
module but add ONLY to the USE statements in the routines. This allows
each routine to see only the variables it needs. However, I obviously
have to keep the ONLY lists in sync by hand.

It seems the logical thing would be to have instead of

USE SHARED_VARIABLES, ONLY: X, Y, Z

something like

USE SHARED_VARIABLES, ONLY: A

where A is the name, not of a variable, but of a "submodule" in the
module SHARED_VARIABLES, i.e. something like

MODULE SHARED VARIABLES
CONTAINS
SUBMODULE A
REAL :: X, Y, Z

I understand that sometime after F95 submodules were implemented. Are
they similar to what my "submodule" above does? What else can they do?

.

Relevant Pages

  • communicating the name of a function to deep within the call tree
    ... Internally, these call other routines etc, and 6 or 7 levels ... I'm now re-writing the stuff in good Fortran95 style: ... module files (compilation result) are found when compiling stuff which ... I obviously don't want to keep these common blocks, ...
    (comp.lang.fortran)
  • Re: Pb with the nonlinear solver "hybrd"
    ... first you have to get it to compile. ... HYBRD.F contains multiple routines, and you need to ensure that these ... Although it shouldn't affect CVF ... I would check that there are no COMMON blocks being used to pass data, ...
    (comp.lang.fortran)
  • Re: Pb with the nonlinear solver "hybrd"
    ... HYBRD.F contains multiple routines, and you need to ensure that these ... routines have unique names - no duplicates. ... I would check that there are no COMMON blocks being used to pass data, ... I have known numerical integration routines that specifically ...
    (comp.lang.fortran)
  • Re: suggestions for restricted sharing of variables
    ... communicate between pairs of routines in an additional module, ... In F77 I had COMMON blocks and the ... subroutine alpha ...
    (comp.lang.fortran)