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
980 stars 233 forks source link

Fault_Block #503

Closed Ali1990dashti closed 4 years ago

Ali1990dashti commented 4 years ago

What is your question? Dear all,

Hope doing well and being healthy. I have a question about the possibility of showing the effect of a fault on the output model of gempy. To my understanding, after exporting our model the block ID of faults (lets say 1) is not observed in the grids which means faults have not any volume i.e. faults just displace adjacent blocks. A way is to propagate a layer sandwiching the fault between layers (a highly informative example is presented in https://github.com/Japhiolite/gempy-tests/blob/master/notebooks/Test-model_dyke.ipynb). In this example, a dyke layer is proposed to represent the effect of fault. But it seems too tricky to develop a very thin layer around the fault in a 3D model. Is there any other way to show the effect of the faults (except displacing layers) on the model? In advance, I appreciate any contribution and help.

Cheers, Ali

javoha commented 4 years ago

Hello @Ali1990dashti,

as of now there is no function in Gempy to add fault core or damage zone. Some reasonable workarounds are discussed here: #326 . It is also on our list and might become a feature in the future. Can you maybe also specifiy why the solution in the notebook you linked does not work for you scenario?

Best wishes, Jan

Ali1990dashti commented 4 years ago

Hi @javoha

Thanks for your informative response. The solution in the notebook cannot be applied fpr 3d models. I added several surface points and orientations for the dyke but still this series doesn't propagate like a thin layer parallel to the fault. By adding the inputs of the dyke, model was getting more and more local and it is giving me the dyke as finite bodies around the input data, instead a of a layer with parallel boundaries. A screenshot is dragged here. pic

Also by decreasing the thinckness of dyke, the results of model get more problematic. I tried to play with the range parameter of kriging (using geo_model.modify_kriging_parameters('range', ...)) and increased it but still it was not enough and I could not achieve my goal. Thanks again to the community for being responsible and making research easier.

flohorovicic commented 4 years ago

Dear @javoha and @Ali1990dashti ,

This could also be another potential application of a hierarchical modelling method, as a bit of a workaround, by maybe giving @Ali1990dashti what is needed at the moment.

Essentially, it would be a combination of two models:

  1. The "base" model with the fault as offset, as it is now;
  2. A "dike"/ "fault core" model, which contains only the points and orientations for the fault - shifted in plus/minus directions orthogonal to the fault plane and in a conventional "geological series" order

Finally, you would have to re-combine results of both models for visualisation and export. To see how this could work, I would suggest to start with a voxel export first - and simply to replace the voxels of model 1 with those of model 2 where the dyke/ fault core is present.

Not sure if this approach would solve your question, @Ali1990dashti , but maybe worth a try.

Ali1990dashti commented 4 years ago

Dear @flohorovicic and @javoha

I really appreciate your excellent hints. I tried to make two separate models (base model and dyke model) and replace the dyke layer of my dyke model with the existing lithology ids in the base model. The simplest way to replace it is using pandas dataframe (base_model.loc[dyke_model.lith_id==2, 'lith_id']=5). The following picture was the result: fig

javoha commented 4 years ago

This looks pretty great and like a straighforward and solid solution. Is this sufficient to solve your problem?

Ali1990dashti commented 4 years ago

Yes, proposed methods were truly efficient. Thanks for helping.

flohorovicic commented 4 years ago

Great to see that the solution worked! Seems like you are approaching a "gempy-wizard" status!

AlexanderJuestel commented 4 years ago

Closing this issue as it seems the problem was solved. Feel free to reopen it if there are more problems coming up.