Application

Gempy-drivers gives ANALYST users the ability to run GemPy’s geological modeling engine through a ui.json dialogue. The user selects data constraining the model and any options controlling the process. Upon execution, gempy-drivers will reformat the data and make an API call to GemPy, collect the results and re-package into geoh5py objects for display in ANALYST.

Methodology

GemPy’s implicit modeling engine is based on a cokriging method ([LaCM97], [CCCG08]). Geological information in the form of contact, orientation and fault markers are interpolated as a 3D scalar field that represents boundaries between geological domains. See the GemPy Documentation page for more details.

GemPy supports two main types of observations. The first is a contact observation that lies within the surface that it describes. The contact points can either contain orientation data or not. The second type is an orientation observation that may either be within a surface or not.

_images/observation_types.png

GemPy observation types: A contact point (left), an orientation in a contact (right) and an orientation not in a contact (middle).

There are three types of geological events supported by Gempy: stratigraphy, faults and unconformities. In the absence of faults or unconformities, stratigraphy events are considered conformal and will belong to the same structural group. Faults belong to their own group and are not considered conformal. To model distinct stratigraphic series that are not conformal with each other, a fault or unconformity must separate the stratigraphy events in the reference map representing history.

There are a few rules that need to be followed to generate a valid structural stack in GemPy. The first is that every event must contain at least one contact point. The second is that each conformal group must contain at least one orientation. The gempy-drivers package includes an input validation layer that will catch these user errors and provide a useful error message suggesting how to fix the problem.

_images/validations.png

Before running gempy-drivers on this data, the user will have to provide at least one orientation, and set at least one point as a contact. If run by mistake, gempy-drivers will fail to run while indicating that it’s missing both a contact point for the Mississippi surface and orientation for the structural group.

Note

Unconformities are not yet implemented by gempy-drivers.

Input

_images/uijson.png

gempy-drivers dialogue.

Observations

The constraining data must be organized into an points object and selected in the dialogue. Creating or adding vertices to a Points object is done with P + left-click in the ANALYST viewport.

_images/observations.png

Points object containing constraining data.

The observations object must contain data for orientations, contacts, faults, and history.

_images/data.png

Constraining data.

These can be created by right-clicking on the points object and opening the script dialogue.

_images/scripting_data.png

Using scripting to initialize data channels.

Orientations

Orientation data are provided by azimuth and dip channels collected into either a strike and dip or dip direction and dip group. Users can create the azimuth and dip channels from the script menu by providing a float value.

_images/orientations_script.png

Creating the dip data channel.

Both the azimuth and dip channels can then be collected into a group by right-clicking the observations object, selecting Group Data and choosing one of the special types Strike & dip or Dip direction & dip.

_images/orientation_group.png

Creating the orientations group.

Contacts and Faults

The contacts and faults data channels can be created by providing a true or false value in the script dialogue.

_images/is_contact_script.png

Creating the contacts data channel.

History

The history is represented by a reference data object and is created by providing a string in the script dialogue. The string should contain the name of the event that the point is describing.

_images/history_script.png

Creating the history data channel.

To add other events categories to the history map, the user can save the references to disk, edit the file to add the new definitions, and then re-load back to the project.

_images/new_categories.png

Adding new categories by saving to disk and re-loading. Circled buttons are (top) save and (bottom) load.

The history map must be ordered in geological time so that the oldest event is at the bottom of the list.

Output

The output of the gempy-drivers is a geological unit model, stored as Referenced data on the input mesh, and a set of surfaces that describes the geological model. The surfaces and model are stored in a UIJson group container.

_images/results.png

Output from gempy-drivers.

References

[LaCM97]

Lajauni, D.; Courrioux, G.; Manuel, L.: Foliation fields and 3D cartography in geology: Principles of a method based on potential interpolation. Math Geol 29, 571-584 (1997).

[CCCG08]

Calcagno, P.; Chilès, J.P.; Courrioux, G.; Guillen, A.: Geological modelling from field data and geological knowledge: Part I. Modelling method coupling 3D potential-field interpolation and geological rules, Physics of the Earth and Planetary Interiors 171, 147-157 (2008).