Results of the PPDM Seismic Implementation SIG
By Ken Cooley
PPDM special intrest group to standardize practices when using seismic data and integrating between different software packages. Flexible implementation of seismic data meta storage applied in interpretation and its standardized best practices determined at PPDM SIG meeting.
Full Article Text...
The PPDM Seismic Implementation Special Interest Group has met several times in the past year to achieve agreement on best practices for implementing Seismic Data in PPDM. The intent of the group is to share common implementation practices to achieve better integration between different software packages and PPDM installations with fewer data exchange obstacles. For this presentation, we will be summarizing the results from the meetings.
So far, we have made a good start towards standardizing seismic implementation in PPDM. Our goal is to continue to hone the agreed practices, and ultimately to publish seismic implementation standards that can be used for the long term.
WHAT DOES THIS PAPER DISCUSS?
- HOW WAS THE PPDM SEISMIC IMPLEMENTATION SPECIAL INTEREST GROUP (SIG) FORMED?
- WHY FORM A GROUP LIKE THIS?
- WHO ARE WE?
- WHAT ARE RESULTS, ALONG WITH EXAMPLES OF INFO DISCUSSED / RESOLVED / NOT RESOLVED?
- WHAT IS NEXT?
HOW WAS THE GROUP FORMED?
During last year’s PPDM Houston Users Group Meeting, Ken Cooley presented Geophysical Insight’s approach to implementing Seismic Meta data in the PPDM data model. During that presentation, he offered to work with other companies to help avoid conflicts between different implementations. Robert Best, President of Neuralog, and Scott Schneider President and CEO of Volant, stood up and volunteered to work with Ken on standardizing the implementation details.
Following that, several others were contacted and joined the discussion. Several meetings were held to determine the best practices for storing Seismic data in PPDM. We called ourselves a special interest group, and Trudy Curtis started a Forum on PPDM’s website to collect the results of our discussions.
WHY SHARE IMPLEMENTATION DETAILS?
SOURCE DATA APPEARS IN A STAGGERING ARRAY OF FLAVORS.
No two companies have exactly the same needs. Each different workflow produces a unique constraint on the data content. Company A doesn’t store Acquisition data. Company B stores all geometry info in another system. These differences disturb the expectations and demands on the system and the data.
PPDM NEEDS TO BE FLEXIBLE,
… so that data can be stored similar to its original form. No one wants to lose precious data, just so that it can fit into a mold that someone else created.
THIS FLEXIBILITY OFTEN RESULTS IN MISMATCHES BETWEEN DIFFERENT IMPLEMENTATIONS.
With 5 ways to do something, it is inevitable that implementation differences will arise. If only one way is used in a given company, this naturally leads to assumptions about how the data is structured.
SOFTWARE WHICH WORKS ON ONE IMPLEMENTATION,
… will not work on another. Software mechanisms for accessing data are extremely sensitive to the structure of the data. Certain storage patterns are developed that often exclude other ways of arranging the data. Just knowing what the few popular patterns are, can help reduce the risk of conflicts enormously.
- SHARE COMMON IMPLEMENTATION PATTERNS TO GET BETTER INTEGRATION BETWEEN DIFFERENT SOFTWARE AND PPDM INSTALLATIONS.
- NEED TO REDUCE DATA EXCHANGE OBSTACLES.
- CAPTURE “BEST PRACTICES” FOR SEISMIC META DATA STORAGE.
A GOAL FOR THE GROUP IS TO PRODUCE RULES FOR STORING SEISMIC
DATA FOR CERTAIN OVERLAPPING WORKFLOWS.
Rules can help avoid collisions in many walks of life. An example would be a rule about how to use the seismic line tables to store the line name. A best practice can be recorded so that, if followed, it enables any software which honors that rule to reliably access the data.
There are 3 places in PPDM where the name of a seismic 2d line can be stored. They are different columns in 3 different tables.
Let’s call them columns A, B, and C.
But, which is the most frequently used?
The group determined that most existing systems use column A, but some use column B.
We agreed on a new rule to always record the name in column A, but also automatically populate column B. Any software which follows this rule will be able to reliably work with most systems.
FOR DATA INTEGRITY, USE SEIS_GROUP_COMP TO RELATE TWO SEIS_SET TABLES.
VALID SEIS_GROUP_COMP ALTERNATIVES
USE FOREIGN KEYS INSTEAD OF SEIS_GROUP_COMP WHEN THEY ARE AVAILABLE.
• A 2D survey composed of a set of Lines
• A 2D line composed of a set of line segments
• A 3D Survey composed of a set of volumes
** Originally suggested by Geophysical Insights
Note that SEIS_GROUP_COMP rows aren’t required if the corresponding foreign keys are populated, explicitly linking the tables.
SEIS_POINT VS. SP_POINT
• Use SEIS POINT instead of SP_POINT to store Trace/CDP bin locations for 2D Lines.
• Additional proprietary storage (DB or otherwise) may be required for performance.
• SEIS_SEGMENT entries can optionally be used to represent the ends and bends of 2D lines. For example, there are 4 segments in this line:
But, the segments are not as efficiently stored in PPDM.
LINE AND SURVEY NAMES
USE SEIS_BIN_GRID TO STORE TRACE/CDP BIN LOCATIONS FOR 3D SURVEYS.
USE SEIS_LINE.LINE_NAME FOR THE PREFERRED 2D LINE NAME.
(LINE_NAME was column “A” in the earlier example.)
USE SEIS_ACQTN_SURVEY.SURVEY_NAME FOR THE PREFERRED SURVEY NAME.
COURTESY NATURAL RESOURCES CANADA
USE SEIS_ALIAS FOR ALTERNATE NAMES.
Include the Preferred 2D Line name here as well as in SEIS_LINE
Automatically copy to SEIS_ALIAS from:
Plus other survey/line codes and identifiers, such as:
- Source system key (original identifier in source system)
- Previous name from earlier version
- Duplicate name from alternate source
ALTERNATE NAME SEARCHES
One concern about storing additional alias names in the system is that it might degrade the performance for queries.
If this is a concern, the user interface could default to only search LINE_NAME, and then only search the aliases when the user requested that (by checking the appropriate checkbox in the UI).
ALIAS TABLE RECOMMENDATIONS
ALIAS ID SHOULD BE POPULATED AS A SURROGATE KEY SUCH AS A SEQUENCE NUMBER. ALWAYS POPULATE THE LONG_NAME COLUMN.
(The LONG_NAME column was column “B” in the earlier example.)
USE THE LONG_NAME COLUMN FOR ALL SEARCHES. USE THE SHORT_NAME COLUMN IF A SHORTER VERSION IS NEEDED AS A DISPLAY NAME.
But, don’t search on short name, as it is less likely to be unique.
Any proprietary mechanism is allowed for computing unique keys...
But, in the interest of avoiding conflicts, we can use PPDM_COLUMN.LAST_SYSTEM_KEY to record the last incremented surrogate key used in the system for a given table.
For example, for the SEIS_SET table, the corresponding PPDM_COLUMN entry would be:
The Last System Key can be parsed to determine the current number for incrementing to create the next guaranteed unique key for that table/column.
DATA MODEL CHANGES
ENABLE SEISMIC REFERENCE DATUM FOR CHECK SHOTS
Add new columns to SEIS_WELL:
The DATUM info can be stored in the RM_SEIS_TRACE table, but adding these SEIS_WELL columns would be a more natural fit.
CAN WE RENAME THE SEIS_ALIAS.ALIAS_CODE COLUMN TO ABBREVIATION?
No one in the group could explain the ALIAS_CODE column, but we all understood the ABBREVIATION column on other reference tables.
The recommendation is to change it from VARCHAR (30) to VARCHAR (12).
Should we do the same for all other ****_ALIAS tables?
ADD FOREIGN KEYS TO SEIS_PROC_COMPONENT TO LINK TO THE CORRESPONDING SEIS_BIN_GRID.
This would involve adding the following columns to the SEIS_PROC_COMPONENT table:
Prior to implementing this change, possible conflicts should be evaluated. This change may imply Load of the Rings issues, or there might be other requirements (like multiple SEIS_BIN_GRIDs per SEIS_PROC_COMPONENT) that would not be supported by this solution.
THE *_NUMERIC_ID COLUMNS WITH UNIQUE CONSTRAINTS ARE REQUIRED ON SQL SERVER DATABASES, SINCE NUMERIC COLUMNS CANNOT BE NULL.
There is a non-trivial overhead of calculating unique numeric values for these “optional” columns which are not being used, but are required.
WE PROPOSE REMOVING THEM, SINCE WE KNOW OF NO ONE WHO USES THEM.
SIG PROCESS: GOOD & BAD
THE MECHANICS OF GETTING TOGETHER
Meetings vs. Teleconference vs. Forums
Face-to-face meetings were the best. We had to compromise in every case, in order to choose a reasonable number of days between meetings, versus who could attend.
Some of the meetings were purely international conference calls. They presented their own challenges.
It was very difficult to choose a meeting time that was least inconvenient.
PPDM SIG FORUM
TRUDY CURTIS CREATED A SPECIAL PPDM FORUM FOR THE SIG.
All PPDM members may view the group’s discussions, results, and activities there.
The Forum is nice in general, because it is one place to keep all of the group’s documentation. However, the SIG Forum hasn’t gotten a lot of web traffic. There have been only a handful of views, and limited posting.
- Everyone has it.
- Some members relied exclusively on their Email.
- Emails have a higher likelihood of being read.
- Regular distribution of Group info could be seen as Spam.
- It’s more difficult to collaborate on documents.
- Discussion threads can get splintered into multiple threads, which can make it extra difficult to follow.
REFERENCE TABLE VALUES
For example, which reference value is agreed to represent a specific software application?
2D LINE TRACE SPACING
Which column should be used to represent 2D line trace spacing in PPDM?
TESTS TO EVALUATE INTEROPERABILITY BETWEEN SOFTWARE AND ACTUAL IMPLEMENTATIONS
The ideal would be to arrange for some testing of multiple PPDM software packages against actual implementations.
Although the benefits to the industry of this testing are clear, this would require a larger dedicated effort. Also, general access to PPDM implementations is not usually easy to obtain.
OTHER FLAVORS OF SEISMIC DATA (SLICES, BRICKS, MICRO-SEISMIC, ETC.)
Encana has been asking about how Micro-Seismic would be stored in PPDM.
WHERE TO GO FROM HERE?
HOW LONG TO KEEP A SIG ACTIVE, INVOLVED AND USEFUL?
Some have suggested that a SIG should be targeted at a specific deliverable by a given deadline, with a drop dead date.
Others are concerned that volunteers won’t be able to donate more than the minimum time to keep discussions going. The periodic meetings may serve as a good discussion venue as problems are encountered over time. The fewer the problems… the further apart the meetings.
© 2012 Geophysical Insights. All rights reserved. No part of the material protected by this copyright may be reproduced 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 Geophysical Insights.