Less is Flow: How Sparse Sensing Rethinks Urban Flood Monitoring

A city drainage engineer rarely gets to choose between perfect data and bad data. The real choice is more annoying: a few sensors in the right places, a few sensors in the wrong places, or a procurement request large enough to frighten everyone in finance.

Urban flood monitoring has always had this observability problem. Storm sewers are spatial systems. Water does not politely report its location from one convenient manhole. It moves through a network of subcatchments, conduits, junctions, slopes, storage, bottlenecks, and hydraulic thresholds. Full visibility would mean dense instrumentation across the network. That is expensive to install, maintain, power, calibrate, secure, and occasionally rescue from the weather doing exactly what it was installed to measure.

The paper behind this article asks a more disciplined question: can a drainage network be monitored by measuring only a small number of carefully chosen points, then reconstructing the wider system state from those sparse measurements?¹

The answer, in one Duluth, Minnesota catchment, is surprisingly strong. Three strategically selected sensors among 77 candidate nodes achieved a mean system-level Nash-Sutcliffe Efficiency, or NSE, of 0.949 across five observed storm events. Ten sensors raised system-level performance to 0.993. The method also stayed close to exhaustive-search optima for small sensor counts and substantially outperformed random sensor placement.

That is the headline. It is also where the nonsense can begin if we are not careful.

This paper does not prove that three sensors can predict city-wide flooding anywhere. It does not field-validate a universal flood-warning product. It reconstructs simulated full-network flow states in one storm sewer catchment using a digital-twin-based sparse sensing pipeline. That distinction is not academic fussiness. It is the difference between an infrastructure strategy and a brochure with equations on it.

The trick is not fewer sensors. The trick is finding the network’s hydraulic grammar

Sparse sensing works only when the thing being monitored has structure. Urban drainage flow is chaotic enough to ruin weekends, but not so random that every node behaves independently. Stormwater networks have repeated patterns: upstream runoff pulses, downstream aggregation, timing delays, peak-flow propagation, recession behaviour, and recurring relationships between locations.

The authors exploit that structure through a data-driven sparse sensing, or DSS, pipeline. The mechanism has three main parts.

First, they use EPA-SWMM, a standard stormwater modelling tool, to generate a large training ensemble of network flow behaviour. The case study is the Woodland catchment in Duluth, covering 133.53 hectares, with 48 subcatchments, 130 conduits, and 77 nodes. The training ensemble combines 10 rainfall events with 25 hydrologic parameter settings: five synthetic design storms, five observed storms, five imperviousness levels, and five Horton minimum infiltration rates. That gives 250 simulated scenarios.

Second, they apply Singular Value Decomposition, or SVD, to the simulated spatiotemporal flow matrix. SVD is doing the compression work. It identifies dominant modes of variation: the main ways the drainage system tends to move from one hydraulic state to another. Instead of treating 77 node time series as 77 unrelated signals, the method looks for a lower-dimensional basis that captures the important shared dynamics.

Third, they use QR factorization with column pivoting to select sensor locations. This is the placement step. Once SVD identifies the dominant basis, QR asks which physical nodes best sample that basis. In plain English: if you can only listen to a few points in the sewer network, which points tell you the most about the whole performance?

The operational loop looks like this:

SWMM scenario ensemble
        ↓
Full 77-node flow matrix
        ↓
SVD: dominant hydraulic modes
        ↓
QR pivoting: most informative nodes
        ↓
Sparse sensor readings
        ↓
Reconstructed full-network flow state

This is why the result is more interesting than “three sensors good”. The paper is not merely reducing hardware. It is replacing brute-force measurement with a learned representation of hydraulic behaviour. That is a much better sentence, though admittedly harder to sell at a budget meeting.

The Duluth experiment tests reconstruction, not omniscience

The validation design matters because this is where the result earns its seriousness.

The authors train the DSS basis using the simulation ensemble, then test reconstruction on six events excluded from basis construction: five observed storm events and one separate 200-year design storm. Performance is measured using NSE, where values closer to 1 indicate closer agreement between reconstructed flows and SWMM-simulated flows.

