Fout in de flow_rate on edges beneden en bovenstrooms Maas #172

[ngoorden]

Balans op Basin met node_id 172 lijkt niet te kloppen

Versie RWS-HWS model: 2024.4.2

reproductie

Simulatie uitgevoerd volgens standaard instellingen (januari 2020) Resultaten in results/flow.arrow geïnspecteerd met IMOD plugin en via Pandas (basin.arrow); beiden leveren hetzelfde plaatje

resultaat

+/- 400 m3/s over edge 297 (Maas-bendenstrooms). Plausibel gezien randvoorwaarde Eijsden grens #272 van 400 m3/s +/- 0 m3/s over edge 135 (Maas-bovenstrooms richting Borgharen ). Lijkt niet plausibel gezien randvoorwaarde Eijsden grens met node_id 272 van 400 m3/s +/- 0 m3/s over edge 136 (Maas-bovenstrooms richting Julianakanaal). Lijkt plausibel, gezien Limmel afgesloten is (pump met flow_rate 0)

verwachting

400 m3/s over edge 135 vanaf node_id 72 naar node_id 1 (Borgharen)

[visr]

I see LinearResistance 1 has a resistance of 0.005 s/m2. The water level difference between the two basins is around 20 meter. This would lead to a flow of 4000 m3/s. The initial storage in the upstream Basin is only 3000 m3. So it falls dry in less than a second.

So the resistance needs to be at least 10x higher. And the storage in the upstream Basin also sounds at least two orders of magnitude lower than I'd expect.

[visr]

The initial water level difference of around 20 meters is much too high. Why is the upstream level 36 and downstream 12 meter? Though I can imagine using a max_flow_rate to avoid a huge peak flow at the beginning helps here.

[DanielTollenaar]

@visr I see it as the chicken and the egg; you need a state to run a model, but you need a model-run to get a proper state. I estemated a basin/ state (here state_df) from basin/profile (here profile_df) 1m above lowest profile-elevation, but not lower than 0m NAP:

state_df = profile_df.groupby("node_id").min()["level"].reset_index()
state_df.loc[:, ["level"]] = state_df["level"].apply(lambda x: max(x + 1, 0))

The Meuse between just-upstream Borgaren and Linne (confluence with Kanaal Wessem-Nederweert) drops indeed roughly 20m.

Edit; running this simulation with Euler works a bit better

Edit2:

• crest-level of weir @ Borgharen = 39.7 m NAP (source: https://downloads.rijkswaterstaatdata.nl/rws_legger/dwarsprofielen/61F-004-01.html)
• crest-level of weir @ Linne = 17 m NAP (source: https://downloads.rijkswaterstaatdata.nl/rws_legger/dwarsprofielen/58D-353-01.html) So, ideed roughly 20m delta-head. Let's figure out how to deal with it best.

[visr]

Oh right, so the 20m is fine. But that still leaves the resistance 10x too low. The initial level is not so much the issue as the initial storage. But perhaps adjusting the resistance is enough.

I understand the chicken and egg problem. Ideally we'd support starting with steady state levels.

[visr]

Is there a reason you went with LinearResistance over a TabulatedRatingCurve for these nodes?

[DanielTollenaar]

Oh right, so the 20m is fine. But that still leaves the resistance 10x too low.

We noticed we get the model running with LinearResistance 0.05 s/m2. But with 3500 m3/s being design flow_rates, I suspect we run into other issues if we apply high flow_rates and 0.05 s/m2 resistance.

Is there a reason you went with LinearResistance over a TabulatedRatingCurve for these nodes?

Last January @gijsber and I decided to keep the schematization/parameterization as simple as possible; hence giving all structures (as Borgharen) unlimited flow capacity using LinearResistance with 0.005 s/m2.

Let's discuss to do something else, but hopefully keeping the schematization/parameterization as simple as possible (exact levels/volumes in upstream Meuse don't WRM perspective (shipping aside)). I've made an issue for that here: https://github.com/Deltares/Ribasim-NL/issues/82

[gijsber]

I think we have to go to some level controlled outlet in combination with a Qh-table for the moment the weir is down.

[visr]

But with 3500 m3/s being design flow_rates, I suspect we run into other issues if we apply high flow_rates and 0.05 s/m2 resistance.

Right. If a LinearResistance node gives 400 m3/s with a 20 meter level difference, it will need a 200 meter difference to give 4000 m3/s. I think that shows that this is not really the right node. It is more appropriate for open connections with smaller level differences, where flow can go either way.

[DanielTollenaar]

I think this issue gives sufficient input to improve error-handling-by-solver and we all conclude we need (to parameterize) other nodes for the Meuse. Let's got to #82; I close this one.