Flood forecasting with neural networks: a 2018 White Oak Bayou case study

I built a neural-network forecasting system for Houston’s White Oak Bayou watershed and documented the original TensorFlow/LSTM work in September 2018. The study used 154,868 data points from 2015 to 2018 across 14 HCFCD gauges. My later presentation records calibration on 44 storm events and a separate Imelda comparison.

The original report was published on October 1, 2018. It includes the forecasting problem, model-output plots, and a working modeling dashboard. Imelda occurred in September 2019, so the Imelda results below belong to the later testing.

On unseen storms, my one-hour-ahead elevation predictions had a peak difference of 1.31 feet. At timing, my ANN’s peak difference was 0.72 feet. The other models were measured at timing, with peak differences of 1.12 feet for HCFCD Gauge, 1.95 feet for NWS MRMS Radar, and 1.08 feet for Vieux GARR. My forward prediction was in the same range; my at-timing result had the smallest peak difference in that comparison.

The unadjusted Imelda result was a one-hour-ahead forecast: 9 of 13 gauges, 69%, were within 2 feet of the observed water level. The network issued a prediction for a future target using the information available at issue time. After timing adjustment, the gauge comparison reached 12 of 13, or 92%.

A forecast needs an issue time and a valid time

The issue time is when a prediction is made. The valid time is when its predicted value applies. Those two timestamps define what information the model could have known and how far ahead it is trying to predict.

That distinction is easy to lose when evaluating historical data. A rainfall observation may be available in an archive today but may not have arrived when a forecast would have been issued. Feeding it into a historical replay can make a model appear more capable than the live system would have been.

The original report uses an LSTM, a recurrent neural-network family suited to sequence modeling, and explores several forecast horizons. It also examines scenarios involving user-specified rainfall. A scenario answers what the model produces under an assumed input; it should be interpreted separately from a forecast evaluated against independently observed conditions.

Hold out the event that matters

The 2018 report describes setting aside the Tax Day flood event for validation and testing. That is a more meaningful unit of separation than treating every overlapping time window as independent.

Adjacent windows from the same storm share much of their information. If those windows are mixed across training and evaluation, the model may be tested on something very close to what it already saw. A storm-level split asks a harder question: how does the model behave on a distinct event?

I keep the event split, model identity, and input-availability conditions with the results. Those records make the held-out test traceable.

There is more than one way to be wrong

A hydrograph is a water-level curve over time. Two predictions can have similar average error while creating very different operational consequences. One might underestimate the peak. Another might predict the right level too late.

A simple persistence baseline predicts that the current level remains unchanged. It is a useful reference for checking whether a more complex model adds value at a particular horizon. The comparison must use the same observations and eligible forecast cases; otherwise an apparent improvement can come from a different test population.

Connecting the forecast to an operating decision

A river or bayou gauge measures a specific quantity at a specific location. Connecting that measurement to a road, property, or warning threshold requires additional evidence. A channel elevation and a roadway elevation need compatible references before they can be compared.

Road-level decisions also depend on local drainage, observation freshness, and the physical connection between a gauge and the road.

Those constraints are part of engineering a platform. Data acquisition, freshness checks, model execution, operator inspection, and delivery each contribute to whether a forecast becomes useful information. The 2018 report's dashboard is evidence that the work extended to a software interface around the model.

What the testing showed.

The network was tested the hard way: on storms it never trained on. The unseen-storm system-wide summary records a 1.31-foot peak-elevation difference for my one-hour-ahead prediction and 0.72 feet at timing. The comparison models’ at-timing peak differences ranged from 1.08 to 1.95 feet. Predictions returned in milliseconds.

The slide reports my ANN’s peak difference as 1.31/0.72 feet. The first value is my forecast one hour ahead; the second is my elevation result at timing. The other systems’ values are at timing. These are elevation differences measured in feet.

The separate gauge-within-two-feet result

For the Imelda gauge comparison, my unadjusted one-hour-ahead forecasts put 9 of 13 gauges, 69%, within 2 feet of observed levels. Timing adjustment brought that count to 12 of 13, 92%. These percentages count gauges meeting a two-foot tolerance. On Tropical Storm Imelda, I also reported water-level timing within ±15 minutes at 85% confidence.

One hour of forward prediction

In the operating comparison I made, the reference hydrographs stopped at the latest available data. Their future interval was empty while my network produced a water-level forecast one hour ahead. An empty curve means no forecast was supplied for that interval, rather than a prediction of zero water level.

That is the practical distinction behind the 69% figure: a forecast was available, and 9 of 13 gauges were within 2 feet of what was observed an hour later. The reference scores in my presentation describe the comparison traces, rather than matching one-hour-ahead forecast scores.

I built this with data from White Oak Bayou, one watershed. The comparison systems had countywide gauge coverage available. The input footprints were different, and the 69% forward result came from the smaller watershed-specific input set.

Speed is the practical edge. A new storm calibrates in 30 minutes; a full retrain on new weights takes about 2 hours. The original study used 154,868 data points across 14 HCFCD gauges from 2015 to 2018, including the Memorial Day, Tax Day, and Harvey events, with the Tax Day flood held out entirely as the test set.

My Flood-Prediction-Network repository contains the public code and original report. The 2018 report documents 26 events in the source data; the later presentation records 44 storm calibrations.

The counts and percentages come from my later presentation. I have added the scoring basis to make the one-hour forecast horizon explicit. The presentation describes the separate Imelda timing result as “up to 30min ±15min predictions with 85% confidence.”

I bring the same engineering practice to AI-agent implementation: connect the available data, define the decision, record the result, and make it useful to the person acting on it.

Scope, stated plainly. This is a watershed-specific model on a 2018 stack (TensorFlow, LSTM), not a statewide product. But the results are measured, not hypothetical, and the code and report are public.

Inspect the evidence

• The October 2018 public commit contains the report dated September 23, 2018.
• The original lab report documents the experiment and dashboard.
• My later Predicting Floods With Machine Learning presentation, slides 13–16, records the calibration speed, Imelda timing, gauge counts, and unseen-storm peak-elevation differences reproduced above. The one-hour scoring horizon, interpretation of the ANN’s 1.31/0.72-foot pair, reference-curve availability, and countywide-versus-watershed input context are my firsthand account of that comparison.
• The National Weather Service’s Imelda account dates Tropical Storm Imelda to September 2019.

Explore AI-Rey services · Book a free fit call