Update: spack stack 2.0.0 (for Intel) and 2.1.0 (for GNU) and ip library

[scrasmussen]

SOURCE: Soren Rasmussen, NSF NCAR

DESCRIPTION OF CHANGES:

• Add ability to build with ip library if it is found. The sp library is being replaced by ip so this is required. Note that in spack-stack 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 target was updated from bacio::bacio_4 to bacio::bacio in spack-stack 2.0.0
• To build with the Intel oneAPI 2025.2.1 the optimization had to be turned off to -O0. It fails at runtime on Derecho though, this will need to investigated more.
• Spack Stack 1.9.3 is used for GNU and 2.0.0 for Intel since per the Spack Stack 2.0.0 release notes, GNU is not supported on Derecho in 2.0.0

ASSOCIATED PRs:

• Ability to build with ip and sp library ccpp-physics#1197
• [scm/dev] Ability to build with ip and sp library ccpp-physics#1208

TESTS CONDUCTED: Built on Derecho with GNU and Intel. GNU successfully ran the scm cases but Intel is failing.

Contributors:

Built on work from @climbfuji in NCAR/ccpp-physics#1090 and #524

[hertneky]

@scrasmussen I ran tests on derecho with this PR.

GNU w/ 1.9.3 Builds and runs SCM fine
Intel w/2.0.0 Can build with more memory - no scm cases run

Did you ever discover what the issue with running the SCM was for Intel on Derecho? Do you want me to look into it? LMK

[scrasmussen]

Did you ever discover what the issue with running the SCM was for Intel on Derecho? Do you want me to look into it? LMK

@hertneky I haven't had time to dive into why the SCM is failing with an Intel executable. I'll be able to look into it a bit more next week. If we want to merge this in sooner I can split off the intel stuff until we can get it to run. Or we can add a note when the spack stack 2.0 intel modules are loaded that the SCM is failing at runtime with them

[hertneky]

Did you ever discover what the issue with running the SCM was for Intel on Derecho? Do you want me to look into it? LMK

@hertneky I haven't had time to dive into why the SCM is failing with an Intel executable. I'll be able to look into it a bit more next week. If we want to merge this in sooner I can split off the intel stuff until we can get it to run. Or we can add a note when the spack stack 2.0 intel modules are loaded that the SCM is failing at runtime with them

@scrasmussen That's what I wasn't sure about either, whether it was fine to merge this knowing intel is broken for running SCM. Do others have thoughts? @grantfirl @dustinswales

[grantfirl]

I'd also like to get this working on Ursa before merging this. I can work on that.

[grantfirl]

@scrasmussen @hertneky I just uploaded a module file for spack-stack-2.0.0 using ip on Ursa. It successfully compiled and ran a case. I also made a new spack-stack-2.0.0 python virtual environment to use there in /scratch3/BMC/gmtb/ccpp-scm-software.

[grantfirl]

@scrasmussen Also, no issues on Ursa for using -O2. If issues persist on Derecho, we should test for which machine is being used before reducing optimization, IMO.

[grantfirl]

@scrasmussen @hertneky Also added a GNU module file and python environment using spack-stack 2.0.0. Everything works with GNU too.

[grantfirl]

I also tested the code using the spack-stack-1.9.1 module on Ursa (without ip), and it successfully built/ran, so it will successfully fall back to the sp library if necessary.

[grantfirl]

@scrasmussen I removed the -O0 in the scm/src/CMakeLists.txt since it is apparently a known issue with too many suites that will be addressed in a future PR. Are there any problems remaining on Derecho?

[grantfirl]

@scrasmussen I had several commits into this PR branch, including ursa module files for using spack stack 2.0. Where did those commits go?

[scrasmussen]

@scrasmussen I had several commits into this PR branch, including ursa module files for using spack stack 2.0. Where did those commits go?

Dang, I didn't pull before rebasing, sorry about that! I'll fix this, thanks for pointing this out!

[scrasmussen]

I believe this PR is now ready to be merged after people review it.

Things I updated and tested today:

• Looks like the Intel built executable was failing at runtime on Derecho because SCM_GFS_v16_ps is a required suite to run the supported case arm_sgp_summer_1997_A. I updated the supported suites to reflect that need
• The code builds and runs for derecho_gnu/2.1.0 and derecho_intel/2.0.0
  • spack-stack 2.1.0 for Intel doesn't currently work on Derecho because it tries to load intel/2025.3.1 and only intel/2025.3.2 exists
  • Just noting that sadly the emacs module doesn't exist with spack-stack 2.1.0
• I've add derecho_gnu and derecho_intel as directories and the different spack-stack versions as lua files in them. The default version loaded is listed in the .modulerc.lua files

[grantfirl]

I don't think that adding SCM_GFS_v16_ps should be necessary. Let me look.

[grantfirl]

I don't think that supported_suites and supported_cases are actually used anymore by anything. I really don't understand why this was necessary.

[scrasmussen]

I and I believe @hertneky, use supported suites and cases as the minimum list of suites and cases to test. I didn't use them before ifx, because I'd just use Intel to build everything at once.

I agree they don't seem to be used by anything, so if they don't represent the minimum list of suites and cases we support, we might want to discuss removing these files in the SCM meeting.

[grantfirl]

Ya, I think these have been entirely supplanted by suite_info.py. I think that they should be removed.

[scrasmussen]

Ok, I see now, thanks for the explanation! I'll add a commit removing those two files

[grantfirl]

FYI, this now depends on NCAR/ccpp-physics#1208

[grantfirl]

@scrasmussen There will be an incoming PR into your PR branch to add functionality to compile suites based on the run_list functionality in the rt_test_cases.py. Compiling only those suites needed to run each of the run_lists in rt_test_cases.py at one time allows one to get past the ifx memory issue easily without having to manually specify suites for cmake.

[grantfirl]

@scrasmussen Please see scrasmussen#11

I uses this successfully on derecho using intel and gnu. The only issue that I ran into was the interactive session didn't have enough memory for the RRTMGP runs by default.