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
Fixed the issue by going through and making some small geometry changes. I think I fixed it when I eliminated two pipes connecting directly to a tank (I've always considered that an issue when troubleshooting past models). Now, I'm down to 10 trials. Didn't use the "advanced reply editor" last time (new to this), but have attached updated graphic. Just to reiterate, that 0:00 line was 101 trials previously with a convergence accuracy well below 0.001
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