Convert F-compsets to use stub glacier instead of CISM%NOEVOLVE

[Katetc]

We had a meeting with @billsacks and @mvertens today to address issues with long test suite build times and calendars in compsets that use CISM%NOEVOLVE. We decided that the long term goal would be to build a NUOPC-based data glacier component that used active CISM output. But, this is likely several months to a year out. To address current issues, the LIWG is comfortable with other components moving to use stub glacier in their compsets temporarily.

I can update the F cases (and any other CAM-owned compsets that use CISM currently) to use stub glacier. This will not go into the 2.2 release. It will change all baseline answers slightly, very likely.

[cacraigucar]

Will replace CISM2%NOEVOLVE with SGLC

[Katetc]

I actually made these changes on a branch last week and ran the aux_cam tests. There were A LOT of answer changes. I'm not sure of the best way to validate this. I am going to check in with Bill Sacks.

[gold2718]

We expect a lot of answer changes, the issue is whether they are significantly bigger than roundoff. How big are these changes, especially in CAM?

[billsacks]

Larger than roundoff answer changes are expected because glacier cover will be different over Greenland.

[cacraigucar]

This is starting to feel like a high priority issue for a number of reasons:

1. Using the default intel compiler on izumi with DEBUG=T, the job errors out in glissade_velo_higher
2. It takes a long time to run glissade (when I use totalview, it takes a significant amount of time to get through its initialization)
3. I've been told that the compilation time is significant
4. According to @adamrher who consulted with @mvertens, CISM2%NOEVOLVE is not supported in NUOPC

@Katetc - Since you've started this, would you be willing to take the lead on this with the goal being of creating a PR in the next week or two? Or would you like for me to take the lead on this?

If I do it, I'd probably treat it like any other answer component change and for the most part accept the answer changes as they are and have this be the only change in the CAM tag. I'd probably ask the scientists at the Tuesday AMP meeting if they want any special tests run prior to committing this change.

[Katetc]

@cacraigucar I was looking into the answer changes today and I discovered that I was testing against the wrong baseline. I'll rerun the tests today and I think I can have a PR made tomorrow. The issue of how Stub glacier affects an F compost is much bigger than just the few lines of changes needed to implement. We can discuss validation on the PR.

[mvertens]

CISM2%NOEVOLVE is supported in NUOPC. It just adds complications when run in an F compset. Sorry if I have been confusing in communicating this.

On Wed, Dec 8, 2021 at 2:43 PM cacraigucar @.***> wrote:

This is starting to feel like a high priority issue for a number of reasons:

1. Using the default intel compiler on izumi with DEBUG=T, the job errors out in glissade_velo_higher
2. It takes a long time to run glissade (when I use totalview, it takes a significant amount of time to get through its initialization)
3. I've been told that the compilation time is significant
4. According to @adamrher https://github.com/adamrher who consulted with @mvertens https://github.com/mvertens, CISM2%NOEVOLVE is not supported in NUOPC

@Katetc https://github.com/Katetc - Since you've started this, would you be willing to take the lead on this with the goal being of creating a PR in the next week or two? Or would you like for me to take the lead on this?

If I do it, I'd probably treat it like any other answer component change and for the most part accept the answer changes as they are and have this be the only change in the CAM tag. I'd probably ask the scientists at the Tuesday AMP meeting if they want any special tests run prior to committing this change.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CAM/issues/204#issuecomment-989220087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4XCE4KNDZ6SQ2FALBIHYLUP7GRJANCNFSM4QSQONRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Dr. Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: @.***

[mvertens]

We should get Bill Sacks as well involved in the stub glacier discussion.

On Wed, Dec 8, 2021 at 2:47 PM Kate Thayer-Calder @.***> wrote:

@cacraigucar https://github.com/cacraigucar I was looking into the answer changes today and I discovered that I was testing against the wrong baseline. I'll rerun the tests today and I think I can have a PR made tomorrow. The issue of how Stub glacier affects an F compost is much bigger than just the few lines of changes needed to implement. We can discuss validation on the PR.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CAM/issues/204#issuecomment-989222414, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4XCEZORR2SMMQCJMR3JYDUP7G7DANCNFSM4QSQONRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Dr. Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: @.***

[gold2718]

CISM2%NOEVOLVE is supported in NUOPC. It just adds complications when run in an F compset.

Even if it is supported, I think we should use stub for now. Perhaps when a data glacier component is available we can try that.

[mvertens]

I totally agree and I've been pushing this for a while.

On Wed, Dec 8, 2021 at 3:06 PM goldy @.***> wrote:

CISM2%NOEVOLVE is supported in NUOPC. It just adds complications when run in an F compset.

Even if it is supported, I think we should use stub for now. Perhaps when a data glacier component is available we can try that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CAM/issues/204#issuecomment-989265110, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4XCEZ4PWTPTW3OTOSBW63UP7JFZANCNFSM4QSQONRQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Dr. Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: @.***

[billsacks]

Regarding the changes from running with SGLC instead of CISM: see https://escomp.github.io/cism-docs/cism-in-cesm/versions/master/html/clm-cism-coupling.html#stub-glc-model-cism-absent

[adamrher]

@billsacks If I'm understanding the SGLC functionality correctly, CLM units with glacier ECs will use the subgrid glacier area fractions from the surfdat file. That is fine by me. But I would prefer that at least the workhorse grids of CESM (e.g., f19_f19_mg17, f09_f09_mg17, ne30pg3_ne30pg3_mg17) use surfdat files using the new CTSM glacier dataset that Rene and I developed (https://github.com/ESCOMP/CTSM/issues/1406). In that dataset, the EC's are derived from the BedMachine datasets that CISM is (or should be using @whlipscomb?) using as its initial conditions for NO_EVOLVE configurations. This would result in little difference between SGLC and NO_EVOLVE, I think.

I suspect that new surfdats have not yet been made with the new glacier dataset?

[whlipscomb]

@adamrher, I agree. There's nothing CISM-specific about using BedMachine data to overwrite GMTED over Greenland and Antarctica. It's just the best dataset for these regions, so we might as well use it consistently across components.

As you say, this would have the side benefit of removing diffs between NO_EVOLVE and SGLC, though I'm not sure whether or not answers would be BFB.

[billsacks]

Updating CTSM's surface datasets to use the new glacier dataset is on the list for CTSM5.2, where @ekluzek will be doing a massive update of a bunch of surface dataset fields to newer versions.