Drawbacks of Using Damping Limit?

Question

I have a model with a large number of control valves and pumps, and solving steady state simulations take a varying amount of trials. For instance, one scenario solved SS in ~25 trials, but after a minor-yet-significant modification to the network (added one short pipe to connect two regions within a zone) the solver requires over 2000 trials to resolve steady state. The Intra-Trial status messages indicated that the many valves were being toggled between Active/Opened/Closed repeatedly. After adding a damping limit of 0.01, per recommendation for a solver accuracy of 0.001, the solution is arrived at much more quickly (close to 25 trials). Bentley guidance typically explains damping as limiting flow changes to no more than 60% of the non-damped flow change. 
 Since I expect to see notable flow differences due to network modifications, is it possible that add damping would change the solution? Is it worth validating a "damped solution" with a follow-up trial that does not use damping? Any comments on the impact of damping and solutions with many control valves would be appreciated.

Wayne Hartell · Accepted Answer

Hi Andrew, Thanks for asking this question. As one of the developers who has worked on the WaterGEMS computational engine for many years I will try to provide you with an answer. In order to do this, I would like to cover a little bit of history of the engine development, which should shed some light on the motivation behind such settings as damping limit. Firstly, I should point out that the hydraulic engine upon which the WaterGEMS numerical engine is based, is the US EPA's EPANET, in fact EPANET v2. EPANET v2 was originally developed in the late 90's (first released to the public in 2000) and was actively developed by the US EPA until 2008. During those years, changes were made to the computational engine by the US EPA in response to feedback from users. In the history of the engine development there were and continue to be two main stable release points as follows. EPANET 2.00.10, released 6/24/2002. EPANET 2.00.12, released 2/25/2008. That is, EPANET 2.00.10 was the result of 2 years of public feedback that stood un-modified for 5 years until 2007, and EPANET 2.00.12 has been the standard since 2008. EPANET 2.00.12 was the release that included a parameter for controlling the damping limit. You will note corresponding to the above stable releases, that in WaterGEMS, we support an engine compatibility setting, that has four possible options as follows: 1. EPANET 2.00.10 2. EPANET 2.00.12 3. WaterGEMS 2.00.10 4. WaterGEMS 2.00.12 The meaning of these four settings, in the same order as listed above, is: 1. An engine closely based upon EPANET 2.00.10. This engine attempts to match the result obtained by EPANET 2.00.10. 2. An engine closely based upon EPANET 2.00.12. This engine attempts to match the result obtained by EPANET 2.00.12. 3. An engine based upon EPANET 2.00.10, but with corrections and enhanced features. 4. An engine based upon EPANET 2.00.12, but with corrections and enhanced features. In reality, it is always the same computational engine behind the scenes, but the compatibility setting changes the way the engine behaves in accordance with the above descriptions. The words "attempts to" (for cases 1 and 2) means that the engine version will faithfully reproduce any known computational errors that exist in the corresponding EPANET version in order to match the EPANET results of the same version. For that reason, you would only want to use an EPANET compatibility mode in the case you are exporting to EPANET and wish to match hydraulic results with that version of EPANET. The words "based upon" (for cases 3 and 4) could also, for most intents and purposes, be interpreted as "using the convergence strategy of" and this point provides the segway we need into the discussion of convergence and the questions you are asking. One of the more significant changes made between EPANET 2.00.10 and 2.00.12 was to alter the convergence strategy used for control valves. This was presumably in response to cases (models) where the previous strategy was unable to solve correctly. Cases that could not solve would typically manifest in unbalanced calculations where pairs of control valves would oscillate. The convergence strategy was modified in a number of ways. One modification was to initialize control valves to ACTIVE (versus explicitly starting only PRVs and PSVs as OPEN), so to answer your specific question about "does it change algorithm starting point?" the answer is that the EPANET 2.00.12 based mode does this in comparison to the EPANET 2.00.10 based mode, but otherwise there is no effect on starting point (other than the continued fact that the solution for one time-step in an EPS run forms the starting point for the next time's simulation). Or in other words, the EPANET 2.00.10 based engines use a different starting point to the EPANET 2.00.12 based engines, but changing engine options does not affect starting point. Another modification to the convergence strategy is that the concept of damping (2.00.11) and a damping factor (2.00.12) was introduced, in order to assist with the convergence of problematic models. By the sounds Andrew, you have discovered this option and utilized it to your benefit. The change was simply to no longer check the status of control valve every iteration (which could result in oscillations in some cases) and to relax that check only occur when the relative flow change is getting close to the target accuracy (e.g., 0.01, versus 0.001). In EPANET 2.00.11 the damp limit was fixed at 10x the hydraulic accuracy, however, in EPANET 2.00.12 it was exposed to allow the user to change it (and it defaults to OFF (0) in that case, which reverts to the same case as EPANET 2.00.10, unless a user wishes to enable it). In terms of "what is affected by damping options", let me first start with a brief description of why the damping is in place, and not some other kind of modification. The computational engine essentially solves one linear continuity equation for each node and one non-linear energy equation for each loop. Since the equations are non-linear, an iterative method must be used. Once the equations are set up, the solution converges very efficiently, however, once a control valve changes status, the equations themselves change. Thus, the computational engine is shooting at a moving target. In order to help the equations to stay stable for a while, the damping comes into play. Too much damping, however, can slow down the process. So damping affects the convergence checks that are made on valves and then the subsequent flow changes applied to all hydraulic links, by reducing the magnitude of the flow changes. The damping option aims to allow the solution to converge to within a reasonable level before checking control valve status, and then when it has converged to within a certain value, to smooth out the effect of oscillating valve status changes and improve the final convergence in such situations. As an analog, think of the damping as something similar to tweaking the feedback amplifier in a feedback control system. The damping tries to avoid overshoot. In so far as computed results go, the main factor here is the specified hydraulic accuracy. Valve statuses are checked for the converged solution so using damping should not affect the result in that way; it's merely a means to improving the ability of the algorithm to find a valid solution. Converged results achieved with different calculations in play are not guaranteed to be exactly the same since the results in part may depend on the path taken to convergence, however, the default hydraulic accuracy value normally means that for most practical purposes and systems that results do not significantly vary (by any appreciable value in an engineering sense). You may wish to perform a sensitivity analysis on your model with varying hydraulic accuracy to see whether the model you have built solves well with the default hydraulic accuracy, or whether a tighter value is required (at the potential trade-off of more hydraulic trials). Finally, you mention VFD (Variable speed pumps) in your question. There should not be any discernible difference between the application of the VSP algorithm in either the EPANET 2.00.10 and EPANET 2.00.12 based engines (noting that EPANET itself does not support automatically variable speed parameter estimation) or with any calculation options changes. At the end of the day you should adopt the set of calculation options that results in consistent and stable convergence, and if that is not readily obtainable, as Jesse mentioned in his response, then you should seek to eliminate the causes of such stability issues from the model itself. I hope that this reply helps, at least in part, to answer some of your questions. Regards, Wayne.

Jesse Dringoli · Answer

Hello Andrew, 
 Some of my other colleagues may be able to help you better with specifics on the damping limit (I will "nudge" them about this), but in my opinion it would indeed make sense to more closely examine the results of the model when a change to the advanced calculation options (such as the damping limit) are required. The fact that you are seeing many valves oscillating status in a particularly challenging timestep is an indication that their configuration should be checked as well, to ensure that they are correct and not accidently "fighting against each other" due to the assumed settings. Data checking is the first thing suggested in our general troubleshooting article on "network unbalanced". You might be able to adjust the configuration of those valves (in some cases with a conservative assumption) to make the model more simple and stable. In other words, try to address the root of the problem instead of tweaking the options to get it to work. This should be better in the long run if you can identify (with help from the intra-trial status messages) some changes that stabilize the model. 
 For example this article talks about challenges like this that can occur with PRVs in parallel. 
 Related article on advanced calculation options: 
 http://communities.bentley.com/products/hydraulics___hydrology/w/hydraulics_and_hydrology__wiki/5110.engine-compability-modes-and-calculation-options 
 Of course in some cases you may need to adjust the calculation options, in which case it does make sense to be extra cautious.