Ongeveer 20 jaar geleden rekende ik veel met InfoWorks. Dat was met wisselend succes en plezier. Op deze pagina beschrijf ik een voorbeeld van een berekening waar het bijna ongemerkt numeriek fout gaat.
Voorgeschiedenis
In mijn hele carrière heb ik gewerkt met diverse rekenmodellen. Op mijn homecomputer heb ik voor mijn afstuderen aan de HTS gewerkt met zelf geprogrammeerde software. Op de TU-Delft ben ik afgestudeerd op het toepassen van het impliciete rekenmodel FLOWS voor het berekenen niet stationaire stromingen in rioolstelsels. Bij Grontmij heb ik uit het Extended Transportmodel uit het SWMM pakket, Extran/GM ontwikkeld om op productieschaal rioolstelsels standaard niet-stationair door te rekenen. Dat was nieuw in Nederland. Voor de Leidraad Riolering was ik betrokken bij de ontwikkeling van de module C2100, de basis voor het berekenen van het Hydraulisch functioneren van rioolstelsels. Na mijn overstap van Grontmij naar Tauw heb ik nog gerekend met InfoWorks en de voorganger HydroWorks overgeslagen.
InfoWorks
Met InfoWorks had ik een haat liefde verhouding. Die software werd indertijd gemaakt om super snel te rekenen, de nauwkeurigheid was bijzaak. De mogelijkheden om e.e.a. te controleren waren ook beperkt. Het programma presenteerde bijvoorbeeld geen waterbalans in de tijd.
In onderstaand voorbeeld gaat het mis met de nauwkeurigheid van de resultaten vanwege problemen met de stabiliteit van het rekenproces.
Animatie berekende waterstanden in langsdoorsnede Rioolstelsel (InfoWorks)
Rekenvoorbeeld uitleg
Op de knopen R60, R61, R62 en R62a wordt na 32 minuten water (op straat) boven maaiveld berekend, heel kort, maar toch. Het lijkt wel een waterslagberekening. In een tijdbestek van ongeveer van 1 minuut schiet het water even boven het maaiveld. Dat is hier numeriek onrealistisch. Praktisch gezien zou iets dergelijks mogelijk kunnen zijn door luchtinspuiting op knoop R62, maar dat effect ziet niet in dit rekenmodel.
Als we de waterstand in knoop R62 op voet volgen dan zien we ongeveer vanaf het begin van de animatie een waterstand in die knoop die lange tijd constant blijft, eerst hoger dan in de omliggende knopen R61 en R62a en daarna lager. Pas na het tijdstip van 32 minuten begint de waterstand in knoop R62 snel te stijgen als de waterstanden in de omliggende knopen al veel hoger staan. Dat klopt fysisch dus niet.
Dit soort rekenmodellen hebben principieel moeite met het onder tegenschot vullen van leidingen. In de leidingen van knoop 61 naar 62 en van knoop 62a naar 61 moet het water omhoog stromen om die leiding te vullen. Dat gebeurt dus niet of veel te traag. Het natte profiel in de leidingen die uitkomen op knoop 62 knijpen a.h.w. het vullen van de leidingen die aansluiten op die knoop.
In die leidingen zie je enorme waterstands-verhangen richting knoop 62, maar het debiet dat daarbij hoort is er niet. Daardoor worden die leidingen niet gelijkmatig gevuld. Op een gegeven moment gaat dat knijp slot in die leidingen van de deur en vullen de leidingen bij knoop 62 zich met geweld. Dan schiet het water omhoog in de schachten van de putten rond knoop 62. Het water schiet zover door dat het tijdelijk boven maaiveld wordt berekend.
Hoe zou het resultaat er realistisch uit moeten zien? Het stelsel zou zich bij de knopen R61, R62 en R62a gelijkmatig moeten vullen met een nagenoeg horizontale waterspiegel. De maximale waterstand in de knoop hoort het maaiveld dan helemaal niet moeten bereiken. Vanuit het helicopterview op de kaart gezien is het dus loos alarm.
Rekenschema
Over dit probleem heb ik 20 jaar geleden veel discussie met de InfoWorks ontwikkelaars gehad. Ze probeerden het uit te leggen als een dynamisch verschijnsel. Als ik de reacties op mijn LinkedIn post goed proef dan is die mening nog niet veranderd.
Indertijd heb ik exact deze situatie ook laten doorrekenen met SOBEK en daar kwam eigenlijk hetzelfde resultaat uit. InfoWorks en SOBEK hebben beide een impliciet rekenmodel. Extran/GM had een expliciet rekenmodel. Met Extran/GM had je dit soort problemen niet omdat het rekende met veel kleinere tijdstappen. Het was ook veel trager.
In mijn afstudeerervaring met het impliciete FLOWS rekenmodel had ik veel aandacht besteed aan de instelling van de parameters van het rekenschema. In InfoWorks had je als gebruiker maar een beperkte toegang tot de rekenparameters. Het vervelende was ook dat als je een parameterwaarde opgaf die buiten de range van de softwarebouwer lag dat deze werd gecorrigeerd, ZONDER WAARSCHUWING. Je wist dus nooit zeker waarmee je rekende.
In SOBEK was het veel makkelijker het rekenschema in te stellen. Essentiële parameter was de zogenaamde têta waarde, dat is de mate waarin je nadruk legt op tussen de resultaten van de voorafgaande en de volgende tijdstap. Idealiter is têta waarde 0,5. Dan is de berekening maximaal nauwkeurig en minimaal stabiel. Daarom wordt vaak gekozen voor een waarde van 0,55 met meer stabiliteit en toch nauwkeurig. In mijn afstudeerproject met FLOWS heb ik veel gerekend met een têta waarde 1,0, minimaal nauwkeurig en maximaal stabiel.
Door in SOBEK de têta waarde 1,0 in te stellen werd mijn rekenvoorbeeld eenvoudig stabiel en rekende het zoals het hoorde, een gelijkmatige vulling van de leidingen rond knoop 62. Misschien iets minder nauwkeurig maar veel nauwkeuriger dan het instabiele resultaat. Een aantal jaren geleden heb ik dit nog eens besproken met Guus Stelling, de geestelijk vader van SOBEK, en die beaamde die keuze voor têta=1,0.
Last Updated on 2023-08-25 10:41 by harrr