Tips for Managing Your GeoProbe Projects in R5000

Shared by Don Pack on December 16, 2010. Posted In Data,Geology,Geophysics.

Post image for Tips for Managing Your GeoProbe Projects in R5000

Migrating Existing Projects

For 5000.0.0, the GeoProbe® software data directory structure has dramatically changed to allow for a more thoughtful handling of multi-survey objects. Older vintage projects must be migrated to follow this directory structure. Beneath the top-level OpenWorks® or GeoProbe software project, GeoProbe objects are now separated based upon whether they exist on a project or survey level. By making this change, the same horizon or fault can now extend from one survey area, or 2D line, to another. In addition, state files now encompass all objects within a project and are no longer restricted to only saving objects or a survey-by-survey basis.

As more GeoProbe objects are converted to honor world coordinates in future releases, they will eventually move out of the individual survey directories into the project directory. Currently, objects that can span multiple surveys include horizons, swFaults, 2D data, TSurf and AGF files.

In previous releases, the GeoProbe working directory was based on your shortcut name. This directory could be located anywhere on your system for GeoProbe projects and under the SeisWorks directory for OpenWorks-connected projects. In 5000.0.0 and moving forward, this working directory has been uncoupled from the shortcut name and better aligns with the OpenWorks 5000.0.0 data model.

GeoProbe-only projects can still be located anywhere on your system, but now the working directory can be any name of your choice, with the project and individual survey directories beneath it. For OpenWorks-connected projects, the working directory defaults to be under the connected OpenWorks project in OW_PROJ_DATA, but this can also be anywhere on your system.

Understanding Project Directories

Project Subdirectories
Beneath the GeoProbe Working Directory are directories for both the project-level objects as well as survey-specific objects. As one project may contain multiple surveys, data objects contained on a project level are those that can encompass the entire project space. The graphic below describes where data object directories for a particular project are located (in this example, an OpenWorks-connected project).

All previously created GeoProbe projects must have their data objects copied into a directory structure that matches this format. In almost all cases, this simply involves moving the Object directory (e.g. volumes, faults, swFaults) under the project directory or the appropriate survey directory. However, you’ll notice that there is a Horizons directory on both the project and survey level. Old horizons, of *.hzn extent, should be copied into the survey-level directory. These horizons are still valid for loading into the GeoProbe session, but should then be saved in the new format of *.mzn as described in the following section.

Horizon Directory Structure

As a single horizon can be interpreted across multiple surveys and 2D lines, this has necessitated the use of a tiered directory structure to save such a horizon to the GeoProbe working directory. New horizons in GeoProbe are saved in the following manner.

  • A master index file, called .mzn will be created in the project/Horizons directory. This ascii file will point to the individual surveys and lines and their applicable horizon pieces. When loading the horizon from disk, the Horizon Load GUI will search for this file.
  • Under each 3D survey, there will also be directories called /Horizons. Here will be the actual binary horizon interpretation files for the parts of the horizon that fall in that survey’s boundaries. These files will have the format of MZN.mzn.
  • Portions of the horizon that are interpreted on 2D lines are saved in the project/Horizon2D directory. Under this main directory will be a directory with the same name as the horizon. This secondary directory will then contain a series of *.xml files, which will retain the naming convention of the 2D lines on which each horizon piece was interpreted.

In the example below, we have interpreted and saved a horizon called Green across two surveys and three 2D lines in an OpenWorks connect project.

Merging Existing Horizons and Faults

Follow these steps to migrate existing GeoProbe horizons to the new 5000.0.0 format and to merge horizon pieces into a single horizon object.

1. For the same horizon interpreted in multiple surveys, copy or move your *.hzn files into the appropriate survey directories for your project.
2. In GeoProbe, load these individual horizon pieces into the session.

3. Highlight the horizon pieces, and click Merge. Using this dialog, merge the pieces into a single, new horizon.
4. Save the new horizon. The next time you load this single horizon, you have the choice of either loading the horizon for the entire project or only the part of your survey of interest.

Follow these steps to merge swFault segments into a single, multi-survey swFault object.

1. In GeoProbe, load the same fault interpreted in multiple surveys – in this example, fault_a and fault_b.
2. With fault_b highlighted, click Interpret to launch the swFault Interpretation dialog.
3. Unassign the segments in fault_b.

4. From the swFaults Object Manager, highlight fault_a and highlight Unassigned segments.
5. In the swFault Interpretation dialog, click Assign.

6. The two faults are now merged into one. Save the swFault.

Related posts:

  1. Upgrade GeoProbe Projects Not Connected to OpenWorks
  2. Horizon Upgrade and Interpretation Projects in R5000
  3. Framework Building with ezModel in GeoProbe R5000

Comments on this entry are closed.

Previous post:

Next post: