View source for TUFLOW Output Discussion

= Common Questions Answered (FAQ)=
== Why are grid outputs (ASC, FLT) slightly different from mesh outputs (XMDF, DAT)? ==
Slight differences are expected between the result grids (ASC or FLT) and mesh results (XMDF or DAT) due to small differences in the interpolation method.
* When outputting directly to FLT or ASC using the <font color="blue"><tt>Map Output Format</tt></font> command, the output grid results are derived from both the cell centres and cell corners and the final results has those values interpolated to the centres of half cells (by default).
* When outputting XMDF (or DAT) format, the mesh results are derived from cell centres for depths / levels and cell sides for vector data. The final XMDF stores data interpolated to the cell corners and doesn’t have any memory of where the corner data were derived from and what those values were.
The differences can also be amplified when the rotation of the model is not perfectly north-south aligned (i.e., a non-zero orientation).<br>

== Why are grids processed with TUFLOW_to_GIS different from TUFLOW grids? ==
Slight differences are expected between the result grids (ASC or FLT) produced directly from TUFLOW and post-processed from the TUFLOW_to_GIS utility from XMDF or DAT due to differences in the interpolation approach.
Check <u>[[TUFLOW_Output_Discussion#Why_are_grid_outputs_.28ASC.2C_FLT.29_slightly_different_from_mesh_outputs_.28XMDF.2C_DAT.29.3F | Why are grid outputs (ASC, FLT) slightly different from mesh outputs (XMDF, DAT)?]]</u> question above on differences between outputs direct from the TUFLOW Engine.<br>
When ASC/FLT results are sampled from the XMDF files with the TUFLOW_to_GIS utility, it uses less data points than when the grids are written directly from TUFLOW. 

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>

== Why is Z0 hazard coming directly from TUFLOW different to the one calculated from maximum velocity and depth? ==
The maximum velocity and maximum depth doesn’t necessarily occur at the same time. The Z0 hazard written directly from TUFLOW has the depth x velocity calculated every timestep and at the end outputs the maximums of all the timesteps. When using the velocity and depth grids the maximum velocity is always used with maximum depth. <br>
Outputting the Z0 hazard grid directly from TUFLOW is more accurate, however, if this is not an option, manual creation is an acceptable workaround. The general recommendation is to choose one method and keep it consistent for the length of the project.<br>
When calculating the Z0 hazard from the velocity and depth, the grids have already been interpolated by TUFLOW before the raster calculation (less data is used for the calculation), whereas the TUFLOW Z0 output is interpolated from the calculated data directly. Please also refer to the above question for more information <u>[[TUFLOW_Output_Discussion#Why_are_grid_outputs_.28ASC.2C_FLT.29_slightly_different_from_mesh_outputs_.28XMDF.2C_DAT.29.3F | Why are grid outputs (ASC, FLT) slightly different from mesh outputs (XMDF, DAT)?]]</u>.<br>

== 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 because grid files are north-south aligned.<br>

== Why are results from 2d_po features, POMM.csv and plots extracted from XMDF in GIS package not matching? ==
There are numerous reasons for the outputs to not be matching:
* Plot output:
** The 2d_po results are tracked at every <font color="blue"><tt>Time Series Output Interval</tt></font> and saved into the PO.csv file. If the water level peaks in between the intervals, that maximum water level won’t be recorded in the PO.csv.
** 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.
* Although the maximums from POMM.csv and the maximum map output will be very close, they won't match exactly.

Further notes for using post-processed flux line:
* No information is stored in the map output about whether the flow is upstream or downstream controlled.
* The staggered computational grid means there is always some interpolation occurring when projecting levels and velocities to the flux line. This will cause significant uncertainty in areas of sudden topographic change such as at an embankment.  It is also the reason that two similar lines side by side may provide different outputs.
* Highly variable/complex flows, which are usually associated with highly variable topography, will add to the uncertainty when interpolating to the flux line.

The general recommendation is to use a lot of 2d_po features with reasonably small <font color="blue"><tt>Time Series Output Interval</tt></font> to achieve better accuracy, they won't slow the simulation down. In case of flux lines, the 2d_po lines are using the actual computed fluxes across each cell face and will be an exact representation of the flow being calculated by the 2D solver. Post-processed fluxes should only be located in areas of little topographic change and even then, used as a rough guide.<br>

== Why are my TIF raster outputs not updated after a model rerun? ==
The GeoTIFF raster output is supported from the 2023-03 Release and onwards. It is considered an image by File Explorer and for some users, the 'Date' in file explorer defaults to show the 'Date Created' rather than the 'Date Modified'. If it appears that your results in the 'Results' folder (e.g. XMDF) are being updated however the results in the 'Results/grid' folder (e.g. TIF) aren't, this may be the reason. <br><br>
To confirm, turn on both 'Date Created' and 'Date Modified':<br>
[[File:TIF Date 01.png | 500px]]<br><br>
The 'Date Modified' column will show the date of the last model run:<br>
[[File:TIF Date 02.png | 500px]]<br>
<br>

== How do I apply high resolution (HR) output and what are the options? ==
See the <u>[[TUFLOW_HR_Output | TUFLOW HR Output]]</u> Wiki page for details.<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>
 
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 of TUFLOW version 2025.1.1, there is a current limitation affecting result outputs for shallow sheet flow cells on steeper terrain in sub-grid sampling (SGS) enabled models. Direct rainfall models are particularly prone to producing substantial areas 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]]
}}