OK, leading on from last past as to why we started relooking at WaterGems Engine 2.2.0.   That was because EPANet 2.2 got released midway through a major water quality modelling project.

We were excited to read in EPANet 2.2's developer release notes this putting fixes in to the Lagangrian mass accumulation and distribution method to/from nodes that Rossman and Boulos originally wrote for EPANet.  This was a major source of error in many WaterGems/EPANet modelling projects and the workaround changes needed to base hydraulic models to limit these errors to something reasonable are extremely compromised, expensive and time consuming.

I won't get into too much detail, the likely mass/age errors in real network models were covered by Davis et al. in their 2018 research paper into the issue.   The real-world workarounds that we and others have to employ in models to get around this is both skeletisation of models to merge as many short lengths of pipes as we can into longer lengths, and to reduce the water quality timestep to a much, much lower value than WaterGems default of 1/10th of the hydraulic timestep.  The resulting WQ models are hence very expensive to build and take hours to run due to the necessarily ultra-short WQ timesteps.

So following the logic that each new release of EPANet engine becomes a new Bentley WaterGems Engine base, we were hoping that the above enhancement had similarly made its way into WaterGems Engine 2.2.0.

Unfortunately On first testing we still found the same age/concentration errors in WaterGems (Note "Age" is just another contaminant to track with a reaction rate linearly proportion to time as far as the programming is concerned).

So to test we get an unusual situation where now EPANet 2.2 gives a different (and correct) Water Age value in the test network than the sample model imported into WaterGems (as an EPANet INP file), where WaterGems is still affected by compounding errors that happen through relatively short pipe lengths.

The first test model itself is a relatively simple one:  In theory, a model with 10 x 1 metre long pipes should give the same Water Quality as a model with 1 x 10 metre long pipe.  With Demands of 1 L/s at each end of the pipe runs, this gives a velocity 0.1273 m/s,  so we know then the maximum age calculated at the end of each pipe run should be 10 metres / 0.1273 m/s =0.022 hours.

Due to EPANet 2.00.10 and 2.00.12 not handling nodes in topological order and working its way from upstream to downstream, errors could occur, and the 10 x 1 metre short pipe length case would be expected to give errors that in this case can greatly exaggerate the water age (but in other sample cases the reverse can happen)

So, let's see if EPANet 2.2 does indeed solve this properly now:

OK, nice!  EPANet 2.2 has got the right answer AND the result is the same value for both end nodes.  I would need a more complex model to test EPANet 2.2 more thoroughly for Eg. Nodes that have > 2 Links and more complex flow dynamics etc. but this tends to evidence the EPANet developers have potentially done what they said they did in largely fixing the node in/out mass/concentration errors that occurred in previous engines.

What happens now if we bring this EPANet INP file into WaterGems and flip the Calculation Engine to the newest additions:  EPANet 2.2.0 and WaterGems 2.2.0 ?

So unfortunately Engine = WaterGems 2.2.0 gives the wrong result and one different from EPANet 2.2.  The 1 x 10 metre long pipe run calculates the right age, but the 10 x 1 metre pipe run does not.   This suggests that these engines for the water quality runs do not yet have a topological upstream/downstream sorting enhancement of the same nature before applying the Lagrangian WQ pipe segmentation analysis to generate the intermediate WQ timestep node concentrations/ages.

Same if we flip the Engine to "EPANet 2.2.0".

communities.bentley.com/.../EPANet2_5F00_2_5F00_Age_5F00_Test.zip