At the system level, performance improves steadily as more sensors are added. Across the five observed rainfall events, mean system-level NSE rises from 0.896 with one sensor to 0.993 with ten sensors. With three sensors, the paper reports mean system-level NSE of 0.949. By five sensors, performance becomes nearly stationary above 0.982, meaning additional sensors mainly refine an already strong reconstruction.

The 200-year design event is harder under very sparse monitoring. Its system-level NSE starts at 0.842 with one sensor and reaches 0.994 with ten. That is important because extreme events are exactly where monitoring systems tend to reveal whether they are resilient or decorative. The DSS-selected sensors still recover the system-wide response once a small number of informative locations are included, but the paper does not pretend that one sensor is enough for every hydraulic mood swing.

The hydrograph comparisons sharpen the interpretation. Adding sensors is not merely gaming a summary metric. It improves peak-flow capture, timing, and event volume. For the June 11, 2024 event, increasing the sensor count from one to ten reduces peak-flow error from 10.92% to 2.14%. For the 200-year design event, peak-flow error drops from 27.14% to 0.18%, with time-to-peak errors eliminated.

That is not a minor operational detail. Flood response cares about timing and peaks, not just pretty aggregate fit. A reconstruction method that gets the general shape right but misses the peak can still be operationally rude.

System-level success can hide local bruises

The paper’s most useful discipline is that it does not stop at system-level performance. It also examines node-level reconstruction.

This is where the story becomes more realistic. Node-level performance generally improves as sensor count increases, but it is less uniform than the system-level metric suggests. For observed events, the median node-level NSE rises from 0.717 at one sensor to 0.960 at six sensors, then sits at a still-high 0.900 at ten sensors. For the 200-year design event, the median rises from 0.526 at one sensor to 0.941 at six and 0.965 at ten.

Yet the lower tail matters. For observed events, 14.474% of nodes have NSE below 0.500 with one sensor. Oddly but revealingly, this share rises to 52.632% at four sensors before improving later. Even at ten sensors, 6.579% of nodes remain below 0.500 and 2.632% remain below zero.

That sounds awkward because it is. It tells us that a sensor placement designed for system-level reconstruction does not guarantee evenly good reconstruction at every node. Some locations are harder: especially those with threshold-driven behaviour, intermittent activation, or local hydraulic quirks that do not sit neatly inside a linear reduced basis.

For business interpretation, this is not a failure. It is a design warning. Sparse sensing can be excellent for system-level situational awareness while still needing special handling for critical local assets: overflow nodes, high-risk underpasses, hospital-adjacent drainage points, industrial discharge interfaces, or any site where being locally wrong is expensive.

A useful deployment would therefore separate two objectives:

The attractive sentence is “monitor the network with fewer sensors.” The more accurate sentence is “use sparse sensors to reconstruct dominant system behaviour, then instrument local exceptions deliberately.” Less catchy. More useful.

QR placement is not just random thrift with better branding

The paper benchmarks the DSS-selected sensor sets against two alternatives: exhaustive search for one to four sensors, and Monte Carlo random placement for five to ten sensors.

For one to four sensors, exhaustive search can still enumerate all feasible combinations and identify the best possible set. DSS comes very close. The mean system-level NSE values for DSS are 0.887, 0.923, 0.954, and 0.967 for one, two, three, and four sensors. The corresponding exhaustive optima are 0.890, 0.935, 0.955, and 0.973.

That gap is small. It matters because exhaustive search becomes combinatorially ugly as sensor count and network size grow. QR factorization is not just a clever mathematical accessory; it is a practical way to approximate high-quality placement without testing every possible sensor combination until the procurement cycle ends or civilisation does.

For five to ten sensors, the authors compare DSS against 20,000 random configurations per sensor count. Random placement performs badly and inconsistently, with a heavy-tailed distribution and many configurations producing strongly negative system-level NSE. DSS remains consistently high-performing, with mean system-level NSE between 0.983 and 0.995.

This is the paper’s quiet business lesson: the savings do not come from buying fewer sensors. They come from not wasting the sensors you buy.

A three-sensor strategy chosen by QR from a trained basis is not equivalent to three sensors chosen by a committee, a map, a hunch, and the phrase “that manhole looks central”. Infrastructure does not reward vibes.

