You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[INSTALL]: ESMF v9.0.0b19 on ursa for pre-release testing #2128
@natalie-perlin I tried to test using an ESMF b19 for the current stack which @alexrichert built for me. The issue is that aside from the compiler changes, just going from sp->ip will change baselines. CESM has found some unexpected baseline changes w/ this release candidate, so I need to test w/ using the SS2.1x stack on Ursa (which makes the sp->ip change). This is delaying the ESMF 9.0 release, until both CESM and UFS can confirm behaviour. Can you let me know your timeline?
@natalie-perlin I tried to test using an ESMF b19 for the current stack which @alexrichert built for me. The issue is that aside from the compiler changes, just going from sp->ip will change baselines. CESM has found some unexpected baseline changes w/ this release candidate, so I need to test w/ using the SS2.1x stack on Ursa (which makes the sp->ip change). This is delaying the ESMF 9.0 release, until both CESM and UFS can confirm behaviour. Can you let me know your timeline?
@DeniseWorthen It's not entirely clear to me what you need - spack-stack-2.1.1 with the only difference being ESMF 9.0.0b18? Which compiler?
My understanding is that Alex built the current stack (1.9.2) with the b18 ESMF; but the sp->ip change in the stack won't go in until SS2.1. So Alex had to add sp also, to make the current develop work compile.
But it is also perfectly possible that I'm confused. I know when Brian tested the sp->ip change on WCOSS2 (ie, w/o using updated compilers, because WCOSS2 won't be updating), we got baseline changes. So I interpreted that as "same compiler (same stack) just adding the sp->ip changes baselines."
Yes, the original request was ambiguous (Pease install on Ursa with oneapi). I thought I could use what Alex had quickly done, but then I ran into the baseline change issue.
I've gotten a result to pass along to ESMF using just a DATM-OCN-ICE configuration. It may be consistent w/ what CESM saw. So I'd say you could hold off on this for now.
I've gotten a result to pass along to ESMF using just a DATM-OCN-ICE configuration. It may be consistent w/ what CESM saw. So I'd say you could hold off on this for now.
Ok. If you still need the spack-stack environment, all I need to know is the mapl version to use and then press enter.
@DeniseWorthen Just checking that this has been addressed. The spack-stack-2.2.0 release will ship with 9.0.0 b18 (for UFS) and b19 (for GEOS and NEPTUNE).
22. @theurich does b17 excludes the random data initialization? If so, we could have @DeniseWorthen test b17 to see if cpl_scalars problem still exist....
Yes, that is correct, the random-data-fill under NUOPC_Connector came in with b18, which is the reason why I pointed to b17 when the question came up in the yaml-cpp context.
@DeniseWorthen what is the last ESMF version (beta?) that the UFS Weather Model was currently validated against? I am just trying to fill in some blanks for myself. Thanks!
28. > 27. > 26. @theurich I don't know of any testing for UFS of a beta version prior to the request from Ann to test b9.0.18.
> > Thanks. Does this mean out-of-the-box UFS Weather Model uses the last official ESMF release, i.e. 8.9.1? >
We're actually still on SS1.9.2, which uses esmf 8.8.0
I am happy to add 8.9.1 last minute. But given that the UFS is still sitting on 8.8.0 in spack-stack-1.9.2, that the PR that updates to spack-stack-2.1.0 is moving at glacial speeds and still contains 8.8.0, I am not sure how helpful this will be. Adding 8.9.1 back may also require adding back in an older version of MAPL.
Given how slowly the UFS moves, we need to ask how realistic it will be for UFS to move to 2.2.0 / 9.0.0b17 before we release 2.3.0 with a proper release of ESMF 9.0.0.
30. I am happy to add 8.9.1 last minute. But given that the UFS is still sitting on 8.8.0 in spack-stack-1.9.2, that the PR that updates to spack-stack-2.1.0 is moving at glacial speeds and still contains 8.8.0, I am not sure how helpful this will be. Adding 8.9.1 back may also require adding back in an older version of MAPL.
Given how slowly the UFS moves, we need to ask how realistic it will be for UFS to move to 2.2.0 / 9.0.0b17 before we release 2.3.0 with a proper release of ESMF 9.0.0.
@climbfuji what you are saying makes sense to me. Given the track record, it does seem very unlikely that UFS is going to suddenly jump onto spack-stack 2.2.0, unless maybe for some internal testing... and that's what ESMF v9.0.0b17 is for.
From a general release strategy, I do see the benefit of always including the last official ESMF release in an official SS release. I think that is where @anntsay is coming from. But I also understand your concern about a compatible MAPL. My hope would be that any recent MAPL works with 8.9.1. Maybe @mathomp4 could confirm?
30. Yep. 8.9.1 is fine as I suspected. All MAPL tests pass and GEOSgcm v12 didn't crash.
@mathomp4 thanks a bunch for the quick testing against ESMF v8.9.1. Good to know it holds up as expected, and could potentially still slip into spack-stack 2.2.0 without needing a different MAPL version.
@climbfuji I know it's always a pain to push last minute changes into a release. I think the request to have the last official ESMF release included with a spack-stack release makes good sense going forward. But I also don't think anything will crumble if spack-stack 2.2.0 goes out the door as-is. Of course that's just my opinion ... and others may (will?) differ.
I'll try adding the current version of mapl@2.69.1 with esmf@8.9.1 in addition to what's in there. That will be in unified-dev (the unified environment) only.
Thanks everyone for the discussions and the additional checking! Dom, I really appreciate your flexibility in accommodating 8.9.1 this late in the release cycle.
Activity
climbfuji commentedon Sep 22, 2026
We just updated to 9.0.0b18 - do you know what if any critical update in b19 is missing in b18?
DeniseWorthen commentedon Sep 25, 2026
@climbfuji I've confirmed w/ ESMF that the b18 should be fine; b19 simply removed ESMX_test
climbfuji commentedon Sep 25, 2026
Great, thank you. We can probably skip b19 and go straight to the official release 9.0.0 once it's ready.
DeniseWorthen commentedon Oct 5, 2026
@natalie-perlin Do you have a timeline on when we might have a stack w/ the release candidate installed?
DeniseWorthen commentedon Oct 7, 2026
@natalie-perlin I tried to test using an ESMF b19 for the current stack which @alexrichert built for me. The issue is that aside from the compiler changes, just going from sp->ip will change baselines. CESM has found some unexpected baseline changes w/ this release candidate, so I need to test w/ using the SS2.1x stack on Ursa (which makes the sp->ip change). This is delaying the ESMF 9.0 release, until both CESM and UFS can confirm behaviour. Can you let me know your timeline?
climbfuji commentedon Oct 7, 2026
@DeniseWorthen It's not entirely clear to me what you need - spack-stack-2.1.1 with the only difference being ESMF 9.0.0b18? Which compiler?
DeniseWorthen commentedon Oct 7, 2026
My understanding is that Alex built the current stack (1.9.2) with the b18 ESMF; but the sp->ip change in the stack won't go in until SS2.1. So Alex had to add sp also, to make the current develop work compile.
But it is also perfectly possible that I'm confused. I know when Brian tested the sp->ip change on WCOSS2 (ie, w/o using updated compilers, because WCOSS2 won't be updating), we got baseline changes. So I interpreted that as "same compiler (same stack) just adding the sp->ip changes baselines."
climbfuji commentedon Oct 7, 2026
So basically, you want 2.1.1 with ESMF 9.0.0 b18 for Intel oneAPI?
DeniseWorthen commentedon Oct 7, 2026
Yes, the original request was ambiguous (
Pease install on Ursa with oneapi). I thought I could use what Alex had quickly done, but then I ran into the baseline change issue.EDIT: 18 or 19 doesn't matter though.
climbfuji commentedon Oct 7, 2026
Which mapl goes with this? The 2.1.1 mapl@2.53.4 is not compatible with 9.0.0b18.
DeniseWorthen commentedon Oct 7, 2026
I've gotten a result to pass along to ESMF using just a DATM-OCN-ICE configuration. It may be consistent w/ what CESM saw. So I'd say you could hold off on this for now.
climbfuji commentedon Oct 7, 2026
Ok. If you still need the spack-stack environment, all I need to know is the mapl version to use and then press enter.
climbfuji commentedon Oct 28, 2026
@DeniseWorthen Just checking that this has been addressed. The spack-stack-2.2.0 release will ship with 9.0.0 b18 (for UFS) and b19 (for GEOS and NEPTUNE).
8 remaining items
theurich commentedon Oct 28, 2026
Yes, that is correct, the random-data-fill under NUOPC_Connector came in with b18, which is the reason why I pointed to b17 when the question came up in the yaml-cpp context.
anntsay commentedon Oct 28, 2026
Hi @climbfuji I think 8.9.1 should be included as it is an official release of ESMF. Is it possible to still get 8.9.1 in this package?
theurich commentedon Oct 28, 2026
@DeniseWorthen what is the last ESMF version (beta?) that the UFS Weather Model was currently validated against? I am just trying to fill in some blanks for myself. Thanks!
DeniseWorthen commentedon Oct 28, 2026
@theurich I don't know of any testing for UFS of a beta version prior to the request from Ann to test b9.0.18.
theurich commentedon Oct 28, 2026
Thanks. Does this mean out-of-the-box UFS Weather Model uses the last official ESMF release, i.e. 8.9.1?
DeniseWorthen commentedon Oct 28, 2026
We're actually still on SS1.9.2, which uses esmf 8.8.0
theurich commentedon Oct 28, 2026
Okay. Good to know. Thank you.
climbfuji commentedon Oct 28, 2026
I am happy to add 8.9.1 last minute. But given that the UFS is still sitting on 8.8.0 in spack-stack-1.9.2, that the PR that updates to spack-stack-2.1.0 is moving at glacial speeds and still contains 8.8.0, I am not sure how helpful this will be. Adding 8.9.1 back may also require adding back in an older version of MAPL.
Given how slowly the UFS moves, we need to ask how realistic it will be for UFS to move to 2.2.0 / 9.0.0b17 before we release 2.3.0 with a proper release of ESMF 9.0.0.
theurich commentedon Oct 28, 2026
@climbfuji what you are saying makes sense to me. Given the track record, it does seem very unlikely that UFS is going to suddenly jump onto spack-stack 2.2.0, unless maybe for some internal testing... and that's what ESMF v9.0.0b17 is for.
From a general release strategy, I do see the benefit of always including the last official ESMF release in an official SS release. I think that is where @anntsay is coming from. But I also understand your concern about a compatible MAPL. My hope would be that any recent MAPL works with 8.9.1. Maybe @mathomp4 could confirm?
mathomp4 commentedon Oct 29, 2026
@theurich I believe MAPL v2 should be happy with ESMF 8.9.1. I'll do a test build with it and confirm this soon.
mathomp4 commentedon Oct 29, 2026
Yep. 8.9.1 is fine as I suspected. All MAPL tests pass and GEOSgcm v12 didn't crash.
theurich commentedon Oct 29, 2026
@mathomp4 thanks a bunch for the quick testing against ESMF v8.9.1. Good to know it holds up as expected, and could potentially still slip into spack-stack 2.2.0 without needing a different MAPL version.
@climbfuji I know it's always a pain to push last minute changes into a release. I think the request to have the last official ESMF release included with a spack-stack release makes good sense going forward. But I also don't think anything will crumble if spack-stack 2.2.0 goes out the door as-is. Of course that's just my opinion ... and others may (will?) differ.
climbfuji commentedon Oct 29, 2026
I'll try adding the current version of mapl@2.69.1 with esmf@8.9.1 in addition to what's in there. That will be in unified-dev (the unified environment) only.
anntsay commentedon Oct 29, 2026
Thanks everyone for the discussions and the additional checking! Dom, I really appreciate your flexibility in accommodating 8.9.1 this late in the release cycle.