Changing Hantush step function for WellModel

[dbrakenhoff]

As discussed at the Pastas meeting, I would like to propose changing the Hantush step function to allow individual stresses in a WellModel to have a different "steady-state" influences as determined by the distance to the observation point. In the current implementation each well has the same steady-state influence regardless of its distance to the observation point.

I'm posting this to check if there are other changes that need to be made as a result of this adjustment? This changes the value of the parameter A (as compared to the other response functions in Pastas), which perhaps should be described somewhere.

The adjustment would change

def step(self, p, dt=1, cutoff=None):
   ...
   return p[0] * F / (2 * k0rho)

to

def step(self, p, dt=1, cutoff=None):
   ...
   return p[0] * F

[raoulcollenteur]

Sorry for the late response. Can we implement the redial distance r as a parameter, that is fixed by WellModel but free by default? If so, I think this would be the preferred.

A should be the value of the step response as time goes to infinity. Is this possible as well?

Also, I have noticed the block response is not smooth with some parameters combinations, seen that before? E.g.,

import pastas as ps
import matplotlib.pyplot as plt
b = ps.Hantush()
plt.plot(b.block([4, 5, 10]))

Right after the peak the curve is not smooth..

[dbrakenhoff]

In my previous attempt at something along these lines, I added r as an optional parameter in Hantush by checking the length of the passed array of parameters:

pastas/pastas/rfunc.py

Lines 288 to 292 in 52f0491

	def step(self, p, dt=1, cutoff=None):
	if len(p) == 4: # distance is provided as param in p[3], rho = p[1] * distance
	rho = p[1] * p[3]
	else: # distance is not provided as fixed param so rho is p[1]
	rho = p[1]

Which I agree is a bit vague.

If we add r as a parameter, how do we deal with that in the solver? The solver won't be able to distinguish between r and lambda under normal conditions (when both are free). When the WellModel is used, and r is set to a fixed value that isn't a problem.

[dbrakenhoff]

Also, I have noticed the block response is not smooth with some parameters combinations, seen that before?

FYI, the non-smooth block response for those parameters has been that way for all implementations of Hantush we've had so far. Not sure if that puts you at ease, but that's all I know...

A should be the value of the step response as time goes to infinity. Is this possible as well?

The value of the step response as time goes to infinity is A * (2 * k0(rho)). The reason for this is because that factor 2k0(rho) is dependent on the radial distance. By keeping that factor out of the value of A, the optimization of a WellModel will result in the three parameters (A, rho, cS) that are common to all the wells. Then A and rho still have to be scaled by the known radial distance for each well. So I don't see how we can make the above possible if we make A equal the value of the step response as time goes to infinity.

Can we implement the redial distance r as a parameter, that is fixed by WellModel but free by default? If so, I think this would be the preferred.

• The radial distance is normally contained in the parameter rho. By adding it as a parameter, this might be confusing. You could then add lambda instead of rho as the other parameter, but the optimization should use rho (under normal circumstances) and not these two parameters individually. So that would be a bit confusing in my opinion.
• In a WellModel this parameter r needs to be passed to Hantush to scale the parameters. There are multiple wells however, so multiple values for r, and there is just the one Hantush response.
• A solution would be to create a new Hantush with parameters r and lambda, in which r does not vary by default. A WellModel then overwrites the fixed parameter r for each individual well. This is also a bit weird because you will see a value of r in the parameters that is determined by the last well in the simulation.

So I'm not so sure we want this. Your thoughts?

[raoulcollenteur]

PR #129 will fix this issue by implementing the HantushWellModel response function to rfunc.py.

The final value for the Hantush function remains A now.

Closing this issue.