July 2, 2013 Seismic Data Preprocessing Workshop

July 2, 2013 Seismic Data Preprocessing Workshop

In this session we loaded about 200 shot records from a noncommercial seismic survey offshore Washington State. These data were downloaded from the internet by following links on the Marine Geoscience Data System (MGDS) entry page For the workshop I chose the data for line 3 stored in the 4GB file MGL1212.003.MCS01.001.tar accessible from the MGDS Data Set page Uncompressing and unpacking that file produces a directory TAPE0008.REEL containing individual SEG-D formatted shot records with names matching the pattern R{ffid}_{timestamp}.RAW. That directory also contains an EOF.RAW file[1].

EOT.RAW R000069_1342242636.RAW R000138_1342244291.RAW

R000001_1342240888.RAW R000070_1342242661.RAW R000139_1342244313.RAW

R000002_1342240915.RAW R000071_1342242686.RAW R000140_1342244334.RAW

R000003_1342240941.RAW R000072_1342242711.RAW R000141_1342244356.RAW

R000004_1342240966.RAW R000073_1342242737.RAW R000142_1342244377.RAW

R000005_1342240993.RAW R000074_1342242763.RAW R000143_1342244398.RAW

R000006_1342241020.RAW R000075_1342242789.RAW R000144_1342244420.RAW

R000007_1342241047.RAW R000076_1342242815.RAW R000145_1342244441.RAW

R000008_1342241073.RAW R000077_1342242841.RAW R000146_1342244463.RAW

R000009_1342241100.RAW R000078_1342242868.RAW R000147_1342244485.RAW

R000010_1342241126.RAW R000079_1342242895.RAW R000148_1342244506.RAW

R000011_1342241152.RAW R000080_1342242922.RAW R000149_1342244528.RAW

R000012_1342241177.RAW R000081_1342242949.RAW R000150_1342244550.RAW

…

R000061_1342242435.RAW R000130_1342244116.RAW R000199_1342245619.RAW

R000062_1342242460.RAW R000131_1342244138.RAW R000200_1342245641.RAW

R000063_1342242485.RAW R000132_1342244160.RAW R000201_1342245663.RAW

R000064_1342242510.RAW R000133_1342244182.RAW R000202_1342245685.RAW

R000065_1342242535.RAW R000134_1342244204.RAW R000203_1342245710.RAW

R000066_1342242560.RAW R000135_1342244226.RAW R000204_1342245736.RAW

R000067_1342242585.RAW R000136_1342244248.RAW

R000068_1342242610.RAW R000137_1342244270.RAW

In order to read and display these data files, we used the freeware Seismic Unix (SU) software package maintained by the Colorado School of Mines (CSM) Center for Wave Phenomena (CWP). The full source tree for the current version (43 revision 3) was downloaded from the page. It may be built and run on Linux, Mac OS X, and other Unix-flavored operating systems, including the Cygwin 32 Windows environment. For the workshop we are using it with Mac OS X. To save participants the effort of wading through its installation instructions, I preconfigured the source tree for the Mac and provided two small scripts, one to build the executables and the other to set up the environment for running them. At the time, most, but not all, of the excutables built and I switched over to a Linux version running remotely from an SEP computer. (Subsequently, I tracked down and fixed the Mac OS X compilation problems and sent the changes I made back to the CWP folks for inclusion in their next patch release.)

To use the build script, listed below, one first changes directory to the location in which the software distribution was expanded. For the workshop, I have used the unimaginative name cwproot for that directory. Within that directory are the SU src subdirectory and the scripts buildit.sh and setup.sh. The buildit.sh script sets the environment variable CWPROOT and runs a handful of make commands to compile, link and install executables and scripts. One invokes the script by typing “./buildit.sh”on the command line.

#!/bin/bash

# buildit.sh to build the CWP SU software

export CWPROOT=`pwd`

export PATH=${CWPROOT}/bin:${PATH}

cd src

make install

make xtinstall

make finstall

make sfinstall

