Module Public variables OR Common areas ?

[Phares__Cliff]

I'm converting a large VMS Fortran process model ofplastics plantto IVF. The legacy codes makes abundant use of common areas.

I'm finding that I like to pass data between modules using two methods:

1) create COMMON area .FI's and include them whereever I which; or,

2) place those COMMON area variables in the MODULE public data space and use USE in other modules.

Are there other commonly used techniques ?

In terms of code maintenance, is one method more maintainable than the other ?

In terms of performance, does one method execute faster ?

Or is it just a matter of 'taste' ?

Thanks in advance,

- Cliff

[Steven_L_Intel1]

If you are creating new shared variables, make them module variables and not COMMON. If you have existing COMMONs and want to shift to using modules instead of include files, then go ahead and put the COMMONs in modules.

My recommendation, in the absence of other reasons, is to use module variables and not COMMONs, as it allows better control of the namespace. There's no performance difference I can think of.

[Phares__Cliff]

Thanks Steve.

Same question about parameters. Some parameters specify array sizes, some are flags, and some are array element pointers. Do you prefer to define these in include files and then include them when needed, or do you prefer to list these in the data space of a module ?

Thanks again,

- Cliff

[Les_Neilson]

Cliff

My preference would be to keep the relevant parameters with the data, ie the sizes and the element pointers in the module(s) containing those arrays. Maintenance is so much easier when it's all in one place (eg array size changes)
The flags parameters could go in their own module if they are general and do notapply to specific data or contained subroutines/functions.

Les

[Steven_L_Intel1]

I'm with Les on this one - keep everything together in a module. If you have definitions that are shared among modules, put them in their own module (for example, many people create a KINDS module to define KIND constants and then use those everywhere.)

Don't be afraid to have multiple modules if functional grouping suggests that. The worst thing is to pile everything into one big module.

[DavidWhite]

Just expanding on this thread slightly - what about subroutines and functions within modules?

I tend to use modules mainly for defining variables and parameters, but I have noticed some people put almost all their executable routineswithin large modules. What are the advantages and disadvantages of this?

Thanks, David

[Steven_L_Intel1]

If the functions are logically grouped with other things in the module, that makes sense. With module procedures you can take advantage of PRIVATE data and routines and expose only the names you want. It can also be cleaner to code as the module routines have access to everything in the module automatically.

Again, it helps if the things in the module are related. For example, you might have a GLUG type and a collection of routines to create and manipulate things of that type. Then it would make sense to package all the GLUG things into a single module.

[Les_Neilson]

To add to what Steve has said, another big advantage of using modules is interface checking. It helped me identifyseveral argumentmismatches.
Also, I have modules with lots of allocatable (and resizeable)arrays; so I have contained routines to allocate and initialise, deallocate and re-allocatethe arrays. Then there are routines to read the data from file and write the data to file.
Ifa routine or function only operates on the module data then it makes sense to have it as a contained routine. Some prefer to declare module variables as private and have Get and Set access routines so changing the data becomes deliberate rather than accidental as in the old days of common blocks and subscript errors :-(painful memories of bug hunting.

Les