Hydraulic Model Verification Checklist (HEC-RAS 2D and ANUGA)¶

Hydraulic model verification is the process of confirming that a finished 2D flood or stormwater model is internally consistent, defensible against reviewer questions, and fit to submit. This page sets out the verification checklist Hydrata runs on every uploaded HEC-RAS or ANUGA model. It is engine-agnostic where the engineering question is the same and engine-specific where the implementations differ. Engineers can work through it manually on their own model, or upload the project to Hydrata and have the checks run automatically.

Last updated: May 2026.

What is the difference between validation and verification?¶

Validation answers the question: does the model match observed reality? That is a calibration question. It compares simulated peak depths against gauged flood marks, verifies mass arrival times against measured hydrographs, and benchmarks against analytical solutions. ANUGA's validation record sits in Validation.

Verification answers a different question: is the model internally consistent and defensible? That is an audit question. It checks mass balance, mesh quality, parameter sanity, boundary condition setup, and jurisdiction-checklist compliance. A model can be verified without being validated against field data, and an uncalibrated model can pass verification if its internals are sound. Most submissions in practice require both: validation evidence for the engine and verification evidence for the specific model.

Reviewers send models back for verification failures far more often than for validation failures. The 12 checks below are the ones most commonly raised in review.

The 12-check verification checklist¶

1. Does the model close on mass balance?¶

Mass balance is the first check any competent reviewer runs. Inflow plus initial storage must equal outflow plus final storage plus any documented losses, to within a defensible tolerance.

Engine	Where the mass balance number lives	Acceptable tolerance
HEC-RAS 2D	`Summary Output` → `Volume Accounting` in RAS Mapper	< 1% of total inflow volume
ANUGA	Logged during `evolve()`; written to the SWW summary	< 1% of total inflow volume

A model with >1% mass balance error is not submittable. Common causes: leaky boundaries, internal sinks (storage areas mis-elevated below the mesh), or numerical diffusion at the wet/dry interface for ANUGA. Find the source before submission.

2. Is the mesh fine enough where it matters and coarse enough where it doesn't?¶

A mesh too coarse smears peak depths at the location that matters. A mesh too fine inflates run time without changing decisions. The verification question is whether mesh resolution reflects engineering priorities.

Required checks:

Refinement zones drawn around the asset under consideration (channel, structure, inundated property) with edge length ≤ 1/3 of the smallest geometric feature.
Transition between coarse and fine cells uses no more than 2× size jump per ring (prevents numerical artefacts at the interface).
No triangle with skew > 0.7 (ANUGA) or cells with aspect ratio > 5 (HEC-RAS), except where the geometry demands it and the issue is documented.
Total cell count justified by the engineering question. A 5-million-cell model for a single-property assessment is usually wrong; a 50,000-cell model for a regional study is usually wrong.

3. Are Manning's n values within defensible ranges, and assigned to the right surfaces?¶

Reviewers cross-check Manning's n against land-use mapping. The verification check is two-fold: are the values within published ranges, and is the spatial assignment defensible against the source data?

Surface	Manning's n range (1D-2D urban flood, AEM 2018)
Mowed grass	0.025 – 0.035
Light brush / pasture	0.030 – 0.050
Heavy brush	0.060 – 0.100
Cleared urban (roads, paved)	0.013 – 0.020
Dense urban (buildings as roughness)	0.080 – 0.150
Mature forest	0.080 – 0.120
Channel, concrete	0.012 – 0.018
Channel, earthen, regular	0.022 – 0.030
Channel, natural, irregular	0.035 – 0.060

A model that uses a single n=0.035 across a mixed urban/rural catchment will not survive review. The spatial assignment must reference the source land-use raster or vector layer, and the friction map must be exportable for the reviewer to audit.

4. Are the boundary conditions consistent with the hydrologic forcing?¶

The most common boundary-condition error is an inflow hydrograph at the upstream boundary that does not match the rainfall-runoff totals over the contributing area. If the hydrologic model produces 14 ML of runoff for the design event, the inflow hydrograph must integrate to ~14 ML.

For each boundary, the audit asks:

