Runoff not conserved

[aekiss]

Runoff isn't conserved. Plots below show the RYF JRA55do input data and what is reported by MOM6 for a 1deg run (ignore "m-2" in the units).

The global integral of liquid runoff shows a significant shortfall in MOM6, especially in SH summer, but also (weirdly) excess water in late August. The step at 1 May is the RYF join.

MOM6 total_frunoff is drastically smaller than JRA55do licalvf

Plot script: https://github.com/aekiss/access-eval-recipes/blob/ef120fa/ocean/runoff_budget.ipynb

Related: #208 (comment), #217, #37, ACCESS-NRI/dev_coupling#33 (comment)

[aekiss]

I'm not sure what happens when JRA55do runoff is located at land points in the model. Need to find out what routing is done (if any).

[aekiss]

Also need to check whether conservative regridding is used - see #37

[aekiss]

Here's log(friver) from JRA55do

and log(friver) from MOM - notice MOM is missing the Black Sea - where does this water go?

[aekiss]

Here's log(licalvf) from JRA55do

and log(ficeberg) from MOM

[aekiss]

Maybe we'll need to set these in nuopc.runconfig to map the runoff into the ocean?

     rof2ocn_ice_rmapname = unset
     rof2ocn_liq_rmapname = unset

[anton-seaice]

In https://escomp.github.io/CMEPS/versions/master/html/addendum/req_attributes_cesm.html?highlight=rof2ocn_ice_rmapname#mediator-mapping-file-attributes it says CMEPS will create an "online route handle" if those values are unset.

Whats the format of a "mapping file"?

It looks like the default is to do a first-order conservative remapping:

https://github.com/ESCOMP/CMEPS/blob/f4f64c324469c33a78e0118ce1dd7944e85521d6/mediator/esmFldsExchange_cesm_mod.F90#L2399

There are options for maptype when creating the remap online:

maptype determines the mapping type and can have values of:

mapbilnr: bilinear mapping
mapconsf: first order conservative mapping with normalization type of conservative fraction.
mapconsd: first order conservative mapping with normalization type of conservative fraction.
mappatch: patch mapping
mapfcopy: redist mapping
mapnstod: nearest source to destination mapping
mapnstod_consd: nearest source to destination followed by conservative destination
mapnstod_consf: nearest source to destination followed by conservative fraction

I don't know if one of those makes more sense ?

[anton-seaice]

ESMF seems to support remapping with masks, so maybe we need to include a mask in our mesh files ?

https://earthsystemmodeling.org/regrid/#options-for-masking-areas-unmapped-points-etc

[aekiss]

