RG Seismic Processing Exercise

J. Louie
6 October 1996

Purpose

This exercise will let you take seismic data from raw field records to migrated stack in an industry-standard sequence. You should be familiar with the description of the ``Resource Geology Seismic Processing System'' as it is implemented here. Keep that document on hand for reference. You should also have some experience programming both in the C language and with UNIX C-Shell scripts. All of the scripts and data files used in this exercise are publicly accessible at http://crack.seismo.unr.edu/ftp/pub/louie/rg/, and through links from this page. All of the programs used in the scripts are accessible locally in the directories /rg and /usr/local/bin, with documentation reachable through the RG program list.

PROCEDURES

Follow the procedures below to stack the synthetic data supplied in the 10 megabyte file ``MODEL''.

Define records to stack

The MODEL file contains 50 shot records of a seismic experiment created with a finite-difference solution of the acoustic wave equation. The synthetics mimic data from the COCORP Mojave line 5 survey in southern California. The procedures below could also be used to stack the real data.

Click on each image for more details.

First decide which of the 50 records to process. We could do as little as one, but we'll do them all. The C-shell script file ``allstack.sh'' executes the ``stack.sh'' script on each of the fifty records. ``allstack.sh'' also supplies ``stack.sh'' with each record's plane number within the MODEL data file, the record's field record number, and the shotpoint location or VP number. In the MODEL file, note, the field record numbers are the same as the vibrator point numbers. This is not usually the case. Field record numbers are originally defined in the observer's reports, which usually have to be typed in. The observer's report for the MODEL data volume file is in the file ``model.obs''.

Most real surveys come on tapes, unlike the MODEL file.

Documentation and Parameters

Most of the programs described here take a number of parameter arguments. The programs are self-documenting, which means that if you run them without any arguments they will produce a list of the default parameters and quit. Try this for the ``window'' and ``cmpstack'' programs. If no default is listed after the ``='' sign in the self documentation, then that parameter is mandatory and must be supplied. To see what the parameters mean, look at the top of the file of C source code in the directory ``/rg''. window's code is thus in ``/rg/window.c''. You should look at this documentation for each of the programs mentioned here, and in the shell scripts ``allstack.sh'' and ``stack.sh''.

The parameters are supplied in a format that allows you give them in any order, ignore columns, make files of parameters, and alter pre-defined parameters on the command line. The format is defined in the on-line manual, ``man getpar''. You can identify ``getpar'' parameters by the ``='' sign. To the left is the name of the parameter, to the right is its value, which may be a number or a name. Most of the programs used here take getpar parameters, often pre-defined in files that are called on the command line. Usually you can alter any parameter in either the ``par'' file or the command line. Just remember that the last occurrence on the command line takes precedence. Parameters prefixed with a ``#'' are commented out.

Processing the data

Log into any of the Sun workstations or terminals, directly or remotely. Change to a scratch directory to which you have copied all the files mentioned here, except the 10 megabyte MODEL file. Make sure you save each file to your scratch directory with exactly the name that appears here (case matters):
allstack.sh stack.sh gepar model.mute
model.obs model.vp plstack.sh plstkpar
stkpar vmod.stack
We use our scratch directories because the processing involves large chunks of data that may not fit on the disk carrying our home directories. Contact sysadmin@seismo.unr.edu if you are not sure where your scratch directories may be. You will need at least 500 kbytes of space to process the MODEL records. Most real datasets would require 10 times as much, plus the tens of megabytes to gigabytes of space needed for the data volume file. Check the available space on different disks with the UNIX ``df'' command.

You will start processing with the command ``csh allstack.sh''. The ``allstack.sh'' script sequentially extracts each gather from the original MODEL data volume file (which you cannot alter) and processes it. You can edit the ``allstack.sh'' script to process only certain records by deleting all the calls to the ``stack.sh'' script for the records you do not want to process. The scripts will place messages on both the standard and the standard error outputs.

You can redirect all of these messages into a monitor file by appending ``>& mon'' to the end of the command. Then you would have a record of any error messages. You may further want to put the job in the background by appending a ``&'' to the command. You should also set your processing job to have a high ``nice'' value by prepending the script command with ``nice +15'', to avoid interfering with others' use of the workstation. Thus the complete command would be

	nice +15 csh allstack.sh >& mon &
With the job running in background you can make other use of the window, or even log out and the processing will continue while you step out for coffee. Simply check the ``mon'' monitor file periodically to see how the job is progressing. Depending on the worstation and its load, processing of all records should be complete within 10 minutes to an hour.

The stack.sh script uses networked file systems to move data from the MODEL file on the machine ``quake'' onto your scratch directory. Your scratch disk may not be on the machine ``quake''. However, the computations can be done on any of the Sun workstations. Whatever machine your shell or telnet window is logged into will actually process the computations. The network takes care of transferring data from the MODEL file to your disk elsewhere. From any terminal or workstation you can ``rlogin'' to any other machine and do the processing there. Processing the the MODEL records may take 16 minutes running on a Sun SPARC 2, and half that on some of the other machines. You can check to see how busy each machine is with the ``rup'' command (hit control-C when rup is done).

Pre-set processes

