bridge: Seismic Data Format Conversions

Introduction

Geophysicists / technologists today are faced with an ever increasing choice of interpretational / processing software fielded by a host of vendors. Each system utilizes it's own data format making transference of data between systems painful. This situation is not going to change any time soon. In fact it will probably get worse, for as the recently laid-off sector of the business gets ever larger, the number of truly home grown applications is bound to increase.

To provide a seamless interface between all data formats is a formidable request. Randy Selzler has taken some fairly large steps in that direction with his DDS [Data Dictionary System] concept. A discussion of DDS here is beyond the scope of this note. Instead I will demonstrate how a single DDS application program, bridge, can be used to provide if not a seamless interface, certainly an effective path between the most common seismic data formats in use today.

USP Format

In the USP environment a dataset is made up of two parts, the line header followed by trace data (Fig. 1). This format is valid for tape or disk datasets.

Line Header

Each entry of the USP line header is accessible by mnemonic and contains global information about the data set that follows [NumRec, NumTrc, NumSmp etc.]. Also contained in the line header is a subset of data called the historical line header [HLH] containing information about previous processing steps that have been applied to the data.

Trace Data

Each USP trace data block is made up of two parts, the binary trace header followed by the trace data. The number of such blocks is defined by the line header entries NumRec and NumTrc. The length of each block is 256 bytes of trace header followed by NumSmp sample values. The number of trace blocks in a defined record is constant making disk access extremely fast through the use of pointers.

SEG-Y Format

In 1975 the SEG published a recommended standard for digital tape format [Geophysics, Vol. 40, No. 2 (April, 1975), P344-352]. A SEG-Y dataset therein described is made up of two basic components, a reel identification header, and trace data. Unlike USP formatted data the tape format is not identical to the format on disk as an inter-block gap is defined in the tape format.

Reel Identification Header

The reel identification header is made up of two parts, the card image EBCDIC block [40 cards - 3200 bytes in length] and the binary coded block [400 bytes in length]. The EBCDIC block usually contains comments supposedly relating to the data to follow. The binary block contains 60 assigned bytes followed by 340 bytes open for optional use. This portion of the dataset corresponds to the USP line header in that parameters global to the entire dataset [number of traces/record, sample interval, number of samples/trace etc.] are contained herein.

Trace Data

Each trace data block consists of a fixed 240 byte binary trace header followed by data samples written in one of four predetermined formats. This is completely analogous to the USP trace header - data arrangement. The number of samples in each trace and the total number of traces in the dataset, however, are not necessarily fixed by the values found in the reel header. A SEG-Y dataset may have a different number of samples and a different sample interval for each trace. There is also no such thing in the SEG-Y world as the total number of records in a dataset. Likewise, the total number of traces per records is allowed to vary. This was all done to minimize the amount of physical medium needed to contain a dataset in the days of 800 byte/ inch 9 track tapes.

Over the years, various contractors have added their own flavoring to the SEG-Y standard resulting in such formats as Sattlegger's SEGY-Like format. In a typical SEG-Y dataset the parameters listed in the reel header may in fact bear no relationship to the following data. It is not uncommon to have invalid entries regarding trace length in the trace header as well. These lapses in format usually come about in contractor generated datasets where the conversion job was built from a previously existing job and where the operator did not ensure that the appropriate information was entered in the line and trace headers for the data being transcribed.

VDS [DISCO] Formats

