Move from sp to ip

[rhaesung]

Description

See ufs-community/ufs-weather-model#3041 for a description of the issue.

sp is no longer provided in spack-stack 2.0.0. We should evaluate and transition to ip, which appears to provide the required subset of functionality.

This may primarily require updating linked libraries in the build system rather than code changes.

Solution

• Update build configuration to link against ip instead of sp.
• Identify any required code adjustments (if needed).
• Verify compatibility with spack-stack 2.0.0

[yangfanglin]

@rhaesung has this been done on the UFS/CCPP side ?

[yangfanglin]

@rhaesung If DTC team is busy, will you be able to work on this as a priority ?

[rhaesung]

@yangfanglin Thanks for the follow-up.
Since @scrasmussen mentioned that testing with spack-stack 2.0 had started on Derecho a couple of weeks ago (#1070 (comment)), I was wondering how things are progressing on that front.
While I’m not deeply familiar with the library configuration, I’ll review the build setup and assess what changes may be needed to move from sp to ip.

[scrasmussen]

@yangfanglin Thanks for the follow-up. Since @scrasmussen mentioned that testing with spack-stack 2.0 had started on Derecho a couple of weeks ago (#1070 (comment)), I was wondering how things are progressing on that front. While I’m not deeply familiar with the library configuration, I’ll review the build setup and assess what changes may be needed to move from sp to ip.

@rhaesung I've been busy with other projects but I'll move this higher up on my todo list! I'll aim to get this worked out by the end of the week

[scrasmussen]

@rhaesung I got the SCM to build with Spack Stack 2.0.0 and the new ip library. The changes to the CCPP-Physics are in #1197 and are relatively small. As you can see in PR NCAR/ccpp-scm#662 the host model needs a few more things done.

The key changes are

• Link ip::ip_d if ip_FOUND, otherwise link sp::sp_d. Seems like a good thing to allow both until SP is officially sunsetted.
• The host model will need to define the variable CMAKE_Fortran_FLAGS_OPENMP_OFF, such as the following for GNU: set(CMAKE_Fortran_FLAGS_OPENMP_OFF "-fno-openmp"). As explained in the PRs, the ip package builds with the OpenMP flag so it gets turned on in the CMake build. The RRTMGP files currently break if compiled with OpenMP flags so the CMAKE_Fortran_FLAGS_OPENMP_OFF environment variable will make sure OpenMP isn't used by the RRTMGP files.
• Bacio has been updated so the target is now bacio::bacio instead of bacio::bacio_4
• To build the SCM with the Intel oneAPI 2025.2.1 the optimization had to be turned off to -O0. It fails at runtime on Derecho though, so I'll be looking into that more (After more testing it seems -O0 is only needed with SCM when building all suites at once, when doing a subset of suites -O2 will work just fine)

[climbfuji]

The last item is probably SCM-specific; we build and run NEPTUNE with -O2 and several other optimization flags.

[dustinswales]

For a reference, here is the CMakeLists for the SCM with Intel oneAPI. Same Release flags, but slightly different DEBUG flags were needed.
When using oneAPI I had to turn off 4 RRTMGP RTs that were failing,

[rhaesung]

Thanks, @scrasmussen for the detailed explanation and for the PR. This is very helpful. I’ll pass these changes and notes along to the UFS code managers and coordinate the necessary updates on our side.

[scrasmussen]

@rhaesung no problem!

@climbfuji @dustinswales Good to know! Did a bit more testing this morning, seems like -O0 flag is only required with the SCM when building all of the suites at once. Doing a subset of the suites works just fine with -O2.

[dustinswales]

@scrasmussen Yeah. Intel oneAPI does not build with all of the SCM suites.
I just updated my description of SCM658 to:
" -Tests have been broken down into "supported", "legacy" and "dev". UPDATE: This is a workaround for the limitation on the number of SDFs that can be used with Intel oneAPI."

[grantfirl]

@rhaesung @scrasmussen It seems as though the ccpp-physics and ccpp-scm PRs work just fine with spack-stack 2.0.0 and ip. I'm guessing that we need to create UFSATM/UWM PRs for this too, right? Or, should this wait until UFS moves to spack-stack 2.0.0+?