Fortran namespace conflicts

Question

I'm working on coupling a couple of simulation codes together. Currently, there are 3 codes but there may be more in the future. You can think of information exchange in the following diagram:

 sim1  <====>  sim_main <=====> sim2

The information exchange is done via a limited interface on each side.

I recently diagnosed a problem where a common block in sim1 had the same name as a subroutine in sim2 which was causing a segmentation fault. The easy solution is to change the name of the common block in sim1, however that's not ideal because if the developers of sim1 come out with sim1-2.0, then I'll have to dig in and change the name of that common block again. Since the interface is relatively limited, I'm wondering if a better solution would be to write a simple module:

module sim2_mod
contains
include "sim2.f90"
end

As this should put all the routines in sim2 into the sim2_mod namespace which could be used on a limited basis. Is this a good idea? a bad idea? Are there situations where this wouldn't work? Do common blocks used in sim2 still have global scope?

Answer 1

Well, if sim2.f90 only contains lines which, when spliced into your proposed sim2_mod, form a syntactically valid Fortran source file, your suggestion will work. If not you'll have to edit the source.

While you're doing that you might as well make it a module anyway and use-associate it in sim_main. Once you've got that far, you can add an only clause, with some renaming, on the use statement and work round the name clash that way.

Common blocks do indeed have global scope throughout your program, I think the consensus within the Fortran-writing community is that the preferred way to avoid the issues that this global availability can cause, not only the issue that you currently face, is to replace them with a module which defines all the variables that the common block contains. You can then use the module variables with a bit more control over the availability and naming of the (formerly) global variables.

This approach can be tiresome to implement and does raise the possibility that the next release of sim1 will need to be reworked too. But then, isn't it about time you told the developers of sim1 to drop the common blocks and implement something a little more modern ?