cd ..

The setup.sh file, listed below, is even shorter, but is invoked differently because it is “sourced” rather than executed so that it modifies the current user environment. It is invoked by typing “. ./setup.sh” on the command line.

# to use: . ./setup.sh

CWPROOT=`pwd`

export CWPROOT

PATH=${CWPROOT}/bin:${PATH}

export PATH

For csh/tcsh users, the script and its invocation are different:

# to use: source ./setup.sh

setenv CWPROOT `pwd`

set path=(${CWPROOT}/bin ${path})

The suhelp utility provides a catalogue of most available SU modules. In addition, each executable is self-documenting, that is, when its name is entered alone on the command line, it simply prints out details on

how to use it.

The format of an SU dataset is almost the same as that of a standard SEG-Y dataset. There are four differences. First, only the traces themselves are in SU, all 3200 byte textual headers and the 400 byte binary reel header are absent. This makes it easy to concatenate multiple SU files into a single dataset or, conversely, split an SU dataset into multiple pieces, each as an SU dataset itself. Second, the SU system overwrites bytes 181-212 in each trace header, bytes which are now assigned in the current SEG-Y standard. This may cause some information to be thrown away when importing SEG-Y into SU. Third, the SU trace data is always kept in IEEE floating point format. Last, the ordering of bytes within each field of the trace header and within the bytes of the trace data depends upon which machine the SU dataset was created on and which compiler options were used when building the SU software. For this workshop, the SU software is compiled with the –DSUXDR option to ensure consistent byte ordering on all machines.

One topic I briefly raised was that of coordinate systems and precision. The data we are using is available in SEG-Y format, complete with X-Y coordinates, as well as SEG-D, which doesn’t provide coordinates. When I examined the SEG-Y coordinates, they showed that in each shot record, the shot location was identical to each of its receiver locations. This was simply wrong. The minimum distance between a source and its receiver array was 264 meters. While this could be repaired, and we will, indeed, later import source and receiver coordinates into our SU datasets, it is important to have experience reading SEG-D field data into a seismic processing system.

Invoking segdread without arguments gives the self-doc printout

SEGDREAD - read an SEG-D tape

segdread > stdout tape=

Required parameters:

tape= input tape device

tape=- to read from stdin

Optional parameters:

use_stdio=0 for record devices (9-track reel tape drive)

=1 for pipe, disk and fixed-block 8mm drives

verbose=0 silent operation

= 1 ; echo every 'vblock' traces

= 2 ; echo information about blocks

vblock=50 echo every 'vblock' traces under verbose option

ptmin=1 first shot to read

ptmax=INT_MAX last shot to read

gain=0 no application of gain

aux=0 no recovery of auxiliary traces

errmax=0 allowable number of consecutive tape IO errors

ns=0 override of computed ns to work around SEG-D

flaws. Ignored when use_stdio=0.

pivot_year=30 Use current century for 2 digit yrs less than

pivot_year, previous century otherwise.

type: sudoc segdread for further information

Using this help, I invoked the command

segdread tape=R000001_1342240888.RAW use_stdio=1 gain=1 > test.su

which completed normally, albeit with excessive printout. (I’ve updated segdread to be less repetitive and forwarded the changes to the CWP folks.) To get an idea of what is in the output, we run the surange utility.

surange < test.su

636 traces:

fldr 1

tracf 1 636 (1 - 636)

ep 3226

trid 1

ns 8192

dt 2000

year 2012

day 196

hour 4

minute 41

sec 28

This printout tells us we have just converted field record 1 (matching the R000001 in the SEG-D filename) with 636 traces of 8192 samples at a 2 milliseconds interval. These data correspond to shotpoint 3226 and were acquired at 4:41:28 on the 196th day (July 14th) of 2012. Note that there are no entries for the coordinate fields sx, gx, sy, and gy.

Now that we have imported this SEG-D record into SU format, let’s take a look at it using one of the SU graphical tools. Here’s we’ll use the suximage utility. This, as its selfdoc explains, is a wrapper for the underlying graphical tool ximage. Running the default command

