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.
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.
| allstack.sh | stack.sh | gepar | model.mute |
| model.obs | model.vp | plstack.sh | plstkpar |
| stkpar | vmod.stack |
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).
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.
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.
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.
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?
Below are plots of two raw records. What kind of seismic wave
carries most of
the acoustic energy in these records?
