routing in shyft

22 views
Skip to first unread message

Felix Matt

unread,
Sep 29, 2017, 8:42:26 AM9/29/17
to sh...@googlegroups.com
Hi,

I have a question related to the routing parametrization in Shyft. Is it
possible to route the discharge from a single cell? I thought it should
- but I tried it and it seems like routed discharge equals unrouted
discharge for a single cell.

Background to this question is that we try to do a benchmark test of
Shyft models against the CAMELS datasets
(https://ncar.github.io/hydrology/datasets/CAMELS_timeseries). Since the
benchmark data uses lumped models, I would like to use Shyft stacks as
well as lumped models (meaning just as a single cell model). This
requires to include some kind of routing parametrization on a single cell.

All the best,

Felix

Sigbjørn Helset

unread,
Sep 29, 2017, 1:37:08 PM9/29/17
to sh...@googlegroups.com, Felix Matt
Hi, Yes, routing from cells to river network, and then cascading downstream network.

It's a while since i completed the work, but I guess it's something with the parameters /setup?
Maybe we should make a single cell case, a catchment with one cell?
I think there was a test using the feature?

Sendt fra min Sony Xperia™-smarttelefon

---- Felix Matt skrev ----
--
You received this message because you are subscribed to the Google Groups "shyft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shyft+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shyft/489ebbc0-bddf-4257-1d4b-48ab2f51f021%40geo.uio.no.
For more options, visit https://groups.google.com/d/optout.

Felix Matt

unread,
Sep 29, 2017, 1:40:25 PM9/29/17
to sh...@googlegroups.com

Hi Sigbjørn.

ok, thanks, god to know. I can set up a single cell test (I'm aware of the multi-cell nosetest) and will share it with you, so you can review it in case it's not working how i set it up.

Best,

Felix

Felix Matt

unread,
Oct 3, 2017, 4:21:45 AM10/3/17
to sh...@googlegroups.com

Hi,

I created a test with a single cell. I ran it with a daily time step. Seems like if I use a short hydro length, routing doesn't have any impact, routed and unrouted discharge (river_local_inflow_m3s  and river_output_flow_m3s) are exactly the same, double by double (is that what one would expect?). If I choose the river to be sufficient long in terms of hydro length, then I get a difference in routed VS unrouted discharge.

Another question is:

Are routing parameters (alpha, beta, velocity) available for calibration? I see that I can access them as region_parameter, e.g.

params = region_model.get_region_parameter()

params.routing.alpha

but I set up a test and run a calibration and it does not seem that the region_parameters for routing have any impact on the simulation. How do these region_paramers interact with what is set up for a certein river in the river network?

Might be that I don't understand the complete concept of how routing is implemented. Are there any publications describing the approach?

All the best,

Felix



On 29. sep. 2017 19:37, Sigbjørn Helset wrote:

Felix Matt

unread,
Oct 3, 2017, 12:42:16 PM10/3/17
to sh...@googlegroups.com

Hi,

again to routing in shyft... I have the feeling that there's a small bug, but please review ...

If I use shyft API functionality to create a UHG, the "api.make_uhg_from_gamma" function returns an array with length i-1 when the step_n parameter is i for i > 1.

Shouldn't it return a array with length i (except when i=0)?

E.g.: the first parameter passed in the function is the step_n parameter, here evaluated for step_n = 0,1,2,3

api.make_uhg_from_gamma(0, 1,1).to_numpy() -> array([ 1.]) # that should be correct, no delay

api.make_uhg_from_gamma(1, 1,1).to_numpy() -> array([ 1.]) # should also be correct, no delay

api.make_uhg_from_gamma(2, 1,1).to_numpy() -> array([ 1.]) # here I would expect an array with length 2

api.make_uhg_from_gamma(3, 1,1).to_numpy() -> array([ 0.66666667,  0.33333333]) # here I would expect an array with length 3.

The "step_n" parameter is calculated from the hydrologic length of the river, the velocity, and the timestep dt:

step_n = int((distance / velocity) / dt + 0.5) # rounded int

e.g. from a river length of 2000 m length, with a velocity of 1 km/h, and 1 h timestep, I would expect that routing should have an impact.

however, this results in step_n = 2, so that make_uhg_from_gamma returns an array with size 1 and no routing happens.

The reason for this is a for-loop in https://github.com/statkraft/shyft/blob/master/core/routing.h#L405 that stops too early.

I think it should rather be sth like

for (double q = d;q <= 1.0; q += d) { etc...

or

double small = 1.0E-10;

for (double q = d;q < 1.0+small; q += d) { etc...


It would be nice if someone could review this. I can also create a pull-request...


Best,

Felix

sigbjorn.helset

unread,
Oct 3, 2017, 5:27:07 PM10/3/17
to shyft
Hi,

Daily timesteps is pretty long, so make sure your routing constants are in the order of magnitude of days if you want to observe significant differences.
(Try with the notebook example, using the concvolve ts to verify, then you have closed loops that does not require any time-consuming 
computation to figure out the length/shape parameters).


The routing parameters is used to form a unit hydro-graph (uhg) with a certain timelength, 
for each routing step,

1. cell to 1st river
2  1st river to next downstream river etc.

The uhg is used together with the convolve function ts to shape and delay the water-flow.

So from the cell and down to the first river, typically all cells in a catchment, 
you can shape the delay and flow.  (There is a separate notebook example showing how the uhg and  convolve ts works.)

Each river takes flow from any connection cell (lateral flow), and at its top it takes input from upstream rivers.

Water inserted into the river is then shaped by a river uhg, from input to output (river can be connected to downstream rivers).

Now, for the calibration, 
Calibration usually relates to catchments, or sum of catchments.

When we introduced routing, we also introduced calibration to river-id (each river have a unique river-id, similar to catchment id).

So when setting up calibration, make sure to use river-id based targets. The target time-series should match the expected output at river-id you relate it to.

The PR that had the original first effort 

and further on the calibration/parameters:


I can also provide you with the doc/spec from Yisak that was used to form these mechanisms.

Br Sigbjørn

sigbjorn.helset

unread,
Oct 3, 2017, 5:43:29 PM10/3/17
to shyft
To the uhg:
Having a convolution with two bin does not make sense I think. My tip is to use odd-numbers 5-7-... 
(There are currently no life-belts yet to these functions :-) )

I can have a second check on the examples and tests that's already in there to see if there is non-intended roundings etc.

Also observe the hints in the PR regarding start/end effects to the convolution.


Br Sigbjørn

sigbjorn.helset

unread,
Oct 3, 2017, 6:21:34 PM10/3/17
to shyft
.. and looking at the results of make_uhg_from_gamma, 
I think this need some more work,
-- which is already announced in the header file reading the doc.. 
I think the intention was to use a flexible
function, like gamma, to make the shape of the uhg, but I guess we should do some more
work in order to provide some useful parameters that gives a reasonable uhg.

Can you provide a uhg that you want to  use,(5..7..9..11 steps long) 
- so can I have a look into to how it can be shaped using gamma function or similar ?

Br Sigbjørn
Reply all
Reply to author
Forward
0 new messages