Quadtree and Sub-Grid Sampling FAQ

Which of the TUFLOW solvers support Quadtree and Sub-Grid Sampling (SGS)?

Quadtree and Sub-Grid Sampling are currently only supported by TUFLOW HPC. The features are currently not available using TUFLOW Classic or TUFLOW FV.

How coarse can the base cell size be for a Quadtree model with Sub-Grid Sampling (SGS)?

There are two answers to this question depending on your modelling objectives. For example, by doubling your base cell size, and not changing the Quadtree levels, you will be doubling the cell sizes throughout your model. Provided this doubling of cell sizes does not conflict with other objectives (remember, only one velocity is calculated per cell face, so a consequence of doubling cell size is to reduce the quality of velocity based outputs such as hazard), whether or not it is okay to increase the base cell size simply comes down to whether results convergence can be proven. By results convergence we mean you can increase (or decrease) your cell sizes without unacceptably changing the model results. If you do see a significant change in results that is considered unacceptable, then you need to possibly make your cell sizes smaller (not larger!). A well-designed model mesh is one where you can decrease cells sizes without seeing an unacceptable change in results. SGS will greatly help with achieving results convergence and very much increase your ability to use a coarser base cell size or coarsen up parts of your model. The second part of the answer is if you wish to coarsen up parts of your model but retain the same cell sizes in your focus area. To achieve this you can increase your base cell size to your largest cell size you wish to use, then add additional levels of nesting layers for your Quadtree mesh noting that the 2020-01 release of TUFLOW allows for up to 9 levels of nesting, so your smallest cell size can only be one-eighth of your base cell size.

When should I not use SGS?

There is a threshold beyond which SGS isn’t required. The benefit of SGS is focussed on cells with variety of elevations within each cell. For flat cells, where all SGS sample points have almost the same elevation, there won’t be much of a difference in comparison without SGS.

When should I not use Quadtree?

The main advantages of using Quadtree are shorter run times (with considerable cell count reduction compared with using a HPC grid), lower GPU RAM footprint and smaller size of output files. If you're not achieving this by using Quadtree then there is little benefit in using it. Some models with cell count reduction of only around 30% may even run slower with Quadtree than the original HPC model.

When should I not use a combination of SGS and Quadtree?

Based on the benchmarking thus far there seems to be little reason not to use SGS with Quadtree. The one exception is if the underlying resolution of the DEM is of similar (or coarser) resolution to the 2D cells then there is little reason to use SGS as there is no detailed sub-cell terrain to sample. SGS was not made the default in the 2020-01 release because for some models, especially those with coarse cell sizes over highly variable terrain, you can see substantially different results due to SGS picking up a lot more detail of the terrain within a 2D cell. Using Quadtree with SGS, and by using coarser cells within your model than you would have using a HPC grid, you will achieve a much better result and good results convergence (as discussed further above). It's highly likely that SGS will be made the default in a future release once there has been extensive industry benchmarking demonstrating using SGS to be consistently superior to not using (which is the case thus far).

The resolution of my underlying DEM is 1m and my 2D cell size is 1m. Is there any benefit in using SGS?

None or very little benefit. The DEM resolution really needs to be finer than the 2D cell size resolution for SGS to be of any benefit. In this case the SGS sampling resolution would effectively be one point per cell area/face, so there wouldn't be any precision benefit and the model will have an unnecessarily longer initialisation time.

Does using SGS increase model runtimes?

Turning SGS on can increase run times by 20-30% for a model that is well designed with appropriate cell sizes. However, in cases where the model resolution is too coarse for the terrain, the improvement in model stability and hydraulic performance by using SGS can actually cause a reduction in run times. For example, for a direct rainfall model of the Johnstone River catchment SGS vastly reduced the choking of narrow flow paths caused by one elevation per cell face in the steeper part of the catchment, thereby reducing high depth and high velocity areas that allowed the simulation to progress at much larger timesteps reducing the simulation time from 26 hours to 4(!). Using SGS may allow you to use larger cell size(s) without adversely changing results so that runs can be performed much faster - this is of great benefit when developing or calibrating a model when you wish to have a high turnover of simulations - if you can carry out this phase of the modelling using coarser cell sizes by using SGS without greatly changing results your workflow efficiency can be greatly enhanced.

Should the same model using Quadtree with smaller cell count always be faster than HPC?

Not necessarily. By default, running a model with a single level Quadtree mesh identical to a HPC grid is always slower, on average 20%. Quadtree really starts to have major benefits once there is at least three levels of cell size and judicious refinement resulting in 80% of cell count reduction. There is one major benefit of Quadtree regardless in that in nearly always has a much smaller GPU RAM memory footprint because unused 2D cells within the bounding rectangle used by a HPC grid are not stored in memory whereas for a grid they are.

I'm using SGS and my water level extent is larger than depth extent. Why?

For map outputs, the default for SGS models is to treat whether a 2D cell is wet or dry differently for water level surfaces compared to other map outputs. For water level surfaces a cell is wet if any part of the cell is wet (based on the lowest elevation from the SGS sampling), therefore, all partially wet cells are flagged as wet and will appear wet in the XMDF and other map output. The advantages here are as a modeller you can see which cells are wet even if they are only partially wet, and there is no need to buffer the water level surface for high quality mapping produced by subtracting the DEM from the water level surface. For all other map outputs a cell is deemed wet only if the water level in the cell exceeds the SGS elevation at the 2D cell centre. This was necessary as otherwise greatly distorted depth, hazard and other outputs could occur by taking the depth at the lowest part of the cell based on the SGS sampling. There are a range of commands that allow you to adjust the default settings for map outputs using SGS. For a more detailed discussion and a description of these new commands see Section 7.5 in the 2020-01 Release Notes.
Note there is a new remap function as a part of the asc_to_asc utility that can be used to post-process the result grids using a finer resolution DEM to produce high resolution mapping. See TUFLOW Remapping.

Why should I create more Z Shape ridge/max lines with SGS models?

When the SGS parameters are being processed, every cell face will store its own curve of flow area versus elevation. TUFLOW doesn’t actually know the location in the cell or along the cell face where the lower elevations are, it just parametrises that they exist. As such, SGS isn't a grid within the model grid. It allows water to flow from low point to low point within the same cell even if there is higher point in between them.
Without breaklines SGS will be more likely to allow "leaks" through a levee or embankment compared to running the model without SGS. This is because SGS sampling will pick up lower elevations either side of the levee where the 2D cell extends over both sides of the levee, and therefore produce lower flowpaths through the levee or embankment. Therefore, the need to represent all hydraulic controls such as levees (artificial or natural), road/rail embankments, etc is even more important for SGS models (this practice should be carried out for all TUFLOW models, but even more so for SGS models). In summary, it is highly recommended to add 2d_zsh ridge/max line for every levee, road/rail embankment, etc in SGS models to achieve closer results with non SGS models.
The breakline feature in asc_to_asc utility can be very useful for easily creating breaklines from a DEM.
For Z shape polygons raising elevation, if the high ground ridge of the polygon isn't aligned exactly with the cell face, there will be lower elevation values in the SGS cell face width versus depth curve which could let water to leak. To overcome this, Z shape ridge line should be used along the Z shape polygon perimeter to enforce its shape.

Why shouldn't I use Z Shape gully/min lines with SGS models?

When the SGS parameters are being processed, every cell face will store its own curve of flow area versus elevation. TUFLOW doesn’t actually know the location in the cell or along the cell face where the lower elevations are, it just parametrises that they exist. As such, SGS isn't a grid within the model grid. It allows water to flow from low point to low point within the same cell even if there is higher point in between them. It automatically defines the minimum flow paths.
If the DEM is fine enough, SGS can preserve the gully along the cells without using any gully line. In such case using a gully line may overestimate the width of the flow path. By default, a gully line applies a gradient along the faces based on the cell corners and cell side Zpt values, and creates sloping cells using the ZC, ZU, ZV and ZH values. This effect will get more pronounced when cell sizes are increased, e.g. wider unrealistic flow path is created when gully lines are still used in the model.

400px

If I run one SGS model, double the cell size and run it again, will I get the same results?

Firstly, you'll never get identical results - this will never happen with any hydraulic modelling software. However, using SGS greatly improves your results convergence when changing cell sizes, therefore you're much more likely to be able to demonstrate results consistency between the two runs if using SGS. Of importance is that your hydraulic controls are well-defined using breaklines as discussed above - ensure this is the case before running the two simulations. Note as discussed further above that there is only one velocity calculated per cell face (this is a depth and width averaged velocity) - increasing the cell size with SGS on may produce consistent water level and flow results, but you will see a smoothing of your velocity based map outputs as the velocity for the larger cell size will be based on that over a larger flow area. If there are significant velocity gradients across the channel you might need to use a finer resolution to achieve results convergence. Finally, as always, simply run both simulations and spend some time comparing your results in your focus area(s) to ensure the coarser cell size is not adversely affecting your modelling, but you should expect to see a much improved results convergence using SGS.

My HPC model runs with double precision, using SGS the model initialisation slows down significantly. Why?

Due to an Intel compiler issue the grid inspection has to be carried out with un-optimised code and will be slow. However, note that the HPC solution scheme (including Quadtree) doesn't generally require double precision engine. Also, if XF files are enabled (default), subsequent initialisations will be much faster.

Do I need to use "SXL" option for pits and why my model is causing "pit inlet level" error?

In non-SGS models, the "SXL" option is often used to lower the pit ground level to improve flow capture. However, an SGS model creates evaluation-storage relationships at cells based on the underlying DEM and is naturally better at capturing flows at pit inlets. Therefore "SXL" option is not necessary in an SGS model if the DEM is fine enough. On the other hand, users may receive "ERROR 1278 - Pit <pit ID> inlet level is below lowest channel/pipe bed." after converting a working non-SGS model to an SGS model. Since the lowest elevation sampled inside a cell is used as the “pit inlet level”, an SGS model might picked up an elevation lower than the pipe invert level. In such case, the "US_Invert" attribute of the 1d_nwk GIS layer can be used to manually specify the ground elevation of the pit.