What happened?

After adding a compiler configuration (cray_gnu_debug) to our MetOffice JEDI workflow system, the fckit_test_mpi test fails for this new config.

What are the steps to reproduce the bug?

Running with GNU 7.3.0 on the MO CRAY HPC.
Using the following flags:

        "CMAKE_CXX_FLAGS": {
          "type": "STRING",
          "value": "-g -Wuninitialized -fstack-check -fstack-protector-all"
        },
        "CMAKE_Fortran_FLAGS": {
          "type": "STRING",
          "value": "-g -fbacktrace -fcheck=all"
        }

Version

tags/0.10.0

Platform (OS and architecture)

CRAY/Linux

Relevant log output

12/14 Test  #5: fckit_test_mpi ...................***Failed   11.67 sec
 test_default_comm
 test_default_comm
 test_default_comm
 test_default_comm
At line 736 of file /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp
Fortran runtime error: Proc-pointer actual argument 'this' is not associated

Error termination. Backtrace:
At line 736 of file /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp
Fortran runtime error: Proc-pointer actual argument 'this' is not associated

Error termination. Backtrace:
At line 736 of file /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp
Fortran runtime error: Proc-pointer actual argument 'this' is not associated

Error termination. Backtrace:
At line 736 of file /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp
Fortran runtime error: Proc-pointer actual argument 'this' is not associated

Error termination. Backtrace:
#0  0x2b247a98182b in __fckit_mpi_module_MOD_fckit_mpi__size
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp:736
#0  0x2b330878e82b in __fckit_mpi_module_MOD_fckit_mpi__size
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp:736
#0  0x2b02229c082b in __fckit_mpi_module_MOD_fckit_mpi__size
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp:736
#0  0x2ae13fb9782b in __fckit_mpi_module_MOD_fckit_mpi__size
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/fckit/module/fckit_mpi.fypp:736
#1  0x4102f2 in __test_mpi_MOD_test_default_comm
	at /research/data/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/tests/test_mpi.F90:29
#2  0x41119d in run_test_mpi
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:20
#1  0x4102f2 in __test_mpi_MOD_test_default_comm
	at /research/data/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/tests/test_mpi.F90:29
#2  0x41119d in run_test_mpi
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:20
#1  0x4102f2 in __test_mpi_MOD_test_default_comm
	at /research/data/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/tests/test_mpi.F90:29
#2  0x41119d in run_test_mpi
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:20
#1  0x4102f2 in __test_mpi_MOD_test_default_comm
	at /research/data/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/mo-bundle/fckit/src/tests/test_mpi.F90:29
#2  0x41119d in run_test_mpi
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:20
#3  0x411255 in main
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:3
#3  0x411255 in main
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:3
#3  0x411255 in main
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:3
#3  0x411255 in main
	at /home/d01/kraykova/cylc-run/cray-gnu-debug-fckit-fiat/share/build-mo-cray_gnu_debug/fckit/src/tests/test_mpi_main.F90:3

Accompanying data

No response

Organisation

Met Office

When doing a build test of the UFO bundle on Apple Clang, several warnings were noted regarding 1) uninitialized memory use and 2) functions with names that shadow compiler intrinsics.

The log: fckit-log.txt

These should probably be passed upstream, but I am recording these here in case anyone stumbles across fckit-related issues.

Now that NVIDIA has taken over control of the PGI compiler suite, they are transitioning to a new naming scheme. For example, pgfortran and gcc are being replaced with nvfortran and nvc.

More to the point, the CMake compiler IDs have changed. For example, in order to compile fckit using the NVIDIA SDK 21.5 version of the compilers, I had to change this line from PGI to NVHPC:

Other occurrences of PGI in the CMake code do not seem to need special attention. Perhaps they have fixed some of the bugs.

Just something to be aware of.

Is your feature request related to a problem? Please describe.

At JCSDA, we are seeing that our partners developing the Unified Forecast System (NOAA; UFS), NEPTUNE (NAVY), and others are moving away from the MPI F90 implementation to the MPI F08 implementation. As far as I understand, fckit doesn't support that yet. Interfaces that convert the old MPI communicator used in fckit (an integer) to the new MPI communicator (type(MPI_comm)) need to be put in place.

Is there are plan to move away from the old MPI F90 implementation, or to support both in fckit?

Describe the solution you'd like