suximage < test.su

produces the X-Windows display

This is a grayscale display with the largest positive amplitudes appearing as white and the largest negative amplitudes as black. The vertical scale is the time in seconds (8192 samples at 2 msec. is 16.384 seconds) and the horizontal scale is tracf, the trace number in the field file, ranging from 1–636. Most of the plot is almost featureless gray, indicating that the default amplitude scaling was controlled by the large amplitudes in the small handful of vertical streaks. To override the default scaling, the ximage program provides several options:

perc=100.0 percentile used to determine clip

clip=(perc percentile) clip used to determine bclip and wclip

bperc=perc percentile for determining black clip value

wperc=100.0-perc percentile for determining white clip value

bclip=clip data values outside of [bclip,wclip] are clipped

wclip=-clip data values outside of [bclip,wclip] are clipped

balance=0 bclip & wclip individually

=1 set them to the same abs value

if specified via perc (avoids colorbar skew)

Redisplaying with the command

suximage < test.su perc=98

A much more feature full display, indeed. The very steep streaks are known as swell noise and result from small pressure changes as waves pass over and along the towed hydrophone sensor array. The linear event starting at the far right near the top is the direct wave traveling from the source to the hydrophones. The curved events are reflections off the subsurface, the topmost, arriving at about 3½ seconds traveltime on tracf 636, being from the water bottom. The arrival at about 7 seconds traveltime below it is what is known as a free surface multiple, that is, the water bottom reflection bouncing off the air-water sea surface interface (with a reflection coefficient of −1) and thence reflecting of the water bottom a second time.

Since the swell noise is not associated with the subsurface, let us suppress it and take a closer look at the reflections. One way to do this is to realized that the swell noise varies quite slowly along the vertical axis. This makes it amenable to low-cut filtering, that is, removing slowly varying temporal components of each trace. Using suhelp, we find that the program sufilter provides such an option. We invoke it with a highpass option

sufilter < test.su > testbandpass.su f=1,2,8,200 amps=0,0,1,1

and then display the output as before. One noteworthy feature of SU is your ability to “pipe” data through multiple SU modules without creating a separate output file for each module. Thus the above could also have been handled via the command line

sufilter < test.su f=1,2,8,200 amps=0,0,1,1 | suximage perc=98

where the two su commands are separated by the | pipe symbol.

The swell noise has definitely been suppressed and the free surface multiples are eminently clear. In view of the fact that there are 8192 samples vertically, while the computer screen has only a thousand or so pixels it can display vertically, there is a lot of detail that is missing in this screen capture. Fortunately, suximage allows selection and zooming, either by clicking and dragging a box around the portion you want to zoom or by pressing keys to zoom in and out and scroll. Focusing on the shallow right hand portion of the display, we see that there is still some faint swell noise above the seafloor reflection and that the number of noisy traces is more than we might have gleaned at first from the previous displays.

Finally, while we didn’t get to it during class, it will be more convenient to assemble all the shot records into a single SU file. Here’s a script that will do this:

!# /bin/sh –v

touch line3raw.su

for i in R*.RAW

do

segdread tape=$i use_stdio=1 gain=1 > line3raw.su

done

Running surange on line3raw.su:

129744 traces:

fldr 1 204 (1 - 204)

tracf 1 636 (1 - 636)

ep 3226 3429 (3226 - 3429)

trid 1

ns 8192

dt 2000

year 2012

day 196

hour 4 6 (4 - 6)

minute 0 59 (41 - 2)

sec 0 59 (28 - 16)

[1] This arrangement is created by an onboard realtime quality control (QC) package SeisNet™ that run on a Microsoft Windows platform. I once modified Landmark Graphic’s ProMAX® seismic data processing package to allow it to stream these records into its SEG-D Input module as soon as they were created on disk, allowing ProMAX to be used for more sophisticated realtime analysis and preprocessing.