Update: spack stack 1.9.3 and 2.0.0 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

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?