The MPI F08 implementation has many advantages, one being that it provides interfaces for all Fortran/MPI data types. This means one can compile MPI codes with gfortran-10+ without having to add -fallow-argument-mismatch, which can cover up real argument mismatches that one would like to detect.

Describe alternatives you've considered

No response

Additional context

No response

Organisation

JCSDA

With the introduction of the Fypp preprocessor, some functionality that was working before is no longer working. The problem has to with the MPI send command in fckit_mpi.fypp. We're getting compilation errors (with gfortran 7.3) when we try to send single integers or 1D integer arrays. They are of the type:

Error: Found no matching specific binding for the call to the GENERIC ‘send’ at (1)

Such send operations were working with the develop version from approximately Jan 17, 2019.

The CMake function fckit_target_preprocess_fypp automatically adds all definitions to fypp for preprocessing.
One issue reported by Ioan was encountered with the valid definition -D_POSIX_C_SOURCE=200809L:

error: exception at evaluating '200809L' in definition for '_POSIX_C_SOURCE' [FyppFatalError]
error: unexpected EOF while parsing (<string>, line 1) [SyntaxError]

Internal to fypp (in Python) there occurs a eval('200809L') which triggers a Python exception as follows:

>>> eval('200809L')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    200809L
          ^SyntaxError: invalid decimal 

and this causes the fypp preprocessing to fail.
To work around we introduce two mechanisms to remove this definition from being passed to the fypp preprocessor:

1. An extra argument FYPP_ARGS_EXCLUDE arg1 [arg2]... to the fckit_target_preprocess_fypp function
2. A general FCKIT_FYPP_ARGS_EXCLUDE list which can be added to e.g. a toolchain or CMake command-line.

The arguments or list elements described can be regular expressions as understood by bash and shall not contain a comma.
By default we already add the regex -D[[:space:]]?.*=([0-9])+L which captures the -D_POSIX_C_SOURCE=200809L argument reported in this issue.

Using cmake 3.11.2, running with these options:

-DCMAKE_CXX_COMPILER="$HOME/installs/gcc/7.1.0/v1/bin/g++"
-DCMAKE_CXX_FLAGS="-g"
-DCMAKE_EXE_LINKER_FLAGS="-Wl,-rpath=$HOME/installs/gcc/7.1.0/v1/lib"
-DCMAKE_Fortran_COMPILER="$HOME/installs/gcc/7.1.0/v1/bin/gfortran"
-DCMAKE_Fortran_FLAGS="-fbacktrace -g"
-DCMAKE_INSTALL_PREFIX=$HOME/installs/oops-stuff/fckit
-DCMAKE_MODULE_PATH=$HOME/installs/oops-stuff/ecbuild/share/ecbuild/cmake
-DECKIT_PATH=$HOME/installs/oops-stuff/eckit

gets this in the output:

-- Looking for sys/types.h
CMake Error at /home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckIncludeFile.cmake:58 (try_compile):
Unknown extension ".c" for file

/home/david/src/oops-stuff/fckit/fckit-build/CMakeFiles/CMakeTmp/CheckIncludeFile.c

try_compile() works only for enabled languages. Currently these are:

CXX Fortran

See project() command to enable other languages.
Call Stack (most recent call first):
/home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckTypeSize.cmake:225 (check_include_file)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_check_os.cmake:13 (check_type_size)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_system.cmake:236 (include)
CMakeLists.txt:22 (include)

-- Looking for sys/types.h - not found
-- Looking for stdint.h
CMake Error at /home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckIncludeFile.cmake:58 (try_compile):
Unknown extension ".c" for file

/home/david/src/oops-stuff/fckit/fckit-build/CMakeFiles/CMakeTmp/CheckIncludeFile.c

try_compile() works only for enabled languages. Currently these are:

CXX Fortran

See project() command to enable other languages.
Call Stack (most recent call first):
/home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckTypeSize.cmake:226 (check_include_file)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_check_os.cmake:13 (check_type_size)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_system.cmake:236 (include)
CMakeLists.txt:22 (include)

-- Looking for stdint.h - not found
-- Looking for stddef.h
CMake Error at /home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckIncludeFile.cmake:58 (try_compile):
Unknown extension ".c" for file

/home/david/src/oops-stuff/fckit/fckit-build/CMakeFiles/CMakeTmp/CheckIncludeFile.c

try_compile() works only for enabled languages. Currently these are:

CXX Fortran

