Runtime error with TOUGH2-MP (Allocatable variable BCELEM)

After some time I tried to replicate the error I described above. I did not manage to. Maybe they changed something on our cluster. I don't know. So I can't give a solution to this problem.

Thanks for the help anyways.

Holger

After testing different compiler flags last week, I found a solution to my previous post. I also want to present some results that could be useful for both, users and developers. It appears to me that the present code version needs some fixes regarding the occurrence of uninitialized values. It also should be made more robust against the compiler options that are used.

Here are my findings:

EOS7 and EOS7R with Intel compiler (12.0-64, Linux)

The runtime error mentioned in my previous post (Attempt to fetch from allocatable variable BCELEM when it is not allocated) occurs for both, EOS7 and EOS7R, if the flag 

-check all

is set. With one of the following flags TOUGH2-MP it runs without error:

ifort -O0 -fpp -r8 -i4 -g -traceback

ifort -O0 -fpp -r8 -i4

ifort -O0 -r8 -i4

EOS7R with GCC (gfortran) compiler (4.3.6, Linux)

Segmentation fault independent of the compiler flags I'm using

gfortran -O0 -fdefault-real-8 -i4

gfortran -O0 -fdefault-real-8 -i4 -g -fbacktrace

gfortran -O0 -fdefault-real-8 -i4 -g -fbacktrace -Wall

The segmentation fault disappears if the following compiler option is set:

-fno-automatic

EOS7 with GCC (gfortran) compiler (4.3.6, Linux)

NaN in the TOUGH output after second timestep:

    36   (    1, 1) ST = 0.100000E-08 DT = 0.100000E-08 DX1= 0.000000E+00 DX2= 0.000000E+00 T =  25.000 P =   100000. S = 0.100000E+01

     1   (    2, 3) ST = 0.200000E+01 DT = 0.200000E+01 DX1=          NaN DX2=          NaN T =     NaN P =       NaN S = 0.100000E-05

The NaN errors disappear if one or two of the following compiler options are set:

-fno-automatic

-finit-local-zero

Discussion

Using the gfortran –Wall option I noticed some “unitialized value” warnings. Since EOS7 was executed without error using the Intel compiler this brought up the idea that the two compilers might treat uninitialized values differently (by setting them 0 or NaN).

Solutions were found using the options -fno-automatic and -finit-local-zero. The compiler option -fno-automatic treats each program unit as if the SAVE statement were specified for every local variable and array referenced in it. Consequently, the previously unitialized values remain initialized. The same is true for the compiler option -finit-local-zero, which instructs the compiler to initialize local INTEGER, REAL, and COMPLEX variables to zero.

Using these compiler options, it seems that I get the correct TOUGH behavior with correct calculation results. However, which of both initialization methods (SAVE or =0) is correct cannot be answered from a user perspective. I therefore suggest that the code is revised in order to get a well defined model state independent from the compiler options that are used.

It also should be clarified why the Intel compiler produces a runtime error in debug mode.

I also send an email to Noel Keen with these results.

Holger