Apply multiple maps for ROF -> OCN?

[mnlevy1981]

I had a meeting with @ekluzek and others, discussing the process of making the runoff -> ocean maps used in CESM. Basically, we make two maps:

1. nearest neighbor runoff -> ocean. In ESMF parlance, I believe this is nearestdtos; we map each grid cell from the runoff (source) grid to the nearest ocean (destination) cell. We do this in an area-weighted fashion, so that the global integral of runoff is preserved (which might not be supported by ESMF yet?)
2. ocean -> ocean. This is a CESM-specific map where we smooth out the runoff over many cells; Brian Kaufman wrote the Fortran program that generates these maps, and I'm not entirely familiar with the algorithm but it does neat stuff like not spreading runoff from the Atlantic coast of Central America into the Pacific.

Multiplying the two sparse matrices representing the maps together results in the runoff -> ocean map used by the model. While discussing the process of generating new maps for MizuRoute, we realized that some of the offline work could be minimized if CMEPS could use the ESMF online nearest-neighbor mapping to get the runoff onto the ocean grid, and then apply the ocean -> ocean smooth map read in from a file. I have no idea if this is a feasible workflow, but it would mean (a) we only need to generate new mapping files when introducing a new ocean grid, (b) we only need one mapping file per ocean grid, and (c) we only need 1 of the 3 steps in Brian's tool (so generating the single new map would be much faster).

[billsacks]

I like this idea. There is some relevant discussion in #334. The target of that discussion is cases where you want only the nearest neighbor mapping without smoothing, but I see the value in what you suggest – having the nearest neighbor piece done at runtime and just the ocean -> ocean smoothing read in from an offline mapping file. The gist is that it should be possible to do this nearest neighbor mapping in CMEPS, but it will take a bit of care.

[mnlevy1981]

The target of that discussion is cases where you want only the nearest neighbor mapping without smoothing

It seems like that's a special case where you would specify the correct nearest neighbor option for the rof -> ocn portion and idmap for the ocn -> ocn portion. And, long term, I think that's what we want for MOM6 as well -- POP uses the smooth mapping for marginal seas, but the open ocean has an estuary box model that helps mix the river runoff with ocean water. MOM6 doesn't have any marginal seas, so once we port the EBM to MOM6 (or implement a similar feature) it will just need the nearest neighbor map without smoothing as well.