gfortran test failures

[Huw Lewis]

At ROPP-4, tests MT-IO-OP (thin 621 operational profiles), IT-FM-05 (2d operator applied to 500 profiles), IT-PP-03 (25 CHAMP occ processing) and IT-PP-04 (25 COSMIC occ processing) fail for the gfortran compiler with memory fault issues.

This is a compiler-specific problem, generally with handling a large number of successive profiles, and not critical for ROPP release. However, a fix should be investigated if possible.

[Huw Lewis]

Helpdesk enquiry ID 43 resulted in some investigation of the problem with running ropp_pp_occ_tool with gfortran. A number of small updates were made to improve memory allocation/deallocation. See [2444].

In particular:

ropp_io/ropp/ropp_io_shrink.f90 (improved checks for imin and imax within range)

ropp_pp/common/ropp_pp_sliding_polynomial.f90 (simplified routine avoiding unnecessary pointers and allocating/deallocating local arrays - this change alone enables 'make test' with ropp_pp_occ_tool to run successfully)

ropp_pp/preprocess/ropp_pp_cutoff.f90 (only attempt to shrink elements Lev1a and Lev1b from ROprof, since either Lev2a+ missing or with fewer data points than imin:imax).

Further testing and developments to be made ahead of v4.1.

[Ian Culverwell]

Painstaking investigations got nowhere with this. Eg, between leaving a called subroutine and returning to the calling routine (as evidenced by PRINT* statements), the model crashes with

* glibc detected * free(): invalid next size (normal): 0x08f91ef0 *

Setting MALLOC_CHECK_=1 didn't help.

All this is with

gfortran --version: GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258]

which is now quite old. We (at Met Office) should have access to a more recent version when RHEL-6 is installed.

Recommendation: Cut our losses with this version of gfortran. Return when we have a later one.

[Ian Culverwell]

Chris Burrows has found the root of many of the gfortran problems to be array bounds errors. By replacing

IF (A .AND. B) THEN

ENDIF

constructs with

IF (A) THEN

IF (B) THEN

ENDIF

ENDIF

contructs, he finds we can avoid many of the problems encountered by gfortran when B is improperly dimensioned. (Most of these are in ropp_pp.)

Similarly, hardwiring

newval(:) = val(1:nlev)

rather than

newval(:) = val(:)

in ropp_io_thin, helps when val is improperly dimensioned.

Changes like these mean that ROPP now passes (and fails) the same tests with gfortran as it does with the other compilers.

Transferring ownership to Chris in case he wants to comment further before closing the ticket.

[cburrows]

These runtime errors are dependent on the size of arrays read in (notably, issues are caused when reading in multifiles). More instances may exist, but hopefully the test folder has been rigorous enough to catch most cases.

Closing ticket.

[Ian Culverwell]

Reopening ticket, as ROPP6.0 beta testing shows that problems remain with gfortran 4.5.x (which we don't yet have).

Move milestone to ROPP7.0 (with DRI's permission) and return to ticket when we have access to this compiler. (Our latest version is 4.4.5.)

[Dave Offiler]

RHEL6 gfortran was only a minor update to v4.4.6. The current gcc/gfortran is v4.7.1. Installing the (then) latest gfortran under RHEL4 (as sa_app) proved impossible due to out-of-date dependencies, but perhaps this should be re-attempted?

[cburrows]

This compiler is still not available at the Met Office. Changing milestone to whenever, i.e. action will be taken if this compiler becomes available.