Ask a modeller what a master planning study involves and the analysis is a small fraction of the answer. The rest is running the same network under a grid of scenarios: demand growth cases, fire flow at every node, pump combinations, pipe out of service conditions. Each run is trivial. There are hundreds of them, and in the graphical interface each one is a sequence of clicks ending in a copy and paste.
What scripting changes
EPANET has had a programmer's toolkit for decades, and the EPA's own WNTR package wraps it in Python for resilience and criticality analysis. Together they mean the loop above is a dozen lines: load the network once, iterate the scenarios, collect the results into a table.
Three things follow, and only the first is about speed.
- The study becomes reproducible. A script is the method, written down. Six months later, when a reviewer asks why node 4412 failed its fire flow, you rerun it rather than reconstruct it. For studies that go into a funded programme's deliverables, this is the difference between a defensible result and a folder of spreadsheets.
- The scenario grid can be complete. When each run costs nothing, you stop sampling. Fire flow at every node rather than the forty the budget allowed. Every single pipe out of service rather than the ones someone thought were critical, which are rarely the ones that are.
- The error class changes. Manual runs produce transcription errors, which are silent and unevenly distributed. Scripted runs produce logic errors, which are systematic and therefore findable. A wrong script is wrong the same way every time, and that shows up in review.
What it does not change
It does not improve the model. A badly calibrated network run ten thousand times is ten thousand wrong answers, delivered faster and with more authority than before. Automation raises the cost of a bad model rather than lowering it, because the output volume makes the error harder to spot by eye.
It also does not remove the modeller. Deciding which scenarios matter, judging whether a result is physically plausible, and knowing that a node reporting negative pressure means the demand allocation is wrong rather than the network is: none of that is in the loop being automated.
Where to draw the line
The graphical interface remains better for building and inspecting the network, tracing a problem visually, and producing the figures that go in the report. It is worse at doing the same thing repeatedly and recording that you did.
A reasonable split is to build and calibrate in the application, then script everything from the calibrated model onward. That keeps the part humans are good at with humans, and it is the shape of most of the decision support work we build: not replacing the model, wrapping it so the answers come out on demand rather than on request.
The same argument applies on the flood side, where text driven tools make ensembles straightforward, which is part of the case for TUFLOW over ICM on study types that rerun constantly.
