The sheer volume of seismic data to be evaluated and folded into fully integrated interpretations has increased the burden already carried by interpreters. We must work ever more efficiently and assess the quality of a rapidly growing number of interpretation products, many of which are the output of automated processes. To keep from being overwhelmed by a torrent of seismic datasets and derivative products (horizons, faults, grids, attributes, etc.), you must effectively manage your data. Begin by designing and using a nomenclature system in every interpretation project.
A good data-management system serves as a road map, with which a user should be able to navigate through an interpretation project with a minimum of difficulty and confusion. A system should be comprehensive, in the sense that it contains and succinctly describes all of the fundamental elements that a user needs to find a desired product. It also should be intuitive, not based on jargon or esoteric language, and flexible enough that it doesn’t require re-engineering to incorporate a new data or product type. An effective data management system is one that you should carefully design at the outset of a project to facilitate rather than encumber interpretation. A good way of thinking about such a system is to imagine what you would need to know about a project if you were taking it over from another interpreter — how would you find what she had done, and determine how she had done it? (I assume, of course, that as a normal business process interpreters document their work in a report of some kind that resides in some sort of document management system. )
Let’s consider a horizon naming system. Each horizon name must have a minimum number of core elements, each delineated by an underscore. These elements must appear in the following order in each unique horizon name:
- Project identifier — perhaps including the vintage of seismic data
- Numerical designation for the approximate geological age of the horizon. This number increases with the age of the interpreted horizon, and enables the horizon list to be sorted and displayed in order of horizon age.
- Colour assigned to the horizon
- Biostratigraphic age of the horizon
- Name of the trace data file on which the horizon was interpreted. This is especially important if there are, say, pre-stack and post-stack migrations
- Initials of the interpreter who picked the horizon
Here’s an example, with an explanation of what all the pieces mean:
- X2005 - Exploration project that began in the year 2005
- 0600 - Numerical designation for the horizon green Colour assigned to the interpreted horizon
- green - Colour assigned to the interpreted horizon
- A - Indicates a named lithologic unit (in this case, the so-called ‘A’ sand)
- pl20 - Biostratigraphic age of the horizon (in this case lower Pliocene)
- ewfa04 - Name of trace data file on which the horizon was interpreted (in this case the final gained version of a pre-stack time migration volume with a sample interval of 4 ms)
- DH - Interpreter’s initials
Continuing with the road map analogy, this description of the core elements of the system should serve as the map’s legend, clearly explaining the meaning of each element. This legend should be kept as an integral part of the project’s documentation, perhaps as a readme file.
Many companies maintain nomenclature systems for their seismic projects, but even with a company-wide system in place, you should always be sure to document instances in which you customize a system for the specific purposes of a given project. One or two frustrating instances of losing valuable data is enough to convince most interpreters that data management matters Indeed, business success depends on it.