A water network is not a drawing of pipes. It is pressure that shifts at six in the morning, a tank that drops overnight, and chlorine that decays while the water travels. In the 1990s the EPA needed a model that joined hydraulics and water quality in the same executable. That thread — not a catalogue of buttons — is the history of EPANET.
Why the EPA
The U.S. Environmental Protection Agency (EPA) needed to understand the transport and fate of substances in drinking-water distribution networks: residual chlorine, water age, source tracing, contamination. A pressure calculation alone is not enough. What was needed was Extended Period Simulation (EPS): hours or days, not a still photograph.
The central figure in the development was Lewis A. Rossman, an engineer and EPA researcher.
1991: before the name — QHCSIM
Before it was called EPANET there was an experimental prototype: QHCSIM (October 1991). Jim Uber documented it when announcing Rossman’s retirement: the name EPANET did not exist yet; the code already combined hydraulics and quality in a single executable — the mark that would later be EPANET. It was small (on the order of 1,500 lines) and fit on a floppy disk.
That precursor matters: EPANET did not start as a pretty window. It started as a simulation engine.
1993–1994: EPANET 1.x is born
EPA places the first public release around 1993–1994. The EPANET Users Manual (Version 1.1) is dated January 1994 (Rossman). It already ran extended hydraulic and quality simulation: flows, pressures, tank levels, concentration, water age, and source tracing (knowing which source supplies each zone).
The engine was written in C, designed to be portable. Simulations could run from an executable with a text file of the model. Hydraulics used the gradient algorithm; quality later moved from a finite-volume scheme to a Lagrangian approach in later generations.
Two layers of code: engine and screen
Engine in C
The core — the solver — lives in C. That is why it could later be packaged as a function library (DLL/API) and live inside other programs.
Windows graphical interface: Visual Basic, then Delphi
The first graphical interface (the program window on Windows) appeared in early 1993, under Windows 3.1, and was developed in Visual Basic. In that early version the network was not drawn on screen: the network was defined in an input file (.MAP). Later versions of that window were rewritten in Borland Delphi / Object Pascal, now with drawing and layout editing (the screen where you assemble the network). The old EPANET 2 interface code (EPANET2W) is still archived by EPA as a Delphi project; the 2.2-line interface is also maintained in Delphi.
Separating engine (C) and window (Visual Basic → Delphi) is part of the story: the solver could travel without dragging the whole screen along.
2000: EPANET 2 and the Toolkit
In 2000 Rossman published the EPANET 2 manual. That generation became the reference for years among utilities, consultants, universities, and developers.
The long-reach decision was the Programmer’s Toolkit: a function library (epanet2.dll) that other programs can call from C/C++, Visual Basic, Delphi/Pascal, or any other language that can talk to a Windows DLL.
That turned EPANET into an engine, not only “the EPA program”. A great deal of network software inherits formats, ideas, or the engine itself.
MSX: more than one chemical species
When a single species (chlorine, for example) is not enough, EPA published the EPANET-MSX extension (Multi-Species eXtension): multi-species reactions coupled to the hydraulic engine, also as an executable and as a function library (epanetmsx.dll) alongside the classic Toolkit. MSX does not replace EPANET: it extends it when network chemistry is the problem.
2014: Open Water Analytics (OWA)
After decades of evolution mainly inside EPA, around 2014 the Open Water Analytics (OWA) community took up the open stewardship of the engine: a community repository, issues, contributions. It does not erase EPA; it opens another development track.
The distinction always matters:
- Stable EPA — the official release EPA points to as the reference (today, in public practice, EPANET 2.2).
- OWA branch — the community line (e.g. 2.3.x), newer, not automatically “the EPA version”.
2020: EPANET 2.2 and Pressure-Driven Demand
In 2020 EPA officially published EPANET 2.2 (user manual and the USEPA/EPANET2.2 repository), with strong collaboration relative to the community work. Among the historically relevant additions is support for Pressure-Driven Demand (PDD) — demand that depends on pressure:
That matters in failures, fires, and deficient networks, where assuming that “demand is always delivered” is physically false. 2.2 also brought numerical and API improvements (the way another program calls the engine); the historical thread is: the official engine caught up, and EPA labelled it stable.
EPANET 3: experimental, in C++
EPANET 3 is not the official stable version. It is a development/research project at OWA (OpenWaterAnalytics/epanet-dev): an object-oriented reimplementation of the engine in C++. It is worth naming so the reader is not confused, and so it stays clear that it is experimental next to EPA 2.2.
What you can do with EPANET (use cases)
EPANET models pressurized distribution networks (drinking water / pressure networks): nodes, pipes, pumps, valves, tanks, reservoirs. It solves continuity and energy; it can track quality over time (EPS). Below is what a civil or sanitary engineer usually does with that engine — not an empty feature list, but office work.
Size or extend a network
Try diameters, see whether velocities and head losses make sense, and check whether an extension (a new neighbourhood, a new flow) leaves the existing network without pressure.
Nodal pressures
Ask what pressure each user will have at peak demand and in the off-peak valley. Catch slack-pressure or overpressure zones before buying pipe.
Pumps and tanks
Simulate pump curves, on/off schedules, tank filling and emptying, and how they interact with demand through the day.
Pumping energy
Compare operating strategies (which pump, at what hour) to cut energy use without breaking minimum pressures.
Water quality: chlorine, age, sources
Follow how chlorine decays as it travels, estimate water age at low-demand network ends, and run source tracing: which reservoir or well supplies each zone. Useful for disinfection, mixing of sources, and “old” zones.
Emergencies and contamination
Evaluate which part of the network would be affected if a contaminant enters, a pump fails, or a reach must be isolated. EPA also uses it in threat and resilience scenarios.
Fires
Check available hydrant flows and pressures while the rest of the network is still demanding. Here 2.2 PDD helps: if pressure drops, demand is not delivered “by magic”.
Leakage and deficient networks
Explore scenarios with lost flow or insufficient pressure. The model does not invent leaks on its own: you supply the hypothesis; the engine shows the hydraulic effect.
Calibration against real data
Compare the model with measured pressures, flows, tank levels, and operating data (SCADA). Adjust roughnesses, demands, and valves until the model resembles the real network.
Automation (Toolkit + scripts)
Call the engine from Python or another application: GIS → build the network → EPANET → optimize diameters or pump schedules → dashboard. The Toolkit is what makes that flow possible without rewriting the solver.
Short contrasts
EPANET vs HEC-RAS
EPANET: pressurized networks (drinking water). HEC-RAS: rivers, channels, floodplains. Both deal with “water”; they do not solve the same problem.
EPANET vs SWMM
EPANET: pressurized distribution. SWMM: urban drainage and sewerage (storm/sanitary), with surfaces and hydrologic processes. Complementary in a city; not interchangeable.
Short timeline
- ~1991 — QHCSIM (Rossman): hydraulics + quality, without the EPANET name.
- 1993–1994 — EPANET 1.x; manual 1.1 (Jan 1994); engine in C; first Windows window in Visual Basic.
- ~2000 — EPANET 2 + Programmer’s Toolkit; graphical interface in Delphi.
- MSX — multi-species extension on top of the engine.
- ~2014 — Open Water Analytics; community around the code.
- 2020 — EPA EPANET 2.2 (official stable, with PDD).
- OWA 2.3.x — community branch (distinct from stable EPA).
- EPANET 3 — experimental OWA in C++ (do not confuse with 2.2).
Conclusion
EPANET was not born to draw pretty networks. It was born because EPA needed to join pressure and quality over time, in a portable C engine, with a function library others could call. The graphical interface moved from Visual Basic to Delphi; the ecosystem added MSX, OWA, and later an experimental C++ track. For the civil engineer, the historical message is simple: when you model a water network, you are almost always talking to a lineage that starts in a 1991 prototype and is still alive — provided you know whether you are on EPA 2.2 or a community branch — and that engine is there to size, operate, calibrate, and think through emergencies, not only to “run an .inp”.
References
- U.S. EPA. EPANET.
- Rossman, L. A. EPANET Users Manual (Version 1.1), January 1994. NTIS.
- Rossman, L. A. EPANET 2 Users Manual, U.S. EPA, 2000.
- U.S. EPA. EPANET 2.2 (repository).
- U.S. EPA. EPANET-legacy-user-interface (Delphi EPANET2W interface).
- Open Water Analytics. EPANET (community branch).
- Open Water Analytics. epanet-dev (EPANET 3 / OO C++).
- Uber, J. / openepanet.org. Note on Lew Rossman’s retirement and QHCSIM (1991).
- Salomons, E. The creator of EPANET has retired (includes QHCSIM context).
- Riaño-Briceño et al. The EPANET Open Source Initiative (WDSA/CCWI; VB→Delphi interface, C engine).
- U.S. EPA. EPANET-MSX (multi-species extension; EPA/NEPIS manuals).
- EPANET Programmer’s Toolkit (DLL; C/C++, VB, Delphi). Historical Toolkit documentation.
Evaluation and limitations
Treat the notes below as evaluation context, not as a verified calculation or code check.
Treat it as an engine for pressurized networks. Know whether you are on EPA 2.2 or a community branch. Calibration remains the modeller’s responsibility.