Quadtree and Sub-Grid Sampling FAQ

This Page is under construction

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's 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.

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

Not necessarily. By default, running a model with a 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.

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.

Why I should 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 the 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 further supports the case of using SGS as it is very likely 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) by using SGS. 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.

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 byt 20-30%, but in some cases the improvement in model stability can actually cause a reduction in run times. Also, being able to go to a larger grid size and still keep the hydraulic accuracy means that runs can be performed much faster.

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

The default for SGS models is to map the water level in its full extent and the rest of the data types as trimmed. This can be changed with the below commands:
SGS Map Extent Trim == All
SGS Map Extent Full == h d v
For more information see section 7.5.4 in the 2020-01 Release Notes - to be changed to the Manual.
Remap function that is part of the asc_to_asc utility can be used to post-process the result grids to a finer resolution DEM. See TUFLOW Remapping.

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

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 as it makes the entire cell and face flat.

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

It is possible that without correct breaklines, SGS model allows a leak over a levee or embankment that model with smaller cell size does not or does much less. The more 2d_zsh max/ridges are used the better. A rough estimate of SGS testing required twice the number of ridge lines compared to a traditional model. This also includes locations where there were no ridges previously. Breakline feature in asc_to_asc utility might be useful for creating additional breaklines.
The reason for this is that SGS doesn't know where in the cell the low elevations and high elevations are, so it smooths out the breaklines. It allows water to flow from low point to low point within the same cell even if there is higher point in between them.

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

SGS isn't a silver bullet that resolves all. If the hydraulic controls aren't adequately defined by the chosen cell resolution the results will vary until the said features are defined by the mesh adequately. Check the gully lines and ridge lines questions above. For a situation where there is little variation in velocity across channel the results might be impressive. In the real world, where there are significant velocity gradients across the channel the modeller might need to use a finer resolution to converge to a solution.

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

Due to an Intel compiler issue this grid inspection has to be done with un-optimised code and will be slow. HPC solution scheme doesn't generally require double precision engine. If XF files are enabled (default), subsequent initialisations will be much faster.
The need for using double precision with HPC should be revisited. From experience the models that still require double precision when using HPC are models with carved 1D channels. Either the channel itself is causing the mass error or the boundary links between 1D and 2D domain do. Unfortunately, it is not possible to run the 1D engine in double precision and 2D engine in single precision for the same model. There are two ways how to go about this, we would recommend the second one:

• Try to improve stability of the 1D features and 1D/2D links so it would perform well in single precision. The _TSMB and _TSMB1d2d layers might help locating specific features that could be worked on. The drawback of this suggestion is that it might be very time consuming to achieve even a small improvement and sometimes it is just not possible to get the mass error low enough.
• Remove 1D channel completely and use Quadtree mesh to sufficiently refine resolution of the creek in 2D.