Thanks @anton-seaice, these (from https://earthsystemmodeling.org/regrid/#options-for-masking-areas-unmapped-points-etc) look like they may be suitable

• Nearest source to destination: The value of each destination point is set to the value of the closest source point.
• Inverse distance weighted average: The value of each destination point is set to the weighted average of the values of the N closest source points. The weight is the reciprocal of the distance of the source from the destination raised to the power P. The user can choose N and P, but defaults are also provided.

or from CMEPS

mapnstod_consd: nearest source to destination followed by conservative destination

[anton-seaice]

@gustavo-marques - We (ACCESS) are looking at options for how to make sure runoff is distributed into the ocean (and not land). Does CESM use an 'online' computation for remapping weights? Or are you using pre-computed mapping weights?

We are using this option for computing mapping weights online for liquid run-off:
mapconsd: first order conservative mapping with normalization type of conservative fraction.
but think maybe
mapnstod_consd: nearest source to destination followed by conservative destination
should ensure it gets mapped into the ocean ?

[gustavo-marques]

Hi @anton-seaice,
The runoff mapping files are still done offline in CESM. We use a combination of nearest-neighbor and smoothing mappings to distribute the runoff over a pre-defined radius and using an e-folding distance. Input parameters:

eFold = smoothing eFold distance in meters (default: 1000000)
rMax = maximum radius of effect in meters (default: 300000)

You can find out more about this procedure here.

[aekiss]

Thanks @gustavo-marques, it's great to have these details

[anton-seaice]

It's possible #240 will play into this - our DROF mesh file doesn't contain any cell areas and the CDEPS is not expecting one either

However we are definitely loosing lots of runoff in the mediator. From the mediator output, this is the difference between the rof and ocean diagnostics from the mediator.

We gain run-off in some cells but no where near enough to equal the amount which disappears.

Similarly the frozen runoff is mostly lost

Most of the runoff is being masked out. If the runoff is masked using the landmask and compared to the amount entering the ocean, the different is very small (but non-zero!)

And much closer to 0 in the frozen run off case

[aekiss]

We should prioritise fixing this, as it is blocking finalising the topography #172 (comment)

[aekiss]

@anton-seaice does it look like these tools will be suitable for us? https://github.com/ESMCI/cime/blob/master/tools/mapping/gen_mapping_files/runoff_to_ocn/README

[anton-seaice]

I am not sure, I think @kieranricardo has been trying something similar but different.

I am planning on just trying one of these mapping options in the short term:

mapnstod: nearest source to destination mapping
mapnstod_consd: nearest source to destination followed by conservative destination
mapnstod_consf: nearest source to destination followed by conservative fraction

[anton-seaice]

I think that changing the remapping option might not have the desired effect.

All regridding methods conserve the total volume of water (at least where there is no masking), see

https://earthsystemmodeling.org/docs/release/ESMF_8_1_0/ESMF_refdoc/node5.html#SECTION05012700000000000000

So we don't need to worry about how the choice of regridding might impact overall water conservation

They are also mask aware:

https://earthsystemmodeling.org/docs/release/ESMF_8_1_0/ESMF_refdoc/node5.html#SECTION050121000000000000000

However the total volume is not mapped on to unmasked cells - its mapped to all cells and then the mask is applied ( I think). (For example, there's nothing specified differently for rain which should be mapped to all cells vs runoff which only goes to ocean cells and lakes ). So the runoff mapped to land is still lost.

It turns out there are two places to specify remapping relevant here.

1. In the CDEPS component for drof, which specifies the remapping between the JRA mesh and the mediator mesh. This is configured in the drof "stream" file. (As an aside - the issue @aekiss highlighted above with more run-off into the ocean than in JRA55do - might be due to the time interpolation applied in this stream file - it's set to upper and maybe should be linear)
2. in the mediator - which specifies the mapping between the mediator mesh and the ocean mesh.

Depending on the configuration - the runoff can be mapped onto land (and therefore lost) at either place. With our current set-up it's lost in the second step. When mapped in the mediator from the rof import to the ocn export.

Changing the method in the mediator to mapfcopy conserves the total volume of runoff in the mediator however doesn't help in the end as its not a mask aware redistribution (all the other options actually do some remapping).

There is no implementation [2] in CMEPS for nearest destination to source regridding which is possible in ESMF - maybe this is what we wan't. However its not clear that the "nearest destination" would only be an unmasked cells.

[anton-seaice]

It looks like there is a few ways of generating remapping run-off forcings:

1. generating new versions of the run-off on the new grid. e.g.

GFDL has a method for producing remapped runoff files. It looks like this would produce a new version of the runoff file, with the runoff in the correct location for the provided grid. It seems to be based on the older mosaic grid format, so would need some work to be adapted to this circumstance.

There is also this python package developed for ORA grids/models, which looks comprehensive but hasn't been updated in three years :
https://git.geomar.de/open-source/runoff_remapping

2. access-om2 used an "online" remapping using a kdtree algorithm

Or the online remapping using a kdtree, which could be implemented in the mediator

https://github.com/ACCESS-NRI/libaccessom2/blob/f9f2d67a44554e15a477505ae1b8c5676e4c21f7/atm/src/remap_runoff_mod.F90#L5

3. the CIME tool:
   https://github.com/ESMCI/cime/tree/master/tools/mapping/gen_mapping_files/runoff_to_ocn

which looks ok but relies on grids in the SCRIP or pop-grid formats, so might need some adapting for us

[AndyHoggANU]

Thanks Anton - all good info.
My inclination is that we would prefer to stay away from option 1 (but it might be viable for an interim solution to allow testing with RYF forcing (this is what we do, and frequently get wrong, in regional-mom6).
My suspicion is that option 3 is probably best in the long term, the only issue being that we need a workflow to update mapping files every time we change the land-sea mask ...