TUFLOW Output Discussion: Difference between revisions
Content deleted Content added
No edit summary |
Anne.Kolega (talk | contribs) m →How to create a maximum grid for datasets without direct maximum output from a TUFLOW run?: deleted a comma |
||
| (31 intermediate revisions by 4 users not shown) | |||
Line 12:
The differences can also be amplified when the rotation of the model is a non-zero value.
The extent of the grids is also different. When TUFLOW starts, it removes any redundant areas (if any) outside of 2d_code layer to reduce the calculation time:
* The extent of grids written directly from TUFLOW works with the unreduced area, encapsulating the entire rotated model domain in a north-south orientated rectangle.
* The extent of XMDF (or DAT) results is based on the reduced area. When the TUFLOW_to_GIS utility is used, the post-processed north-south aligned grids encapsulate the reduced model extent. The origin coordinates of such grids doesn't match the origin of the model (model domain), neither the grids written out from TUFLOW directly.
In general, a better interpolation of results is achieved when the grids are written directly from TUFLOW than when post-processed with TUFLOW_to_GIS utility. Importantly, when comparing results the recommendation is to be consistent and to use the same method for the duration of a project to ensure there are no differences as a consequence of the post-processing method.<br>
Line 24:
== Why does hazard output (Z1, Z2, ...) show float values and not just integers? ==
The hazard values are calculated in cell corners and are in a form of an integer. When the values are processed into a grid, which has, by default, a resolution of half the cell size, the values are interpolated to the cell centres - four cell centre values per cell. Further interpolation occurs when the model has a non-zero orientation
== Why are results from 2d_po features, POMM.csv and plots extracted from XMDF in GIS package not matching? ==
Line 32:
** The POMM.csv tracks maximums of PO features at every computational timestep.<br>
* Map output:
** The temporal XMDF (or DAT) results are tracked every <font color="blue"><tt>Map Output Interval</tt></font> and interpolated to the cell corners.
** The maximum XMDF map output records the value at every computational timestep, however the final maximum map output is also being interpolated to the cell corners.<br>
** The extraction tools in GIS packages use interpolated data for the plot creation, e.g. less data than the TUFLOW direct plot output.
Line 52:
<br>
==
See the <u>[[TUFLOW_HR_Output | TUFLOW HR Output]]</u> Wiki page for details.<br>
Differences are expected between the direct HR output and the [[ASC_to_ASC#Remap | remap function]] in the asc_to_asc utility due to the different steps involved in the interpolation of water level results. <br>▼
== Why are there differences between high resolution grid from TUFLOW and remapped outputs generated by the asc_to_asc utility? ==
▲Differences are expected between the direct HR output and the <u>[[ASC_to_ASC#Remap | remap function]]</u> in the asc_to_asc utility due to the different steps involved in the interpolation of water level results. <br>
The direct HR output is based on a triangulation of the water levels at the cell centres and corners. In comparison, the remap function involves two interpolation steps. The first is the interpolation from the cell centres and corners to the grid map output locations (by default, half the cell size). Then, the asc_to_asc utility interpolates the water level output to the target DEM grids with fine resolution: <br>
[[File:High-res-interpolation.jpg|600px]]<br>
Line 59 ⟶ 62:
The direct HR output tends to have better resolution in comparison to the remapped results. Due to the additional stages of interpolation involved with the remapped output, there is potential to lose definition in the results particularly in areas with steep slopes.
==How to create a maximum grid for datasets without direct maximum output from a TUFLOW run?==
For cumulative datasets without direct maximum output (e.g. cumulative infiltration, cumulative rainfall etc), the map output interval in the TCF needs to match the simulation end time in seconds. The end time output is when the maximum occurs for cumulative datasets, as it represents the cumulative results over the entire simulation duration.
For non-cumulative datasets without direct maximum output (e.g., Froude number, rainfall rate etc):
*Adjust the <font color="blue"><tt>Map Output Interval</tt></font> in the TCF to a small value to ensure temporal variations are captured.
*Specify XMDF for <font color="blue"><tt>Map Output Format</tt></font>.
*Identify the output ID number of the desired dataset within the .xmdf file:
<pre>"C:\TUFLOW\Releases\res_to_res\res_to_res_w64.exe" -xnfo results.xmdf</pre>
*Extract maximum values using the <u>[[RES_to_RES#Introduction | RES to RES]]</u> utility.
*Confirm the dataset's output ID number in the resulting (maxmax).xmdf file:
<pre>"C:\TUFLOW\Releases\res_to_res\res_to_res_w64.exe" -xnfo (maxmax).xmdf</pre>
*Convert the resulting dataset to a preferred grid format for GIS using the <u>[[TUFLOW_to_GIS#Introduction | TUFLOW to GIS]]</u> utility.
:Note: For non-cumulative datasets, this method does not capture the true maximum, however can be close enough with a fine map output interval.
== Why are the values of the mapped water level results (h_max) lower than the terrain elevations (DEM_Z)? ==
As at TUFLOW Build 25.1.1, there is a current limitation for result outputs at shallow sheet flow cells on steeper terrain in sub-grid-scale (SGS) enabled models. Direct rainfall models are particularly prone to result in substantial extents of shallow sheet flow.
In TUFLOW HPC, the cell averaged depth is used computationally and by default in the depth outputs (see below).
Water level outputs, however, assume that water fills from the bottom of the SGS cell’s storage curve. This water level result is recorded at the cell centre, interpolated to the cell corners, and then the gridded outputs are triangulated from these points (orange line). In sheet flow situations when the volume in that cell is small, the cell-centered water level may sit below the terrain (blue dot on diagram) if the cell is steep enough. This can result in a water level results sitting below the DEM_Z, even when there is a positive depth result. Note this does not affect the simulation computationally, only how the water level results are output. <br>
[[File:SGS_Sheetflow_Waterlevel.jpg|600px]]
== The modelled water surface level is below the SGS cell elevations. How should this result be interpreted or presented? ==
Below ground WSE in wet SGS cells is a known output behaviour in SGS enabled models and does not indicate an error in the hydraulic solution.
This occurs because TUFLOW reports water level assuming water fills from the lowest part of the SGS cell during output. As a result, cells may be wet while the reported WSE remains below the cell centre ground level.
This behaviour commonly occurs in the following situations:
'''Channel edge partial wetting'''
* Partially wet cells along channel banks may contain water that does not reach the cell centre elevation.
* In this case, compare the standard WSE with the standard DEM_Z check file to confirm consistency with terrain levels.
'''Shallow sheet flow from rainfall or side inflow'''
Cells may be wet but still report WSE below the cell centre ground level because the depth is small and distributed across the SGS terrain.
'''Presentation and reporting considerations'''
* A presentation method is to post process results by adding the cell averaged depth output <font color="blue"><tt>SGS Depth Output</tt></font> <font color="red"><tt>==</tt></font><tt> CELL AVERAGE</tt> </font>to the DEM elevation to derive an above ground water level.
* This approach can improve the visual representation of shallow flooding in sheet flow areas but may produce unrealistic water levels in fully wet or partially wet cells.
* Conditional IF logic may be required to choose where to present cell averaged depth plus DEM and where to retain the standard TUFLOW water level output.
== Why do the high-resolution (HR) mapped results have a significantly smaller extent than the standard (non-HR) grid outputs for a sub-grid-scale (SGS) direct rainfall HPC model? ==
The high resolution (HR) outputs are based on <u>[[TUFLOW_HR_Output | intersecting]]</u> the standard water level output results with the HR DEM_Z. Due to the <u>[[TUFLOW_Output_Discussion#Why_are_the_values_of_the_mapped_water_level_results_.28h_max.29_lower_than_the_terrain_elevations_.28DEM_Z.29.3F | output limitation]]</u> for sub-grid-scale (SGS) enabled models with shallow sheet flow (particularly direct rainfall models) on sufficiently steep terrain, water levels can be output lower than the DEM_Z terrain elevations. This is due to the assumption (for output purposes) that water fills the SGS cell’s storage curve from the bottom, which differs from the approach of cell-average depth used computationally in TUFLOW HPC and by default in depth outputs. When the HR water level results are processed, the full extent of the water level results are intersected with the HR DEM_Z and any water level results that are lower than the HR DEM_Z elevations due to the above effect are trimmed. The extent of the HR water level results are then used to trim the HR depth outputs.
== When should high-resolution (HR) outputs be used, and what are their limitations? ==
HR outputs are intended for visualisation and presentation because they retain sub-grid terrain detail but do not improve the underlying hydraulic calculations.
They are not suitable for assessment, benchmarking, or detailed analysis. Standard non-HR map outputs should be used for these purposes, and accuracy should be improved by refining the 2D cell size.
{{Tips Navigation
|uplink=[[TUFLOW_Modelling_Guidance | Back to TUFLOW Modelling Guidance]]
| |||