Click on your picture in the top right corner, go to Preferences and select your notification preferences.
Please keep in mind:
1. To only comment on the topic where the discussion is about. Do you have a new question or topic? Please start a new discussion.
2. Be kind to other users!
SEWER_PUMP_SPEED mechanics
Hi Tygron,
I would like to simulate a small sewer area with relatively large sewer pump speed. With this, i am able to estimate the required discharge capacity at water stress locations in order to prevent flooding or damage to buildings.
I build a sewer area of 40 m2 with 1 mm storage and 0,1 m3/s discharge capacity. I simulate a rainfall event of 100 mm in 30 minutes. I expect to see a 'Object flow output' at my sewer area of 6 m3/minute (60*0,1). Instead, i see only 0,7 m3/minute discharge.
I've run several checks on the model. There is enough water on the surface to fill the sewer area constantly:
There are several setting I can adjust to change the 'Object flow ouput': Sewer storage, grid cell size, rainintensity.
When I increase Sewer storage to 2 mm, my Object Flow Output increases to 1,4 m3/minute. Increasing it to 5 mm, my Object Flow Output increases to 3,5 m3/minute. There seems to be a linear dependency between storage and the object flow output. However, when I calculate the storage with 5 mm for 40 m2, there is 0,2 m3 storage in my sewer area. Conclusion: although the storage capacity of my sewer area exceeds the Sewer Pump Speed (0,1 m3/s) AND there is enough water on the surface (picture above), the sewer area still does not discharges the expected volume of 6 m3/minute.
When I decrease the grid resolution from 0,25m2 (0,5x0,5m) to 1m2 (1x1m) the Object flow output decreases from 3,5 m3/minute to 1,5 m3/minute. I do not expect this result, as there is still enough water on the surface and the sewer area is large enough to still fit 40 gridcells.
Simulating with 5 mm storage, 1m2 resolution and increasing the rainintensity to 1.000 mm, the outflow output increases from 1,5 m3/minute to 1,7 m3/minute. Although there is enough water on the surface during a 100 mm rainfall event, seemingly an increased waterdepth on the surface leads to higher discharge.
How is the Object flow output for sewer areas calculated and why is the outflow lower than the expected outflow?
Thanks in advance for your reply,
Kind regards, Thijs Visser
Comments
Hi @Thijs Visser ,
A few questions to better understand what is happening:
Tygron support team
Hi @Godelief ,
I selected the sewer area at current situation > areas > sewer > 'name of the area'. After the calculations I saw the Object Flow Output change.
The sewer area is completely covered with sewered buildings.
I have no sewer overflow in my project (there is no water terrain available).
Thanks in advance for your reply
Thijs
Hi Thijs,
Thank you very much for including the exact numbers in your post, as this has allowed me to dive into the exact calculations and attempt to duplicate the results you describe. And although I haven't gotten the exact results you have, I have found the most likely cause of the issue, namely that your sewer is very small compared to the pump speed.
I'm aware my answers tend to be quite long at times, but in this case there's a lot to touch on. The first bit is most important, the rest is depth and more exact details. Bear with me. ;)
What's happening
A sewer of 40m² with 1mm of allowed storage has a total storage capacity of 40*0.001 = 0.04m³. This means that if a timestep of more than 400 milliseconds is computed, the maximum speed of 0.1m³/s is not actually reached. Instead, whatever water there is in the sewer is simply removed in full.
Because a sewer so small is not realistic for the way sewers are implemented in the Tygron Platform, timesteps are not throttled based on this bottleneck. In other words, the dynamic calculation of timestep length does not take into account that for such a small sewer, smaller timesteps may lead to more expedient water flow. So for any given timestep, it's possible that the sewer is up entirely in one go, and that in that same time step the pump drains it entirely again, with both inflow and outflow limited by the sewer's storage capacity.
(Important sidenote for any reader: timesteps are not to be confused with timeframes.)
You can test this by creating a larger sewer (try 400m² or 4000m²) with the same pump speed, and noticing it will max out at your pump speed.
What's happening in detail
Regarding the computational phenomenons you see as you tweak the numbers:
Sewer capacity
Increasing the sewer storage attribute or the size of the sewer, both increase the total amount of m³ of water can be stored in the sewer. Thus also how much water can be pumped out during any single timestep. Increasing the sewer storage attribute is something you've tried. You haven't directly changed the size of the sewer, but you did change the grid size at one point.
Sewer size and grids
When the calculation is performed, the world is first rasterized. This means the entire world is divvied up into cells, and if certain properties exist within that cell, then the entire cell is considered to have that property. For instance, if there is 1m² of polygonal data indicating a sewer is present found in a cell of 10m by 10m, then the entire cell of 100m² is considered a sewer. Changing the grid cell size changes the overlaps between polygon data and cells, but in quantity and in size. This rasterized interpretation of the sewer size is what truely determines the surface area of the sewer which, multiplied by the storage capacity of the sewer, is the actual volume of water it can retain. You can determine the exact interpreted surface area of the sewer by adding a "Base Types" result, and querying it with the following query (in which GRID 6 should of course reference your base types overlay, and GRIDVALUE 4 corresponds to the nominal value of a sewer):
SELECT_LANDSIZE_WHERE_GRID_IS_6_AND_GRIDVALUE_IS_4.0
For example, I tested by drawing exactly 10 squares of 2m by 2m for the sewer, which is2x2x10=40m², but this amounted to 62m² on a 0.25m² grid as it was interpreted by the overlay, because of minute overlaps with adjacent cells. Decreasing the resolution (increasing cell size) to 1m² brought this up to 88.
Timesteps (affected by grid cells)
This would imply that the capacity of the sewer would increase and more water can flow out as the resolution decreases, which is correct. But you've also described that you saw the opposite happening: lower resolution meant a lower flowthrough. This actually comes down to the fundamental relation between timesteps and grids, namely that the smaller your grid cells are, the smaller the timesteps are with which the overlay calculates. This is in fact one of the key factors in how timesteps are calculated, with some considerations made for impulse and such. The intent being that as water may not "overshoot" the path it would realistically take.
So by changing the grid cell size, specifically by using larger cells, the amount of time represented by a timestep changes as well, and so fewer timesteps are computed for the same simulation time. Fewer timesteps then also means fewer times that the sewer is filled to the brim and emptied again, leading to (in the end) less water in total having been pumped through.
Rain
I must admit that I haven't been able to find an equally firm reasoning for the rain to have these same effects, but it is very likely that it comes down to timesteps as well. Presence of water and impulse of water are both taken into consideration as the overlay calibrates itself towards taking appropriate timesteps. so that no water overshoots the trajectory it needs to take. More rain means more water means more careful consideration of momentum and pressure and thus smaller timesteps to ensure the water flows where it needs to go. And thus more timesteps, allowing more water to fill the sewer and be pumped out.
There may also be something with rounding of exact numbers going on, but that is entirely speculative
Timesteps are never externally predictable
Because timesteps are dynamically calculated, by the overlay itself to ensure computational integrity, it is not possible to control them to such a degree that you can balance them out with the exact time needed to empty an entire sewer perfectly. The fact that you have run into this is due to the very small size of the sewer, which is smaller than how sewers are practically used.
However, the same issue will occur if you scale up the sewer to realistic size but scale the pump speed accordingly: if it takes (in the order of )less than a second to pump out the entire sewer, a bottleneck will form in which the sewer's storage capacity combined with the amount of computational timesteps dictate how much water can be pumped out for any given period of time, rather than the configured pump speed.
In conclusion
In summary: in this setup the amount of timesteps dictates how many times the sewer is pumped empty. The stated experimentations affect either how much water is pumped out per single timestep, or how many timesteps there are.
Be sure to let us know if:
Hi @RudolfNL
Thank you for your reaction. Your answer gives a lot of context that helps explaining the unexpected results of the simulation. Based on your comment I did some further testing to fully understand the sewer pump speed. I still got some questions:
I used the model I mentioned earlier. I used the same sewer area (which is 50 m2 instead of earlier mentioned 40 m2) and tried to determine the required sewer storage based on the simulation time, timesteps and sewerpumpspeed. In the figure below you can see my spreadsheet where I calculate the required storage (0,6 mm).
I use twice the required storage, but the object flow output does not reach 6 m3/min. Can you help me understand these results a bit more? As you see below, there is enough water on the surface.
Kind regards and thank you for your reply!
Thijs Visser
Hi Thijs,
I will emphasize again that the level you are calculating with is so exactly "on" the margins, that any minor rounding or missmatch will be enlarged to seemingly significant levels. I say seemingly because, in practical cases, no sewer is likely to be so close to the mathematical margins.
That said, I have some clarity on why the number appear as they do. The rate at which water flows into the sewer differs from the timesteps themselves. Specifically, water flowing into the sewer is calculated once every 2 seconds*.
To verify this, I had set up a project with a very small sewer, a flooded surface, and inspecting the exact numbers:
Given the above, the bottleneck for flowthough is how much water can flow into the sewer. 1800 seconds, and water flowing in once every 2 seconds, means there are 900 times the sewer is filled. 900 inflows *0.336 m³ storage = 302.4m³ water, which matches the output calculated by Tygron.
So if you retry your calculations with the assumption of the sewer filling up every 2 seconds (or at least experiencing inflow only every 2 seconds), you should find your values lining up significantly better.
*As a final note, the exact interval with which water flows into the sewer is dependent on the calculation mode. While "Accuracy" is obviously the most rapid interval, other settings will still be sufficient for a proper simulation of water flow at the scale at which the Water Overlay is meant to calculate.