The robustness tests are where the deployment story gets less cute

The paper includes several tests that should be read as robustness and sensitivity checks, not as a second thesis. They ask whether the method survives the messy realities that arrive after the slide deck.

The noise result is encouraging. Under multiplicative Gaussian noise of 5%, 10%, and 15%, system-level reconstruction barely degrades. At one sensor, median NSE moves from 0.889 in the clean case to 0.887 at 15% noise. At six sensors, the median stays around 0.981 with very narrow variation.

Noise, however, is the easy villain. Real systems fail in ways that are less polite than Gaussian distributions. They clog. They drift. They go offline. Someone discovers that “weatherproof” was more of a brand aspiration.

The single-sensor dropout test is therefore more operationally interesting. At six sensors, removing some nodes has minor impact: dropping OF-04, 163, or 184 reduces mean system-level NSE by only 0.009, 0.038, and 0.007. But dropping OF-02, J297, or 96 reduces it by 0.358, 0.219, and 0.335. At ten sensors, most failures remain tolerable, but two sensors are still failure-critical: removing OF-02 and 94 causes delta NSE losses of 0.299 and 0.367.

More sensors improve fault tolerance on average. From two to six to ten sensors, the mean system-level NSE loss after a single dropout falls from 0.476 to 0.161 to 0.090. The median loss falls from 0.476 to 0.128 to 0.037. But the worst-case loss remains stubbornly large.

This is exactly the kind of nuance infrastructure buyers need. A sparse system can be cost-efficient and fragile at the same time if it places too much unique information on one critical node. The fix is not necessarily “install everything everywhere”. It is to design redundancy around the few sensors whose failure would collapse observability.

The paper’s post-hoc dropout analysis helps explain why some sensors are more failure-critical than others. QR selection order alone explains little of the observed dropout-loss variability, with adjusted $R^2$ of 0.159. When the authors add relative projection residual, condition number, and maximum modal loading, adjusted $R^2$ rises to 0.694. The largest explanatory contribution comes from maximum modal loading, at 64%, followed by QR rank at 22%, condition number at 7%, and relative projection residual at 6%.

Translated: a sensor is dangerous to lose when it carries a strong role in the dominant hydraulic modes, is not easily replaced by the remaining sensors, and leaves the reconstruction problem numerically less stable. That is not a procurement footnote. That is how sparse monitoring becomes resilient instead of merely cheap.

The model uncertainty test says the idea is stable, not the exact map

The authors also test SWMM parameter uncertainty by creating nine perturbed model variants in addition to the baseline. They preserve the network topology but vary parameters such as subcatchment width, Horton infiltration parameters, conduit roughness, surface roughness, and depression storage. Then they regenerate the full training ensemble and rerun DSS.

The result is subtle. Reconstruction performance remains broadly robust, especially with larger sensor counts. At four, six, eight, and ten sensors, the reference model produces mean system-level NSE values of 0.925, 0.955, 0.960, and 0.974. The nine modified models produce corresponding averages of 0.908, 0.945, 0.962, and 0.974.

So the method does not appear to be an artefact of one convenient SWMM parameterization. Good.

But the optimal sensor locations vary. At six sensors, 67% of modified cases fall into the low-overlap category relative to the reference sensor set, with Jaccard overlap below 0.50. At eight sensors, overlap becomes more consistent, but not perfectly stable. At ten sensors, most cases are moderate-overlap, while 22% still show low overlap.

This is the deployment boundary in one sentence: the sparse sensing principle is more stable than the exact sensor placement.

For municipalities and vendors, that means model calibration is not clerical. If the digital twin is wrong in ways that matter, the QR-selected locations may shift. A city should not treat one uncalibrated model run as the final sensor blueprint and start drilling. It should use field measurements, temporary sensing campaigns, rainfall records, maintenance knowledge, and sensitivity analysis to decide whether the chosen nodes remain informative under plausible realities.

The paper itself is candid on this point. The SWMM model was not validated with field monitoring data because such data were not available. It had been used by local public agencies for design-phase hydraulic-load estimation, so it is physically grounded. But in this study it functions more as a scenario generator preserving network layout and routing behaviour than as a fully calibrated operational digital twin.

