TUFLOW Output Discussion: Difference between revisions
Content deleted Content added
No edit summary |
|||
| (8 intermediate revisions by 2 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 64:
==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.
For non-cumulative datasets without direct maximum output (e.g., Froude number, rainfall rate etc):
Line 74:
*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
:Note: For non-cumulative datasets, this method does not capture the true maximum, however can be close enough with a fine map output interval.
Line 80:
== Why are the values of the mapped water level results (h_max) lower than the terrain elevations (DEM_Z)? ==
As
In TUFLOW HPC, the cell averaged depth is used computationally and by default in the depth outputs (see below).
Line 87:
[[File:SGS_Sheetflow_Waterlevel.jpg|600px]]
==
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
This behaviour commonly occurs in the following situations:
Line 97:
* Partially wet cells along channel banks may contain water that does not reach the cell centre elevation.
* In this case, compare the standard
'''Shallow sheet flow from rainfall or side inflow'''
Cells may be wet but still report
'''Presentation and reporting considerations'''
* A presentation method is to post process results by adding the
* 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
== 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? ==
| |||