Overview

The purpose of this article is to explain the Engine Compatibility modes and related advanced calculation options.

These have been added to Bentley WaterCAD/WaterGEMS/Hammer V8i SelectSeries 2 (SS2). Additional information may be found in the Help menu of each program.

Background

The Engine Compatibility dropdown in the calculation options enables you to switch between different versions of the EPANET numerical solver (including the "Bentley-Enhanced" versions) and provide results directly compatible with a certain version. This can be helpful for example when exporting back to EPANET.

• 2.2.0 solver version: introduced with CONNECT Edition Update 4 (2023) 
• 2.0.12 solver version: introduced with V8i SELECTSeries 2 (2010)

Each option will be covered in detail below including the additional calculation options exposed when selecting a certain solver version.

Note that as of the current version, newly created models will default to the Bentley-Enhanced 2.2.0 version engine. With CONNECT Edition Update 3 and earlier, new models will default to the Bentley-enhanced 2.00.12 engine. Previous models will retain the solver version used by the version they were last saved in . 

Engine Compatibility Modes

The ‘Engine Compatibility’ Calculation option replaces the ‘Use EPANET Compatible Results?’ option which was seen in older versions (V8i SELECTSeries 1 and earlier.) In the old versions, when set to true, you were using EPANET 2.00.10. The software now includes compatibility modes, to choose between  EPANET 2.00.10, as well as the revised engine changes in EPANET 2.00.12 and EPANET 2.2.0.

WaterGEMS 2.00.12 – this engine is based on the EPANET 2.00.12 engine, including Bentley modifications. Choose this option to get all the engine improvements and fixes made by Bentley and an engine mode that is based upon EPANET 2.00.12. This is the default for new models in WaterGEMS and WaterCAD CONNECT Edition Update 3 and earlier.

WaterGEMS 2.00.10 – this engine is based on the EPANET 2.00.10 engine, including Bentley modifications. Choose this option to maintain compatibility with previous versions of WaterGEMS (meaning V8i SS1 and earlier) where the computational engine is based upon EPANET 2.00.10. This is the default for upgraded (existing) models. Note: the ‘Use Linear Interpolation for Multi Point Pumps?’ option is FALSE by default in existing models as well. These default options are designed to make the transition smoother for users.

EPANET 2.2.0 - models run using this engine have results that are compatible with EPANET 2.2.0. If choosing a version of the EPANET engine, any enhancements, calculation corrections, bug fixes, etc. added by Bentley will be disabled in order for results to match the specific EPANET version results. Imported EPANET INP files will default to the EPANET version used when the INP file was generated in EPANET itself.

EPANET 2.00.12 – models run using this engine have results that are compatible with EPANET 2.00.12. If choosing a version of the EPANET engine, any enhancements, calculation corrections, bug fixes, etc. added by Bentley will be disabled in order for results to match the specific EPANET version results. Imported EPANET INP files will default to the EPANET version used when the INP file was generated in EPANET itself.

EPANET 2.00.10 – models run using this engine have results that are compatible with EPANET 2.00.10.

Note:

• When using the EPANET solver version (instead of the "WaterGEMS" version), the ‘Use Linear Interpolation for Multi Point Pumps?’ option is hidden as it will not apply.
• Additional details on compatible results can be found in this article: Should the EPANET solver and the WaterGEMS/CAD solver give the same results for a model?

Compatibility Matrix - 2.00.10 vs. 2.00.12

The following engine compatibility matrix is included in the Help file (Modeling Capabilities>Calculation Options>Engine Compatibility Calculation Option).

2.2.0 Engine Version

The 2.2.0 engine version adds additional enhancements beyond 2.00.12 mentioned in the table above.

• WaterGEMS 2.2.0 
  • Additional Convergence calculation options - see details in the next section.
  • Improved Handling of Near-Zero Flows: In summary, the 2.2.0 solver is less likely to be unbalanced or ill-conditioned in cases where the flow is zero or near zero. EPANET's hydraulic solver can generate an ill-conditioned solution matrix when pipe flows approach zero unless some adjustment is made (i.e., as a pipe's flow approaches 0 its head loss gradient also approaches 0 causing its reciprocal, which is used to form the solution matrix's coefficients, to approach infinity). EPANET 2.0 used an arbitrary cutoff on head loss gradient to prevent it from becoming 0. This approach doesn't allow a pipe to follow any head loss v. flow relation in the region below the cutoff and can produce incorrect solutions for some networks (see Estrada et al., 2009). The hydraulic solver has been modified to use a linear head loss v. flow relation for flows approaching zero. For the Darcy-Weisbach equation, the linear Hagen-Poiseuille formula is used for laminar flow where the Reynolds Number is <= 2000. For the Hazen-Williams and Chezy-Manning equations, if the head loss gradient at a given flow is below the EPANET 2.0 gradient cutoff then a linear head loss relation is used whose slope equals the cutoff. EPANET 2.2 is now able to correctly solve the examples presented in Estrada et al. (2009) as well as those in Gorev et al., (2013) and Elhay and Simpson (2011).
  • Pressure Dependent Demands (PDD):
    • The EPANET implementation of PDD (introduced in EPANET 2.2.0) is not used with the 2.2.0 solver version, because WaterCAD and WaterGEMS have had PDD functionality for a very long time, and support more capabilities* than the PDD functionality built into EPANET 2.2 (WaterCAD and WaterGEMS have piecewise linear function support, the ability to apply PDD selectively to a portion of the network and as a percentage of the total demand)
    • Additionally, hydraulic results when using basic PDD functionality should be equivalent. It is expected that a model with PDD that runs in EPANET 2.2, will import into WaterCAD and WaterGEMS and gets the same hydraulic results.
    • When exporting a WaterCAD/GEMS model to EPANET 2.2, the PDD options are NOT exported, due to the inability of the EPANET 2.2 PDD support to embody the full range of WaterCAD/GEMS settings.
    • When using the 2.2.0 solver version if you are using PDD features that are not supported in EPANET itself, you will see the user notification "WaterGEMS pressure dependent demands settings are not fully supported by EPANET 2.2; results may not match EPANET 2.2."

      *The one exception is that EPANET 2.2 supports a Minimum Pressure where the demand becomes zero. This cannot be accommodated directly within WaterCAD/GEMS, however, it is possible to incorporate through the use of piecewise linear pressure dependent demand curves.

