Hi Guys, I'm working on a CFD code my predecessor developed and it's written in fortran 77. I have extensive experience in fortran 90 but am having a few teething troubles with his code. If someone could shed some light on these issues I'd be very grateful.

The code uses a common file which stores all the global variables, this file is "included" in every subroutine. There is only one common file and it contains many variables. In order to introduce some changes to the code (it's massive and a re-write would take weeks) I have had to introduce some new variables, two of these are common to the whole program so I added them to the common file, lets call them Array1 and Array2. When doing this I remembered to declare their type as double precision and allocated the correct array size, of 10,10; they were also initialised at the start of the program so that all their array elements are equal to 0.0. In this prototype code Array1 and Array2 are not altered in any way (in other words they should be maintained at 0.0; when I get this bit working Array1 and Array2 will be read from a file - that's the next step).

There are two subroutines in the program, lets call them Asub and Bsub. Asub calculates the variables A, B and C and passes them to Bsub, Bsub them performs some calculations and returns an answer. The data passed between the two routines are local variables and are not required at any other point in the program - so I didn't add them to the 'common' file. The code looks something like:

-------------------------------------

Subroutine Asub

Include Codecommon.cmn

Double Precision A,B,C

A = Array1(1,1)

B = Array2(1,1)

C = 5

CALL Bsub(A,B,C,D)

-------------------------------------

Subroutine Bsub

Include Codecommon.cmn

Double Precision A,B,C

D = function(A,B,C)

-------------------------------------

My problem is that the solutions coming out of Bsub aren't what I expect. They seem to indicate that Array1 and Array2 have had their values changed - I'm not sure how this is possible since they are not used at any other point in the program. To verify this I ran searches for every mention of the variable names - they only appear where I expect them to. I also wrote a line into Bsub that printed the values A and B to a file every time the subroutine was accessed; I found several non-zero values (magnitude around 4e-4).

Once Array1 and Array2 have their values initiated to 0.0 I expect them to stay that way, they are not altered at any point in the code. I suspect this is something to do with the use of "include" and common files but I'm rather unfamiliar with these concepts. When I use global variables I always put them in modules.

If someone could please help - you may just save my sanity CFD nerd

The intent of your code additions is straightforward, and I think the FORTRAN standard specifies static behavior for COMMON block variables, so that their values should not change unless explicitly assigned. The anomalies that you notice are due to either a compiler bug or, more likely, due to some tricks or an error in the legacy code.

First, turn off all code optimization during the compilation, via a compiler flag at the command line or in the makefile. Or, if possible, use a different compiler, also without optimization. If the problem disappears, then it may be due to a compiler bug in an older compiler. This is an unlikely possibility, and I only mention it because it is easier to check.

Second, assume a bug or trick in the legacy code, arising from the assumption of linear memory. Many older FORTRAN codes assumed that variables would be stored in memory sequentially in the order that they occurred in a COMMON block. Thus, there might be some loops which write to more than one COMMON block variable, though they refer to only one variable when writing (look for any EQUIVALENCE statements). If this was intentional, and carefully programmed, then you can avoid the problem by either moving Array1 and Array2 to the end of the global COMMON block in which you might have stuck them, or even better, moving them into their own named COMMON block in the Codecommon.cmn file, such as

COMMON /nerd/ Array1(10,10), Array2(10,10)

Note that there is only one unnamed COMMON block, but there can be multiple named COMMON blocks such as the one named "nerd" above.

If the overwriting was unintentional on the other hand, then you have stumbled upon an existing bug in the legacy code, and you have the opportunity to fix it and not just make the current symptoms go away by sticking the new arrays in their own named COMMON block. However, tracking down the bug is not trivial.

Another possibility is that you might be running out of memory, though this seems unlikely, since Array1 and Array2 are so small.

Also, make sure that all "include" statements refer to the same "Codecommon.cmn" file, in case you had changed some include statements to refer to a newer common block file. The include statement is unlikely to be the culprit, as its only effect is to substitute the code in the included file for itself, but it is important to include the correct file!

That is all that pops into my head.

Another thought is that you could turn on the "array bounds checking" flag on your compiler, though I do not know whether this would cause the code to throw an exception for intentional spanning of multiple variables in a COMMON block by writing to the first of them.

Thanks for your help Ananda, I fixed the problem by changing the common file (again) to add all the new variables into a new, named common block instead of placing them in pre-existing blocks. I recompiled everything and the program seems to work now.

I am unsure as to WHY this fix worked - the code never refers to the common blocks by name and every routine includes the entire common file.

Thanks again for your helpful advice - it is much appreciated. Blunder

Glad I could help, Blunderbus. The reason the fix worked is that any given common block, whether named or the unnamed one (the unnamed one is referred to as BLANK COMMON in discussions), represents a single contiguous block of sequential memory locations. (Any common block is unrelated to another with a different name.) Therefore, the code may assume two variables to be adjacent in memory if they are adjacent in a common block, even though the code never refers to the common block by name. Thus,

COMMON /THERMO/ T(3), V(2,2)

is laid out in memory as T(1), T(2), T(3), V(1,1), V(2,1), V(1,2), V(2,2), and therefore

DO I = 1, 7

T(I) = REAL(I)

END DO

will result in V(1,1) being assigned the value 4.0, etc., upto V(2,2) being assigned the value 7.0. This is legal and well-behaved even in F95, though people like you who have learned a modern style of programming wisely steer clear of COMMON blocks. The legacy code you work with must be using such an assumption of sequential memory allocation. Putting the new variables in a separate named COMMON ensured that they did not interfere with the storage association assumed in the pre-existing blocks.

Nasty language. No wonder planes (etc) crash.