gempy-project / gempy_engine

European Union Public License 1.2
1 stars 0 forks source link

Hierarchical modeling #4

Open agzimmerman opened 4 years ago

agzimmerman commented 4 years ago

Is your feature request related to a problem? Please describe. Problem: different interpolation approaches may be required for different geological features on multiple scales, or simply different geological domains. This requires separating the entire modelling domain into sub-zones.

Describe the solution you'd like Ideal: a high-level function/ class which allows to create a domain separation and a hierarchical definition of models.

Describe alternatives you've considered Trying it all with one scalar field -> doesn't work...

Additional context n/a

flohorovicic commented 4 years ago

Hierarchical Modeling - some background

We often have several regions in a model domain with different geological elements. In this case, a global interpolation will very likely cause problems.

Simple example: faults, different models on both sides (although this is an aspect that can be handled with gempy - serves here as purpose of example). A typical procedure would be to:

  1. Define a model to separate the entire modeling domain into different regions
  2. Interpolate a model in each of these regions separately (note: the model will be defined in the entire domain, but only "active" in a specific region)
  3. Combine a final model using the high-hierarchy "domain map" and the corresponding low-hierarchy submodels.

A simple example for the fault case (not using gempy, but just a simple 2D field interpolation): CGRE teaching - domain maps for fautls

Unknown-12

Japhiolite commented 4 years ago

geo_model.solutions.block_matrix may potentially be used as high-hierarchy domain-maps for subdividing the model in different domains. @AlexanderJuestel tested this with a simplified version of his (half-)graben system.
I also tried it with a very simple model: 2 faults, and the graben lithologies have no interface points in the footwalls of the faults. ~~When plotting the block matrices, I found a strange behaviour depending on whether change_color in geo_model.set_is_fault is set to True or False. Attached image shows the same plot: on the left with change_color=False, on the right change_color=True. Is that behaviour expected, or maybe a bug @Leguark ?~~ Nevermind, it is a feature :) fault_block_matrix_color

Japhiolite commented 4 years ago

I added a notebook replicating florians example from the teaching repository in my branch (development_janN) under notebooks/experimental. Don't know, whether that's what you meant @flohorovicic ? The last "combined" gempy model there is only to show how the result should look like.

AlexanderJuestel commented 4 years ago

Based on my current experience with GemPy, hierachical modeling is very much needed, especially if you have domains/depositional systems that can clearly be divided by an unconformity/erosional contact/transgressive surface (which may also be faulted, see Lower Rhine Embayment).

There should also be an easy way to store and load parts of the models (#399) so that you do not have to compute sub-models again.

Since I have many faults (>10 that have a significant offset) and 5-10 layers, it is very tidious to add and remove single objects manually (at least I can do it all in my notebook). You have to change the orientations, interfaces and the entry in the mapping functions as well as set faults active (and scroll through the whole document in my case). Maybe there could be an more interactive way of selecting formations and setting them active as faults (e.g. Checkboxes). You would need an identifier or a pre_mapping function to assign the right order and then easily set them active or inactive. I have to frequently activate/deactivate layers when encountering the LinAlgError since orientations are missing. This kind of relates to gempy-project/gempy#386.

Just some thoughts that I had on my mind.

AlexanderJuestel commented 4 years ago

Just adding another thought that is related to not computing sub-models again: Especially with respect to the LinAlgError, you always have to add orientations (which at least fixes the issue for me) to the model but your faults remain the same. The computational time could be reduced if you just keep the faults and just have to remodel your lithologies. And in general, faults usually do not have to be changed that often in comparison to lithological surfaces.

Leguark commented 4 years ago

Interpolate only the series that have changes is on (my mental) road map and actually most of the functionality is dormant but there