Flood forecasting and early warning systems
Operational chains that run on a schedule, and warnings somebody acts on
A forecast system is mostly plumbing, and plumbing is where forecasts fail. We build the whole chain — acquisition, quality control, interpolation, execution, post-processing, thresholds, delivery — with every stage logged and independently re-runnable.
Forcing, checked on arrival
Gridded fields from GFS, ECMWF, or ERA5, or a parametric vortex built from best-track input. Every cycle is validated when it lands rather than when it fails downstream.
One interpolation path
Forcing is mapped onto the model mesh by the same code every cycle. Ad-hoc regridding between runs is how a forecast quietly stops being comparable to itself.
Execution with failure isolation
Deterministic or ensemble, on HPC or cloud, with restart handling. A stage that fails fails alone, and can be re-run without repeating the cycle.
Products as files, not screenshots
Water level, depth, and exceedance products are generated as data on a defined grid, so downstream systems can consume them without a human in the loop.
Thresholds tied to consequences
A warning level is only meaningful if it corresponds to something real — a road that closes, a first-floor elevation, a substation that goes offline. Thresholds are set against the consequence, with hysteresis so a warning does not flicker on and off.
Delivery, with a heartbeat
A feed, dashboard, or file drop on a schedule, with escalation paths and formats for operators who are not modelers — and a signal when nothing arrives, because a silent forecast system looks identical to a working one.
Scored before it goes live
Hindcast replay over past events, so both the forecast and the trigger logic have a measured record — skill, hit rate, false alarm rate, lead time — before anyone relies on them.
- Deployed chain with scheduling and monitoring
- Threshold catalogue with the rationale for each value, and the escalation logic
- Runbook covering normal operation and every known failure mode
- Back-test: skill, hits, misses, false alarms, and the lead time distribution
- Lead time is bounded by the meteorology, not by the hydrodynamics. A better surge model does not buy you more warning.
- Ensemble spread is a measure of disagreement between members, not a probability. Treating it as one overstates what the system knows.
- A chain validated on tropical events is not automatically valid for extratropical or rainfall-driven ones.
- Every threshold trades false alarms against missed events. There is no setting that avoids both, so the balance has to be chosen deliberately and written down.