How to speed up computation of head grid

[justuskrantz]

Hey!

We're experiencing an issue with retrieving the transient contours. We'd like to plot not the head contours, but of the drawdown itself, so we're subtracting the initial head to come to the drawdown value. We'd like to plot contours for [0.05, 0.10, 0.25, 0.50m] drawdown. However, we're struggling a bit with the trade off between grid and calculation time. Currently, our model runs +/- 10 mins for a single line segment to be drained (Riverstring) with approx. 14 timesteps of 1d, which is quite a long time... If we have a coarse grid, we'd miss the 0.05 contours by far, but for a fine grid, we'll have to wait for so long.

My guess is that we're overlooking something. Any tips on best practices to retrieve accurate drawdowns?

[mbakker7]

Good question. Head contours can take a bit of time to compute, especially when you have a lot of elements (or a strings consists of a lot of elements), you have a lot of layers (so reduce those if you can), or you have lot of log-cycles of time. Regarding the log-cycles, that is between the tmin and tmax. For contours, you often only need 1 or 2 log cycles, depending on your boundary conditions. So if you want contours for 1, 2, 3, and 4 days, don't set tmin to 1e-5, but simply to 0.1 or even 1, and tmax to 10. If you want contours at multiple times, it is often quicker to compute a grid with the headgrid function, which can take multiple times, and then make the contour plot yourself. Final comment: We have talked about using multiprocessing to compute a grid. That is not difficult to implement and will use all the cores on your computer to compute a grid. I will make an Issue right now, so I don't forget.

[dbrakenhoff]

Yes, this is something we're definitely looking into and want to (at least partially improve) in the short term. I think we're looking at 2 strategies to improve computation times for obtaining heads, one is to build smarter grids (i.e. triangle meshes that coarsen away from your elements), and the other is what Mark already mentioned, to parallelize the computation.

[mbakker7]

I will convert this question to the Discussion section

[mbakker7]

See issue #81