The Resource Geology Seismic Processing System
John Louie
updated 12 March 2001
Java Alternative
See the JRG home page, or
http://crack.seismo.unr.edu/ftp/pub/louie/class/453/picklab/ for
a class exercise using JRG, the RG Seismic Processing System for Java.
JRG make it possible to do many of the things available in the RG
system, on any computer platform.
JRG includes a more user-friendly graphical interface, so no scripting
is needed.
Purpose
This is a description of a very limited, but workable seismic processing
system. I originally developed it
for my own use in Caltech's resource geology program, and have continued to
enhance it at Penn State's Department of Geosciences and the Seismological
Laboratory at the University of Nevada, Reno.
It has run on a VAX 11/780 under Berkeley 4.2 UNIX, and now runs on Sun
SPARCs under SunOS 4.1.4. It should run under any UNIX system
having a traditional Kernighan and Ritchie C compiler.
The system is meant to provide some
means of dealing with real seismic reflection datasets while retaining the
flexibility needed for research.
Location of the Software
Most of the software described here resides in the directory
/rg and its
sub-directories on the server ``
rumble.seismo.unr.edu'', which are accessible only locally.
The program list also provides local access
to codes and documentation.
Some pre-existing routines can be found
in /usr/local/bin and
/usr/local/src/sep/SEISMIC.
Other routines can be found in
/home/refl/clay and
/user/john/d.plot.
Users not from the UNR Seismological Lab can download most of the
source code for RG software as the UNIX compressed tar files:
Much of the RG system was derived from the 1981 philosophy if not the code
of the
Stanford Exploration Project (SEP)
founded and run by
Prof. Jon Claerbout.
Naturally since then the
SEP software library
has changed and improved considerably.
For those with UNIX workstations SEP offers some incredible
CD-ROMs
with interactive, reprodicible research results and seismic processing
programs.
If you are looking for seismic reflection processing software that is
interactive, good at the basic operations, user friendly, and free, then
you are looking for
Seismic UNIX (SU)
from the Center for Wave Phenomena (CWP)
at the Colorado School of Mines.
If you are looking for speedy, interactive, user-friendly seismic processing
that implements the latest technical advancements, then you need to buy PROMAX from
Advance Geophysical Corp. (7409 S. Alton Ct., Suite 220; Englewood, CO 80112).
On the other hand you may want to process one or a few 3-component earthquake
seismograms, and you should look at
SAC, the Seismic Analysis Code
from the Lawrence Livermore National Laboratory.
If you are trying to process field data from RefTek portable seismometers,
then you will need the
PASSCAL
software from the
Incorporated Research Institutions
for Seismology (IRIS).
The RG processing system is none of these.
It does not do some simple tasks well or at all, like reading SEG-B field
tapes, importing SEG-Y files, deconvolving, or correcting statics.
It has a very steep learning curve, and requires you to learn UNIX as well.
It will silently spit out garbage in response to simple parameter errors.
Yet it does provide a platform for developing and executing the most
advanced seismic imaging and inversion processes currently available.
For an example take a look at the goals of the
Center for Economic Migration
and Tomography.
Documentation
Attached to this paper is a list of the routines
I have developed. Each of
these carries a page or so of documentation at the beginning of the source file
that tells how to compile and run the program. For most of the programs,
running the code without giving any arguments will produce a list of arguments.
Most of the documentation is collected into the file
``/rg/documentation'' in
alphabetical order. Many other useful routines are documented in the
UNRSL on-line SunOS manual, often in chapter 1.
Process Flow
This processing system essentially runs just like normal programs and C-shells
within UNIX. This system is based on the sequential processing of seismic
gathers, instead of individual traces like most processing systems. However,
most of the routines are set so they are actually working on only one trace at
a time. Entire seismic survey data sets and resulting processed sections
are usually kept as UNIX files on disk. For even the largest reflection data sets,
the data usually start on a tape,
are processed one gather at a time, and the results put on disk to be plotted or
saved on tape later. There are three ways to accomplish something:
- Any of the processing programs may be run interactively on a single gather
within your login shell simply by providing the appropriate parameters and
input.
- The programs may be linked together within a shell script, which can
accept parameters and control the creation and destruction of temporary files.
Such a script may be used to process individual gathers or may themselves be
called from other shell scripts to process a suite of gathers already residing
on disk.
- Large numbers of gathers on disk (or tape) can be processed using the
Rdrec routine. Rdrec can function as a rudimentary processing monitor.
When given a list of gathers to read, it can in sequence put
each gather into a file and pass the name of the file and other arguments to
a shell script, which processes the gather before Rdrec gets the next one.
While this system does not provide the very efficient fully linked code of
a real processing system, it does make the addition of new routines very easy.
When run in a sub-directory of a Sun TMPFS /tmp
file system on a machine with sufficient memory such as rumble.seismo.unr.edu,
all codes and data reside in RAM and the processing will run at mini-supercomputer
speeds on a Sun SPARC10.
Data Types
Seven types of files are used in this processing system:
- C-Shell Scripts often control processing flow. They are usually written
to handle a particular task on a particular dataset. They contain the names
of data files, parameter files, and often parameters which must be modified
from task to task. Often they will control which disk partition the data
will reside in. Some of the more generally useful scripts are documented.
Their filenames should always be appended by ``.sh'' .
- Programs, written in C, are the foundation of the system. They are
written to be useful for a particular task on any dataset. Header data type
declarations and a very few parameters are incorporated into them, so they
must be recompiled to change these. All programs in the system carry
documentation at the head of the source code, and most are self-documenting
when run without arguments. Most of the programs perform extensive error
checks and will crash with an informative message if an error is detected.
- Parameter files are used by most of the programs. These ascii files carry
the arguments used by the programs, through the Getpar
(see on-line manual
chapter 1) mechanism. Usually, for any particular task, any shell scripts run
must be examined for the names of applicable parameter files. Then the program
documentation is used to guide the setting of parameter values for this task.
Their filenames should always contain ``par'' .
- Ascii Data files are also often referenced by programs. They contain
info such as VP coordinates, phase picks, or stacking velocities. They should
be created or edited according to the specifications in the documentation of
the calling program for each particular task. Their names are often suffixed or
appended by a special designation.
- Seismic Gather files contain most of the data used by the system, and
occupy the most disk space. All are in binary, with the actual seismogram
values in single-precision IEEE (Sun, IBM, and SEG-Y) floating point.
Seismograms are always arranged
into rows of time, so that the gather can be thought of as a vector of traces.
There are two types of gathers:
unlabeled and labeled. The labeled gathers have binary header information
written among the data in particular formats, while the unlabeled gathers are
just plain seismograms. Some programs, including all those in the
/usr/local/bin library,
work on unlabeled gathers since they perform only trace-independent operations.
Many other programs depend on trace-varying information that is carried in
the headers.
Shell scripts are usually set up to give names to seismic gather
files that are indicative of their processing history. The root of the name
indicates the area or project, and abbreviations of the processes it has
undergone are successively prefixed to it.
- Other Binary data files are used to contain information derived from
seismograms such as spectra, velocity semblances, or series of special
structures to hold information such as trace amplitude, or plots.
They are created
and read by certain programs according to the specifications in their
documentation, and their names may be appended by a special designation.
- PostScript files are created by a few of the newer plotting programs.
As they are ascii they may be edited, and can be plotted on the workstation
screens under a PostScript display application or spooled to a PostScript
printer. Their names are appended by ``.ps'' .
Headers
Some seismic gathers are labeled with binary information to aid the programs
that need to treat traces in their relationship to each other. This system
uses short, nonstandard headers that contain far less info than, say, the SEG-Y
format. There is not yet a program to convert SEG-Y headers to RG headers,
or vice-versa.
The programs
Strip and Merge can be used to convert an RG-labeled gather into an unlabeled one,
and vice-versa. Headers are most often originally created by one of the
programs that handles line geometry information, such as Label. The SEG-Y
headers supplied with outside data are often incomplete, so our local headers
need to be created from the original surveyors' and observers' reprts. The header
formats are defined by the structures in /rg/hd.h
(this is not actually included
by most of the programs). This header precedes each trace in a gather:
struct rghd
{
float offset; source-receiver offset, in meters, may be signed
float gx; receiver x-coordinate, m, E-W axis, east positive
float gy; receiver y-coordinate, m, N-S axis, north positive
float gz; receiver z-coordinate, m, usually elevation
int sp; source, receiver, field record, or midpoint number
};
This header is at the front of gather files:
struct rgfilhd
{
int ntrace; number of traces in file
int nt; number of samples per trace
float starttime;time after source initiation of 1st sample, seconds
};
Output
Unlabeled data volumes of any nature can be plotted on a Sun running
SunOS 4.x (not Solaris 2) using Viewmat, both on the
screen and to a PostScript device
(
see chapter 1 of the on-line manual).
Viewmat can show and animate color plots, which can be snapped into image files on the
screen, and yield color or monochrome PostScript files.
Labeled seismic gathers can be plotted using Radplotps, which yields traditional
variable-area wiggle traces to a PostScript file.
Although it sometimes requires some trial and error to get a visually pleasing
trace size, Radplotps provides full axis labeling. Large labeled gathers can
be plotted quickly to a raster file using Radrast, which does not provide any
axis labeling. Unlabeled gathers and other
data of a matrix nature can be plotted using Clayplot, for which no labeling
is provided. Clayplot, with output to a raster, provides the traditional
wiggle trace rendition of seismic data.
To print raster files,
see the on-line manual pages on ``sun2ps''.
At this stage, there are 4 ways to show plots:
- The output of any of the plotting routines can be shown on the Sun screen.
Postscript plots can be displayed via Pageview. Plots described by
the intermediate graphic language (IGL) can be displayed directly and through
conversion to PostScript. Raster files, both in the format output by
Clayplot and and in Sun's rasterfile(5) format, can also be displayed
with the Snapshot application.
Anything appearing on the screen can be printed on one of the
laser printers through Snapshot.
- The laser printers produce publication-quality graphics from a PostScript
description. For large amounts of data it can, however, be dreadfully slow.
- The Xmap application can interactively display labeled seismic traces
with respect to time or depth. The traces will need to be located relative
to latitude and longitude. Xmap can produce PostScript output for hard
copy, and these files can be interactively edited with IslandDraw or
the Adobe Acrobat system.
See the user's guide to Xmap and ``man graphedit''.
- Huge volumes of data are most effectively explored with volume visualization
facilities. The SunVision SunCube application
can render volumes in three dimensions, perform image processing,
and allow slicing and manipulation. To convert unlabeled
data to SunCube ``vff'' format, see the ``8bit'' utility in the /rg directory, and
Sun's documentation on the ``vff_create'' conversion program, reviewed
in a
Scientific Visualization lecture.
Images of rendered data volumes can be saved, or animated for output
to video tape or on-line movies.
Adding New Routines
To add a new routine one only needs to determine if it should accept labeled or
unlabeled gathers. To accept and/or output labeled gathers it must include
the header structures given above. It is helpful, of course, if the new program
includes documentation, is self-documenting, and uses Getpar parameter input
with parameter names like those used in similar programs.
Improvements to Make
It should be possible to write a simple command interpreter that can take a
list of brief commands and write a shell script and parameter files to perform
the task, while advising the user of the parameters that need to be set and the
other information that needs to be input. Most of the work in creating the
shell scripts is keeping track of temporary files and looking up parameter
names. Make could possibly handle this.
The deconvolution and filtering routines are compiled with a (large) hard trace size
limit; this can be eliminated.
A program to automatically read data labeled with SEG-Y headers and
convert them to the local headers, and vice-versa, should be available,
but it doesn't work yet.
No trace sorting capability is provided, although Cmpstack will sort and
stack in one operation.
A real system to actually correct for surface-consistent statics needs to be
written.
Example
The following shell script plots and stacks a common-shot gather. It is
run on a tape full of gathers by typing
rdrec par=readpar >& monitor &
``readpar'' is a parameter file set up according to the specifications in
Rdrec.c, which also tells how to construct ``records''. Error and other
messages can be put into ``monitor'' and examined while the processing is in
progress.
Rdrec reads each gather from tape to a file and then can run this script with
the arguments ``gatherfile fieldrec nx''.
#! /bin/csh
# Plot and stack a common-shot gather read by Rdrec
set nt=3000
# Put some info in the monitor file
echo Gather $2 `date`
# Remove possibly bad data values in gather
cull $nt 1e15 < $1 > tmp$1
rm $1
# Label gather with geometry derived from machine that did sorting
label par=lapar if=tmp$1 of=$1 rec=$2 noff=$3
rm tmp$1
# Apply trace equalization and correct for spherical divergence
quanteq par=eqpar < $1 > tr$1
rm $1
sphdiv par=eqpar cmp=$2 < tr$1 > eq$1
rm tr$1
# Plot equalized gather
viewmat par=pltpar if=eq$1
lpr -Ppostscript eq${1}.0.ps
# Apply mutes
mute par=mupar mutes=mute.surf cut=before cmp=$2 < eq$1 > tmp$1
rm eq$1
mute par=mupar mutes=mute.air cut=after cmp=$2 < tmp$1 > mueq$1
rm tmp$1
# Stack midpoint gather into single stacked trace
cmpstack par=stkpar stack=tempstk gath=$2 < mueq$1
# Stack the stack of the single gather to file holding stack of all gathers
rm mueq$1
if ( -e stackfile ) then
hdadd tempstk stackfile > temp
mv temp stackfile
rm tempstk
else
mv tempstk stackfile
endif
Of course, the parameter files ``lapar'', ``eqpar'', ``pltpar'', ``mupar'',
``stkpar'', and numerous other files specifying VP locations, trace headers
output by the machine that made the sorted tape, stacking velocities, and
mute times all need to be created according to the specifications in the
documentation of the calling programs. Once all of the gathers have been
processed, the resulting unlabeled stack ``stackfile'' is plotted using
Viewmat or Radplotps.
An exercise
has been prepared that provides a set of routines, parameter files,
and a data file.