Is the boundary type correct? (Reflective, transmissive, time-series stage, discharge, rating curve.)
Does the boundary location avoid a known flow gradient? (Boundaries placed inside an inundation area produce artefacts.)
Does the downstream tailwater reflect the design tide / lake stage / receiving channel rating curve at the design event?
For ANUGA, is Bt (reflective wall) used where a building edge is meant to act as a wall? Using Bo (transmissive) leaks water into buildings.
For HEC-RAS, are 2D Connection internal boundaries used for embankments and weirs, not modelled as roughness?

5. Is the rainfall input traceable to a published source?¶

The rainfall input is the single most-questioned item in any flood submission. Verification requires:

IFD source named and dated (BoM IFD 2016 for Australia, NOAA Atlas 14 for US, jurisdiction-equivalent elsewhere).
Design ARI / AEP stated explicitly. "1 in 100 year" is ambiguous without specifying whether it is 1% AEP or 1-in-100 ARI, and whether climate scaling has been applied.
Temporal pattern source named (ARR2019 temporal patterns for Australia, NRCS Type II / III for US, jurisdiction-equivalent elsewhere).
Areal reduction factor applied for catchments larger than 25 km², referenced.
If climate-scaled, the scaling factor and emissions pathway documented.

A rainfall input that cannot be reproduced from a published IFD will fail verification.

6. Does the simulation run long enough for the system to drain to a defensible¶

state?

Reviewers check that the final timestep depth field has reached a stable state. For a 24-hour design event, this typically requires running for 36 to 48 hours to allow the catchment to drain. A simulation that ends at 24h with water still ponded above 0.1 m across 5% of the domain is incomplete.

The check: in the final-timestep depth raster, less than 1% of the domain shows depth > 0.1 m, or a separate note in the documentation explains why standing water at the simulation end is expected.

7. Are structures modelled at the correct invert and capacity?¶

The most common verification failure for stormwater models is incorrectly specified culverts, bridges, or weirs.

Culvert: invert levels in/out match survey. Length matches the road embankment width. Loss coefficients (entrance, exit, friction) defensible against published tables for the culvert type.
Bridge: deck low chord elevation matches survey. Pier blockage included if piers occupy > 10% of waterway area.
Weir: crest elevation matches survey. Weir coefficient appropriate for the geometry (broad-crested, sharp-crested, or ogee).
For HEC-RAS 2D, structures are added as 2D Connections, not as roughness patches over the obstruction.
For ANUGA, structures use Inlet_operator, Weir_operator, or Culvert_operator as appropriate. Friction-only treatment is not acceptable for hydraulic structures.

8. Has parameter sensitivity been tested on the critical inputs?¶

Verification requires evidence that the result is not over-sensitive to a single parameter. The minimum sensitivity matrix:

Parameter	Tested range	Recorded output
Manning's n (overall)	±25%	Peak depth at critical location
Rainfall depth	-10% / +20%	Peak depth at critical location
Boundary tailwater	±0.5 m	Peak depth at critical location
Initial soil moisture	dry / saturated	Peak depth at critical location

A result where peak depth changes by more than 30% across these variations indicates over-sensitivity, and the dominant parameter must be discussed in the submission.

9. Has the model been compared against any independent check?¶

The check the reviewer wants to see at the end of a model run: a comparison between the model output and some independent reference. Acceptable independent checks include:

A second model in a different engine on the same domain, even at lower resolution (HEC-RAS 1D quick-check on the channel network).
Hand calculation of peak discharge via the Rational Method for the contributing catchment, compared to the 2D model's peak flow at the catchment outlet.
A historical flood mark on the model domain, if any are documented.
A regional regression equation for peak discharge, compared to model output.

A model with no independent cross-check is not verifiable. The cross-check does not need to agree exactly; it needs to be defensible.

10. Does the output meet the jurisdiction's submission checklist?¶

Each jurisdiction publishes its own submission requirements. Verification at this step is a literal line-by-line tick against the jurisdiction's published checklist. Examples:

US FEMA MT-2 Form: required maps, profiles, hydraulic structure tables.
Australian local council: AEP coverage required (1%, 0.5%, 0.2%, PMF), freeboard reporting, hazard categorisation per AIDR Flood Hazard Framework.
UK Environment Agency: SAB approval requirements, climate change uplift factors, residual risk assessment.

Each submission must reference the jurisdiction document version and have a mapping between section and model output.

11. Are the deliverables internally consistent?¶

The flood map, the depth statistics table, the velocity raster, and the report narrative must agree. Verification fails on:

A flood map showing inundation that does not match the depth raster's > 0.1 m contour.
Peak depth in the report narrative ≠ peak depth from the depth statistics table.
Hydraulic hazard category in the report ≠ hazard derived from the velocity and depth rasters.
A scenario named "1% AEP + Climate" producing the same depths as the "1% AEP" scenario.

Auto-generated reports prevent this class of error; hand-written reports introduce it routinely.

12. Is there an audit trail?¶

The final verification item is reproducibility: a reviewer should be able to re-run the model and reproduce the result. That requires:

Input data files preserved (DEM, rainfall, friction map, boundary CSVs, structure geometry) with checksums.
Engine version recorded (HEC-RAS version, ANUGA version).
Solver settings recorded (timestep, output frequency, wetting/drying threshold, parallelisation settings).
Random seeds recorded if any stochastic component is used.
Each scenario tagged with the date, the engineer responsible, and the inputs used.

A model with no audit trail can be re-run, but the result of the re-run cannot be compared against the submitted result, which means the submitted result cannot be defended.

How Hydrata automates this checklist¶

Hydrata is a hydraulic model verification platform: it runs the 12 checks above automatically and produces a signed advisory PDF report. The process:

Upload a finished HEC-RAS .zip or ANUGA project. Hydrata parses the project structure, ingests the DEM, friction map, boundary conditions, rainfall input, and any structures.
The platform runs each of the 12 checks against the model and records the pass/fail status, the diagnostic value (e.g. mass balance %), and any flags.
Sensitivity runs are dispatched to AWS Batch in parallel. For ANUGA, this uses the validated run_anuga open-source toolchain. For HEC-RAS, sensitivity runs are executed on the consultant's own model with parameter variations.
Jurisdiction-checklist comparison runs against the project's declared submission target.
Output: a signed advisory report listing each check, the result, and the recommended action where any check fails. The report is co-signed by Hydrata, not certified by it. The consultant remains the model-of-record.

The platform is open source under MIT licence. The verification pipeline is auditable end-to-end at github.com/Hydrata/run_anuga and the project repos linked from the main site.

Book a 20-minute walk-through to see a verification report against your own model: david.kennewell@hydrata.com.

Frequently asked questions¶

How long does a Hydrata verification run take?¶

For a typical urban catchment model (mesh size 50,000 to 500,000 cells), a full 12-check verification with parameter sensitivity completes in 4 to 8 hours of wall clock time. The sensitivity runs dominate. Mass balance, mesh quality, and parameter audit checks complete in under 10 minutes.

Does Hydrata require my model to be in a specific format?¶

For ANUGA, Hydrata accepts the standard ANUGA project structure (scenario.json plus referenced inputs). For HEC-RAS, Hydrata accepts a HEC-RAS .zip exported from RAS Mapper, including the project file, plan file, geometry file, and any referenced inputs. Other engine ingests (SWMM, InfoWorks, MIKE+) are added on request.

What happens if my model fails verification?¶

Each failed check is logged with the diagnostic value, the recommended fix, and a reference to the relevant section of this checklist. The consultant remains the model-of-record; Hydrata's role is to identify defensible issues before the model reaches a reviewer.

Is Hydrata a substitute for professional engineering review?¶

No. Hydrata's verification is automated and advisory. A licensed engineer remains responsible for the model and the submission. Hydrata reduces the workload of the engineering review by surfacing the issues a reviewer is likely to raise.

Can I use Hydrata as an internal QA tool before sending the model to a regulator?¶

Yes. The most common use case is internal QA: a consultant runs the model through Hydrata as the last step before submitting to a third-party reviewer or regulator. The signed advisory report accompanies the submission as evidence of pre-review verification.

Does Hydrata verify HEC-RAS 1D models, or only 2D?¶

Hydrata's verification today targets 2D models in HEC-RAS and ANUGA. HEC-RAS 1D verification is on the roadmap; the underlying mass balance and parameter audit checks are engine-agnostic, but the 1D-specific items (cross-section spacing, contraction/expansion coefficients, ineffective flow areas) require 1D-aware implementations.

How do I get a verification report run?¶

Free tier: one verification report per month, no credit card required, on any ANUGA or HEC-RAS 2D model under 500,000 mesh cells. Sign up at hydrata.com and upload your project, or book a 20-minute walk-through with the team.