The hydroEngine.
The differentiable hydraulic solver inside the platform.
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 and reads and writes EPANET .inp files losslessly. 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 EPANET and SWMM workers for now.
EPANET is excellent. It's also built for the desktop.
EPANET remains the right tool for steady-state and extended-period analysis on the desktop, and it's the reference we hold ourselves to. As the engine for a cloud platform built around differentiable calibration, GPU acceleration, transient coupling, and ensemble uncertainty, a few things are missing:
Differentiability
EPANET has no automatic differentiation, so roughness, demand, and leakage calibration are forced into black-box optimisation. The hydroEngine is differentiable end-to-end — calibration and leak-localisation become gradient-based, far faster, with quantified sensitivity.
GPU acceleration
Single-thread CPU is the only EPANET path. The hydroEngine runs the same code on CPU and GPU and carries an ensemble batch dimension, so large extended-period 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 via TSNet — the trusted method-of-characteristics solver — in the cloud, on the same model (in development). Unifying steady, extended-period, and transient under the engine's own time-stepper is a longer-term aim.
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 need bolt-on infrastructure. The hydroEngine carries an ensemble batch dimension from commit one — uncertainty is a vectorised operation, 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 EPANET .inp round-trip
Reads EPANET .inp files and writes them back byte-identical (modulo whitespace). Migration is reversible — a utility can move its model into the platform without rewriting it, and take it back out.
- 3
0.1% parity gate against EPANET 2.3.5
Every 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. 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 solver, held to a known standard.
The hydroEngine reproduces EPANET 2.3.5 to within 0.1% on the benchmark corpus — that means it matches a trusted, free solver 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, transient fidelity, or water quality; the advantage we're investing in is differentiable distribution hydraulics in the cloud.
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. Import paths for InfoWorks ICM / WS Pro and InfoWater native models are the near-term target — migration into the platform, not a plug-in that leaves your model on the desktop.
Parity, then differentiability, now transients.
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 now differentiable end-to-end — gradient-based calibration recovers roughness, demand, and leaks within tolerance. Current work is v0.4: a native method-of-characteristics transient solver.
| 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) — method-of-characteristics core, pump-trip & valve-closure boundaries, column separation | 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.