Open d2hydro opened 1 year ago
@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?
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
Een combinatie van een LinearResistance en LevelBoundary doet precies wat de oude LevelControl node deed.
@visr in reactie op https://github.com/d2hydro/lhm-ribasim/issues/5#issuecomment-1571654239;
resistance
de conductance
in m2/dag?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: https://github.com/Deltares/Ribasim/issues/268
De formule is q = (h1 - h2) / resistance
. q is m3/s. Dus resistance is s/m2.
We hebben nu alle Node:type == Basin knopen aangemaakt met bijbehorende profielen (Basin / profile) . Profielen hebben we, waar mogelijk, gelezen uit:
We gaan ervan uit dat tussen elke Basin minimaal nog een ander type knoopje moet liggen dat de flow tussen de basins beschrijft.
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. (https://github.com/Deltares/Ribasim/issues/225)
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.
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
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.
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?
Dat klopt, dit lijkt inderdaad op een foutje.
@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:
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 https://github.com/Deltares/Ribasim/pull/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.
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.
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.
@visr; hierbij een nieuwe GPKG voor Flevoland: https://we.tl/t-PqQkYyLXNv.
Deze comments zijn verwerkt: https://github.com/d2hydro/lhm-ribasim/issues/5#issuecomment-1594444334
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.
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 delevel
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
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.
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
┌ 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
Basin - ManningResistance - LevelBoundary
werkt nu ook, dus dat kan ook gebruikt worden: https://github.com/Deltares/Ribasim/pull/336
Zie nieuw setje: https://we.tl/t-xbMDDaZxFu. Ik heb het nu zo opgelost:
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.
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 :-)
@visr; zelfde kwaliteit schematisatie, maar dan voor heel NL: https://we.tl/t-obZfNJn4KC
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
.
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
Tot nu toe zagen we dit iedere keer door invalide Qh relaties, zie de regels in dit issue: https://github.com/Deltares/Ribasim/issues/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.
N.a.v. deze issue: https://github.com/d2hydro/lhm-ribasim/issues/5#issuecomment-1614384158
Gevonden:
Hierna, geen model-crashes, wél een lange (infinite?) rekentijd:
Met de nieuwe progress bar zag ik een ETA van 17 uur...
Heb dit issue aangemaakt om ernaar te kijken: https://github.com/Deltares/Ribasim/issues/419