See project() command to enable other languages.
Call Stack (most recent call first):
/home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckTypeSize.cmake:227 (check_include_file)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_check_os.cmake:13 (check_type_size)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_system.cmake:236 (include)
CMakeLists.txt:22 (include)

-- Looking for stddef.h - not found
-- Check size of void*
CMake Error at /home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckTypeSize.cmake:116 (try_compile):
Unknown extension ".c" for file

/home/david/src/oops-stuff/fckit/fckit-build/CMakeFiles/CheckTypeSize/CMAKE_SIZEOF_VOID_P.c

try_compile() works only for enabled languages. Currently these are:

CXX Fortran

See project() command to enable other languages.
Call Stack (most recent call first):
/home/david/installs/oops-stuff/cmake/share/cmake-3.11/Modules/CheckTypeSize.cmake:241 (__check_type_size_impl)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_check_os.cmake:13 (check_type_size)
/home/david/installs/oops-stuff/ecbuild/share/ecbuild/cmake/ecbuild_system.cmake:236 (include)
CMakeLists.txt:22 (include)

and the cmake command carries on but ultimately fails.

Hi,

I use fckit within a fortran code: bump-standalone. I noticed lately (while investigating another bug I have with bump) that the variables f_comm%size and f_comm%rank are always equal to 1 and 0 respectively while in this configuration f_comm%size should be equal to 6 and f_comm%rank should range from 0 to 5. I have no idea where the problem is coming from, can you provide some help ?

What happened?

fckit doesn't currently compile with NAG.

There are several issues, I have a PR with some of the simpler fixes.

What are the steps to reproduce the bug?

Trying to build with NAG

Version

develop

Platform (OS and architecture)

Linux

Relevant log output

No response

Accompanying data

No response

Organisation

Met Office

What happened?

Building fckit with Portland 18.7 results in static libraries; I would like shared libraries.

I tried modifying the check in src/fckit/CMakeLists.txt to 18.7 and shared libraries were build just fine.

What are the steps to reproduce the bug?

Build fckit with pgfortran 18.7

Version

head of develop

Platform (OS and architecture)

Linux

Relevant log output

No response

Accompanying data

No response

Organisation

No response

fckit-fypp.py was failing for me on some files with tracebacks like this:

Traceback (most recent call last):
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 3004, in
run_fypp()
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 2838, in run_fypp
tool.process_file(infile, outfile)
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 2514, in process_file
output = self._preprocessor.process_file(infile)
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 2393, in process_file
self._parser.parsefile(fname)
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 253, in parsefile
self._includefile(None, inpfp, fobj, os.path.dirname(fobj))
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 267, in _includefile
self._parse_txt(span, fname, fobj.read())
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 580, in _parse_txt
self._parse(txt)
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 616, in _parse
self._process_control_dir(content, span)
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 679, in _process_control_dir
self._process_include(param, span)
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 829, in _process_include
self._includefile(span, inpfp, fpath, os.path.dirname(fpath))
File "/home/h01/frwd/cylc-run/UnicodeFailure/share/lfric-bundle/fckit/tools/fckit-fypp.py", line 267, in _includefile
self._parse_txt(span, fname, fobj.read())
File "/net/project/ukmo/scitools/opt_scitools/environments/default/2019_02_27/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 242: ordinal not in range(128)

This can be fixed by setting environment variables

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

However it would be nice if this would work without having to set environment variables; one possibility for achieving that might be to add 'encoding="utf-8"' to the open arguments on lines 2862 and 2881. What do you think?

I believe I found a bug in the build system that manifests itself only when using a compiler toolchain (e.g. a newer libstdc++ with the Intel compilers) for certain tests that include both Fortran and C++ code. For example in src/tests/CMakeLists.txt:

add_fctest( TARGET  fckit_test_shared_ptr
            LINKER_LANGUAGE Fortran
            SOURCES
              test_shared_ptr.F90
              test_shared_ptr.cc
            LIBS    fckit)

When using a compiler toolchain on systems where the default gcc is too old, e.g. when adding -gxx-name=/path/to/a/newer/gcc/bin/g++, I get errors of undefined symbols from a newer GLIBCXX standard. That's because test_shared_ptr.cc is compiled with the toolchain, but the Fortran linker doesn't know about it.

An easy workaround when just building fckit is to set the cmake linker flags as follows:

-gxx-name=/path/to/a/newer/gcc/bin/g++ -Wl,-rpath,/path/to/a/newer/gcc/lib64 -lstdc++