DISCO format supports two separate entities. The tape dataset and the disk dataset. The disk dataset is made up of two portions, the line header and the trace data. The tape dataset on the other hand is made up of four files complete with end of files [eof's] and inter-block gaps between files and between trace blocks.

DISCO Disk Format

The DISCO disk dataset is made up of two parts, the line header followed by the trace data.

Line Header

The DISCO line header is very sparse and contains just enough information for a DISCO process to make it through edit phase. Such things as sample interval, data length in samples etc. are contained here.

Trace Block

The DISCO trace header, unlike SEG-Y or USP is extensible. It contains a minimum of three entries and may expand to contain as many as needed for the processes being contemplated. The number of traces in a given ensemble is not a constant so that much disk thrashing must accompany non-sequential data access.

DISCO Tape Format

A DISCO tape dataset is made up of four files complete with intervening end of files [EOF].

Reel Header

The reel header contains enough information for edit phase. This information is customarily loaded to the database when the tape is generated or through tapedb so that the tape does not have to be loaded for the job to pass edit phase.

Duplicate Reel Header

This file is a duplicate of the first used for error recovery.

Auxiliary File

Contains user defined stuff not in the reel header.

Data Traces

Each trace is made up of a trace header and trace data block. Each tape of a multi-tape dataset has the above file structure.

Header Mnemonics and Why

Just before we get into the specifics of format conversion using bridge, a little need be said about how to access the header information in the various formats. In order to make like a little easier a set of mnemonics have been defined for each format to handle the header word identification. This obviates the need for knowing byte address in SEG-Y for instance and makes the creation of a header map between formats much more intuitive. For a complete listing of the header mnemonic definitions used you may refer to the DDS man pages.

bridge Syntax

bridge is a stand alone executable that reads from stdin, writes to stdout and imparts messages to stderr. In this regard it follows the USP program philosophy. The command line syntax however is unlike any other USP routine. Since it uses the DDS it is necessary to provide the routine all the format file support inherent in that system. To to this simply set the following environmental variable:
setenv DDS_PATH /explprod/phase2/usp/dds

Once set the bridge can be used for most basic format conversions.

Reading Foreign Formats

To limit the variations consider the following format conversions into USP:

SEG-Y Tape Input

Prior to actually converting the data format it is necessary to determine how the SEG-Y dataset was indexed [if at all]. A simple [and slick] way of accomplishing this is to run the bridge in dump=diff mode and pipe stderr to an xcat. In English this translates to letting the bridge read through the input SEG-Y data and report the trace header entries that change from trace to trace. The command is:
bridge data=/dev/rst0 format=segy out=tmp: \ out_data=junk dump=diff |& xcat &

The resulting display will list the entire trace header structure for the first trace followed by only those trace header entries that have changed from the last trace for every successive trace. In a glance you can see how your data is indexed and which SEG-Y header mnemonics to use in your header map [assuming the default doesn't work for you].

The header mapping information may be supplied on the command line or in an attached mapping file. Consider an input SEG-Y dataset that has 200 records with a variable number of traces/record [no dead traces on tape]. Let's further assume that the only indexing on tape is FieldRecNum, FieldTrcNum, CdpNum and CdpTrcNum and that the first CDP number is 205. The challenge here is to get the data into USP format with a fixed number of traces/record and have CDP numbers in both the RecNum and DphInd trace header entries.

Here is a mapping file to accomplish the above

segy_NumRec=200
segy:usp.RecNum=CdpNum - 204
segy:usp.TrcNum=CdpTrcNum
segy:usp.DphInd=CdpNum
write_usp=

The first line results in the USP line header entry NumRec being set to 200. The next three lines put the CDP information into the RecNum, TrcNum and DphInd entries. Notice that the first output RecNum will be set to the value 1. This is not strictly necessary but in this case will make the RecNum entry be equal to sequential record assuming no missing CDP's in the input dataset. It also serves to demonstrate that you may embed mathematical operations in the mapping information. The last line tells the bridge routine not to handle the input as sequential record and trace but to actually interpret the RecNum and TrcNum entries and pad any missing traces in the record as determined from those entries. To actually run the bridge while accessing this file use:

bridge data=/dev/rst0 format=segy out=tmp: \out_data=stdout: out_format=usp \
par=MyMappingFile | xcram

SEG-Y Multi-Volume Input

Should your input dataset be a multi-volume tape dataset you may add the following to either the command line or your mapping file:
/dev/rst0= label " label1 label2 ..."

where the tape labels are simply used to prompt the user for the next tape load. No actual check is made to assure the routine that the correct label is on the tape. In this case when the first tape is finished it will be rewound and ejected from the drive and the user prompted to load the next tape. The routine will remain in this wait state until the next tape is loaded to the named drive. If you are using a stacker you can use:

xcram10 -r -segy | bridge data-stdin: ......

without the label definition as the stacker will keep the data streaming from tape to tape for the bridge which will be reading from stdin. The advantage here is that you may pre-load the entire multi-volume dataset and leave the routine unattended.

SEG-Y Disk Input

Should the input be a SEG-Y disk file simply change the data specification to be:
data=MySegyDataset

Should you wish to output the USP formatted data to a file instead of a tape simply change the data_out specification to:

data_out=MyUspDataset

DISCO Tape Input

Change the input format specification to:
format=disco_tape

In this instance you may not [yet] use the stacker for, at this writting we cannot yet pass the EOF information down the pipe to the bridge. The bridge routine has to have control of the drive. The mapping file syntax would be:

disco_tape_NumRec=200
disco_tape:usp.RecNum=CDP - 204
disco_tape:usp.TrcNum=Trace_Number
disco_tape:usp.DphInd=CDP
write_usp=

DISCO Multi-Volume Tape Input

A multi-volume input dataset would be handled in the same fashion as previously. The data specification would point at the drive while the drive label would indicate the number of tapes to read. That is:
bridge data= /dev/rst0 /dev/rst0= label " 1 2 3" ...

The above command would look for three input tapes to be loaded one after the other to the rst0 device.

DISCO Disk Input

To access DISCO disk data, the format specifier becomes:
format=vds

to differentiate between DISCO tape and disk format. In addition the input data specifier will become:

data=MyDiscoDataFile

Writing Foreign Formats

The only wrinkle here is that the bridge must be in control of the output device for the data to be written correctly. If you pipe out of the bridge and use one of the UNIX / USP device drivers to create the tape, the data blocking and EOF placement will not be correct and you will have trouble reading the data back in the other processing environment.

bridge will prompt for more media if required in the case of multi-volume output. There is no need to use a label on the out_data delimiter.

Any of xcram, xcram10 or cram may be used to write multi-volume USP output datasets. Single volumes may also make use of dd. The advantage of the xcram like interfaces is the ability to do I/O on more than one device.

Return to the USP Home Page

Frame Doc to html conversion by Tony Garossino