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

WaterGEMS Trials

Might need a refresher here, but on hour 0:00 below, why is the solution running 101 trials to an accuracy of 0.000066 when the specified convergence accuracy is only 0.001?  On the next time step, it only take 3 trials?  The "yellow" feedback is that the max trials are exceeded and the system may be unstable.  Thanks

Parents
  • Hi Earl,

    Welcome to the forums!

    Convergence within the WaterGEMS numerical engine is achieved when the sum of flow changes relative to the sum of all the flows in the model is lower than the specified unitless threshold (hydraulic accuracy), however, the convergence criteria also requires that no further status changes happen once numerical convergence is achieved.

    So the process is that the engine will solve the hydraulic equations iteratively to reduce the sum of flow changes below the specified accuracy, then the status of elements (valves, pumps etc) is checked. If a status change occurs, further trials are conducted. The default maximum trials is 100 (for the default engine mode), so after 100 trials, if the computation is unable to achieve convergence that also yields no further status changes, the computation is halted, and the report of "max trials exceeded" is produced. (You get max + 1 trials, in this case 101, since the iterative loop inside the computation engine is using '<=' against the maximum trial count, rather than '<'. This is something that is inherited from the EPANET 2 code base.)

    It is always possible that the system may balance with just a few more trials, though once you get into 3 digit trial counts that becomes atypical. The WaterGEMS calculation summary now includes (since a few releases ago) an "Intra-Trial Status Messages" tab so that you may inspect at any particular time which elements are changing status. Normally when lots of trials are registered for a particular time it will be the same few elements changing status back and forth and so some modeling experience can then be used to tinker with the problematic part of the model to try to solve the problem.

    Based on your reply it seems that you probably did something very similar and managed to debug the issue yourself, so thanks for posting that update. I've responded here FYI and also for the benefit of other readers.

    Regards,
    Wayne.



    Answer Verified By: Sushma Choure 

Reply
  • Hi Earl,

    Welcome to the forums!

    Convergence within the WaterGEMS numerical engine is achieved when the sum of flow changes relative to the sum of all the flows in the model is lower than the specified unitless threshold (hydraulic accuracy), however, the convergence criteria also requires that no further status changes happen once numerical convergence is achieved.

    So the process is that the engine will solve the hydraulic equations iteratively to reduce the sum of flow changes below the specified accuracy, then the status of elements (valves, pumps etc) is checked. If a status change occurs, further trials are conducted. The default maximum trials is 100 (for the default engine mode), so after 100 trials, if the computation is unable to achieve convergence that also yields no further status changes, the computation is halted, and the report of "max trials exceeded" is produced. (You get max + 1 trials, in this case 101, since the iterative loop inside the computation engine is using '<=' against the maximum trial count, rather than '<'. This is something that is inherited from the EPANET 2 code base.)

    It is always possible that the system may balance with just a few more trials, though once you get into 3 digit trial counts that becomes atypical. The WaterGEMS calculation summary now includes (since a few releases ago) an "Intra-Trial Status Messages" tab so that you may inspect at any particular time which elements are changing status. Normally when lots of trials are registered for a particular time it will be the same few elements changing status back and forth and so some modeling experience can then be used to tinker with the problematic part of the model to try to solve the problem.

    Based on your reply it seems that you probably did something very similar and managed to debug the issue yourself, so thanks for posting that update. I've responded here FYI and also for the benefit of other readers.

    Regards,
    Wayne.



    Answer Verified By: Sushma Choure 

Children
No Data