Use data glc model where we used to use CISM2%NOEVOLVE

[billsacks]

In compsets that currently use CISM2%NOEVOLVE – and will soon change to use SGLC – we'd like to instead use a data glc model in a time-constant mode. This should provide all of the benefits that we currently get from CISM2%NOEVOLVE: dictating glacier area and topographic heights over the ice sheet domain and providing a high-resolution grid onto which SMB and other fields can be downscaled.

We plan to develop this data glc model in CDEPS, which relies on NUOPC. So we will wait to make this switch until we are using NUOPC as a standard mode of operation (footnote this has happened now).

Definition of done:

• [x] Update CISM and CTSM to use GLC_USE_ANTARCTICA #2222
• [x] Update CTSM with a version of CDEPS that supports DGLC (https://github.com/ESCOMP/CDEPS/issues/25) and (https://github.com/ESCOMP/CDEPS/pull/268)
• [ ] Add I compsets to CTSM that exercise DGLC
• [ ] Add testing to CTSM that test needed DGLC cases
• [ ] Update to a DGLC Verizon that handles negative runoff for glaciers
• [ ] Change most I compsets/tests to use DGLC rather than SGLC

[billsacks]

Blocked: depends on https://github.com/ESCOMP/CDEPS/issues/25

[ekluzek]

LIWG is going to support a DGLC model rather than CISM%NOEVOLVE mode for CESM3. This means rather than fixing #2222 for CISM/CTSM the ability to run cases with DGLC will be setup. This is important for fully coupled compsets so that negative runoff is NOT sent to the ocean model. It looks right now the only CISM%NOEVOLVE compsets and tests are B1850 cases. So minimally we would only need to have a few tests around DGLC for 1850 with Bgc-Crop.

I added some notes about what needs to happen to the introduction for a "Definition of Done" above.

[billsacks]

@ekluzek - responding to and clarifying some points:

• The current implementation of dglc does not yet deal with the negative runoff issue. That is going to involve some substantial development, but yes, I think the current tentative plan is now to do that development in dglc rather than CTSM.
• Regarding which I compsets should be changed to use DGLC in NOEVOLVE mode: Others in the LIWG can comment on this as well, but my understanding is that nearly all I compsets (as well as F & B compsets) will be changed to use DGLC in NOEVOLVE mode; the main exception would be single-point / regional cases. This would go back to being more like how things were when I opened this issue a few years ago, when nearly all configurations used CISM%NOEVOLVE. We stoped using CISM%NOEVOLVE because it was becoming a support burden, but the plan at that time (and still now, I believe) is for these CISM%NOEVOLVE configurations to all be replaced with DGLC.
• The reasons it's better to run with DGLC over SGLC are: (a) this will ensure that glacier cover over Greenland and Antarctica agree with CISM's datasets (without requiring potentially frequent updates to CTSM's glacier raw dataset for this purpose); (b) this allows for downscaling of CTSM's surface mass balance to a high resolution glacier grid; and (c) this will allow for consistent treatment of runoff in various configurations, once this is enabled in DGLC (which isn't critical for an I compset, but it seems good to keep things consistent in this respect, and will allow testing this code in an I compset).

[ekluzek]

@billsacks and @Katetc I think this is something that's required for the June/30th science capability/functionality freeze correct? If so I'll mark it that way.

[wwieder]

Is this required for the summer science capability freeze or before the CESM3.0 release?

[wwieder]

@ekluzek thinks it's for the later (CESM 3 release), but is this accurate @billsacks, @whlipscomb, @Katetc?

[billsacks]

Good question.

For scientifically-supported configurations, they should use ideally either DGLC or an evolving CISM by the science capability freeze, since that will be greater-than-roundoff answer-changing relative to using SGLC. I'm not clear on which configurations will be using DGLC and which will be using an evolving CISM; that may require some discussion, which I guess should happen ASAP.

That said, the changes shouldn't be huge, so this could probably happen at lower priority than other changes needed by this date.

(I assume we're just talking about I compsets here, given that this is a CTSM issue. For B compsets, getting them correct will be higher priority.)

[wwieder]

This came up at co-chairs today, with the TODO to decide on running stub vs. data glacier models in F and I compsets. Maybe @Katetc or @billsacks can weigh in here to help us understand when or why we'd want to run with DGLC vs. SGLC by default moving forward?

[billsacks]

My feeling is that I and F compsets should stay consistent with B compsets in this respect and generally use DGLC (or an evolving CISM) in nearly all cases. An exception would be regional cases that don't involve Greenland or Antarctica (I'm not sure if it would work to use DGLC in those cases; maybe it would).

The main advantages of this are what's laid out in the initial comment of this issue: dictating glacier area and topographic heights over the ice sheet domain and providing a high-resolution grid onto which SMB and other fields can be downscaled.

In B compsets an additional advantage of DGLC is that @Katetc recently put in place some improved handling of runoff fluxes to better handle negative runoff over ice sheets; this probably isn't important for I or F compsets, but it seems best to stay consistent with B compsets in this respect.

[wwieder]

Thanks for this explantation, Bill.

So single point and regional cases should use a SGLC, with DGLC uses everywhere else. This is easy to set up for single point compsets, but a bit trickier in regional cases. I guess our documentation and examples just need to be clear for setting up regional cases with long-name compsets?

[billsacks]

So single point and regional cases should use a SGLC, with DGLC uses everywhere else. This is easy to set up for single point compsets, but a bit trickier in regional cases. I guess our documentation and examples just need to be clear for setting up regional cases with long-name compsets?

Yes, that sounds right. It may be worth experimenting and seeing if things happen to work when using DGLC with a regional configuration that doesn't include the DGLC domain. I wouldn't be surprised if you run into errors with that, but it might just work.

Note that I think this is similar to the situation we had with CESM2.1 / CLM5: There, I think we used CISM2%NOEVOLVE for most configurations, but SGLC for single-point / regional configurations.