When the Canals Are Full: A Digital Twin for Urban Drainage, and What Bangkok’s September 2026 Flood Shows About Why It Matters

September 27, 2026

On 26 September 2026, after almost 48 hours of rain and close to 300 mm in parts of the city, Bangkok declared all 50 of its districts flood-disaster zones. The city’s pumping stations were running flat out, moving about 1,200 cubic metres per second between them. The governor summed up the situation in one line: the problem is that the canals are full.

Our thoughts are with everyone still dealing with water in their homes, shops and streets. This post is about something that will matter after the water goes down: why a city with four giant drainage tunnels and more than 300 real-time monitoring points still flooded, and what kind of tool would help operators make better decisions the next time.

The short answer is that this was a network problem. The Nation reported the assessment of water engineer Chawalit Chantararat: the main cause was rainfall the local drainage system could not clear fast enough, not an overflow of the Chao Phraya. The river was still about 40 cm below its banks at two monitoring points. But canals close to bank level were restricting the flow of rainwater from roads into the drainage network, so water stayed on the streets.

That is a coupled system, and coupled systems are exactly what a digital twin is for.

1. Why "the canals are full" is a modelling problem

Bangkok’s Drainage and Sewerage Department describes the city’s risk as "three waters": runoff from the North, high tides, and rainfall — with rainfall now the biggest concern because of intense "rain bomb" storms. The same briefing, from June 2026, noted that the city had raised its rainfall drainage capacity from 60 to 80 mm per hour, has four large drainage tunnels in operation, and uses underground "water bank" tanks to absorb the first 15 minutes of heavy rain.

Those are real improvements. But a capacity figure in millimetres per hour describes one stage of a chain:

  1. Rain falls on streets and roofs and enters street inlets.
  2. Pipes carry it to canals.
  3. Canals carry it to pumping stations and tunnel intakes.
  4. Pumps and tunnels push it into the Chao Phraya.

Each stage only works as well as the next one lets it. When the canal is near bank level, the pipe that drains into it slows down. When the pipe backs up, the street inlet stops taking water. Pumps lift against a higher head and deliver less. A rise of a few tens of centimetres in one canal can change which streets flood and for how long — and 100–150 mm of rain a day, sustained over two days, is a test of storage and state, not just of peak hourly capacity.

No single dashboard number captures that. A model of the network does.

2. What a digital twin is — and what it isn’t

We wrote a general introduction to digital twins last year. For drainage, the useful definition is narrower. A drainage digital twin has three parts:

  • A model of the network. Catchments, pipes, canals, storage, pumps, gates and outfalls, with their real dimensions and capacities.
  • Live synchronisation. Sensor readings — canal levels, sump levels, rain gauges, radar, pump and gate status, river and tide level — continuously pull the model’s state towards what is actually happening.
  • Forward what-ifs from now. The ability to ask "what happens over the next two hours if…?" starting from the current state of the network, not from design assumptions.

That third part is the difference. A dashboard tells you the canal is at 2.1 m now. A design simulation tells you how the network behaves in a theoretical 1-in-10-year storm with everything working. A twin tells you what happens to this canal, starting at 2.1 m right now, if the next rain cell arrives in 40 minutes and pump 3 is still offline.

3. This has already been proven in Bangkok

This isn’t speculative. In a pilot for the Bangkok Metropolitan Administration funded by the UK government, Mott MacDonald built a real-time stormwater flood forecasting system for a 17 km² area of Wang Thonglang. They calibrated the city’s C-band rainfall radar, built a detailed hydraulic model of pipes, pump stations and canals, and then trained a machine-learning surrogate that reproduces the hydraulic model far faster: 41 rain events in 30 seconds, against 30 hours for the full model, with an average difference of about 20 mm. Observations refresh every five minutes and two-hour flood forecasts every ten.

The project also listed its own natural next steps, including integrating SCADA data for better operational control.

