Changing a Geological Model’s Base Lithology Column
This topic describes the process of changing a geological model’s base lithology column, including some of the factors to consider when deciding whether or not to make such a change. Because changing a model’s base lithology column can have considerable downstream effects, it is highly recommended that you:
- Make a test copy of the geological model and work in that copy before committing to changing the base lithology column in the model that is linked to other objects in the project. This will help you determine what changes to lithology codes and contact surfaces need to be made without affecting and/or reprocessing other objects in the project that are dependent on the geological model.
- Make a backup copy of the geological model you can refer to once you have made the change.
- If you are working in a local project, make a backup copy of your project you can roll back to if needed.
- If you are working in a project that is connected to Central, make sure your latest changes have been published to Central before you start testing changing the base lithology column.
You can change the base lithology column to columns in:
- The same table, e.g. a new interval selection column
- A different table in the same drilling data set
- Another drilling data set
- A combined drilling data set
Before starting the process of changing a geological model’s base lithology column, see the Geological Model Lithologies topic to understand how lithology codes for a geological model are derived and prioritised; this will help you in resolving any lithology code conflicts that arise.
Contact surfaces built using the data in the base lithology column will be affected when the base lithology column is changed. In addition, a geological model’s surfaces and volumes can be used as inputs to other models in Leapfrog Works. Changing model’s base lithology column will update all surfaces and volumes that are built from the base lithology column, and so other dependent models will be affected by changing the base lithology column. Because changing the base lithology column can have such widespread effects, when you click OK to start processing this change, Leapfrog Works will prompt you to first test the changes in a backup copy of the project.
Clicking Copy to test the base column changes will discard the changes you have made in the Geological Model window, including those not related to changing the base lithology column. A copy of the model will be added to the project tree. You can then experiment in the copy before going back and making the change in the original model.
Clicking Continue will result in the geological model being reprocessed to use the base lithology column, with no copy being made.
The rest of this topic discusses first the potential effects changing the base lithology column can have on model surfaces and volumes and other models in the project. It then discusses how to manage the different lithology code changes that may be required. It is divided into:
- Effects on Contact Surfaces
- Faulted Models
- Checking for Downstream Effects
- Lithology Considerations
- Resolving Conflicts with Manually Defined Codes
Effects on Contact Surfaces
Contact surfaces built using the data in the base lithology column will be affected when the base lithology column is changed. In many cases, this is the desired effect, but in some cases the changes can result in edits to surfaces being lost when the underlying data changes. Contact surface settings are preserved with the base lithology column changes, but the types of edits that could be affected include:
- Manual edits to the surface made with polylines or structural data
- Manual edits to vein pinchouts, vein segments and vein midpoints
The most important step to take to prevent losing contact surface information should you choose to change a model’s base lithology column is to make a backup copy of the geological model. If you do this, you will have a copy of the model you can check contact surfaces against once you have made the change.
For all contact surfaces, if you have edited the surfaces with polylines or structural data, make sure the polyline or structural data table is shared rather than local. See Sharing Objects in Managing Data Objects in a Project.
For veins, export any edits you have made to vein surfaces as described in Exporting and Importing Pinchout, Segment and Midpoint Edits in the Veins topic.
Faulted Models
For faulted geological models, each fault block has its own Surface Chronology and each surface in the chronology can be modified without affecting other fault blocks in the model. This can result in a large number of complex surfaces, and if these surfaces are built using the data in the base lithology column, they will be updated when the base lithology column is updated.
Because faulted geological models can be complex, changing the base lithology column is not recommended for complex faulted models with large numbers of contact surfaces.
Checking for Downstream Effects
A geological model’s surfaces and volumes can be used as inputs to other models in Leapfrog Works. Changing the geological model’s base lithology column will update all surfaces and volumes that are built from the base lithology column, and so other dependent models will be affected by changing the base lithology column.
Use the View Relationships tool to check relationships between the geological model and other objects in the project. For example, here we can see that changing the base lithology column for the HostRock model has the potential to impact all the objects in the Outputs list:
Note that when you make a test copy of the geological model to experiment with the effects of changing the base lithology column, this will only tell you what the effects are in the model itself. Only the original geological model is linked to dependent objects in the project; copies are not linked.
Lithology Considerations
Before changing a geological model’s base lithology column, check that the lithology codes used in any surfaces already built in the model are supported in the lithology column you want to switch to.
See the Geological Model Lithologies topic for information about how lithology codes for a geological model are derived and prioritised.
When the base column is changed:
- The new base column must contain all lithology codes from the previous base column that are currently in use in the geological model.
- Any lithology codes in the old base column that are not used in the model are not required in the new base column.
- Any contact surfaces built from the base lithology column will be updated.
- Contact surfaces that do not use the base lithology column will not be changed. This includes contact surfaces that use manually defined codes.
If the new column does not contain the required codes, Leapfrog Works will not let you change the base lithology column. For example, here the model is using the column VSTRAT and we want to change it to WHLITHCOMP. The error message tells us what lithology codes are missing from the WHLITHCOMP column:
Click OK to dismiss the message, then Cancel to close the Geological Model window without making changes.
What changes you need to make to be able to change the base lithology column depends on how the model’s lithology codes have been derived. Possibilities are:
- Derived from the base lithology column. If a model is created from lithology data, the codes used in the model are derived from that lithology data; changes to that data will be updated in the geological model, and vice versa. For example, if you edit the colour for the lithologies in the source data, those colours will be updated in the geological model, and editing the colours in the geological model will update the colours used in the source data.
- Derived from linked lithology data. Other lithology data in the project can be linked to the geological model. This can be done in the Lithology Columns tab, and is discussed below. As with the codes derived from the base lithology column, changes to that data will be updated in the geological model, and vice versa.
- Manually defined. You can add codes to the model in the Lithologies tab.
When you open the Geological Model window, how the lithology codes are displayed in the Lithologies tab tells you from what sources they were derived:
You cannot switch to using a column that is already linked to the model, i.e. one listed in the Lithology Columns tab whose codes are used in the Lithologies list. It simply will not appear in the list of Base lithology column options:
You can remove the linked column; once the model is reprocessed, surfaces that use that code will instead use the code set as the Background lithology (in the Surface Chronology tab). By default, the Background lithology for a geological model is the code Unknown.
Resolving Conflicts with Manually Defined Codes
Leapfrog Works prioritises a geological model’s lithologies as follows, from high to low:
- Base column codes
- Manually defined codes
- Codes from linked columns
Because linked columns have lowest priority, if codes from linked columns exist in the newly-selected base lithology column, having duplicate code names in linked columns and the base column is not an issue; the codes in the base lithology column will have priority and the duplicated in the linked columns will be ignored.
The same is not true, however, for manually defined codes.
Because manually defined codes would have been created for specific reasons, Leapfrog Works will not overwrite manually-defined codes that exist in a newly-selected base lithology column, even though they are lower in priority than base lithology column codes. Before the base lithology column can be changed, you need to decide whether you will delete manually-defined codes or rename them so they do not conflict with the codes in the lithology column you wish to switch to.
In this example, we want to change from the original lithology column, Old_lith, to an interval selection that contains Andesite and Rhyolite_Cover codes:
Looking at the geological model’s lithologies, we can see that it contains the manually defined code Andesite, which will conflict with the Andesite code in the New_lith column:
Note that the Andesite code in the New_lith column uses the colour yellow, whereas the manually defined code uses purple.
If you have only one or two codes that conflict, deleting the manually defined codes may be the best approach.
In our example model, the manually defined Andesite code is used in two contact surfaces:
Deleting the Andesite code will result in these surfaces being reprocessed with the code Unknown being assigned in place of the Andesite code:
Once we have changed the base lithology column, we can then remap the codes assigned to the surfaces:
In a model with a lot of contact surfaces and multiple manually defined codes, another approach would be to rename the manually defined codes so they will not conflict with the code in the New_lith column. Objects using renamed coded will also be renamed, as shown here when the manually defined Andesite code is renamed:
Once the base lithology column has been changed, we can then search for the renamed code in the project tree and switch the lithology used by contact surfaces to the code in the new base lithology column: