Bouw RIBASIM model met default parameters

[d2hydro]

• aanmaken basin nodes
• maken Basin / profile tabel met storage area level kolommen
• maken TabulatedRatingCurve nodes (op linkjes tussen LSWs)
• maken TabulatedRatingCurve tabel met discharge en level kolommen per knoop
• maken FractionalFlow knopen op bifurcaties
• maken FractionalFlow / static tabel met fraction kolom
• maken ManningFriction knopen (+ tabellen) tussen basins zonder TRC
• maken LevelBoundary knopen en friction (+ tabellen) aan benedenstroomse basins

[d2hydro]

@visr, we missen t.o.v. aangeleverde RIBASIM LHM test-model de node-types LevelControl en LinearLevelConnection in de Julia-code en de documentatie (https://deltares.github.io/Ribasim/core/usage.html).

Zijn die vervallen?

Als zo, hoe kunnen we ervoor zorgen dat een peil gehandhaafd wordt in peilgestuurde gebieden?

[gijsber]

Hoi @d2hydro LinearlevelConnection is hernoemd tot LinearResistance.
Omdat de vorige versie van LevelControl niet echt leek te doen wat we willen, is hij even verwijderd. De komende maand gaan we een nieuw concept ontwikkelen en implementeren

[visr]

Een combinatie van een LinearResistance en LevelBoundary doet precies wat de oude LevelControl node deed.

[d2hydro]

@visr in reactie op #5 (comment);

• kan er beneden strooms van en LevelBoundary dan ook weer een basin liggen en wordt het water dan getransporteerd óver de LevelBoundary, of raak je het dan kwijt?
• LinearResistance mist als in de usage-docs; zie hieronder de tabel uit het basic-transient model; is de kolom resistance de conductance in m2/dag?

[visr]

Nee, water wordt niet over de LevelBoundary getransporteert, het is echt een randvoorwaarde. Het kan wel om meerdere basins aan heet LevelBoundary te koppelen, die delen dezelfde randvoorwaarde.

Ik zie inderdaad dat de LinearResistance mist, heb er een issue voor aangemaakt: Deltares/Ribasim#268

De formule is q = (h1 - h2) / resistance. q is m3/s. Dus resistance is s/m2.

[d2hydro]

We hebben nu alle Node:type == Basin knopen aangemaakt met bijbehorende profielen (Basin / profile) . Profielen hebben we, waar mogelijk, gelezen uit:

• data\lhm4.3\dm\txtfiles_git\nds.txt (dm-knopen)
• data\lhm4.3\mozart\mozartin\ladvalue.dik (lsws, storage berekend op basis van level en area)
• data\lhm4.3\mozart\mozartin\vadvalue.dik (lsws, level berekend op basis van volume en area en de lsw:DEPTH_SF_W)

We gaan ervan uit dat tussen elke Basin minimaal nog een ander type knoopje moet liggen dat de flow tussen de basins beschrijft.

[visr]

Mooi! Heb je voor de profielen ook gekeken naar de simplified NetCDF? De profielen van LSWs in de Mozart data leken niet altijd goed. De QH relaties staan ook in de simplified NetCDF.

We gaan ervan uit dat tussen elke Basin minimaal nog een ander type knoopje moet liggen dat de flow tussen de basins beschrijft.

Inderdaad, voor peilgestuurde gebieden is dat typisch een weerstand (LinearResistance of ManningResistance), en voor vrij afwaterend een TabulatedRatingCurve.

Voor de profielen gaan we trouwens nog de storage eruit halen, omdat dat zoals je zegt kan worden berekend op basis van level en area. (Deltares/Ribasim#225)

[d2hydro]

Heb je ook de methode/scripts waarmee deze gesimplificeerde tabellen zijn gemaakt? Probleem is dat wij andere LSWs hebben, waarschijnlijk LHM4.3 versus <LHM4.3 ofzo. Zo kunnen we ze zelf berekenen.

Tabellen van DM-knopen zien er ook niet allemaal fris uit, dus daar moeten we ook nog even naar kijken.

[d2hydro]

Andere topic; we zien dat tabellen worden gekoppeld aan de Node layer via de fid. Ik ben bang dat dat problemen op gaat leveren. Stel ik doe:

gdf = gpd.read_file("model.gpkg", layer="Node")
gdf.sort_values(by="type, inplace=True)
gdf.to_file("model.gpkg", layer="Node")

Dan kloppen volgens mij alle tabellen die aan Node hangen (dus alle tabellen :-) niet meer met de Node-indices; gdf.to_file doet namelijk een reset_index.

Ik ben fan van een expliciete index kolom, deze kan ik bij het lezen als index aanwijzen. Bij schrijven wordt dat automatisch een extra kolom

[visr]

Ik ben fan van een expliciete index kolom

Ken je de fid_as_index optie? e.g. gpd.read_file(path, layer=layername, engine="pyogrio", fid_as_index=True)

Heb je ook de methode/scripts waarmee deze gesimplificeerde tabellen zijn gemaakt?

Ik heb je een mail gestuurd met een download link / meer info.

[d2hydro]

Hi @visr, we begrijpen iets niet óf er zit een foutje in het geleverde ribasim-model:

Ik had hier 267 verwacht i.p.v. (Basin / profile):

Immers, Node:fid == 267 is een Basin en 268 is een water-user:

Klopt het dat "Basin / profile":node_id moet koppelen aan Node:fid?

En als dat zo is, klopt het dat dit een foutje is, of zie ik toch iets over het hoofd?

[visr]

Dat klopt, dit lijkt inderdaad op een foutje.

[d2hydro]

@visr, kun je helpen dit model draaiend te krijgen: https://we.tl/t-XFOxS2plwb?

We hebben nu eerst even allen Flevoland gedaan, zodat we relatief snel kunnen kijken of de knoopjes goed liggen:

[visr]

Nice! Ik heb er even een ribasim_model.toml naastgezet met

starttime = 2020-01-01 00:00:00
endtime = 2021-01-01 00:00:00
geopackage = "ribasim_model.gpkg"

En dan met ribasim ribasim_model.toml met de laatste nightly ribasim gestart.

Ik krijg eerst een error: no such column: edge_type. Dat komt omdat er afgelopen week "control" edges zijn toegevoegd. Dus ik heb aan de Edge tabel een edge_type kolom met alle waardes "flow" toegevoegd. Als je ribasim-python update zou dat vanzelf moeten gaan.

Daarna krijg ik een aantal network validation errors. Een deel daarvan is volgens mij onterecht, zie Deltares/Ribasim#327.

De andere zijn wel een netwerk issue:

┌ Error: Cannot connect a ManningResistance to a FractionalFlow (edge #2 from node #139 to #140).
│ Cannot connect a ManningResistance to a FractionalFlow (edge #4 from node #139 to #141).
│ Cannot connect a FractionalFlow to a LevelBoundary (edge #5 from node #141 to #136).
│ Cannot connect a ManningResistance to a FractionalFlow (edge #6 from node #139 to #142).
│ Cannot connect a FractionalFlow to a LevelBoundary (edge #7 from node #142 to #132).

De level based knopen (ManningResistance en LevelBoundary hier) zijn bidirectional, en de FractionalFlow is alleen maar 1 kant op. Als je vanuit een Basin naar meerdere LevelBoundaries wilt connecten, dan kan je verschillende Resistances ertussen zetten. Of wellicht wil je wat anders hier.

[d2hydro]

OK, leest logisch, maar voor de check:

• FractionalFlow is alléén nodig wanneer ik 1 basin wil koppelen aan meerdere basins en deze basin discharged via een TabulatedRatingCurve.
• In het geval van basin 134, die ik wil koppelen aan 132, 133, 136 en 137 (ijsselmeer aan randmeren) met manning-resistance, mag ik geen FractionalFlow knopen te gebruiken, kan ik dit zo doen:
  • 134 -> manningResistance -> 132
  • 134 -> manningResistance -> 133
  • 134 -> manningResistance -> 136
  • 134 -> manningResistance -> 137
    (uiteraard gaan al die node_ids straks weer veranderen :-))

[visr]

FractionalFlow is alléén nodig wanneer ik 1 basin wil koppelen aan meerdere basins en deze basin discharged via een TabulatedRatingCurve.

Klopt, want de TabulatedRatingCurve bepaalt dan de Q die de FractionalFlow kan verdelen. Je kan hier trouwens ook twee TabulatedRatingCurve, met eigen Qh relaties op de Basin zetten en zo het water verdelen.

In het geval van basin 134

Precies.

[d2hydro]

@visr; hierbij een nieuwe GPKG voor Flevoland: https://we.tl/t-PqQkYyLXNv.

Deze comments zijn verwerkt: #5 (comment)

[visr]

Thanks. Ik zie nog wat issues, bijvoorbeeld met de profielen:

Docs:
https://deltares.github.io/Ribasim/core/usage.html#basin-profile
Data:

Er mist een node_id, en de level moet een REAL zijn. Storage is overigens ook niet meer nodig nu.

Gebruik je (de main branch van) ribasim-python? Want die valideert de tabellen volgens de schemas. Er mist in de static tabellen bijvoorbeeld een control_state text kolom. Die mag verder leeg zijn.

[d2hydro]

Thanks. Ik zie nog wat issues, bijvoorbeeld met de profielen:

Docs: https://deltares.github.io/Ribasim/core/usage.html#basin-profile Data:

Er mist een node_id, en de level moet een REAL zijn. Storage is overigens ook niet meer nodig nu.

Gebruik je (de main branch van) ribasim-python? Want die valideert de tabellen volgens de schemas. Er mist in de static tabellen bijvoorbeeld een control_state text kolom. Die mag verder leeg zijn.

OK, jij wint :-): nu netjes gebouwd met de Ribasim python-module; kwam bovenstaande, en meer, issues inderdaad tegen: https://we.tl/t-YwDIrQp5P2

[visr]

Ha mooi, dit komt de validatie inderdaad door. Alleen krijg ik een error omdat ManningResistance eigenlijk alleen tussen basins werkt, en niet tussen Basin en LevelBoundary. Je zou die (of alle) resistances kunnen vervangen door LinearResistance voor nu.

[d2hydro]

Ha mooi, dit komt de validatie inderdaad door. Alleen krijg ik een error omdat ManningResistance eigenlijk alleen tussen basins werkt, en niet tussen Basin en LevelBoundary. Je zou die (of alle) resistances kunnen vervangen door LinearResistance voor nu.

Ik heb het nu gefixt door een boundary knoop 100m noordelijk te leggen van elke knoop die nergens meer naar afwatert: https://we.tl/t-OvfnwUvD3M

[visr]

┌ Error: Cannot connect a Basin to a LevelBoundary (edge #2 from node #7 to #293).
│ Cannot connect a Basin to a LevelBoundary (edge #4 from node #10 to #294).
│ Cannot connect a Basin to a LevelBoundary (edge #6 from node #12 to #295).
│ Cannot connect a Basin to a LevelBoundary (edge #8 from node #13 to #296).
│ Cannot connect a Basin to a LevelBoundary (edge #10 from node #132 to #297).
│ Cannot connect a Basin to a LevelBoundary (edge #12 from node #133 to #298).
│ Cannot connect a Basin to a LevelBoundary (edge #13 from node #136 to #299).
└ @ Ribasim D:\ribasim\core\src\solve.jl:46
ERROR: Invalid network

[visr]

Basin - ManningResistance - LevelBoundary werkt nu ook, dus dat kan ook gebruikt worden: Deltares/Ribasim#336

[d2hydro]

Zie nieuw setje: https://we.tl/t-xbMDDaZxFu. Ik heb het nu zo opgelost:

[visr]

Nice, that works! Here some results in the Ribasim QGIS plugin:

Do you have the underlying polygons of the basins as well? I'd like to show them during the iMOD User Day presentation tomorrow as an example of a model besides the test models.

[d2hydro]

Do you have the underlying polygons of the basins as well? I'd like to show them during the iMOD User Day presentation tomorrow as an example of a model besides the test models.

Dit zijn de LSWs: https://we.tl/t-uj0PCvphKI. Ik heb bovenstaande schematisatie gemaakt door het LHM netwerk te knippen op de total_bounds van DWRN == 30. Vandaar dat je, naast Flevoland, ook randjes Veluwe mee krijgt.

Misschien wel handig een disclaimer op te nemen bij het plaatje in je presentatie; deze schematisatie is nog work-in-progress, dient nu vooral software-ontwikkeling en zal nog ver-van zinnige resultaten leveren :-)

[d2hydro]

@visr; zelfde kwaliteit schematisatie, maar dan voor heel NL: https://we.tl/t-obZfNJn4KC

[visr]

Thanks! Hij draait nog niet, vanwege NULL areas in de Basin / profile tabel. En er zitten ook nog twee extreme levels in.

index	remarks	area	node_id	level
34361	uit dm nds.txt	1.00E+06	8652	-999
34366	uit dm nds.txt	1.00E+06	8652	999
34362	uit dm nds.txt	NULL	8652	-2.4
34260	uit dm nds.txt	NULL	8604	-1.4
34212	uit dm nds.txt	NULL	8581	-1.36
34261	uit dm nds.txt	NULL	8604	-1.3
34262	uit dm nds.txt	NULL	8604	-1.2
34363	uit dm nds.txt	NULL	8652	-1.2
34263	uit dm nds.txt	NULL	8604	-1.1
34264	uit dm nds.txt	NULL	8604	-1
34213	uit dm nds.txt	NULL	8581	-0.96
34364	uit dm nds.txt	NULL	8652	0
34365	uit dm nds.txt	NULL	8652	1.2

Ik zie in de Node tabel trouwens een fid en een ribasim_id. Voor Node wordt alleen de fid gebruikt als ID, dus dat is waar de node_id uit andere tabellen naar verwijzen, niet ribasim_id.

[d2hydro]

Kolom ribasim_id heb ik weggehaald (was de de node-id van jullie oude model, niet relevant); `fid is idd node-id.

Ik heb de NaNs uit area gehaald, maar krijg nu instabiliteit; hoe kan ik dat verder onderzoeken?

Model staat hier: https://github.com/d2hydro/lhm-ribasim/tree/main/models/ribasim_model_nederland

[visr]

Tot nu toe zagen we dit iedere keer door invalide Qh relaties, zie de regels in dit issue: Deltares/Ribasim#279

Ik heb nog niet gekeken of deze tabel aan alle regels voldoet. Maar eerder kregen we hetzelfde issue als een h bijvoorbeeld twee keer voorkomt in de relatie.

[d2hydro]

N.a.v. deze issue: #5 (comment)

Gevonden:

• niet-plausibele profielen in DM; alle profielen vervangen voor defaults => DM dus niet direct bruikbaar
• niet-plausibele profielen in simplified.nc; gaat hier waarschijnlijk om gebieden met 0 m2 oppervlaktewater in de brongegevens

Hierna, geen model-crashes, wél een lange (infinite?) rekentijd:

[visr]

Met de nieuwe progress bar zag ik een ETA van 17 uur...

Heb dit issue aangemaakt om ernaar te kijken: Deltares/Ribasim#419