This one is driving me in--sane! I can't figure out whether this is a bug or a nuance of the modelling engine, but the hydrant curves in some of our models are not returning the correct results.
The attached model is a case in point:
1. Two different hydrant curves for the same Junction. Curve 1 has 5 L/s steps, Curve 2 has 1 L/s steps. They return different curve calculated pressures for the same junction, same scenario!
2. Neither curve returns the correct pressures (although the 1 L/s step curve is closer) when compared with adding the fire flow demand points manually and manually running the calc engine.
3. There seems to be sensitivity to calc-engine setting changes. If I change the Calc Engine Accuracy to 0.0001, then the Hydrant Curve will give the same answers as the what the scenario's manually run fire-flow demand will return.
4. Similarly, if I just make the tank "T-Eildon Hill" topologically inactive, which is in a completely hydraulically separate part of the model and not connected to the fire flow curve junction, then this changes the results for Curve 1 (5 L/s steps) to now return the correct results (?!)
This to me is pointing to some issue with some non-convergent calc engine settings being used by the Hydrant Curve Analysis Tool for its runs vs manual runs ie. It isn't using the same calc engine options as what has been set for the scenario?
On a separate note, I've only just realised yesterday that the Hydrant Curve demands replace the junction's demands instead of being additive. Is this by design?
Hi Ben,
I took a look at your model and can see what you are saying. I can fill you in a little on how the hydrant curve calculation is performed and why you are seeing slight hydraulic variations compared to a full hydraulic analysis.
Since our hydrant curves feature not only supports running multiple points (and multiple hydraulic analyses) per curve, it also supports running curves at different times during an EPS. In order to get correct results for the EPS based curves we run the full EPS analysis to the curve time, then run the curve point(s). For a lot of different times, and curve points, the analysis time for larger models can become appreciable, so we have implemented this in a way that optimizes performance, but can potentially result in slightly different hydraulics depending on the model and the hydraulic accuracy setting (as you found out). The reason for the slight difference in results is the use of cached hydraulics to improve convergence in the hydrant calculations, rather than starting from assumed initial conditions as is the case for a full hydraulic run. These different starting points can result in different finishing points. This characteristic will vary depending on the model and the hydraulic accuracy setting. As you also saw, just disturbing the solution matrix in some way (like making some distant part of the network inactive) can have a similar effect on the calculated results. This is the nature of iterative floating point calculations.
To answer your question about the calculation options; the hydrant curve uses exactly the same calculation options as a regular run, except it allows more trials in case the flows applied at the hydrant node trigger some imbalance in the model that can be solved with a few extra trials. If we didn't do this we would possibly see more hydrant curves with odd blips due to non-converged points.
Finally, with respect to the demands, yes both the hydrant curves and system head curves work this way. We present a pure flow versus pressure curve. For the case of hydrant curves any additional demand is included in the curve.
I hope you are doing well.
Kind Regards,
Wayne Hartell
ps/ I notice a lot of the pipes in your model are low flow which is possibly why the tighter hydraulic accuracy helps since this is a measure of the relative flow change in the network.
Thanks Wayne, similarly I hope they aren't working you too hard mate! Early days with the SS4 release, but a big thumbs up to the devs on both the SQLite and new Alternative Management schema.........much bigger and more versatile models now possible with very little overhead penalties! ;-)
Yes, similarly by late yesterday I had reached that conclusion that it must be that the Hydrant curve is a hybrid of calculated/inferred results. You're right, I eventually eliminated specific modelling elements as being the cause and started concentrating on playing with the general calc engine options, EPS and making different elements active/inactive to see what would change the convergence "path" that the Gradient algorithm/solver followed to settle on the "calculated" points in the curve and seeing that it did, in fact, change the results to give varying degrees of accuracy.
Thanks for giving the run down on how the Hydrant Curves derive, knowing that now we should be able to modify our models/procedures to work around it (I hope). My counter-points to think about would be:
1. In this particular model, at 5 L/s, Hydrant Curve 1 has a 3 metre calculated pressure error. That's a lot. A general purpose modeller would probably expect the Hydrant Curve conformance to a manual run to be quite a bit tighter than that.
2. Our group uses Hydrant Curve results as direct output to our Hydraulic Modelling Advice service to external hydraulic consultants. This particular Model/Junction and Hydrant Curve is the basis for a hydraulic report issued to a hydraulic consultant designing a new 5-20 L/s building fire system fed from this water main. Obviously it's important that we try to get as accurate and consistent modelling results as possible.
3. The current version of the WaterGems manual infers the Hydrant Curve engine will actually calculate the pressure at each flow point on the curve. It also recommends users use a high nominal flow, and as large as possible flow step intervals. However, doing the opposite (use a low nominal flow rate and/or finer flow steps) seems like it will generally yield more accurate results in getting the Hydrant Curve engine to do more actual calculations.
4. Having the junction demands overridden in the Hydrant Curve instead of being additive can lead to some traps for GP modellers. In the vast majority of cases, not such an issue as the distributed load from properties across the junctions usually means little reduction in the base load from doing a hydrant curve on one junction with demands. However, there are a minority of junctions that..........through coincidence.........were selected as the most representative demand point for eg. A major industrial complex, or shopping centre etc. with a point load that significantly contributes the the zone's background demands. If in creating a hydraulic fire flow/pressure report for someone, if the modellor inadvertantly selects the same junction for a Hydrant Curve as being representative as the connection point for another property's fire service, then he/she will accidentally remove a significant portion of the background demand and not get a true result of available fire flow/pressure.
5. Ironically, I strongly discourage our team from using Hydrant Curves in EPS runs (even though the software can do it) and only in Steady State. In general engineering practice the use of the tool is to predict the minimum available fire flows/pressures that can occur. In a "real-world" system, it is very difficult to make EPS runs give you a "true" potential minimum system design pressure as the EPS simulation is controlling the boundary conditions (tank levels, pump/valve status etc.). Instead we get our team to directly specify the boundary conditions in Steady State for fire-flow analysis, what the assumed tank levels should be, pump status(es), valve settings etc. that will be the operational condition with the lowest system pressures.
Have a good one mate and thanks again your usual detailed insight!
Hi Ben,Thanks for that feedback with respect to SS4; I will pass that on to the development team!Just some comments on your counter-points.1. Yes that error is not great. I'm thinking in this instance the root issue boils down to the combination of model low flows in many pipes, plus the expedient calculation method, plus the number of points used to calculate the 5 L/s curve. You'll note that an increase in accuracy (smaller value) or even adjusting the nominal flow to closer to what the hydrant produces seems to improve things substantially. I have included some images (hopefully) to illustrate this below. I am logging an issue so I can review the potential for a user to disable the expedited calculation and whether that would help in this instance (especially seeing you are only calculating a single curve here).2. Agreed.3. I'll review the documentation to ensure it is consistent with my understanding of the current algorithms. I noted the other day that there is some incorrect content with respect to how we handle EPS runs also (we run the full EPS and do not merely rely on EPS Snapshot).4. I understand the issue here. We should be clearer at least in the documentation what we are displaying. Right now it's pure flow vs pressure at that point in the network, exclusive of existing demands. Maybe we should include this as an option in the calculation; I will log this for review. It's not a difficult thing for us to support I don't think.5. I also understand your reasoning here. You need to be conservative. I'm not sure how many users use the EPS feature in hydrant calculations since I don't get to talk to as many users as I used to. It would be an interesting statistic to know.Thanks for your feedback. It's exactly the kind of thing we love to get Ben; much appreciated.Regards,Wayne.
Running with an hydraulic accuracy of 0.001. The red line is the 5L/s curve (over-layed on the 1L/s curve in blue).
Running with an hydraulic accuracy of 0.0001. The red line is the 5L/s curve (over-layed on the 1L/s curve in blue). Notice in this case the curves correlate a lot better.
Running with a lower nominal flow (closer to what the hydrant delivers at/near 0 pressure).