COSIMA / access-om2

Deprecated ACCESS-OM2 global ocean - sea ice coupled model code and configurations.
22 stars 23 forks source link

Ob runoff misdirected in new 0.1 deg topography #130

Open aekiss opened 5 years ago

aekiss commented 5 years ago

This is probably not an important issue but I thought it worth noting anyway. In #126 we removed the upper Gulf of Ob. It looks like some of the runoff that should go the the truncated Ob is being misdirected to Baydaratskaya Bay to its west, presumably because this is closer.

Here's the runoff with the old topography (/g/data3/hh5/tmp/cosima/access-om2-01/01deg_jra55v13_ryf8485_spinup6/output425/ocean/ocean_month.nc) screen shot 2019-01-26 at sat 26-1 3 21pm The Gulf of Ob has hit its regional cap of 0.001, which seems to have erroneously spread runoff into Baydaratskaya Bay to its west, but this is not the issue I'm concerned with (because I think it can be fixed by increasing the Ob regional cap).

Here's the runoff for the same month (and runoff caps) but with the truncated Ob (/short/v45/aek156/access-om2/archive/01deg_jra55v13_ryf8485_spinup6_newtopog/output427/ocean/ocean_month.nc) screen shot 2019-01-26 at sat 26-1 3 30pm Now we have runoff hitting the global cap of 0.03 in Baydaratskaya Bay, which I think means that runoff is being sent directly there from land points (rather than via the subsequent capping step). (We hit the global cap because the Ob cap doesn't extend into this bay.)

/g/data1/ua8/JRA55-do/RYF/v1-3/RYF.runoff_all.1984_1985.nc shows significant runoff at the head of the Gulf of Ob (e.g. see red dot): screen shot 2019-01-26 at sat 26-1 3 51pm which would be on land points in the new topography. Some of this seems likely to have been misdirected to Baydaratskaya Bay because it is closer than what remains of the Gulf of Ob.

Possible fixes (if we think this is important enough):

nichannah commented 5 years ago

I prefer the third option above because it is more general and shouldn't be too hard to implement - we just need to change our the distance measure used in the nearest neighbour calculation. However, we we have a file with land topography presently? I guess there is no harm in introducing one.

russfiedler commented 5 years ago

Doing proper river runoff is an art in itself and we would have to do it globally which could cause problems. If it's just a few points then it may be easier to read in the troublesome source points and direct them to a particular point on the target grid. Alternatively, we could override the position of the source point on the fly and place it near where we want it and then allow the default algorithm to do its thing. This also allows possible further land mask changes.

aekiss commented 5 years ago

We wouldn't need real land topography - just something that's flat nearly everywhere apart from a few "fences" (rough watershed boundaries) to restrict runoff remapping in the few places that need it.

aidanheerdegen commented 5 years ago

I seem to recall talking about this, or something similar, a while back. I seem to recall advocating having a masked/unmasked ocean, so the routing could be done with the unmasked version and the moved where appropriate after masking.

aekiss commented 5 years ago

For the related issue of runoff being spread to the wrong bay (first example above), is there a way to base the k-d tree distance measure on ocean-only paths? e.g. by heavily penalising paths that pass over land...?

russfiedler commented 5 years ago

@aidanheerdegen played around with this sort of stuff a while back. I think it would be too difficult/slow to implement everywhere in the kd-tree but if a point was found that had too much water going into it then a set of contenders that it would be possibly spread to can be found using the standard method. Let's say 2x the estimated number of ocean points. You could then use a modified form of Dijkstra's method to get the closest N points with some sort of modified metric. Now, how you handle the tripolar fold, that's another thing. Tricky.

aidanheerdegen commented 5 years ago

I've push some path finding code I worked on ages ago

https://github.com/aidanheerdegen/gridtools

the dev branch is probably the one to look at, but I honestly can't recall in what state it is. But I agree, this is not obviously easy.

Come to think of it, how is the runoff being redistributed now? Is it using the ocean grid directly? Couldn't we mask the runoff grid with the ocean grid, find all cells that aren't adjacent, or on, an ocean cell, and then use some connectivity tree to just assign that runoff to the closest connected ocean cell?

I did something very similar to identify isolated water bodies in this code

https://github.com/aidanheerdegen/gridtools/blob/master/waterdiviner.f90