.TL The Resource Geology Seismic Processing System .AU John Louie .AI 30 August 1990 .SH Purpose .PP 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. It has run on a VAX 11/780 under Berkeley 4.2 UNIX, and now runs on Sun 3s and 4s under SunOS 4.0. The system is meant to provide some means of dealing with real datasets while retaining the flexibility needed for research. .SH Location of the Software .PP Most of the software described here resides in the directory /rg and its sub-directories on the server "quake". Some pre-existing routines can be found on the server "seismic" in /usr/local/bin and /usr/local/src/SEISMIC. Other routines can be found in /user/clay and /user/john/d.plot. .SH Documentation .PP 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. All of the documentation is collected into the file "/rg/documentation" in alphabetical order. Many other useful routines are documented in the on-line manual, often in chapter 1. .SH Process Flow .PP 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. Since there is only one tape drive, 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: .IP 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. .IP 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. .IP 3) Large numbers of gathers on tape (or disk) can be processed using the Rdrec routine. Rdrec can function as a rudimentary processing monitor. When given a list of gathers to read from a tape, 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 from the tape. .LP 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. .SH Data Types .PP Seven types of files are used in this processing system: .IP \(bu 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" . .IP \(bu 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. .IP \(bu 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" . .IP \(bu 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. .IP \(bu 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 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 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. .IP \(bu 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. .IP \(bu 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 NeWS or on spooled to the Laserwriter. Their names are appended by ".ps" . .bp .SH Headers .PP 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. The programs Strip and Merge can be used to convert a 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 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: .LP struct rghd .IP { .br float offset; \f2 source-receiver offset, in meters, may be signed \f1 .br float gx; \f2 receiver x-coordinate, m, E-W axis, east positive \f1 .br float gy; \f2 receiver y-coordinate, m, N-S axis, north positive \f1 .br float gz; \f2 receiver z-coordinate, m, usually elevation \f1 .br int sp; \f2 source, receiver, field record, or midpoint number \f1 .br }; .LP This header is at the front of gather files: .LP struct rgfilhd .IP { .br int ntrace; \f2 number of traces in file \f1 .br int nt; \f2 number of samples per trace \f1 .br float starttime; \f2 time after source initiation of 1st sample, seconds \f1 .br }; .SH Output .PP Unlabeled data volumes of any nature can be plotted using Viewmat, both on the screen and to a PostScript device (see chapter 1 of the on-line manual). Viewmat can yield color plots on the Sun 3/60 workstation screen, which are easily photographed, or color or monochrome PostScript files. Labeled seismic gathers can be plotted using Radplot, which yields a PostScript description. Although it sometimes requires some trial and error to get a visually pleasing trace size, Radplot 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". .PP At this stage, there are 4 ways to show plots: .IP \(bu The output of any of the plotting routines can be shown on the screen. Postscript plots can be displayed via the NeWS system. 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. Anything appearing on the screen can be printed on one of the laser printers. .IP \(bu The laser printers produce publication-quality graphics from a PostScript description. For large amounts of data it can, however, be dreadfully slow. .IP \(bu The Wellmap utility can interactively display labeled seismic traces with respect to time or depth. The traces will need to be located relative to latitude and longitude. Wellmap can produce PostScript output for hard copy, and these files can be interactively edited with the "graphedit" utility. See the user's guide to Wellmap and "man graphedit". .IP \(bu Huge volumes of data are most effectively explored with the visualization facilities attached to the server "quake". The Sun TAAC-1 Application Accelerator can render volumes in three dimensions, perform image processing, and allow slicing and manipulation. To convert unlabeled data to TAAC "tv" format, see the "8bit" utility in the /rg directory, and Sun's documentation on the "taslicetotv" conversion program and the "voxvu" volume rendering package. Rendered data volumes can be photographed, converted to monochrome PostScript with the "image" utility, or animated for output to video tape. See the TAAC documentation on "a2bitmovie" and "make_movie". .SH Adding New Routines .PP 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. .SH Improvements to Make .LP 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. .LP These routines should be integrated with the interactive graphic database system being developed by R. Clayton and B. Worden at Caltech. They should also take advantage of the TAAC-1 Application Accelerator on the machine quake, and be more network-conscious in general. .LP The deconvolution and filtering routines are compiled with a hard trace size limit; this can be eliminated. .LP 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. .LP No trace sorting capability is provided, due to the absence of a second tape drive. However, the implementation of the interactive database system will make sorting obsolete. .LP A real system to actually correct for surface-consistent statics needs to be written. .bp .SH Example .PP The following shell script plots and stacks a common-midpoint gather. It is run on a tape full of gathers by typing .IP .B rdrec par=readpar >& monitor & .R .LP ``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. .LP Rdrec reads each gather from tape to a file and then can run this script with the arguments ``gatherfile cmp nx''. .IP .B # Plot and stack a common-midpoint gather read by Rdrec .br set nt=3000 .br # Put some info in the monitor file .br echo Gather $2 `date` .br # Remove possibly bad data values in gather .br cull $nt 1e15 <$1 >tmp$1 .br rm $1 .br # Label gather with geometry derived from machine that did sorting .br label par=cmpar if=tmp$1 of=$1 cmp=$2 noff=$3 .br rm tmp$1 .br # Apply trace equalization and correct for spherical divergence .br quanteq par=eqpar <$1 >tr$1 .br rm $1 .br sphdiv par=eqpar cmp=$2 eq$1 .br rm tr$1 .br # Plot equalized gather .br radplotps par=pltpar file=eq$1 | lpr -PPostScript .br # Apply mutes .br mute par=mupar mutes=mute.surf cut=before cmp=$2 < eq$1 > tmp$1 .br rm eq$1 .br mute par=mupar mutes=mute.air cut=after cmp=$2 < tmp$1 > mueq$1 .br rm tmp$1 .br # Stack midpoint gather into single stacked trace .br stack par=stkpar stack=tempstk cmp=$2 >stackfile .br rm mueq$1 .br echo _______________________________________________________________________ .R .LP Of course, the parameter files ``cmpar'', ``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 Clayplot. .PP An exercise has been prepared that provides a set of routines, parameter files, and a data tape. See J. Louie.