Fix bug in CMakeLists.txt (get_filename_component was using non-existent path as BASE_DIR), use ip@5: if available instead of sp #1090

climbfuji · 2024-10-07T14:15:19Z

Description

This PR does two things:

Fix a bug in CMakeLists.txt: The first call to get_filename_component seems to be using an uninitialized (empty) variable LOCAL_CURRENT_SOURCE_DIR as BASE_DIR argument. It would be good if somebody could verify that.
The sp library is deprecated and replaced by ip@5 and newer (drop-in replacement). While [email protected] is still in spack-stack-1.8.0, ip-5.0.0 is also available. We expect sp to be removed in spack-stack-1.9.0.

Because of (2), similar changes need to be made in the host model (SCM: PR to come in a minute, UFS: someone else needs to do).

Note that I cannot compile the SCM on my laptop with GCC, because the SCHEMES_OPENMP_OFF logic seems to be not working as expected (with and without the change made in 1 I believe), therefore I would like to ask someone else to test these two changes, please.

…ent path as BASE_DIR), use ip@5: if available instead of sp

dustinswales

@climbfuji Thanks for making these changes.
@grantfirl Is there and open ccpp-physics:ufs/dev PR that I(you) could add this on the UFS side?

climbfuji · 2024-12-27T20:16:27Z

ping

grantfirl

Agree that LOCAL_CURRENT_SOURCE_DIR is empty.

grantfirl

Something about switching to ip/5.0.0 is causing compilation of RRTMGP to fail. @dustinswales

dustinswales · 2025-01-27T17:48:57Z

@grantfirl I needed to add the following to the CMakeLists.txt for things to work with GP:
if(SCHEMES_OPENMP_OFF)
SET_PROPERTY(SOURCE ${SCHEMES_OPENMP_OFF}
APPEND_STRING PROPERTY COMPILE_FLAGS " ${CMAKE_Fortran_FLAGS_PHYSICS} -qno-openmp ")
list(REMOVE_ITEM SCHEMES ${SCHEMES_OPENMP_OFF})

I'm not sure if this is the ideal solution though?
Also, I can't understand why we NOW need this flag. Is it that the flags come down from above and they aren't getting set correctly for the new spack-stack version?
@climbfuji

climbfuji · 2025-01-27T18:15:48Z

@grantfirl I needed to add the following to the CMakeLists.txt for things to work with GP: if(SCHEMES_OPENMP_OFF) SET_PROPERTY(SOURCE ${SCHEMES_OPENMP_OFF} APPEND_STRING PROPERTY COMPILE_FLAGS " ${CMAKE_Fortran_FLAGS_PHYSICS} -qno-openmp ") list(REMOVE_ITEM SCHEMES ${SCHEMES_OPENMP_OFF})

I'm not sure if this is the ideal solution though? Also, I can't understand why we NOW need this flag. Is it that the flags come down from above and they aren't getting set correctly for the new spack-stack version? @climbfuji

Pretty sure that one of the dependencies (maybe ip) defines itself as a cmake target with the openmp flags incorrectly assigned as public.

Note that your -qno-openmp` is Intel-specific, will need to define the no-openmp flag for each compiler.

dustinswales · 2025-01-27T18:45:51Z

Pretty sure that one of the dependencies (maybe ip) defines itself as a cmake target with the openmp flags incorrectly assigned as public.
This seems plausible to me. How to we confirm this is the case? Or do we even care for this PR switching from SP to IP? Is this more of a spack-stack problem?

Note that your -qno-openmp` is Intel-specific, will need to define the no-openmp flag for each compiler.
Yeah, that's why I didn't this was the solution and the flags are being corrupted further up.

climbfuji · 2025-01-27T18:52:51Z

Pretty sure that one of the dependencies (maybe ip) defines itself as a cmake target with the openmp flags incorrectly assigned as public.
This seems plausible to me. How to we confirm this is the case? Or do we even care for this PR switching from SP to IP? Is this more of a spack-stack problem?

It's going to be your problem, because spack-stack-1.10 definitely won't have sp anymore, maybe even spack-stack-1.9.0.

Confirming is easy, just look in the cmake target definitions of the ip library. Example:

> cat ../../neptune/spack-stack/spack-stack-neptune-1.5/envs/ne-oneapi-2024.2.1/install/oneapi/2024.2.1/ip-5.1.0-6uutwti/lib64/cmake/ip/ip-targets.cmake

# Create imported target ip::ip_4
add_library(ip::ip_4 STATIC IMPORTED)

set_target_properties(ip::ip_4 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include_4"
  INTERFACE_LINK_LIBRARIES "OpenMP::OpenMP_Fortran;LAPACK::LAPACK"
)

# Create imported target ip::ip_d
add_library(ip::ip_d STATIC IMPORTED)

set_target_properties(ip::ip_d PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include_d"
  INTERFACE_LINK_LIBRARIES "OpenMP::OpenMP_Fortran;LAPACK::LAPACK"
)

# Create imported target ip::ip_8
add_library(ip::ip_8 STATIC IMPORTED)

set_target_properties(ip::ip_8 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include_8"
  INTERFACE_LINK_LIBRARIES "OpenMP::OpenMP_Fortran;LAPACK::LAPACK"
)