That is the gap we find most interesting — for the city, and even more for private sites that sit inside the city’s drainage system: industrial estates, factories, hospitals, data centres, logistics hubs. Knowing where water will be is the first half. The second half is: given what we know, what should we do with our pumps, gates and people in the next hour?

4. The architecture

flowchart TD
    A1["Canal and sump level sensors"] --> SY["State sync and quality checks"]
    A2["Rain gauges and radar nowcast"] --> SY
    A3["Pump and gate status from SCADA"] --> SY
    A4["River and tide level feeds"] --> SY
    SY --> M["Hydraulic network model SWMM"]
    M --> SR["Scenario runner"]
    SR --> SG["ML surrogate for fast answers"]
    M --> SG
    SR --> O1["Flood depth and timing forecast"]
    SG --> O1
    SR --> O2["Pump and gate recommendations"]
    O1 --> FS["Flood SOC alerting and cases"]
    O2 --> OP["Duty operator decides"]
    FS --> OP

State sync. Every few minutes, current sensor readings update the model’s starting conditions: canal and sump levels, which pumps are running, which gates are open, the river and tide level at the outfall. Readings pass a quality check first — a gauge that’s stuck, spiking or silent should not drive the model.

Hydraulic model. For the network engine, EPA SWMM is a natural fit: it’s open source and free, used worldwide, and explicitly simulates pumps, gates and weirs as well as backwater, surcharging and reverse flow — exactly the behaviour behind "the canals are full." PySWMM lets Python code step through a running simulation and change pump and gate settings along the way.

Scenario runner and surrogate. For a site-scale network, SWMM itself runs fast enough to test several scenarios per update. For city-scale networks, the Bangkok pilot shows the proven route: train an ML surrogate on many model runs and use it when seconds matter.

Outputs to people, not to pumps. Forecasts and recommendations go to the duty operator and into the same alerting and case workflow we described in Running Flood Response Like a SOC. The twin advises; a person decides.

5. What a what-if looks like in practice

Here is the core of a scenario runner, using PySWMM against a deliberately tiny model: one 20-hectare paved catchment draining into a sump, two pumps lifting water into a canal, and a storm peaking at 90 mm per hour. It replays the same storm under different conditions and reports the peak water level in the sump.

from pathlib import Path
from pyswmm import Simulation, Links, Nodes

BASE = Path("site.inp").read_text()

def run_scenario(canal_level_m=-0.5, failed_pumps=()):
    """Replay the same storm through the twin under one what-if condition."""
    inp = Path(f"scn_{canal_level_m}_{'-'.join(failed_pumps) or 'all'}.inp")
    inp.write_text(BASE.replace("CANALLEVEL  0:00  -0.5", f"CANALLEVEL  0:00  {canal_level_m}")
                       .replace("CANALLEVEL  12:00  -0.5", f"CANALLEVEL  12:00  {canal_level_m}"))
    peak = 0.0
    with Simulation(str(inp)) as sim:
        links, sump = Links(sim), Nodes(sim)["SUMP"]
        for _ in sim:
            for pid in failed_pumps:
                links[pid].target_setting = 0.0   # pump out of service
            peak = max(peak, sump.depth)
    return peak

Running four scenarios on this toy model gives:

Scenario Peak sump depth (sump full at 3.50 m)
Normal canal level, both pumps running 0.47 m
Normal canal level, one pump out of service 1.76 m
Canal near bank level, both pumps running 1.12 m
Canal near bank level, one pump out of service 2.38 m

This is a toy model built to illustrate the method, not a model of any real site. But the pattern is the one that matters. A high canal alone more than doubles the peak. A failed pump alone nearly quadruples it. Both together push the sump most of the way to full, because a pump lifting into a full canal delivers less water at exactly the moment you need more. In a real twin, the starting levels come from live sensors, and the same loop answers the operator’s question in minutes.

