Known issues caused by compiler bugs

From Geos-chem
Jump to: navigation, search

On this page we provide a list of known issues that are caused by bugs in the compiler used to build the GEOS-Chem executable file. We have resolved most of these issues, or at least have workarounds for them.

Please also see our Common GEOS-Chem error messages wiki page for a list of other commonly-encountered GEOS-Chem errors.

Intel Fortran Compiler

The following issues have been traced to bugs in the Intel Fortran Compiler (aka ifort).

First reported ifort
version
Module or routine Description Current Status
v10-01 17 (maybe 16 too) ncdf_mod.F90
hco_diagn_mod.F90
Not a compiler bug per se, but Intel Fortran v17 chokes when encountering subroutines (with OPTIONAL arguments) that are included in an INTERFACE block. This seems to be caused by a strict adherence to the Fortran 2003 or Fortran 2008 standard, unlike prior Intel compiler versions. NOTE: This same issue was also observed to occur when compiling GEOS-Chem with GNU Fortran. UPDATE REQUIRED.
v10-01 15.0.0
and newer
regrid_a2a_mod.F90 A segmentation fault error occurs when compiling GEOS-Chem with BOUNDS=yes DEBUG=no (which sets -check bounds -O2).

Bob Y. reported the issue to Intel Customer Service. They acknowledge that the issue occurs but have not issued a fix in ifort 15.

WORKAROUND.
  • GCST recommends always compiling with DEBUG=y BOUNDS=y if you want to check for array out-of-bounds errors.
v10-01 12
13.0.079
and newer
hcoio_dataread_mod.F90 Apparently a HEMCO pointer variable became disassociated without any good reason. WORKAROUND.
  • Seb Eastham recommends putting in a print statement (as described in the reference), which seems to alleviate the error.
  • This workaround will be added to v11-01g.
v10-01h 11.1.069
and newer
regrid_a2a_mod.F90 An optimization error was setting an array (that held the sines of latitude at the N and S edges of each grid box) to zeroes. This propagated to the MAP_A2A regridding routines, thus causing GEOS-Chem to exit abnormally.

It turned out that passing an array reference to the sine function
(e.g. SIN( YDGR(I,J,L) )) was the culprit.

RESOLVED.
  • Rewriting the call to the SIN() function (as described in the reference) fixed this error.
v9-01-03 12.1.3.293 strat_chem_mod.F90 GEOS-Chem nested-grid simulations exited with this error, which occurred in the stratospheric chemistry module:

catastrophic error: **Internal compiler error: segmentation violation signal raised

GCST discovered that an undefined variable (i.e. only used for global simulations but not nested-grid simulations) was being accessed within a parallel loop Ifort should have thrown a compile-time error, but didn't.

RESOLVED.
  • We rewrote an #ifdef block to prevent the undefined variable from appearing during nested-grid simulations.
  • This was issued as a v9-01-03 post-release patch on 05 Oct 2012.
v9-01-02 12.1.3.293
on Mac OSX
- The default compilation resulted in this error:

ld: library not found for -lcrt1.10.6.o

RESOLVED.
  • As described in the reference, a certain path has to be added to the LD_LIBRARY_PATH variable.
v8-02-03 11.0.074 partition.F GEOS-Chem would stop with an abnormal exit in partition.F. Also, the spatial pattern of species as computed by SMVGEAR (especially NOx) was totally wrong.

It turned out that the earlier builds of ifort 11 (i.e. prior to ifort 11.1.058) produced numerically-unstable code. Other non-GEOS-Chem users had reported this as well.

RESOLVED.
  • Moving to ifort 11.1.058 or higher solved the problem.
v8-02-03 adjoint 11.1.069 - An apparent linker error produced this error message:
OMP abort: Initializing libguide.so, but we but found libguide.so already initialized.
RESOLVED.
  • Updating the OS version seems to have fixed this error.

--Bob Yantosca (talk) 21:29, 20 January 2017 (UTC)

GNU Fortran Compiler

The following GEOS-Chem issues have been traced to bugs (or configuration oddities) in the GNU Fortran compiler:

First reported gfortran
version
Module or routine Description Current Status
v11-01 4.8.2 ncdf_mod.F90
hco_diagn_mod.F90
Not a compiler bug per se, the GNU Fortran compiler chokes when encountering subroutines (with OPTIONAL arguments) that are included in an INTERFACE block. This seems to be caused by a strict adherence to the Fortran 2003 or Fortran 2008 standard. NOTE: This same issue was also observed to occur when compiling GEOS-Chem with ifort 17. UPDATE REQUIRED.


v11-01 4.8.2 hcox_paranox_mod.F90 The ASIND function, which computes the inverse sine of an argument in degress, is not supported in Gfortran. RESOLVED.
  • We convert the argument from degrees to radians, then use the standard ASIN function.
v11-01 4.8.2 ucx_mod.F The SIND function, which computes the sine of an argument in degress, is not supported in Gfortran. RESOLVED.
  • We convert the argument from degrees to radians, then use the standard SIN function.
v11-01 4.8.2 isrpia.inc GNU Fortran v5 and higher does not allow you to place a COMMON block name in an !$OMP THREADPRIVATE statement. UNRESOLVED.
  • Use gfortran 4.4.7, or
  • Use gfortran 4.8.2
v11-01 4.8.2 - GNU Fortran 4.8 by default uses the DWARF-4 library. The Totalview debugger needs either DWARF-2 or DWARF-3. UNRESOLVED.
  • Use the gdb debugger, or
  • Use gfortran 4.4.7

--Bob Yantosca (talk) 21:52, 20 January 2017 (UTC)

Portland Group Fortran Compiler

The following GEOS-Chem issues have been traced to bugs (or configuration oddities) in the PGI Fortran compiler:

First reported pgfortran
version
Module or routine Description Current Status
v11-01f 14.10 file_mod.F
main.F
readchem.F
hco_error_mod.F90
GEOS-Chem log file outputs were not being flushed to disk during a simulation. Therefore, it was difficult to determine if a simulation was proceeding normally.

The GCST discovered that pgfortran turns off "file buffering" by default. In other words, if you want the logfile output to be continually flushed to disk while a program is running, you have to activate that manually. This can be done by making calls to the SETVBUF3F function.

RESOLVED.
v7-02-04? ?? charpak_mod.F Win Trivitayanurak reported that a circa 2005 version of the PGI compiler would apparently cause an error if you added a TRIM() statement inside another string function. For example, ADJUSTL( TRIM( STR ) ) generated a compile-time error. RESOLVED.
  • It appears that newer versions of the PGI compiler do not generate this error anymore.

--Bob Yantosca (talk) 19:22, 13 April 2016 (UTC)