The Resource Geology Seismic Processing System

John Louie

updated 14 July 2014

Java Alternative

See the JRG home page, or 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. Recently, students and I have used JRG interactively to read SAC, SEG-Y, and other data types; doing preprocessing on shot records; and then putting them out in the new RG format for advanced processing such as PSDM using RG codes. Some new RG codes put their results into the new RG format, for easy visualization with JRG.


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 was developed on a VAX 11/780 under Berkeley 4.2 UNIX, and at the turn of the century on Sun SPARCs under SunOS 4.1.4.

It should run under any UNIX system having a compiler implementing traditional Kernighan and Ritchie C. Recently I have brought many RG codes up to date for use on Linux and MacOS X 10.9 Mavericks. The system is meant to provide some means of dealing with real seismic reflection datasets while retaining the flexibility needed for research.

Downloading the Software

Most of the RG source code, and a compile script, are in these archives: 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 the open-source systems Seismic UNIX (SU), Madagascar, or OpendTect. If you are looking for speedy, interactive, user-friendly seismic processing that implements the latest technical advancements, then you need to buy Parallel's Seismic Processing Workshop, GNS Science's Claritas, or Halliburton's ProMAX.

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.


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. Many other useful routines are documented in the UNIX/Linux ''man'' on-line 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:
  1. 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.

  2. 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.

  3. 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, 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:


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


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:

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.


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}
# Apply mutes
mute par=mupar 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
	mv tempstk stackfile
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.

Attachment: Program List

An exercise has been prepared that provides a set of routines, parameter files, and a data file.