For GLC runoff fluxes: change a flag so that these fluxes are kept separate from LND-derived runoff

[billsacks]

@mvertens is making changes in CESM so that solid & liquid runoff fluxes from CISM are routed to the runoff model rather than directly to the ocean. Currently, for backwards compatibility, she is making the default behavior be that these runoff fluxes from GLC get combined with the other runoff terms in MOSART so that the ocean gets the combined fluxes that it already imports in its cap. However, at the request of @gustavo-marques, the long-term behavior will be for the GLC-derived runoff fluxes to be routed separately through MOSART and then kept separate in the mediator, so that MOM can distinguish between GLC-derived runoff and LND-derived runoff for the sake of enthalpy calculations and diagnostics.

@mvertens is putting a flag in MOSART to control this behavior - dictating whether the GLC-derived fluxes should be combined with or kept separate from the LND-derived runoff fluxes. Once MOM's cap is updated to accept the new GLC-derived runoff fluxes (https://github.com/NCAR/MOM6/issues/281), we should change this flag for CESM so that the GLC-derived fluxes are kept separate. However, @mvertens thinks that NorESM may want to keep these combined, so we'll need model-dependent logic controlling this (maybe via an xml variable).

[billsacks]

I have heard from Michele Petrini that NorESM wants to keep the GLC fluxes separate from the LND fluxes, too, so that will make this change easier: the default can change for both systems, at least long-term. (It's possible that the default will still need to differ short-term depending on when the two ocean models can handle these separate fluxes.)

[ekluzek]

Thanks for pointing this out @billsacks. This is also something that we'll want to track for mizuRoute. However, there I think it will be done much later as a post CESM3.0 activity. It would be part of the work that will happen to get mizuRoute connected to the fully coupled model.

I also assume we wouldn't do this for RTM for Paleo work? Since combining the two is still functional I think we just shouldn't allow RTM to run this way.

Since, this is something that all ROF models have to know about -- I suggest having an XML variable with a generic name like:

ROF_SEPARATE_GLC_FLUX_FROM_LND

Does that make sense? That way initially both RTM and mizuRoute will query it and if set will abort with an error. And this way the same variable is used by all ROF models.

Pinging @slevis-lmwg

[mvertens]

@ekluzek - I think it will be awkward for mosart to handle this one way and the other river components to handle it another way. At this point there is a simple implementation in MOSART that easily permits this behavior. I propose for now to keep it separate and not introduce a new xml variable that will effectively accomplish the same thing.

[ekluzek]

@mvertens I don't understand what you are saying here, can you explain more? The point I'm making is how we are going to take care of this in both RTM and mizuRoute? I don't think either one is going to do this right away. And I don't think we are going to be able to put the MOSART solution you have into both RTM and mizuRoute at the same time. Maybe what you are saying is that RTM and mizuRoute shouldn't have a way to change the behavior and should always handle them separately? The thing there is that I don't think we'll be able to do this in mizuRoute immediately. Which is why having a variable for saying that mizuRoute can't do the separation seems important to me.

I'm also assuming that both the ROF model and MOM will need to use the same XML variable in order to coordinate what happens. As such it makes sense to me that the variable name that MOM will use would be a generic name that is recognized by all ROF models -- which means it needs to be generic.

I might be missing something and/or this might be something that we need a few of us to discuss.

[billsacks]

I agree with @mvertens : I think it's going to add too much complexity to the system to try to support both ways of doing things. This flag may be needed in the very short-term (e.g., for the next month or so) until MOM can handle the separate fluxes, but after that we should assume that the river models are separating the glc from lnd runoff fluxes, since that's what MOM will expect.

That said, there are some things that I think can address your concerns, @ekluzek :

First, keep in mind that this is only relevant for cases with evolving ice sheets. So in the near-term, mizuRoute – and maybe RTM – can get away with just confirming that the runoff fluxes received from GLC are 0 everywhere, and if not, abort... i.e., essentially confirming that you're not trynig to run mizuRoute or RTM in a case with evolving ice sheets.

Second, even if MOM is expecting separate runoff fluxes from GLC vs. mizuRoute, and even in a case with evolving ice sheets that generate these GLC runoff fluxes: I suspect that, at least initially, you could get away with combining them into a single runoff flux to send to the ocean. i.e., the river model would lie to MOM and tell it that all of the runoff was coming from the land model, not the glc model. That would make MOM's diagnostics wrong (if it has diagnostics separating the two), and eventually would make enthalpy calculations wrong (but those aren't implemented yet), but would at least conserve water.