6. The questions a twin answers mid-storm

  • "If this pump trips now, which areas flood first, and when?" Ranked by depth and time, so crews go to the right place first.
  • "Should we pre-draw this canal before the next rain cell?" Pumping down ahead of a radar-nowcast storm buys storage — if the downstream system can take it.
  • "Is opening this gate worth it at this river and tide level?" The trade-off between relieving one area and loading another becomes a number, not a guess.
  • "Where do the mobile pumps go?" Test candidate locations against the forecast instead of dispatching to whoever called loudest.
  • "When will this street be dry?" "Two to three days if the rain stops" becomes a per-area recession estimate, which matters for businesses deciding when to reopen.

7. Why private sites need their own small twin

Most factories, estates and campuses have their own internal drains, sumps and pumps — and all of them discharge into the public canal network. When the canals are full, a site’s own pumps lose capacity at exactly the moment they’re needed, as the toy example shows.

A site-scale twin is small: tens of nodes, not tens of thousands. It needs the site’s drainage drawings, pump curves, a handful of level sensors, and the level of the canal it discharges into. It answers questions the city can’t answer for you: how long can we keep the line running if the canal stays at this level? Which building floods first if the big pump fails? Should we start moving stock now?

8. The hard parts, honestly

  • Drawings are often wrong. As-built drainage records are incomplete, and siltation, encroachment and rubbish change real capacity from what’s on paper. On 26 September, municipal crews in Bangkok were out clearing rubbish so street drains could keep working. Calibration against past events is how the model finds out.
  • A model is not the truth. It’s a tool for comparing options. Forecasts need ranges, and operators need to see how confident the model is.
  • Sensors fail when you need them. State sync must treat a silent or stuck gauge as a problem — the same silence-is-a-signal rule we use in a SOC.
  • Pump control is operational technology. We recommend advisory-only designs: the twin recommends, a person acts. Any connection to SCADA should be read-only by default and monitored like any other OT system.

9. What’s available today, what’s built per project, and what’s out of scope

Available today:

Built per engagement (there is no packaged "twin" product):

  • The SWMM network model, built and calibrated together with a hydraulic engineering partner.
  • State sync, sensor quality checks, the scenario runner and, where scale requires it, an ML surrogate.
  • Operator dashboards and the link into Flood SOC alerting.
  • Read-only SCADA integration, where the owner allows it.

Out of scope:

  • Certified hydraulic design and engineering sign-off. That belongs to licensed engineers.
  • Automatic control of pumps or gates. Our designs are advisory.
  • Official warnings, which remain with the BMA, the Department of Disaster Prevention and Mitigation and the Thai Meteorological Department.

FAQ

Is this a product we can buy?
No. It’s a reference architecture built from open-source tools (SWMM, PySWMM) and our integration work, delivered per site with a hydraulic engineering partner.

Isn’t this what the city already does?
The city runs its own monitoring and forecasting, and pilots like the Wang Thonglang project show what’s possible at city scale. A site twin complements that: it models your drains, your pumps and your decisions.

How accurate will it be?
Only as accurate as its data and calibration. That’s why the first phase is always calibration against past events — photos, water marks and level records — and why outputs come with ranges.

Can it control our pumps automatically?
We don’t recommend it. The twin recommends; your operator decides. Any SCADA connection starts read-only.

What does a first project look like?
One site, one question — for example, "what happens if our biggest pump fails while the canal is at bank level?" — answered with a calibrated site model and live sensor sync before expanding.

Talk to us

If this week’s flood reached your site, or came close, send us whatever you have: drainage drawings (even partial), your pump list, the canal you discharge into, and photos or water-level notes from this event. We’ll come back with a thin-slice plan for a site twin that answers the one question you most wish you could have answered on 26 September.

Email hello@simplico.net.


Sources:

Ready to talk about your project?

Share goals and constraints. We'll assemble architects and engineers to move fast with you.

Get in touch