Warren County Utility District serves around 34,000 people spread across seven Tennessee counties, through roughly 900 miles of pipe and 14,000 connections. It runs on a staff of about 65, and for most of its history the engineering behind the system came from outside: a contracted firm handles the studies, the designs, and any hydraulic analysis the district needed.
Wyatt Wilson is working to change that. A civil engineer covering GIS, asset management, and cost estimation, he is one of only two engineers on staff (the general manager is the district's PE). Over the past couple of years the district has been deliberately building engineering capability in-house, and a hydraulic model turned out to be one of the first big steps.
Diagnosing the flow routing problem
The push came from a specific problem. One area of the system is fed by three six-inch mains, and nobody was sure which route the water was actually taking. The obvious fix was to put flow meters on the lines, but even installed in-house, a meter runs $5,000 to $6,000. Multiply that across several lines and the idea was ruled out quickly.
Until then, questions like this went one of two ways: send them to the consultant, or reason it out from SCADA flows and tank levels and a good deal of assumption. "We didn't really have a tool like this to use," Wyatt says. What the district needed was a way to see the hydraulics between its sensors, without digging up roads to add more of them.
Wyatt remembered EPANET from a week-long stretch of a college hydraulics class, so that's what he Googled. He knew the classic desktop program would be a slog at their scale, with no practical way to bring in 900 miles of GIS data. Commercial modeling suites were never on the table; annual licenses can run to $10,000. Scrolling the search results, he spotted epanet-js, watched every short video and webinar he could find, and decided it looked like a fit.
Learning the software and building the model in a single day
Getting started did not require a training course or a budget line. It required a rainy day.
I picked a rainy day, opened it up, and played with it, watching the videos on one screen and the model on the other. After an eight-hour day of playing around, I felt like I knew everything I could do with it.
Two things made the model itself practical to build. The first was GIS import: the district's pipe network went straight into epanet-js instead of being redrawn by hand. "That would have been a nightmare," Wyatt says. The second was the satellite basemap. Laid over imagery and roads, a system spanning seven counties could be checked against the district's GIS piece by piece, rather than floating on a blank screen.
The network cleaning tools then caught the connectivity errors hiding in the data, and paid off beyond the model. "That was one of the best tools in there, in my opinion," Wyatt says. "We could see the connectivity problems in the model, and I was able to put it side by side with our GIS and fix them at the source. So when I need that data again, it's all connected."
Along the way, Wyatt leaned on short videos and ended up in a running conversation with Iterating, the team behind epanet-js. He came to epanet-js early, and an engineer putting a 900-mile system through the tool had a clear view of where it needed to grow. His feedback and feature requests helped shape the product as it was built. "To be able to work with the guys that have created this thing has been really cool," he says.
What the model showed
With the model running, the district finally got its answer about the problem area, and it wasn't the one they expected. The water was not flowing the way they had assumed, and knowing the real routes has let them fix a string of issues there since.
Wyatt also checked the model against the district's SCADA flow data:
It's obviously not perfect. You're never going to get it perfect when you're going off average consumption. But it's really darn close. Close enough to give you the information you need to know.
From there the model worked its way into the daily routine. When a customer requests a fire hydrant, the district plugs the location in and sees the whole picture: whether the hydrant works, and whether it drags down a water line at a high spot two miles away. When hunting a leak, they add a demand where they suspect it sits and watch what the water should be doing around it, then open and close valves in the model to test how to isolate it.
That speed changed how the rest of the district sees the tool. Wyatt is still the main user, but he isn't the only one asking the questions. "My colleague came in and said, hey, plug that into the model, see what the model says."
Line extensions and new mains get the same treatment. Instead of guessing, or sending the question out and waiting for a response, the district sits down and runs the scenario. The routine hydraulic questions get answered in-house the same day, and the consulting budget is saved for the harder problems where that expertise really counts.
What's next
The to-do list is practical. The district has thousands of system valves to bring into the model so that closed and open statuses match the real network. Water quality modeling is next on the list, tracking water age and chlorine decay over time and then comparing results against the sampling the district already does. And Wyatt wants to get more staff involved and educated on what the model can do so its benefits can be used even more widely throughout the utility.
His advice for other utilities is direct. Smaller systems get left behind on hydraulic modeling for two reasons, the price of the software and the lack of in-house engineers to run it, and the first of those barriers is now gone.
You're at $0 to start. I would urge anyone to try to build a model for their system. The sooner you get the base model built, the easier it is to add to as you add lines and customers.
Warren County built theirs in a day. It started raining, and Wyatt opened a tab.