Update the global workflow environment - #2068
Conversation
28a7f7e to
a2e8e88
Compare
057aabe to
42f83b7
Compare
|
|
||
| # Is GMAO ready to move to crtm@3.1.3? | ||
| - gmao-swell-env ^crtm@=v2.4.1-jedi.2 | ||
| - gsi-env ^crtm@=3.1.3 |
There was a problem hiding this comment.
Now that the global workflow environment includes the GSI environment, should this be removed from the unified environment?
There was a problem hiding this comment.
If the gsi-env is included in the unified environment only because the global workflow needs it, then I'd say yes. I'd like to defer to @climbfuji and @AlexanderRichert-NOAA on this though!
| # The unified environment concretizes these two envs twice: once against | ||
| # crtm@3.1.3 (their own root specs) and once against crtm@v2.4.1-jedi.2, | ||
| # as pulled in by global-workflow-env. Suffix the latter so the module | ||
| # files don't clash. | ||
| gsi-env: | ||
| suffixes: | ||
| ^crtm@v2.4.1-jedi.2: 'crtm-2.4.1-jedi.2' | ||
| ufs-weather-model-env: | ||
| suffixes: | ||
| ^crtm@v2.4.1-jedi.2: 'crtm-2.4.1-jedi.2' |
There was a problem hiding this comment.
I should have caught this earlier. If we need to keep CRTM 2 for the GSI, we would need the version 2.4.0.1, not 2.4.1-jedi. I'm not sure how feasible this option is, though, as that would make for 3 CRTM packages, and 2.4.0.1 has not been in spack-stack since 1.9.x, so I'm not sure how compatible it is.
All of that to say, I think it would be best if we can just move to CRTM 3.x, and my suggestion would be to remove crtm-2.4.1-jedi from the GSI and global workflow environments entirely.
But I should defer this line to DA personnel:
@RussTreadon-NOAA do you think it would be acceptable to move the GSI and GDASapp to CRTM 3 for the spack-stack 2.x upgrade or do you need the capability to run with CRTM 2?
There was a problem hiding this comment.
@DavidHuber-NOAA : We should move GSI and GDASApp to CRTM v3. @ADCollard was looking at CRTM v3 in the GSI. I'm not aware of anyone looking at CRTM v3 in GDASApp
There was a problem hiding this comment.
Thanks @RussTreadon-NOAA.
In that case, I'll stick to my original suggestion that we remove references to CRTM 2.4.x from the GSI and GW environments.
There was a problem hiding this comment.
The gsi-env included explicitly in the unified environment already depends on crtm@3.1.3. Regardless of whether or not the gsi-env is retained in the unified environment explicitly, adding a ^crtm@3.1.3 to the global workflow environment would cover the global workflow + GSI crtm dependence. JEDI omits crtm dependence to force the user to provide it explicitly. In keeping with that pattern, I think global-workflow-env+gdas probably shouldn't specify the crtm version needed for JEDI. For the vast majority of users, they will get the correct crtm version from the unified environment anyway. Otherwise, the version needed for JEDI will be missing (unless it's crtm@3.1.3) and the user will have to decide, which is the intention.
|
@AlexanderHrabski-NOAA Can you take a look at the reviewer comments and pull in develop, please? |
8bbfbaa to
3f369a1
Compare
|
I rebased on develop and reverted the changes related to duplicate packages because the duplicates were due to having additional |
|
I personally don't have a preference. The idea of the metamodules is to make sure all the various apps are represented in the unified env, so as long as all the GSI dependencies end up there my two cents is it's okay either way. |
|
I defer to @RussTreadon-NOAA and @DavidHuber-NOAA |
|
As long as GSI applications are able to build and run correctly, I am personally fine with whatever the library team decides. |
| rust: | ||
| require: | ||
| - '%c,cxx=gcc' | ||
| # glib@2.88 with the meson@1.11 build system fails to build for intel-oneapi-compilers@2025.3.1 |
There was a problem hiding this comment.
Interesting. I didn't run into issues building glib with Intel oneAPI, using versions between 2025.0.3 and 2026.1.0.
There was a problem hiding this comment.
I'd be happy to try to recreate the error. It's probably worth re-verifying the unified-env on Ursa after these changes and the rebase anyway!
5 participants
Description
This PR updates the
global-workflow-envwith the latest dependencies of the global workflow. The python variant is removed because it now must always be on, and some additional variants were added to support user installs for specific applications per the comments in #1994. Also removes theip2dependence fromufs-utils-envs, which was leading to a concretization error.ip2was depreciated, and no longer exists in thespack-packagesupstream.ipprovides the lost functionality.Dependencies
#2063 is required to build the environment for Ubuntu WSL.
Issues addressed
Resolves #1994
Applications affected
Affects the global workflow. Also modifies the unified environment, which includes the global workflow environment.
Systems affected
All, via changing an environment that is part of the unified environment.
Testing
CI: Note whether the automatic tests (GitHub actions tests that run automatically for every commit) pass or not
New tests added: List and describe any new tests added to GitHub actions
Additional testing: Add information on any additional tests conducted
unified-envon Ubuntu WSL with GNU compilersglobal-workflow-envon Ubuntu WSL with GNU compilersunified-envon Ursa with Intel OneAPI compilersglobal-workflow-envon Ursa with Intel OneAPI compilersKeeping this a draft while I test. Please let me know if there are other systems you'd like me to test this on.
Checklist