Calculation times between MWell and QGIS-TIM in transient mode

[CGoudswaard]

I hope this first 'discussion' topic isn't considered superfluous.

We are making the transfer from using MWell to using QGIS-TIM. So far for a steady-state analysis the integration with QGIS and resulting ease of use has been greatly appreciated, but whilst comparing the two I've noticed a significant difference in required calculation times between the two when generating contour plots in transient mode.

The model I've recreated in MWell and QGIS-TIM consists of ~600 discharge well along a 3 km line. They are divided in groups of 20 where each group is active for 2 days, starting every next day for a total of 32 days.

With a simple aquifer model resembling the 'Rijsenhout tutorial' model, with a mesh size of 50 m, MWell is done after a few minutes with 6 contouring times. Note that these are far from pretty and I was hoping these could be improvied by switching to QGIS-TIM. However, QGIS-TIM in transient mode requires up to an hour to calculate the same 6 contour plots when calculating Mesh, Contours and Head Observations.

I assume the easy 'method' to decrease the mesh and contour calculations would be to greatly reduce the number of discharge wells and increase the discharge rate per well, but I am interested in why the calculations in MWell are approximately 10 times faster than in QGIS-TIM and if our existing workflow can be transferred to QGIS-TIM without the experienced calculation times.

Any thoughts?

[Huite]

Hi @CGoudswaard,

This is a very relevant question.

The mentioned case is quite helpful and such a slowdown compared to MWELL is quite undesirable.

Just for checking: I guess the solve step isn't too bad?

This should be a very good comparison case, because the principles of wells in MWELL and TTim are essentially the same (the biggest difference would be the inversion from the Laplace domain).
I'm pretty confident the biggest difference is due to function overhead in Python. MWELL is Pascal and compiled, and so pretty fast. In TTim, only the slowest parts are compiled.

When actually contouring, TTim will iterate over every grid point. The way it's set up, it will iterate over all well per point. Since you're dealing with 600 wells, every well is being queried once per grid point. Ideally, I think, we would batch the grid points, and add the potential of all gridpoints at a time. Since a well is relatively simple, the function call overhead is possibly relatively large; by batching it we'd reduce the overhead (MWELL's overhead here would be much smaller, being fully compiled). We're currently calling the method ny * nx * 600, and we could reduce it to being just 600 calls.

What I think I'll try is implementing a headgrid method on the well element (for your example with 600 wells), then profile them. If that gives a good result, we can implement them for all elements.