However, one can't do this when building fckit as part of a software stack using a package manager like spack. And it is only putting duct tape over the problem. I think the correct solution is to explicitly link against libstdc++ for those tests that use LINKER_LANGUAGE Fortran and C++ sources:

diff --git a/src/tests/CMakeLists.txt b/src/tests/CMakeLists.txt
index 248ac67..150d574 100644
--- a/src/tests/CMakeLists.txt
+++ b/src/tests/CMakeLists.txt
@@ -31,7 +31,7 @@ add_fctest( TARGET  fckit_test_shared_ptr
             SOURCES
               test_shared_ptr.F90
               test_shared_ptr.cc
-            LIBS    fckit)
+            LIBS    fckit stdc++)

 add_fctest( TARGET  fckit_test_mpi
             LINKER_LANGUAGE Fortran
@@ -88,7 +88,7 @@ ecbuild_add_test( TARGET  fckit_test_configuration_cpp
             test_configuration_fortcode.F90
             INCLUDES ${ECKIT_INCLUDE_DIRS}
             CONDITION HAVE_ECKIT
-            LIBS    fckit  eckit eckit_mpi )
+            LIBS    fckit  eckit eckit_mpi stdc++)

 if( TEST fckit_test_configuration_cpp )
   set_property( TEST fckit_test_configuration_cpp APPEND PROPERTY LABELS "fortran" )
@@ -100,7 +100,7 @@ ecbuild_add_test( TARGET fckit_test_cpp
   INCLUDES ${ECKIT_INCLUDE_DIRS}
   ENVIRONMENT "DEBUG=1"
   CONDITION HAVE_ECKIT
-  LIBS fckit eckit eckit_mpi )
+  LIBS fckit eckit eckit_mpi stdc++)

 ### Fix linking for C++ test executables linked with Fortran linker
 if( CMAKE_Fortran_COMPILER_ID MATCHES "PGI|NVHPC" )

I'm getting an odd recursion when running make install for fckit. The module directory keeps getting written to a subfolder of itself, so I get a tree of

{fckitdir}/build/module/fckit/./fckit/fckit/.../fckit/*.mod

of the same modules over and over. An fckit binary is generated, though I haven't tested to see if it works correctly. Any ideas what this could be? Are there any steps of the build process that come after this?
cmake.log
ecbuild.log
install.txt
make.log

[not related to #7 - from @danholdaway]

Line 1106 of fckit_mpi.py is commented out and this seems to be causing an issue with reusing comms. The following pseudo code does not work for me:

type(fckit_mpi_comm) :: f_comm_new

call mpi_comm_split(f_comm%communicator(), geom%ntile, f_comm%rank(), commnew, ierr)
f_comm_new = fckit_mpi_comm(commnew)

call f_comm_new%delete()
call MPI_Comm_free(commtile, ierr)

call mpi_comm_split(f_comm%communicator(), geom%ntile, f_comm%rank(), commnew, ierr)
f_comm_new = fckit_mpi_comm(commnew)
print*, f_comm_new%rank()

This is because the second f_comm_new = fckit_mpi_comm(commnew) does not return a valid pointer. My guess is this because nothing really happens in %delete so the second fckit_mpi_comm(commnew) call does not set a pointer to the comm created in the second mpi_comm_split since it thinks it already exists but call MPI_Comm_free(commtile, ierr) removed the place it needs to point to. Interestingly only GCC compilers pick up on this issue.

If I uncomment line 1106 then I get an immediate seg fault in applications

What maintenance does this project need?

There is no documentation detailing the installation process for fckit.

Please add documentation detailing the installation process.

Organisation

No response

ecbuild is failing to detect python for me:

CMake Error at /research/data/d03/frwd/installs/cmake/3.19.4/v1/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:218 (message): Could NOT find PythonInterp: Found unsuitable version "2.7.9", but required is at least "3.4" (found /opt/python/gnu/2.7.9/bin/python) Call Stack (most recent call first): /research/data/d03/frwd/installs/cmake/3.19.4/v1/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:580 (_FPHSA_FAILURE_MESSAGE) /research/data/d03/frwd/installs/cmake/3.19.4/v1/share/cmake-3.19/Modules/FindPythonInterp.cmake:169 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) /research/data/d03/frwd/installs/ecbuild/3.6.1-v1/share/ecbuild/cmake/ecbuild_find_python.cmake:94 (find_package) fckit/CMakeLists.txt:25 (ecbuild_find_python)

The system python is python 2 so I have installed python 3 in a custom location. However I don't know how to make fckit pick it up. I have set $PATH to pick up my custom python executable but that doesn't seem to be sufficient.

What happened?

We are seeing problems with the latest Intel classic compilers ([email protected], [email protected]; part of Intel's [email protected]) on a new machine called Hercules (Mississippi State University / NOAA; Rocky Linux release 9.1 (Blue Onyx)).

Here is an example traceback for one of our ctests fv3jedi_test_tier1_hyb-fgat_fv3lm (cont'd below).

1465: Info     : --- Configuration parameters
1465: Info     :        General:{"color log":false,"testing":false,"default seed":true,"reproducibility operators":true,"reproducibility threshold":9.9999999999999998e-13,"universe length-scale":20015806.220738243,"sampling method":"potential"}
1465: Info     :        I/O:{"data directory":".","files prefix":"Data/bump/fv3jedi_bumpparameters_nicas_geos","new files":true,"parallel netcdf":true,"io tasks":20,"alias":[{"in code":"eastward_wind","in file":"fixed_2500km_0.3"},{"in code":"northward_wind","in file":"fixed_25
00km_0.3"},{"in code":"air_temperature","in file":"fixed_2500km_0.3"},{"in code":"specific_humidity","in file":"fixed_2500km_0.3"},{"in code":"cloud_liquid_ice","in file":"fixed_2500km_0.3"},{"in code":"cloud_liquid_water","in file":"fixed_2500km_0.3"},{"in code":"mole_fraction
_of_ozone_in_air","in file":"fixed_2500km_0.3"},{"in code":"surface_pressure","in file":"fixed_2500km"}],"overriding sampling file":"","overriding vertical covariance file":[],"overriding vertical balance file":"","overriding moments file":[],"overriding lowres moments file":[]
,"overriding universe radius file":"","overriding nicas file":"","overriding psichitouv file":"","gsi data file":"","gsi namelist":""}
1465: Info     :        Drivers:{"compute covariance":false,"compute lowres covariance":false,"compute correlation":false,"compute lowres correlation":false,"compute localization":false,"compute lowres localization":false,"compute hybrid weights":false,"hybrid source":"","multi
variate strategy":"univariate","compute normality":false,"read local sampling":false,"read global sampling":false,"write local sampling":false,"write global sampling":false,"write sampling grids":false,"compute vertical covariance":false,"read vertical covariance":false,"write
vertical covariance":false,"compute vertical balance":false,"read vertical balance":false,"write vertical balance":false,"compute variance":false,"compute moments":false,"read moments":false,"write moments":false,"write diagnostics":false,"write diagnostics detail":false,"read
universe radius":false,"write universe radius":false,"compute nicas":false,"read local nicas":true,"read global nicas":false,"write local nicas":false,"write global nicas":false,"write nicas grids":false,"write nicas steps":false,"compute psichitouv":false,"read local psichitou
v":false,"write local psichitouv":false,"vertical balance inverse test":false,"adjoints test":false,"normalization test":0,"internal dirac test":false,"randomization test":false,"internal consistency test":false,"localization optimality test":false,"interpolate from gsi data":f
alse}
1465: Info     :        Model:{"variables":["eastward_wind","northward_wind","air_temperature","specific_humidity","cloud_liquid_ice","cloud_liquid_water","mole_fraction_of_ozone_in_air"],"2d variables":[],"do not cross mask boundaries":false,"level for 2d variables":"first","n
l0":72,"lev2d":"first"}
1465: Info     :        Ensemble sizes:{"total ensemble size":0,"sub-ensembles":1,"total lowres ensemble size":0,"lowres sub-ensembles":1}
1465: Info     :        Sampling:{"computation grid size":0,"diagnostic grid size":0,"distance classes":0,"angular sectors":1,"distance class width":0,"reduced levels":0,"local diagnostic":false,"averaging length-scale":0,"averaging latitude width":0,"grid type":"random","max n
umber of draws":10000,"interpolation type":"si","masks":[],"contiguous levels threshold":0}
1465: Info     :        diagnostics:[hercules-login-2:1617504:0:1617504] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
1465: {"target ensemble size":0,"target lowres ensemble size":0,"gaussian approximation":false,"generalized kurtosis threshold":1.7976931348623157e+308,"histogram bins":0,"diagnosed lengths scaling":1}
1465: Info     :        Vertical balance:{"vbal":[],"pseudo inverse":false,"dominant mode":0,"variance threshold":0,"identity blocks":false}
1465: [hercules-login-2:1617503:0:1617503] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
1465: [hercules-login-2:1617507:0:1617507] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
1465: [hercules-login-2:1617508:0:1617508] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
1465: [hercules-login-2:1617506:0:1617506] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
1465: [hercules-login-2:1617505:0:1617505] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
1465: ==== backtrace (tid:1617503) ====
1465:  0 0x0000000000054d90 __GI___sigaction()  :0
1465:  1 0x0000000000038027 fckit_shared_ptr_module_mp_owners_()  /work/noaa/epic/role-epic/spack-stack/hercules/spack-stack-dev-20230717/cache/build_stage/spack-stage-fckit-0.10.1-vnk44k7j7qo22dgxy7smdoiud35jk23z/spack-src/src/fckit/module/fckit_shared_ptr.F90:263
1465:  2 0x0000000000037c8d fckit_shared_ptr_module_mp_fckit_shared_ptr__final_auto_()  /work/noaa/epic/role-epic/spack-stack/hercules/spack-stack-dev-20230717/cache/build_stage/spack-stage-fckit-0.10.1-vnk44k7j7qo22dgxy7smdoiud35jk23z/spack-src/src/fckit/module/fckit_shared_ptr.F90:138
1465:  3 0x000000000047a40f for_finalize()  ???:0
1465:  4 0x000000000047a5e6 for_finalize()  ???:0
1465:  5 0x000000000047a5e6 for_finalize()  ???:0
1465:  6 0x000000000003e299 fckit_configuration_module_mp_deallocate_fckit_configuration_()  /work/noaa/epic/role-epic/spack-stack/hercules/spack-stack-dev-20230717/cache/build_stage/spack-stage-fckit-0.10.1-vnk44k7j7qo22dgxy7smdoiud35jk23z/spack-src/src/fckit/module/fckit_configuration.F90:340
1465:  7 0x000000000003d998 fckit_configuration_module_mp_get_config_list_()  /work/noaa/epic/role-epic/spack-stack/hercules/spack-stack-dev-20230717/cache/build_stage/spack-stage-fckit-0.10.1-vnk44k7j7qo22dgxy7smdoiud35jk23z/spack-src/src/fckit/module/fckit_configuration.F90:599
1465:  8 0x0000000000d0cf53 type_nam_mp_nam_from_conf_()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/build-release/saber/src/saber/bump/lib//work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/bump/lib/type_nam.fypp:640
1465:  9 0x0000000000b1cb3c type_bump_mp_bump_create_()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/build-release/saber/src/saber/bump/lib//work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/bump/lib/type_bump.fypp:129
1465: 10 0x0000000000755ae5 bump_create_f90()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/bump/lib/type_bump_interface.F90:76
1465: 11 0x000000000074777b bump_lib::BUMP::BUMP()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/bump/lib/BUMP.cc:180
1465: 12 0x00000000007c1fe5 saber::bump::NICAS::NICAS()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/bump/NICAS.cc:68
1465: 13 0x000000000089e800 std::make_unique<saber::bump::NICAS, oops::GeometryData const&, oops::Variables const&, eckit::Configuration const&, saber::bump::NICASParameters const&, atlas::FieldSet const&, atlas::FieldSet const&, util::DateTime const&, unsigned long const&>()  /usr/include/c++/11/bits/unique_ptr.h:962
1465: 14 0x000000000089e800 saber::SaberCentralBlockMaker<saber::bump::NICAS>::make()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/../saber/oops/SaberCentralBlockBase.h:197
1465: 15 0x000000000094de6f saber::SaberCentralBlockFactory::create()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/oops/SaberCentralBlockBase.cc:68
1465: 16 0x000000000094d154 saber::SaberBlockChain::centralBlockInit()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/oops/SaberBlockChain.cc:37
1465: 17 0x00000000006e7da4 saber::buildCentralBlock<fv3jedi::Traits>()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/../saber/oops/Utilities.h:699
1465: 18 0x00000000006f5140 saber::ErrorCovariance<fv3jedi::Traits>::ErrorCovariance()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/saber/src/saber/../saber/oops/ErrorCovariance.h:299
1465: 19 0x00000000006fcf4d oops::CovarMaker<fv3jedi::Traits, saber::ErrorCovariance<fv3jedi::Traits> >::make()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/ModelSpaceCovarianceBase.h:233
1465: 20 0x0000000000586131 oops::CovarianceFactory<fv3jedi::Traits>::create()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/ModelSpaceCovarianceBase.h:281
1465: 21 0x0000000000585e24 oops::CovarianceFactory<fv3jedi::Traits>::create()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/ModelSpaceCovarianceBase.h:295
1465: 22 0x00000000005855f3 oops::HybridCovariance<fv3jedi::Traits>::HybridCovariance()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/HybridCovariance.h:77
1465: 23 0x00000000005855f3 std::__uniq_ptr_data<oops::ModelSpaceCovarianceBase<fv3jedi::Traits>, std::default_delete<oops::ModelSpaceCovarianceBase<fv3jedi::Traits> >, true, true>::__uniq_ptr_impl()  /usr/include/c++/11/bits/unique_ptr.h:210
1465: 24 0x00000000005855f3 std::unique_ptr<oops::ModelSpaceCovarianceBase<fv3jedi::Traits>, std::default_delete<oops::ModelSpaceCovarianceBase<fv3jedi::Traits> > >::unique_ptr<std::default_delete<oops::ModelSpaceCovarianceBase<fv3jedi::Traits> >, void>()  /usr/include/c++/11/bits/unique_ptr.h:281
1465: 25 0x00000000005855f3 oops::HybridCovariance<fv3jedi::Traits>::HybridCovariance()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/HybridCovariance.h:77
1465: 26 0x0000000000585364 oops::CovarMaker<fv3jedi::Traits, oops::HybridCovariance<fv3jedi::Traits> >::make()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/ModelSpaceCovarianceBase.h:233
1465: 27 0x0000000000586131 oops::CovarianceFactory<fv3jedi::Traits>::create()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/ModelSpaceCovarianceBase.h:281
1465: 28 0x0000000000585e24 oops::CovarianceFactory<fv3jedi::Traits>::create()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/base/ModelSpaceCovarianceBase.h:295
1465: 29 0x0000000000591a0e oops::CostJb3D<fv3jedi::Traits>::linearize()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/assimilation/CostJb3D.h:126
1465: 30 0x0000000000560b8d oops::CostJbTotal<fv3jedi::Traits, ufo::ObsTraits>::computeCostTraj()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/assimilation/CostJbTotal.h:233
1465: 31 0x000000000055c6a3 oops::CostFunction<fv3jedi::Traits, ufo::ObsTraits>::evaluate()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/assimilation/CostFunction.h:258
1465: 32 0x000000000055c6a3 oops::CostFunction<fv3jedi::Traits, ufo::ObsTraits>::evaluate()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/assimilation/CostFunction.h:259
1465: 33 0x0000000000557289 oops::IncrementalAssimilation<fv3jedi::Traits, ufo::ObsTraits>()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/assimilation/IncrementalAssimilation.h:67
1465: 34 0x0000000000557289 oops::IncrementalAssimilation<fv3jedi::Traits, ufo::ObsTraits>()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/assimilation/IncrementalAssimilation.h:67
1465: 35 0x0000000000555887 oops::Variational<fv3jedi::Traits, ufo::ObsTraits>::execute()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/runs/Variational.h:79
1465: 36 0x00000000000fa31d oops::Run::execute()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/oops/src/oops/runs/Run.cc:182
1465: 37 0x00000000004acc71 main()  /work2/noaa/da/dheinzel-new/skylab-test-20230717-hercules/jedi-bundle/fv3-jedi/src/mains/fv3jediVar.cc:25
1465: 38 0x000000000003feb0 __libc_start_call_main()  ???:0
1465: 39 0x000000000003ff60 __libc_start_main_alias_2()  :0
1465: 40 0x00000000004acb05 _start()  ???:0

The automatic detection of HAVE_FINAL in fckit's cmake config enables the feature. If I turn off the FINAL feature manually in the cmake build, the above errors are gone.

As part of my investigation I spent a bit of time cruising around in the fckit code and cmake files and I found several places that hint to problems with the FINAL feature in fckit itself. For example, there are build flags like FCKIT_FINAL_BROKEN_FOR_ALLOCATABLE_ARRAY and FCKIT_FINAL_BROKEN_FOR_AUTOMATIC_ARRAY that simply turn off related tests etc.

I am not entirely sure what the reasoning behind relying on auto-detecting the FINAL feature by default is, but from all that I've seen and not knowing what you know, I would expect the default for HAVE_FINAL to be OFF, and any user setting it to ON should be greeted with big bold warnings?

What are the steps to reproduce the bug?

The only system on which I currently have access to this particular version of oneAPI is MSU Hercules, therefore I cannot say if it is just the compiler or a combination of the compiler PLUS the machine. A slightly earlier version of Intel (2021.8.0, part of [email protected]) did not have this problem with the finalization of the shared pointers (but had other problems that were indeed bugs in the compiler that forced us to move on to the latest version).

Version

0.10.1

Platform (OS and architecture)

Linux hercules-login-4.hpc.msstate.edu 5.14.0-162.12.1.el9_1.0.2.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 30 22:14:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux / Rocky Linux release 9.1 (Blue Onyx)

Relevant log output

see above

Accompanying data

n/a

Organisation

JCSDA

I suggest adding topics such as interoperability, fortran, cplusplus in the About section at https://github.com/ecmwf/fckit.

This is strongly related to ecmwf/ecbuild#1. It is actually the same issue but occurring in check_final_support instead of ecbuild_check_fortran. Again a workaround is to set -rpath in CMAKE_Fortran_FLAGS as that seems to propagate, but surely CMAKE_EXE_LINKER_FLAGS should propagate as well?

I am getting transient timeout failures in fckit_test_configuration_fails on some platforms. Increasing the timeout to, say, 100 seems to work in that the failures go away. There is a big variation in runtime within those limits though.

Can the timeout be increased for this test? Or can the timeout be removed altogether?

I am getting this compile failure:

[ 1%] Building Fortran object src/fckit/CMakeFiles/fckit.dir/fctest.F90.o
cd /home/david/src/oops-stuff/fckit/fckit-build/src/fckit && /home/david/installs/gcc/7.1.0/v1/bin/gfortran -Dfckit_EXPORTS -I/home/david/src/oops-stuff/fckit/fckit-build/module -I/home/david/src/oops-stuff/fckit/src -I/home/david/src/oops-stuff/fckit/fckit-build/src -I/home/david/src/oops-stuff/fckit/fckit-build/src/fckit -I/home/david/installs/oops-stuff/eckit/include -I/usr/include -I/home/david/installs/oops-stuff/eigen/include/eigen3 -I/home/david/installs/oops-stuff/mpich/include -fbacktrace -g -O3 -funroll-all-loops -finline-functions -J../../module -fPIC -c /home/david/src/oops-stuff/fckit/src/fckit/fctest.F90 -o CMakeFiles/fckit.dir/fctest.F90.o
/home/david/src/oops-stuff/fckit/src/fckit/fctest.F90:111:38:

subroutine fctest_check_equal_int32_r1(V1,V2,line)
1
/home/david/src/oops-stuff/fckit/src/fckit/fctest.F90:131:38:

subroutine fctest_check_equal_int64_r1(V1,V2,line)
2
Error: Ambiguous interfaces in generic interface 'fce' for ‘fctest_check_equal_int32_r1’ at (1) and ‘fctest_check_equal_int64_r1’ at (2)
make[2]: *** [src/fckit/CMakeFiles/fckit.dir/fctest.F90.o] Error 1

david@david-System-Product-Name ~/src/oops-stuff $ $HOME/installs/gcc/7.1.0/v1/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/home/david/installs/gcc/7.1.0/v1/bin/gfortran
COLLECT_LTO_WRAPPER=/home/david/installs/gcc/7.1.0/v1/libexec/gcc/i686-pc-linux-gnu/7.1.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /home/david/src/downloads/gcc-7.1.0/configure --prefix=/home/david/installs/gcc/7.1.0/v1 --enable-languages=all
Thread model: posix
gcc version 7.1.0 (GCC)

david@david-System-Product-Name ~/src/oops-stuff $ uname -a
Linux david-System-Product-Name 3.13.0-149-generic #199-Ubuntu SMP Thu May 17 10:12:57 UTC 2018 i686 athlon i686 GNU/Linux

I think this is because the generic interface FCE contains an "int32" version and an "int64" version where the int32 version declares the arguments as c_int and the int64 version declares the argument as c_long. However c_int and c_long are the same on this platform.

This crops up in quite a few places in fckit, the particular failure above is the first of many I think.