Change routing of GLC runoff fluxes to go to ROF instead of OCN

[billsacks]

Currently, GLC runoff fluxes (which are generated when CISM is running with an evolving ice sheet; these are primarily solid ice representing ice calving, but there are also small liquid fluxes representing basal melt) are routed directly to the ocean using GLC -> OCN mapping files that follow the same procedure as ROF -> OCN mapping files: custom mapping file generation using a preprocessing step that does nearest neighbor plus smoothing. These custom mapping files are a barrier for the generation of new ice sheet grids, and currently don't work with multiple ice sheets (see #431 ).

The reason we originally chose this direct GLC -> OCN routing was to handle the possibility that someone would want to run with an evolving ice sheet but a DROF model (see https://github.com/ESCOMP/CMEPS/issues/431#issuecomment-1979288117). But in discussion with @mvertens , @whlipscomb, @Katec, @gunterl, @hgoelzer and Michele Petrini, people didn't feel that this was a configuration that we need to permit, and it would be better to make the process of introducing a new CISM grid simpler.

So we would like to change the routing of these GLC runoff fluxes to go to ROF instead of OCN.

I talked a bit with @swensosc about this; a couple of points emerged from this discussion:

• Note that the CISM domain might not match up exactly with the system's land-ocean mask. We should make sure that fluxes generated from CISM outside of the system's land-ocean mask make it to the ocean, and ideally end up in a reasonable place. For example, ice calving on the edge of a floating ice shelf should end up in nearby ocean grid cells. (We think this location should be roughly correct as long as the "coast" is defined as being at the edge of the ice shelf, which I think is currently the case. But we should still do some thinking and/or experimentation to make sure that ice calving generated ocean-side of the system's land-ocean boundary indeed makes it to the ocean.)
• Sean points out that we may want to use MOSART's direct-to-outlet routing rather than trying to unrealistically routing these fluxes through the river network, which would introduce physically unrealistic and unnecessary time delays, particularly given that we already smooth the generation of runoff fluxes over a year.

@whlipscomb raised the question of what would happen with melt of floating ice shelves. It feels like we might eventually want a separate stream for those fluxes, which goes directly glc -> ocn even if most glc fluxes go to rof. Note that this melt of floating ice shelves might appear at deeper levels of the ocean, which is another reason to go directly glc -> ocn. We'll need to confirm, though, if the ocean can handle these fluxes without the need for smoothing so that we can do a simple nearest neighbor rather than nearest neighbor + smoothing.

Once this is changed, the TODO notes referenced in #431 should no longer be an issue, so we should make sure they are removed.

• In terms of the concerns raised @swensosc
  • the MOSART mesh has a mask of 1 everywhere. Consequently, the mapping of cism->mosart will not depend on the system's land-ocean mask. In fact - this is a benefit of send the cism runoff fluxes to mosart rather than directly mapping to the ocean where the ocean mask becomes an issue.
  • all points that are sent from cism that are recognized by mosart as being ocean (not land or outlet) will just be viewed as the outlet point (via the setting of idx ocean).

[jedwards4b]

@mvertens do I understand correctly that this will also require a change in mosart or did I get that wrong?

[ekluzek]

From email discussions with the CISM group the plan is to have a scientifically supported BG compset for CESM3.0, with an evolving Greenland ice sheet, which means this capability needs to come in for the science capability freeze currently slated for June/30th.

[mvertens]

@jedwards4b - yes this will involve a change in MOSART and I will only be implementing this on top of https://github.com/ESCOMP/MOSART/pull/76 which has already been brought into NorESM.

[ekluzek]

Thanks for clarifying that @mvertens appreciate it. LMWG wasn't aware of this as a critical thing that needed to come in for CESM3. To my knowledge there is not an issue in MOSART for this, nor did we have it in our list of CESM3 prioritization

https://github.com/ESCOMP/CTSM/projects/40

Note, that from the perspective of LMWG we had already brought in the critical things needed for MOSART and RTM for CESM3.0.

For our planning it's important that we have an issue to track this. This is especially critical to meet the June 30th deadline that is looming for us. Our timelines are full to meet that deadline right now. Possibly we can have Sam Levis work on this but we will need to discuss in the CTSM SE team.

So @mvertens could you add an issue in MOSART regarding this? I'll add it to the above project board when you do. And we'll start discussing this in the CTSM SE group.

[billsacks]

@mvertens has done this - see #463 🎉