
Ask a civil engineer to describe water network modeling and they will usually picture a pressurized supply network: pumps, tanks, demand nodes, pressure checks. Wastewater modeling looks superficially similar on screen — pipes, nodes, a network diagram — but the physics underneath, and the questions the model has to answer, are genuinely different. If you are coming to wastewater (sewer) network modeling from a water-supply background, several of your working assumptions need to be set aside before the model will tell you anything useful.
A pressurized water supply network is designed so pipes run full, driven by pump head and system pressure. Capacity is primarily a pressure question: can the network deliver enough flow at enough pressure to every demand point. A gravity sewer network is designed the opposite way. Bentley’s own product documentation for its sewer modeling tools is explicit about this: gravity pipes are meant to run partially full, sized so that flow moves by gravity down a slope rather than by pump pressure, while only forced mains (pumped sections) are expected to run completely full.
That single distinction changes almost everything about how you read a model’s output. In a pressurized network, a pipe running at less than capacity is often fine or even expected. In a gravity sewer, a pipe running too full, too often, is the early warning sign of a surcharge problem — sewage backing up toward manholes and, in the worst case, overflowing. The model isn’t just checking “can the pipe carry the flow,” it’s checking how full the pipe gets under a range of conditions, and whether that leaves room for storm-driven surges.
Pressurized water networks don’t have an equivalent of infiltration and inflow (commonly shortened to I&I) — groundwater seeping into pipe joints, or stormwater entering through manhole covers and illegal connections, adding unplanned flow to a sewer network that was sized for wastewater alone. Wastewater modeling tools like Bentley’s SewerGEMS build infiltration directly into the model as a first-class input, not an afterthought. The software’s help documentation describes several ways engineers can specify it along a pipe run: by pipe length, by contributing area, by a combination of diameter and length, by a fixed count of contributing units, or as a time-varying hydrograph or pattern load. The first four are constant-rate approximations; the last two let infiltration and inflow vary over a simulated storm event, which matters because I&I is rarely steady — it spikes during and after rain, sometimes for days.
Bentley’s own sewer-overview material frames this plainly: excess infiltration and inflow reduces a sewer system’s real capacity, drives up treatment costs at the downstream plant (because the treatment works now has to process extra flow that isn’t actually sewage), and in the worst cases, contributes directly to overflows. A model that ignores I&I, or treats it as a rounding error, will systematically understate how close a network is to its real operating limit — particularly in older networks with aging pipe joints, which describes a meaningful share of sewer infrastructure anywhere in the world, UAE networks included as the city’s built environment ages past its first few decades.
Water supply models typically solve for pressure and flow across a looped, pressurized network using methods built around that assumption. Gravity sewer networks need a different mathematical approach, because flow depth and flow velocity in a partially-full pipe behave differently from flow in a pressurized pipe. Bentley’s technical material on this describes support for multiple solver types for gravity networks, including convex and gradually varied flow (GVF) solvers, and notes that the GVF-convex approach is generally suited to new collection-system design work, especially where pumping stations or pressure sewers are mixed into an otherwise gravity-driven network — a very common real-world configuration where low points force a lift station before the flow can continue downhill.
For a civil engineer new to this, the practical takeaway is simple: don’t assume your water-network modeling intuition transfers directly. The inputs look similar on the screen (pipes, nodes, diameters, slopes) but the solver underneath is answering a different physical question, and the model needs to be set up — and read — with that difference in mind.
In practice, a usable wastewater network model answers three or four recurring questions on almost every real project:
| Aspect | Pressurized Water Supply Model | Gravity Wastewater Model |
|---|---|---|
| Driving force | Pump head / system pressure | Gravity / pipe slope |
| Normal pipe fill condition | Full | Partially full (by design) |
| Key failure mode | Insufficient pressure/flow at demand point | Surcharge / overflow at manhole |
| Unique input variable | Demand pattern | Infiltration & inflow (I&I) |
| Typical solver type | Pressure-flow network solver | Convex / gradually varied flow (GVF) |
Water-supply modeling and wastewater modeling are sometimes treated as a single “hydraulic modeling” skill set on a CV, and in a narrow technical sense they are related: both use network modeling software, both require an understanding of pipe hydraulics, and both reward the same underlying rigor. But an employer staffing a wastewater master-planning project, or a design-build contractor tendering for a sewer upgrade, is specifically looking for someone who understands gravity-flow design, surcharge risk, and I&I — not just someone who has used hydraulic modeling software in a different context. Being explicit, in an interview or on a CV, about having modeled gravity sewer networks specifically (not just “hydraulic modeling” generally) signals a level of specificity that stands out.
This is precisely the gap Bentley OpenFlows training in Dubai is built to close: moving from “I understand hydraulic modeling in general” to “I can set up and interpret a gravity sewer network model, including I&I and surcharge analysis, specifically.” Orbit Training Centre’s hands-on approach walks through exactly this distinction in a classroom setting, not just a software-features tour, because the distinction between pressurized and gravity-flow thinking is the part that trips up engineers moving between water and wastewater specializations.
For someone opening a wastewater model for the first time, a sensible first pass looks like this: confirm every pipe’s slope and invert elevations are correctly entered (a single wrong invert elevation can make an otherwise correct model produce nonsense results, because the whole gravity-flow calculation depends on elevation differences); check that infiltration has been assigned somewhere, even as a simple constant-rate estimate, rather than left at zero by default; run the dry-weather baseline first and sanity-check it against rough manual estimates before adding complexity; then layer in a design storm and watch specifically for manholes where the model reports the pipe filling beyond its safe depth.
This sequence — baseline first, complexity added deliberately, surcharge checked explicitly — is the difference between a model that produces numbers and a model that produces a defensible engineering answer. It is also, not coincidentally, the sequence most design-review checklists and most experienced reviewers will look for when they check someone else’s model before it goes into a submission.
Imagine a model returns a warning at a single manhole partway down a collector line: the pipe is predicted to run at 95% of its depth during the design storm, just short of the surcharge threshold the reviewer has flagged. A beginner’s instinct is often to treat this as a pass — it’s under 100%, so the pipe isn’t surcharging. That instinct misses two things an experienced reviewer would check immediately. First, 95% during the design storm leaves almost no margin for anything the model didn’t capture precisely: a slightly conservative infiltration estimate that turns out to be optimistic, a storm that runs a notch more intense than the design event, or future development upstream adding flow the model didn’t account for. Second, and more specifically, the question isn’t just “does this one pipe surcharge” but “what happens immediately upstream and downstream of it if it does.” A pipe running at 95% capacity at one manhole often means the pipe immediately upstream is effectively being throttled by it, which can mask a worse problem one or two manholes further up the line that the model will only reveal if every node along the run is checked individually rather than skimming for outright failures.
The practical habit this points to: treat anything above roughly 80-85% of design capacity as worth a second look, not just outright surcharge warnings, and always trace at least one manhole upstream and downstream of any flagged node before concluding the model is telling a complete story.
In practice, a wastewater model built for a UAE infrastructure submission rarely stays purely technical — it has to produce outputs an authority reviewer can check against submission requirements, which typically means clearly presented capacity results at every manhole under both dry-weather and design-storm conditions, explicit documentation of the infiltration assumptions used and why, and pump station performance curves presented alongside the predicted operating point rather than just the pump’s generic rated capacity. Building the model with this end submission in mind from the start — rather than treating documentation as an afterthought once the modeling itself is “done” — saves significant rework when a reviewer inevitably asks for the assumptions behind a specific result.
A wastewater model built purely from design assumptions — theoretical population-based flow estimates, textbook infiltration percentages — is a reasonable starting point for a brand-new network with no operating history, but for an existing network being modeled for an upgrade or capacity study, calibrating the model against actual measured flow data is a meaningfully more defensible approach. This typically means installing temporary flow monitors at key points in the network for a period that spans both dry weather and at least one real rain event, then adjusting the model’s infiltration and demand assumptions until its predicted flows match what the monitors actually recorded. A model calibrated this way carries far more weight with an authority reviewer than one built purely on design-standard assumptions, because it demonstrates the model reflects how the specific network actually behaves, not just how a generic network of similar size is assumed to behave.
This calibration step is also where a lot of the “where did I go wrong” learning happens for someone newer to wastewater modeling: discovering that a section of pipe assumed to have minimal infiltration is actually contributing a large share of wet-weather flow, based on real monitored data, is a far more concrete lesson than any amount of reading about infiltration in the abstract. It’s also, practically speaking, the step that separates a model built to satisfy a submission checklist from a model that will still be trusted and used years later for operational decisions on that same network.
Not inherently harder, but different enough that prior water-supply modeling experience doesn’t transfer automatically. The core new concepts — partial pipe fill as the design intent, infiltration and inflow as an active input, and surcharge as the primary failure mode to check for — take deliberate practice to internalize, even for someone already comfortable with pressurized network modeling.
Treating infiltration and inflow as a minor adjustment rather than a variable that can determine whether the network passes or fails under wet-weather conditions. A model that looks fine under dry-weather flow can surcharge badly once a realistic storm-driven I&I load is added, and skipping that step gives a false sense of adequate capacity.
Infiltration and inflow is primarily a function of pipe age, joint condition, and groundwater/surface-water exposure rather than climate alone, so it varies by network and area rather than being uniformly high or low across the UAE. Newer networks with well-sealed modern pipe joints generally see less I&I than older infrastructure, which is one reason condition assessment matters alongside the hydraulic model itself.
Bentley’s OpenFlows product family covers both, with separate dedicated modules (commonly associated with WaterGEMS-style functionality for pressurized water networks and SewerGEMS-style functionality for gravity wastewater networks) built around the different solvers each flow type needs, rather than forcing one generic tool to handle both.
There’s no universally correct order — it depends on which roles are realistically available and which skill a target employer is hiring for. Many civil engineers learn pressurized water modeling first because it’s conceptually closer to general hydraulics coursework, then add wastewater/gravity-flow modeling once they have a specific project or role that calls for it. A structured course that covers both, rather than assuming prior exposure to one, removes the guesswork about which to tackle first.


