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

[mvertens]

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 ESCOMP/CMEPS#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 ESCOMP/CMEPS#431 (comment)). 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.

This will be in conjunction with ESCOMP/CMEPS#437. The implementation will only be done on top of the PR #76

[ekluzek]

@mvertens thanks for adding the issue here we appreciate it.

It sounds like there have been extensive discussions on this with CISM that we were completely unaware of in our LMWG planning. It's good for us to be brought into the loop.

Pinging @slevis-lmwg

[ekluzek]

@mvertens one more question. I know you will be implementing this on top of #76 (which of course is the right thing for you to do for NorESM) -- but I think the changes here don't explicitly require it correct? I think the changes here are only going to be for MOSART to receive fields from CISM through CMEPS correct? So it's only working with the "plumbing" from NUOPC to MOSART. I just wanted to make sure I understood the scope of what this actually needs to do. Thanks in advance.

[billsacks]

@ekluzek I just talked with @mvertens about this. The issue is that the runoff from CISM will ideally be routed direct-to-outlet, and that will require some new, possibly extensive code for separately handling the CISM liquid runoff (since it sounds like there are hooks in place for routing ice directly to outlet but not for liquid, or at least not for having some liquid go directly to outlet while some is routed). So @mvertens anticipates needing to make fairly extensive changes and it makes sense for her to do those changes on top of #76 , since that's what is now being used in NorESM.

[ekluzek]

Ahhh, very good to know. Thanks for discussing with @mvertens and giving the update. We'll plan on making this a priority to come in ASAP after it's ready.

[ekluzek]

The plan right now is for @slevis-lmwg to bring this in following #76 when he has time that opens up. His priority right now is CN Matrix a critical capability needed by LMWG for the science capability/functionality freeze targeted for the end of the month.