Add WellModel #129
Add WellModel #129
Conversation
add support for distances to WellModel
add notebook that only runs the relevant model between tmin and tmax, edit original notebook to fix path to data
for different wells in WellModel
add option to sort wells in WellModel
Codecov Report
@@ Coverage Diff @@
## dev #129 +/- ##
==========================================
+ Coverage 65.52% 65.65% +0.12%
==========================================
Files 31 31
Lines 3275 3296 +21
==========================================
+ Hits 2146 2164 +18
- Misses 1129 1132 +3
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## dev #129 +/- ##
==========================================
+ Coverage 65.52% 65.59% +0.07%
==========================================
Files 31 31
Lines 3275 3375 +100
==========================================
+ Hits 2146 2214 +68
- Misses 1129 1161 +32
Continue to review full report at Codecov.
|
|
I will look at the code later today and probably merge the PR (just had a quick look and it al looks fine). I just need to read the issues #201 and #108 a bit and compare to the formulas we used in the Pastas paper and check if the notebook still works. Do you have example notebook to go with this PR? That would be a nice addition :) |
|
I modified the existing example_Wellmodel.py to show how it works. I think I can easily convert that into a notebook if that is preferred over a Python script. |
|
As I was afraid this PR changes the result of the example 2 of the groundwater paper, which is not something we want. Most likely this is caused by the scaling of the step response. Maybe we best add a new response function to rfunc.py? EDIT: I'll read a bit through #108 tomorrow and put some more thought into this. |
|
Do you think the boundaries of the parameter or the different value of I can't solve the example from the paper with the LmFitSolver because of the covar error you mentioned elsewhere in #133. But I do get a fairly similar result when solving with LeastSquares and multiplying the parameters and stderr by the factor 2*k0(rho). Left is my result, and right is the old result.
Having said all that, I do think a new rfunc is a good idea though, that way all the weirdness caused by the WellModel can be contained in a separate class. I think that's clearest from the user perspective. It can inherit from Hantush and only needs a extra few lines of code. If you agree, I'll set it up. |
- remove changes related to WellModel from Hantush - add new rfunc HantushWellModel - change params to A, lab, cS - set initial, pmin, pmax for lab to 100, 1, 1e6 - set gain() method to calculate the A Hantush returns now - set meanstress to the max of the std of the stresses
…ameters option to get parameters with distance
|
As you can see I went ahead with your suggestion for a new rfunc class. It's better this way, as the differences between Hantush and HantushWellModel are now more obvious (instead of being hidden in if-statements in the code). |
|
Nice! I'll check it now and hopefully merge soon :) |
|
Okay all looks good and ready to merge! The notebook looks very good now, really like the stack_plot. This could become a nice new plotting method acutally! Where all contribution are stacked. I think at some point we might want to provide the stresses from a csv-file and move away from the Menyanthes file but that can be done later. One small question before merging:
|
|
Theres no real need to sort the wells, I just wanted a nice list ordered by distance for myself and I figured others might too, so i added it as an option. I have a few models with quite a few wells in the WellModel and then it help keep things a little more organized if they're sorted by distance. |
Okay makes sense. I added the keyword to the dump method. In general all arguments used in the init method of a stressmodel need to be written in the dump method :) Merging now. Thanks for the PR! |
Add WellModel to pastas: