Quadtree and Sub-Grid Sampling FAQ

This Page is under construction

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

Even when using SGS to improve conveyance, only one velocity is used for the whole cell. Every model has a cell size range, from very fine to very coarse, beyond which it just doesn't make any sense to go. Cell size sensitivity testing is recommended to establish this range.

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

Not necessarily. By default, running model on a mesh (Quadtree) rather than a grid (HPC) is always slower, on average 20%. Quadtree really comes into an effect once there is at least three levels of cell size and judicious refinement - around 80% of cell count reduction. As Quadtree development is an ongoing task this might further improve in the future.

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

The main advantages of using Quadtree are shorter run times (with considerable cell count reduction) and smaller size of output files. If longer run times of model without Quadtree are not an issue and output file sizes are fine then there is no strong argument to use Quadtree. Some models with cell count reduction only around 30% might be even running slower with Quadtree than the original HPC model.

The resolution of my underlying DEM is 1m and model cell size is 1m. Is there any benefit to use SGS?

No. The SGS sample points within once cell would have the same elevation, so there wouldn't be any precision benefit and the model will have longer initialisation time.

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.