This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WaterCAD VSP + Upstream Control Change: Wrong pump speed/HGL

Here's an interesting EPS brainteaser that one of our WaterCAD user group gave me to look at for some diagnostics.

For certain timesteps, when a pump is turned On by Controls, a downstream Variable Speed Pump would not calculate the right pump speed and it would not maintain its downstream pressure setting.

....OK, so let's look at the troublesome timesteps and see what we can see:

55-56 trials?  Hmmmmmm.......something is not playing nice.   It got me thinking, there must be something in the Calc Options rules that is allowing this to happen.  What exactly is the Calculation engine treating as a "converged" solution?   The EPANet engine doesn't have variable speed pumps, maybe there are some strange things happening in the WaterCAD hybrid engine that extended the pump functionality for VSP but still runs on similar EPANet convergence rules?

So.......can you see what the problem may be here?  It took me 30 minutes to puzzle this one out.............but I always like a good brainteaser! ;-)    Luckily the fix turned out to be fairly simple!

ExampleVSDPump.zip
  • Hello Ben,

    I checked that, and found that changing the Convergence Check Cut Off (in the calculation option) will solve that issue, once I increase the number I got the desired results. But I do not understand what behind that, most likely the default numbers are used and changing those default numbers should be supported with technical reason.

    Is that number should be greater than the 56 trial you mentioned? i.e. meaning that after 56 trials; instead of checking status every "Convergence Check Frequency" trials, status is checked only at convergence.

    Would you please elaborate about " Convergence Check Cut Off " why the default number causes problem and why increasing it solve it (if I am true).

    Regards...............Mohamad

  • Hi Mohamad,

    In this case you should go the other way, set the Convergence Check Frequency to 1.   This makes the calculation engine recalculate the VSP speed on every trial, and the model will converge much quicker (those 55-56 trials on those timesteps will reduce to a normal level of trials)

    The original default EPANet/WaterCAD settings are of course, a compromise between accuracy and computational speed, primarily due to desktop computing power that existed through the 1990s.  So the default settings gave good results most of the time (but not all the time), whilst not having to wait hours for the model to complete a run.  This is why the default setting was put at 2 (ie. recalculate controlled elements every other trial).  However, you could probably say on typical 2013 PC hardware there is perhaps no longer a need for this to be left at 2, and should instead be set at 1 by default to prevent strange calculation results artefacts that can otherwise creep in.

    In this particular model the issue gives crazy answers at these timesteps because the calculation engine thinks that it has already checked in previous trials that all controls have been triggered, all control actions have been completed, and because the system flows didn't change between trials (ie. within Accuracy tolerance) then the solution is "converged".   However, with the additional WaterCAD VSP elements that have been added to the WaterCAD branch of the EPANet Calc Engine code, it "forgets" that the VSP pump speed "control" also needs to be recalculated in the final calculation trial to get an accurate answer.  (which of course the original EPANet calc engine doesn't need to worry about.......it has no Variable Speed Pumping!).   The modellors working on this model eventually gave up on solving the issue, but a few months later one of modellors escalated it up to me to have a look at.



  • Hi Ben,

    I really appreciate your deeply answer "as you usually do".

    I am bringing other case and your input is recommended and hope get more feedback. In the attached model I had problem " Unbalanced system" and I got feed back to increase the trials which helps.

    The unbalanced system problem has been solved at Trial 1500 as in the model attached, would you please elaborate more about that problem; why that happened? Specially I did larger models and larger networks and did not get that; this is small example and requires 1500 trial, it does not sounds well for me.

    The other thing about this case is if you change both AV to be "treated as junction" and make trials=40, I do not get unbalanced system, so why treating the element  air valves as an air valve create that problem? Would you please have a look closely and I guess will be interesting case for everybody in this Forum.

    Regards...........Mohamad

    With trial 1500.rar
  • Hi Ben,

    Thanks for deeply answer.

    I am attaching new case and the description in the word file attached in the model, please have a look. I tried to post it few time but required approval as happened with you.

    It seems I success this time, before I was doing copy and past; (might be that was the problem)???!!!!!!!!!.

    Regards............Mohamad

    Model.rar
  • Because it thinks AV-2 and/or AV-1 have negative pressures and are letting air into the system.

    As it is pressure pipe modelling software, it can't solve the conflict: If pipe pressure at the air valves was negative then air would enter the system and the downstream mains would be acting as partially full mains, but the standard WaterCAD steady state calc engine is for full flow pressure pipes, not partially full/gravity mains.

    Usually we are not interested in air valve behaviour for steady state network simulations, this is only relevant if we are going to use the calculation engine to calculate the initial steady-state conditions for a Hammer model run.  Setting "Treat Air Valve as Junction?" on AV-1 and AV-2 will solve the calculation instability.

    However, it would be worthwhile looking at the system design and seeing if the pressure really does drop to negative.  On a double-acting Air Valve, this would be an undesirable condition in the force mains as it would leave air in the system.......you would usually want the system with positive pressures at the high point.