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

[andreitablan]

Follow-up to prior comment on drawdown contour extraction, @mbakker7:

We're using TimFlow to generate drawdown contour shapefiles around drainage lines (RiverString) to visualize the spatial impact of dewatering, including areas with small drawdown (e.g. 0.05 m), just like @justuskrantz mentioned.

Finding: Head Collapse with RiverString Alone

With RiverString, drawdown and head contours are accurate near the drain. But when we increased the buffer (hundreds of meters), groundwater heads in the far-field tended to collapse toward zero, producing unrealistically large drawdowns (0.9–1.1 m) across the domain (head around 0.0 m for a target head of 1.0 m), rather than a gradual decay. This made contours for small drawdowns (like 0.05 m) impossible to generate.

Attempted Solution 1: Adjust RiverString Parameters

We tested modifying these parameters from the default res = 0 and wh = 2h:

• Changed res=100 to add finite resistance
• Changed wh='2H' to allow water entry from both sides
  Result: No improvement. The head collapse persisted with the same physics, and drawdown ranges remained large with no far-field gradient.

Attempted Solution 2: Boundary HeadWells

We added HeadWell elements at the domain boundaries (fixed at the phreatic level) to anchor far-field heads. This improved the model, producing a realistic gradient and allowing small drawdown values [0.05, 0.1, 0.2, 0.5] m expected to be generated.

However, the HeadWells created a new problem: The exported contours were dominated by the wells themselves rather than showing the drainage line's impact zone. The contour shapefiles displayed circular patterns around the four boundary wells at the domain corners, not realistic drawdown gradients around the RiverString. The wells became the visually dominant features instead of the drain.

Questions:

• Why does RiverString produce unrealistic far-field behavior? When using RiverString alone with an expanded evaluation buffer, heads collapse toward zero rather than maintaining a realistic gradient. Is this expected behavior for line sinks without boundary conditions? What is the physical mechanism?
• What is the recommended boundary condition strategy for multi-feature models? For domains with multiple water features (rivers, lakes, drainage lines), what is the best approach to constrain far-field heads realistically without creating artificial singularities that dominate the contour export?
• Are there alternative element types we should consider? For large-area impact analysis, are there better choices that naturally represent far-field effects without point-source artifacts?

Thank you!

[mbakker7]

Thanks for your question. Managing the far field is an important issue. Not quite sure I fully understand your question though. Could you clarify the following:

1. Is this for timflow.steady?
2. Can you post a minimal example that shows your problem?
3. Can you create a new Discussion as this is a different topic than the topic you repsonded to. A better topic would be: How to specify far field conditions for drainage problems.

[andreitablan]

Thanks, I added more details here: https://github.com/orgs/timflow-org/discussions/84