The lines in the ``allstack.sh'' script starting with ``csh'' run another shell script instead of a single program. This script can in turn invoke many different programs and even other shell scripts to let us carry out very complex processing sequences. The ``allstack.sh'' script supplies the ``stack.sh'' script with several arguments describing the data record to be extracted. These arguments are described in both scripts. They can be referenced from inside the called shell script with the shell command-line variables such as ``$1''. See ``man csh'' for a description of how shell variables work. To process the 50 gathers in the MODEL data file, ``allstack.sh'' will execute ``stack.sh'' 50 times.

The ``stack.sh'' script actually controls the processing of the data, and you should endeavor to understand everything it does. It is documented with comment lines. Many different programs are called by stack.sh. Each is a step in the normal pre-processing and stacking of seismic gathers. You should have to make very few changes to stack almost any data with this script. Each data set, however, will require many changes to the parameters read by the programs. Note that the parameters for two of the programs are collected into two different ``par'' files, ``gepar '' and ``stkpar ''. Note also the use of shell variables for certain parameters, which are sometimes used to override parameters in the par files. Closely examine all of the parameters and par files, referring to the source code in /rg of each program for their descriptions.

Plotting the result

Once allstack.sh has finished processing the records and you have inspected the monitor file ``mon'' for error messages, you can plot the stacked section. Note from stack.sh and the documentation for the ``cmpstack'' program that the stack is in the file named ``modelstack''. This file, however, is binary data and cannot be easily inspected on the terminal or edited (check ``man od'' if you want to see the numerical values). We can plot binary data, or images, with the ``viewmat'' program. Read ``man viewmat''.

Viewmat can most easily plot data that are purely binary floats. The cmpstack output file modelstack is labeled with trace headers, binary structures that describe the locations of the midpoints. It is easiest to strip the headers off before the stack is plotted. The ``strip '' program accomplishes this. The stack should also be checked for a good plotting amplitude.

The ``plstack.sh '' script is provided to run the programs required to plot. You should also understand how it works. Run the command ``csh plstack.sh '' to interpret the script. It strips the headers from the modelstack file, evaluates a good plotting amplitude, runs viewmat to get a PostScript plot description, spools the plot to the printer in 320 LME, and cleans up the temporary files. The par file ``plstkpar '' controls the appearance of the plot and its axes. It is also possible to edit the ascii PostScript file to make further changes.

ASSIGNMENT

Begin to accomplish the tasks that follow. Please show me your results of each step. I will be happy to help you at any time with any questions or problems. Save all of your plots and program changes in a notebook, which will help you carry out similar work later on.

Survey Geometry

The observer's report in the file ``model.obs'' defines the geometry of the MODEL survey. It refers to vibrator point locations defined in the file ``model.vp '', which is the surveyor's report. The formats of both files are defined at the beginning of the program ``/rg/label.c ''. With this information, determine the nominal source and receiver spacings, the maximum and minimum fold, and the minimum possible midpoint spacing. You don't have to plot the whole stacking diagram, just a little piece of it. Indicate a CMP gather on the diagram. What parts of the stacked section will have low fold? the maximum fold? Refer to the par file ``stkpar '' and ``/rg/cmpstack.c'' to see how the midpoint bins will be defined.

Stacking

Follow the procedure above to obtain a stacked section from the MODEL data. Mark some diffraction hyperbolas on the plot.

The cmpstack program used in the stack.sh script differs from most common-midpoint stacking routines in an important way. Most routines first require the completion of a pass of common-midpoint sorting before stack, where the data volume is effectively rotated about the time axis and re-sliced along planes of traces having common midpoints ( click here for an illustration of rotating a volume of seismic records). Then traces having the same midpoint are stacked together.

Cmpstack defines instead the entire midpoint versus time section each time it is run. After applying the normal-moveout correction, it implements the sorting step by summing the trace into the section at the appropriate midpoint. So the output of running cmpstack on a single shot record will be a mostly blank stack, with the NMO-corrected record inserted over its range of midpoints. An illustration of single-record stacks is available in GIF and PDF formats. These single-record stacks are summed into the accumulating stack of all records near the bottom of the stack.sh script by the hdadd program.

Migration

A fast, simple migration can be done with the ``/rg/stoltmig.c '' program. You should find out what parameter values it requires, build a parameter file, and run it directly. The modelstack file will also have to be stripped of headers before migration. Refer to the plstack.sh script to see how the strip program is used. Try a velocity of 2.2 km/s. Note that the output migration is larger than the input stack. You can either alter the parameters for the viewmat plotting program (plstkpar ) or use the ``window'' program (source code is in ``/rg/window.c'') to cut it down to the original size. Try additional migrations using velocities at least 50% different from 2.2 km/s. What happens to the reflections?

Depth Conversion

Depth-convert the migrated stacked section by assuming a constant velocity of 2.2 km/s. You can do this simply by relabeling the time axis of the plot to make it a depth axis. Just change the appropriate viewmat parameters in the par file plstkpar .

Intermediate Results

Plot the pre-stack shot gather from field record 334 after it has been operated on by each of the programs in stack.sh. You should obtain 5 different images showing the progressive effects of ``cull'', ``tegain'', ``label'', ``sphdiv'', and ``mute''. Label all plot axes and title them correctly by making viewmat par files similar to plstkpar . Note that some of the intermediate gather files are labeled with trace headers and some aren't. The most direct way to to this is to construct plotting scripts similar to plstack.sh and call them from within a modified version of stack.sh; run as in allstack.sh just for the one record.

Below are plots of two raw records. What kind of seismic wave carries most of the acoustic energy in these records?