Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ob runoff misdirected in new 0.1 deg topography #130

Open
aekiss opened this issue Jan 26, 2019 · 7 comments

Comments

@aekiss
Copy link
Contributor

commented Jan 26, 2019

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):

  • reinstate some of the upper Ob to catch this runoff
  • move the runoff closer to the truncated Ob in the JRA forcing files
  • making the runoff remapping take land topography into account
@nichannah

This comment has been minimized.

Copy link
Contributor

commented Jun 9, 2019

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

This comment has been minimized.

Copy link

commented Jun 11, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2019

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

This comment has been minimized.

Copy link

commented Jun 11, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.