• EPANET 2.2.0
  • Adds the enhancements above
  • Does not support the WaterGEMS-specific engine enhancements seen in the table further above

Additional Calculation Options

When using the 2.00.12 or 2.2.0 solver version, there are three additional calculation options available. These options are the same for both the EPANET and WaterGEMS engines.

NOTE: if a model is sensitive to these options, it may be evidence of a deeper convergence issue that you may want to investigate in case there is a data entry issue that can be addressed so the model is more stable (and less sensitive). You can use the guidance in the "troubleshooting" article in the "See also" below, for example looking closely at the “intra trial details” tab of the calculation summary.

Convergence Check Frequency – The Convergence Check Frequency option sets the number of solution trials that pass during the hydraulic balancing before the status of pumps, check valves, flow control valves (FCV) and pipes connected to tanks are once again updated. The default value is 2 (meaning that status checks are made every other trial). A value equal to the maximum number of trials would mean that status checks are made only after a system has converged. The frequency of status checks on pressure reducing (PRV) and pressure sustaining valves (PSV) is determined by the Damping Factor option.

Increasing the convergence check frequency can allow model conditions to settle down a bit (converge more closely just with the basics in play) before it tries to change the status of valves and pumps (which adds more complexity to the convergence), so this usually results in better stability (better chance of a balanced timestep). However in some cases it may not. For example if there is too much going on (complexity of the valve and pump interactions plus other things), the timestep may continue to fail to converge after it attempts to update the pump/valve status, in which case increasing the frequency value may not improve stability. As noted above, pursuing the root cause of the instability or sensitivity is recommended, and adjustment of this option can instead be used in particularly challenging models which have already been verified to be configured correctly and have unnecessary complexity removed.

Convergence Check Cutoff – The Convergence Check Cutoff option is the number of solution trials after which periodic status checks on pumps, check valves, flow control valves (FCV) and pipes connected to tanks are discontinued. Instead, a status check is made only after convergence is achieved. The default value is 10 (after 10 trials, instead of checking status every “convergence Check Frequency” trials, the status is only checked after convergence is achieved).

Damping Limit – The Damping Limit is the accuracy value at which solution damping and status checks on PRVs and PSVs should begin. Damping limits all flow changes to 60% of what they would otherwise be as future trials unfold. So, instead of checking the status of control valves at every iteration (which could result in oscillations in some cases) damping relaxes that check to only occur when the relative flow change is getting close to the target accuracy (e.g., 0.01, versus 0.001). The default value is 0 (zero), which indicates that no damping should be used and that status checks on control valves are made at every iteration. Damping might be needed on networks that have trouble converging. A limit of 0.01 is suggested (relative to the default calculation hydraulic accuracy of 0.001). See further below for a more detailed explanation.

Additional Post Calculation Warnings

Post Calculation warnings have been added to advise a user if they are using any features that are NOT supported by EPANET when they are running with one of the two EPANET compatibility settings. These are POST calculation and will not be displayed when validating a model (i.e. these calculation warnings are only displayed when computing a model. In some cases the results will still be accurate but these messages are there to remind you to carefully check the results related to the specific element or area that they mention, and understand that the results will likely not match if the model were to be computed in EPANET itself since those elements/features are not present in EPANET (for example if you were to export the model to EPANET INP format and open it in EPANET itself).

Detailed Background

The hydraulic engine upon which the WaterGEMS and WaterCAD numerical engine is based, is the US EPA's 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 (as of this writing in August, 2016) two main stable release points as follows.

EPANET 2.00.10, released 6/24/2002.
EPANET 2.00.12, released 2/25/2008.
EPANET 2.2.0, released 

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, Convergence Check Frequency and Convergence Check Cutoff. EPANET 2.2.0, includes options for flow change limit, headloss error limit, and an option to continue if unbalanced.

You will note corresponding to the above stable releases, that in WaterGEMS, we support an engine compatibility setting, that has six possible options as follows:

1. EPANET 2.00.10
2. EPANET 2.00.12
3. EPANET 2.2.0
4. WaterGEMS 2.00.10
5. WaterGEMS 2.00.12
6. WaterGEMS 2.2.0

WaterGEMS 2.2.0 and EPANET 2.2.0 are available starting with CONNECT Edition Update 4.

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 closely based upon EPANET 2.2.0. This engine attempts to match the result obtained by EPANET 2.2.0.
4. An engine based upon EPANET 2.00.10, but with corrections and enhanced features.
5. An engine based upon EPANET 2.00.12, but with corrections and enhanced features.
6. An engine based upon EPANET 2.2.0, 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".

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). 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. 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 to 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 ten times 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).

Regarding the Damping Limit, one must first understand 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", so to speak. 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 analogy, 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).

With that said, you should adopt the set of calculation options that results in consistent and stable convergence, and if that is not readily obtainable, then you should seek to eliminate the causes of such stability issues from the model itself.

See Also

Drawbacks of Using Damping Limit?

Troubleshooting "Network Unbalanced" or "Cannot solve network hydraulic equations" user notification