Storing Post Stack Seismic Meta Data in PPDM · Storing Post Stack Seismic Meta Data in PPDM...

from insight to foresight tm

Storing Post Stack Seismic Meta Data in PPDMBy: Ken Cooley, Consultant to Geophysical Insights

Presented at: PPDM Houston Conference, March 8, 2011

Storing Post Stack Seismic Meta Data in PPDM

Abstract

Introduction

3D Seismic Survey

Records Management Information Item

Records Management Data Store

2D Seismic Line

The Whole Picture

PPDM Tables

Conclusion

1

1

2

2

2

4

5

7

8

Contents

FiguresFigure 1: Post Stack Processing Flow

Figure 2: 3D Seismic Survey

Figure 3: Information Item Key Value

Figure 4: Data Store

Figure 5: 2D Seismic Line

Figure 6: Seismic and Records Management Table Relationships for Storing Post Stack Data

Figure 7: Records Management & Seismic Data Models

Figure 8: Required PPDM Tables

Figure 9: Geophysical Insights’ usage of Post Stack Data

1

3

3

3

4

5

6

7

8


Abstract

We propose a Method of populating seismic survey meta data that resolves some confusion about which PPDM tables to use for which pieces of Seismic data related to documenting meta data about 2D and 3D post stack seismic trace data files. We selected specific PPDM Seismic, Reference, and Records Management tables that were suitable for the requirements. The selected tables fit together well given the relationships between them, resulting in accurate storage and retrieval of the needed data. This pattern of populating seismic survey meta data allows us to unambiguously store and access the data in a PPDM database in a standard way. Other companies could use this pattern to enable sharing of seismic survey meta data among different software applications. Clearly, this would support better integration with fewer data exchange obstacles.

Introduction

Geophysical Insights was facing the following challenge:

• We needed an industry standard data model for storing information about seismic post stack trace data (meta data).

• PPDM was chosen because it is comprehensive, open, and supported.

It supports any kind of data in one database. Other applications can access the data, and there is ongoing work to refine and further develop it. The PPDM organization has been very responsive to our questions.

Initially, the complexity of the Seismic data model was a concern. There are many ways of representing the same information. This discrepancy can result in disconnects

between different implementations of the same PPDM module.

However, we have been able to choose a way of representing Survey, Geometry, Trace, and storage information for Post Stack trace data (3D Seismic Attribute volumes and 2D data types) in PPDM that satisfies our needs.The goal was to be able to collect Seismic Attribute volumes (3D) and data types (2D) from Seismic Surveys from several different Oil & Gas Seismic projects via OpenSpirit.

For each 3D Seismic Attribute Volume, for example, we needed to store the bulk data (traces) in large binary files, but for selection, graphical display, and processing, we needed to represent the meta data in the PPDM data model.

A method was chosen of representing the following information for Post Stack trace data (3D Seismic Attribute volumes and 2D data types) in PPDM:

• Seismic Survey• Geometry• Trace Info• File Storage

This is the Meta data about the trace data. Seismic Post Stack Data comes from processing raw Seismic data. (Figure 1)

Figure 1 - Post Stack Processing Flow


1


Many different seismic attributes can be calculated from a single set of post stack amplitudes. There can easily be as many as 50 different kinds attributes calculated for a single survey. For each 3D Seismic Attribute Volume, for example, we needed to store the bulk data (traces) in large binary files. For survey selection, graphical display, and processing, we needed to represent the survey and post stack trace meta data in the PPDM data model.

Typically, we would need to access meta data for many surveys at once, for mapping logic, for example. But for bulk trace data, we would only need to access one volume at a time.

As a result, specific PPDM Seismic, Reference, Records Management tables were selected that were suitable for the above requirements. The selected tables fit together well given the relationships between them.

3D Seismic Survey

These tables can “share” the same key value. The common key ties them to a 3D survey. (Figure 2)

All these tables have “SS_1001” as their ID primary key value. It ties them together associating the rows with a single 3D Survey. The “SS_” is mainly for clarity in the presentation. The key is a text field, but can be just numbers. This represents a 3D survey, named “GOLDEN” with an attribute volume for the “Coherence” attribute. Additional volumes would get incremented COMPONENT_ID’s.

2

Storing Post Stack Seismic Meta Data in PPDM Storing Post Stack Seismic Meta Data in PPDM

Records Management Information Item (Figure 3)

