gempy-project / gempy

GemPy is an open-source, Python-based 3-D structural geological modeling software, which allows the implicit (i.e. automatic) creation of complex geological models from interface and orientation data. It also offers support for stochastic modeling to address parameter and model uncertainties.
https://gempy.org
European Union Public License 1.2
983 stars 234 forks source link

Fault displacement, throw, heaven #198

Closed HighPerformance01 closed 7 months ago

HighPerformance01 commented 5 years ago

Hi all,

In the case were fault displacement, throw, heaven needs to be taken care of carefully, how is this represented in gempy 2. All I see is a list of points locations and orientations where I am not sure how the displacement, for example, is inferred.

Thank you

javoha commented 5 years ago

Hi,

one of the problems of defining the fault offset (or throw and heave) is the 3D environment. The offset of your fault probaly varies. Are you sure that you have a constant fault offset throughout your entire model? Or do you only need it for a certain cross-section?

As far as I know there is no "official" way to do it right now, but there might be reasonbale workarounds to estimate the offset for a slice of your model.

HighPerformance01 commented 5 years ago

Thank you very much Javoha for your response

You are right that there is maybe no "official" way to do it right now

However, I need to take care of that somehow and one of the options is to build on gempy giving the great effort that has been put so far on the core engine

So for now, I need to just understand how gempy is inferring at least the current displacement around the fault especially when the fault does not partition the geological model

So maybe it gets this from x,y,z pointset and will stop interpolation from both sides

So would you please let me know the full picture here around the fault displacement that currently noticed in many of the example provided?

For the example provided with gempy we may notice the difference in elevation of the horizons if we look to the right or to the left of the fault.

Thank you

Leguark commented 5 years ago

The fault offset is calculated by minimising the variance of the scalar field considering a drift of the first moment. The current behaviour right now is that on the fault plane we "allow" to we a sharp change of value and therefore having an offset is the option that minimise the variance the most.

In short, the location of you surface points will dictate the offset. This has the current limitation that the offset must be constant over the whole fault or otherwise will produce some artefacts in the layers. We know how to correct this behaviour but this is in experimental phase yet.

Another experimental feature is to add the offset as a parameter instead of being inferenced by your input data.

May I ask what your project is about? If it fits with the direction of GemPy development we could try to set a collaboration.

HighPerformance01 commented 5 years ago

Thank you Leguark for your answer, that is very helpful.

Definitely, once we are clear about the practicality of our ideas and we are sure we are not repeating other work, we will be discussing this more here but it is still in the early stages.

andrea-bistacchi commented 5 years ago

Hello @Leguark, I've just seen that in your answer of July 11 you say that: "This has the current limitation that the offset must be constant over the whole fault or otherwise will produce some artefacts in the layers."

Is this true also for finite faults? I guess that for these the offset should drop to zero at the tipline. However, if the offset is constant within the fault and drops to zero at the tipline, you will have a sharp discontinuity in the stratigraphy. How does it work?

In any case, it would be more clear if it is possible to record the offset as a property of the each fault surface, and then visualize it e.g. in Paraview.

Thanks!

Leguark commented 5 years ago

You are right. In the finite faults we have some function to manipulate the offset at the tipline but again this is all very prototype stage and we do not even know if a paper can be worth publish with some ideas around faults. The thing is that "offset" is not an input parameter with the current implementation. It could be possible to get a proportional value by evaluate the scalar field values jump at both sides of a fault and we have some ideas in that direction but I did not try yet.

Again, finite faults are there, feel free to use them, feel free to try to understand them but it will take some time until they are in a production level quality.

andrea-bistacchi commented 5 years ago

Dear @Leguark , if I remember well the "offset function" in Geomodeler is elliptical, or something like that, in any case with a progressive tapering of offset from centre to periphery of the fault?