Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hierarchical modeling #4

Open
agzimmerman opened this issue Feb 26, 2020 · 6 comments
Open

Hierarchical modeling #4

agzimmerman opened this issue Feb 26, 2020 · 6 comments
Assignees

Comments

@agzimmerman
Copy link
Contributor

agzimmerman commented Feb 26, 2020

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
Copy link
Member

flohorovicic commented Feb 27, 2020

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

@MohammadCGRE MohammadCGRE self-assigned this Feb 27, 2020
@Japhiolite
Copy link
Contributor

Japhiolite commented Feb 27, 2020

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
Copy link
Contributor

Japhiolite commented Mar 6, 2020

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
Copy link

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
Copy link

AlexanderJuestel commented May 20, 2020

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
Copy link
Member

Leguark commented May 20, 2020

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

@Leguark Leguark transferred this issue from gempy-project/gempy Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants