Modelling without Customer Meter

Hello! 

I'm tring to create a model just to verify a filter operation, i would like to model 2 scenarios, the first one is to chek the behavior of the pumps and the flow results with a specified filter (about 5 mca on local headloss), the second scenario it's just to check the flow and the pump behavior without this filter. We are analising the cost-benefit of removing this filter. 

The model it's stuck in network unbalanced problem, i wonder if it's because i'm modelling without customer meter, it's that a problem? There is any way just to check the pump operation connected to a Tank and just check the flow and the time to fill the tank? Should i change any calculation options? 

Parents
  • Hi Fabio,

    A typical error is caused by the modeller using Check Valves / Non-Return Valves in line with the pump.   It is perhaps not obvious, but model pumps already have an implicit check valve within them and putting a second check valve in line with the pump can lead to unsolvable networks.........in fact, unnecessary use of Check Valves in EPANet based / WaterCAD models is one of the leading causes of Unbalanced Network equations as the model reaches a point where it can't solve the hydraulics with either the Check valve open or closed and gets stuck trying to converge to a solution.   To a lesser extent, other model Control Valve types can also do this if not setup correctly in the model when combined with a model Pump.

    If you post a screenshot of what is the Modelled Pump Layout causing the Unbalanced error then this would be the first step to diagnosis.



    Answer Verified By: Fabio Lobo Araujo 

  • Hello Ben! Thanks for the answer! I didn't use any check valves. I also look for any others issues and didn't find anything. 

    I've just uploaded a copy of the model.

  • Would be happy to look at the model Fabio, usually there a few usual candidates that cause an excessive number of calculation iterations or a failure to converge.

    However, I can only see files that are attached to Posts ie. Users attached files as per Option 1 in copy of the model files

    As am not Bentley staff, cannot see anything that has instead been uploaded using Option 2! Wink



  • Fabio and Ben, please see Scott Kampa's answer further above from Friday. He reviewed your model and provided some suggestions. If you need more help understanding why your model is struggling to converge, let us know.


    Regards,

    Jesse Dringoli
    Technical Support Manager, OpenFlows
    Bentley Communities Site Administrator
    Bentley Systems, Inc.

  • Thanks Jesse, noted Scott's review.

    By way of comparison, using methods of model building with a primary objective of convergence stability,  our largest corporate base model with 192,000 Pipes, 125 Pumps (~50% VSP) , 120 PRVs , 80 TCVs and 40 CVs,  typically has timestep convergence after <30 iterations.

    There are certainly legitimate circumstances for having a model that instead takes 100s of iterations to converge, but in my practical experience, the majority of times this is pointing to an inherently unstable model.

    When I first started modelling, I similarly used to brute force models to get convergence by increasing the allowed convergence iterations to ~400 - 1,000 or engine swapping/kludging, until realised that this was just putting bandages on an unstable model that would be prone to non-convergence/new calculation errors whenever I changed some of the input variables.

    As almost certainly seen in many unstable models submitted to Tech Support that the team has likely helped the users diagnose, the 2 primary reasons for instability/excessively high iteration count are either very low pipe velocities/friction head that are insensitive to iterative trials of different network flow path mass balance solutions,  or the sparse matrix solver struggles to converge to the right combination of Active/Inactive/Closed statuses of Pumps, CVs and Control Valves.   In the second case, this can usually be significantly improved by some tweaks to the model layout that has the same hydraulic equivalence but is far more stable, and run times are considerably shortened as a bonus..

    Usually an assessment of how stable/unstable the model is, and causes for it can be reviewed through the Calculation Summary, Intra-Trial Status messages, an addition to WaterCAD's Features we have found invaluable for rapidly narrowing in to instability diagnostics and resolution in our many 100s of project models. Wink



Reply
  • Thanks Jesse, noted Scott's review.

    By way of comparison, using methods of model building with a primary objective of convergence stability,  our largest corporate base model with 192,000 Pipes, 125 Pumps (~50% VSP) , 120 PRVs , 80 TCVs and 40 CVs,  typically has timestep convergence after <30 iterations.

    There are certainly legitimate circumstances for having a model that instead takes 100s of iterations to converge, but in my practical experience, the majority of times this is pointing to an inherently unstable model.

    When I first started modelling, I similarly used to brute force models to get convergence by increasing the allowed convergence iterations to ~400 - 1,000 or engine swapping/kludging, until realised that this was just putting bandages on an unstable model that would be prone to non-convergence/new calculation errors whenever I changed some of the input variables.

    As almost certainly seen in many unstable models submitted to Tech Support that the team has likely helped the users diagnose, the 2 primary reasons for instability/excessively high iteration count are either very low pipe velocities/friction head that are insensitive to iterative trials of different network flow path mass balance solutions,  or the sparse matrix solver struggles to converge to the right combination of Active/Inactive/Closed statuses of Pumps, CVs and Control Valves.   In the second case, this can usually be significantly improved by some tweaks to the model layout that has the same hydraulic equivalence but is far more stable, and run times are considerably shortened as a bonus..

    Usually an assessment of how stable/unstable the model is, and causes for it can be reviewed through the Calculation Summary, Intra-Trial Status messages, an addition to WaterCAD's Features we have found invaluable for rapidly narrowing in to instability diagnostics and resolution in our many 100s of project models. Wink



Children
No Data