Results 1 to 4 of 4

Thread: System Unbalance Question

  1. #1

    Join Date
    Feb 2014
    Posts
    9

    System Unbalance Question

    Hi.

    I am experiencing an error with my model that I wonder if someone might be able to provide some input on.

    The problem i am encountering is an unbalance error that seems to be related to a specific group of pumps which are turning on and off repeatedly until the simulation fails.

    Would anyone have any recommendations on to why this may be occuring?

    These are all pumps that pull from fixed head reservoirs and do not have any logic controls attached to them, so i'm not sure why they are toggling on and off like they are. Thanks for the help!

    I've attached an example of what i mean below

    Trial 6: relative flow change = 0.000331
    CV PPE_00192 switched from closed to open
    Pipe PPE_00193 switched from closed to open
    CV PPE_00194 switched from open to closed
    Pump PMP_22 switched from closed to open
    Pump PMP_23 switched from closed to open
    Pump PMP_24 switched from closed to open
    Pump PMP_26 switched from closed to open
    Pump PMP_50 switched from closed to open
    Trial 7: relative flow change = 0.038532
    PSV PSV_50 switched from closed to open
    Trial 8: relative flow change = 0.037507
    Pipe PPE_00193 switched from open to closed
    CV PPE_00194 switched from closed to open
    Pump PMP_22 switched from open to closed
    Pump PMP_23 switched from open to closed
    Pump PMP_24 switched from open to closed
    Pump PMP_26 switched from open to closed
    Pump PMP_50 switched from open to closed
    Trial 9: relative flow change = 0.017686
    PSV PSV_50 switched from open to closed
    Trial 10: relative flow change = 0.000627
    Pipe PPE_00193 switched from closed to open
    CV PPE_00194 switched from open to closed
    Pump PMP_22 switched from closed to open
    Pump PMP_23 switched from closed to open
    Pump PMP_24 switched from closed to open
    Pump PMP_26 switched from closed to open
    Pump PMP_50 switched from closed to open

  2. #2
    Member

    Innovyze Employee



    Join Date
    Mar 2013
    Posts
    72
    I think the problem is caused by the PSV. You may change PSV to another valve type and re-run the simulation.

  3. #3
    Forum Moderator

    Innovyze Employee



    Innovyze Employee



    Join Date
    May 2015
    Posts
    421
    jcscott,

    While based on the date of this post I suspect your issue has been resolved, I wanted to post a reply for the benefit of other users of things to consider:

    If the model run ever fails it is best to rerun and use the Full status report option with the warning messages displayed (if not already done.) This will allow you to see what is changing during each iteration and what warning messages are being generated as these are usually indicative of the issue.

    To make this change open the run manager and select the ellipsis for the report options:
    (click for a larger image)
    Run Manager - Report Options.jpg

    Then make sure the report option used has the Full Status Report and Generate Warning Messages options selected as shown:
    (click for a larger image)
    Full Report with Warning Messages.jpg

    To see the report (if it didn't already pop up because the run failed) select the report button from the run manager:
    (click for a larger image)
    Run Manager - Report button.jpg

    Now you can see all of the information the model provides to help troubleshoot the issue. If you did not have these options selected rerun the model and then open the report.

    1) Locate any warning messages generated:
    a) Search for the following words using a CTRL-F to bring up the Find window. "Warning" or even just "Warn" is fine.
    b) Go through each warning message and make note of repeated warnings and write down ID's associated with them.
    c) Visit each element with warnings and check what could cause the error. See below for the typical Warning Messages and possible resolutions taken from the
    InfoWater Help file
    .Warning Message Suggested Action
    .


    • Pump cannot deliver
      head
      . The pump is trying to deliver pressure greater than the shut-off
      head. Use a pump with a larger shutoff head.


    • .
    • Pump cannot deliver
      flow.
      The flow required is greater than the maximum flow capacity of
      this pump. Use a pump with a larger flow capacity.
      .
    • Flow control valve cannot
      deliver flow.
      A flow control valve provides a restriction to flow to
      maintain a set flow through the valve. If the flow through a wide open valve is
      less than the set flow, the valve can not deliver the set flow. Reduce the flow
      setting on the valve or provide additional head at the valve.

      .
    • Following nodes are
      disconnected at timestep [timestep]:
      [list of nodes]
      One or more pipes
      are closed at the given timestep, therefore shutting off all flow to a portion
      of the network. Ensure that this action is appropriate and if not, change the
      controls or status associated with the pipes and re-run the analysis. It should
      be noted that not all pipes connecting a junction node can be closed
      simultaneously. Each junction node must have at least one connecting pipe open.
      For example, a pipe connecting a dead-end junction node cannot be closed.
      InfoWater will identify all junction nodes that are disconnected and this data
      must be corrected before an analysis can be made.

      .
    • System unbalanced.
      This condition typically occurs when a pump or valve keeps switching its status
      back and forth between successive iterations while solving the hydraulic
      equations for the network, thus causing the system to fail to converge to a
      solution. Possible causes for this include a pair of pressure controls that
      turn a pump on and off whose pressure settings are too close together, or a
      collection of pressure regulating valves whose pressure settings influence the
      status of one another. You can specify a Full
      Hydraulic Status
      report with the Simulation
      Report Options
      to identify those pipes in the Output File that might be
      behaving in this manner and then modify their pressure or flow settings to avoid
      this situation. Another option, but less preferred, would be to use a slightly
      larger value for the model ACCURACY parameter, which can be set using the Edit
      Simulation Options command.
    • Negative Pressures exist at
      Node(s)
      . InfoWater will issue a warning message when it encounters
      negative pressures at junctions that have positive demands. This usually
      indicates that there is some problem with the way the network has been connected
      or operated. There is more demand than the system is able to supply. Negative
      pressures can occur when portions of the network can only receive water through
      pipes that have been closed or restricted. In such cases, an additional warning
      message about the network being disconnected is usually issued.


    The last step is to look at the final hour of the report and see if certain elements are switching back and forth causing the simulation to reach the maximum trials. If so, those are the elements one wants to examine closely to see why they are causing issues. While many things can cause issues in not converging the most common seems to be associated with either multiple valves fighting for control or something which makes it impossible for the model to reach a solution.
    .
    Valves can fight if they are close to one another and have settings which cause them to fight for which valve will have primary control. When this happens in the model it is also usually happening in the real world somewhat. Resolving those issues could be related to adjusting the setpoints to be farther apart, adjust elevations so the valve HGL's downstream are farther apart, or making other changes specific to that system so the valves "fight" less. As far as the software goes, there are a few things one can do to potentially help. I'll post those in another post .
    .
    Last edited by Patrick Moore; April 7, 2016 at 12:23 PM.

  4. #4
    Forum Moderator

    Innovyze Employee



    Innovyze Employee



    Join Date
    May 2015
    Posts
    421
    To continue from my last post:

    One is to make changes to the simulation options. Once could increase the number of trials allowed by increasing the value under "Trials", the model software defaults to 40 iterations, but increasing the number allowed to 100 or 150 is not uncommon. Also you can change what the software does when it reaches the max simulation runs to continue instead of to stop. If you choose to continue, make sure you include at least 40-50 in the extended run box. See the key boxes to change highlighted below:
    (click for larger image)
    simulation options for extended runs.jpg
    .
    Changes to the advanced parameters in the simulation options can also help dampen the potentially unlimited changes EPANET can make when its trying to find a solution. The advanced parameters are also found in the Advanced tab of the simulations option window. The default values will make a model generally run faster but can be more susceptible to non convergence of PRV's at times. Adjusting the parameters can help the model be more stable:

    The default values are Check Freq = 2, Max Status Check = 10, Relaxation Factor = 1, and a Damping Limit of 0.

    Recommended changes would be Check Freq = 2, Max Status Check = 10, Relaxation Factor = 0.6, and a Damping Limit at 10X the model accuracy.

    The original EPANET 2 help file (with its notes copied into most modeling software packages) indicate a suggested minimum for the damping limit at ten times the model convergence accuracy, (So an accuracy of 0.001 would use 0.01 for the damping limit). In practice a higher damping limit could be necessary. One could start with a Relaxation of 0.6 and a damping of at 10X your accuracy first and adjust the Damping limit and or the accuracy until the model converges. Under certain circumstances higher damping limits can help, but the most improvement seems to come from the lowering of the relaxation factor. I have found at times Damping limits as high as 0.8 and 1.5 were helpful to achieve convergence in certain models, but I would use that as a last resort. The higher the number, the quicker the dampening is utilized. Essentially when the convergence relative flow change drops below the Damping limit, the model will begin to dampen changes to help the model converge with the minimum recommended occurring at 10 times the accuracy goal.

    If these changes do not resolve the issue, then your only recourse is to adjust the settings of the two valves farther apart so that one valve is clearly controlling.

    Also as far as the pumps turning on and off please recall that there are two types of control statements the model uses. One is Logical controls and the other is simple controls. Simple controls on an element are seen by selecting the "Control" button in the Model Explorer which looks like a hand on top of a blue pipe just to the right of the initial status "faucet" icon. You should check the pumps controls to see if they have any simple control statements defined.
    (click for a larger image)
    Simple Controls button.png

    Lastly, if the pump changes occur during the final trial of the model run, the turning on and off of the pumps is part of what EPANET does to try and find a solution when it is not readily found. Just be aware that this can occur and is caused by EPANET and not by any control statements. This can be confusing when troubleshooting but is all part of what EPANET does to try and find a solution. When it cant find a solution these changes often are confusing as to why they occur. But EPANET often says "temporarily closed element X" when this occurs but I have also seen it make what appear to be random changes in an attempt to find a solution.

    The one other common tool used to help troubleshoot model errors is to put all tanks in the domain and to complete a Tank group Graph. If you display the results as % Full you can easily spot tanks going 100 empty and tanks going 100% full. Both are often indicative of missing or problematic control statements or open ties between pressure zones that are normally closed. By looking at elements feeding those zones errors can often be identified.

    Hope these help you and other posters be aware of the general procedures used in modeling to help troubleshoot a model that is not converging.

    Innovyze Support.
    Last edited by Patrick Moore; April 7, 2016 at 12:31 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •