For multiple ice sheets: Need to address TODO notes in code to handle multiple glc2ocn runoff maps

[billsacks]

There are a number of TODO notes that I think still need to be addressed for multiple ice sheets, relating to the custom runoff mapping files for glc2ocn:

mediator/esmFldsExchange_cesm_mod.F90:
  2195:                 ! TODO: this custom map needs to be different for every ice sheet - how will this be handled?
  2214:                 ! TODO: this custom map needs to be different for every ice sheet - how will this be handled?
  2256:                    ! TODO: this custom map needs to be different for every ice sheet - how will this be handled?
  2276:                    ! TODO: this custom map needs to be different for every ice sheet - how will this be handled?

From setting up a B compset case with multiple ice sheets (--res f09_g17_ais8gris4 --compset 1850_CAM60_CLM50%BGC-CROP_CICE_POP2%ECO_MOSART_CISM2%AIS-EVOLVE%GRIS-EVOLVE_WW3_BGC%BDRD) it looks like we have made the necessary changes on the scripting / namelist generation side to handle multiple runoff mapping files (though we still have placeholders for the Antarctica maps: https://github.com/ESMCI/ccs_config_cesm/issues/3): We currently get a colon-delimited list of mapping files in nuopc.runconfig:

glc2ocn_ice_rmapname = /Users/sacks/projects/cesm-inputdata/cpl/gridmaps/ais8/map_ais8_to_gx1v7_nnsm_e1000r300_TOBECREATED.nc:/Users/sacks/projects/cesm-inputdata/cpl/gridmaps/gland4km/map_gland4km_to_gx1v7_nnsm_e1000r300_171105.nc
glc2ocn_liq_rmapname = /Users/sacks/projects/cesm-inputdata/cpl/gridmaps/ais8/map_ais8_to_gx1v7_nn_open_ocean_nnsm_e1000r300_marginal_sea_TOBECREATED.nc:/Users/sacks/projects/cesm-inputdata/cpl/gridmaps/gland4km/map_gland4km_to_gx1v7_nn_open_ocean_nnsm_e1000r300_marginal_sea_171105.nc

But it looks like the Fortran side of CMEPS isn't set up yet to handle these multiple mapping files.

(As a side note, there is also a TODO note in med_diag_mod.F90 related to multiple ice sheets... there may be others as well, but those are the ones that I found from a regex search for "TODO.*ice".)

FYI @mvertens @Katetc @whlipscomb @gunterl

[billsacks]

@mvertens and I were just talking about whether we could change the system to go GLC -> ROF -> OCN rather than directly GLC -> OCN. Doing so would let us remove these problematic GLC -> OCN mapping files entirely. I dug up an old email discussion on this:

From me September 25, 2017:

Hi Bill [Lipscomb], Keith [Lindsay] and Mike [Levy],

I dug up my notes from 4 years ago describing why we went with the solution of direct glc -> ocn mapping rather than going glc -> rof (or glc -> lnd -> rof). Jeremy was leading this effort scientifically. It turns out that Jeremy's original plan was to go glc -> rof or glc -> lnd -> rof, but Tony Craig talked us out of that. The main reason was the question Keith brought up today: Would you ever want a situation where you have active ocn and active glc, but drof? Even though we currently don't have that in CESM, I could envision that as a potentially useful compset for developing ice-ocean coupling, where you force the ice sheet with some prescribed SMB via dlnd. Tony pointed out that that won't be possible if your data flow requires an active rof sitting between glc and ocn, and he urged us to remove the middle-man in order to keep more flexibility in terms of how CESM can be configured.

Other downsides I started to feel about changing the coupling to glc -> rof -> ocn:

(1) The up-front implementation cost will be greater than some of the other options (probably 1-2 weeks to implement and test it: this requires some pretty significant changes in the coupler as well as some small changes in CISM)

(2) It's a big enough change to the system that it feels riskier than some of the other options: I could imagine some unhandled edge cases going undetected for a while, which makes this feel riskier as we get close to a release (maybe).

(3) Allowing backwards compatibility with the way (I think) ACME currently operates could result in some complexity.

Of course, an important factor is what is best scientifically. My sense from today's discussion is that glc -> rof -> ocn is somewhat better scientifically, but probably not hugely so. Bill & others, do you agree with that assessment?

If that's right, then my current feeling is to go with one of the other options. I'm coming around to the idea of having a second set of mapping files used just for glc -> ocn liquid, if the process for creating those truly isn't too difficult.

Please let me know if you have any thoughts – or if you'd like a follow-up in-person meeting to discuss this further.

Thanks, Bill S

From Bill Lipscomb September 26, 2017:

Hi Bill,

Thanks for following up. I had a feeling that the solution we talked about yesterday was too easy to be true. I agree with you and Tony that we don't want to be locked into always using active rof when we have active ocn and glc. I also agree that glc -> rof -> ocn is somewhat better scientifically than the alternatives, but not hugely so. I'm OK with having a second set of mapping files for glc -> ocn liquid.

Let me also toss out an idea for the longer run. Would it be possible to abstract the part of the runoff model that receives a geopotential field (typically surface elevation, but it could also be a fluid potential) and outputs a map of the downstream cell (adjacent to the ocean) corresponding to each input cell? If so, maybe this chunk of the runoff model could live in shared code where it would be accessible to other components. Even better, it could be designed to be called at runtime, so that it could handle a dynamic ice sheet.

I don't see this as an immediate priority, but it seems more like the way things ought to be done scientifically.

Thanks,

Bill L.

However, these decisions were all made in the cpl7 world, where we needed to create offline mapping files anyway. Now that the runoff maps are significantly harder than others, I think it's worth revisiting this discussion. The main question is whether it would be helpful to preserve the ability to have a configuration with active OCN & active GLC but DLND and DROF. That was viewed as a possibly useful configuration in our discussions in 2013 and 2017. But if that no longer seems to be a likely configuration, then it seems like a good idea to change this to go GLC -> ROF -> OCN, removing the need for GLC -> OCN mapping files. Note that this would make this current issue a moot point.

[billsacks]

@whlipscomb and others would really like to get away from the combinatorics of the glc -> ocn runoff fluxes.

@whlipscomb raised the question of what would happen with melt of floating ice shelves. It feels like we might 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.

[billsacks]

In discussion today, we decided to change the GLC runoff routing to go to ROF rather than OCN. This makes this issue irrelevant, but leads to the need for #437 .