That is not a fatal weakness. It is the normal entry fee for digital-twin infrastructure. The twin must earn its job.

The business value is cheaper observability, not cheaper fantasy

For smart-city teams, utilities, engineering firms, insurers, and infrastructure technology vendors, the paper’s business relevance is straightforward but easily misquoted.

The direct result is not: “Install three sensors and solve flooding.”

The direct result is: “Given a physically grounded SWMM model of one 77-node storm sewer network, SVD plus QR selected sparse sensor configurations that reconstructed simulated full-network flow states with high system-level accuracy across held-out storm events and robustness checks.”

The Cognaptus inference is more useful: a city may be able to reduce monitoring capex and deployment complexity by using a calibrated drainage digital twin to identify high-information sensor locations, then reconstruct broader hydraulic states from limited live measurements.

That inference leads to a practical adoption sequence:

1. Build or update the hydraulic model.
2. Calibrate it with available field data, even if the campaign starts temporary.
3. Generate a scenario ensemble covering rainfall intensity, land-use assumptions, infiltration behaviour, and plausible infrastructure states.
4. Use SVD to identify dominant hydraulic modes.
5. Use QR pivoting to propose informative sensor locations.
6. Validate the selected locations against excluded events and, preferably, field measurements.
7. Add redundancy around failure-critical sensors.
8. Recompute placements as the network, climate assumptions, or asset conditions change.

The ROI case is not just fewer devices. It is fewer bad devices. Sparse sensing can reduce unnecessary coverage, shorten deployment timelines, and support better state estimation where full instrumentation is unrealistic. It can also help engineering teams decide where extra monitoring is genuinely worth it.

There is a commercial opening here for vendors building digital-twin platforms, sensor-network planning tools, and decision-support systems for municipal drainage. But the product should not be a shiny “AI flood monitor” dashboard with three dots and a subscription fee. The valuable product is a workflow: model generation, sparse placement, uncertainty testing, redundancy design, field validation, and operational integration.

Less glamorous. More billable.

Where this method stops

The paper’s boundaries materially affect practical interpretation.

First, the study relies on simulated flow data. Without long-term field measurements, errors in model structure, rainfall input, parameter calibration, or local hydraulic assumptions can propagate into both sensor placement and reconstruction.

Second, DSS is a linear reduced-order reconstruction framework. That is powerful when dominant system behaviour can be captured in a low-dimensional basis. It is weaker for strongly nonlinear, threshold-controlled nodes, such as overflows that remain inactive until intense rainfall triggers abrupt behaviour. Linear reconstruction can generate weak false flows or miss sudden activation at those nodes.

Third, the study focuses on flowrate. Real monitoring programmes often care about water level, water quality, sediment, pollutant transport, asset blockage, and operational control. Multi-variable sparse sensing is a different and harder design problem.

Fourth, the method reconstructs current or simulated network state. It is not, by itself, a forecasting model. The authors point toward future integration with LSTMs, physics-informed machine learning, and real-time control. That is plausible, but it remains future work.

Finally, the study is one catchment. Duluth’s Woodland catchment has specific topography, land cover, soil characteristics, and network structure. Transferability must be tested, not assumed. Infrastructure has a long history of humiliating universal claims. It enjoys the hobby.

Measure meaningfully, then automate carefully

The best reading of this paper is not that cities can become omniscient with three sensors. It is that full observability may be approximated when the network’s dominant dynamics are learned first and the sensors are placed to capture those dynamics.

That is a serious idea. It reframes monitoring from a hardware coverage problem into an information design problem. In a world of limited municipal budgets, ageing stormwater systems, and more volatile rainfall, that reframing matters.

The sparse sensing lesson is not “less is always more”. Less can be blind, brittle, and smug. The lesson is that fewer sensors can be enough when they are chosen by the structure of the system rather than by convenience, politics, or whichever manhole happens to have easy access.

Urban flood monitoring does not need theatrical omniscience. It needs calibrated models, informative measurements, redundancy where failure matters, and enough humility to know when reconstruction is not prediction.

Measure less, perhaps. But measure what carries the flow.

Cognaptus: Automate the Present, Incubate the Future.