Simulating borehole falling head test

[nlosacco]

Hi all,

I wish to simulate a variable head permeability test (Lefranc test) in a borehole. A borehole with an open tip is filled with water and the decrease in water level in time is measured. Few possibilities:

1. simulate the borehole as filled with a fictitious porous very permeable material, with a quasi step-function water retention curve
2. simulate water in the borehole with as a fluid in an Eulerian mesh, copuled at the bottom with a lagrangian mesh of the soil, where the varying water flow at the bottom acts as a flux into the soil

1 is feasible but i’d rather go for 2 as it’s more realistic and does not require fictitious material properties.
Is there such a possibility in MOOSE? What options should I look at? Any other suggestions?

[josebastiase]

Hi,

An alternative would be to write a ScalarKernel, with the variable being the height of the water in the well (or the porepressure at the bottom, etc – whatever is convenient. i.e. dh/dt ), which gets fed the water from your Sinks. This is fully-coupled. Look at things like ParsedODEKernel, or PPValue, and (Coef)ODETimeDerivative. Ideally, you want the Jacobian (derivative of height of water wrt the porepressures at the well screen) to be correct so your fully-coupled system converges nicely, otherwise you might be forced back to short timesteps.

Try to make MOOSE to compute the coupling between variables in every non-linear step.

Try this as an starting point
https://github.com/josebastiase/TSA---Numerical-study/blob/main/Fig_7/S6/k10/Sim_files

I hope this makes sense

[nlosacco]

Thanks @josebastiase I’ll have a look at the link. Although, maybe I misunderstood, there are no sinks in the model, but water from the water column itself should infiltrate into the porous soil at the bottom. And the water column height should decrease consequently

[josebastiase]

yeah the sink is the conection between your well and your porous media. So you have a sink/sourve which moves liquid in/out of your system based on the column of your well

[nlosacco]

Hi @josebastiase
I started from your examples and modified them to suit my needs, but I'm quite stuck. I'm simulating a simple falling head test, in plane strain, the soil column is 1 m wide, 10 m tall, and the initial water column in the well, at the top of the soil column, is 10 m.
A zero porepressure is applied at the bottom at all times. Can you have a look at my input file? Please find it attached.
I have convergence issues, the problem won't converge with default settings, if I increase nl_abs_tol to 1.E-8, for instance, it converges but mostly it does not iterate (which I assume means it's not solving anything). And when I manage to make it converge, the height of the water column h does not change during the analysis.
test.i.txt
Thanks,
N

[nlosacco]

Hi all, @vabufano

somehow I managed to get what I expected, but I really don't know how. I need someone to explain better how the execute_on flags work, as this seems to be the key issue.
With respect to the approach proposed by @josebastiase (many thanks) I tackled the problem in a simpler way, i.e. by using a simple Diffusion Kernel. As in the previous file, the rate of water level change in the borehole, dh/dt, is given by the flux Postprocessor, that is a NodalSum of nodal fluxes, saved into the AuxVariable fluxes by a CoupledVarNeumannBC. The latter uses another AuxVariable diff equal to pwp - wellPP at the boundary, where pwp is the nonlinear variable of the diffusion kernel, wellPP is an AuxVariable representing the pressure of the bottom of the borehole (set equal to the scalar variable h).
I copied the entire Preconditioning block from Jose's example (no idea of what all those options are) but used a standard Executioner.

Now, the only way to make all this stuff work was setting execute_on = 'TIMESTEP_BEGIN' for the flux Postprocessor, while for the AuxVariables diff and wellPP I also had to set execute_on = 'LINEAR NONLINEAR'. Can someone explain me why? Shouldn't I compute flux also during the iterations? If I do the analysis goes bananas.
Also, with this approach the flux is 0 at the first timestep, can I have it start with the correct value?

Thank you in advance

test2.i.txt

[GiudGiud]

Hello

When you pick execute_on flags you are defining the numerical scheme. Executing on linear is as often as possible, while you are solving the linear systems on every iteration.
nonlinear is in between each newton / nonlinear iteration

timestep_begin is only once per time step. This is lagging the quantity, you freeze it at the beginning of the time step.

This decision on the execute_on flag can influence the time integration scheme convergence order. It also generally helps to lag things to get convergence. It s a double edged sword

Guillaume