xpswmm/xpstorm Resource Center xps

XPSWMM and XPStorm 2020.1 Quadtree and Sub-Grid Sampling (SGS) Frequently Asked Questions (FAQ):


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

Quadtree (Multiple Domain module required) and SGS are currently only supported by the XP2D Extreme Engine. This is introduced in XPSWMM/XPStorm 2020.1. The features are currently not available using XP2D or XP2D Classic. 

Quadtree and SGS Surface Recommendations

XPSWMM/XPStorm default setting to pass the surface to the XP2D Extreme Engine is set to "Use DTM".   This setting, when SGS is enabled, will export the XPTIN format to LandXML.  It is recommended that users select "Use Grid file for topography" when substantial terrain surfaces are used.  For performance reasons in XP2D Extreme with Quadtree & SGS, we recommend using the Binary Float file (FLT). 

XPSWMM and Multiple Surfaces

XPSWMM/XPStorm 2020.1 will export a LandXML file when SGS is enabled that contains the two or multiple XPTIN Surfaces.   The XP2D Extreme engine will recognize this file format, and properly sample the LandXML surface data given the required sample distance.

How coarse can the base cell size be for a Quadtree model with SGS?

A well-designed model mesh is one where you can decrease cell 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 answer to that question depending on your modeling 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 are considered unacceptable, then you need to possibly make your cell sizes smaller (not larger!). 

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 XPSWMM/XPStorm 2020.1 release allows for up to nine levels of nesting, so your smallest cell size can only be one-eighth of your base cell size.   Quadtree requires the multiple domain module.

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

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

When should I not use Quadtree (Multiple Domain Module required)?

The main advantages of using Quadtree are shorter run times (with considerable cell count reduction compared with using an XP2D Extreme 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 XP2D Extreme model.

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

Based on the benchmarking performed by Tuflow 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 XPSWMM/XPStorm 2020.1 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 an XP2D Extreme 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 would not be any precision benefit and the model will have an unnecessarily longer initialization time. 

Does using SGS increase model runtimes?

Turning on SGS will 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. In Tuflow testing of 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 the 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 modeling using coarser cell sizes by using SGS without greatly changing results, your workflow efficiency can be greatly enhanced. 

I'm using SGS and my water level extent is larger than the 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 results file (XMDF) and other map output. The advantages here are as modeler 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 center. 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 is 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 TUFLOW 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.

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 with cells without using any gully line. In such a 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?

Without breaklines, SGS will be more likely to allow "leaks" through a levee or embankment compared to running the model without SGS. SGS sampling will pick up lower elevations on either side of the levee where the 2D cell extends over both sides of the levee, and therefore produce lower flow paths 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 XPSWMM/XPStorm 2D models, but even more so for SGS models). The breakline feature in [[ASC_to_ASC | asc_to_asc utility]] can be very useful for easily creating break lines from a DEM. 

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 modeling 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 break lines 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 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 modeling, but you should expect to see a much-improved results convergence using SGS. 

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

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


Thanks to Tuflow for much of their expertise on the FAQ noted above.  https://wiki.tuflow.com/index.php?title=Quadtree_and_Sub-Grid_Sampling_FAQ