The hydroEngine.
The differentiable simulation engine inside the platform — water and sewer.
HydroDSS is a cloud-native modelling platform; the hydroEngine is its structural differentiator. Built from scratch to be differentiable end-to-end and GPU-capable, it matches EPANET 2.3.5 on the benchmark corpus, reads and writes EPANET .inp files losslessly, and has landed a native transient (water-hammer) solver. The same differentiable platform is being extended to drainage: a SWMM-class sewer and stormwater engine — runoff, infiltration, groundwater — is in active development, with gradient support built in from the start. Because it is differentiable, calibration and design optimisation become gradient-based — the slow, manual loop becomes a solve. It is validated as a component and is productizing into the platform; the platform's runs use the EPA EPANET and SWMM engines for now.
EPANET and SWMM are excellent. They're also built for the desktop.
EPANET and SWMM remain the reference tools for water-distribution and drainage analysis, and they are the oracles we hold ourselves to — every hydroEngine result is checked against them. But as engines for a cloud platform built around differentiable calibration, GPU acceleration, transient coupling, and ensemble uncertainty, a few things are missing:
Differentiability
Neither EPANET nor SWMM has automatic differentiation, so calibration — roughness, demand, and leakage on the water side; runoff, infiltration, and storage on the drainage side — is forced into black-box optimisation. The hydroEngine is differentiable end-to-end: calibration and leak localisation become gradient-based, far faster, with quantified sensitivity.
One engine, two domains
Water distribution and drainage normally mean two separate desktop tools with separate schemas. The hydroEngine is one platform — shared kernels, one time-stepper abstraction, one gradient system — with an EPANET-class water line and a SWMM-class drainage line as solver families, not forks.
GPU acceleration
Single-thread CPU is the only path in both reference engines. The hydroEngine runs the same code on CPU and GPU and carries an ensemble batch dimension, so large extended-period, design-storm, and uncertainty runs vectorise instead of looping.
Transient in the same platform
Water hammer normally means a separate desktop tool with separate inputs. HydroDSS delivers transient and surge analysis live today via TSNet — the trusted method-of-characteristics solver — in the cloud, on the same model. The engine's own native water-hammer solver has landed in the lab, unifying steady, extended-period, and transient under one time-stepper.
Pressure-driven demand by default
EPANET defaults to demand-driven analysis; pressure-driven demand is bolted on, which is physically wrong in the low-pressure regimes that matter most. The hydroEngine reverses the default — PDA is standard, DDA remains available but opt-in.
Ensemble uncertainty as a first-class operation
Monte Carlo and ensemble propagation in EPANET or SWMM need bolt-on infrastructure. The hydroEngine carries an ensemble batch dimension from commit one — uncertainty is a vectorised operation for both domains, not a wrapper.
Six commitments locked in commit one.
Every architectural choice is documented and versioned. The list is short on purpose — engineering investment compounds when commitments don't churn.
- 1
Architectural completeness from day one
Full schema, full time-stepper abstraction, full ensemble batch dimension, full capability-flag system from commit one. Releases fill in physics underneath; the architecture doesn't churn.
- 2
Lossless model round-trip
Reads EPANET .inp files and writes them back byte-identical (modulo whitespace); the drainage line carries the same commitment for the SWMM .inp dialect. Migration is reversible — a utility can move its model into the platform without rewriting it, and take it back out.
- 3
Parity gates against the reference engines
Every water-side release reproduces EPANET 2.3.5 within 0.1% on the benchmark corpus — steady-state and 24-hour extended-period across Hanoi, Net1, Net3, and Anytown — and the drainage line is held to EPA SWMM as its parity oracle the same way. The parity harness runs on every change; a physics improvement that genuinely shifts results requires a documented amendment and a re-pin, never a silent deviation.
- 4
Auto-diff at non-smooth physics
Valve hysteresis, pump trips, and switching controls are handled by custom vector-Jacobian products with smoothed surrogates on the gradient path. Real engineering hardware, defensibly differentiated.
- 5
Pressure-driven demand as the default
Demand drops when pressure drops, the way real networks behave. Demand-driven analysis remains available for legacy parity but is no longer the default.
- 6
Reproducibility is the build status
Three consecutive runs under fresh processes produce identical results on a fixed environment. Reproducibility isn't a release gate — it's the engine's resting state, because calibration drift cascades into every downstream decision.
A modern engine, held to known standards.
The hydroEngine reproduces EPANET 2.3.5 to within 0.1% on the benchmark corpus, and the drainage line is held to EPA SWMM as its parity oracle the same way — it matches the trusted, free reference engines on the cases everyone agrees on, so a utility can move a model in and check the numbers themselves. It doesn't claim to out-physics the desktop incumbents on 2D fidelity; the advantage we're investing in is differentiable network hydraulics in the cloud — across both the water and drainage domains.
Lossless .inp round-trip is built into the engine, and the platform already imports GIS formats (Esri shapefile, GeoPackage, GeoJSON) with two- and three-point georeferencing — migration into the platform, not a plug-in that leaves your model on the desktop. Coming from another desktop modelling tool? Talk to us at [email protected].
Parity, differentiability, transients — and now drainage.
The capability surface exists in stub form from commit one; each release lands real physics behind a function that always existed. Steady-state and extended-period parity are validated across the Tier-A corpus, and the engine is differentiable end-to-end — gradient-based calibration recovers roughness, demand, and leaks within tolerance. The native transient solve has landed and is working toward its validation gate, water quality is in progress, and the SWMM-class drainage line is under active development on the same platform.
| Release | Capability | Status |
|---|---|---|
| v0.1 | Steady-state EPANET parity (Hanoi) | Validated |
| v0.2 | Extended-period simulation + SIMPLE/RULES controls + full Tier-A corpus parity (steady + 24h EPS) | Validated |
| v0.3 | Differentiable end-to-end — gradient calibration (roughness · demand · leak) + leak localisation, on steady and EPS | Validated |
| v0.4 | Transients (water hammer) — the method-of-characteristics core, pump-trip and valve-closure boundaries, and the end-to-end solve have landed; column separation and the reference-validation gate are in progress | In development |
| v0.5 | Water quality — Lagrangian advection transport, first-order reaction kinetics (bulk · wall · tank), and water age | In development |
| SWMM | A sewer & stormwater solver family on the same differentiable platform — runoff hydrology, infiltration, and groundwater physics with gradient support built in from the start; EPA SWMM is the parity oracle | In development |
| v1.0 | Production hardening, native format, multi-GPU — productizing the engine into the HydroDSS platform | Planned |
No quarter pins on this table. We commit to architecture and to parity correctness — release timing depends on validation depth on real networks and parity-corpus expansion. Matching EPANET 2.3.5 is the floor, not a claim that it earns a regulator's trust on its own.