After following the Quick start training, as well as completing multiple tutorials on the Tygron Support Wiki, the newest intern of Tygron has been tasked to apply his newly obtained knowledge in the form of an example case study. He has documented his process by writing this article and he will take you through the choices he made and the places he acquired his information from.
By: Brent Horsten
Working with new, unknown software can seem like a daunting task. It’s easy to get lost in all the buttons, options, features, displays, user interfaces and things you don’t even know the name for. This article functions as a guide for beginners, a step-by-step example for working with the Tygron Platform.
The hypothetical case used in this article is a part of the ‘Ruimte voor de rivier’ project, formed in 2006, which has the goal to manage the water from the river ‘Waal’ in a better way.
The local water board near the village Ochten is concerned about the upcoming increase in water discharge from the river Waal. The latest predictions state the constant discharge of the river will increase from 10.700 m³/s to 12.000 m³/s. The new peak discharge will lie around 20.000 m³/s. The water board wants to know if the Goeveneurse Polder can adequately protect the surrounding villages from flooding.
When working with models, it is important to formulate goals in such a way the software can make sense of it. A way of doing this is by redefining your goals as SMART goals. SMART stands for Specific, Measurable, Achievable, Realistic and Timebound. The most important aspects for the software are specific and measurable.
In the case at hand, the SMART goal for the water board’s wishes for ‘safety’ could look like:
‘At a constant water discharge of 12.000 m³/s, the surrounding villages should not contain any buildings damaged by the flood.’
‘At a peak water discharge of 20.000 m³/s, the water is should not cross the current dikes.’
Mapping the current design
The first step of the project is to map the current situation. After starting up the client, press ‘New Project’, as seen in Figure 1.
From there, give your project a name. Select your preferred language, the currency used in the area and the preferred unit system. Once that is done, select ‘Empty Project’ (see Figure 2).
Select the project area (keep in mind the bigger your project area is, the longer calculations can take, so don’t select more than needed). Click the ‘Selection’ option over the ‘Empty map’ and press ‘Generate Map’, as seen in Figure 3.
Now, the map is being generated, as seen in Figure 4. The platform retrieves data from multiple open sources and adds them together to form the 3D world.
After a cinematic flythrough over the area the client is ready and set (see Figure 5).
Modelling the future scenario
The first thing that needs to be implemented is the new problem. The example case stated an increase in water discharge from 10.700 m³/s to 12.000 m³/s. However, how is such a thing simulated? Where to start? The answers to these and many other questions can be found on the Support Wiki.
However, even after consulting the wiki thoroughly, it did not answer all of the questions at hand. In order to obtain the required information, help was needed from the support team. The biggest research breakthrough is briefly explained here.
This case makes use of the flooding overlay, a subpart of the water module. This overlay is added by hovering over the ‘Overlays’ button and selecting ‘Add Flooding’. The configuration wizard provides various options to simulate an increase in water depending on the scenario. However, for this specific case, the extra water discharge is added manually. As no additional data sets are used in this project, the only notable tab in the configuration wizard is the ‘output overlays’ tab. Obviously, if the user has more specific data sets than standard ones present in the platform they should add it in the wizard. The ‘output overlays’ tab lets the user decide which kind of results they would like to see. For this project, ‘surface elevation’, ‘surface last value’ and ‘impacted buildings’ are chosen.
For this case, inlets are used to manually simulate the additional flow of water in and out of the river. As the river flows from east to west, an inlet generating water is added on the east side, while an inlet removing water is placed on the west side. This is shown in Figure 6. These inlets can be found under ‘buildings’ (see the red ‘1’ in Figure 6, ‘underground’ and then ‘add’ (see the red ‘2’ in Figure 6). By selecting the newly created underground building on the left side, the about this building is displayed on the right side of the screen. Press the ‘change function’ option (marked with the red ‘3’ in Figure 6), select ‘inlet’ (marked with the red ‘4’) and press apply.
The last step to get the inlets working is to set their INLET_Q attribute to the desired value. In this project, an inlet on the east side of the map is placed with an INLET_Q of 2.300 m³/s. This number is obtained by subtracting the current flow of water (10.700 m³/s) from the future discharge (12.000 m³/s). With the inlet in place, 2.300 m³ of water is generated every second on this point. On the west side of the river, a couple of inlets with a negative value are placed. Multiple outlets are needed to prevent water from accumulating in unnatural and unintended ways.
The standard grid cell size is set on 10 m. For this project, a grid cell size of 10 m is quite rough, and can lead to some inaccurate estimations. Smaller grid cell sizes increase the accuracy of the model, but at the cost of computation time. Here, a grid cell size of 3 m is used. After adjusting the grid cell size to 3 m and the result type to SURFACE_LAST_VALUE, the platform is set up for calculations. By clicking ‘update now’.
After the calculations are finished the result overlays can be viewed.
Figure 7 shows the project area with an additional 2.300 m³/s water discharge. At first glance, it looks normal. However, remember that specific criteria were set to justify the safety of the area at the beginning of the article. Namely, the project area is not allowed to contain any impacted buildings according to the set goals. To check this, hover over the flooding overlay icon on the right side of the screen and select the impacted buildings overlay (this feature is enabled in the configuration wizard).
Figure 8 shows an impacted building inside of the riverbank, at the end of a road. The model of the building appears to be an office building, which seems strange. By checking satellite images with the help of e.g. Google Maps, this building appears to be a floating dock (see Figure 9). What happened here? Why does the platform represent this dock as an office building? The platform had data available to know that a building was present there, but it didn’t have data about the specific type of building. To fill in this lack of information, the platform chose to represent this building as a standard building within its catalogue. In this instance, an office building was used. When analyzing results, always be careful of strange situations like this.
Apart from the dock, the some roads alongside the are marked as impacted. However, upon closer inspection with the measuring tool available on the right side of the screen, it seems people walking on these roads are still be able to walk there without getting their feet wet.
Looping back to the first SMART goal set earlier, it seems like the current situation is suitable for the upcoming extra water discharge.
Updating the first scenario to a similar problem
For the second scenario, the only change needed is the value of the INLET_Q attribute of the in- and outlets. The inlet on the east side of the map is now set on 9.300 m³/s.
As seen in Figure 10, even during peak discharge times the dikes seem to protect the surrounding villages. However, some areas (like the industrial area in the Drutense Waarden) do get hit significantly. By hopping through timeframes (found in the bottom-left corner of the screen), it becomes apparent that during peak discharge times this area has about four to five hours to evacuate.
By setting SMART goals, the original user story has been made specific and measurable. This gives the user a foothold to hold onto when simulating the problem. After consulting different information sources (Tygron Wiki, Support, the forum), the problem can be simulated, tested and analyzed.