.. _export: 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. .. figure:: /images/observation_types.png :align: center :width: 80% *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. .. _gempy rules: 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. .. figure:: /images/validations.png :align: center :width: 80% *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`. .. _gempy-drivers input: Input ..... .. figure:: /images/uijson.png :align: center :width: 50% *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. .. figure:: /images/observations.png :align: center :width: 50% *Points object containing constraining data.* The observations object must contain data for :ref:`orientations `, :ref:`contacts `, :ref:`faults `, and :ref:`history `. .. figure:: /images/data.png :align: center :width: 100% *Constraining data.* These can be created by right-clicking on the points object and opening the script dialogue. .. figure:: /images/scripting_data.png :align: center :width: 100% *Using scripting to initialize data channels.* .. _orientations: 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. .. figure:: /images/orientations_script.png :align: center :width: 50% *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*. .. figure:: /images/orientation_group.png :align: center :width: 100% *Creating the orientations group.* .. _contacts_and_faults: Contacts and Faults ~~~~~~~~~~~~~~~~~~~ The *contacts* and *faults* data channels can be created by providing a *true* or *false* value in the script dialogue. .. figure:: /images/is_contact_script.png :align: center :width: 50% *Creating the contacts data channel.* .. _history: 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. .. figure:: /images/history_script.png :align: center :width: 50% *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. .. figure:: /images/new_categories.png :align: center :width: 50% *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. .. figure:: /images/results.png :align: center :width: 100% *Output from gempy-drivers.* .. rubric:: 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).