Recently introduced CRTM cmake build breaks ufs-bundle

[climbfuji]

Description

The recently introduced cmake build for crtm breaks ufs-bundle:

CMake Error at fv3-jedi/CMakeLists.txt:84 (find_package):
  By not providing "Findcrtm.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "crtm", but
  CMake did not find one.

  Could not find a package configuration file provided by "crtm" (requested
  version 2.2.3) with any of the following names:

    crtmConfig.cmake
    crtm-config.cmake

  Add the installation prefix of "crtm" to CMAKE_PREFIX_PATH or set
  "crtm_DIR" to a directory containing one of the above files.  If "crtm"
  provides a separate development package or SDK, be sure it has been
  installed.

-- Configuring incomplete, errors occurred!

Additional information

Until this is resolved, use the Skylab v7 tag of CRTM (workaround is in https://github.com/JCSDA/ufs-bundle/pull/48).

[climbfuji]

Workaround was merged (use Skylab v7 release tag for CRTM). This is not a solution, therefore keeping this issue open.

[climbfuji]

@BenjaminTJohnson Unfortunately the update we merged into develop (install prefix fix) did not help - this is still an issue. Hopefully I have some time in the next few weeks!

[BenjaminTJohnson]

I guess I'm confused, I haven't changed cmake related things for a while.

Should I revert the latest change?

[climbfuji]

No, sorry for the confusion. I was hoping the latest change would solve a problem that was introduced between the skylabv7 tag (still ecbuild) and the skylabv8 tag (cmake) of crtm. Looking at the error more closely, that was a fool's hope. It can't find crtmConfig.cmake / crtm-config.cmake.

[rhoneyager-tomorrow]

@climbfuji https://github.com/JCSDA/CRTMv3/pull/140 - I may have fixed this inadvertently, though I'm not a regular ufs-bundle user. Might be worth revisiting.

[climbfuji]

@shlyaeva @fmahebert @BenjaminTJohnson please see @rhoneyager-tomorrow 's message above

[shlyaeva]

Thank you @rhoneyager-tomorrow and @climbfuji for bringing this up. I've just tried to build ufs-bundle with the crtmv3 develop and unfortunately see the same error as in this issue description.

[BenjaminTJohnson]

@shlyaeva @climbfuji @rhoneyager-tomorrow I'm confused why CRTMv3 develop works with jedi-bundle: fv3-jedi is the same commit hash for both jedi-bundle andufs-bundle. I rolled crtmv3 back to even prior to Ryan's commits, and ufs-bundle was failing before Ryan's commits, so this isn't a very new issue.

Specifically:

jedi-bundle: -- [fv3jedi] (1.9.0) [d3c800b]
ufs-bundle: -- [fv3jedi] (1.9.0) [d3c800b]

Any thoughts about what might be different between these two?

[BenjaminTJohnson]

@shlyaeva @climbfuji @rhoneyager-tomorrow because I was bored during my PTO, I think I've narrowed this down to the following: I copied the following cmake material from jedi-bundle "a" to ufs-bundle "b" CMakeLists.txt, and it allows it to cmake to completion.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index d8643d6..7ca39fd 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,26 +11,40 @@ find_package( ecbuild 3.5 REQUIRED HINTS ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CUR

 project( ufs-bundle VERSION 1.1.0 LANGUAGES C CXX Fortran )

-list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
+# Default release mode
+set( ECBUILD_DEFAULT_BUILD_TYPE Release )

-include( ecbuild_bundle )
-include( GNUInstallDirs )
-set(CMAKE_INSTALL_LIBDIR "lib")
+# Enable OpenMP and MPI
+set( ENABLE_MPI ON CACHE BOOL "Compile with MPI" )
+set( ENABLE_OMP ON CACHE BOOL "Compile with OpenMP" )

+# Depend path for non-ecbuild packages
 set(DEPEND_LIB_ROOT ${CMAKE_CURRENT_BINARY_DIR}/Depends)
 list(APPEND CMAKE_PREFIX_PATH ${DEPEND_LIB_ROOT})
-message("prefix path is ${CMAKE_PREFIX_PATH}")

-# Default release mode
-set( ECBUILD_DEFAULT_BUILD_TYPE Release )
+# Library path for non-ecbuild packages
+link_directories(${CMAKE_CURRENT_BINARY_DIR}/lib)
+
+include( GNUInstallDirs )
+if(APPLE)
+       list( APPEND CMAKE_INSTALL_RPATH $ENV{llvm_openmp_ROOT}/lib )
+endif()
+list( APPEND CMAKE_INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/fv3 )

-# Enable MPI
-set( ENABLE_MPI ON CACHE BOOL "Compile with MPI")
-set( ENABLE_OMP ON CACHE BOOL "Compile with OpenMP")
+# add the automatically determined parts of the RPATH
+# which point to directories outside the build tree to the install RPATH
+set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON)

-# Use external jedi-cmake or build in bundle
+# when building, already use the install RPATH
+set(CMAKE_BUILD_WITH_INSTALL_RPATH ON)
+
+# Define bundle
+ecbuild_bundle_initialize()

Not sure which of the above fixed it, but ufs-bundle was missing the ecbuild_bundle_initialize line, and the RPATH stuff -- which is the most likely culprit in my extremely limited experience with cmake. This is as far as my laziness will take me, but hopefully one of the 3 of you can spot the exact changes necessary to fix ufs-bundle. I'm of the opinion that the "setup" material in all of our bundles should be more similar than they currently are.

[shlyaeva]

@BenjaminTJohnson great! do you mind opening the PR for that?

[climbfuji]

The issue is that the ufs-weather-model uses a plain cmake build that doesn't work well in an ecbuild system. I didn't make the original design choice to use an external project for ufs-weather-model. Instead, for the new fv3 dycore in jedi-bundle, I decided to go a different route (create an interface cmake file for it with the minimum settings necessary). I think the same would work for ufs-weather-model in ufs-bundle.