RG Seismic Processing Exercise
6 October 1996
This exercise will let you take seismic data from raw field records
migrated stack in an industry-standard sequence.
You should be familiar with the description of the
Geology Seismic Processing System'' as it is implemented here.
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
http://crack.seismo.unr.edu/ftp/pub/louie/rg/, and through links from
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.
Follow the procedures below to stack the synthetic data supplied in
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
California. The procedures below could also be used to stack the
Click on each image for more details.
First decide which of the 50 records to process. We could do as
one, but we'll do them all. The C-shell script file ``allstack.sh''
executes the ``stack.sh'' script on each of
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
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
MODEL data volume file is in the file ``model.obs''.
Most real surveys come on tapes, unlike the MODEL file.
- If you have 9-track reel tapes, you should consult the
old version of this exercise, which
programs helpful in extracting and processing records from a data
across a series of tapes.
- If your data is written as one of several files
on a SEG-Y format 8 mm Exabyte or 4 mm DAT tape, you will want to
UNIX on-line manual pages for the ``mt'' and
``dd'' commands, the
self-documentation of the /rg/window.c
program, and about the Society of
You will end up extracting an unlabeled binary
IEEE float data file similar to
the ``MODEL'' file.
- If your data is on an archive tape volume (e.g.: in ``tar'' or
``dump'' format) or comes on a
disk, you will probably end up using
/rg/window.c to produce an
volume from a
SEG-Y format file restored to your hard disk.
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
any arguments they will produce a list of the default parameters and
Try this for the ``window'' and
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
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
ignore columns, make files of parameters, and alter pre-defined
the command line. The format is defined in the on-line manual,
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
files that are called on the command line. Usually you can alter any
parameter in either the ``par'' file or the command line. Just
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
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):
We use our scratch
directories because the processing
involves large chunks of data that may not fit on the disk carrying
email@example.com if you are not sure where your scratch
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
megabytes to gigabytes of space needed for the data volume file.
Check the available space on different disks with the UNIX
You will start processing with the command ``csh 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
by appending a ``&'' to the command. You should also set your
job to have a high ``nice'' value by prepending the script command
``nice +15'', to avoid interfering with others' use of the
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
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
complete within 10 minutes to an hour.
The stack.sh script uses networked file
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
Whatever machine your shell or telnet window is logged into will
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.
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
machine is with the ``rup'' command (hit control-C when rup is done).
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
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
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
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
make very few changes to stack almost any data with this script.
set, however, will require many changes to the parameters read by the
Note that the parameters for two of the programs are collected into
different ``par'' files, ``gepar '' and
Note also the use of shell variables for certain
parameters, which are sometimes used to override parameters in the
Closely examine all of the parameters and par files, referring to the
code in /rg of each program for their
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
Note from stack.sh and the
documentation for the ``cmpstack'' program that the stack is
file named ``modelstack''. This file, however, is binary data and
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
program. Read ``man viewmat''.
Viewmat can most easily plot data that are purely binary floats.
The cmpstack output file
is labeled with trace headers, binary structures that describe the
locations of the midpoints. It is easiest to strip the headers off
stack is plotted. The ``strip '' program accomplishes this. The
also be checked for a good plotting amplitude.
The ``plstack.sh '' script is provided to run the programs required to
You should also understand how it works. Run the command ``csh
to interpret the script. It strips the headers from the
modelstack file, evaluates a good plotting amplitude, runs viewmat to
PostScript plot description, spools the plot to the printer in 320
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
make further changes.
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
changes in a notebook, which will help you carry out similar work
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
defined at the beginning of the program ``/rg/label.c ''. With this
determine the nominal source and receiver spacings, the maximum and
fold, and the minimum possible midpoint spacing. You don't have to
the whole stacking diagram, just a little piece of it. Indicate a
on the diagram. What parts of the stacked section will have low
maximum fold? Refer to the par file ``stkpar '' and ``/rg/cmpstack.c'' to see
how the midpoint bins will be defined.
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.
A fast, simple migration can be done with the ``/rg/stoltmig.c '' program.
find out what parameter values it requires, build a parameter file,
run it directly. The modelstack file will also have to be stripped
before migration. Refer to the plstack.sh script to see how the
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
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-convert the migrated stacked section by assuming a constant
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
Plot the pre-stack shot gather from field record 334 after it has
on by each of the programs in stack.sh. You
should obtain 5 different images
showing the progressive effects of ``cull'',
Label all plot axes and title them correctly by making
files similar to plstkpar . Note that some of the intermediate
gather files are labeled with trace headers and some aren't. The
way to to this is to construct plotting scripts similar to plstack.sh
them from within a modified version of stack.sh; run as in allstack.sh just for the
Below are plots of two raw records. What kind of seismic wave
carries most of
the acoustic energy in these records?