Strange spreading of liquid runoff in 25km OM3?

[chrisb13]

At the rOM3 panan hackathon recently (@claireyung @willaguiar @adele-morrison @chrisb13 @helenmacdonald ) have found that liquid runoff is being spread in an unusual way in the 4km panan rOM3 configuration.

This issue is to prompt @ACCESS-NRI/ocean team to check that this issue does not arise in the 25km (or other) OM3 configurations.

[anton-seaice]

The issue is that the JRA grid is 0.25deg (mercator projection?) and the model grids are higher resolution. So cells in the JRA grid have several cells in the model grid and therefore when doing a conservative remapping the runoff is spread around the model cells.

The suggestion to only send runoff to exact coastal cells is an interesting problem - presumably the ocean cells can be found by first running some sort of edge detection algorithm to find ocean cells which have at least one side which touches land, and then only remap to those cells.

This is kind of the opposite to the general runoff spreading we talk about - e.g. for the big rivers, we could have more spreading that we currently have.

[adele-morrison]

This is what was done in ACCESS-OM2:

YATM is also responsible for remapping river runoff in real time. This is done separately from the other forcing fields because it is difficult to do in a distributed memory setting, since ensuring runoff is on coastal points may require inter- process communication. Remapping is done in two steps: first runoff is moved to the destination grid using conservative interpolation, and then it is distributed from land to coastal points using an efficient nearest-neighbour algorithm based on a pre-computed k-dimensional tree (k-d tree) data structure (Bentley, 1975). We use the KDTREE2 Fortran k-d tree implementation (https://github.com/jmhodges/kdtree2, last access: 21 January 2020). The k-d tree is also used to conservatively spread runoff into the neighbouring ocean grid points to ensure it does not exceed a prescribed cap. ACCESS-OM2 and ACCESS-OM2-025 use a runoff cap of 0.03 kg m−2s−1 globally. In ACCESS-OM2-01 there are reduced caps of 0.001 and 0.003 kg m−2 s−1 at the mouths of some Arctic rivers to produce broader spreading and avoid excessively low salinity and a cap of 0.03 kg m−2 s−1 everywhere else.

[chrisb13]

Thanks Adele, if anyone else is wondering, looks like it came from here, p408.

[anton-seaice]

For future Anton:

The target for the remapping could be cells which are ocean but adjacent land and they can be found by doing a "binary_dilation" of the land cells and then subtracting the land cells

[chrisb13]

Sounds a bit like the "contract" command in photoshop ;)

Any thoughts on how this is causing the 4km panan rOM3 issue?

[anton-seaice]

Any thoughts on how this is causing the 4km panan rOM3 issue?

Just that the grid cells in jra55 (55km) are much bigger than the ones in "high" resolution grids, so sometimes there a multiple target cells in one jra55 cell.

[adele-morrison]

Can we implement code to move it to the nearest coastal cell?

[anton-seaice]

Yeah will do - is it a priority for some project?

There are three runoff related things to look at together:

• putting basal melt/liquid runoff at the coast
• spreading iceberg melt
• spreading the three biggest rivers (I think its the Amazon, the Nile and the Sea of Okhotsk but needs confirming)

[aekiss]

Other Arctic rivers such as the Ob and Mackenzie may also need spreading in the spring melt season

[chrisb13]

is it a priority for some project?

At a guess..

• @claireyung panan rOM3 I guess?
• perhaps this?
• @helenmacdonald anything?

Please add configuration tags as appropriate.

So it's not an issue in the 100km or 25km?

[adele-morrison]

Definitely a priority for the 8km global config.