Hello, i have a doubt.
In a program i have 2 differents names for the same COMMON.
They have the same name however some variables have different name.
My question is R and R1 have the same value or not ?
Thank you very much for your attention.
In a program i have 2 differents names for the same COMMON
That is not true; both files have the same common block name, namely, MAPOT, and that is a significant property.
Within a common block, what matters is the offset (byte offset, usually) of each variable relative to the start of the common block. As long as the variables have the same type, kind and rank in the two files, the actual names do not even matter. If fact, if you look at the generated code, you will see variables being represented by addresses with the base of the common block in a base register or as the constant in an assembly instruction r/m expression.
In short, R and R1 are "the same", provided that in the rest of the code, which you did not show, wherever R appears in the first file R1 appears in the second file, and so on.
The parameters LSM, LM, and LP1 must be defined the same for ERLAM0, CPHI0, and SPHI0 to align at the same offset in MAPOT.
My question is, In my program, i have some subroutines with:
And I'm trying create a module for it.
Boths are the same COMMON /MAPOT/ with the same number of variables, however some variables have different name.
How can i replace it using MODULE ?
Thank you very much for your attention
I suggest doing the source code modification in two steps.
First of all, in those routines that include COMMON_MAPOT1.F90, see if variables R and R1 both occur. If not, simply replace R1 by R in those routines. Similarly for other variable pairs.
For those instances where both names occur and are used in the same routine, and you do not want to edit the source to change variable names, you can use the rename feature of the USE statement:
USE <module-name>, <local-name> => <use-name>, ...
For details, see a Fortran reference manual.
mecej4's second suggestion is good, (great actually), but you need to be aware of one thing,
Same named COMMONs are essentially equivalent to UNIONs. In the cases shown where R and R1 are both REAL, the R1=>R on USE will be correct. However, you could just as well have code that has an INTEGER or other types placed in the same locations within the COMMON. For these you may have to handle differently (via UNION and MAP).
Hello Mecej4, And Jim
Thank you very much for your help !
It works almost nice for me.
How ever i got another problem.
I have 3 Common Blocks that uses the same Variables. I Attached them, Its MAPOT, DYNAM and PHYS.
All of them have PT, DETA and AETA variables.
When i susbstituted MAPOT and DYNAM for MODULES and used the USE <module-name>, <local-name> => <use-name>, ... it works perfect, but for the PHYS if give-me little differences on the final result.
I separate all the other variables that are equals in PHYS and PHYS2, and i implemented it as MODULE_PHYS0.f90 and I kept the PT, DELTA and BETA variables in COMM_PHYS.f90 and PT2, DELTA2 and BETA2 variables in COMM_PHYS2.f90 It works perfect, so the problem is in this 3 variables PT, DETA and AETA.
Some ideia how to solve it ?
Thank again for your attention.
Sorry, we know nothing about your application and all that you have shown are a bunch of COMMON block lists. So, there is no basis for you to expect any comments about code that you have not shown, i.e, the code with the USE statements with variable name substitutions.
The Excel table conveys no useful information to me.
It is up to you to check that variables in COMMON are used properly. When you use different variable names in different instances of the block, it can be more difficult to make sure that (i) variables that should be accessed are in the proper locations in the block, regardless of their names, and (ii) that variables that are not expected to be touched are not altered or referenced because of confusion caused by variable renaming.
I suspect that refactoring the code to replace some COMMON blocks with modules has introduced some new bugs. You will have to work those out yourself.