These tables share the “II_2001” Information Item key value, and represent the records management record for the Coherence attribute volume for a specific Survey.

Records Management Data Store (Figure 4)

These tables share the “IIS_3003” Data Store key value, and represent the actual disk location and file name for the bulk data associated with the attribute volume.

“I’m excited by the interest that we have

about converging in our key practices,

so that eventually we might reach our

‘nirvana’ - interoperability!”

- Trudy Curtis (CEO, PPDM Association)

Figure 4 Data Store

Figure 23D Seismic Survey

Figure 3Information Item Key Value

3


For referential integrity we need to connect SEIS_3D and SEIS_LINE to SEIS_PROC_SET with a foreign key relationship.

Use SEIS_GROUP_COMP to group the SEIS_PROC_SET as part of the corresponding SEIS_3D/SEIS_LINE.

We need to group these tables in order to enforce a relationship between the processed data and the survey.

Figure 5 - 2D Seismic Line

2D Seismic Line

These tables share the “SS_1003” Seismic Line key value similar to the 3D case. (Figure 5)

4


Figure 6 - Seismic Line Key Value

The Whole Picture:

RM_DATA_STORERM_PHYSICAL_ITEM

RM_SEIS_TRACE RM_INFORMATION_ITEM

RM_DATA_CONTENT

SEIS_PROC_SETSEIS_PROC_COMPONENT

SEIS_SET

SEIS_3DSEIS_ALIAS

SEIS_BIN_GRID

SEIS_LINESEIS_ACQTN_DESIGN

SEIS_POINT

5


Figure 6 - Seismic and Records Management Table Relationships

for Storing Post Stack Data

* Figure 7

Records Management & Seismic Data Models

This approach focuses on the parts of the PPDM model that are relevant to Post Stack Seismic Trace Data. The full data model is quite a bit more complex. (Figure 7)

* Copyright of PPDM6


Figure 8 - Required PPDM Tables

7


Figure 8 is a list of PPDM tables that we discovered were required to support this method.

Are more PPDM tables required in order to correctly persist the data?

Here are additional tables which link position information to spatial databases:SEIS_SET_GEOMETRY?SP_LINE, SP_POINT, SP_LINE_POINT?

In order to group a 2D Line as part of a 2D survey we would use SEIS_GROUP_COMP to tie the SEIS_LINE to a SEIS_ACQTN_SURVEY.

Post stack trace data (attributes) are inputs into our business solution. Classification volumes (3D) and lines (2D) are outputs. Their meta data is also stored in PPDM as attributes. (Figure 9)

A Possible PPDM Extension could include, Self Organizing Map (SOM) analysis results, which are another output of our business solution. Currently, there is no place in the PPDM for them. We may propose some PPDM data model extensions to cover these.

This paper represents a top level view. There are many additional details. Some are self-explanatory. The column names describe the usage of the columns. There are, of course commonly used PPDM tables which also describe many other parts of the PPDM model, like:

• Coordinate systems• Units of measure• Etc.

Conclusion

In summary, this approach results in an accurate and straightforward storage and retrieval mechanism for the required data. Other companies could use this method to enable sharing of seismic survey meta data among different software applications. This sharing would support better integration, with fewer data exchange obstacles.

We were motivated to publish this method because PPDM exists to enable standardization, but PPDM is flexible. It allows mismatches between different implementations.

There has been very little published PPDM Seismic Survey usage info available. For example, there are no 3D Surveys in the Teapot Dome data set. The sooner a convention for using Post Stack Seismic data is adopted, the fewer incompatibilities between different Implementations may result. Our hope is to provide a good start on “best practices” for seismic meta data storage.

We would like to express thanks to Steve Cooper, President of EnergyIQ and Trudy Curtis, CEO of PPDM. We received a great deal of instruction and assistance from them.

Figure 9 - Geophysical Insights’ usage of Post Stack Data8


© 2011 Geophysical Insights. All rights reserved. No part of the material protected by this copyright may be re-produced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, broadcasting or by any information storage and retrieval system, without permission in writing from Geophysi-cal Insights.

9


1044 Teresa Dr.Houston, TX 77055

www.geoinsights.com

Phone: +1.713.464.1312

from insight to foresight tm

Storing Post Stack Seismic Meta Data in PPDM · Storing Post Stack Seismic Meta Data in PPDM...

Documents

Transcript of Storing Post Stack Seismic Meta Data in PPDM · Storing Post Stack Seismic Meta Data in PPDM...