forums.silverfrost.com

[technophobe]

Hi Guys, I'm working on a CFD code my predecessor developed and it's written in fortran 77. I have a good amount of 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:

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

[JohnCampbell]

My apologies if I am missing your problem.

Prior to modules, it was good programming practise to use include files for all common definition. In this format there are two main things that must be provided in the include file.

file codecommon.cmn should look like:
!
! Declare variable types and size
real*8 other_real_variables
integer*4 other_integer_variables
real*8 array1(10,10)
real*8 array2(10,10)
!
! Allocate them to common list
common /cmd_blk/ other_real_variables, other_integer_variables, &
array1, array2

In an ideal world, all variables in the include file are both declared and listed in the common block variable list.

In a less than ideal world:-
1) the variables may not be declared explicitly, then if declared in other routines, can change the length, eg mixing as real*8 and integer*4 for the same variable in different routines can change the length of the common and mess up the implied location of each variable. It was common to not declare variables, but use the first letter as implicit type. If the program was developed where integer and reals had the same byte length, this error would not have been noticed. eg on the CDC cyber machines in 1970's.
2) some variables declared, may not be listed in the common block variable list. This is a bug and would result in the variables not being transferred between routines.
3) In a realy bad programing style, there may be variables added to the common block list, locally in each subroutine, via extra continuations or by equivalence. It can happen !!

The solutions can include:-
1) Make variable declaration explicit, using IMPLICIT NONE, however this may result in a lot of work for an old program. I adopted using IMPLICIT NONE when I started using FTN95, it finds a lot of bugs.
2) You could experiment by only making sure all variables in the include file are explicitly declared, say 1 per line. (see clearwin.ins and other ftn95 include files as examples). This should find double declarations as errors when compiling with ftn95.
3) Experiment with converting the common include into a module, then include it with a use statement. This removes the problem of overwriting of arrays and may pick up the problem of array type declaration outside the module.
3) With this, old fashioned implicit equivalence can no longer be guaranteed, as the common block variable list guaranteed the location of arrays. eg " common a,b,c" could also be used for a subroutine call as and array a(3), to address b and c. I've done this one ! It can change the rank and size of arrays.

The aim is to minimise the changes to the original code.

Good luck,
John

[technophobe]

Thanks for your reply John - I really appreciate you taking the time to respond to my rather lengthy post.

Unfortunately I still haven't resolved the issue. The code I am changing has been very well written and the fault must lie with the additions that I have made. The original author has used IMPLICIT NONE everywhere so there are no problems with mis-typing variable names. The new variables have all been declared in a common block and explicitly assigned equal to zero.

I have run some test to try and locate my problem. The difficulty seems to be that I set variable A equal to an array element Array1(1) , at the moment there is only one element in the array and it is equal to zero. I then pass A to a subroutine. The subroutine uses A in some calculations but never reassigns it. It then outputs some results and writes A to a file for post-processing.

This all happens inside a loop which is repeated many times, other variables are involved elsewhere in the program but these are all operating as I would expect. At some stage, however, the value of Array1(1) gets reassigned to some non-zero value. Later in the loop it returns to zero again! There is only one assignment statement for Array1 in the entire program and this sets each element (1 at the moment) equal to zero.

I have checked this code with some work colleagues and no-one can work out what's going on! It simply doesn't make sense for the code to work this way. The author of the original code now works at another company so I'm going mad trying to work it out. If someone could shed some light on this I'd be very grateful.
Bren

[brucebowler]

[technophobe]

Thanks Bruce, you're right I should have included the variables in the subroutine call and the subroutine declaration. In the real code I have made sure that the subroutine and the calling program are both using the same variables list. In both cases the variables are local so they are declared at the start of each routine. I made sure of this by copy-pasting the variables.

Unfortunately I can't display the actual code because it will violate IPR regs at work. I'm sorry - I know that is a pain

[technophobe]

Hello again guys,

To try and resolve this issue I have removed the arrays entirely and am just using real variables. I still have the same problem although I am unsure why. It appears that a variable is being overwritten somewhere although I have checked every single assignment statement where the variable exists and it is only asigned once.

I now have variable A, set equal to zero early in the code. The simplified code looks like

[brucebowler]

How is "function" declared? Is it double precision? If not, it probably should be, and if so, there should probably be a

[Martin]

If a variable's value is changing but you can't see why I'd suggest it is a memory corruption error in some other part of the code, e.g. a buffer overflow.

I'd recommend compiling with checkmate and/or setting a write breakpoint on the variable being corrupted in SDBG - this will pause execution of the program when that variable is modified so you can see which statement is doing the damage.

[LitusSaxonicum]

In Fortran 77 style programming, you can pass variables between routines using the subprogram parameter lists OR through named COMMON blocks. If one method gives you grief - try the other. My advice is that if you are passing variables between routines via a parameter list and getting corruption, then an answer is to put the variables into an uniquely named COMMON block, mentioned in your ASUB and BSUB routines, and possibly nowhere else.

If the problem then goes away (relative to passing variables via the parameter list) then your bug is probably in the way you set up the variables to be passed. If it doesn't go away, then the values are being reassigned somewhere else.

Eddie

[technophobe]

Thanks for the replies guys, there's some very helpful information there.

I think I confused matters when I wrote

[technophobe]

Hi Guys,
I think I have finally fixed my problem. Unfortunately, I made two changes at the same time and am not sure which one to attribute the success to.

When I changed the code initially I added six new variables, these were added to the common file and I added them to some existing, named, common blocks. I didn't think that this would cause any problems as the program never refers to the common block by their names. I decided to change this and add a named common block with all the new variables.

Finally, I deleted the executable and recompiled everything - there are several dozen subroutines in seperate files and this was a last ditch attempt to see if it was a compiler error.

I think the former change is likely to have fixed things but can't completely rule out the second. I thoguht I should let you guys know in case someone comes across a similar problem someday.

Thanks very much for your help
Bren

[JohnCampbell]

I think both changes would have been required.

Modules were introduced, to replace include files, as they require a single declaration of the variable and not also the order in the common block. They are a much more robust method, especially when changing a program.
While common blocks have a useable feature of defining the variable order, you do have to be careful when using different variable lists for the same common block. A good coding rule for common is never put common declarations in the code, but always define them by a single include file. Unfortunately I break this rule many times, although I am migrating to modules. ( I am yet to try EQUIVALENCE for variables in a module, to replicate some of the things you could do with COMMON. They are probably better not being done ! )

With regard to obsolete .obj files, and especially .mod files, I have never mastered the use of the make utility, and instead still use my make.bat file, where the first two lines are :-
del *.obj
del *.mod

This approach has been a good way of guaranteeing that recent coding changes take effect, as I don't think the date stamp method of the make utility is sufficiently robust, especially when developing on multiple computers.

Similarly, It is my impression that if the .mod file is younger than the .f95 (or .for) file that defines it, then FTN95 does not replace it. If I copy a younger .mod file from another computer, which had an older version of the .f95 definition, this leads to many problems. It is safer to delete the files and recompile everything. There are few compiles that take too long these days.

John