gempy-project
Variogram Modelling with Gempy?
Is your feature request related to a problem? Please describe. I am looking to model valiograms similar as shown in GeoStatsGuy:GeostatsPy_variogram_modeling.ipynb.
Gempy would be one of the options. I understand that there is some basic functionality in
gempy.assets.kriging. However this module might still be missing the full functionality to calculate the variograms resulting from the interpolated grid.
Also I am aware, that the main layer modelling process is based on Kriging as well and uses a theano based approach, which in theory can be much faster then direct implementation in numpy.
What would be the way to go to implement this functionality? The main steps needed would be:
- Generate a theoretical variogram model
- Generate the covariance Matrix based on the distance matrix
- Perform some sort of spatial interpolation (e.G. Simple Kriging)
- Calculate the actual variogram based on the interpolated grid data
- Plot the calculated variogram
1,2, and 3 are available in gempy.assets.kriging based on a direct numpy implementation without any orientation transformation and superposition of theoretical variogram models. Would it be possible and/or advantagous, to reuse functionality from the layer modelling interpolation process in theano?
4 and 5 I have not found yet and would be necessary to be implemented I think. I could implement something based on the functionality in GeoStatsPy.
Another thing I am missing in the functionality is to be able to split the 3D domain in N-2D layers along one axis for 2D spatial analysis. Maybe this would be a way to make this feature request a lot easier and more approachable.
Describe the solution you'd like Implement a functionality to split 3D-domains into N Layers along a (major) axis.
Implement some sort of functionality, which allows to model more complex analytical variograms with orientations (transformations) either in 2D or 3D.
Implement some sort of functionality, which allows to calculate resulting variograms with orientations (transformations) from interpolated 2D or 3D grid data.
Finally: I am happy to start working on this, but I wanted to check in with you guys first to discuss the best way to go on this, since I am not too familiar, with whats actually there yet.
hey @TobiasGlaubach, I think there is a functionality for splitting the 3D domain existing in the "sections" grid functionality, which describes a 2d "slice or cross section" between two points in the 3d domain, see the tutorials/notebooks for examples. However there isn't currently direct support for N Layers which to me sounds like you want to generate fence diagrams or N cross sections. It should be relatively easily to use the Sections grid type to make this functionality however. If you want vertical slices (on the xy plane) however then custom grids could be used.
Hi @TobiasGlaubach, great to see that you are looking into this. Maybe I can provide some insight and my opinion on a couple of your suggestions.
You already made this quite clear, but I wanna emphasize again the difference between the universal cokriging approach that is underlying the core gempy modeling algorithm (potential field method) and the kriging in assets (we often call it property kriging to distinguish it), that aims to perform spatial interpolation/simulation of (geologic) properties within a defined domain of a Gempy model.
For the underlying cokriging algorithm (@leguark correct me here if I am wrong) the used variogram is just a linear model and while we acknowledge that its has an effect on the resulting model, it is not easily possible to infer a better model from the "data", as this data is the "artificial" scalar values we construct for the surfaces (layer boundaries).
Regarding the Kriging in assets: I wrote that code for my master thesis project and it only provides very, very basic functionailty. There are many libraries that offer great geostatistical support (you named GeoStatsPy, but also GSTools). It would be great though to have functionality like proper varigoram modeling (including anisotropies, more models, etc.) in this module, and help would be greatly appreciated. A faster implementation would be interesting in the long term, but I think there are things that are more useful to do first.
From my perspective it makes sense to keep it decoupled from the core functionality though as it tackles quite different problems. But I would be interested to hear more opinions on that.
I hope was able to offer some context, I think it is maybe helpful to understand how this structure evolved. Thanks alot again for looking into this and I would love to see some work done on the assests.kriging module. If you are interested in this I would be happy to talk some more (maybe videocall?).
Best wishes and stay healthy, Jan
@javoha Hi Jan and thans for your reply. I asked about the core functionality since I was wondering maybe if the implemented cokriging algorithm in theano could be used / hijacked to perform property kriging as well, since it seems to be a quite effective implementation. But if it's not easily possible I agree that keeping things seperate might be the better option.
Also thanks for pointing out GSTools I actually just found this toolbox today when looking into alternatives. I will have a look and see where to go from here, maybe marrying the two libraries, (since we generate the layer model from data in gempy) would be the best way to go from here.
@AndrewAnnex Thanks for pointing me to the right direction. If getting single layers is possible I can easlily get N layers as well with a little bit of code.
I will post on this issue again, when I know where to go from here. Either start working on it or use different libraries for different problems.
Hi everyone, we decided to use GSTools for the variogram modelling stage and property Kriging interpolation. So we will keep things seperate and I will not work on implementing property Kriging in gempy.
Therefore for me this functionality is not needed anymore. Thank you very much for your support though. Do you want to keep this issue open in case someone else wants to pick it up and start working on it?
Hey all (and thanks @javoha form mentioning), sorry for being late to the Party. Sebastian here, Core-Developer from GeoStat-Framework and GSTools. What about a collaboration? We provide kriging and (conditioned) simulation implemented in Cython. GSTools will soon be released in version 1.3 and I'd be happy to work on more Interoperability in the future.
I think gempy and GSTools could really complement each other!
Cheers, Sebastian
