Writers working with large numbers often feel compelled to display digits beyond a reasonable level. For example, they may want to report a pressure as 27,871 psf, when only the first two digits are meaningful. Two solutions to this are to use a more reasonable unit such as converting that value to 190 psi. The other option is to scientific notation and report 28 x 103 psf.
A key input to a water distribution system model is the demand assigned to locations in the system. For most of the history of modeling and most models today, these demands are based on a known volumetric flow rate. Some, however, would argue that all water leaves the system through some kind of pressurized orifice and demands should be modeled as pressure-dependent. Software today, like OpenFlows WaterGEMS, has the ability to model demands as volume-based or pressure-dependent.
Collection system models like OpenFlows SewerGEMS are a powerful tool in their toolbox to assess the problem and develop solutions. The requirement is to develop a method to produce hydrographs based on a simple and reproduceable approach using data that are readily available. The most successful methods can reproduce the total quantity of I&I, the time to peak and the duration of the recession limb of the hydrograph.
To maintain adequate self-cleaning velocity, you need smaller pipes, which means you need to pump. By varying the diameter in model runs, you can look at the effect of trading off velocity vs. head loss.
A key input to any model with pumps is some form of pump head curve showing flow vs. pump head. Given the curve, the model can tell the user the exact point on the pump curve at which the pump will operate.
One of the most common questions we get from our WaterGEMS/WaterCAD users is how to model the connection between a proposed land development and the water distribution system supplying it.
These days, I get involved in a lot of discussions about “digital twins”. One of the most common questions is, “What is a digital twin?” With so many people talking about this, you would think that by now there would be a clear definition. Several organizations have written definitions. I sit on an AWWA Committee whose mission is partly to come up with a definition. So far, we haven’t come up with the perfect definition, and we probably won’t.
Simulating low pressure in your hydraulic model can identify/confirm the cause of the problem and point you to the right solution.
Another issue lies in the personas who are asking and answering the question. Usually the decision maker (i.e. design engineer or system operator) will ask the modeler, “Is this model calibrated?,” and expect the modeler to answer yes or no. What should happen is that the modeler should show the work that was done to calibrate the model to the decision maker and ask, “Do you think the model will meet your needs?”
Real-world problems are ugly, and simplifications and assumptions need to be made to make the problem solvable. The researchers tend to gloss over these assumptions—if they mention them at all. I think many researchers may not even realize that they are making them. Most researchers are graduate students and their advisors, who have never worked on real-world problems. As a starting point for their work, they rely on prior research papers that contain assumptions that the prior authors did not mention. As a result, real-world complications are often lost in legacy papers.