#2 - extraction well induces groundwater rising

Hi guys,
I've just another question about multilayered well boundary condition.

In a simple model (dimension 1km*3km), with Kx,y,z = 0.001m/s everywhere, I've placed a well (8640m3/d) in a point (central in respect to the upstream end downstream BC but near a river BC) where start groundwater level is rather 7.2m a.s.l.

After simulation (with convergence) feflow shows (at large scale) a downhill groundwater table around the well, as expected,  but close to it (say 15/20m radius or so) groundwater starts to rise up to 7m a.s.l. (or it remains similar to the original groundwater level).

Any idea on how it is possible?

thanks

Giuseppe

Hi Guiseppe,

This sometimes happens in case of a relatively large abstraction for a single well. You probably see an overshoot of head values at the nodes around the well nodes - on regional scale then everything is OK again. The reason for this is in the default handling of storage, that involves the neighboring nodes. To fulfill the required steep gradient towards the extraction nodes, the solution then generates a higher water level at the surrounding nodes. You can try to switch to 'Lumped Mass' on the 'Numerical Parameters' page of the 'Problem Settings' dialog to overcome the problem.

Good luck!
Peter

I have a similar issue,  When I apply a high yield well BC to the bottom slice of a 1 layer model, I get a increase in water level in the top slice near to the bore.  This also occurs in a 2 layer model where I use a multi-layer well over the lower two slices.  The inverted water table cone occurs in the top slice.  Further away the water levels in the top layer decline as expected. 
I changed to lumped mass, but that made no difference. 
I have attached a simple example.
I am wondering if this behaviour is normal, or is there a way to prevent this.
Thanks

In BoreTest.fem, the horizontal node spacing next to the pumped node is about 1 meter, and the vertical spacing is 50 meters, which is probably too large to allow accurate simulation of gradients near the pumped node. Another consideration is the hydraulic conductivity. If its small relative to the pumping rate, any simulator will have trouble with convergence.  So make sure the grid spacing is sensible and that the K is compatible with the pumping rate.  If you're not using automatic time stepping, smaller time steps may also improve convergence.

I suggest you run a test on BoreHole with a lower pumping rate or increased K. If the odd results disappear, then you know there is something about your model that needs work.

Another observation about BoreTest: the geometry of a few of the elements near the pumping node are less than ideal, which may contribute to numerical instability.

Pete

Hi Pete,

Thanks for the help. 

The K (20m/d) and pumping rate (30L/s) are from typical site conditions, so I  can't change that.  I am using automatic time-steps.

If I split the model into 5 x 10m thick layers, I still get a water level rise in the slice above the pumping node(s).  For a larger regional model it may not be practical to use more layers. 

What I am concerned about it whether the water level at the pumping node is realistic?  The ideal element size (using the multlayer well boundary condition) is indicated to have a diameter of 1.6m, to match the 'virtual radius' circle to the size of my well (0.27m diameter).  I am not clear if I am doing that correctly.  It is called a radius, but I am assuming the circle shown is the diameter and the radius is half.  And for the 'ideal element size' is the circle meant to match the typical width of 1 element.  In my case to get the virtual radius circle to match the actual well diameter, the ideal element circle is approximately the width of 3 elements? 

Do I need to have the vertical size of the elements also matching the 'ideal element size'?

Hi Mark,  Its not clear to me how you've determined the ideal element size, but you can test the effect of lateral spacing of nodes by reducing that spacing. The simplest way would be to add elements around the column of pumping nodes.  If the simulated water level at the pumped node is significantly different, you know the spacing is important for computing that water level (and water levels near the pumped node). You can make the elements as small as you want...the element size relative to the physical size of the well is not so important to this test. 

Vertical spacing tends to be less important horizontal spacing due to smaller induced vertical gradients. 

You can also add the user data distribution $error_norm_flow (look for "predefined distributions" in the help). After you run the simulation, this data distribution is the computed error at each node in the model.  You may find that the pumping node has the largest error and therefore the least accurate simulated water level.

Pete

Hi Pete,

Thanks for the help.  When I use multi-layer well boundary conditions and select 'ideal element size' under attributes in the View Components Panel, Feflow draws a circle around the boundary node, which I am guessing is the size of the first ring of elements around the boundary condition node to be accurate. 