Note that your -qno-openmp` is Intel-specific, will need to define the no-openmp flag for each compiler.
Yeah, that's why I didn't this was the solution and the flags are being corrupted further up.

climbfuji · 2025-01-27T18:54:50Z

See also NOAA-EMC/NCEPLIBS-ip#234

dustinswales · 2025-01-28T21:28:50Z

Pretty sure that one of the dependencies (maybe ip) defines itself as a cmake target with the openmp flags incorrectly assigned as public.
This seems plausible to me. How to we confirm this is the case? Or do we even care for this PR switching from SP to IP? Is this more of a spack-stack problem?

It's going to be your problem, because spack-stack-1.10 definitely won't have sp anymore, maybe even spack-stack-1.9.0.

Confirming is easy, just look in the cmake target definitions of the ip library. Example:
> cat ../../neptune/spack-stack/spack-stack-neptune-1.5/envs/ne-oneapi-2024.2.1/install/oneapi/2024.2.1/ip-5.1.0-6uutwti/lib64/cmake/ip/ip-targets.cmake

# Create imported target ip::ip_4
add_library(ip::ip_4 STATIC IMPORTED)

set_target_properties(ip::ip_4 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include_4"
  INTERFACE_LINK_LIBRARIES "OpenMP::OpenMP_Fortran;LAPACK::LAPACK"
)

# Create imported target ip::ip_d
add_library(ip::ip_d STATIC IMPORTED)

set_target_properties(ip::ip_d PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include_d"
  INTERFACE_LINK_LIBRARIES "OpenMP::OpenMP_Fortran;LAPACK::LAPACK"
)

# Create imported target ip::ip_8
add_library(ip::ip_8 STATIC IMPORTED)

set_target_properties(ip::ip_8 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include_8"
  INTERFACE_LINK_LIBRARIES "OpenMP::OpenMP_Fortran;LAPACK::LAPACK"
)
Note that your -qno-openmp` is Intel-specific, will need to define the no-openmp flag for each compiler.
Yeah, that's why I didn't this was the solution and the flags are being corrupted further up.

@climbfuji Is it not the case that whoever builds spack-stack-1.9, and onwards, for the UWM will have to build the IP target correctly? Which will then be available for the SCM?

climbfuji · 2025-01-28T22:44:02Z

If your testing with the PRIVATE directive works well, we can ask the NCEPLIBS-ip developers to fix their package and then switching shouldn't be a problem once sp is gone.

climbfuji · 2025-03-18T13:53:26Z

Closing this. Someone can take care of updating to [email protected] or later when sp is no longer distributed in spack-stack-2.0.0 (anticipated for July 2025). spack-stack-1.9.1 still has sp and the "faulty" [email protected].

grantfirl · 2025-03-18T14:30:11Z

Closing this. Someone can take care of updating to [email protected] or later when sp is no longer distributed in spack-stack-2.0.0 (anticipated for July 2025). spack-stack-1.9.1 still has sp and the "faulty" [email protected].

Thanks for checking on this. I've tested the SCM with 1.9.1 with success, but I hadn't tested it with ip replacing sp yet. When ip is updated, I'll be happy to test it and update it.

climbfuji · 2025-03-18T14:36:14Z

We need at least [email protected], if not a later version to fix the issues you've seen.

Fix bug in CMakeLists.txt (get_filename_component was using non-exist…

be05d12

…ent path as BASE_DIR), use ip@5: if available instead of sp

climbfuji requested review from Qingfu-Liu, dustinswales, grantfirl and mzhangw as code owners October 7, 2024 14:15

This was referenced Oct 7, 2024

Use ip@5: if available instead of sp NCAR/ccpp-scm#524

Open

Remove sp library in spack-stack-1.9.0 --> spack-stack-2.0.0 JCSDA/spack-stack#1330

Open

dustinswales approved these changes Oct 7, 2024

View reviewed changes

Merge branch 'main' into feature/ip5

9d967aa

grantfirl requested a review from rhaesung as a code owner January 17, 2025 00:27

grantfirl approved these changes Jan 17, 2025

View reviewed changes

Qingfu-Liu approved these changes Jan 17, 2025

View reviewed changes

grantfirl requested changes Jan 17, 2025

View reviewed changes

climbfuji mentioned this pull request Jan 27, 2025

OpenMP and UFS WM NOAA-EMC/NCEPLIBS-ip#234

Closed

climbfuji closed this Mar 18, 2025

climbfuji deleted the feature/ip5 branch March 18, 2025 14:36

Fix bug in CMakeLists.txt (get_filename_component was using non-existent path as BASE_DIR), use ip@5: if available instead of sp #1090

Fix bug in CMakeLists.txt (get_filename_component was using non-existent path as BASE_DIR), use ip@5: if available instead of sp #1090

Uh oh!

Conversation

climbfuji commented Oct 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

dustinswales left a comment

Choose a reason for hiding this comment

Uh oh!

climbfuji commented Dec 27, 2024

Uh oh!

grantfirl left a comment

Choose a reason for hiding this comment

Uh oh!

grantfirl left a comment

Choose a reason for hiding this comment

Uh oh!

dustinswales commented Jan 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

climbfuji commented Jan 27, 2025

Uh oh!

dustinswales commented Jan 27, 2025

Uh oh!

climbfuji commented Jan 27, 2025

Uh oh!

climbfuji commented Jan 27, 2025

Uh oh!

dustinswales commented Jan 28, 2025

Uh oh!

climbfuji commented Jan 28, 2025

Uh oh!

climbfuji commented Mar 18, 2025

Uh oh!

grantfirl commented Mar 18, 2025

Uh oh!

climbfuji commented Mar 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

climbfuji commented Oct 7, 2024 •

edited

Loading

dustinswales commented Jan 27, 2025 •

edited

Loading