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 Map Output Format 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).

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 Why are grid outputs (ASC, FLT) slightly different from mesh outputs (XMDF, DAT)? question above on differences between outputs direct from the TUFLOW Engine.
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.

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.
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.
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 Why are grid outputs (ASC, FLT) slightly different from mesh outputs (XMDF, DAT)?.

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 as grid files are north-south aligned.

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 Time Series Output Interval 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.
    
• Map output:
  • The temporal XMDF (or DAT) results are tracked every Map Output Interval 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.
    
  • 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 Time Series Output Interval 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.

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.

To confirm, turn on both 'Date Created' and 'Date Modified':


The 'Date Modified' column will show the date of the last model run:

How do I apply high resolution (HR) output and what are the options?

See the TUFLOW HR Output Wiki page for details.

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 remap function in the asc_to_asc utility due to the different steps involved in the interpolation of water level results.
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:

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.

Up
Back to TUFLOW Modelling Guidance