There was some discussion on this in another post, but it wasn't clear how to compare the elements to the 'ideal element size' circle.  It seems to be that if I match the 'virtual radius' circle to the actual bore casing diameter, the ideal element circle covered outside the nodes surrounding the BC, so in my example encapsulates 8 elements.

I previously used elements at wells so that there was nodes at the edges of the casing and one in the middle,  but this seemed to over-estimate the draw-down at the well, and the 'virtual radius' circle was smaller than the actual casing diameter.

I see. I hadn't used this feature of FEFLOW before, but looking at the help file, the "ideal element size" seems fixed regardless of the pumping rate. When I change the well radius (which is the radius of the vertical pipe element feflow internally assigns), the "ideal" radius changes, but the rate has no effect on the "ideal" radius. 

However, the larger the pumping rate, the larger the hydraulic gradients at the well node and associated pipe elements, which to me means that elements have to be smaller (nodes closer together) to get an accurate simulation of heads in and near the well.

The help file states this: "Due to spatial discretization in numerical modelling, the hydraulic head resulting from the simulation at the well nodes themselves highly depends on the size of the elements around the well location. " 

So while I don't understand why the ideal radius isn't also a function of the pumping rate, it is clear to me that smaller elements are needed as the pumping rate increases. In any case, the way you describe your problem leads me to think your node spacing (and hence element size) is too large. 

You basically tested this when you put nodes closer to the pumping well. your result was more drawdown, which is exactly what I would expect with a more accurate simulation. The drawdown wasn't over-estimated in that simulation, it was more accurately calculated.  FEFLOW is simulating an ideal pumping well but your field data comes from a realistic (non-ideal) well.

Pete

Smaller elements doesn't necessarily result in more accuracy for a well node.  There should be a minimum element size below which the model over-estimates drawdown, just as a small diameter well will have a greater drawdown than a larger one, due to the smaller cylinder of surface area outside the bore that the water must flow through.

It would be helpful if there was more explanation about the 'ideal element size' and 'virtual radius'.

Mark

Actually the ideal element size is the element size that gives you the 'correct' drawdown - with smaller elements you over-estimate, with larger ones you under-estimate. With this element size, the virtual radius is equal to the real well radius. Please note that the calculation of the ideal element size and virtual radius is based on a 2D analytical solution (no 3D effects of the well, no regional gradient). For most cases, this assumption is no problem at all.
You can find some information in chapter 13.5.3 (page 690) of the FEFLOW book. It refers to borehole heat exchangers and heat transport, but the concept is exactly the same for a well.

Hi Peter,

Thank you for the clarification. 
My original query was about an apparent groundwater rise in the slice above the well boundary condition node.  Is this an artifact, which I can ignore, or should I be reducing the vertical element size?

Thanks,

Mark

If it is not a huge rise, I'd ignore it as an artifact. Reducing the element size vertically would most probably work, but at a relatively large expense in the sense of additional nodes - so if you can get away without it, you should try.

The 'ideal element size' is based on a 2D analytical solution applied to a 3D system? What analytical solution is used? The Book doesn't indicate for flow-only situations.  I agree that smaller element size (closer node spacing) may not result in more accuracy because at some point the numerical approximation will match the continuous PDE very closely (within the limits of the machine). 

What Peter is calling an "over estimate" is not the same thing as numerical error. When you add nodes (smaller elements), the simulation is indeed more accurate (or as accurate as the machine precision allows) but the computed drawdown values at nodes inside the "virtual radius" (the actual or physical radius of the pumped well) do not represent what actually happens inside the bore hole.

I assume the analytical solution Peter refers to is the typical one developed by CV Theis.  The Theis solution does not apply to what actually happens inside of the bore hole either. However, both the numerical and the analytical solutions can be used to compute drawdowns within the radius of the bore and, since the bore hole is not actually simulated by either, both will provide accurate results for a point sink  (one of the assumptions for the Theis equation is that the borehole is infinitely small).

I wonder if the virtual radius is really a good guideline for node spacing near the bore hole in cases where one wants to simulate drawdown near to, or at, the borehole wall. Maybe I will do some tests.

As for the artifact (numerical error), I agree with Peter that its not that important provided (1) you are not attempting to accurately simulate the drawdown near to, or at, the wall of the borehole and (2) the error doesn't overwhelm your mass balance. 

I think Mark did get more accurate results when he added nodes.

Pete