Known issues caused by compiler bugs

From Geos-chem
Revision as of 14:47, 20 September 2022 by Bmy (Talk | contribs) (→‎Portland Group Fortran Compiler)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Previous | Next | Guide to compilers for GEOS-Chem

  1. Supported compilers for GEOS-Chem
  2. The GNU Fortran compiler (aka gfortran)
  3. The Intel Fortran compiler (aka ifort)
  4. Known issues caused by compiler bugs
  5. Fortran language resources


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.

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. RESOLVED.
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. RESOLVED.
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)

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
12.8.1 2019.0.3.199 Somewhere in KPP? Causes an apparent optimization error in tropchem simulations, where OH and O3 go to zero. UPDATE REQUIRED.
  • Avoid using ifort 2019.0.3.199.
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)

Retrieved from "https://wiki.seas.harvard.edu/geos-chem/index.php?title=Known_issues_caused_by_compiler_bugs&oldid=51607"