Na het volgen van de Quick start-training en het voltooien van meerdere tutorials op de Tygron Support Wiki, heeft de nieuwste stagiair van Tygron de opdracht gekregen om zijn nieuw verworven kennis toe te passen in de vorm van een voorbeeldcase. Hij heeft zijn proces gedocumenteerd door dit artikel te schrijven en hij zal u meenemen door de keuzes die hij heeft gemaakt en de plaatsen waar hij zijn informatie vandaan heeft gehaald.
Door: Brent Horsten
Werken met nieuwe, onbekende software kan een ontmoedigende taak lijken. U kunt gemakkelijk verdwalen in alle knoppen, opties, functies, displays, gebruikersinterfaces en dingen waarvan u de naam niet eens weet. Dit artikel fungeert als een gids voor beginners, een stapsgewijs voorbeeld voor het werken met het Tygron Platform.
Case study
De hypothetische casus die in dit artikel wordt gebruikt, is een onderdeel van het project ‘Ruimte voor de rivier’, opgericht in 2006, dat tot doel heeft het water uit de Waal beter te beheren.
Het lokale waterschap bij het dorp Ochten maakt zich zorgen over de aanstaande toename van de waterafvoer uit de Waal. Volgens de laatste voorspellingen zal de constante afvoer van de rivier toenemen van 10.700 m³ / s tot 12.000 m³ / s. De nieuwe piekafvoer zal rond de 20.000 m³ / s liggen. Het waterschap wil weten of de Goeveneurse Polder de omliggende dorpen voldoende kan beschermen tegen overstromingen.
Definitie probleem
Bij het werken met modellen is het belangrijk om doelen zo te formuleren dat de software het kan begrijpen. Een manier om dit te doen, is door uw doelen opnieuw te definiëren als SMART-doelen. SMART staat voor Specifiek, Meetbaar, Haalbaar, Realistisch en Tijdgebonden. De belangrijkste aspecten van de software zijn specifiek en meetbaar.
In het voorliggende geval zou het SMART-doel voor de wensen van het waterschap voor ‘veiligheid’ er als volgt uit kunnen zien:
‘Bij een constante waterafvoer van 12.000 m³ / s mogen de omliggende dorpen geen gebouwen bevatten die door de overstroming zijn beschadigd.’
En:
‘Bij een piekwaterafvoer van 20.000 m³ / s mag het water de huidige dijken niet kruisen.’
Het huidige ontwerp in kaart brengen
De eerste stap van het project is het in kaart brengen van de huidige situatie. Druk na het opstarten van de client op ‘Nieuw project’, zoals te zien in afbeelding 1.
Geef daar uw project een naam. Selecteer uw voorkeurstaal, de valuta die in het gebied wordt gebruikt en het gewenste eenheidssysteem. Zodra dat is gebeurd, selecteert u ‘Leeg project’ (zie afbeelding 2).
Selecteer het projectgebied (houd er rekening mee dat hoe groter uw projectgebied is, hoe langer de berekeningen kunnen duren, dus selecteer niet meer dan nodig is). Klik op de ‘Selectie’ optie boven de ‘Lege kaart’ en druk op ‘Kaart genereren’, zoals te zien is in afbeelding 3.
Nu wordt de kaart gegenereerd, zoals te zien is in afbeelding 4. Het platform haalt gegevens op uit meerdere open bronnen en voegt ze samen om de 3D-wereld te vormen.
Na een flythrough over het gebied is de cliënt klaar om te beginnen (zie afbeelding 5).
Modellering van het toekomstige scenario.
Het eerste dat moet worden geïmplementeerd, is het nieuwe probleem. In het voorbeeldgeval werd een toename van de waterafvoer genoemd van 10.700 m³ / s naar 12.000 m³ / s. Maar hoe wordt zoiets gesimuleerd? Waar te beginnen? De antwoorden op deze en vele andere vragen zijn te vinden op de Support Wiki.
Maar zelfs na het grondig raadplegen van de wiki, beantwoordde het niet alle vragen die voorhanden waren. Om de vereiste informatie te verkrijgen, was hulp van het ondersteuningsteam nodig. De grootste onderzoeksdoorbraak wordt hier kort toegelicht.
Deze case maakt gebruik van de overstromingsoverlay, een onderdeel van de watermodule. Deze overlay wordt toegevoegd door over de ‘Overlays’ knop te bewegen en ‘Overstroming toevoegen’ te selecteren. De configuratiewizard biedt verschillende opties om een watertoename te simuleren, afhankelijk van het scenario. Voor dit specifieke geval wordt de extra waterafvoer echter handmatig toegevoegd. Aangezien er in dit project geen extra datasets worden gebruikt, is het enige opmerkelijke tabblad in de configuratiewizard het tabblad ‘output overlays’. Het is duidelijk dat als de gebruiker meer specifieke gegevenssets heeft dan de standaardgegevens die in het platform aanwezig zijn, ze deze in de wizard moeten toevoegen. Op het tabblad ‘output overlays’ kan de gebruiker beslissen welk soort resultaten hij wil zien. Voor dit project worden ‘oppervlakte-verhoging’, ‘oppervlakte laatste waarde’ en ‘getroffen gebouwen’ gekozen.
In dit geval worden inlaten gebruikt om handmatig de extra waterstroom in en uit de rivier te simuleren. Terwijl de rivier van oost naar west stroomt, wordt aan de oostkant een inlaat voor het genereren van water toegevoegd, terwijl aan de westkant een inlaat voor het verwijderen van water wordt geplaatst. Dit wordt getoond in figuur 6. Deze inlaten zijn te vinden onder ‘gebouwen’ (zie de rode ‘1’ in afbeelding 6, ‘ondergronds’ en dan ‘toevoegen’, de rode ‘2’ in afbeelding 6). Door het nieuw gecreëerde ondergrondse gebouw aan de linkerkant te selecteren, worden de eigenschappen van dit gebouw aan de rechterkant van het scherm weergegeven. Druk op de ‘functie wijzigen’ optie (gemarkeerd met de rode ‘3’ in afbeelding 6), selecteer ‘inlaat’ (gemarkeerd met de rode ‘4’) en druk op toepassen.
De laatste stap om de inlaten te laten werken, is door hun INLET_Q-attribuut op de gewenste waarde in te stellen. In dit project wordt een inlaat aan de oostzijde van de kaart geplaatst met een INLET_Q van 2.300 m³ / s. Dit aantal wordt bereikt door de huidige waterstroom (10.700 m³ / s) af te trekken van de toekomstige afvoer (12.000 m³ / s). Met de inlaat op zijn plaats wordt op dit punt elke seconde 2.300 m³ water gegenereerd. Aan de westkant van de rivier zijn een aantal inhammen met een negatieve waarde geplaatst. Er zijn meerdere uitlaten nodig om te voorkomen dat water zich op onnatuurlijke en onbedoelde manieren ophoopt.
De standaardgrootte van de rastercellen is ingesteld op 10 m. Voor dit project is een rastercelgrootte van 10 m vrij ruw en dit kan leiden tot onnauwkeurige schattingen. Kleinere celgroottes vergroten de nauwkeurigheid van het model, maar dit gaat ten koste van de rekentijd. Hier wordt een rastercelgrootte van 3 m gebruikt. Na aanpassing van de rastercelgrootte naar 3 m en het resultaattype veranderd naar SURFACE_LAST_VALUE, is het platform ingericht voor berekeningen. Door op ‘nu updaten’ te klikken.
Nadat de berekeningen zijn voltooid, kunnen de resultaatoverlays worden bekeken.
Resultaten analyseren
Afbeelding 7 toont het projectgebied met een bijkomende waterafvoer van 2.300 m³ / s. Op het eerste gezicht ziet het er normaal uit. Onthoud echter dat aan het begin van het artikel specifieke criteria zijn vastgesteld om de veiligheid van het gebied te rechtvaardigen. Namelijk, het projectgebied mag geen getroffen gebouwen bevatten volgens de gestelde doelen. Om dit te controleren, beweegt u de muisaanwijzer over het overstromingsoverlay-pictogram aan de rechterkant van het scherm en selecteert u de betreffende gebouwenoverlay (deze functie is ingeschakeld in de configuratiewizard).
Afbeelding 8 toont een getroffen gebouw aan de binnenkant van de rivieroever, aan het einde van een weg. De maquette van het gebouw blijkt een kantoorgebouw te zijn, wat vreemd overkomt. Door satellietbeelden te controleren met behulp van b.v. Google Maps, blijkt dit gebouw een drijvend dok te zijn (zie afbeelding 9). Wat is hier gebeurd? Waarom stelt het platform dit dok voor als een kantoorgebouw? Het platform had gegevens beschikbaar om te weten dat er een gebouw aanwezig was, maar het had geen gegevens over het specifieke type gebouw. Om dit gebrek aan informatie op te vullen, koos het platform ervoor om dit gebouw als een standaardgebouw in zijn catalogus weer te geven. In dit geval werd een kantoorpand gebruikt. Pas bij het analyseren van resultaten altijd op voor vreemde situaties zoals deze.
Afgezien van het dok, zijn de enkele wegen langs de haven gemarkeerd als getroffen. Bij nader inzien met het meetinstrument aan de rechterkant van het scherm, lijkt het erop dat mensen die op deze wegen lopen er nog steeds kunnen lopen zonder natte voeten te krijgen.
Terugkerend naar het eerder gestelde eerste SMART-doel, lijkt de huidige situatie geschikt voor de komende extra waterafvoer.
Het eerste scenario bijwerken naar een soortgelijk probleem.
Voor het tweede scenario is de enige wijziging die nodig is de waarde van het INLET_Q-attribuut van de in- en uitgangen. De inlaat aan de oostkant van de kaart is nu ingesteld op 9.300 m³ / s.
Zoals te zien is in afbeelding 10, lijken de dijken zelfs tijdens de piekafvoeren de omliggende dorpen te beschermen. Wel worden sommige gebieden (zoals het industriegebied in de Drutense Waarden) flink getroffen. Door de tijdframes te springen (te vinden in de linkerbenedenhoek van het scherm), wordt duidelijk dat dit gebied tijdens piekontladingen ongeveer vier tot vijf uur de tijd heeft om te evacueren.
Samenvatting
Door SMART-doelen te stellen, is het oorspronkelijke gebruikersverhaal specifiek en meetbaar gemaakt. Dit geeft de gebruiker houvast bij het simuleren van het probleem. Na raadpleging van verschillende informatiebronnen (Tygron Wiki, Support, het Forum) kan het probleem worden gesimuleerd, getest en geanalyseerd.
