Fout in balans Waal boven/benedenstrooms Maas-Waalkanaal

[DanielTollenaar]

Balans op Basin met node_id 223 lijkt niet te kloppen

Versie RWS-HWS model: 2024.3.0

reproductie

• Simulatie uitgevoerd volgens standaard instellingen (jaar 2020)
• Resultaten in results/flow.arrow geïnspecteerd met IMOD plugin en Pandas; beiden leveren hetzelfde plaatje
• resultaat:
  • +/- 2000 m3/s over edge 223 (Waal bovenstrooms). Plausibel gezien randvoorwaarde van 2750 m3/s
  • +/- 0 m3/s over edge 222 (Maas-Waalkanaal). Plausibel gezien opgegeven capaciteit Sleus Weurt van 1 m3/s
  • +/- 6000 m3/s over edge 224 (Waal benedenstrooms). Lijkt niet plausibel, gezien het gat van 4000 m3/s

Verwacht resultaat

Ongeveer 2000 m3/s over edge 224

[visr]

I see this but further downstream the flow gets much bigger still and also in the wrong direction.

I noticed all ManningResistance nodes have these parameters.

length	manning_n	profile_width	profile_slope
10000	0.04	10000	1

Here you are saying that the rivers are 10 km wide, leading to very low frictions and therefore a highly reactive system. Probably together with the chosen solver settings this leads to water balance issues. If I set the profile width to a more realistic 200 m it all seems to go much smoother already.

[DanielTollenaar]

Updating manning-params, length from adjacent edges and profile_width from an intersect with basin-areas is listed the todo's of issue #58. If that helps solving the issue, I'll fix that next week.

I think a water balance tool, usable for one of a set of basins, is helpfull in understanding the extent of the problem. If it doesn't exist in Python, I can write it.

But having a warning, or error, from the core in case balance errors get too large may be something to take into consideration?

[visr]

Yeah fully agree. It is on the radar with https://github.com/Deltares/Ribasim/issues/642.

[DanielTollenaar]

I've fixed this by parameterizing manning from basin \ Area and edge.length as listed in #58. Is fair; in hydraulic models storage and conveyance are both derived from cross-section profiles, now we do basically the same.

As we use an explicit scheme, I've increased fiction a bit more by choosing manning=0.05 (was 0.04) and linearResistance from 0.0005 to 0.005. Next stop; see if we can get an efficiënt model with an implicit scheme (new issue).

@visr; I've included a ManningResistance / line (or shall we call it profile_line?) manually as you see in the shot below. Not super-urgent but for similar reasons as Basin / area I suggest to accept it as an optional table in ManningResistance.

[visr]

Great that this helps. I might need some convincing on ManningResistance / line. The ManningResistance parameters take some representative profile that is not neccesarily any one actual profile, as well as a length in the flow direction.

At least as of https://github.com/Deltares/Ribasim/pull/1265 the QGIS plugin won't crash on extra tables anymore.

[DanielTollenaar]

OK, I do it for not crashing on extra tables 😄