common blocks and allocatable arrays

common blocks and allocatable arrays

Hello!

I need to work on an old fortran code. The code contains a lot of subroutines and common blocks in each subroutine. I want to increase the size of the arrays defined in the common blocks in the subroutines. But the size for the static arrays is limited. So I start to consider the allocatable arrays. However, the allocatable arrays are not allowed in the common blocks. I am wondering if anyone has any good idea for this problem.

Thanks for your answer and help.

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

common blocks can be easily replaced by Modules. Only 'gotcha' is in some of the 'old' code the code assumes the storage is linear. that would probably be the the only reason you would need to continue to use common blocks.

Yes, u r right. I will try to build a module to include the varaiables in the common blocks. 

i would recommend that you simply create a separate module for each common block. then routines USE the module with the same name as the common block. easy way to start is to simply copy each common block into a spearate module. Then comment out the common block and declare each variable (i would be willing to bet the common blocks in your old programs are implicitly declared by first letter of the variable name!)

You can also, in most cases, do away with the COMMON entirely and just make the variables module-level variables. You wouldn't want to do this if you rely on "storage association", where the order of the variables in COMMON mattera.

Steve - Intel Developer Support

bmchenry and Steve,

I believe Module-level variables is the best effect way for my case. Maybe as bmchenry suggests, the way to put different common blocks into separate modules should work with my case. Since the following may happen sometimes: the common block "P" declared in subroutine "A"  does not appear in subroutine "B", and some variables in subroutine "B" have the same names as the ones in common block "P". By seperating the modules and USE different modules in different subroutines, the error can be avoided.

 But my questions are: 1) Is there any limitation for the number of modules being used? Since there are so many common blocks in each subroutine, that means there will be a number of seperate modules. 2) What will happen during the compiling if I have so many seperate modules?

my only suggestion to keep the module names the same as the common names was for convenience. Then comment out the common and declare all the variable in the module (leave the commented out common in the module as a reminder of original form and to check for typos!)

1) Is there any limitation for the number of modules being used? Since there are so many common blocks in each subroutine, that means there will be a number of seperate modules. Nope. Or at least more than you could possible need (you can look up the max in the users manual...since named common blocks are limited only by memory constraints i am guessing same goes for modules)

2) What will happen during the compiling if I have so many seperate modules? it compiles them! I normally put modules in the resource section (for convenience) and i normlly name them with a 'mod_' before the name like: mod_whatever.f90 so you know that's it's a module. The compiler scans files in your project and will recognize and compile modules first before subroutines.

Thanks, bmchenry!

You might consider, if you have lots of modules, putting them in a Static Library project that is made a dependent of the main project. Really just for organization sake, but not a requirement.

Steve - Intel Developer Support

With COMMON, it was typical/good(?) programming practise to INCLUDE common from a single file. Converting these to MODULE, changing INCLUDE to USE is a simple and fairly safe process.

If INCLUDE was not used, this is a warning sign that there may be problems. You need to check the list of variables in each COMMON list to ensure there is no change to the type, kind or size.
The use of EQUIVALENCE is also a big warning sign that the conversion to modules will be a problem.

John

Leave a Comment

Please sign in to add a comment. Not a member? Join today