FV User Manual 2019.01
FV User Manual 2019.01
Material Commands
Build 2019.01 Boundary Commands
Manual Overview
This document is the User Manual for the TUFLOW FV hydrodynamic computational engine 2019-01
release. The table below provides a quick reference to TUFLOW FV’s control file and commands. Each
chapter heavily references Appendix A, Appendix B and Appendix C which contain the command
syntax for TUFLOW FV.
Command Description Chapter
Category
Introduction Overview of flexible mesh modelling, the TUFLOW FV solution Chapter
scheme and benchmark studies used to verify TUFLOW FV’s 1
performance.
Running TUFLOW TUFLOW FV software structure, its installation process, licensing Chapter
FV and running simulations. 2
The Modelling A high-level overview of the modelling process. If you are new to Chapter
Process modelling it is recommended to read through this chapter first prior 3
to proceeding with other sections of the manual.
Model Setup and Recommended layout and syntax used in the TUFLOW FV control Chapter
Control Files file. 4
GIS Setup GIS format, spatial reference assignment, empty file creation. Chapter
5
Simulation Solution include statements, spatial order selection, units selection, Chapter
Configuration coordinate type, bed roughness model. 6
Time and Time format and reference time, model start and end times, CFL Chapter
Timestep limits, timestep limits. 6
Model Parameters Wetting / drying, turbulence related commands, stability limits, Chapter
reference values. 7
Hydraulic Weirs, culverts, bridges, porous and wall structures, operational Chapter
Structures structures and controls. 11
Model Results and Output directory, map output formats and data types Chapter
Output check files, time series and profile outputs, logging and diagnostics. 12
Section, Table and Figure references are styled like this and linked. In Word, to go to the link hold
down the control (Ctrl) key and click on the Section, Table or Figure number in the text to move to the
relevant page. In pdf, the links should be directly accessible.
Similarly, and most importantly, script or control file commands are hyperlinked and are easily accessed
through the lists at the end of the manual. To quickly go to the end of the manual press Ctrl End. There
are also command hyperlinks within the text (normally blue and underlined). Command text can be
copied and pasted into the text files to ensure correct spelling.
Web and email links are styled like this. An increasing amount of content now resides on the TUFLOW
Wiki with web links provided in the document to these pages. Other useful keys are Alt Left / Right
arrow to link backwards / forwards to the last locations. Ctrl Home returns to the front page, which also
contains useful links.
A secondary window can be opened in Word by selecting View, New Window or in Adobe Acrobat by
selecting Window, New Window, allowing you to view different sections of the document in different
windows. For example, the TUFLOW command lists could be viewed in one window and the section
describing the functionality in another window.
If simulating models using prior TUFLOW FV builds, reference may need to be made to the release
notes and documentation relevant for that particular build. These can be downloaded from the All
TUFLOW Downloads page or requested from [email protected].
Chapters
1 Introduction 1-1
9 Modelling in 3D 9-1
Table of Contents
1 Introduction 1-1
1.1.1 Introduction 1-2
1.2 TUFLOW FV 1-4
1.2.1 Flexible Mesh Modelling 1-5
1.3 Solution Scheme 1-6
1.3.1 Non-Linear Shallow Water Equations 1-6
1.3.2 Scalar Conservation Equations 1-7
1.3.3 Conserved vs. Scalar Variables 1-8
1.3.3.1 Conserved Variables 1-8
1.3.3.2 Scalar Variables 1-8
1.4 Schematisation 1-9
1.5 Multi-Core Processing 1-10
1.6 UK Benchmarking Study 1-11
9 Modelling in 3D 9-1
9.1 Introduction 9-2
9.2 Overview 9-3
9.3 3D Layer Z Coordinate Options 9-4
Sigma Coordinates 9-6
Z Coordinates 9-7
Hybrid Z-Sigma Coordinates 9-7
9.4 Density Coupling 9-9
9.5 Reviewing 3D Results 9-10
9.6 3D Boundary and Initial Conditions 9-11
9.7 3D Structure Conditions 9-12
Appendices
.fvc File Commands A-1
List of Figures
Figure 1-1 Schematisation of Common TUFLOW Flexible Mesh Solver Features 1-3
Figure 1-2 Schematisation of Common TUFLOW Fixed Grid Solver Features 1-3
Figure 1-3 Cell Schematisation 1-9
Figure 1-4 Example decrease in runtime using TUFLOW FV multi-thread processing 1-10
Figure 3-1 Digital Elevation Model of Port Curtis, Queensland, Australia 3-6
Figure 3-2 TUFLOW FV Mesh of Port Curtis Estuary, Queensland, Australia 3-7
Figure 3-3 Example Tidal Water Level Timeseries Calibration Plot 3-14
Figure 3-4 Example Current Speed and Current Direction Timeseries Calibration Plots for
a Tidal Estuary 3-14
Figure 3-5 Example Flow Timeseries Calibration Plots for a Tidal Estuary 3-15
Figure 4-1 Example TUFLOW FV Sub-Folder Structure 4-3
Figure 4-3 Example TUFLOW FV Control File using Include command 4-11
Figure 4-4 Contents of Materials.fvc called via Include command 4-11
Figure 4-5 Example TUFLOW FV Simulation Control File 4-13
Figure 6-1 1st (left) and 2nd (right) Order Velocity Results Dambreak Flow 6-5
Figure 6-2 TUFLOW FV Mode Split Timestepping 6-11
Figure 8-1 Mesh Development Example 8-3
Figure 8-2 Example 2dm File 8-4
Figure 8-3 Example Node Definition 8-5
Figure 8-4 Example Quadrilateral Element Definition 8-5
Figure 8-5 Example Triangular Element Definition 8-5
Figure 8-6 Example Nodestring Definition 8-6
Figure 8-7 Cell Centre Elevations Assigned via Read GRID Zpts 8-8
Figure 8-8 Cell Elevation Polyline Example 8-11
Figure 8-9 Cell Elevation Polygon Example 8-11
Figure 8-9 Materials Specification using 2d_mat GIS Layers 8-12
Figure 9-1 3D Model Vertical Discretisation Options 9-4
Figure 9-2 Hybrid Z-Sigma example setup (left) with z layer face file (right) 9-8
Figure 9-3 Salinity long section in coastal ‘salt wedge’ estuary. 9-9
Figure 9-4 Counter current velocity at depth. Considerations for result depth averaging. 9-
10
Figure 10-1 Boundary Condition Block Examples 10-3
Figure 11-6 Auto Weir Example 11-5
Figure 11-1 Structure Block Example 11-9
Figure 11-1 hQh Structure Example 11-12
Figure 11-2 hQh Calculation Design Options 11-13
List of Tables
Table 1-1 Table Summary of United Kingdom Environment Agency Benchmark Tests 1-
12
Table 2-1 Suggested Supporting Software 2-3
Table 2-1 TUFLOW FV Tutorial/Demo Models 2-10
Table 4-1 Recommended TUFLOW FV Sub-Folder Structure Description 4-4
Table 4-2 TUFLOW FV File Formats 4-5
Table 4-4 Reserved Characters – Text Files 4-9
Table 4-4 Notation Used in Command Documentation – Text Files 4-10
Table 4-5 TUFLOW FV Simulation Control File Layout 4-12
Table 5-1 TUFLOW Interpretation of GIS Objects 5-3
Table 5-2 GIS Input Data Layers and Recommended Prefixes 5-5
Table 6-1 Solution Include Terms 6-3
Table 6-2 Model Units 6-6
Table 6-3 Wind Stress Model and Drag Coefficients 6-9
Table 8-1 GIS Nodestring (2d_ns) Attributes 8-7
Table 8-2 2D Z (2d_z_) Attribute Description 8-9
Table 8-3 Cell Elevation File Examples (the example on the left references X,Y co-
ordinates and the one on the right uses Cell ID) 8-10
Table 8-4 2D Material (2d_mat) Attribute Description 8-13
Table 9-1 3D Geometry Layer Options 9-6
Table 10-1 Grid Definition Block Commands 10-12
Table 10-2 Boundary Condition Types 10-18
Table 10-3 Boundary Condition Types (Advanced) 10-19
Table 10-4 Boundary Sub-types 10-22
Table 11-1 Flux Function Types 11-10
Table 11-2 1D Culvert Flow Regimes 11-17
Table 11-3 Culvert File Inputs 11-20
Table 12-1 Output Data Formats 12-3
Table 12-2 Flux and Mass Outputs 12-6
Table 12-3 Common Map Output Types 12-16
Table 12-4 Advanced Map Output Types 12-16
Table 12-5 Sediment Transport Map Output Types 12-20
Table 12-5 GIS Check Files 12-26
Attribute Data associated with / or attached to a GIS object. For example, an elevation is
attached to a point using a column of data named “Height”. The “Height” of
the point is an attribute of the point.
control file Text file containing a series of commands (instructions) that control how a
simulation proceeds or a 1D or 2D domain is built.
.dbf Industry standard database file format used by ESRI GIS .shp layers to store
attribute data.
GIS Geographic Information System, for use in TUFLOW modelling it will need to
be able to import/export files in .mif or .shp format.
Read GIS The TUFLOW command “Read GIS <data type> ==” is used to input
spatial data into TUFLOW. For example, Read GIS Nodestring ==
2d_ns_myboundaries.mif Would be used to read nodestring location
data.
land cell A land cell is one that will never wet, ie. an inactive cell.
Line A GIS object defining a straight line defined by two points. See also, polyline
(Pline).
.mid MapInfo Industry standard GIS import/export file that contains the attribute
data of geographic objects in a .mif file. The .mif and .mid files are a pair, and
can’t be opened in GIS unless both files are present.
.mif MapInfo Industry standard GIS import/export file that contains the attribute
data types and the geographic coordinates of objects. The attribute data of the
objects is stored in the .mid file by the same filename.
Node in a model mesh used for viewing 2D results in SMS. The nodes are
located at the cell corners.
null cell A null cell is an inactive 2D cell used for defining the inactive side of an
external boundary.
Point GIS object representing a point on the earth’s surface. A point has no length or
area.
polyline (or Pline) A GIS object representing one or more lines connected together. A polyline
has a length but no area.
Region A GIS object representing an enclosed area (ie. a polygon). A region has a
centroid, perimeter and area. Polygons can have internal holes.
.shp ESRI GIS layer file containing the geographic coordinates of objects. This is
referred to as a Shapefile, however, a GIS dataset in Shapefile format will also
contain a number of additional file (.dbf, .shx, .prj).
Snap When geographic objects are connected exactly at a point or along a side.
ArcMap, QGIS and MapInfo all have a “snap” feature, which ensures the
features have the same coordinates. The snap tolerance can be changed in
TUFLOW using the Snap Tolerance command.
Soffit The elevation of the underside of a bridge deck or the inner top of a culvert.
Same as obvert. Note this manual uses the term obvert.
1 Introduction
Chapter Contents
1 Introduction 1-1
1.1.1 Introduction 1-2
1.2 TUFLOW FV 1-4
1.2.1 Flexible Mesh Modelling 1-5
1.3 Solution Scheme 1-6
1.3.1 Non-Linear Shallow Water Equations 1-6
1.3.2 Scalar Conservation Equations 1-7
1.3.3 Conserved vs. Scalar Variables 1-8
1.3.3.1 Conserved Variables 1-8
1.3.3.2 Scalar Variables 1-8
1.4 Schematisation 1-9
1.5 Multi-Core Processing 1-10
1.6 UK Benchmarking Study 1-11
1.1.1 Introduction
TUFLOW Products are a suite of world leading urban drainage, catchment flood and coastal simulation
software. It is developed through collaboration with universities and our users. We deliver software of
high scientific standard, that is rigorously benchmarked, practical, and workflow efficient.
1) TUFLOW’s Flexible Mesh Solver, TUFLOW FV, is a numerical hydrodynamic model for the
one-dimensional (1D), two-dimensional (2D) and three-dimensional (3D) Non-Linear Shallow
Water Equations (NLSWE). The model is suitable for solving a wide range of hydrodynamic
systems ranging in scale from the open channels and floodplains, through estuaries to coasts and
oceans. TUFLOW FV also includes optional modules that provide advection dispersion, sediment
transport and morphology, particle tracking, water quality and three-dimensional modelling
capabilities. Figure 1-1 shows common TUFLOW FV solver features.
This manual provides user guidance for TUFLOW’s Flexible Mesh solver, TUFLOW FV.
2) TUFLOW’s Fixed Grid Solvers, using a matrix (grid) of square cells as the computation
structure. It includes two 2D engine options and a coupled 1D engine:
TUFLOW’s fixed grid solver includes world leading 1D/2D and 2D/2D dynamic linking and is
compatible for CPU and GPU hardware. These features are shown in Figure 1-2.
The fixed grid solvers are well suited to simulating integrated urban drainage situations (above and
below ground), distributed hydrology direct rainfall scenarios, catchment flooding, tides and storm tide
hydraulics.
This manual DOES NOT provide user guidance for our fixed grid solver TUFLOW Classic and
TUFLOW HPC. This documentation is available for download from the TUFLOW website.
Advection Dispersion
2D Flexible Mesh Design 3D Module Layer Options
Module
For any enquiries about the fixed grid or flexible mesh solvers, please email [email protected] or
[email protected].
1.2 TUFLOW FV
The Finite Volume (FV) numerical scheme employed by TUFLOW FV is capable of solving the
NLSWE on both structured rectilinear grids and unstructured meshes comprised of triangular and
quadrilateral elements. The flexible mesh allows for seamless boundary fitting along complex coastlines
or open channels as well as accurately and efficiently representing complex bathymetries with a
minimum number of computational elements. The flexible mesh capability is particularly efficient at
resolving a range of scales in a single model without requiring multiple domain nesting. The governing
equations are updated using an appropriate timestep that obeys the Courant-Friedrich-Lewy (CFL)
constraints imposed by the flow characteristics. Further details regarding the numerical scheme
employed by TUFLOW FV are provided in the TUFLOW FV Science Manual.
Unstructured mesh geometries can be created using a suitable mesh generation tool such as Aquaveo’s
SMS or Rising Water Sofware’s GIS Mesher. Both Cartesian and Spherical mesh geometries can be
used as the basis for TUFLOW FV simulations. Model elements such as topography, boundary locations
and structures can be specified interactively using GIS files in industry standard GIS packages including
ArcGIS, Mapinfo and QGIS.
Advection-Diffusion (AD) of multiple water-borne constituents can be solved within TUFLOW FV,
either coupled with a hydrodynamic simulation, or alternatively in transport mode using a pre-calculated
transport file. Simple constituent decay and settling can be accommodated in the AD solutions, or
alternatively more complex sediment transport algorithms can be applied through the Sediment
Transport Module.
Both cohesive and non-cohesive Sediment Transport (ST) routines can be accessed through in-built
TUFLOW FV modules which handle both bed and suspended load mechanisms. Dynamic morphology
updating can be optionally activated to reflect changes upon the underlying topography.
Baroclinic pressure-gradient terms can be optionally activated to allow the hydrodynamic solution to
respond to temperature, salinity and sediment induced density gradients. Atmospheric heat exchange
can also be calculated from given standard meteorological parameter inputs by an integrated module.
TUFLOW FV has a variety of options for simulating horizontal turbulent mixing, including the
Smagorinsky scheme. Simple parametric models for vertical mixing are incorporated within TUFLOW
FV and for more complicated turbulence model algorithms an interface for linking with various external
turbulence models has been implemented.
The water quality module couples TUFLOW FV with the Aquatic EcoDynamics (AED) model to
simulate aquatic biogeochemical and ecological dynamics. AED has been developed in response to
recognised deficiencies in existing water quality approaches used around the world, and it supports a
common library of biogeochemical and ecological ‘components’. AED includes the ability to simulate
interactions between biogeochemical variables including oxygen, carbon, nutrients (organic and
inorganic), sediment, light, temperature and algal species.
TUFLOW FV provides a multitude of options for specifying model boundary conditions, including:
Model output files are primarily map output in SMS DAT or XMDF formats (2D or vertically averaged
3D), map output in NetCDF format (2D, vertically averaged 3D or full 3D) and time-series output in
comma-delimited format (2D or vertically averaged 3D). The NetCDF output files can be viewed using
any numerical analysis package with a NetCDF library interface, including MATLAB, R, GNU Octave
or Python NumPy. The TUFLOW FV NetCDF output file structure is described in Appendix C.
The flexible mesh consists of a network of irregular triangular and quadrilateral elements. This has
inherent advantages, including:
• Mesh resolution can be adjusted according to the needs of the study (i.e. fine resolution within
the area of interest and coarser resolution in the regional extents). Therefore, a range of spatial
scales can be modelled without resorting to nesting.
• Mesh alignment can neatly fit bathymetric contours and boundary extents, optimising mesh
resolution. This is particularly relevant in regions with complex bathymetric or topographic
features.
• Specific features, the geometry such as hydraulic structures and coastal barriers can be
included explicitly in the model mesh.
To exploit these advantages, the mesh needs to be designed carefully and appropriately for the specific
model application. There are several mesh generators available to construct a model mesh discussed
further in Section 8.1.
The NLSWE is a system of equations describing the conservation of fluid mass/volume and momentum
in an incompressible fluid, under the hydrostatic pressure and Boussinesq assumptions. The standard
form of the NLSWE, which relates the time-derivative of the conserved variables to flux-gradient and
source terms, is given below.
𝜕𝑼
𝜕𝑡
+ ∇ ∙ 𝑭(𝑼) = 𝑺(𝑼) (1)
The finite-volume schemes are derived from the conservative integral form of the NLSWE, which are
obtained by integrating the standard conservation equation over a control volume, Ω.
𝜕𝑼
∫Ω 𝑑Ω + ∫Ω ∇ ∙ 𝑭(𝑼) 𝑑Ω = ∫Ω 𝑺(𝑼) 𝑑Ω (2)
𝜕𝑡
Gauss’ theorem is used to convert the flux-gradient volume integral into a boundary-integral:
𝜕
∫ 𝑼 𝑑Ω + ∮𝜕Ω(𝑭 ∙ 𝒏) 𝑑𝑠 = ∫Ω 𝑺(𝑼) 𝑑Ω (3)
𝜕𝑡 Ω
where ∫Ω 𝑑Ω represent volume integrals and ∮𝜕Ω 𝑑𝑠 represents a boundary integral and 𝒏 is the boundary
unit-normal vector.
The NLSWE conserved variables are volume (depth), x-momentum and y-momentum:
ℎ
𝑼 = [ℎ𝑢] (4)
ℎ𝑣
where h is depth, u is x-velocity and v is y-velocity.
The x, y and z components of the inviscid flux (𝑭𝐼 ) and viscous flux (𝑭𝑉 ) terms in the NLSWE are given
below.
0
ℎ𝑢 𝜕𝑢
𝑭𝐼𝑥 = [ℎ𝑢2 + 2𝑔ℎ2 ] , 𝑭𝑉𝑥 ≈ [
1 −ℎ𝐾 𝑣 𝜕𝑥 ]
𝜕𝑣
ℎ𝑢𝑣 −ℎ𝐾𝑣 𝜕𝑥
0
ℎ𝑣 𝜕𝑢
−ℎ𝐾𝑣 𝜕𝑦
𝑭𝐼𝑦 = [ ℎ𝑢𝑣 ] , 𝑭𝑉𝑦 ≈ (5)
ℎ𝑣 2 + 12𝑔ℎ2 𝜕𝑣
[−ℎ𝐾𝑣 𝜕𝑦]
0
ℎ𝑤 𝜕𝑢
𝑭𝐼𝑧 = [ℎ𝑤𝑢] , 𝑭𝑉𝑧 ≈ [−𝜈𝑡 𝜕𝑧 ]
ℎ𝑤𝑣 𝜕𝑣
−𝜈𝑡 𝜕𝑧
Some of the various source terms to the NLSWE are provided below:
0
𝜕𝑧 ℎ 𝜕𝑝 ℎ𝑔 𝜂 𝜕𝜌 1 𝜕𝒔𝑥𝑥 𝜕𝒔 𝝉𝑠𝑥 𝝉𝑏𝑥
𝑔ℎ 𝜕𝑥𝑏 + 𝑓𝑣ℎ − 𝜌 𝜕𝑥𝑎 − 𝜌 ∫𝑧 𝜕𝑥 𝑑𝑧 − 𝜌 ( + 𝜕𝑦𝑥𝑦 ) + −
𝑺= 0 0 0 𝜕𝑥 𝜌0 𝜌0 (6)
𝜕𝑧𝑏 ℎ 𝜕𝑝𝑎 ℎ𝑔 𝜂 𝜕𝜌 1 𝜕𝒔𝑦𝑥 𝜕𝒔𝑦𝑦 𝝉𝑠𝑦 𝝉𝑏𝑦
[ 𝑔ℎ 𝜕𝑦 − 𝑓𝑢ℎ − 𝜌 𝜕𝑦 − 𝜌 ∫𝑧 𝜕𝑦 𝑑𝑧 − 𝜌
0 0 0
( 𝜕𝑥
+ 𝜕𝑦
)+ 𝜌0
− 𝜌0 ]
where,
𝜕𝑧𝑏 𝜕𝑧𝑏
• ,
𝜕𝑥 𝜕𝑦
are the x- and y-components of bed slope;
• 𝝉𝑠 and 𝝉𝑏 are respectively the surface and bottom shear stress terms (where applicable).
Other source terms not included above include inflow/outflow to/from the water column.
For full detail on the above source terms please refer to the TUFLOW FV Science Manual.
𝑈 = [ℎ𝐶] (7)
where 𝐶 is the constituent concentration. The flux components of the scalar conservation equation are:
𝜕𝐶 𝜕𝐶
𝐹𝑥𝐼 = [ℎ𝑢𝐶], 𝐹𝑥𝑉 ≈ [−ℎ (𝐷𝑥𝑥 𝜕𝑥 + 𝐷𝑥𝑦 𝜕𝑦)]
𝜕𝐶 𝜕𝐶
𝐹𝑦𝐼 = [ℎ𝑣𝐶], 𝐹𝑦𝑉 ≈ [−ℎ (𝐷𝑦𝑥 𝜕𝑥 + 𝐷𝑦𝑦 𝜕𝑦)] (8)
𝜕𝐶
𝐹𝑧𝐼 = [ℎ𝑤𝐶], 𝐹𝑧𝑉 ≈ [−ℎ𝜈𝑡′ 𝜕𝑧 ]
𝑆 = [−𝐾𝑑 ℎ𝐶 − 𝑤𝑠 𝐶] (9)
• Water volume per cell area (equivalent to the depth of water in a cell): For incompressible
fluids, this is the water mass per cell area in the cell.
• X-component of momentum: The x-component of velocity multiplied by the water volume.
• Y-component of momentum: The y-component of velocity multiplied by the water volume.
• Salt mass (if salinity is included): The salinity concentration multiplied by the water volume.
• Heat mass (if temperature included): The temperature concentration multiplied by the water
volume.
• Sediment mass (for each sediment that is modelled): The sediment concentration multiplied
by the water volume.
• Tracer mass (for each tracer that is modelled): The tracer concentration multiplied by the water
volume.
• Water Quality scalar mass (for each tracer that is modelled): The water quality parameter
concentration multiplied by the water volume. The order of this is dependent on external water
quality module, see the relevant external water quality manual for information.
1.4 Schematisation
The mesh cells (or elements) are the computational blocks of the finite volume approach used by
TUFLOW FV. TUFLOW FV uses a cell centred scheme with a single bed elevation value assigned to
each cell in its calculations, and then produces output that is applicable for each cell (cell velocities are
derived from the values across each cell face as shown in Figure 1-3).
Unless the user decides otherwise, TUFLOW FV will run using the maximum number of threads
available to it, only limited by the software licence or computer hardware.
Upcoming releases of TUFLOW FV are planned to include GPU acceleration and domain
decomposition to further improve computational performance.
The TUFLOW suite was submitted for the initial phase of testing in 2010 with all three 2D schemes,
TUFLOW’s implicit and explicit GPU solvers, and TUFLOW FV’s explicit solvers undergoing the
more recent phase of testing in 2012. The results demonstrated consistency between each of the three
TUFLOW engines and with other fully dynamic schemes. All three TUFLOW engines were found to
be suitable for the following applications:
The 10 tests are outlined in Table 1-1. For further information refer to “Benchmarking the Latest
Generation of 2D Hydraulic Modelling Packages” (Néelz, S. and Pender, G. 2013).
All tests were completed using TUFLOW FV with the exception of Tests 7 and 8B. These two tests
require 1D/2D linking which is currently in development.
Table 1-1 Table Summary of United Kingdom Environment Agency Benchmark Tests
Test
Description Purpose
Number
1 Flooding a disconnected water Assess basic capability to simulate flooding
body of disconnected water bodies on floodplains
or coastal areas.
2 Filling of floodplain depressions Tests capability to predict inundation extent
and final flood depth for low momentum flow
over complex topographies.
3 Momentum conservation over a Tests capability to simulate flow at relatively
small (0.25m) obstruction low depths over an obstruction with an
adverse slope.
4 Speed of flood propagation over Tests simulation of speed of propagation of
an extended floodplain flood wave and the prediction of velocities at
the leading edge of the advancing flood.
5 Valley flooding Tests simulation of major flood inundation at
the valley scale.
6A and 6B Dam break Tests simulation of shocks and wake zones
close to a failing dam.
7 River to floodplain linking Evaluates capability to simulate flood volume
transfer between rivers and floodplains using
1D to 2D model linking. This test has not yet
been undertaken for TUFLOW FV but will be
included following 1D/2D integration.
8A and 8B Rainfall and sewer surcharge flood Tests capability to simulate shallow flows in
in urban areas urban areas with inputs from rainfall (8A) and
sewer surcharge (8B). Test 8B has not yet
been undertaken for TUFLOW FV but will be
included following 1D/2D integration.
2 Running TUFLOW FV
Chapter Contents
2.1 Software Structure 2-2
2.2 Installing and Running TUFLOW FV 2-5
2.2.1 TUFLOW FV Downloads and Installation 2-5
2.2.2 Linux Installation 2-5
2.2.3 USB Locks (Dongles) and Licencing 2-5
2.2.4 Dongle Types and Setup 2-5
2.3 Performing Simulations 2-7
2.3.1 Batch File Example and Run Options (Switches) 2-7
2.3.2 From a Text Editor 2-8
2.3.3 From the SMS Interface 2-8
2.3.4 Directly from GIS 2-8
2.3.5 Change Priority, Pause, Restart or Cancel a Simulation 2-8
2.4 Licence Free Simulations 2-10
2.4.1 Tutorial Models 2-10
2.5 Tips and Tricks 2-11
TUFLOW FV requires the generation of a mesh which forms the basis for model
topography/bathymetry, resolution and material coverage. Mesh generators are discussed in detail in
Section 8.1. A good mesh generator tool used skilfully is fundamental when developing a model in
TUFLOW FV. For those familiar with the ‘TUFLOW Classic’ workflow where the model mesh is
automatically generated at runtime, the need for a manually and carefully developed user-defined mesh
is a significant departure from the methodology you are used to.
Text files are used for controlling simulations and simulation parameters, whilst the bulk of data input
is in GIS, comma delimited text files (.CSV) in combination with the model mesh. An approach that
combines mesh generation and GIS offers several benefits including:
For those modellers preferring to work predominantly within a Graphical User Interface, there are also
several third-party options as discussed later in this chapter. For experienced modellers, the ability to
be able to essentially script up a model, and use GIS in combination with these GUIs, offers a highly
proficient arrangement by utilising the optimal software for different modelling tasks.
The fundamental software necessary for building and viewing TUFLOW FV models are:
• A text editor.
• A mesh generation software such as Aquaveo SMS or the Rising Water Software GIS Mesher.
• Spreadsheet software.
• GIS software that can import/export .mif files or .shp files.
• 3D surface modelling software for the creation and interrogation of a DTM, and for importing
3D surfaces of water levels, depths, hazard, etc. This functionality is available in most GIS
packages, sometimes as an add-on.
• GIS, Aquaveo SMS and/or a GUI for viewing results.
The above combination offers a very powerful, workflow efficient and economical system for hydraulic
modelling, driven by the unparalleled range of features and functionality available in TUFLOW FV, and
the efficient modelling workflow that is generated using TUFLOW FV scripts or control files.
Suggested software packages include (but are not limited to) those listed in Table 2-1. A typical model
setup workflow comprises the following elements:
• The GIS system is used to set up, modify, thematically map and manage all geographic data.
• The mesh generator to provide the underlying computation domain.
• Time-series and other non-geographically located data tabulated using spreadsheet software.
Often scripting and programming software such as MATLAB or Python may be used to
development or modify advanced model inputs.
• The text editor is used to create and edit TUFLOW FV simulation control files. The control
files list all the simulation commands and file path references to the above mentioned GIS and
tabular datasets.
• Visualisation of TUFLOW outputs results in text editor, spreadsheet, GIS or via/in
combination with MATLAB or Python visualisation libraries.
The TUFLOW FV software may even be located in a folder under the parent folder for the model, so
that the version of TUFLOW FV used for that particular model is associated and archived with the
model.
For third-party USB locks that have TUFLOW FV licences please refer to the vendor’s documentation
for configuring the licence.
1
Please contact [email protected] if interested in running TUFLOW FV on Linux.
Refer to the installation instructions on the TUFLOW Wiki for further information on WIBU dongle
setup.
• Running a batch file. Batch files can be set up to loop through events and scenarios to run a
multitude of simulations or to push simulations to different processors.
• Directly from the text editor – ideal for one off simulations especially whilst constructing a
model to test inputs.
• Via a GUI, such as the SMS TUFLOW FV Interface.
• Directly from a GIS.
• From a Command (Console) Window.
Details of each method are provided in the following sections and also are available on the TUFLOW
Wiki.
“C:\TUFLOWFV\2019.01.009\TUFLOWFV.exe” run01.fvc
“C:\TUFLOWFV\2019.01.009\TUFLOWFV.exe” run02.fvc
“C:\TUFLOWFV\2019.01.009\TUFLOWFV.exe” run03.fvc
Pause
The .bat file is run or opened by double clicking on it in Explorer. This opens a Console Window and
then executes each line of the .bat file. The pause at the end stops the Console window from closing
automatically after completion of the last simulation.
Note that the full path and executable is within double quotes; this is needed when there is a space in
the command.
For example:
C:\>set OMP_NUM_THREADS=4
“C:\TUFLOWFV\2019.01.009\TUFLOWFV.exe” run01.fvc
“C:\TUFLOWFV\2019.01.009\TUFLOWFV.exe” run02.fvc
“C:\TUFLOWFV\2019.01.009\TUFLOWFV.exe” run03.fvc
Pause
Setting up TUFLOW FV to run from UltraEdit and Notepad ++ is described in the TUFLOW FV wiki:
http://fvwiki.tuflow.com/index.php?title=Running_TUFLOW_FV.
The TUFLOW FV wiki outlines the steps required to install the SMS interface:
http://fvwiki.tuflow.com/index.php?title=SMS_Tips#TUFLOW_FV_SMS_Interface
Tutorial Module 2 on the TUFLOW FV wiki steps through the process of developing and running a
model using the interface:
http://fvwiki.tuflow.com/index.php?title=Tutorial_Module02
• Open Task Manager (see your System Administrator if you’re not sure how to do this)
• Click on the details tab
• Find the TUFLOWFV.exe process you wish to change
• Right click, choose Set Priority, then the priority desired as shown in the image below
Note, don’t choose High or Realtime as this will cause TUFLOW FV to take over your CPU and you
may not able to do much until the simulation is finished.
Simulation priority can also be specified when using a batchfile. Refer to the TUFLOW FV wiki for
more details:http://fvwiki.tuflow.com/index.php?title=Running_TUFLOW_FV.
To pause a model simulation, highlight the console window and press “Ctrl-S”. This will temporarily
halt the model simulation.
To cancel a simulation, “Ctrl-C”. This will include all result outputs up until the time of cancellation.
There is no need to have a TUFLOW FV licence to simulate the tutorial model. Changes to the model’s
boundaries and other inputs are allowed so that the user can test and evaluate TUFLOW FV’s various
features. The command Tutorial Model == ON must occur within the .fvc file to simulate the model
without needing a licence. An error will be generated if this command is included in any model other
than the TUFLOW FV tutorial model available from the TUFLOW website.
The tutorial models are fully supported via the TUFLOW support services, therefore, should you have
any queries please don’t hesitate to contact [email protected].
New users are recommended to complete these tutorial models to learn how to create a model mesh and
setup a TUFLOW FV model.
Table 2-2 TUFLOW FV Tutorial/Demo Models
Tutorial Module 1 Simple Trapezoidal channel. Build a mesh in your choice of SMS or
GIS Mesher. Integrate basic GIS functionality and review results.
Tutorial Module 2 Meandering river. Build the mesh in your choice of SMS or GIS
Mesher. Try the TUFLOW FV SMS interface.
Tutorial Module 3 Floodplain and estuarine example. Include structures and advection
dispersion. This example provides you with a pre-constructed mesh.
Tutorial Module 4 Coastal example. Look at the application of an astronomical tide and
model a tropical cyclone induced storm tide.
Tutorial Module 5 3D estuary example. Begin with a 2D model and then increase the
complexity to a stratified 3D model. Optionally add water quality and
assess the impact of a wastewater treatment outfall. Get an
introduction to the TUFLOW FV MATLAB and TUFLOW FV Python
2D and 3D visualisation tools.
Mesh Generation Tips A set of tips to consider when building and updating your project mesh.
3.1 Introduction
This chapter discusses key considerations that should be addressed during the design phase of a
hydraulic modelling study, prior to the commencement of model build. Consideration of how the model
is to be schematised and selection of key model parameters may have a significant influence on the
accuracy, stability and simulation time of the model, and may avoid redundant work later in the study.
Defining a modelling exercise often starts with a preferred, highly rigorous and scientifically thorough
approach that strives to replicate the physical system as accurately as possible. This is followed by a
series of compromises and simplifications due to practical constraints. The final problem definition
strikes a balance, providing a fit-for-purpose outcome. Key considerations include:
• The spatial extent of the model domain (i.e. the area to be modelled). This is typically guided
by:
o the spatial extent of the problem to be solved
o the availability and locality of data with which to define boundary conditions
o the spatial extent of the key physical processes to be represented
• The specified start and end time of the simulation which is typically guided by the temporal
extent of the key physical processes to be represented. Examples include:
o a flood assessment requires simulation of individual flood events with durations in the
hours
o a coastal or estuarine assessment, where tidal forces dominate, which may require the
simulation of several tidal cycles over weeks, months or years
o a morphological assessment which may require simulation periods of years or decades
• The model mesh geometry and the number of active, wet elements (or cells) in the model
domain. For coastal, estuarine and flood assessments the number of wet elements may vary
with time.
• The timestep, which varies throughout a simulation and is selected by taking into account
physical and numerical convergence and stability considerations. The appropriate timestep is
calculated by TUFLOW FV such that CFL constraints imposed by the flow characteristics are
obeyed.
• The complexity of the processes being simulated. A simulation that includes scalar transport
calculations such as tracers, sediments or water quality constituents will require additional
computational effort compared to a hydrodynamics only simulation.
The base data required to develop a TUFLOW FV model will typically comprise of:
• Spatial datasets that define elevations (bathymetric and topographic) throughout the model
domain.
• Timeseries datasets that define the open boundary conditions, such as a temporally varying
water level (tidal) or inflow condition.
This information is normally easy to prepare, especially with pre-processing tools such as spreadsheets,
SMS, GIS/3D surface modelling software and other numerical analysis packages (e.g. MATLAB) and
scripting (e.g. Python). Quality checking of input data is a crucial component of any modelling exercise
(yes, the often quoted “garbage in, garbage out” phrase cannot be left out of any modelling manual).
Being proactive in quality assuring the input data can significantly reduce the possibilities of further
issues.
Bathymetric data is typically obtained via hydrographic surveys and/or nautical charts. These sources
of data are generally restricted to areas of ship movements and recreational boating. In some instances,
a hydrographic survey specific to the project may be available. In the absence of reliable hydrographic
survey or nautical chart information, bathymetry estimated from satellite data may be available.
For flooding or coastal inundation, a description of the land topography is also required. This
information is typically obtained via satellite radar or plane-mounted Laser Detection and Ranging
(LIDAR or LADS) instruments although is increasingly being obtained from terrestrial instruments
In most modelling exercises an early step will be to develop a Digital Elevation Model (DEM) or Digital
Terrain Model (DTM) of the study area using the available sources of bathymetry/topography data and
GIS/3D surface mapping software. A DEM/DTM is a regular structured grid of elevation values. An
example DEM/DTM constructed using MapInfo and Vertical Mapper software from a combination of
hydrographic survey, LIDAR and digitised nautical chart data sources is shown in Figure 3-1.
TUFLOW FV solves the NLSWE on regular structured grids or unstructured meshes. Most TUFLOW
FV users take advantage of the flexible mesh capability, with the model mesh comprising of triangular
and quadrilateral elements. The flexible mesh approach allows for seamless boundary fitting along
complex coastlines or open channels as well as accurately and efficiently representing complex
bathymetries with a minimum number of computational elements. The flexible mesh capability is
particularly efficient at resolving a range of resolutions within a single model without requiring multiple
domain nesting.
Figure 3-2 shows a TUFLOW FV mesh and DEM of Port Curtis on the east coast of Australia (the DEM
without the mesh is shown in Figure 3-1). This mesh was primarily developed to assess the impacts of
a proposed shipping navigation channel expansion. Consequently, the mesh was constructed to neatly
resolve the existing and proposed shipping channel geometry. Smaller mesh elements (higher mesh
resolution) were necessary to resolve the complex tidal flows in the vicinity of the smaller islands and
the harbour constriction. Larger mesh elements (lower mesh resolution) were used in regions located
away from the areas of interest and/or where the flow varied more gradually, such as the shallow mud
flats represented by the dark green areas in Figure 3-2.
Unstructured or flexible mesh geometries can be created using any suitable mesh generation tool.
TUFLOW FV users generally use the Aquaveo SMS Generic Mesh Module or Rising Water Software
GIS Mesher for building meshes as well as undertaking a range of model pre-processing and post-
processing tasks. Both Cartesian and Spherical mesh geometries can be used as the basis for TUFLOW
FV simulations. Mesh building/editing tutorials are available from the following sources:
In addition to these web-based resources, Section 8.1 provides guidance on mesh generation and is
particularly useful for new flexible mesh modellers. Section 8.1.1 describes the contents and required
format of a TUFLOW FV mesh geometry file which follows the SMS Generic Mesh Module format.
Mesh geometry files generated using an alternative mesh generation tool need to follow the format
described in Section 8.1.1. This may require manual manipulation of the mesh geometry file contents.
- The closed boundaries at the seabed, open channel bed and water surface
Descriptions of the various open boundary conditions, their commands and associated inputs are
provided in Chapter 10. TUFLOW support can be contacted for further information on applying
boundary conditions derived from ocean circulation models: [email protected].
Simulations that require spatially and temporally varied forcing typically rely on input data arranged on
regular structured grids and stored in NetCDF format. For example, often SWAN (Simulating WAves
Nearshore) wave model output or hindcast meteorological data from global models (e.g. NCEP/NCAR
http://www.ncep.noaa.gov/) are utilised as inputs to TUFLOW FV simulations.
Spatially and temporally varying data accessed from online sources or generated using other models can
be very large datasets (up to gigabytes in file size) and generally require some degree of processing prior
to being used as input to a TUFLOW FV simulation. MATLAB or Python are typically used by BMT
for preparing input data; however, other numerical analysis software packages with GRIB (a binary
format commonly used to store meteorological data) and NetCDF libraries could also be used. Examples
of common TUFLOW FV NetCDF input files and the associated commands are provided in Appendix
E.
In some situations the modeller may wish to set the initial condition using a TUFLOW FV restart file
which contains the spatially varying conserved variables (at an instant in time) generated by a previous
simulation. Further information on the initial condition and restart file options can be found in Section
10.7.
The range of model performance tests undertaken by the modeller will depend on the type of TUFLOW
FV application; nevertheless, there are a number of key checks to be completed prior to an initial
simulation with a TUFLOW FV model:
• Once a mesh has been generated, the modeller needs to check for inconsistent element shapes
or sizes that may unnecessarily constrain the model timestep. The accidental creation of a very
small model cell (often a thin triangle) is a common issue and these “bad” cells must be
removed from the mesh in order to achieve maximum model efficiency.
o The Aquaevo XMS Wiki provides several mesh construction “rules” that will assist the
user to create a clean mesh: http://www.xmswiki.com/xms/SMS:Mesh_Quality
• The mesh should accurately represent the bathymetry and topography, this can be checked by:
o Specifying ‘ZB’ as a mapped output variable (either SMS Data File or NetCDF format,
see Section 12.6) and running the TUFLOW FV model for short period. The ZB results
represent the model bathymetry and should be compared to the base bathymetry and
topography dataset.
o Using the Write Check Files command will output a GIS layer of the mesh that includes
core information such as cell ZB, material and element ID. This can be quickly read
into GIS platforms for review. For more information on GIS Check Files please refer
to Section 12.9.
o By default, TUFLOW FV automatically outputs a number of model geometry files to
the log directory (*_geo.nc and a series of .CSV files). The .CSV files provide a log of
the model geometry and structure inputs and are an important check for flood
applications. Using 3D surface modelling software, the user can create a TIN of the
dataset and compare it against the base bathymetry/topography dataset and structure
locations. Note: This method is depreciated. It is now recommended to integrate
TUFLOW FV models with GIS and use the Write Check Files command.
The TUFLOW FV Wiki lists a number of ways to review a simulation timestep and also various ways
to increase the efficiency of a model:
http://fvwiki.tuflow.com/index.php?title=A_Model_Runs_Slow
For more information on setting the and reviewing computational timestep commands please refer
Section 6.8.1
Verify the model to another set of independent observed data, preferably from a different location
and/or a different time (with correspondingly different physical conditions).
Where knowledge or data is lacking, perform sensitivity tests on model parameters to quantify
the uncertainty of model results.
Calibration is the process where the parameters of a model are adjusted, within reasonable bounds, so
that simulation results match observed measurements. Validation is the process where a calibrated model
is compared to observed measurements from a different period with different physical conditions. In
combination, calibration and validation provide confidence that the model can replicate the physical
processes and is a useful tool.
Choice of measurement periods for calibration depends upon the physical processes that need to be
captured in the model. Typically, timeseries of response (for example river discharge, stage or tidal
variations and current speed/direction) are more valuable for calibration purposes compared to
instantaneous spot readings, however all relevant, reliable data should be absorbed into a calibration
exercise.
As a minimum requirement for calibration and validation of a hydrodynamic tidal model, the following
measurements are recommended:
• Calibration: A timeseries of water level, current speed and current direction at two or more
locations, performed over a period that captures the tidal variation (e.g. over a spring-neap
period)
• Validation: A timeseries of water level, current speed and current direction at two or more
locations, over an independent period.
If seasonal variations are important, this exercise could be repeated at different times of year.
Example tidal calibration timeseries plots are shown in Figure 3-3 and Figure 3-4. The water level data
was obtained from a permanent tide recording location. The current data was recorded using a fixed-
location, bottom-mounted Acoustic Doppler Current Profiler (ADCP) instrument. TUFLOW FV point
output has been obtained from these locations for direct comparison with the recorded data.
Flow (discharge) measurement across the entrance to an estuary or harbour is also a valuable model
calibration dataset as shown in Figure 3-5. These measurements are typically obtained using a boat-
mounted ADCP and performing continuous transects across the entrance or channel over a tide cycle.
The model output corresponds to the flow through the location where the ADCP transect data was
recorded. This type of output is obtained using the TUFLOW FV flux command.
Auckland Point
3.0
2.0
0.0
-1.0
-2.0
-3.0
08/06/2009 10/06/2009 12/06/2009 14/06/2009 16/06/2009 18/06/2009 20/06/2009 22/06/2009 24/06/2009 26/06/2009 28/06/2009 30/06/2009
Recorded Modelled
ADCP Site 2
1
0.8
0.6
0.4
Current Speed (m/s)
0.2
-0.2
-0.4
-0.6
-0.8
-1
06/06/2009 08/06/2009 10/06/2009 12/06/2009 14/06/2009 16/06/2009 18/06/2009 20/06/2009
ADCP Site 2
360
315
270
Current Direction (Degrees true)
225
180
135
90
45
0
06/06/2009 08/06/2009 10/06/2009 12/06/2009 14/06/2009 16/06/2009 18/06/2009 20/06/2009
Figure 3-4 Example Current Speed and Current Direction Timeseries Calibration Plots for a
Tidal Estuary
20000
Flood
15000
10000
5000
Flow (m3/s)
-5000
-10000
-15000
-20000
Ebb
-25000
27/04 0:00 27/04 6:00 27/04 12:00 27/04 18:00 28/04 0:00 28/04 6:00 28/04 12:00 28/04 18:00 29/04 0:00
Figure 3-5 Example Flow Timeseries Calibration Plots for a Tidal Estuary
Overland flow calibration is less dependent upon instantaneous measurements performed at the time of
the modelling study and more dependent upon historical records of floods. In these circumstances, all
available information should be sought, quality checked and analysed, and used in the calibration
exercise.
If a model cannot be calibrated due to a lack of data, don’t despair; application of an uncalibrated model
can still be useful. Be cautious with the model; interpret the results as indicators of specific trends and
processes which, when combined with available data and experience, can provide worthwhile
information.
4.1 Introduction
This chapter of the Manual discusses the TUFLOW FV recommended folder structure and the differing
types of model input and output files used by the model. Focus is provided on the TUFLOW FV Control
File (.fvc extension) which is the master run file input to TUFLOW FV on execution. Syntax rules,
naming conventions and suggestions for control file layout are explored in this chapter.
Section 4.3.3 provides a useful reference to guide you through the .fvc file structure and links to specific
chapters of the Manual for further guidance.
The new folder names and structure differs slightly from that recommended in the previous manual and
used in model builds pre-2019. This new configuration is designed to align with the folder structure
used by TUFLOW FV’s sister products: TUFLOW Classic and TUFLOW HPC/QPC. It also allows for
integration with the QGIS Plugin and GIS input files. You can find a copy of the recommended folder
structure in the data download package of Tutorial Model 01.
If running an older model there’s no requirement for you to modify your existing folder structure and
we recommend leaving it ‘as is’. For new models we suggest that you adopt the scheme in Figure 4-1
and Table 4-1 as this is the new standard for TUFLOW FV model development. Where applicable the
description column of Table 4-1 provides pre-2019 folder names.
Sub-Folder Description
Locate folders below on the system network under a folder named “TUFLOWFV” in the
project folder (e.g. J:\Project12345\tuflowfv) These folders should be backed up regularly
bc_dbase Boundary conditions, often with additional sub-folders for specific boundary
condition types (e.g. tide, flow, meteorology, etc.). This folder was typically
called ‘bc’ for model builds prior to 2019.
check If the Write Check Files == command is included in the .fvc check files will be
output from TUFLOW FV. These are a series of output files in both GIS
(MapInfo or Shapefile format) and tabular data in .CSV format. These check
files contain information on the data processed by TUFLOW FV.
exe Optional sub-folder, placing the tuflowfv.exe (and associated dlls) within the
TUFLOW FV folder structure may be desired. Alternatively, the tuflowfv.exe is
located elsewhere on the network or local computer.
runs TUFLOW FV simulation control files. Batch files are also stored here when
performing multiple simulations in a series. This folder was typically called
‘input’ for model builds prior to 2019.
runs\log Location for automatically generated simulation log and model performance
files.
results The directory where specified model output is written. Often placed on a local
drive rather than a network drive. This folder was typically called ‘output’ for
model builds prior to 2019.
• Control Files
• Data Input Files
• Model Output Files
• Check Files
Control files are used for directing inputs to the simulation and setting parameters. The style of input is
very simple, free form text commands, like writing down a series of instructions. This offers the most
flexible and efficient system for experienced modellers. It is also easy for inexperienced users to learn.
Data input files are primarily comma-delimited files prepared using spreadsheet software. Simulations
that require spatially and temporally varied forcing (e.g. wind fields or short-wave forcing) typically
rely on NetCDF format data input. Common examples of NetCDF input file formats used by TUFLOW
FV are provided in Appendix E. In some instances, the model initial condition may be defined by
spatially and vertically (for 3D or layered sediments) varying outputs from a previous simulation,
referred to as a TUFLOW FV restart file.
Data output files are primarily map output in SMS format (2D or vertically averaged 3D), map output
in NetCDF format (2D, vertically averaged 3D or full 3D) and time-series output in comma-delimited
format. The TUFLOW FV NetCDF output file structure is summarised in Appendix C. In addition to
the above, a range of check files are produced in text and comma-delimited formats to carry out quality
control and model efficiency checks.
The most common file types and their extensions are listed in Table 4-2.
Table 4-2 TUFLOW FV File Formats
Control Files
TUFLOW FV .fvc Controls the data input and output for a 2D or 3D Text
Simulation Control simulation. Mandatory for 2D and 3D. Also used to
File include other files.
Data Input
Mesh Geometry .2dm A file containing the 2D geometry of the model Text
File mesh and elevations. It also contains information on
the material types used to define areas with a
specified bed roughness and the location of open
boundaries. The structure of the .2dm file follows
the SMS Generic Mesh Module structure.
Mandatory for 2D and 3D.
3D Model Vertical .CSV A file containing the z-coordinates of the vertical Text
Mesh File mesh. Mandatory for 3D using z-coordinate or z-
sigma coordinate discretisation.
GIS Files .shp or .mif Mapinfo MIF or ESRI Shape Files containing vector GIS
point, polyline or polygon data. Used to assign the
location and attributes of a range of model inputs
including nodestring, materials and
topographic/bathymetry datasets.
GIS Grid Files .asc or .flt ESRI ASCII grid (.asc) or binary grid (.flt) formats. GIS
Typically used to assign bathymetry or topography
and can be read by the Read GRID Zpts command.
Comma Delimited .CSV These files are used for temporally varying Text
Files boundary condition input, such as a tidally varying
water level or inflow condition. They can be opened
and saved using a text editor or spreadsheet
software such as Microsoft Excel.
NetCDF File .nc These files are typically used to store data inputs NetCDF
that vary spatially and temporally. These inputs are
often derived from outputs from other models and
may include wind fields, atmospheric conditions,
short-wave forcing or ocean current forcing.
Restart File .rst These files are generated by TUFLOW FV and Binary
contain the spatially varying conserved variables at
an instant in time. Restart files are optionally used
to define the initial condition of a TUFLOW FV
simulation.
Model Output
Comma Delimited .CSV These files are used for time-series data output (2D Text
Files and vertically averaged 3D). They are typically
opened and viewed using numerical analysis
software (e.g. spreadsheet software such as
Microsoft Excel).
SMS Data File .dat, xmdf, SMS generic formatted simulation output file. Binary
.sup TUFLOW FV map output can be written in the SMS
.dat or .xmdf format (2D and vertically averaged
3D). The .sup file is used to combine the input
mesh and output results and is read by SMS or the
TUFLOW Viewer Plugin for QGIS.
NetCDF File .nc NetCDF formatted simulation output file. TUFLOW NetCDF
FMTUFLOW FV map output can be written in the
NetCDF .nc format (2D, vertically averaged 3D and
full 3D).
GIS Check Files .mif, .shp Point, polyline or region GIS check files that Text
reproduce information on the location and attributes (.mif),
of model input datasets. Very useful for model Binary
debugging. (.shp)
2. A “==” following a command indicates the start of the parameter(s) for the command. For
example: Geometry 2D == ..\model\MyMesh.2dm
3. “#” or “!” represent comment syntax. All text after the comment command from that point
onward will be ignored. This is useful for “commenting-out” unwanted commands, and for
including modelling documentation within the control file. Comments may be entered at any
line or after a command. For example:
! This is the model mesh.
Geometry 2D == ..\model\MyMesh.2dm
OR:
Control files are command or keyword driven text files. The commands are entered free form, based on
the rules described below. Comments may be entered at any line or after a command. The commands
are listed in the index in Appendix A and Appendix B
Note: TUFLOW FV control file are NOT case sensitive on Windows Operating Systems. On Linux
commands to the left of the == are not case sensitive, however file paths and names to the right of ==
are case sensitive, consistent with Linux file and folder naming convention.
This command sets the simulation end time to 10 hours. The text to the right of the “!” is treated as a
comment and not used by TUFLOW when interpreting the line.
Automatic colour coding of files for easy viewing is available for the following text editors: Ultra Edit,
Notepad++ and TextPad. Instructions outlining how this software can be configured can be found on
the TUFLOW Wiki.
Commands can be repeated as often as needed. This offers significant flexibility and effectiveness when
modelling, particularly in building 2D model topography. Note that a repeat occurrence of a command
may overwrite the effect of previous occurrences of the same command.
The style of input is flexible bar a few rules. The rules are:
• A few characters are reserved for special purposes as described in Table 4-3;
• Command syntax is not case sensitive;
• Only one command can occur on a single line;
• A few commands rely on another command being previously specified. These are documented
where appropriate.
Unlike TUFLOW Classic or TUFLOW HPC/QPC additional text cannot be placed before and/or after
a command. For example, a line containing the command Start Time to set the start time of a simulation
to 10 hours can only be written as:
To indicate the units is it best to make use of comments i.e. Start Time == 10 ! hours would be
acceptable, noting the use of the comment delimiter “!”.
Blank lines are ignored. Spaces or indentations can occur at the start of the line. This is recommended
when using the logic control or material, structure, boundary or output blocks. The second and third
lines in the following example is not required to be indented, however, it is recommended for ease of
reviewing the model build:
output == NetCDF
output parameters == h,v,d, temp, sal, Rhow
output interval == 3600.
End If
The notation used to document commands and valid parameter values in Appendix A to Appendix B
are presented in Table 4-4.
Table 4-3 Reserved Characters – Text Files
“#” or “!” A “#” or “!” causes the rest of the line from that point on to be ignored.
Useful for “commenting-out” unwanted commands, and for all that
modelling documentation.
Notation Description
<…> Greater than and less than symbols are used to indicate a variable parameter.
For example, the commonly used <file> example is described below.
<file> A filename (can include an absolute or relative path, or a UNC path). See
Section 4.3 for a more detailed description.
spaces Spaces can occur in commands and parameter options. If a space occurs in a
command, it is only one (1) space, not two or more spaces in succession.
Spaces can occur in file and path names, however, third party software may not
allow this and as such is not recommended. If using spaces in filenames, batch
files will require that the filename is enclosed in quotes.
For the relative file path in TUFLOW FV the path is relative to the location of the fvc file. In the case
above, if the command occurred in the .fvc file which is located in the TUFLOWFV\runs\ folder. The
..\ indicates to go up one level (from TUFLOWFV\runs\ to TUFLOWFV\) the model\ navigates into the
TUFLOWFV\model\ folder, gis\ navigates from TUFLOWFV\model\ into TUFLOWFV\model\gis\).
To go up more than one level simply use ..\ multiple times (e.g. ..\..\ would navigate up two folders). If
the file sits under the same folder then the filename can be specified.
It is recommended where possible to use relative files paths. This makes it easy to move and package
models e.g. if client provision is required or you need flexibility to move models from one computer to
another.
Time and Time format and reference time, model start and end Chapter 6
Timestep times, CFL limits, timestep limits.
Model Results Output directory, map output formats and data types Chapter 12
and Output check files, time series and profile outputs, logging and
diagnostics.
An example fvc file is shown in Figure 4-4. New users wishing to learn how to create a simulation
control file are advised to complete the TUFLOW FV tutorial models which are available via the
TUFLOW FV Wiki (http://fvwiki.tuflow.com) and are described further in Section 2.4.1.
5 GIS Setup
Chapter Contents
5.1 Introduction 5-2
5.2 “GIS” Commands 5-3
5.2.1 Naming Conventions 5-4
5.3 GIS Initialisation 5-6
5.3.1 Define the Project Projection 5-6
5.3.2 Setting the GIS Output Format 5-6
5.3.3 Creating ‘Empty’ GIS Template Files 5-7
5.3.4 TUFLOW Viewer QGIS Plugin 5-8
5.4 TUFLOW FV GIS Integration Tutorials 5-9
5.1 Introduction
As of TUFLOW FV Release 2019.01 you can use GIS layers to assist with model development. GIS
data layers are transferred into and out of TUFLOW using the MapInfo data exchange .mif or ArcGIS
.shp format. These formats are industry standards and publicly available. The .mif format is in text
(ASCII) form, making it particularly easy to work with. Most mainstream CAD/GIS platforms
recognise these formats.
The format of input layers is solely controlled by the file extension (i.e. .mif for the MIF format and .shp
for the SHP format). TUFLOW FV requires that all GIS layers imported or exported by TUFLOW FV
must be in the same geographic projection. The model projection is initialised using the MI Projection
and/or SHP Projection commands. If a model has a mixture of .mif and .shp files as input, then both MI
Projection and SHP Projection should be specified.
The default output format for GIS check layers and GIS outputs is the .mif format. To produce check
and output GIS layers as .shp files, specify GIS Format == SHP in the .fvc file (refer GIS Format).
Please note that the use of GIS Integration is optional and not a requirement to run TUFLOW FV. If
building new models (or modifying old ones) we do encourage you to use these features, particularly if
using the pre-2019 CSV file formats for model geometry assignment such as the Nodestring Polyline
File, Cell Elevation File, Cell Elevation Polyline File etc.
To appreciate how TUFLOW FV interprets GIS data it is important to understand the following.
• .mif or .shp files contain the geometrical (map) data about the objects.
• .mid or .dbf files contain the attribute data of the objects.
The geographic location of objects for GIS commands is important. The geographic position of the
object controls which part of the TUFLOW model they affect. By default TUFLOW, checks that the
projection of each .mif file matches that specified by the MI Projection command and the projection of
each shapefile matches that specified by the SHP Projection command. A MapInfo GIS layer must have
a projection specified, whilst a Shapefile layer does not need to have a projection defined. Regardless
of which GIS software used, it is strongly recommended that each file has a defined projection. Table
5-1 defines the different data objects supported. If an unsupported GIS object is identified on input
TUFLOW FV will throw the following warning to the console and log file: WARNING 3023 Ignored
Object in GIS Layer.
Table 5-1 TUFLOW Interpretation of GIS Objects
Used Objects
Point Refers to the 2D cell that the point falls within or a 1D node.
Points snapped to the sides or corners of a 2D cell may give
uncertain outcomes as to which cell the point refers to.
Line (straight line) Continuous line of 2D cells, 1D channel, connects other objects,
alignment of a 3D breakline and other applications.
Note, the algorithm for selecting the 2D cells has varied with
different TUFLOW builds. See Line Cell Selection.
Multiple (Combined) Objects In later versions of TUFLOW, multiple point, polyline and region
objects are generally accepted (ERROR or WARNING messages
are given if not the case).
none These objects are ignored and most commonly occur when a line
of attribute data is added that is not associated with an object. In
MapInfo, this occurs when a line of data is added directly to a
Browser Window (i.e. no object was digitised).
Text Ignored.
Object snapping is often used to relate point data with line and region data, for example with the Read
GIS Z Line command. TUFLOW FV supports point, end and vertex snapping. It does not support edge
snapping.
Different TUFLOW FV GIS input files require different attributes, for example the 2d_mat material
input file only requires a single attribute (with the attribute – Mat), whereas a topographic breakline has
a number of attributes. Each of these file types is described in Table 5-2. It is strongly recommended
that the prefixes described in Table 5-2 be adhered to for all 2D GIS layers. This greatly enhances the
data management efficiency and, importantly, makes it much easier for another modeller or reviewer to
quickly interpret the model. The .fvc command Write Empty GIS Files can be used to automate the
creation of template files which use the recommended GIS data naming convention.
Data input is structured so that there is no limit on the number of data sources. Commands are repeated
indefinitely in the text files to build a model from a variety of sources. For example, a model’s materials
may be built from more than one source. A DTM may be used to define the general topography, while
several 3D elevation lines (breaklines) define the crests of levees or roads. The sequential approach to
reading datasets offers unlimited flexibility and increased efficiency particularly when representing
different scenarios. This layered approach also offers good traceability and quality control.
Suggested Refer to
GIS Data Type Description
File Prefix Section
The .fvc commands MI Projection and SHP Projection are used for model inputs and outputs that are
specified in MapInfo MIF layers or ESRI Shapefile format respectively. If a model has a mixture of .mif
and .shp files as input, then both MI Projection and SHP Projection are required.
TUFLOW FV can extract the projection information from any mif or shp file layer. Typically, at project
start up an empty ‘dummy’ mif or shp GIS layer is created that contains the projection information. The
projection file can be created manually or can be assisted through use of the TUFLOW Viewer Plugin
for QGIS.
Examples:
MI Projection == ..\model\mi\Model_Projection.mif
As an alternative to specifying a .mif or .prj file, the coordinate reference string can be copied out of the
*.mif or *.prj file and read directly from the .fvc. For more information please consult the MI Projection
and SHP Projection Appendix sections.
Note: All MID/MIF/SHP GIS layers read by TUFLOW FV MUST USE this projection or the
following error message is produced:
ERROR 0305 - Projection of .shp file is different to that specified by the SHP Projection == command.
If you are confident that the projection you are using are in fact the same, then you can change this error
to a warning via the command: GIS Projection Check == WARNING.
Note: that the GIS format of an input layer is solely controlled by the file extension (i.e. .mif for
the MIF format and .shp for the SHP format). GIS file extensions should be used in filenames
and TUFLOW FV control files.
Suggested Relevant
GIS Data Type Description
File Prefix Section
Nodestrings 2d_ns_ Optional polyline layer that can used to define 8.2
the location, direction and nodestring type of
external nodestrings.
The .fvc command Write Empty GIS Files can be used to automate the creation of template (empty)
files which use the recommended GIS data naming convention and contain the correct GIS attributes.
The command requires a location where you would like empty files written. The TUFLOW FV
convention is the folder model\gis\empty as shown below.
You only need to write the empty files once during model setup. The TUFLOW FV simulation will stop
after writing the empty files which is the same behaviour implemented in TUFLOW Classic. Once they
are created you can comment the command out (or delete) and continue to develop your .fvc file.
The TUFLOW Viewer Plugin for QGIS can be used to assist with creating these empty files during
model setup.
The TUFLOW Viewer Plugin is available as a free download via the QGIS Plugin Manager .
The commands can occur in any order (if it is a logical one). If an unrecognisable command occurs,
TUFLOW FV stops and displays the unrecognisable text.
1 Elevations and materials are always read from the .2dm file first, regardless of the order of where
the Read Geometry 2d == command is in the .fvc. There can currently only be one mesh file
(.2dm) per model.
3 Commands are executed in the order they occur. If the data for a cell is supplied more than once,
the last data that is read in the fvc is used (i.e. the latter data for a cell overrides any previous data
for that cell).
4 The new GIS commands whilst recommended over legacy commands such as Cell Elevation
File ==, Elevation Polyline File ==, Cell Elevation Polygon == etc. will still be
read in sequential order when combined with these command types. For example, cells intersected
by the CSV-derived elevation polylines in the file ‘Shipping_Channel.CSV’ below will be read into
the model following the Read GRID Zpts == command. The command Read GIS Z Line ==
will overwrite any ‘Shipping_Channel.CSV’ or grid elevations with those provided in
my_road_001_L.shp and my_road_001_P.shp at cells where the datasets overlap.
5 Use the Write Check Files == command (refer Section 12.10) to cross-check and carry out
quality control checks on the final mesh ZB and Material inputs.
6 Simulation Configuration
Chapter Contents
6.1 Introduction 6-2
6.2 Solution Include Statements 6-3
6.3 Spatial Order and Gradient Limiters 6-5
6.4 Units – Metric or US Customary/English 6-6
6.5 Spherical or Cartesian 6-7
6.6 Bottom Drag Model 6-8
6.7 Wind Stress Model 6-9
6.8 Model Timestep 6-10
6.8.1 Adaptive Timestepping and CFL 6-10
6.8.2 Mode Splitting 6-11
6.9 Time Commands 6-12
6.1 Introduction
This chapter outlines the core simulation configuration commands including the solution ‘include’
statements, spatial order selection, units selection, coordinate type and the selection of bed roughness
model.
TUFLOW FV’s adaptive time stepping, CFL control numbers, time stepping limits and mode splitting
techniques are explored as well as the model time format, reference time, model start and end time
definition.
Please note these ‘include’ statements differ in purpose and should not be confused with the Include
files functionality described in Section 4.3.3
Table 6-1 Solution Include Terms
Include Salinity Optionally enable salinity Accessed via TUFLOW FV’s advection
modelling functionality with or dispersion module.
without density coupling.
Include Heat Optionally enable heat flux Accessed via TUFLOW FV’s advection
modelling between the water dispersion module.
surface and atmosphere.
Important for stratified
environments or modelling with
temperature enabled.
Include Optionally enable the modelling Accessed via TUFLOW FV’s sediment
Sediment of cohesive or non-cohesive transport module.
suspended sediments (with or
without hydrodynamic density
coupling) or bed load
sediments. Sediment modelling
is set via a separate TUFLOW
Include Coriolis Optional command used to Coriolis forcing can often be omitted/neglected
switch off the Coriolis force for small study areas or where frictional forces
source term from the dominate in shallow flow areas. i.e. where
momentum conservation Coriolis deflection is limited. Will require either
equations. a spherical coordinates simulation, or
specification of model latitude via a separate
command.
Include bed
Optional command used to Recommended to include bed friction through
friction switch off bed friction. the use of the default value of 1. This option has
been used previously for model testing and
academic/training purposes.
Include wind An optional command used to Turn off to remove wind effects from simulation
remove the wind stress terms e.g. for sensitivity testing.
from the momentum equations
(only relevant if wind is a
specified input using the BC
command):
2
Please contact [email protected] for further documention and information on the sediment transport module.
Generally, initial model development is typically undertaken in 1st order schemes, with 2nd order spatial
schemes tested during the latter stages of development. If a significant difference is observed between
1st and 2nd then the a 2nd order solution is probably necessary, or alternatively further mesh refinement
is required.
For flow conditions with rapidly varying flows such as tsunamis, dam breaks or flood flows in deep,
fast flowing channels, a 2nd order solution is usually necessary and recommended. Likewise, this is also
often the case when modelling high gradients in density, concentration, temperature or other conserved
variables. 2nd order spatial accuracy will typically be required in the vertical direction when trying to
resolve sharp stratification.
A demonstration of the potential ‘smoothing’ effect of numerical diffusion is provided in the mapped
velocity plots in Figure 6-1. The results shown are velocity contours from a laboratory-scale dam break
analysis where both models have been run with identical setups apart from the horizontal spatial order
specified. The left panel of Figure 6-1 uses a first order solution and shows the smoothing of shock
waves when compared to the strong gradients shown in the 2nd order example.
Figure 6-1 1st (left) and 2nd (right) Order Velocity Results Dambreak Flow
Spatial order can also be adjusted for selected material types using the Spatial Reconstruction command
within a Material Block.
When running the second order solution, the horizontal (Horizontal AlphaR) and vertical (Vertical
AlphaR) gradient reduction factor commands may be of use for regions of high spatial gradients or to
assist with improving model stability.
Currently, Imperial Units are currently supported only for 2D flood assessments. They are yet to be fully
implemented for use with the Advection Dispersion, 3D, Heat, Water Quality, Sediment Transport or
Particle Tracking Modules. There has been improved error/warning messaged added to the 2019 Release
if you do try to use: Units == Imperial | US Customary | English with unsupported modules
similar to the following:
Imperial/US Customary/English Units are not yet supported for ice module. Please use Units == Metric
This manual uses the metric term for documentation purposes. If your model uses US Customary
Units the metric term must be substituted for the equivalent US Customary unit as per Table 6-2
when reading this manual, unless otherwise stated.
Table 6-2 Model Units
Length m ft
Note: Please use caution if using Cartesian coordinates in combination with the Include Coriolis
command as you will need to manually specify the Latitude for Coriolis deflection (the default is at the
equator). If using Spherical coordinates, the latitude is read directly from the model mesh and Coriolis
deflection is spatially variable along the north-south axis of the model mesh.
2
If using a Constant Wind Stress Model the wind stress parameterisation stays the same as pre-
2019 builds and is applied using the Bulk Momentum Transfer Coefficient:
3
If using Kondo Wind Stress Model it is now possible to apply a scaling factor using a single term
via the Wind Stress Parameters command.
|𝐮∙𝐧±√𝑔ℎ|∆𝑡
𝐿∗
= CFL
u·n is the flow velocity normal vector from a given cell face.
min(𝐴𝑖 ,𝐴𝑗 )
𝐿∗ is a cell-size dependent length scale 𝐿∗ = 𝐿𝑘
where 𝐴𝑖 , 𝐴𝑗 are the adjacent cell-areas and 𝐿𝑘 is
the face length.
max(|𝐮∙𝐧|,𝑐𝑏𝑎𝑟𝑜 )∆𝑡
𝐿∗
≤1
|D∙n|∆𝑡
𝐿∗ 2
≤1
A variable time step scheme is implemented to ensure that the CFL is maintained below the user
specified CFL control number and Peclet criterion are satisfied at all points in the model with the largest
possible time step. The minimum and maximum timestep limits are provided by the user via the
Timestep Limits command. Outputs providing information relating to performance of the model with
respect to the CFL criterion are provided to enable informed refinement of the model mesh in accordance
with the constraints of computational time.
While the theoretic upper limit for the CFL is one, in practice this value is commonly lowered to provide
additional stability for problems that exhibit large gradients in flow, density or constituent
concentrations such as the assessment of Tsunami, dam break or lakes with strong vertical stratification.
The maximum CFL used by TUFLOW FV can be modified globally using the CFL command or
specifically for the external and internal time stepping calculations (when mode splitting is enabled)
using the CFL External and CFL Internal commands.
A reduced set of equations comprising all terms other than the barotropic (free-surface) pressure-
gradients is initially partially solved. As part of this solution, an appropriate “internal mode” timestep
is calculated that obeys both:
An example of the calculated internal and external timesteps with mode-splitting enabled is shown in
the TUFLOW FV Console Window (refer Figure 6-2). The internal timestep is highlighted by the yellow
box, the external by the red. This internal mode timestep is used to solve internal waves, internal
constituents with wave speeds typically an order of magnitude lower than the free surface shallow water
wave speed and thus can be run at a much larger timestep than the “external mode”.
Prior to updating the solution an “external mode” loop is entered, in which a 2D depth-averaged
reduction of the 3D NLSWE is solved multiple times, using a timestep that obeys the barotropic
Courant-Friedrich-Lewy (CFL) constraint imposed by the shallow water wave speed 𝑢̅ ± √𝑔ℎ (where
𝑢̅ is the depth-averaged current speed). The external mode loop is repeated until the cumulative timestep
is approximately equal to the internal mode timestep.
Mode splitting can be disabled for 2D simulations using the Mode split command and this configuration
can be more computationally efficient for fast, shallow flow scenarios where the “internal mode” and
“external mode” timesteps are similarly restrictive. Currently, 3D simulations are only supported with
mode splitting enabled.
Unless there are compelling reasons to turn mode splitting off it is recommended to run TUFLOW FV
with mode splitting enabled. If unsure you can always run a sensitivity/benchmark tests and compare
your results and runtimes to check if you gain any performance benefit.
The start time and end time commands reside in the fvc (or an include or read file) and define the model
simulation period. If using a restart file, the start time may be overwritten depending on the configuration
of the use restart file time command (for more information on using restart files please refer to Section
10.7.3).
If using time format == hours, the Reference time default value is 0hrs. For time format ==
ISODATE, the Reference time is set to 01/01/1990 00:00:00 by default. This is important to note when
visualising and processing results and input data from programs such as MATLAB. For example,
TUFLOW FV will output times to NetCDF output in decimal hours from 01/01/1990 00:00:00 whereas
the convention in MATLAB is to output serial times in decimal days since 01/01/0000 00:00:00 and if
overlaying datasets some time conversions will be likely required.
If reading in NetCDF boundaries with differing reference times, the bc reference time and bc time units
commands may be of use (these are detailed further in Chapter 10. Examples of NetCDF input and
output files are provided in Appendix D and Appendix E for reference.
7 Model Parameters
Chapter Contents
7.1 Introduction 7-2
7.2 Turbulence 7-3
7.2.1 Eddy Viscosity 7-3
7.2.1.1 Horizontal 7-3
7.2.1.2 Vertical 7-3
7.2.2 Scalar Diffusivity 7-4
7.2.2.1 Horizontal 7-4
7.2.2.2 Vertical 7-4
7.3 Reference Values 7-5
7.4 Wetting and Drying Thresholds 7-7
7.5 Stability Limits 7-8
7.1 Introduction
This chapter describes the horizontal and vertical turbulence related commands, stability limits, model
reference values, and wetting and drying specification.
7.2 Turbulence
TUFLOW FV has a variety of options for simulating horizontal and vertical viscous fluxes. The
horizontal eddy-viscosity can be specified directly or can be calculated using the Smagorinsky scheme.
Simple parametric models for vertical mixing are also incorporated within the TUFLOW FV engine.
TUFLOW FV allows the horizontal scalar diffusivity to be specified as a constant value or calculated
from a Smagorinsky or Elder model. The vertical scalar diffusivity may also be directly specified or
calculated using parametric formulations which vary depending on the scalar type.
For more complicated turbulence model algorithms an interface for linking with various external
turbulence models has been implemented (e.g. GOTM, http://www.gotm.net/). TUFLOW Support can
be contacted for further information on coupling TUFLOW FV with external turbulence models:
[email protected].
The horizontal and vertical-mixing options are set in the TUFLOW FV Simulation Control File (.fvc).
7.2.1.2 Vertical
Vertical-mixing eddy-viscosity can be defined as a constant value or calculated using a parametric model
or external scheme set by the Vertical mixing model command. Eddy-viscosity values for the constant
and parametric models can be set globally via the Vertical mixing parameters command (if using an
external scheme such as GOTM, the external model calculates the eddy viscosity (at a time increment
defined by the turbulence update dt) and returns it to TUFLOW FV). The parametric model is based
on a parabolic eddy-viscosity profile in the lower-half of the water column transitioning to a constant
eddy-viscosity in the upper-half and applies the Munk & Anderson limiters in the case of stable
stratification. For systems with strong vertical gradients the use of an external vertical turbulence mixing
model is recommended. For parametric and external schemes eddy viscosity limits can be applied using
the Global vertical eddy viscosity limits command. The global commands can be overwritten on a
material basis using the vertical eddy viscosity limits command within a Material Block (refer Section
8.5).
7.2.2.2 Vertical
The vertical-mixing scalar diffusivity can be defined as a constant value or can be calculated using a
parametric or external model (see Vertical mixing model). Coefficients for each model are applied
using the Vertical mixing parameters command. If using an external model, diffusivity is calculated on
a user-defined time interval turbulence update dt. The parametric model is based on a parabolic eddy-
viscosity profile in the lower-half of the water column transitioning to a constant eddy-viscosity in the
upper-half and applies the Munk & Anderson limiters in the case of stable stratification. Upper and
lower bound values can be specified globally using the Global vertical scalar diffusivity limits command
and also on a material basis (refer vertical scalar diffusivity limits, and Section 8.5) which allows spatial
variation.
Kinematic viscosity
Sets the kinematic viscosity of water. <Default = 1.05e-06 m2/s>. This value is used as a lower limit in
the parametric vertical eddy viscosity and is also used in various formulae within sediment transport and
particle tracking modules.
Latitude
Globally sets the model latitude. < Default = 0 degrees>. Positive value for northern hemisphere and
negative for southern hemisphere. Used to calculate Coriolis source term for cartesian grid models (i.e.
UTM coordinate system). Note that spherical coordinate system is preferred where Coriolis effects may
be significant.
Density air
Globally sets the density of air <Default = 1.20 kg/m3>. This value is used to calculate wind stress and
atmospheric heat exchange source terms. May be over-ridden by values specified in Holland
(parametric Tropical Cyclone model, refer Section 10.5.3.2) boundary condition file or will be
calculated internally when the Kondo wind stress model is specified.
Reference MSLP
Globally sets the mean sea level pressure <Default = 1013.25 hPa>. This value is used in the
atmosphere module when a mean sea level pressure boundary condition has not been specified. The
global MSLP value is used in various atmosphere module heat exchange routines. A globally uniform
MSLP value will not drive a direct hydrodynamic response as it does not result in any pressure
gradients.
Reference density
Sets the reference density (of water) <Default = 1000 kg/m3>. For baroclinic simulations (where
density may vary locally based on salinity, temperature or suspended sediment concentration) this
value is used as the baseline from which density gradients are calculated. Numerical accuracy of
baroclinic simulations can be marginally improved by setting this value close to a typical value
expected in the model (e.g. 1,027 kg/m3 for ocean simulations). For non-baroclinic simulations this
command will globally set the density which is used in various source term and sediment transport
formulae.
Reference salinity
Sets the reference salinity <Default = 0 psu>. Numerical accuracy of baroclinic terms in NLSWE can
be marginally improved by setting this value close to a typical value expected in the model (e.g. 35.0
psu for ocean simulations). For non-baroclinic simulations this command will globally set the salinity.
May also be used to globally initialise salinity in the absence of other relevant initial conditions.
Reference temperature
Sets the reference temperature (of water) <Default = 20 degrees celsius>. Numerical accuracy of
baroclinic terms can be marginally improved by setting this value close to a typical value expected in
the model. For non-baroclinic simulations this command will globally set the temperature. May also
be used to globally initialise temperature in the absence of other relevant initial conditions.
Sets the specific heat capacity of air <Default = 1005.0 J/Kg/oC>. Used to calculate atmospheric heat
exchange source terms. The specific heat capacity value will be calculated internally when the Kondo
wind stress model is specified.
Set the specific heat capacity of water <Default = 4181.3 J/Kg/oC>. Used to calculate atmospheric
heat exchange source terms. The specific heat capacity value will be calculated internally when the
Kondo wind stress model is specified.
In terms of the TUFLOW FV computations, the drying value corresponds to a minimum depth below
which the cell is dropped from computations (subject to the status of surrounding cells). The wet value
corresponds to a minimum depth below which cell momentum is set to zero, in order to avoid unphysical
velocities at very low depths. The default wetting and drying values can be modified using the Cell
wet/dry depth command in the TUFLOW FV Control File (.fvc).
Modellers are advised to set these limits to be as low as practicable to ensure that any real instabilities
are ‘caught’ as soon as possible, but any small anomalous and acceptable spikes in water level or velocity
do not cause a model exit. For typical ocean modelling in most parts of the world it might be appropriate
to set these limits to a 10 m water elevation and a 5 m/s maximum current. These limits will capture
most of the highest expected water levels due to tide and storm surge effects as well as set an appropriate
limit for tidal currents in an open area. If modellers are trying to capture extreme water levels or high
currents through narrow choke points, then it is possible that these limits should be increased.
Difficulties arise when investigating catchment models. In these situations, the topography may contain
elevations above the maximum water level (if using a mean-sea-level datum for example). If any of
these high cell elevations become wet due to rainfall inputs or upstream inflow boundary conditions,
then this will instantly trigger a model exit. For these models it is important to set the maximum water
level limit to be higher than the highest expected cell elevation that will get wet, plus any additional
water depth expected in that cell.
8 Model Geometry
Chapter Contents
8.1 Mesh Generation 8-2
8.1.1 Choosing a Mesh Generator 8-3
8.1.2 Mesh File Format (.2dm) 8-3
8.2 External Nodestrings 8-7
8.3 Elevations 8-8
8.3.1 Direct Reading from .2dm Mesh 8-8
8.3.2 Updating Elevations from a Grid 8-8
8.3.3 Breakline Layers 8-9
8.3.4 Legacy Elevation Update Options 8-10
8.3.4.1 Cell Elevation Polyline File 8-10
8.3.4.2 Cell Elevation Polygon File 8-11
8.4 Materials 8-12
8.5 Material Block 8-14
8.5.1 Bed Resistance 8-14
8.5.2 Active/Inactive Areas 8-14
8.5.3 Horizontal Eddy Viscosity 8-15
8.5.4 Horizontal and Vertical Eddy Viscosity Limits 8-15
8.5.5 Horizontal Scalar Diffusivity 8-16
8.5.6 Horizontal and Vertical Scalar Diffusivity Limits 8-16
8.5.7 Bed Elevation Limits 8-17
8.5.8 Spatial Reconstruction 8-17
Creating a mesh is a combination of manual and automated steps. Maintaining a reasonable amount of
manual intervention into the design of the mesh will ultimately produce a far more efficient mesh which
will be more accurate and computationally efficient.
Using a mesh generator, a TUFLOW FV mesh (SMS .2dm format) is constructed using nodes (points),
arcs and vertices (polylines). These “mesh controls” are generally positioned manually by the modeller
using their preferred mesh generation tool. Important features of an area to be modelled may include
islands, rivers and inlets, deep channels or man-made infrastructure. A good mesh is constructed using
the mesh controls (nodes, vertices and arcs) to neatly resolve the important features within the model
domain.
Figure 8-1 provides an example of the mesh controls and the resulting mesh for a section along a river
bend. The left panel shows the mesh controls, namely:
The positions of the mesh controls have been defined by the modeller and in this case are located to
resolve the river banks and the main channel. The vertices have been distributed evenly along each arc
and control the number of mesh cells that can occur along the arc. The right panel shows the resulting
mesh that is generated by the mesh software.
You can reproduce the mesh shown in Figure 8-1 by following along the steps in Tutorial Model 02.
• Aquaveo SMS
Setting up and running a TUFLOW FV model simulation does not necessarily require a detailed line by
line inspection of the mesh file; SMS or GIS provides a graphical interface to do this instead.
Nevertheless, a modeller may find it necessary at times to interrogate the 2dm file in detail.
MESH2D
MESHNAME "illustration of a 2dm file"
E4Q 1 2 1 9 10 1
E4Q 2 3 2 10 11 1
E4Q 3 4 3 11 12 1
E4Q 4 6 5 1 2 1
E4Q 5 7 6 2 3 1
E4Q 6 8 7 3 4 1
E4Q 7 14 13 5 6 1
E4Q 8 15 14 6 7 1
E3T 9 16 15 7 1
E3T 10 16 7 8 1
ND 1 2.48000000e+001 4.02800000e+001 0.00000000e+000
ND 2 3.30421270e+001 4.21236640e+001 -1.00000000e+001
ND 3 4.12871134e+001 4.39683219e+001 -1.00000000e+001
ND 4 5.20800000e+001 4.58200000e+001 0.00000000e+000
ND 5 1.76200000e+001 6.18200000e+001 0.00000000e+000
ND 6 2.57990034e+001 6.57578467e+001 -1.00000000e+001
ND 7 3.39997467e+001 6.96992724e+001 -1.00000000e+001
ND 8 4.34600000e+001 7.37100000e+001 0.00000000e+000
2dm Layout - SMS ND 9 2.56200000e+001 1.85400000e+001 0.00000000e+000
ND 10 3.42333333e+001 1.88833333e+001 -1.00000000e+001
ND 11 4.28466667e+001 1.92266667e+001 -1.00000000e+001
ND 12 5.53200000e+001 1.95700000e+001 0.00000000e+000
ND 13 1.21000000e+000 8.02700000e+001 0.00000000e+000
ND 14 9.62000000e+000 8.52633333e+001 -1.00000000e+001
ND 15 1.80300000e+001 9.02566667e+001 -1.00000000e+001
ND 16 2.64400000e+001 9.52500000e+001 0.00000000e+000
NS 9 10 11 -12 1
2dm File Contents – Text Editor
NS 16 15 14 -13 2
The contents of the .2dm file required for TUFLOW FV simulations are:
Nodes: Lines that commence with a “ND” are nodes, or the points that define the edges of the elements.
Each ND line describes the node ID and its x, y and z (i.e. bed level) coordinate. The screen shot in
Figure 8-3 shows node 236 selected and its corresponding position and elevation displayed in the X,Y,Z
dialog boxes.
Elements: Lines that commence with an “E4Q” are quadrilateral (4 sided) elements. Each E4Q line
describes the element ID, the four nodes that define its connectivity and spatial extent (in a counter-
clockwise direction) and the material type.
Similar to E4Q, the “E3T” lines are triangular elements. Each E3T line describes the element ID, the
three nodes that define its connectivity and spatial extent (in a counter-clockwise direction) and the
material type.
Nodestrings: Lines that commence with a “NS” are nodestrings, which are used to define boundary
conditions locations. Each NS line defines the series of nodes that form the string, the last node number
is assigned as negative. The number following the negative number is the nodestring ID.
Once the mesh is developed and saved, the .2dm file is read using the .fvc command Geometry 2D and
can be used in conjunction and layered with other elevation commands, e.g. Read GIS Z Line and Cell
Elevation File. These methods are described further in Section 8.3.3 and 8.3.4.
Nodestrings input by the Read GIS Nodestring == command are additive to those existing in the
.2dm or already specified in previous Read GIS Nodestring or Nodestring Polyline File commands.
The Read GIS Nodestring == command requires that all nodestring ID’s in the model are unique.
This includes any that have been specified in the .2dm or nodestring polyline file. If nodestrings with
identical IDs are input then TUFLOW FV will generate an error and you will need to renumber your
inputs. Future versions of the software will include better handling of duplicate nodestring id’s such as
automatic renumbering. The required attributes when using a 2d_ns input layer is provided in Table 8-1.
Table 8-1 GIS Nodestring (2d_ns) Attributes
8.3 Elevations
8.3.1 Direct Reading from .2dm Mesh
The .2dm file defines the base elevations within the model using the Geometry 2d command. The .2dm
format supports elevations only at the nodes or corners of each cell. When TUFLOW FV reads the mesh
geometry file cell centred bed elevations are interpolated from the .2dm node locations. In many
instances, this interpolation is not an issue. However, there may be instances where this is not preferred
and the Read GRID Zpts command can be used to specify exact cell centred elevation values.
Figure 8-7 shows an example study area where the grid DEM_5m.asc is read via the following
command. This grid is interpolated to the mesh cell centres. The output _mesh_check file can be
reviewed and coloured to show the interpolated ZB values from the grid DEM_5m.asc.
Figure 8-7 Cell Centre Elevations Assigned via Read GRID Zpts
GIS layers used for Read GIS Z Line can be split into more than one layer to better manage the variety
of data these commands sometimes require.
For example, one layer may contain the elevation points and another breaklines. This is useful in terms
of managing the data, and especially when interrogating and/or viewing the data in GIS. It is a
requirement of the shapefile format that the different geometries (points, lines and regions) are in
separate shapefiles. The TUFLOW empty template files include the following filename suffixes to
differentiate which files are suitable for point, line or region features.
This is optional for MapInfo users; the different geometries can occur in the same MapInfo file or can
be separated if preferred.
A maximum of nine (9) layers per command line is allowed, and each layer is separated by a vertical
bar (“|”). For example, to read a Z Shape layer which has both line and points, the command may be:
Multiple points layers can be specified. The points layer can be referenced in any location except for
the first layer within the command line entry.
Incorrect:
Read GIS Z Line == gis\2d_zln_M03_002_P.mif | gis\2d_zln_M03_002_L.mif
Correct:
Read GIS Z Line == gis\2d_zln_M03_002_L.mif | gis\2d_zln_M03_002_P.mif
1 Z Elevation (or change in elevation for ADD option) of the point. Float
OR
More than one “cell elevation” command line can be defined with a simulation control file (fvc), and/or
more than one point per cell can be entered. Depending upon input preference, each z value will
overwrite the preceding z value entry, or an average of all points within each cell will be assigned. If
multiple cell elevation files are listed, where inputs from one entry fall with the cell of a preceding entry,
the later entry in the .fvc (lower) entry supersedes the previous (higher). You can check that elevation
updates have been assigned correctly by using the Echo Geometry CSV to produce a set of text files (to
the log directory) that identify cells that have been modified from the base .2dm as follows:
Echo geometry CSV == 1
The cell elevation file option does not interpolate between successive points. If using the cell elevation
file for continuous linear features (such as a road or levee), ensure that the point resolution is sufficiently
fine to accurately represent the elevations along the feature, or use the Read GIS Z Line command further
described in Section 8.3.3.
Note: A list of all cell ID and corresponding X,Y co-ordinates can be obtained from the geometry
log files.
Although still supported the GIS Integrated Read GIS Z Line is now preferred over the Cell Elevation
Polyline File or Cell Elevation Polygon File Commands.
Input data is defined using a CSV file containing X,Y, Z and ID, data. Points within the CSV file define
the vertices along the polyline. Intermediate cell elevations between vertices are interpolated.
Multiple polylines can be defined within a single CSV file. The ID attribute is used to differentiate
between the different polylines. A unique command line input for each polyline is required within the
simulation control file (fvc), as shown below.
8.4 Materials
Material layers are used to differentiate sections of the model domain. Materials layers can be used to
spatially vary a range of bed properties including:
• Active/inactive areas
• Spatial reconstruction
The recommended approach is to assign a unique material to represent a different landuse or bed
characteristic. GIS layers of land-use or vegetation often make excellent material layers. Examples of
different materials are main river channel, river banks, floodplain, sea grass meadows, buildings, sand
banks, mangroves, etc.
Materials can either be assigned during mesh development using your preferred mesh generator
(Aquaveo SMS or the GIS Mesher) or assigned/modified following mesh development directly by
TUFLOW FV using the Set Mat and Read GIS Mat commands.
Prior to the 2019.01.008 TUFLOW FV Release the only way to assign materials was directly via the
.2dm file. While this method is still available, the preferred approach is to digitise one or more 2d_mat
materials layers (see Table 8-4) and assign materials within a Material Block. This approach allows the
easy adjustment of surface characteristics, for example modifying bed resistance during model
calibration or sensitivity testing.
In creating the base 2d_mat layer, it is good practice to not digitise the most common or the most difficult
to digitise material and use the following data layering of commands in the .fvc:
• Use Set Mat to set the most common material to all cells in the domain.
• Use Read GIS Mat to allocate the remaining material values.
The Read GIS Mat command may be used as many times as required to further modify the materials in
parts of a 2D domain. Each subsequent dataset will overwrite the preceding assigned material value, as
described. i.e. layers called lower down the input file will be read in preference to those above them
where to two layers overlap.
Table 8-4 2D Material (2d_mat) Attribute Description
Default GIS
No. Attribute Description Type
Name
1 Material The material ID value referenced within a Materials Block (refer Integer
Section 8.5).
The following example shows a global bottom roughness, then a series of material blocks changing this
for three of the material IDs.
The example below presents a global bottom roughness that is modified for three of the materials.
be permanently dry. This is commonly used for impact assessments when switching off certain cells to
simulate an area of development or can be used to switch of large sections of a model to conduct further
testing on a model subset.
The below example shows how to switch a single material to inactive, the default status for all cells is
active.
This is usually done to smooth instabilities in regions of the model that are not near the area of interest
(such as the corners of offshore boundaries). Users should take care with using this command without a
suitable understanding of the physical relevance of adjusting the momentum mixing spatially.
The below example shows a global horizontal eddy viscosity being set for a Smagorinsky momentum
mixing model, with the Smagorinsky parameter being altered for two different materials.
The below example below shows the turbulence being set to a minimum level of mixing in the cells
with the material ID of 10.
This is usually done to smooth instabilities in regions of the model that are not near the area of interest
(such as the corners of offshore boundaries). Users should take care with using this command without a
suitable understanding of the physical relevance of adjusting the momentum mixing spatially.
The following example shows a global horizontal scalar diffusivity being set for a Smagorinsky scalar
mixing model, with the Smagorinsky parameter being altered for two different materials.
The example below shows the diffusivity being set to a minimum level of mixing in the cells with the
material ID of 10.
This example shows three materials set to different limits. Material 1 is trimmed so that any elevations
below datum level -10m are set to -10 m, without limiting higher levels. Material 2 is entirely set to
+5m. Material 3 is trimmed to the same minimum level as material 1, but with an upper limit of -2m
which might be below the tidal minimum, ensuring wet cells.
This is commonly used near offshore boundary conditions to reduce the computational overhead, or to
reduce instabilities if second order computations are not otherwise used there.
The following example shows three materials, with the first one (material ID 10) being set back to first-
order.
9 Modelling in 3D
Chapter Contents
9.1 Introduction 9-2
9.2 Overview 9-3
9.3 3D Layer Z Coordinate Options 9-4
Sigma Coordinates 9-6
Z Coordinates 9-7
Hybrid Z-Sigma Coordinates 9-7
9.4 Density Coupling 9-9
9.5 Reviewing 3D Results 9-10
9.6 3D Boundary and Initial Conditions 9-11
9.7 3D Structure Conditions 9-12
9.1 Introduction
This chapter describes commands specific to the 3D module of TUFLOW FV. It provides general
guidance on the 3D modelling process including sections on the additional data and visualisation
challenges that 3D modelling requires. The chapter outlines 3D model geometry commands and
provides a quick reference to navigate the relevant 3D sections concerning boundary, intial conditions
and model outputs.
9.2 Overview
2D depth-averaged simulations can be an excellent approximation for many applications and are often
used for the simulation of flooding, tsunamis and storm surge amongst others. However, there are cases
where 3D modelling is required to sufficiently describe the observed flow characteristics, for example.
in areas where there is significant variation in magnitude and direction of velocity with depth (counter
currents, helicoidal flows) or where the effects of density become important (stratified environments or
dense plume outfalls for instance).
For example, to represent a thermally stratified system well, we need to choose a suitable vertical
discretisation of the water column to adequately capture thermal gradients and the location of the
thermocline using the Vertical Mesh Type and a suitable vertical layering (refer to Section 9.3). To
reproduce these gradients, the modelled vertical mixing needs to be realistic, (i.e. not too much or too
little) and model performance can be sensitive to the selection of the vertical mixing model and vertical
spatial order. To allow model calibration, we need accurate information on inflows and the temperature
profile of the system as a function of depth, thus additional monitoring project costs may be required.
To ensure surface temperatures are well represented energy flux between the water surface and
atmosphere TUFLOW FV’s atmospheric heat flux module may be required (using the include heat
command) driven by site specific meteorological data including: incoming shortwave energy, longwave
energy, surface wind speeds and relative humidity. Similar modelling considerations are required if
modelling an estuarine or offshore environment where both temperature and salinity play a role.
Assignment of 3D initial and boundary conditions are also required to allow the specification of currents,
salinities, temperatures and other scalar variables as both a function of time, space and depth. Section
10.5.5 provides specific guidance on the development and application of these boundary condition
inputs.
To become familiar with the setup, simulation, analyses and visualisation of an example 3D model we
encourage you to try out our free 3D estuary tutorial, Tutorial Module 5 on the TUFLOW FV Wiki.
Note: The assignment of z coordinates can be checked via the IDX3 attribute of the _mesh_check_R
file (refer Table 12-5).
Sigma Coordinates
Using sigma coordinates, layers follow the bed profile with the spacing specified as a percentage of the
water depth via the Layer Face File. This layering is completed consistently for each cell throughout the
model domain, regardless of the water depth. For example, a model with five equal sigma layers in 100m
of depth will have 5 layers, each 20m thick. The same model in 1m of depth will have 5 layers, 0.2 m
thick. Although this example assumes an even distribution of sigma layers, the user is free to distribute
layers as they see fit. Optionally, to improve stability in areas of shallow flow or wetting and drying that
are likely to be well mixed, a Cell 3D Depth threshold value can be applied, such that vertical fluxes
between layers are switched off below these depths and the solution scheme effectively becomes 2D
(depth-averaged). Compatible commands when using a sigma coordinate approach are provided in Table
9-1
Sigma layering is useful at providing high resolution layering typically near surface or near bed to
capture boundary layer problems with a low computational overhead. i.e. bed following layers can be
stacked tightly near the bed and water surface but left relatively sparse through mid-depths to avoid
unnecessary 3D cells. If using bed morphology coupling in 3D, then it is a software requirement to use
sigma layering.
Limitations associated with the sigma coordinate scheme can occur in regions of highly sloping
bathymetry. In these regions, sigma schemes can be prone to horizontal pressure gradient errors if
horizontal grid cell resolutions are not well resolved. Additionally, in regions where thermal
stratification is prevalent near the surface, i.e. lakes, a z coordinate or z-sigma hybrid may be more
accurate at resolving a stratified water column.
Z Coordinates
Z coordinate layers are set at a series of fixed elevations using the Layer Face File in combination with
the Vertical Mesh Type command. TUFLOW FV does not allow a z-layer to be switched off due to the
water level dropping below its lower limit. Therefore, when using a Z coordinates scheme, it is
important that the highest elevation within the Layer Face File remains wet, i.e it’s not at an elevation
subject to wetting and drying.
The z coordinate approach can provide fine consistent resolution throughout the domain independent of
water depth, which can be particularly useful if trying to model strong stratification in the upper layers
of the water column. On the flipside, if the study area contains sloping bathymetry it can be challenging
to efficiently provide high resolution near the bed (for example if near bed sediment processes are
important) without including redundant high resolution in other parts of the model.
In areas of sloping bathymetry, z coordinates can result in thin layers close to the bed, that in turn can
potentially lead to numerical instabilities. To avoid these issues TUFLOW FV offers the option to set a
Min Bottom Layer Thickness that prevents a thin bottom layer from being generated when using the for
z coordinate or z-sigma hybrid schemes.
Compatible commands when using a z coordinate approach are provided in Table 9-1
This method provides flexibility and stability in areas of wetting and drying not available via a z only
coordinate system whilst providing the potential for high resolution near-surface exchange and gradient
capturing. Compatible commands when using a z-sigma coordinate approach are provided in Table 9-1
An example excerpt using the hybrid z-sigma coordinate approach is provided in Figure 9-2. Using this
example, a z-coordinate system is used below -3m (m in the project vertical datum). To avoid
instabilities here the user has assumed that at all times, and at all cells, the model does not dry out below
-3m. Below -3m there are 9 vertical layers between -3m and -16m and a single vertical layer below -
16m terminating at the bed. At each cell location, if any layer faces are below the bathymetry they are
ignored during the simulation. To avoid ‘skinny’ vertical layers truncated by the bathymetry (if the ZB
at a cell is between two layer faces) then the user has used a Min Bottom Layer Thickness cell threshold
0.5 m. This means that we should not have any bottom layers in our 3D solution at the bed less than
0.5m.
Four equally distributed sigma layers are specified between -3m and the water surface, noting that these
layers may stretch and contract in response to changes in water level as the simulation progresses. In
regions of wetting and drying a Cell 3D Depth threshold is applied to disable 3D calculation in well
mixed regions of the coastal zone, in our model case tidal mudflats adjacent to the main estuary channel.
Figure 9-2 Hybrid Z-Sigma example setup (left) with z layer face file (right)
Figure 9-2 below provides an example model output from a coastal estuarine model with both salinity
and temperature density coupling enabled in addition to atmospheric heat exchange. The model uses a
hybrid z-sigma layering system. Fresh river water enters the systems at chainage zero at the left of the
plot. At the right the ocean tide is applied. The density effects at the mixing interface of river and ocean
is clearly visible, with relatively buoyant river water moving over the salt water “wedge” below.
If running TUFLOW FV in baroclinic mode, it is recommended that the user complete sensitivity testing
on the a range of vertical layering discretisations, experiment with the vertical spatial order and vertical
turbulence and diffusivity options (refer Section 7.2) early in the modelling process to allow you to
quickly optimise your setup and runtime for the problem at hand. Further guidance on 3D baroclinic
modelling is also in the overview section of this chapter (Section 9.2).
Salinity (ppt)
35
31.5
2 28
24.5
0
Elevation (m MSL)
21
-2
17.5
-4
14
-6
10.5
-8 7
0 2000 4000 6000 8000 10000 12000
Chainage (m)
3.5
3
Please contact [email protected] for further information on TUFLOW FV’s sediment transport module.
While all basic outputs can be provided in 2D by depth-averaging the results, modellers should take care
that this is an appropriate way to visualise and investigate your study area. Consider the following simple
problem (refer Figure 9-4): a tidal river with a complex vertical profile of currents, with near-surface
(fresh-water) currents flow downstream and near-bed (salt-water) currents flowing upstream. If these
two overall flow magnitudes are similar, then the depth-averaged currents will be zero!
Figure 9-4 Counter current velocity at depth. Considerations for result depth averaging.
As there are many ways to visualise data, and a myriad combination of different features to be looking
for, it is important that any tools used are as flexible as possible. For the visualisation of 3D results the
Unidata NetCDF format is commonly used within TUFLOW FV due to NetCDF’s ability to efficiently
handle multi-dimensional data structures. To assist with the visualisation of 3D NetCDF results, we
offer MATLAB and/or Python toolboxes with example scripts to help you get started. It is recommended
that modellers investigate the usage these tools as they allow for the most customised requirements to
be developed by the modeller in order to investigate specific aspects of each model.
TUFLOW FV also offers a range of depth averaging approaches that allow 2D visualisation of 3D results
via the familiar DATV or XMDF outputs that can be readily opened in SMS and QGIS. For more
detailed instruction on using the various model outputs please refer to Chapter 12.
When applying 3D boundary conditions, users need to ensure that the depth values in the boundary
condition file make sense relative to the bathymetry of the model. This is particularly noticeable with
gridded 3D boundaries, or curtain boundaries where dummy values are used in the NetCDF file below
valid depths. If the coarseness of the boundary condition means that these ‘invalid’ depths are actually
valid in the model bathymetry then the dummy values will be applied to the model. Users should aim to
‘pad down’ the last appropriate real value, so that any variation between the boundary condition
bathymetry and the model bathymetry does not cause problems.
The 3D boundary and initial conditions available within TUFLOW FV are provided in Section
10.5.5 on the Boundary and Intitial Condition Chapter (Chapter 10).
When implementing 3D models with hydraulic structures, modellers need to exercise care to understand
the assumptions and approximations required to transfer mass and momentum fluxes at the structure.
For example, the flow distribution may be based on, depth, cell width or area upstream and downstream
of the structure. These approximations are typically based on simple vertical profiles of velocity and
constant vertical profiles of scalar terms. However no fully-3D structure controls have been
implemented that guarantee that the vertical profile of the water will be maintained through the structure.
Section 11.2 provides an overview and several examples of using 3D commands within a structure
block.
10.1 Introduction
This chapter describes the assignment of model boundary and initial conditions including restart file
setup and the use of hydrodynamic transport files which allows de-coupling of the hydrodynamics and
any advection-dispersion, water quality, sediment and particle tracking modelling for improved
efficiencywhen modelling multiple scenarios.
When defining a boundary condition block the first line is used to specify the input type, the location
and reference file that contains the relevant boundary condition data. Where boundary conditions inputs
vary from default values these details are specified within the boundary condition block.
When developing complex models with many boundary conditions, Include files are recommended to
manage/categorise data inputs. Some example boundary condition blocks are shown below. Worked
examples are available via the TUFLOW FV tutorial models on the TUFLOW FV Wiki:
http://fvwiki.tuflow.com
a. Nodestrings can be defined within a model either when the model mesh is created (refer
to Figure 8-6 or by using the Nodestring Polyline File or Read GIS Nodestring
command.
4) Gridded: Gridded NetCDF format data can be used to define temporally and spatially varying
inputs over an entire computational mesh or a subregion. If using gridded data, a grid definition
file and grid definition variables are first required to define grid coordinates and variable names
within the input file. These commands need to be specified prior to the boundary condition
block
5) Global: Common values can be specified across the entire model using CSV file inputs.
Not all of the above methods are available to all boundary condition types (water level boundaries can
only be applied to nodestrings for example). For those that offer multiple options (for example an inflow
boundary), there are different BC type commands to get these different behaviours (for example Q for
inflow to a nodestring, QC for inflow to a cell and QC_POLY for inflow to a group of cells within a
polygon).
Additionally, a BC update dt command can be used to control how often this interpolation is done. All
timesteps after one boundary condition update, but before the next one will use a constant value for that
boundary condition. If no boundary condition update dt is specified, TUFLOW FV will interpolate the
specified values at every computational timestep of the model.
Users must take care that this behaviour is understood and recognised in their model. Common errors
that can arise when ignoring this behaviour are as follows:
• For an inflow release that only covers part of the modelled period not having a ‘zero’ value at
the start and end can lead to the boundary condition continuing unintentionally. The below
figures show a case where the desired behaviour is a flow release of 10 m³/s for 7 days. The left
figure will continue the flow rate before the first timestep and after the last one. The example
on the right has additional timesteps just before and just after the release to return the flow rate
back to zero.
Time Flow
01/01/2019 00:00 0
Time Flow 01/01/2019 00:01 10
01/01/2019 00:00 10 07/01/2019 23:59 10
08/01/2019 00:00 10 08/01/2019 00:00 0
• Occasionally (due to rounding errors or varied inputs) a boundary condition file will have a
timeseries where some timesteps are repeated or are not in monotonically increasing order. As
the interpolation method in TUFLOW FV does not account for the removal of any timesteps,
and the model will cease with the error message ‘'TIME column must be monotonically
increasing'.
• If the boundary update timestep is too coarse (or the main timestep of the model), it is possible
that not all inputs from a boundary condition will be used within the model. Users must take
into consideration that the model is not reading a timeseries exactly, but is interpolating it onto
a different timestep, which may change the overall effect. For example, a flow input with large
peaks that are not aligned with the timestep of the model will not have the same peak flow rate,
or total inflow volume as the raw input data.
If a boundary condition is outside of the model domain, it will be ignored and no mapping of this to the
nearest cell is available. Warnings will be thrown within the log file when this occurs, but may generally
happen for the following reasons:
• Model reschematisation: If users change the shape of their mesh without adjusting the x and y
coordinates of the inflows then they may occur outside the desired location.
• Coordinate projection: If a mesh uses geographic (lat/lon) coordinates but an inflow is specified
at a UTM (eastings/northings) location then it will be seen as outside the model. Note: If running
the model with GIS integration then this issue should be caught by ERROR 0305 - Projection
of .mif/shp file is different to that specified by the MI/SHP Projection == command will occur.
• Moving BCs interpolating in space: Moving boundary conditions will interpolate their position
from the specified file with respect to the current timestep. In concave mesh sections, this can
cause an intermediate coordinate to fall outside of the model domain.
The above problems can also affect gridded NetCDF boundary conditions. Users must take care that the
boundary conditions are being applied to the model in the way they expect. Usually this is best achieved
by first running simplistic model cases, to QA the boundary conditions that are being applied.
10.4.3 BC Headers
TUFLOW FV allows users a great deal of flexibility in how they specify their input files. The requisite
variables in a CSV or NetCDF file can be ‘called’ (by the header line in a CSV or the variable name in
a NetCDF) whatever the user wishes. However, if these variables differ from the default variable names,
then users must tell TUFLOW FV which headers to look for.
This is powerful as it allows users to have multiple variables in files that may have names that are more
convenient to the project than a list of default inputs. The examples below show a set of desired input
names and the corresponding default input header names for an inflow boundary (QC) with both salinity
and two sediments modelled.
The way TUFLOW FV interprets the headers is with a bc header command in the relevant BC block.
The order of these headers is what TUFLOW FV uses to map the header name to a tracked variable
within the model. Users must take care that these are specified in the correct way, for example TUFLOW
FV does not throw a warning if you accidentally name the temperature variable ‘Salinity’.
Desired Input:
Default Input
The expected default order of the variables in all files follows a standard order that differs for different
boundary conditions (OBC conditions specify water level and currents for example, whereas Q
conditions just specify flow). The main variables are specified in Table 10-2 and Table 10-3 followed
by the tracers in a standard scalar order:
Salinity (if modelled), Temperature (if modelled), Sediment_1, …, Sediment _n (If Sediment modelled),
Tracer_1, …, Tracer_n (If tracers modelled), WQ_1, …, WQ _n (If WQ modelled).
The above are only included if they are being modelled. The previous input examples are modelling
salinity and two sediments, so the BC headers would look as follows:
If the user decided to switch off tracking salinity (include salinity == 0,0) then they would also need to
update they bc header line as follows:
If they did not update this line, the model would interpret the third header as the input for SED_1, which
would have been ‘salinity_surface’. All other variables after that would also be reading the incorrect
columns.
The TUFLOW FV log file prints out the default expected names for each variable, followed by the
headers that the user has specified. This can be used to ensure that the headers have been specified
correctly.
These inputs can be used to quickly sensitivity test boundary condition forcing if need be. Examples are
scaling up a flow boundary condition by 10% to represent climate change or elevating an offshore tide
boundary by a future sea-level-rise offset without needing to create a new copy of any of the boundary
condition files. Note that each header within a boundary condition (excluding time) gets a separate scale
and offset as specified with comma separated values.
Another example is for splitting a boundary condition into separate inputs spatially or vertically without
needing to create different boundary condition inputs. The following example shows distributing a cell
flow boundary with 50% of the flow in the top 1m and the remainder in the bottom 1m.
..\bc\InflowDistribution.CSV
10.4.5 BC Default
BC default can be used to control what value gets applied when TUFLOW FV reads a null-value from
a boundary condition input, or it cannot find the header that the modeller specified.
It is useful when the modeller recognises that a boundary condition needs a header in place but doesn’t
have a particular value to assign to it. An example is for a model that is reading a source term of sediment
into a model that is also modelling salinity and temperature. The simple source term of sediment in this
case is not adding any salt or heat to the model, but still requires an input of the header. It is
recommended that these headers are set to a name that is unlikely to be in the boundary condition file
by coincidence – this example uses the header ‘Dummy’. The header name ‘Dummy’ does not exist in
the boundary condition CSV file and the default values will be applied. This saves the modeller from
needing to add additional columns in the boundary condition file for variables that do not change.
This can be a useful feature but is also often a source of errors that can be hard to catch at times.
Modellers should always check the log file output to ensure that the correct headers have been found
and that the appropriate defaults have been applied if need be.
Whether a boundary condition type can be applied as a cell, nodestring, grid or globally is described in
the ‘BC Method’ column of Table 10-2 and Table 10-3.
All inflows from cell boundary conditions are applied as a source volume/mass input only and have no
direction or momentum added to them. By default, all cell boundaries are averaged over the full depth
of the water column, though this can be changed by specifying a vertical averaging type.
For advanced 3D models, some profile type boundaries are available, which are NetCDF files that can
specify the cell source/sink timeseries as changing with depth. These require a vertical coordinate type
and an additional variable within the NetCDF file of this vertical dimension.
Lastly, a special cell boundary condition, ‘CP boundaries’, exists. These specify a vertical profile of
scalar concentrations in a cell, but do not change with time (i.e. these are fixed constants for that cell).
These are commonly used for warming up a model using known profiles at specific points. By specifying
CP boundaries at multiple locations within a model and setting diffusion parameters to high (non-
physical) levels the internal diffusion parameterisation can then effectively interpolate between the fixed
CP points and be used to create a restart file.
Much like the cell-specified boundary conditions, simpler nodestring BCs can be specified using CSV
files while more complicated conditions are available using NetCDF files. CSVs are available for
conditions that either don’t vary along the length of the nodestring or vary constantly (by specifying
conditions at each end, with TUFLOW FV linearly interpolating between). When boundaries need to
vary non-linearly along the nodestring, or vary with depth, NetCDF files can be used.
Common pitfalls when specifying such boundaries are ensuring that the conditions are specfiied as the
user expects. Many nodestring boundary conditions have different sub-types available that affect the
distribution of flow both across the nodestring and with depth. Sub-type selection can also control
whether flow boundaries bring on the momentum or are treated more like a volume/mass source term.
Users must also make sure that the nodestring boundaries do not over-specify the conditions. This occurs
when any slight variances between the model internal conditions and the boundary conditions conflict
near the boundary and can cause instabilities or reflecting of energy from the boundary, affecting the
results. For ocean boundary conditions, sub-types are available to ‘relax’ some of the conditions to
minimise these issues.
Large grid NetCDF boundary conditions often need to cover the whole model domain. In these cases,
the user must keep in mind the extent of the relevant boundary condition grid (as specified by the grid
definition block and also refer Section 10.5.3.1). If the grid does not cover the whole domain, then the
areas outside of the grid’s extent will not be extrapolated but will be set to the default relevant value.
This can potentially cause issues for the model. In an MSLP_GRID boundary condition for example,
the cells outside of the grid will be set to the reference pressure. This may cause an air-pressure gradient
where the boundary condition grid ends, and consequently affect the water levels within the model.
Grid definitions are within a grid definition block which are typically used for NetCDF inputs as follows:
grid definition LABEL Name to apply to this grid and can be referred to by multiple
label boundary conditions later within the model build process.
Grid definition X_VARIABLE, This command specifies which variables should be read from the
variables Y_VARIABLE, NetCDF to create the grid map. If the inputs are only required on a
Z_VARIABLE. 2D grid (e.g. wind) then the Z_VARIABLE can be omitted.
cell gridmap {1} | 0 If set to 0, TUFLOW FV will not calculate the interpolation
weightings of the cells in the model for this gridded boundary
condition (may be more efficient for grids that are only going to be
applied to the boundaries and not internal model domain.
boundary 1 | {0} Set to 1 to calculate interpolation weightings from the grid onto the
gridmap boundary nodestrings (this is required for OBC_grid boundary
conditions that are to be later applied to nodestrings).
supress 1 or 0 If set to 1 suppresses warnings if the grid does not cover the entire
coverage Default == 0 TUFLOW FV domain. It may be more efficient in situations that the
warnings grid only needs to cover a small number of the cells in the model.
End Grid NA ‘Complete’ the grid block opened by the Grid Definition File
command.
The following .fvc example shows a typical grid definition file setup,in this example the NCEP Climate
Forecast System Reanalyses (CFSR).
This grid definition is then later used to assign gridded boundary conditions such as wind using a bc
block:
The following .fvc example shows a typical 3D grid definition file setup, in this example the HYCOM
Global Circulation Model.
This grid definition is then later used to assign gridded boundary conditions such as wind using a bc
block:
The boundary is specified as follows in the .fvc file. The input file Example_Holland_Cyclone.CSV is
also provided below.
Tutorial Module 4 on the TUFLOW FV Wiki provides an example model using the Holland tropical
cyclone model boundary input.
When using moving boundary conditions, users must take care with a few things:
• Currently the depth at which sources are released must be kept constant. This is based on the
vertical averaging commands in the boundary condition block (default over the whole water
column). If it is important to have boundaries moving in the vertical, users can use multiple
boundaries to achieve this. For more complicated cases, please contact [email protected].
• Interpolation between the specified timesteps can cause problems, these are described further in
Section 10.4.2
flow_distribution.csv
height weight
1 0
1.001 1
5 1
5.001 0
A similar approach can be adopted when using the QC, FC, QCM, FCM, QC_POLY, FC_POLY,
QC_GRID, FC_GRID boundary inputs.
The available curtain (_CURT) input boundaries are provided in Table 10-3.
boundary condition specification using a CSV file and compatible boundary condition type (for
example, Q, QC, WL should suffice.
The available profile (_PROF) input boundaries are provided in Table 10-3.
For 3D gridded NetCDF files, users must specify the grid geometry prior to specifying the boundary
condition. This is so that multiple boundary conditions on the same grid can use the same set of
interpolation calculations (see Section 10.5.3 for more information on gridded boundary conditions).
Typically, 3D gridded boundary files specify the full ocean boundary conditions (water level, current
velocity components and any requisite scalars such as salinity and temperature). An example is shown
below for a grid definition and a corresponding Ocean Boundary Condition (OBC) grid applied onto
two different nodestrings:
Furthermore, an option exists within TUFLOW FV to use the OBC_GRID boundary conditions to
specify initial conditions (initial condition OGCM, see initial conditions Section 10.7.2). Subsequent
initial conditions can be used to overwrite this for certain variables, such as for setting the initial currents
to zero via the initial condition quiescent to avoid initial shocks. The following example shows the usage
of this:
Note: if separately applying water levels boundaries via a 2d WL_CURT for use with the OBC_GRID,
for example to assign an astronomical tide boundary, then it’s common to use sub-type == 5 to apply
tidal heights as incremental to the existing water level anomaly applied via the OBC_GRID (refer
Section 10.6.1 for further information on sub-types).
1. SCALAR_GRID boundaries, that are similar to OBC_GRID boundaries but without the water
level and current velocity terms. These are used to specify just the scalars such as salinity,
temperature, sediments, etc.
2. QC_GRID boundaries, that specify an inflow of water (with associated concentration of scalars)
at each point of a 3D grid. These values are interpolated to the model’s cells that fall within the
grid domain. These can be used to specify complex flow inputs that may be the result of a
nearfield model (such as for taking the outputs of a nearfield diffuser model and applying these
to a far-field TUFLOW FV model).
3. FC_GRID boundaries, which are similar to QC_GRID boundaries, but only specify an inflow
of scalar mass, without an associated inflow of water. These are useful to specify complex source
terms of salinity, temperature, sediments, tracers or water quality constituents, also potentially
from nearfield models.
If you are interested in using these boundary conditions, please contact [email protected] and we
can assist with examples and setup.
The available gridded input boundaries are provided in Table 10-3.
4
Note that the header names listed here are defaults; if a “bc header ==” line is not included in the fvc file then these column header titles are
required. If however a “bc header ==” line is included in the fvc then the header descriptions then match the column header in the CSV file.
The complete list of default headers for the model configuration will also be printed in the log file.
2
The direction of the nodestring determines which is point A and which is point B. The order is the order of the nodes in the nodestring (the
direction that it was ‘clicked’ in sms, the order of the ‘external nodestring’ points or the order of nodes as listed at the end of the .2dm file.
5
Please refer to Section 1.3.3 for discussion on the ordering of scalar variables.
6
Note that the header names listed here are defaults; if a “bc header ==” line is not included in the fvc file then these column header titles are
required. If however a “bc header ==” line is included in the fvc then the header descriptions then match the column header in the CSV file.
7
Note: this boundary application can be used to specify a supercritical flow condition.
8
Note: u,v are cartesion velocity vectors (components in x and y directions).
9
Note: this boundary application can be used to specify a supercritical flow condition.
10
Note: u,v are Cartesian velocity vectors (components in x and y directions).
11
Note: x,y are Cartesian velocity vectors (components in x and y directions).
BC Sub- Details
Type type
1 Specified flow rate boundary with momentum terms. Uniform distribution.
Treated as a cell source term with a wall at the nodestring. Uniform distribution.
This sub-type may be specified to constrain scalar mass inflow into 3D models,
where sub-type 1/3 may allow simultaneous inflow and outflow at different
2 depths.
Q, HQ:
3 Specified flow rate boundary with momentum terms. H1.5 flow distribution
Treated as a cell source term with a wall at the nodestring. H1.5 flow distribution.
This sub-type may be specified to constrain scalar mass inflow into 3D models,
where sub-type 1/3 may allow simultaneous inflow and outflow at different
4 depths.
1 Tracer outflow defined by internal concentration
QC, QG:
2 Tracer outflow defined by BC concentration
(default) The flux calculation uses a new boundary calculation method added to
the 2019.01. This method should limit warning messages that could occur when
1 using QN boundaries: “Unable to solve for specified inflow conditions at bc.”
Pre-2019 TUFLOW FV Releases QN boundary flux calculation method and can
QN 2 be used for legacy simulations.
Correct ubot values based on discrepancies between wave model and TUFLOW
1 FV model depth (if available). Factor = 1/(COSH(MIN(kh/(h*h-depth)))),10)
2 Do not correct waves based on depth.
Calculate wave radiation stress gradients internally and correct for depth as in
3 subtype 1.
Calculate wave radiation stress gradients internally and do not correct for depth
Wave 4 as in subtype 2.
Water level is specified, velocity is calculated internally based on a radiation
1 condition.
Incoming wave height is specified and ghost cell properties are calculated by
2 superimposing outgoing wave form.
Velocity is specified, water level is calculated internally based on a radiation
3 condition.
Both water level and velocity are specified. Note that any changes between the
WL, OBC condition and the TUFLOW FV model may result in waves reflecting off
OBC 4 this boundary due to the overspecification.
Apply water levels as incremental. The change in water level is added to any
existing water level BC. This sub-type can be useful for including tidal forcing on
top of a previously specified OBC specifying the non-tidal water levels and/or
5 currents.
Water level is specified, velocity is specified but barotropically relaxed based on
the internal model conditions (by applying a barotropic Flather condition). This
sub-type will be preferred where boundary forcing is from an Ocean General
6 Circulation Model (e.g. HYCOM).
Initial conditions can be specified equally across the whole model domain, spatially varying, or using a
restart file from a previous model run.
• Initial water level: Sets the water level to a constant value globally. To minimise initial shocks
in the model this should be as close to possible as the initial timesteps of any water level
boundary conditions.
• Initial salinity: Sets the salinity to a constant value globally. As salinity changes slowly with
time, this can take a long period to ‘warm up’ if poorly specified.
• Initial temperature: Sets the temperature to a constant value globally, similar in use and
consideration to the initial salinity.
• Initial sediment concentration: sets the initial concentration for each sediment fraction.
• Initial tracer concentration: sets the initial concentration for each tracer. This can be used to
initialise areas for flushing studies.
• Initial WQ concentration: Sets the initial concentration for water quality constituents.
• Initial scalar profile; Allows the user to set initial scalar values globally but varying by depth.
This uses a CSV file to define this profile structure.
InitialProfile_000.CSV
• Initial condition quiescent; Sets the initial current velocity to zero globally. This is most
commonly used to overwrite other initial conditions (OGCM or restart files) to ease any shocks
due to initialising models with high currents.
• Initial condition OGCM; If an OBC_GRID boundary is present (refer Section 10.5.3), then the
values from this boundary condition are interpolated to all cells for the first timestep to use as
an initial condition.
Often the OGCM is used in combination with ‘initial condition quiescent’ to limit initial instabilities.
• Initial condition 2D; Can specify a CSV file with an initial condition for every 2D cell within
the model.
• Initial condition 3D; Similar to the initial condition 2D, but allows for specification of the initial
conditions for all 3D cells (noting 3D cells have different indices to the 2D cells, you can review
the IDX2 and IDX3 attributes of the mesh check file to review your model mesh indices).
Using a restart file as an initial condition is as simple as providing a path to an existing restart file:-
restart == log\PreviousRun_000.rst
This will automatically read the existing restart file, and any matching turbulence restart file (‘_turb.rst’,
automatically written by previous runs also, but not necessary to run further models). By default, this
will also adjust the starting time of the current run to the timestamp in the restart file/s. This can be
changed by using the use restart file time flag.
For users of sediment transport models, a bed mass restart file (‘_bed.rst’) will also be written by each
model run. This specifies the mass of each sediment class in each sediment layer of each cell. This file
is not automatically used by specifying a restart in the main control file (.fvc) but requires an additional
restart specification in the sediment control file.
restart == log\PreviousRun_000_bed.rst
The output interval must be small enough to capture any important variations in the hydrodynamics
within the area of interest (for example, tidal variation).
The resulting transport file (a NetCDF file with the suffix ‘_trans’) can then be inspected onto the
subsequent runs using a special BC type as follows:
It is important that all other boundary conditions that can affect the hydrodynamics (including salinity
and temperature BCs if using baroclinic coupling) must stay the same as the initial run that created the
transport file. Any conflicts between the transport file and the subsequent model runs using it can cause
inaccuracies and/or instabilities.
Transport files may improve runtimes for subsequent runs though improvements can often still be
limited by CFL timestep restrictions, particularly in wetting and drying areas. In order to overcome
these timestep restrictions the transport mode depth can be set to a value below which the transport flux
is limited (rather than the timestep) to avoid exceeding the CFL stability constraint. This numerical
treatment can lead to some loss of solution accuracy in shallow regions, however in practice these will
usually not be significant. An appropriate value for the transport mode depth limit would be between
the cell wet depth as a lower limit and 0.5-1.0m as an upper limit.
11 Hydraulic Structures
Chapter Contents
11.1 Introduction 11-2
11.2 Structure Types 11-3
11.2.1 Nodestring and Linked Nodestrings 11-4
11.2.2 Autoweir 11-5
11.2.3 Linked Zones 11-5
11.2.4 Cell or Zone 11-6
11.2.5 Defining a Nodestring, Linked Nodestring or Linked Zones Structure Block 11-7
11.2.6 Defining a Cell or Zone Structure Type 11-8
11.2.7 Structure Block Example 11-8
11.3 Flux Functions 11-10
11.3.1 Non-Linear Shallow Water Equations 11-10
11.3.2 Timeseries 11-11
11.3.3 Matrix 11-12
11.3.4 Weir Types 11-14
11.3.4.1 Fixed Weirs 11-14
11.3.4.2 Variable Height Weirs 11-15
11.3.5 Wall 11-16
11.3.6 Porous 11-16
11.3.7 Culvert 11-17
11.4 Energy Losses 11-21
11.4.1 Energy Loss Functions 11-21
11.4.2 Energy Loss Considerations 11-21
11.4.3 Form Loss Coefficient 11-22
11.4.4 Energy Table 11-22
11.5 Scalar Functions 11-24
11.6 Structure Controls 11-26
11.6.1 Control Block 11-26
11.6.2 Control Types 11-26
11.6.3 Control Parameters 11-26
11.6.4 Structure Logging File 11-27
11.6.5 Structure Control Examples 11-27
11.1 Introduction
TUFLOW FV includes a wide range of options for simulating hydraulic structures such as bridges,
culverts, weirs, pumps, water treatment devices etc. Structures can be static, be modified over time, or
respond according to flow behaviour at other locations in the model. The ability to modify selected cell
properties such as topography/bathymetry is also supported
Structures are defined using a structure block and require a unique structure block definition for each
structure within the model (autoweirs being the exception to this rule). When developing complex
models with many structures, include files are recommended to manage the data inputs and to keep
control files as succinct as possible.
To assist with review and visualisation of flow behaviour through the structures, users are encouraged
to use the structflux and structcheck outputs detailed in Section 12.8.
• Hydraulic structures applied as a flux term. These structures transfer fluxes from one cell to
another via a nodestring or a pair of linked nodestrings (refer Section 11.2.1);
• Globally specified as ‘auto weir’ nodestring structures (refer Section 11.2.2);
• Source/sink hydraulic structures that transfer and modify mass via a linked zone (refer Section
11.2.3); and
• Area property ‘structures’ that modify the hydraulic properties of a cell (refer Section 11.2.4).
The structure command is used to define the location of a structure and its type. Nested within a given
structure block, there are a wide range of options to modify, or replace the generic NLSWE. Each is
explored within subsequent sections of this chapter. The key command types nested within a structure
block include:
• Flux functions used to define weirs, culverts, bridges, porous breakwaters, walls and user-
specified flow relationships;
• Scalar functions to enable the user to modify scalar variables such as salinities, temperatures,
water quality variables or sediments; and
• Control blocks to allow a structure to modify its state over time, or in response to model
variables or events.
The distribution of flow (and other conserved variables) extracted from the ‘upstream’ side and input to
the ‘downstream’ side are weighted differently depending on the structure type, but generally weighted
according to the cross-sectional area of a cell face, the cell area the depth of water within a given cell.
This allows for some distribution of the flow in 2-dimensions but may remove any complex stratification
or vertical changes between the upstream and downstream. This is important to remember when
undertaking 3D modelling and using structure links.
1) Single Location (Nodestring): Defined using a single nodestring. Mass and momentum are
transported between neighbouring cells, regulated through the cell face by the flow controls
defined by the structure. This option is commonly used to model bridges, weirs and in some
cases culverts (depending on the model resolution). Upstream and downstream conditions are
inspected for each cell face, with a corresponding flow calculated. Exceptions to this rule are
when using the matrix, timeseries or culvert flux function(refer Section 11.3) and/or with use of
the energy loss method, cell width file or blockage file, all of which use cross sectional average
conditions. Momentum is transferred according to the flow and the upstream velocity. An
example nodestring structure is provided below:
2) Multiple Locations (Linked Nodestrings): Defined by two separate nodestrings. Mass and
momentum are transported between two locations in the model, regulated by the flow controls
defined by the structure. This option is commonly used to represent culverts within a model, or
structures that may be overtopped. Upstream and downstream conditions are averaged along
each nodestring, weighted by the face length and/or flow depth that each cell contributes. These
conditions are used to derive an overall flow through the structure which is distributed according
to cell face lengths. Momentum is transferred according to the flow and the upstream velocity.
An example linked nodestring structure is provided below:
11.2.2 Autoweir
The globally assigned Autoweir structure is a single nodestring structure type. This structure type
instructs TUFLOW FV to identify all cell faces in the model domain that are elevated above the adjacent
cell’s centroid elevations. These cell faces are then assigned a weir flow condition. This feature ensures
that critical floodplain hydraulic controls such as roads and perched riverbanks regulate floodplain flows
accurately. This command is recommended for catchment flood modelling. In combination with this
command, the geometry log files can be used to identify all locations within the model where this
function has been assigned.
NOTE: bathymetry at the faces can only be higher than the adjacent cells when bathymetry at the cell
nodes has been specified. This is usually achieved by specifying the bathymetry on the mesh file (.2dm),
or using the Read GRID Zpts command and not using a separate cell elevation file.
1) Single Cell (Cell): Topography and other property controls are applied to a single cell location
defined by a cell ID. This example raises cell ID 197 from -1m at the start of the simulation
(time=0) to 1m at time=1hr:
Time ZB
0 -1
1 1
3 1
2) Multiple Cells (Zone): Topography and other property controls are applied to any cells with cell
centroids within a polygon, as specified in a polygon file. The example below is analogous to
the cell example above, albeit applied across a group of cells IDs:
X Y ID
197.5 62.5 1
210.5 62.5 1
210.5 42.5 1
197.5 42.5 1
197.5 62.5 1
1. Decide on the most suitable structure type as mentioned in Section 11.2. If momentum transfer
is important, a nodestring type is likely required, if overtopping is possible then a linked
nodestring with an elevated topography in between may be more suitable. If a source/sink type
is appropriate that affects multiple cells, in a low momentum area, then a linked zones structure
may be the best approach.
2. Decide on the flux regime by setting the flux function within the structure block. Either based
on known parameterisations (culvert, weir) or based on the NLSWE with some additional
losses, using a width file and energy loss function for example. Or full specification using a
flow matrix developed already.
3. If modelling in 3D, decide on depth-averaging via the vertical coordinate type and vertical
distribution file commands. The flow can be sampled from the upstream and placed downstream
with different depth-averaging options. This is sometimes important for the representation of
currents downstream but is particularly important when using the advection dispersion module
for controlling where conserved tracers move.
4. Decide on any control needs (refer Section 11.6). The flow rate can be adjusted based on a
timeseries or based on sampling parts of the model and comparing it to some specified logic.
This can be useful when the real system has some operationalcontrol based on gauged data, such
as pumping when a lake falls below a certain level or triggering a gated culvert if upstream
temperatures exceed a limit.
5. Decide on scalar regime (if appropriate) using a scalar function. Scalars can either be adjusted
or conserved as they pass through the structure (refer Section 11.5).
1. Decide on the area property to apply. If updating the topography, then the bed adjust command
needs to be specified. Alternatively, if representing a ‘bubbler’ use the destratification unit
command.
2. Choose whether this area property should be completed on an individual cell or group of cells
using a zone via a polygon file.
3. If using the bed adjust command, select the appropriate control block commands to modify your
bed during the simulation. Alternately, if using the destratification unit select the required
properties for the ‘bubbler’ type.
The structure block begins on line 42 of the control file and is closed via the ‘end structure’ command
on line 64. This structure is defined to transfer flow at cell faces along a single nodestring, nodestring
number 13. The structure has been optionally given the name ‘st_pump’ to assist in locating model
results in any tabulated output data the model produces.
A flux function is defined on line 45 as a time series. For this setup, we are assigning the peak capacity
of the pump 200m3/s over the entire simulation. We will regulate this flow later via the control block.
For this structure we are not modifying any scalar variables via the scalar function command on line 49.
As ‘none’ is the default, this line could have been omitted.
To operate the structure, on line 52 a nested control block is opened using the sample rule approach.
The control block is closed on line 62 with an end control command. Within the nested control block
are a series of commands that increase or decrease the pump operation as a function of model water
level at a storm tide gauge downstream of the structure, its location defined by a sample point.
On line 54 and 55 we tell TUFLOW FV to return water level sample type at the sample point, that will
used as an input to determine the pump operation. On line 57 the ‘fraction_open’ control parameter
compares the water level at the sample point with a relationship specified within the control file
‘pump_rate.CSV’ as defined on line 60. The file ‘pump_rate.CSV’ determines whether the pump is
steady, it;s speed being increased or decreased (and thus flow rate being increased or decreased) as a
function of the water level at the sample point. For example, when the water level reaches 1m at the
storm tide gauge a fraction_open of 0.5 is returned via the sample rule, which will turn the pump onto
half capacity at 100 m3/s. This flowrate is then passed through the structure.
At the beginning of this model simulation, the pump is switched off via the start control state command
on line 59. Updating the operation of the structure is limited to a user defined time increment via the
control update dt, in this case every six minutes. While this is example is quite complex, the structure
block can be kept as simple as a few lines or optionally built up to complete more complex operations.
The possible combinations are explored throughout the chapter.
pump_rate.csv pump_capacity.csv
sample_value fraction_open time q
0 0 0 200
1 0.5 100 200
2 1
3 1
4 1
These are commonly combined with a combination of width (or blockage) file and energy loss functions
to simulate sub-grid scale effects (refer to Section 11.4 for detailed discussion on the use of energy loss
and width modifiers).
The below example shows a basic link between two nodestrings in different parts of the model domain.
11.3.2 Timeseries
The flow through the structure is specified in a separate timeseries CSV file. This method is commonly
used to simulated pumping structures with specified times and flow rates. A secondary command for
the flux file is required to specify the time and flow rate.
The following example showsa set of linked nodestrings with a specified flow rate between them.
example_polyfile.csv example_FluxFile.csv
X Y ID Comments Time Q comments
0 0 1 ! Polygon 1 0 0 ! No flow
10 0 1 ! Polygon 1 10 5 ! Positive flow
10 10 1 ! Polygon 1 12 5 ! Constant
0 10 1 ! Polygon 1 15 10 ! Ramping Up
900 0 2 ! Triangle 20 10 ! Constant
905 5 2 ! Triangle 30 0 ! No Flow
910 2 2 ! Triangle 50 -5 ! Reverse Flow
20 0 3 ! First in structure
25 1 3 ! First in structure
25 11 3 ! First in structure
20 10 3 ! First in structure
53 20 8 ! Second in structure
60 25 8 ! Second in structure
50 20 8 ! Second in structure
11.3.3 Matrix
The hQh structure option (Flux Function == Matrix combined with a Flux File) leaves the calculation
of flow through a structure to the user. This makes the hQh structure extremely flexible in its application
(any structure, be it weir, culvert, pipe, or an irregular structure etc... can be applied). However, the user
is required to define the hQh relationship to be used within the model.
Structure flow is determined from an “hQh” relationship; flow (Q) across the nodestring is determined
by the upstream water level (hus) and downstream water level (hds), as specified in a user defined matrix
of values (the hQh table). The following figure illustrates this (please refer to the Flux File command
description for formatting details of the hQh matrix CSV file).
1 Flows in the hQh table are distributed across the nodestring according to the relative widths of each
individual cell face (a cell face being the connecting line between two cells). Thus, each individual
cell face has a unique hQh table with Q values factored from the original hQh table according to
the cell face width.
2 During a model simulation step, at each cell face the upstream and downstream water levels are
used to obtain Q from the hQh matrix.
3 A check is performed between the tabulated flow (Qhqh) and that calculated using the Shallow Water
Equations (QSWE).
If the tabulated flow (Qhqh) is less than the Shallow Water Equations (QSWE) equivalent, it is applied.
Conversely, if the tabulated flow (Qhqh) is greater than the Shallow Water Equations (QSWE) value,
the Shallow Water Equations flow is used.
4 Momentum is actively transferred through the structure based on Qhqh and the upstream velocity.
A hQh relationship can be calculated either from first principles or using other modelling packages.
When deriving the hQh relationship, care must be taken to ensure that entry and exit losses are being
applied appropriately. Depending upon the layout of the structure in the mesh design, the hQh
relationship can represent all the losses that occur in a structure (macro and micro) or only internal
(micro) losses. This concept is described illustrated in Figure 11-4.
When manually specified, TUFLOW FV uses the standard weir equation (shown below), where the
coefficient C and crest level P are user inputs. TUFLOW automatically calculates the weir width b based
on the cell face across which the weir is being specified.
3⁄
2
𝑄 = 𝐶𝑏ℎ1
A variety of weir options are available (see flux function). These weir commands are applied at cell
faces within the model at specified nodestring locations. For all these options, using default values for
C provides an exact solution to the broad crested weir equation. Two fixed and variable weir flux
function options are available, summarised in Sections 11.3.4.1 and 11.3.4.2.
1) Weir: A weir structure with a fixed crest level. Used when absolute bathymetry and weir crest is
certain.
2) Weir_dz: A weir structure with a crest level (dz) above the existing cell elevation. Used when the
weir crest above the bed level is certain, but the bed level may differ between different scenarios.
Properties input are required both fixed weir options. Example inputs are shown below in Figure 11-6.
adjustableWeir1.csv
Time weir_crest comment
20 2.0 ! Prior to this its constant
22 1.5 ! Drops then constant
adjustableWeir2.csv
Time dz comment
0.0 9.7 ! Initial Level
2.0 9.2 ! Starts dropping
4.0 8.7
6.0 8.2
11.3.5 Wall
Wall type flux-functions block all flow through the structure. They are only available for nodestring
type structure types and do not work for linked nodestrings or linked zones. Wall type structures can be
used to block flow along cell edges where the model resolution would otherwise not allow the
bathymetry to do so.
11.3.6 Porous
Porous structures allow the user to control the flow between two areas based on Darcy’s law of flow
through porous media. It requires the user to specify the hydraulic conductivity and structure length
using the properties flag. This type of structure cannot be used for linked zone structures but is available
for nodestring and linked nodestring types.
𝑑𝐻
𝑄 = −𝐾𝐴
𝑑𝐿
Where K is the hydraulic conductivity (user specified), dL is the length of the structure (user specified),
A is the average cross-sectional area of the water column and dH is the difference between the upstream
and downstream water levels.
11.3.7 Culvert
Sub-grid sized culverts can be modelled as 1D structures. The standard structure equations which have
been used by TUFLOW Classic the late 1990’s have been included in TUFLOW FV12. The calculations
of culvert flow and losses are carried out using techniques from “Hydraulic Charts for the Selection of
Highway Culverts” and “Capacity Charts for the Hydraulic Design of Highway Culverts” together with
additional information provided in Henderson 1966. The calculations have been compared and shown
to be consistent with manufacturer's data provided by both “Rocla” and “Armco”. The equations allow
for a range of different flow regimes, as summarised in Figure 11-8, Figure 11-9 and Table 11-2
Table 11-2 1D Culvert Flow Regimes
Regime Description
C Unsubmerged entrance and exit. Critical flow at exit. Upstream controlled with the
flow control at the culvert outlet.
E Submerged entrance and unsubmerged exit. Full pipe flow. Upstream controlled
with the flow control at the culvert outlet.
L Submerged entrance and exit. Orifice flow at entrance. Upstream controlled with
the flow control at the inlet. Hydraulic jump along culvert.
12
For benchmarking of culvert flow to the literature, see Huxley (2004):
http://www.tuflow.com/Downloads/TUFLOW%20Validation%20and%20Testing,%20Huxley,%202004.pdf
HW HW
TW
TW
HW HW
TW
TW
HW
No Flow No Flow TW
Gate Closed
G: No Flow
Dry or Flap-Gate Closed
HW
HW
TW TW
HW HW
TW TW
HW HW
TW
TW
Culverts are defined using the Flux function command. In combination with the Flux function command,
culvert structure information is defined within the model via a culvert database (see Culvert file). The
culvert file contains a list of the culvert attributes, such as the culvert ID, culvert type, dimensions,
length, upstream and downstream inverts, number of barrels, Manning’s n, entrance and exit losses. A
description of the required culvert file inputs is summarised in Table 11-3
Multiple culverts can be listed within a culvert file (i.e. a unique culvert file for each culvert is not
required). The culvert ID within the culvert file is used to associate a specific structure with the
command line input. Example inputs are shown below in Figure 11-10.
Header
Description
Column
Form loss coefficient; an additional dynamic head loss coefficient applied when
Form_Loss
culvert flow is not critical at the inlet.
% blockage (for 10%, enter 10). For rectangular culverts, the culvert width is
pBlockage reduced by the % Blockage, while for circular culverts the pipe diameter is
reduced by the square root of the % Blockage. (Default = 0).
Recommended values, 0.6 for square edged entrances to 0.8 for rounded edges.
Height_Cont
Not used for unsubmerged inlet flow conditions or outlet controlled flow regimes.
Not used for C channels.
The width contraction coefficient for inlet-controlled flow. Usually 0.9 for sharp
edges to 1.0 for rounded edges for R culverts. Normally set to 1.0 for C culverts.
Width_Cont If value exceeds 1.0 or is less than or equal to zero, it is set to 1.0.
Not used for outlet controlled flow regimes.
Entry_Loss The entry loss coefficient for outlet controlled flow (recommended value of 0.5).
Exit_Loss The exit loss coefficient for outlet controlled flow (recommended value of 1.0).
1. Energy losses calculated by the model using a combination of user specified cell form loss
coefficient energy loss function and optional application of a width (or blockage) file (refer to
Section 11.4.3); or
2. A lookup table energy loss function of flows and pre-calculated energy losses (refer to Section
11.4.4).
• The 2D solution automatically predicts most “macro” losses due to the expansion and
contraction of water through a constriction, or round a bend, provided the resolution of the grid
is sufficiently fine. It is recommended that raised bridge approaches/abutments should be
represented by the model topography (i.e. not included as a contribution to the form loss
coefficient). A breakline using the Read GIS Z Line command may be useful for defining these
topographic features. Where the waterway width varies slightly from the cumulative width of
the cells across which the structure is being applied, a width file or blockage file can be used to
refine the flow area and define the structure soffit within the model13.
• Where the 2D model is not at a fine enough resolution to simulate the “micro” losses (e.g. from
bridge piers, vena contracta, losses in the vertical (3rd) dimension), additional form loss
coefficients and/or modifications to the cells widths and flow height need to be added. This can
be done by using a the form loss coefficient or energy file commands.
• The additional or “micro” losses, which may be derived from information in publications, such
as Hydraulics of Bridge Waterways, should be distributed evenly across the waterway (i.e.
rather than being too specific about the representation of each individual cell).
• The head loss across key structures should be reviewed, and if necessary, benchmarked against
other methods (e.g. Hydraulics of Bridge Waterways or a secondary model). Note that a well-
designed 2D model will be more accurate than a 1D model if any “micro” losses are
13
Width or blockage files are only applicable if used in combination with the form loss coefficient energy loss function.
incorporated. Ultimately, the best approach is to calibrate the structure through adjustment of
the additional “micro” losses – but this, of course, requires good calibration data!
𝑣2
∆𝐻 = 𝐹𝐿𝐶
2𝑔
Width files or blockage files can optionally be used in combination with the coefficient energy loss
function. They allow the user to specify the approximate width of the structure as a function of elevation,
for example to account for flow area reduction due to abutments, piers or other flow obstructions not
represented by the model mesh. These files alter the effective cross-sectional area at the structure,
modifying the velocity in accordance with the laws of continuity: v’ = Q/A’ where A’ is the modified
cross-sectional area of the structure and Q is the flowrate. This increased velocity v’ is used to assign
kinetic energy losses via FLC v’2/2g.
energyloss.csv
Q dH Comment
-10 0.1 ! Flow against structure direction
0 0 ! No head loss for no flow
1 0.1 ! Nlarger head losses for +ve flow
5 0.2
10 0.3
• None – scalar variables are unaffected by flow through the structure (the default).
• Timeseries – scalar concentrations through the structure are controlled by a separate CSV file
that specifies them as changing in time.
• Scale_factor – scalar concentrations are multiplied by a relevant scale factor from the
upstream to the downstream.
• Treatment – scalar concentrations are multiplied by a relevant scale factor from the upstream
to downstream. If scaling reduces concentrations to a specified lower threshold min_conc then
no more scaling is done. Similarly, if concentrations are already below this threshold, no
scaling is done at all. If a maximum concentration is specified via max_conc, then the
concentrations will be limited to this, regardless of the scale factor.
NOTE: when these structure types are used, the mass of scalar variables through the structures is not
conserved (i.e. this is typically the purpose of these structures, to add or remove mass from the model).
If reviewing the model MASS.CSV you may find that the overall mass in the model is increasing or
decreasing, and if this is the case it will likely be due to one of these structures. Care should be taken to
review the structcheck and/or structflux model outputs to ensure that the structure is operating as
intended.
Several examples of scalar functions are provided below for the ‘timeseries’, ‘scale factor’ and
‘treatment’ functions.
‘Timeseries’ flux function example applied at a linked zones structure type with no scalar function:
‘Timeseries’ flux function example applied at a linked zones structure type with a ‘timeseries’ scalar
function:
scalar_tseries.csv
Time Sal Temp SED_1 SED_2 Comment
0 15 25 1 0
20 15 25 1 0
40 15 25 1 0
48 15 25 1 0
48.001 20 25 5 0 ! Different scalars
60 20 25 5 0
80 20 25 5 0
‘Timeseries’ flux function example applied at a linked zones structure type with a ‘scale_factor’ scalar
function:
‘Timeseries’ flux function example applied at a linked zones structure type with a ‘treatment’ scalar
function:
Logic controls adjust flow conditions through a structure according to a series of logical rules specified
by the user. This is particularly useful for applications with adjustable structures, such as drop gates /
sluices / pumps or for levee breach/failure assessments.
Logic controls are specified in a control block nested within a structure block. Structures can have
multiple controls, with the contributions of these combined in different ways depending on the
controlled parameter.
• Trigger: Trigger controls define a condition that will commence after the first exceedance of
a specific trigger value within the model at a specified sample point. Currently TUFLOW FV
is only able to sample water levels for trigger controls.
• Timeseries: Timeseries controls define an adjusting condition based on a separate control file
CSV timeseries. The current timestep is interpolated into the timeseries to calculate a
corresponding control parameter value.
• Sample rule: A sample rule control can adjust the control parameter by sampling a variable
within the model and comparing it to a control file CSV file. Currently TUFLOW FV can
sample the following variables using the sample type command at a sample point at a time
interval specified by sample dt:
o H, V_x, V_y, SAL, TEMP, SED_1 – SED_N, TRACE_1 – TRACE_N, WQ_1 – WQ_N
• Target rule: A target rule control can adjust the control parameter to reach the target value of
the sample type at a sample point at a time interval specified by sample dt. The flow through
the structure is adjusted based on the difference between the sampled value and the target
value. The target value is specified in a target file, which is a timeseries to allow for time-
varying target conditions.
• Fraction_Open: Effectively a scale factor (between 0 and 1) of the flow rate through the
structure. Multiple fraction_open control parameter commands within the same structure will
multiply together for the overall value. Fraction_Open is often used to simulate culverts or
pumps with a gate control that is automated based on the water level elsewhere in the region.
Please note this control parameter is not supported with flux function== nlswe.
• Min_Flow: Provides a minimum flow rate that must pass through the structure (physical
limitations permitting). This is often used in conjunction with dam release structures where a
minimum flow is required for environmental releases. When multiple min_flow controls are
used in the same structure, the maximum of these will be the adopted value. Please note this
control parameter is not supported with flux function== nlswe.
• Weir_Crest: Used with weir_adjust or weir_dz_adjust flux functions (refer Section 11.3.4.2 )
and allows the crest height of the weir (absolute level or relative to the adjacent cells) to be
adjusted based on the control. Often used to simulate a lowerable or failing levee system
(please refer to Figure 11-7 for an example).
• ZB: Can only be used with cell or zone structure types using bed_adjust (refer Section 11.2.4)
and adjusts the bathymetry of the structure area based on a condition. Often used to artificially
adjust a model bed for scour with time, or to simulate a bund failure after a trigger condition.
• DZB: As per ZB above, but with all elevation changes relative to the existing bed level of the
structure region/cell.
BreachCondition.csv
Time Zb
0.0 24.0
2.0 23.0
4.0 22.0
6.0 21.0
8.0 20.0
10.0 19.0
sample_control.csv
Sample_Value Fraction_open
10.0 0.0
10.2 0.1
10.4 0.3
10.6 0.5
10.8 0.8
11.0 1.0
12.0 0.8
13.0 0.5
Flow across a nodestring regulated by the surface salinity in a part of the model (no flow if salinity>20
ppt).
example_sample.csv
Sample_Value Fraction_Open
0 1
20 1
20.01 0
12 Model Outputs
Chapter Contents
12.1 Introduction 12-2
12.2 Output Formats 12-3
12.3 Point Output 12-4
12.4 Profile Output 12-5
12.5 Flux/Mass Output 12-6
12.6 Map Output 12-8
12.6.1 Overview 12-8
12.6.2 2D Only Map Output Formats 12-8
12.6.3 3D Map Outputs 12-9
3D Vertical Averaging Options 12-9
12.6.4 2D and 3D NETCDF Format 12-10
12.6.5 Map Output Statistics 12-15
12.7 Map Output Parameters 12-16
12.8 Structure Outputs 12-23
12.8.1 Structure Flux 12-23
12.8.2 Structure Check 12-23
12.9 Check Files and GIS Layers 12-25
12.9.1 GIS Workspaces (.wor and .qgs files) 12-25
12.10 GIS Check Files 12-26
12.1 Introduction
TUFLOW FV outputs cross-check information and calculation results in a range of different file formats
for use within a wide choice of text, plotting, GIS and GUI visualisation tools and software.
This chapter discusses options to configure and customise TUFLOW FV’s output prior to carrying out
a simulation.
• Mapped output in SMS Data File (2D or vertically averaged 3D, DATV or XMDF) or NetCDF
(2D, vertically averaged 3D or full 3D) formats
• Mapped statistical output in SMS Data File (2D or vertically averaged 3D) or NetCDF (2D,
vertically averaged 3D or full 3D) formats
• Vertical profile time-series output at point locations in NetCDF format (full 3D)
The types of output will typically depend on the TUFLOW FV hydrodynamic calculation mode (2D or
3D), the available model calibration/validation data, the objectives of the modelling exercise and the
modeller’s preferred method of communicating assessment results.
14
Parameters are referred to as Map Output Data Types if you’re a TUFLOW Classic of HPC User.
The TUFLOW FV 2D points output file is a comma separated variable format (*_POINTS.CSV) that
can be opened and viewed in a text editor or spreadsheet software such as Microsoft Excel. The file
contains the time-series of model parameters at the point locations defined in the output points file.
Following the example in Figure 12-1, a sample of the corresponding *_POINTS.CSV output file is
shown in Figure 12-2.
An example profile output is shown in Figure 12-4 whereby salinity at a point location is plotted as a
function of depth for a given timestep. Results are saved to a location defined via the output dir
command.
The values of each parameter in the mass and flux files are made up of the concentrations of each scalar
conserved variable multiplied by the volume of water or the flow rate respectively. These units are not
always immediately intuitive (for example the heat ‘mass’) but if divided by either the flow rate or
volume (for flux terms and mass terms respectively) they will be equivalent to the average concentration
of the parameter that is either passing through a given nodestring, or within the whole domain. These
files can be used to ensure that no instabilities are causing spurious changes in conserved quantities, that
source/sink terms are operating as expected and that external boundaries (such as an offshore ocean
boundary) are not influencing the conserved mass of parameters.
• The simulation ‘mass’ file output is used to check the volume of fluid and, where applicable,
other simulated quantities within the model domain. The command to output the mass file is
simply:
• The simulation flux file used to check the rates of fluid and, where applicable, other simulated
quantities entering/exiting the model boundaries or crossing specified nodestrings within the
model domain. A separate set of time-series is provided for each nodestring in the model
domain. The command to output the flux file is simply:
In builds 2019.01 and later, TUFLOW FV produces a SMS Super File’ (.sup) that links the model mesh
and result outputs, allowing the user to open a single .sup file to view all model parameters at once from
a given run.
If using DATV output a separate output file is created for each specified model parameter (e.g. *_H.dat,
*_V.dat, *_ZB.dat). The Super file will have the name <fvcfilename>.ALL.sup.
If using XMDF, a single output file with .xmdf extension is produced that contains all output parameters.
XMDF also allows file compression, which may be useful if dealing with large models and needing to
reduce the storage footprint of your model results. The Super file produced will have the file name
<fvcfilename>.xmdf.sup. Results are saved to a location defined via the output dir command.
Example datv and xmdf output block commands and are provided in Figure 12-5.
The screenshot in Figure 12-6 provides an example of TUFLOW FV ‘datv’ output opened in the SMS
Generic Mesh Module environment.
Figure 12-6 TUFLOW FV Mapped Current Velocity Output in the SMS Generic Mesh
Module Environment
Various post-processing tasks can be undertaken using SMS, including data extraction and creating
animations. The TUFLOW FV Wiki and Aquaveo SMS website provide post-processing examples and
tips:
• Time-series at a point location (or multiple point locations) defined in an output points file;
• depth-range – averaging between specified minimum and maximum absolute depths measured
downward from water surface
• height-range – averaging between specified minimum and maximum absolute heights measured
upward from the bed
• sigma-range – averaging between specified decimal fraction of the water column where 0 is the
bed and 1 is the water surface
• layer-range-top – averaging between layers referenced from the water surface (i.e. surface layer
is 1, positive downwards)
• layer-range-bot – averaging between layers referenced from the bed (i.e. bottom layer is 1,
positive upwards)
The depth-all option simply averages the 3D output over the entire water column, giving 2D depth
averaged output based on the 3D calculations. The other options allow the modeller to specify a range
of the water column to vertically average over. Examples of each depth averaging command are
described further in the Vertical averaging command section or the TUFLOW FV Wiki.
• The suffix command is often used with the Vertical averaging command to add a clear identifier
to the output filename.
• Multiple vertical averaging outputs are supported but must be added to separate output block
commands for each vertical averaging specification.
TUFLOW FV NetCDF output adopts the NetCDF-4/HDF5 format. The output file is self-describing
and contains information regarding the model geometry (2D or 3D) together with the mapped output at
the specified time interval. The NetCDF format offers the following advantages:
• The files are machine-independent and can be viewed using any numerical analysis package
with a NetCDF library interface, including MATLAB, R, GNU Octave or Python NumPy;
MATLAB or Python is typically used to view TUFLOW FV NetCDF output, extract data and generate
animations. Some commonly used post-processing functions include:
• Sheet plots of vertically averaged, cell-centred model output (example in Figure 12-7);
• Curtain plots (longitudinal or cross-sectional) showing the vertical distribution of model output
(examples in Figure 12-8 and Figure 12-9); and
• Conversion of TUFLOW FV NetCDF output to vertically averaged SMS Data File Format.
Both MATLAB and Python TUFLOW FV specific visualisation toolboxes are available to assist with
the handling of 3D datasets.
The dimensions, variable definitions and attributes of a TUFLOW FV NetCDF output file are provided
in Appendix DAppendix C. This information is intended to assist advanced users wishing to develop
functions and scripts to post-process and/or view TUFLOW FV NetCDF output.
Figure 12-7 TUFLOW FV Sheet Plot with Zoom Example: Velocity Magnitude Top 50%
Water Column (top); Velocity Magnitude Bottom 50% Water Column (bottom)
Salinity (ppt)
35
31.5
2 28
24.5
0
Elevation (m MSL)
21
-2
17.5
-4
14
-6
10.5
-8 7
0 2000 4000 6000 8000 10000 12000
Chainage (m)
3.5
22-Jan-2012 13:00
Salinity (ppt)
35
31.5
28
24.5
21
Elevation (m MSL)
2 3.26
0 3.25 17.5
-2
-4 3.24
-6 Easting (m) 14
-8 3.23 5
x 10
3.22 10.5
5.813
5.8125 3.21
7
5.812 3.2
Northing (m) 5.8115
6 3.19
x 10 5.811 3.5
5.8105 3.18
0
Figure 12-8 TUFLOW FV Salinity Vertical Distribution: Model Mesh and Curtain
Polyline (top); Salinity Curtain Plotted with Polyline Chainage; Salinity Curtain Plotted
with Polyline Coordinates (bottom)
1
2
10 6
0
Elevation (mAHD)
4
-5
3
-10
2
-15
-20 1
Radial Flow Vector
-25 0
0 50 100 150 200
Chainage (m)
10 6
0
Elevation (mAHD)
4
-5
3
-10
2
-15
-20 1
Radial Flow Vector
-25 0
0 50 100 150 200
Chainage (m)
10 6
5
Total Velocity Magnitude (m/s)
0
Elevation (mAHD)
4
-5
3
-10
2
-15
-20 1
Radial Flow Vector
-25 0
0 50 100 150 200
Chainage (m)
Figure 12-9 TUFLOW FV Velocity Vertical Distribution: River Bend Flood Flow and
Cross-Section Locations (top); Total Velocity Magnitude (contours) with Radial Flow
Vectors Cross-Sections (bottom three)
Example use of the output statistics command within an output block is provided in Figure 12-10. The
‘output statistics dt’ must be specified in addition to the ‘output interval’. In the example below, DATV
output files would be created at 900 second intervals with the maximum tracked at a 1 second interval.
Output
Description
Parameter
Output
Description
Parameter
Output
Description
Parameter
Output
Description
Parameter
floodplains-part2-full.pdf (Queensland Reconstruction Authority,
2011-2012).
Output
Description
Parameter
• TURBZ_SPFSQ (/s2)
• TURBZ_BVFSQ (/s2)
• TURBZ_NUM (m2/s)
• TURBZ_NUH (m2/s)
• TURBZ_NUS (m2/s)
Hydraulics
Morphological
Suspended sediment
If users wish to further investigate the difference between upstream and downstream conditions going
through the structure (for example when using the aforementioned scalar functions) then a ‘structcheck’
file can be used (refer to Section 12.8.212.8.2). An example of the first few lines of a ‘structflux’ file
for a simulation with two tracers (but no other conserved scalar variables) is shown below.
The output file has the suffix _STRUCTFLUX.CSV and is located in the folder set by the output dir
command. An .fvc snippet for this output is provided as follows:
An example of the first few lines of a ‘structcheck’ file for a simulation with two tracers (but no other
conserved scalar variables) is shown below:
The output file has the suffix _STRUCTCHECK.CSV and is located in the folder set by the the output
dir command. An .fvc snippet for this output type is provided as follows:
• The simulation .log file which is automatically generated at the beginning of (and continuously
written to during) a TUFLOW FV simulation.
• The simulation timestep files which contain the minimum and mean timestep required for
calculation of the external (free-surface) and internal (advective) terms within each model cell
are automatically written at the end of a TULFOW FV simulation (refer echo geometry). This
information can be used to identify model cell(s) constraining the simulation timestep. A model
‘timestep review’ example is provided on the TUFLOW FV Wiki:
http://fvwiki.tuflow.com/index.php?title=A_Model_Runs_Slow
The .wor file when opened in MapInfo simply opens the .tab layers. No Map or Browser windows are
automatically opened. If the simulated model contains any .shp files, these are not opened, however the
.shp file layers used by TUFLOW can be viewed when opening the .wor file in a text editor.
Opening the .qgs file in QGIS will open all GIS input and output check layers (.mif and/or .shp). Note
that the visibilities of the output layers are unchecked so that the display time is quick.
For ArcMap users, the .mxd files are not directly written by TUFLOW. The format is proprietary and
can’t be directly written. However, the ArcTUFLOW toolbox can be used to load the simulation input
files into ArcMap.
Filename prefix /
Description
suffix
GIS layer of the final 2D or 3D mesh. Represents the final mesh including
modifications from the .fvc file, such as ZB updates.
_mesh_check_R.shp
Please note reported ZB values do not include ZB modifications due to
morphological changes when morphology is enabled. Model material, ZB,
bed roughness and cell 2D and 3D ID are reported.
Shows the cell faces selected, the direction and ID of nodestrings. This
_ns_check_L.shp
includes both nodestrings assigned directly to the .2dm or by external
nodestrings.
GIS layer containing Zpts (ZB values at cell centroids) that have been
modified by Read GIS Z Line == commands, the type of Z Line and the Z
_zln_zpt_check_P.shp
Line filename. This feature is very useful for checking which Zpts that the Z
Lines have modified.
If using QC or other cell based input boundaries returns the cell centroid of
_sa_check_P.shp
each cell selected by the boundary.
GIS layer containing full file paths to all input layers used to compile the
_input_layers.mif
model.
This command can be used to specify the bottom drag model to be used in the simulation.
The default model is Manning, in which case a Manning’s ’n’ coefficient(s) should be specified using
the global bottom roughness or material bottom roughness command.
An alternative model assumes a log-law velocity profile and requires specification of a surface
roughness length-scale, in which case ‘ks’ values should be specified using the global bottom
roughness or material bottom roughness command.
An optional command to set the threshold water depth for 3D calculations. In areas where the depth is
less than the threshold value vertical fluxes between layers are reduced to a 2D solution. Note this
doesn’t speed up model run times but can reduce potential instability in cells with shallow depths.
Cell wet/dry depth == <cell dry depth (m), cell wet depth(m)>
(Optional; Default == 1.0e-6, 1.0e-2)
• The drying value corresponds to a minimum depth below which the cell is dropped from
computations (subject to the status of surrounding cells). If set to zero or a negative value the
drying is set to zero.
• The wet value corresponds to a minimum depth below which cell momentum is set to zero in
order to avoid unphysical velocities at very low depths. If less or equal to the drying depth the
value is set to the drying depth.
This command is provided for legacy models. The recommended alternative is Read GIS Z Line.
This optional command can be used to set the bed elevations for some or all cells in the model domain,
overriding the elevations defined by the .2dm file.
If xytype = coordinate:
• the cell elevation will correspond to the last z value read (i.e. overwrite the elevations defined
by the .2dm file).
If ztype = average:
• the elevation will be the average of the z values read for a given cell (i.e. the average elevation
defined by the .2dm file and read from the cell elevation file).
Note that more than one cell elevation file can be listed in the simulation control file (.fvc). Please
refer to Section 8.3.4 for more details. See also Read GIS Z Line.
This optional command reads a polygon defined in a comma separated variable file. All cell centres
that lie within the polygon are assigned an elevation ZB, overriding the corresponding elevations
defined by the .2dm and/or cell elevation file.
Polygon file:
• The .CSV file contains a first line header:
o X,Y,ID (ID is optional)
o Input data is entered within the rows below the column header.
o Points within the CSV file define the perimeter of the polygon. The definition of
points needs to be consecutively listed and can be either clockwise or counter-
clockwise.
ZB:
• The elevation that all cells within the polygon will be assigned.
ID:
• Only those vertices listed in the .CSV file with an ID value matching the specified value in the
command line will be read by the model.
o note: If ID = 0 or is blank, all vertices will be read from the polygon file
This optional command will set bed elevations for cells that are intersected by a polyline. Cell Z
values will be interpolated from the z values specified at vertices along the polyline, overriding the
corresponding elevations defined by the .2dm and/or cell elevation file.
Polyline file:
• The .CSV file contains a first line header:
o X,Y,Z,ID
ID:
• Only those vertices listed in the .CSV file with an ID value matching the specified value in the
command line will be read by the model.
o note: If ID = 0 or is blank, all vertices will be read from the polyline file
Sets the Courant–Friedrichs–Lewy (CFL) condition used for the calculation of both the internal
(advective) and external (free-surface) terms.
The default value is 1, which is the theoretical stability limit. In practise this value is commonly
lowered to provide additional stability for models that exhibit large gradients in flow, density or
constituent concentrations such as the assessment of Tsunami, dam break or lakes with strong vertical
stratification. Also see CFL external and CFL internal.
Specifies the value of a constant timestep that is to be used during the simulation.
If the command is not entered then a variable timestep is applied according to the CFL stability
criterion, see CFL and Timestep Limits). Due to variable time-stepping using the TUFLOW FV
explicit scheme the use of a constant timestep is not typically recommended.
Using this option will ignore Timestep Limits, CFL, CFL Internal and CFL External commands.
Allows the user to specify the simulation time interval (in seconds) for displaying timestep
information to the log and terminal window.
Setting this to 0 stops the model from writing a series of comma separated variable files and NetCDF
ouput that include various relevant geometry and spatial features of the simulation, including:
• Mesh details
• Cell elevations and material types
• Cell elevations that have been updated externally to the .2dm file (for example by using the cell
elevation file command)
• Nodestring locations and their purposes (boundary, structure, etc.)
• Output locations
See also echo geometry CSV and echo geometry NetCDF.
Setting this to 0 stops the model from writing a series of comma separated variable files that include
various relevant geometry and spatial features of the simulation, including:
• Mesh details
• Cell elevations and material types
• Cell elevations that have been updated externally to the .2dm file (for example by using the cell
elevation file command)
• Nodestring locations and their purposes (boundary, structure, etc.)
• Output locations
See also echo geometry and echo geometry NetCDF.
Setting this to 0 stops the model from writing a *_geo.nc (NetCDF format geometry) check file.
• For Time Format == ISODate, inputs are in date form dd/mm/yyyy HH:MM:SS (or some
truncation thereof).
Optional command to specify the directory for external turbulence model definition files if an external
vertical mixing model is used. If not specified, external turbulence model files must be in the same
directory at the simulation control file.
Gravitational acceleration. If not specified, then the default value depends on the specified units:
• 9.81 m/s2
• 32.174 ft/s2
Specifies the model 2D geometry input file. The input file must be in a format consistent with the
SMS generic mesh module format (see Section 8.1.2).
When following the suggested TUFLOW FV folder structure (refer Section 4.2.1):
geometry 2d == ..\model\geo\mesh_name.2dm
Specifies the output format for GIS check layers and GIS outputs. If the command GIS Format is not
specified, the GIS format used for check layers and other GIS outputs is based on whether MI Projection
or SHP Projection has been specified. If neither or both commands have been specified, and GIS Format
has not been specified, the default of using .mif files is adopted.
Note that the format of an input layer is solely controlled by the file extension (i.e. .mif for the
MIF format and .shp for the SHP format).
Provides option to apply limits to the bed elevations. Can also be applied to specific material types
(see Bed Elevation Limits).
Globally sets a constant horizontal eddy viscosity (m2/s) or the horizontal eddy viscosity coefficient.
This is dependent on the momentum mixing model set using the momentum mixing model command:
For use with Smagorinsky momentum mixing model, globally sets the minimum and maximum
horizontal eddy viscosity (m2/s) limits.
Not applicable if a Constant horizontal eddy viscosity is set using the global horizontal eddy viscosity
command. For further information please refer to Section 7.2.
This command can be used to apply a reduction factor to high-order cell reconstruction gradients,
which may be useful in stabilising a 2nd order simulations. This has no effect on when running in first
order (refer Spatial Order).
Default is <1.0, 1.0, 1.0>, which corresponds to no gradient reduction, whereas <0.0, 0.0, 0.0> would
revert to a first-order scheme.
This may be implemented to solve for water level and velocity in 1st order whilst solving
plume/constituents in 2nd order as they may exhibit high spatial gradients (or vice-versa) This is useful
if 2nd order hydrodynamics are not required. For example, Horizontal AlphaR == 0.0,0.0, 1.0
Sets the Total Variation Diminishing (TVD) limiting scheme for 2nd order horizontal spatial
integration scheme, the options are:
• LCD is the less compressive option and the least computationally intensive.
• MLG is the most compressive option and the most computationally intensive.
At any location in the simulation control file (.fvc) an ‘include file’ can be used. Commands contained
in the include file will be read as if they are listed in the .fvc file. Provides the same functionality as the
Read File command.
Optional command used to switch off bed friction and thereby simulate an ‘ideal’ fluid:
Optional command used to switch off the Coriolis force source term from the momentum conservation
equations:
An optional command used to remove the wind stress terms from the momentum and mass transport
equations (only relevant if wind is a specified input using the BC command):
Optional command to read the initial conditions from a comma separated variable file. The .CSV file
contains initial conditions for each cell of the mesh.
ID, WL, U, V
Optional command to read the initial conditions from a comma separated variable file. The .CSV file
contains initial conditions for each cell of the mesh.
ID, WL, U, V
If salinity, temperature or other scalars are included in the simulation they should also be specified in
the .CSV file (e.g. Sal, Temp, Scal_1,…). An example of the command usage and corresponding .CSV
file is given below:
Ocean General Circulation Model. Derives initial water level, currents, salinity and temperature from
an input NETCDF grid. This is commonly used in combination with the OBC boundary curtain type to
apply global ocean model conditions to a local mesh, for example HYCOM.
Sets the latitude for Coriolis calculations when a Cartesian coordinate system is used. If Coriolis
forcing is important for your study, care should be taken to set a representative latitude, or preferably
use Spherical == 1. Note that the equator is used as the default latitude.
Specifies the location and name of the comma separated variable file containing the 3D layer face
information, depending on the Vertical Mesh Type:
• In the case of Sigma-coordinates, the layer faces are optionally specified as decimal fractions
between 1 (water surface) and 0 (bed level) in a ‘SIGMA’ column. The file must be
monotonically decreasing from the surface (1) to the bed (0). Also, values are required to be
between (and not include) the values 0 or 1 otherwise an error code will be produced. This
command is used if a non-uniform vertical distribution of sigma layers is desired.
• In the case of Z-coordinates, fixed layer face elevations are specified in a ‘Z’ column.
In tidal environments, the user may wish to adopt a hybrid z-sigma-coordinate mesh. In this instance,
the Z-coordinate Vertical Mesh Type is set and “always wet” fixed layer face elevations are specified in
a ‘Z’ column. The number of sigma layers between the maximum “always wet” elevation and the free-
surface is then specified using the surface sigma layers command.
This command specifies the directory for TUFLOW FV simulation log file (.log) output. A log file is
automatically generated for each simulation, the contents of which are the same as that displayed in
the simulation window. The log filename has the same prefix as the simulation control file.
If not specified, the log file will be written to either the same location at the simulation control file or
to the input\log sub-directory if this has been first created by the user (see suggested sub-folder
structure in Section 4.2).
Other check files (*geo.nc, *cfl_dt.CSV) and restart files (if specified) are also written to the specified
log directory location.
Sets the geographic projection for all GIS input and output in MID/MIF format. If this command is
omitted, TUFLOW FV searches for a file “Header.mif” in each folder it opens GIS files, and extracts
the projection from this file. The “Header.mif” file is any GIS layer in the correct projection exported
in MID/MIF format. If no “Header.mif” file is found, non-earth coordinates are assumed.
Alternatively, a projection line extracted from a mif file may be entered (although the previously
described approach of specifying a MIF file is the recommended approach). Follow these steps:
1. In a GIS, create or open a layer in the Cartesian projection to be used for the model. For non-
geographic models (e.g. a test model), use the Non-Earth (metres) projection.
2. Export the layer in MIF/MID format.
3. Open the .mif file in a text editor, copy the whole line starting with “CoordSys” (usually the 4th
or 5th line) and paste after “MI Projection ==” in the .fvc file.
Examples:
MI Projection == ..\model\mi\Model_Projection.mif
MI Projection == CoordSys Earth Projection 8, 13, "m", 153, 0, 0.9996, 500000,
10000000 Bounds (-7745874.38492, 1999.40969607) (8745874.38492, 19998000.5903)
Note: If using GIS Integration All MID/MIF GIS layers read by TUFLOW FV MUST USE this
projection. The projection must be a Cartesian based projection and in metres if using Spherical
== 0. If using Spherical == 1 the coordinate system needs to be spherical such as
Latitude/Longitude.
Further examples of creating a projection file using various software packages can be found on the
TUFLOW Wiki.
See also the corresponding command SHP Projection, for GIS input and output files in .shp format. If
a model has a mixture of .mif and .shp files as input, then both MI Projection and SHP Projection should
Optionally specify the minimum thickness of the lowest layer (i.e. layer at the bed). This command is
used to avoid a thin vertical layer (and associated small timestep) at the bed.
TUFLOW FV uses a mode-splitting approach to efficiently solve the external (free-surface) mode in 2D
at a timestep constrained by the surface wave speed while the internal 3D mode is updated less
frequently. This command is used to disable mode-splitting:
Sets the horizontal eddy viscosity calculation method. See also global horizontal eddy viscosity.
• Constant: specify a constant eddy viscosity using the global horizontal eddy viscosity
command.
• Smagorinsky: the horizontal eddy viscosity is calculated according to the Smagorinsky model
- specify the Smagorinsky coefficient using the global horizontal eddy viscosity command.
Specifies a comma separated variable file that contains the vertex coordinates of a polyline defining a
nodestring path.
The nodestring path is identified by (1) finding the nearest node to each vertex and (2) identifying
internal nodes between them.
Polygon file:
• The .CSV file contains a first line header:
o X,Y,Z,ID (Z, ID are optional)
o Input data is entered within the rows below the column header
o Z inputs will assign elevations to the vertices along the nodestring. This will not
influence cell elevations (use the cell elevation polyline for this task), but can be used
to assign elevations for nodestring structures.
ID:
• If an ID column exists, only those vertices listed in the .CSV file with an ID value matching the
specified value in the command line will be read by the model.
o note that if ID = 0 or is blank, all vertices will be read from the polyline file.
Command to specify the location where simulation output files are to be written. The first example
below specifies the output directory assuming the TUFLOW FV sub-folder structure recommended in
Section 4.2.
Alternatively, the user may wish the output directory to be located on a local drive, for example:
output dir == D:\project12345\tuflowfv\output
Output is written to the same location at the simulation control file (.fvc) if this command is not used.
From Windows build 2019.01 TUFLOW FV will attempt to automatically create the output directory
if it doesn’t exist.
At any location in the simulation control file (.fvc) a ‘read file’ can be used. Commands contained in
the read file will be read as if they are listed in the .fvc file. Provides the same functionality as the Include
command.
Reads .mif/.mid or .shp formatted files containing polylines that are treated as breaklines in the model’s
bathymetry. The breakline can vary in height along its length (i.e. a 3D breakline).
This is a powerful feature for quickly and easily entering a breakline feature such as a road, railway,
levee, creek, drain, etc. It is particularly useful where TUFLOW FV cell discretisation does not
guarantee that the crest along, for example, a road, is picked up from the DTM, or the lowest point along
a drain. It saves having to incorporate roads, levees, etc. into the DTM.
The modified Zpts are output to the 2d_zln_zpt_check layer (see Section 12.10) if Write Check Files
has been set.
A variable height polyline is created in the GIS by snapping the polyline to points in the same layer.
The first attribute column must be a number (real or integer) representing the elevation of the points.
Other attributes are ignored. If the polyline is not snapped with a point at its beginning and end, the
polyline is assumed to be horizontal (the height is taken from the polyline’s attribute). Otherwise, the
polyline’s grade is determined by the height of the points snapped to the polyline nodes. It is not
necessary to snap a point at every polyline node – the minimum requirement is a point snapped to each
polyline end.
Directly interrogates an ESRI ASCII (.asc) or binary (.flt) grid to set the cell centroid elevations.
The use of this command has significant advantages over the previous method of manually carrying out
a manual cell inspection with the Cell Elevation File command.
Optionally sets the reference mean sea level pressure value. Please refer to Section 7.3 for further
information on reference values.
Optional command to load the simulation initial conditions from a restart file (.rst) generated by a
previous TUFLOW FV simulation.
Unless the use restart file time command is used the simulation start time will be set to the timestamp
in the restart file. See also write restart command.
Option to overwrite the restart file at the time interval specified using the write restart dt command
(default) or create a series of restart files for each timestep:
• 0 = False (i.e. the restart file will not be overwritten, and a series of restart files will be
generated).
This command is similar to the MI Projection command that sets the .shp file projection for checking
whether input layers are in the same projection, and for setting the projection of all output layers (e.g.
check layers).
Example:
SHP Projection == ..\model\shp\Projection.prj
If a model has a mixture of .mif and .shp files as input, then both MI Projection and SHP Projection
should be specified.
Specifies the spatial order of accuracy of the solution schemes used in the simulation:
The first-order schemes assume a piecewise constant value of the modelled variables in each cell,
whereas the second-order schemes perform a linear reconstruction.
Higher order spatial schemes will produce more accurate results in the vicinity of sharp gradients;
however, they will be more prone to developing instabilities and are more computationally expensive.
Generally, initial model development should be undertaken using low-order schemes, with higher-order
spatial schemes tested during the latter stages of development. If a significant difference is observed
between low-order and high-order results then the high-order solution is probably necessary, or
alternatively further mesh refinement is required.
Second order spatial accuracy will typically be required in the vertical direction when trying to resolve
sharp stratification.
When running in second order the Horizontal AlphaR and Vertical AlphaR horizontal and vertical
gradient reduction factor commands may be of use for regions of high spatial gradients or to assist with
improving model stability.
Spherical == <0;1>
(Optional; Default == 0)
• 0 = Cartesian where geometry inputs and computational coordinates are in metres / feet.
Note: If Coriolis forcing is likely to be important than Spherical coordinates are recommended.
However, if Cartesian coordinates are required then please take care that a representative Latitude is
set as the default is 0 (the equator).
Optional command to specify a maximum water level and maximum velocity which indicate an
unstable model. The simulation will stop if these limits are exceeded. For example, <max cell ZB
value plus 10m, 10m/s>.
• For Time Format == ISODate, inputs are in date form dd/mm/yyyy HH:MM:SS.
Setting this to 1 will write a structural log file (.slf) that contains the operational behaviour of included
structures through time.
Depending on the Vertical Mesh Type, this command is optionally used to:
Subsequent simulation time commands and simulation inputs must be in the specified time format.
Simulation outputs will be in the specified time format.
Specifies the maximum and minimum variable timestep allowed according to the CFL stability
criterion. See also CFL.
Transport inputs can be disabled for shallow cells to limit instabilities by using the transport mode
depth. This can be useful for areas where wetting and drying are leading to issues with application of
the transport boundary. Refer Section 10.8
Optional command to specify the timestep for updating the vertical turbulence mixing eddy-viscosity
and scalar-diffusivity terms. If not specified, this will occur at every timestep.
When set to ON, allows simulation of the Tutorial Models without the need for a TUFLOW license.
For further information refer to Section 2.4.1.
Optional command to apply Imperial or US Customary units (if not specified the default is metric). All
simulation inputs, model parameters and outputs will follow the specified units
Setting this to 0 resets the model start time to be equal to the value specified using start time even
when a restart file is used (refer Restart file). Without this command or when set to 1 (true), the start
time is set equal to the restart file timestamp:
• 0 = False (i.e. use start time set with command start time)
This command can be used to apply a reduction factor to high-order cell reconstruction gradients,
which may be useful in stabilising a higher-order simulation.
Default is <1.0, 1.0>, which corresponds to no gradient reduction, whereas <0.0, 0.0> would revert to
a first-order scheme.
For use with Parametric or External vertical mixing model, globally sets the minimum and maximum
vertical eddy viscosity (m2/s) limits.
Not applicable if a Constant vertical eddy viscosity is set using the vertical mixing parameters
command.
Sets the Total Variation Diminishing (TVD) limiting scheme for 2nd order vertical spatial integration
scheme.
The options are MINMOD, MC (Monetized Central) and Superbee (ranging from least compressive to
most compressive). For further information please contact [email protected].
• Constant: a constant viscosity / diffusivity value is applied to the vertical mixing of both
momentum and scalars.
• External: any external turbulence model that has been built by the user to couple with
TUFLOW FV through the tuflowfv_external_turb.dll.
See also the Vertical mixing parameters, Global vertical eddy viscosity limits, Global vertical scalar
diffusivity limits Turbulence update dt and External Turbulence Model Dir commands.
Globally sets a constant vertical eddy viscosity (m2/s) or the vertical eddy viscosity coefficients. This
is dependent on the vertical mixing model set using the vertical mixing model command:
Globally sets the wind stress model to one of the following options:
• 1: Wu
• 2: Constant
• 3: Kondo
For further information please refer to Section 6.7. See also wind stress parameters.
Optionally specifies the parameter values of the wind stress model as follows:
Where:
Cd = Ca; [W10<Wa]
Cd = Ca + (W10-Wa)/(Wb-Wa)*(Cb-Ca); [Wa<=W10<=Wb]
Cd = Cb; [W10>Wb]
The default parameters correspond the Wu parameterisation (with a 50 m/s upper limit).
Writes a restart file (.rst) to the log directory location at the time interval specified. The restart file is
binary format and contains the spatially varying conserved variables at an instant in time.
A restart file is used to specify the initial condition for subsequent TUFLOW FV simulations using the
restart file command.
Bottom roughness
Inactive
Material
Spatial reconstruction
Surface roughness
Material block command to specify limits to bed elevations for cells with material id#. Can also be set
globally using the global bed elevation limits command.
Material block command used to set the bottom roughness value for cells with material id#. The
bottom roughness specification depends on the bottom drag model, and may be a Manning’s ‘n’”
coefficient (default) or an equivalent Nikuradse roughness, ‘ks’ (m).
Globally sets the bottom roughness value. The bottom roughness specification depends on the bottom
drag model, and may be a Manning’s ‘n’ coefficient (default) or an equivalent Nikuradse roughness,
‘ks’ (m).
Material block command to specify the horizontal eddy viscosity Constant value (m2/s) or
Smagorinsky model coefficient for cells with material id# (thereby overriding the default or
corresponding globally parameters), depending on the turbulence model used. See momentum mixing
model command to set momentum mixing turbulence model.
Material block command for use with Smagorinsky momentum mixing model to set the minimum and
maximum horizontal eddy viscosity (m2/s) limits for cells with material id# (thereby overriding the
default or corresponding globally set parameters).
Material block command to specify the horizontal scalar diffusivity value (m2/s) or model coefficients
for cells with material id# (thereby overriding the default or corresponding global turbulence
parameters), depending on the scalar mixing model used. See scalar mixing model command to set
momentum mixing turbulence model.
Material block command for use with Smagorinsky and Elder scalar mixing model to set the minimum
and maximum horizontal scalar diffusivity (m2/s) limits for cells with material id# (thereby overriding
the default or corresponding globally set parameters).
Inactive == <0;1>
(Optional, Default == 0)
Material block command used to exclude cells with material id# from the computational domain:
material == 1
inactive == 1
end material
This command indicates the beginning of a material block, specifying unique properties for cells with
material id #. Material properties are listed in the following rows and the ‘end material’ command is
used to indicate the end of the material block.
The following example material block specifies unique bottom roughness, horizontal eddy viscosity
and horizontal scalar diffusivity values for all cells with material type 1 (thereby overriding the default
or corresponding global turbulence parameters):
material == 1
bottom roughness == 0.020
horizontal eddy viscosity == 0.20
horizontal scalar diffusivity == 60.0, 6.0
end material
Note that several material types can be grouped into a single material block:
material == 2,3,4
bottom roughness == 0.1
As a minimum, the roughness for each material type specified in the geometry file should be defined
using material block commands (see also Section 8.5) or the global bottom roughness command. The
commands that can be used to within a material block include:
• Inactive
• Bottom roughness
• Surface roughness
• Spatial reconstruction
Material block command used in high order simulations to optionally limit spatial reconstruction for
cells with material id# (effectively reducing the spatial order of accuracy of the solution):
Material block command used to set the surface roughness value, typically used to simulate ice cover.
Material block command for use with Parametric or External vertical mixing model to set the
minimum and maximum vertical eddy viscosity (m2/s) limits for cells with material id# (thereby
overriding the default or corresponding globally set parameters). See also global vertical eddy
viscosity limits.
Material block command for use with Parametric or External vertical mixing model. Used to control
the vertical diffusion limits (m2/s) i.e. to increase/decrease the effective vertical mixing if there is
insufficient or too much vertical diffusion occurring in sections of your model. Please refer to Section
7.2.2. See also global vertical scalar diffusivity limits.
Material block command for use with Smagorinsky and Elder scalar mixing model to set the minimum
and maximum vertical scalar diffusivity (m2/s) limits for cells with material id# (thereby overriding
the default or corresponding globally set parameters).
BC default
BC default update dt
BC header
BC nodestrings
BC offset
BC reference time
BC scale
BC time units
BC update dt
Includes MSLP
Sub-type
<OR>
Typically (but not always), at least one boundary condition will be required for a TUFLOW FV
simulation and often a number of different boundary condition types will be applied. Each boundary
condition type is defined using a boundary condition (BC) block. The ‘BC’ and ‘End BC’ commands
indicate the beginning and end of a boundary condition block.
See Table 10-2 and Table 10-3 for lists of boundary types.
o The [id] value is the nodestring identifier included in the mesh geometry file (see
Section 8.1.2
• As a point source (within a single cell such as an outfall discharge or a moving point source
such as a plume generated by dredger)
o The [xid], [yid] values are the coordinates of the source location within the model
domain.
• BC header
• Sub-type
• BC offset
• BC scale
• BC default
• BC update dt
• BC time units
• Includes MSLP
• Layer
• BC nodestrings
• Polygon File
BC block command to specify a default boundary condition value if entry in the input file is empty.
A global command that allows the user to specify the update timestep for all boundary conditions. If not
specified, the boundary condition is updated at every simulation timestep. See BC update dt for setting
the update timestep for a specific boundary condition.
BC Header == <Header1,Header2,...>
(Optional)
BC block command that allows the user to specify the .CSV input file column headers or NetCDF file
variable names (thereby overriding the defaults in described in Table 10-2 and Table 10-3). This
command should immediately follow a BC command.
For example, the following lines apply a cell inflow (QC boundary condition type) at the cell which
lies at the x,y coordinate 1025.5, 950.5. It looks in the specified .CSV file for columns Time,
Tailwater_Flow and Turbidity:
Another example shows a water level boundary (WL) applied to nodestring 1, which looks in the
specified .CSV file for columns Time and WL_Loc1:
A final example shows a gridded wind field (W10_Grid) applied to a domain previously defined using
the grid definition variables command, which looks in the specified NetCDF file for variables Time,
Wind_X and Wind_Y:
BC == W10_Grid, 1, ..\bc\wind_10_grid.nc
BC header == Time, Wind_X, Wind_Y
End BC
BC nodestrings == <id1,....,idn>
(Optional)
BC block command to apply the boundary condition to multiple nodestrings (only relevant to the
OBC_GRID boundary type).
BC block command to set the boundary condition reference time. If not specified, the boundary
condition is assumed to be consistent with the simulation reference time.
BC block command used to specify the unit of time for a boundary condition specified using a NetCDF
file. The options are:
• Days
• Minutes
• Seconds
• Isotime
If not specified, the default is hours relative to the simulation reference time.
BC block command that allows the user to specify the update timestep for a boundary condition. If not
specified, the boundary condition is updated at every simulation timestep.
Grid definition file block command. Set to 1 to calculate interpolation weightings from the grid onto the
boundary nodestrings (this is required for OBC_grid boundary conditions that are to be later applied to
nodestrings).
Grid definition file block command. If set to 0, TUFLOW FV will not calculate the interpolation
weightings of the cells in the model for this gridded boundary condition (may be more efficient for grids
that are only going to be applied to the boundaries and not internal model domain.
Specifies a NetCDF location and filename that defines grid coordinates to be used in mapping input
files to the model mesh. The commands that can be used within a grid definition file block include:
cell gridmap
boundary gridmap
Grid definition file block command to specify the grid name and can be referred to by multiple boundary
conditions later. This command is placed within the grid definition file command block.
Grid definition file block command to specify the x,y coordinate variable names (typically Easting,
Northing or Longitude, Latitude) contained in the NetCDF file defined using the grid definition file
command.
BC block command that allows the user to specify whether a water level boundary condition (WL or
WLS) includes an inverse barometer offset.
The default assumption (1) is that the boundary does already include an inverse barometer component.
If include MSLP == 0 then an offset determined by the local MSLP difference from the reference MSLP
is applied at the boundary.
The sub-type BC block command is applicable for various boundary types (refer Table 10-4) and allows
the user to control certain details of how these are numerically implemented.
o Applied as a flux
o Note: While the net flow will match the input file specifications, using this sub-type
with 3D simulations does not guarantee uniform inflow over the entire water column.
In some cases, one part of the water column can be flowing in while another is
flowing out. It is therefore recommended to use sub-type 2 or 4 for 3D models.
o Applied as a flux
Note: for overland application with inflows over an initially dry bed, subtype = 4 is
recommended.
• If sub-type == 1 (default) the flux calculation uses a boundary calculation method added to the
2019 TUFLOW FV Release. This method should limit warning messages that could occur
when using QN boundaries: ‘Unable to solve for specified inflow conditions at bc’.
• If sub-type == 2 the flux calculation uses the pre-2019 TUFLOW FV Release’s QN boundary
flux calculation method and can be used for legacy simulations.
For all OBC boundary condition (i.e. OBC, OBC_PROF, OBC_CURT, OBC_GRID):
• If sub-type == 2, the boundary specifies an incoming wave form which is superimposed with
the internally calculated outgoing wave form.
• If sub-type == 3, the boundary specified flow velocity. Water level is modified to avoid BC
over-specification which can lead to boundary reflection of outgoing energy.
• If sub-type == 4, the boundary is over specified (both water level and velocity are specified).
Water level and velocities are applied exactly as specified in the input files. This can lead to
boundary reflection of outgoing energy.
• If sub-type == 5, specified water levels are treated as an increment to apply to the previously
specified water level. This can for instance be used to add a tidal signal to a separately
specified non-tidal OBC. This sub-type can also be used in conjunction with WL, WLS and
WL_CURT BCs.
• If sub-type == 1 (default). When outflow is specified (Q<0) the scalar flux is determined by
the interior model concentration (the BC file value will be ignored).
• If sub-type == 2. When outflow is specified (Q<0) the scalar flux is determined by the BC file
specified value.
Grid definition file block command. If set to 1 suppresses warnings if the grid does not cover the entire
TUFLOW FV domain. It may be more efficient and result in smaller log file output in situations that the
grid only needs to cover a small number of the cells within the model domain.
BC or Structure block command to specify the BC vertical coordinate type for vertically distributed
boundary conditions. The options are:
• Elevation
• Depth
• Sigma
• Height
This command is followed by speciation of a vertical distribution file that defines the vertical
distribution.
If not specified, the boundary condition is distributed evenly over the water column.
BC or Structure block command used in conjunction with vertical coordinate type to specify a .CSV file
that describes the boundary condition vertical distribution.
• The first column is the vertical coordinate (e.g. DEPTH) type reference.
• The second column is the weighting (between 0 and 1) at the corresponding vertical reference.
The units of WEIGHT are irrelevant as the distribution is normalised.
The first example .CSV file corresponds to the vertical coordinate type “depth” and the boundary
condition being applied to the top 2m of the water column:
The second example corresponds to the vertical coordinate type “height” and the boundary condition
being applied to the bottom 1m of the water column.
HEIGHT, WEIGHT
0.0, 1
1.0, 1
1.11, 0
9999.0, 0
The final example corresponds to the vertical coordinate type “elevation” and the boundary condition
being applied at -10 to -20 meters (below the model datum).
ELEVATION, WEIGHT
0.0, 0
-1.0, 0
-5.0, 0
-9.9, 0
-10.0, 1
-20.0, 1
Destratification Unit
Flux file
Flux function
Max_conc
Min_conc
Name
Polygon file
Properties
Sample dt
Sample point
Sample type
Scal_fact
Scalar function
A control specification is required to initiate bed adjustments (See control). Refer to Section 11.6.1 for
more details. An example using a trigger control block is provided below:
BreachCondition.csv
Time Zb
0.0 24.0
2.0 23.0
4.0 22.0
6.0 21.0
8.0 20.0
10.0 19.0
The blockage file is a comma separated variable file with a relationship of flow fraction and depth,
commonly used during modelling of bridge structures (in conjunction with Form loss coefficient). Refer
to in Section 11.4 for further details.
The file contains the header line with column labels “Z” and “FRAC”.
• The Z column is a list of elevations (lowest to highest).
• The FRAC column is the fraction of flow (0 to 1) for the vertical section between the
corresponding Z value and its previous value.
Z, FRAC
5.0, 0.9
7.0, 0.9
7.1, 0.0
7.9, 0.0
8.0, 0.5
8.9, 0.5
9.0, 1.0
End Control
(Optional, Structure Block Command)
• Timeseries: Timeseries controls define an adjusting condition based on a separate control file CSV
timeseries. The current timestep is interpolated into the timeseries to calculate a corresponding
control parameter value.
• Sample_rule: A sample rule control can adjust the control parameter by sampling a variable within
the model and comparing it to a control file CSV. Currently TUFLOW FV can sample the
following variables using the sample type command at a sample point:
o H, V_x, V_y, SAL, TEMP, SED_1 – SED_N, TRACE_1 – TRACE_N, WQ_1 – WQ_N
• Target_rule: A target rule control can adjust the control parameter to reach the target value of the
sample type at a sample point. The flow through the structure is adjusted based on the difference
between the sampled value and the target value. The target value is specified in a target file, which
is a timeseries to allow for time-varying target conditions.
For quick reference, commands that reside in a control block are provided below:
Control == <controltype>
Control parameter == <controlparam>
Control file == < cfile>
Control update dt == <cdt (hours)>
Sample point == <spx, spy>
Sample type == <st>
Max opening increment == <moi>
Trigger value == <tv>
Target file == <tfile(.CSV)>
End Control
Please refer to Sections 11.6.1 and 11.6.2 for more details and Section 11.6.5 for examples.
Reads in a comma separated file (.CSV) with structure controls. The file contains a header line with
specific column labels required for specific structure types:
If control == sample_rule:
• Column headers = “Sample_value, ControlParameter” (e.g. “Sample_value, Fraction_open”) or
(e.g :Sample_value, Min_flow)
If control == timeseries
o Column headers = “Time, ControlParameter” (e.g. “Time, Fraction_open”)
If control == target
o Column headers = “, Target_deficit, ControlParameter” (e.g. “Target_deficit,
Fraction_open”)
Please refer to Sections 11.6.1 and 11.6.2 for more details and Section 11.6.5 for examples. See also
control parameter and control.
• Min_flow: Provides a minimum flow rate that must pass through the structure (physical limitations
permitting). This is often used in conjunction with dam release structures where a minimum flow
is required for environmental releases. When multiple min_flow controls are used in the same
structure, the maximum of these will be the adopted value. Please note this control parameter is
not supported with flux function == nlswe.
• Weir_crest: Used with weir_adjust or weir_dz_adjust flux functions (refer Section 11.3.4.2 ) and
allows the crest height of the weir (absolute level or relative to the adjacent cells) to be adjusted
based on the control. Often used to simulate a lowerable or failing levee system (please refer to
Figure 11-7 for an example).
• Zb: Can only be used with cell or zone structure types using bed_adjust (refer Section 11.2.4) and
adjusts the bathymetry of the structure area based on a condition. Often used to artificially adjust a
model bed for scour with time, or to simulate a bund failure after a trigger condition.
Refer to Section 11.6.3 for more details and Section 11.6.5 for examples. See also Control file and
control.
Reads in a comma separated variable file (CSV) with properties for a list of culverts.
• Culvertfile is the file containing a list of culvert properties.
• ID identifies the specific culvert properties from the list of culverts in culvertfile.
The file contains a header line with column labels. Each subsequent line contains the property values
listed in Table 11-3. Refer to Section 11.3.7 for more details.
energyloss.csv
Q dH Comment
-10 0.1 ! Flow against structure direction
0 0 ! No head loss for no flow
1 0.1 ! Nlarger head losses for +ve flow
5 0.2
10 0.3
If structype = nodestring or structype = linked nodestrings then an energy loss function can be
specified.
The flux file is a comma separated variable file with the hQh flux matrix, defining discharge for a
combination of upstream and downstream water levels.
It contains header lines (as many header lines as desired but with no more than 2 commas in each
line), then a matrix as follows:
• First row is a list of upstream water levels
• First column is a list of downstream water levels
• Matrix is discharge values corresponding to the listed water levels (corresponding row for
downstream, corresponding column for upstream).
• The first value on the first line is a scale factor, which is applied to the Q values in the matrix.
An example of a CSV file is shown below. Refer to Section 11.3.3 for more details.
1,0,2,4,10 0
Water Level Downstream (RL)
0,0.0,3.6,5.1,8.1 1
-2.6 2.6 4.4 7.7
2
1,-2.6,2.6,4.4,7.7 -3.6 0 3.6 7.2
10
2,-3.6,0.0,3.6,7.2 -8.1 -7.2 -6.3 0
If structype = nodestring or structype = linked nodestrings or structype == linked zones then the flux
function type defines the flux (or flow).
If energy loss function = Coefficient, form loss coefficient applied to structure. FLC applies a head
loss across a cell face according to the equation:
Δh = FLC v2/2g
The maximum concentration of the tracers passing through the structure.. Used in combination with
the scalar function command. See also Min_conc and Scal_fact . For more information on Scalar
functions please refer to Section 11.5).
Maximum change in structure Fraction open (See control) per update time step (see Sample dt). Refer
to Section 11.6.1 for more details.
The minimum concentration of the tracers passing through the structure. Used in combination with the
scalar function command. See also Max_conc and Scal_fact . For more information on Scalar
functions please refer to Section 11.5).
Name == <sname>
(Optional, Structure Block Command)
Name of structure, used in some structure outputs later including the structflux, structcheck outputs.
Reads in a comma separated variable file defining the perimeter vertices of a polygon.
The file contains a header line with column labels “X”, “Y” and “ID, which define the coordinates of
points describing the perimeter of the polygon and the polygon that each coordinate belongs to. The
definition of points needs to be consecutively listed and can be either clockwise or counter-clockwise.
TUFLOW FV searches for cell centres that lie within the polygon.
Properties == <p1,....,pn>
(Optional, Structure Block Command)
The frequency of updating the variable structure (hours). Required is using the
spx, spy defines the location that controls the variable z value structure (i.e. the “control” point)
Commands commonly used in conjunction with Sample point are Sample type and Sample dt.
Control block command that defines the model parameter used for the sampling at a Sample point.
Used in combination with the scalar function command. The factor by which scalar concentrations are
modified as they pass through the structure. Does not conserve mass.
For scale factor type scalar functions this scale factor will always be applied. If a max_conc or
min_conc are also present then they will be applied afterwards.
For treatment type scalar functions this scale factor will be applied unless it results in concentrations
below those specified in the min_conc command.
Commands commonly used with the scalar function include: Min_conc, Max_conc and Scal_fact . For
more information on scalar functions please refer to Section 11.5).
Value equal to or between 0 and 1 defining the fraction open of a structure at the start of the
simulation.
…
End Structure
(Optional)
Each structure type is defined using a structure block. The ‘Structure’ and ‘End Structure’ commands
indicate the beginning and end of an structure block. The structure block specifies the type of structure
using the structype input, and it’s location (if applicable) using the ID input.
Once the structure type has been defined, a range of supporting commands can be nested into the
block, depending on the structure type and if applicable: flux function, scalar function and need for
structure controls.
Structure == Structype, ID
Name == <sname>
Flux function == <fluxtype>
Culvert file == <culvertfile(.CSV), ID> (if flux function == Culvert)
Flux file == <hQhfile(.CSV)> or <timeseries(.CSV)> (if flux function == Matrix or Timeseries)
Properties == <p1,....,pn>
Polygon file == <polyfile(.CSV)> (if structure == zone or linked zone)
Destratification unit == <celltype> (if structure == cell or zone)
Bed adjust == <celltype> (if structure == cell or zone)
Control == <controltype>
Control parameter == <controlparam>
Control update dt == <cdt (hours)>
Sample point == <spx, spy>
Sample type == <st>
Sample dt == < sdt (hours)>
Max opening increment == <moi>
Trigger value == <tv>
Target file == <tfile(.CSV)>
End Control
End Structure
Reads in a comma separated file (.CSV) defining the target value for the Sample Type
• Column headers = “Time","Target_Value"
The value of the specified model parameter at the Sample point spx, spy that, when exceeded, will
trigger a change in structure elevations.
Note that currently the trigger value can only be an absolute water level. Refer to Section 11.6.1 for
more details. Command is commonly used in conjunction with Control file and Polygon file
The width file is a comma separated variable file with a relationship of flow width and depth which is
commonly used during modelling of bridge structures (in conjunction with Form loss coeeficient)..
Refer to in Section 11.4 for further details.
The file contains the header line with column labels “Z” and “WIDTH”.
• The Z column is a list of elevations (lowest to highest).
• The WIDTH column is the width of flow (m or ft – depending on units) for the vertical section
between the corresponding Z value and its previous value.
Output
Output compression
Output interval
Output parameters
Output statistics
Start output
Suffix
Vertical averaging
Output block command to specify the final time for an output request. The time format must be
consistent with the simulation time format. If not specified, the output final time will be consistent
with the simulation end time.
Each output type is defined using an output block. The ‘Output’ and ‘End output’ commands indicate
the beginning and end of an output block. The output block specifies the type of output and the output
properties including the desired parameters and time definitions. Table 12-1 presents a summary of the
the output types available, which include:
• dat (cell centred SMS data file output, not typically recommended).
• Flux (time series of fluxes across all nodestrings, refer Section 12.5).
• NetCDF (cell centred 2D and 3D output, used heavily for 3D model visualisation, refer
Section 12.6.4).
• Transport (TUFLOW FV file used for decoupling hydrodynamics from following advection
dispersion, sediment or water quality simulations, refer Section 10.8).
• Structcheck (Check the behaviour of a structure, commonly used in association with structure
controls refer Section 12.8.2).
• Output parameters
• Output interval
• Start output
• Suffix
• Output compression
• Output statistics
• Output statistics dt
• Vertical averaging
Output block command used to specify the desired output interval in seconds. If this command is not
specified output will be produced at each timestep. In many applications this will not be desired
(possibly leading to extremely large output files) and an output interval at 10min (600s) or 30min
(1800s) will be more appropriate.
Output block command used within the output block to specify the required output parameters. The
available output parameters are summarised in Table 12-3 and Table 12-4 (note that some output
parameters are dependent on the output type).
Mandatory command when points output type is required. This provides the location and name of a
comma separated variable file with the coordinates of the required output points. The following
column headers are required in .CSV file:
• X, Y, ID (where the ID field is optional but recommended for ease of result review)
Output additional requested statistics. The following statistics are currently supported: MAX & MIN.
This feature is available with datv and NetCDF output types.
Output block command to specify the start time for an output request. The time format must be
consistent with the simulation time format. If not specified, the output start time will be consistent
with the simulation start time.
Suffix == <suffix>
(Optional)
Optional output block command to vertically average 3D results over a specified range. The vertical
averaging types are:
• depth-all – The ‘depth-all’ command vertically averages over the entire water column. Example
‘depth-all’ output block commands and a conceptual illustration are provided below.
output == datv
vertical averaging == sigma-range, 0,0.25 !top 25% of water column
suffix == sigma_0_0.25
output parameters == V
output interval == 1800.
end output
output == datv
vertical averaging == height-range, 0,2 !bottom 2m measured from the bed
suffix == height_0_2
output parameters == V
output interval == 1800.
end output
In these examples the suffix command is used to distinguish between output files. This is particularly
important when a simulation control file specifies multiple vertically averaged outputs.
Reference density
Decay rate
Specifies the timestep for performing atmospheric parameter updating, if not specified atmospheric
parameter updating occurs every hydrodynamic model timestep.
Tracer block command to specify the scalar decay rate in concentration units/day. This results in a
sink term flux, S:
S = KdCh
Allows the user to specify the density of air used in atmospheric heat calculations. Please refer to
Section 7.3 for further information on reference values.
Sets the model for calculating the density of water in baroclinic simulations:
• UNESCO: use the UNESCO equation of state (Fofonoff and Miller, 1983).
• Direct: A tracer can be applied as a direct proxy for density. This approach is generally not
recommended but can be useful for conditions where the user requires control over modelled
Globally sets the horizontal diffusivity (m2/s) or diffusivity model coefficients. This is dependent on the
scalar mixing model set using the scalar mixing model command:
See scalar mixing model command to set scalar mixing turbulence model.
For use with Smagorinsky or Elder scalar mixing model, globally sets the minimum and maximum
horizontal scalar diffusivity (m2/s) limits.
Not applicable if a Constant isotropic scalar diffusivity is set using the global horizontal scalar
diffusivity command.
See scalar mixing model command to set scalar mixing turbulence model.
Command for use with Parametric or External vertical mixing model. Used to control the vertical
diffusion limits (m2/s) i.e. to increase/decrease the effective vertical mixing if there is insufficient or
too much vertical diffusion occurring in sections of your model. Please refer to Section 7.2.2.2 for
more information. See also vertical scalar diffusivity limits.
The second flag specifies whether density is a function of the modelled salinity:
The second flag specifies whether density is a function of the modelled temperature:
Globally sets the initial salinity for simulations including baroclinic terms.
Command used in conjunction with initial condition 2d to specify a .CSV file that describes the initial
scalar profile.
Globally sets the initial temperature for simulations including baroclinic terms.
• 1 = Vapour pressure is calculated by the Magnus-Tetens formula (TVA, 1972) – requires air
temperature and relative humidity inputs
• 2 = Vapour pressure is calculated via modified equations based on Lowe (1977) and Reed
(1977) – requires air temperature and cloud cover inputs
• 2 = Incident long wave radiation with long wave radiation albedo and water surface reflection
are calculated following TVA (1972). Long wave radiation emitted by the water surface is
calculated assuming the Stefan-Boltzmann law – requires incident downward long wave
radiation input
• 3 = Incident long wave radiation is calculated assuming the Stefan-Boltzmann law with a
correction for cloud cover following TVA (1972) - requires incident downward long wave
radiation and cloud cover inputs
• 4 = Incident long wave radiation with corrections for cloud cover and the long wave radiation
emitted by the water surface due to the air/water temperature difference following Zillman
(1972) - requires incident downward long wave radiation, cloud cover and air temperature
inputs
• 5 = Based on air temperature and vapour pressure (Chapra, 2008) – requires air temperature
and relative humidity inputs
Command used to specify the number of tracers in an AD simulation. The properties of each tracer are
defined using the tracer block commands. Up to 100 tracers can be specified.
Optionally sets the model reference salinity for simulations including baroclinic terms.
Sets the reference density of water value used in calculation of the baroclinic pressure terms.
Sets the reference density of water value used in calculation of the baroclinic pressure terms.
Optionally sets the model reference temperature for simulations including baroclinic terms.
Sets the scalar mixing calculation method. See also global horizontal scalar diffusivity.
• Constant: specify a constant isotropic scalar diffusivity using the global horizontal scalar
diffusivity command.
• Elder: the horizontal non-isotropic scalar diffusivity is calculated according to the Elder model
- specify the longitudinal and transverse coefficients using the global horizontal scalar
diffusivity command.
• Warm up: can be used for initialising scalar distribution (diffusivity is set to maximum within
CFL stability constraints.
Tracer block command to specify the scalar settling velocity in m/s. This results in a sink term flux, S:
S = -ws0C
• 1 = Incident short wave radiation estimated according to Jacquet (1983) – requires downward
short wave radiation input
• 2 = Incident short wave radiation under clear sky estimated according to Zillman (1972) with
cloud cover correction factor given by Reed (1977) – requires air temperature and cloud cover
inputs
Specific heat capacity of dry air at 25ºC. Please refer to Section 7.3 for further information on
reference values.
Specific heat capacity of water at 25ºC. Please refer to Section 7.3 for further information on reference
values.
This command indicates the beginning of a tracer properties block, specifying the tracer id # that the
properties should be applied to. Tracer properties are listed in the following rows and the ‘end tracer’
command is used to indicate the end of the tracer block.
Ntracer == 2
! Start Tracer Blocks
tracer == 1 ! Open Tracer Block for Tracer ID #1
settling velocity == 2.0e-5
decay rate == 0.05
end tracer ! Close Tracer Block for Tracer ID #1
tracer == 2 ! Open Tracer Block for Tracer ID #2
settling velocity == 1.0e-5
decay rate == 0.05
end tracer ! Close Tracer Block for Tracer ID #2
! End Tracer Blocks
An optional command to set the threshold water depth for transport mode AD calculations. AD
calculations are not undertaken in areas where the depth is less than the threshold value.
Initial WQ concentration
WQ update dt
An optional command to set the threshold water depth for water quality calculations. Water quality
calculations are not undertaken in areas where the depth is less than the threshold value.
• 0 = False (i.e. if specified, external water quality model calculations are enabled).
• 1 = True (i.e. if specified, external water quality model calculations are disabled).
Disabling the water quality model can be a useful diagnostic tool if trying to troubleshoot a coupled
TUFLOW FV/external water quality run.
Optional command to specify the directory for external water quality model definition files if an external
water quality model is used. If not specified, external water quality model model files must be located
in the same directory at the simulation control file.
Optional command to link an external water quality model with TUFLOW FV such as AED2.
Wave forcing is often important when simulating the advection-diffusion of sediments or water-borne
constituents in estuarine or coastal environments. Mapped, time-varying SWAN wave model output in
NetCDF format can be used as a boundary condition for a subsequent TUFLOW FV advection-diffusion
simulation. The dimensions, variable definitions and attributes of a SWAN NetCDF output file are
provided below and would typically contain the following variables:
The TUFLOW FV boundary condition block commands to read the SWAN NetCDF output file and
include the parameters in the advection-diffusion calculations are:
The variables listed following the ‘bc header’ command should follow the order in the example provided
above. Specification of the ‘bc reference time’ and the ‘bc time units’ is crucial since SWAN and
TUFLOW FV have differing default time formats. Without this information TUFLOW FV would not
apply the SWAN output at the intended time. The ‘bc update dt’ specifies the time interval in seconds
between wave field updates, generally consistent with the temporal resolution of the SWAN output.
It is not a requirement for ubot, tmbot, xforce and yforce to be included in the SWAN NetCDF output
file. If not specified, these variables with be either approximated by TUFLOW FV or simply not
included in the advection-diffusion calculation. As a minimum, the following variables should be
specified:
bc header == time, hs, tps, theta0
In this example, TUFLOW FV would approximate the near bottom orbital velocity (ubot) using the
available parameters and following linear wave theory, and the surface peak period (tps) would be
applied as the near bottom period (tmbot). If not specified, the wave induced forces (xforce, yforce) are
not approximated or used by TUFLOW FV.
In situations where ubot and tmbot are present in the SWAN NetCDF output file but the user wishes to
use the TUFLOW FV approximations, the ‘dummy’ command should be used:
Recent versions of SWAN source code and many SWAN binary distributions for Windows support
NetCDF model output. More information may be found on the SWAN website:
http://swanmodel.sourceforge.net/
Source:
C:\TUFLOWFV\bc\waves\SWAN_output.nc
64bit
Global Attributes:
Conventions = 'CF-1.5'
History = 'Created with agioncmd version 1.2'
Directional convention = 'cartesian'
project = '001'
run = '001'
Dimensions:
time = 18633 (UNLIMITED)
xc = 251
yc = 651
Variables:
time
Size: 18633x1
Dimensions: time
Datatype: int32
Attributes:
units = 'seconds since 1970-01-01'
calendar = 'gregorian'
standard_name = 'time'
long_name = 'time'
longitude
Size: 251x651
Dimensions: xc,yc
Datatype: single
Attributes:
units = 'degrees_east'
long_name = 'longitude'
standard_name = 'longitude'
latitude
Size: 251x651
Dimensions: xc,yc
Datatype: single
Attributes:
units = 'degrees_north'
long_name = 'latitude'
standard_name = 'latitude'
hs
Size: 251x651x18633
Dimensions: xc,yc,time
Datatype: int16
Attributes:
units = 'm'
standard_name =
'sea_surface_wave_significant_height'
long_name = 'hs'
coordinates = 'longitude latitude'
_FillValue = -3.28e+04
scale_factor = 0.000763
add_offset = 25
tps
Size: 251x651x18633
Dimensions: xc,yc,time
For TUFLOW FV 3D simulations, the baroclinic pressure-gradient terms can be optionally activated to
allow the hydrodynamic solution to respond to temperature, salinity and sediment induced density
gradients. In addition, atmospheric (surface) heat exchange calculations can also be included for given
standard meteorological parameter inputs.
In the example below mapped, time-varying atmospheric data derived as part of the NCEP-DOE Re-
analysis 2 project (website: http://www.esrl.noaa.gov/psd/data/gridded/data.ncep.reanalysis2.html)
were downloaded and post-processed to create a single NetCDF file containing the following surface
variables:
• precipitation (rain)
The TUFLOW FV boundary condition block commands to read the NetCDF file containing the NCEP-
DOE Re-analysis 2 data and include the parameters in the heat exchange calculations are:
With the exception of precipitation15, the variables provided in this example correspond to the inputs
required by the TUFLOW FV heat exchange module in default mode. Additional inputs, such as cloud
cover, may be required when activating non-default atmospheric module settings. A full description of
the heat exchange calculation options is available in the TUFLOW FV Science Manual.
15
Precipitation is an optional input (assumed freshwater) for baroclinic mode simulations.
Source:
C:\TUFLOWFV\bc\atmospheric\NCEP_DOE_R2_data.nc
Format:
classic
Global Attributes:
origin = 'NCEP Reanalysis'
Dimensions:
ni = 11
nj = 14
time = 1464 (UNLIMITED)
Variables:
time
Size: 1464x1
Dimensions: time
Datatype: double
Attributes:
units = 'hours'
longname = 'time in decimal hours since 01/01/1990
00:00'
reference = 'AEST'
lon
Size: 11x1
Dimensions: ni
Datatype: single
Attributes:
units = 'degrees'
longname = 'longitude'
projection = 'LL_WGS84'
lat
Size: 14x1
Dimensions: nj
Datatype: single
Attributes:
units = 'degrees'
longname = 'latitude'
projection = 'LL_WGS84'
u
Size: 11x14x1464
Dimensions: ni,nj,time
Datatype: single
Attributes:
longname = 'u'
units = 'm s^-1'
v
Size: 11x14x1464
Dimensions: ni,nj,time
Datatype: single
Attributes:
longname = 'v'
units = 'm s^-1'
temp
Size: 11x14x1464
Dimensions: ni,nj,time
Datatype: single
Attributes:
longname = 'air temperature'