To try to restate this more concisely:

• Once MOM implements accepting the runoff fluxes from GLC, we shouldn't have any toggle flags.
• For now, RTM and mizuRoute can just confirm that fluxes from GLC are 0
• Ideally, once RTM or mizuRoute accept non-zero fluxes from GLC, they should route these separately so that they're sending non-zero from-GLC fluxes to the ocean
• But it would probably be acceptable for some time for RTM and mizuRoute to merge the from-GLC and the from-LND fluxes, telling the ocean that the from-GLC fluxes are 0.

[mvertens]

@billsacks - thanks so much for adding this. I've been thinking that there is another simple way to go as well. The mediator is written so that it can accept either separate fluxes glc fluxes from the rof component or a total sum of runoff. Currently, mosart decides what it will send based on its namelist. But what if mosart always sends separate fluxes of glc runoff - and depending on what the ocean component advertises the mediator can sum everything up to send to the ocean (providing current backwards compatibility) - or it can send separate fluxes to the ocean. That way a new xml variable does not need to be introduced and mosart doesn't even have to have a new namelist variable.

The logic in esmFldsExchange_cesm.F90 can look like this for the liquid runoff:

       if ( fldchk(is_local%wrap%FBImp(comprof, comprof), 'Forr_rofl_glc', rc=rc)) then
         if (fldchk(is_local%wrap%FBExp(compocn), 'Forr_rofl_glc', rc=rc)) then
           ! Send separate liquid runoff from glc to mosart to ocn
           if (trim(rof2ocn_liq_rmap) == 'unset') then
             call addmap_from(comprof, 'Forr_rofl_glc', compocn, mapconsd, 'one', 'unset')
           else
             call addmap_from(comprof, 'Forr_rofl_glc', compocn, map_rof2ocn_liq, 'none', rof2ocn_liq_rmap)
           end if
           call addmrg_to(compocn, 'Foxx_rofl_glc', mrg_from=comprof, mrg_fld='Forr_rofl_glc', mrg_type='copy')
         else if ( fldchk(is_local%wrap%FBExp(compocn), 'Foxx_rofl' , rc=rc)) then
           ! Add liquid runoff from glc to mosart to total liquid runoff from ocean
           if (trim(rof2ocn_liq_rmap) == 'unset') then
             call addmap_from(comprof, 'Forr_rofl_glc', compocn, mapconsd, 'one', 'unset')
           else
             call addmap_from(comprof, 'Forr_rofl_glc', compocn, map_rof2ocn_liq, 'none', rof2ocn_liq_rmap)
           end if
           call addmrg_to(compocn, 'Foxx_rofl', mrg_from=comprof, mrg_fld='Foxx_rofl_glc', mrg_type='sum')
         end if
       end if

[ekluzek]

That makes sense to me @billsacks and @mvertens. Having all the options handled in CMEPS just based on the variables that both the ROF model and OCN model can handle does seem ideal. That's an example of the power of using ESMF/NUOPC in our models.

[billsacks]

This sounds great @mvertens - thank you!

[ekluzek]

@mvertens and @billsacks there was a namelist flag to trigger this behavior in #94, is that going to come back in a future PR, or is it always going to be separated? I suppose MOM will need to change to allow both, and it won't care if MOSART always send it separated. I did think that having an option to do it allows more flexibility and an easier transition -- but it doesn't absolutely need a namelist flag.

But, if there won't be a namelist flag -- we should likely adjust the title of this issue and possibly the top content.

[billsacks]

Good point, @ekluzek - my understanding is that @mvertens decided to drop this namelist flag in preference for a simpler solution. My feeling is that extra flags like this just cause more long-term maintenance burden if they aren't really needed. So actually I think the right thing to do at this point is to just close this issue.