First decide which of the 50 records to process. We could do as little as one, but we'll do them all. The text file ``allrecs'' contains a list of all fifty records, by line number (which is ``1'') and field digital record number. On the MODEL tape, 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 tape is in the file ``model.obs''.
Next we have to find out which tapes all these records are on. Most real
surveys come on a whole boxful of tapes, unlike MODEL. Here, the file ``tapes''
describes what range of record numbers is found on each tape, by name.
The program ``sortrec'' uses this information to produce a file for each tape
showing where to find each of the records requested. You run it with
``sortrec tpmap=tapes gather=96
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.
You can see that the ``tpmap'' parameter to sortrec takes the name of the file
describing what records are on which tapes, which happens to be the same as
the default file name ``tapes''. The ``gather'' parameter needs the number of
traces, or seismograms, in each field record, which in our case is 96.
Sortrec further takes any number of line and record numbers on the standard
input, which we supply in the file ``allrecs'', although we could type them in
interactively while sortrec is running. Standard input is terminated with a
``control-d'', just like text files are.
Now that you have run sortrec, you should notice that a new file has been
created in your directory called ``MODEL'', the name of the tape.
The only other output sortrec gives is some info on where it found the records.
If the records
you requested in ``allrecs'' had been on more than one tape, a file would
have been created for each tape. It defines how many records are in front
of each gather, to allow the reading program to locate each one. To process
a tape, you will use the file having the name of the tape.
The MODEL tape should be on our tape rack in 278 LMR. If someone is using the
tape drive already you can usually ask around and find out when they'll be done.
Switch the tape drive
power on and wait a few seconds for the self-test lights to blink out. Pull
the door open and pull the locking lever on the upper hub. Mount the tape
clear side out and lock the hub. Thread the leader through according to the
diagram on the inside of the door. The most common mistake is not threading
over the tensioning roller on the upper right. Hold the tape to the take-up
reel with a few turns. Close the door and push the ``start'' button. The tape
should spin for a few seconds, then the control display should indicate ``LP''
to show that the drive has found the load point.
Later you can unload the tape by pushing the ``reset'' and ``unload'' buttons,
opening the door, and unlocking the hub. Then close the door, turn the drive
power off, and hang the tape on the rack.
Give the command ``rdrec par=rdpar
The contents of the par file ``rdpar'' are described in the documentation at the
beginning of ``/rg/rdrec.c''. The parameters prefixed with a ``#'' are commented
out. They represent specifications for the actual COCORP tapes from the Mojave
lines. The specifications are somewhat different for the MODEL tape, which are
not commented out.
The ``tapehost'' parameter lets us process data on a machine
that is different from the machine that has the tape drive. Only the machine
``quake'' has a nine-track tape drive. The rdrec program uses quake to
move data from tape onto your directory in /s1. The /s1 disk does happen to be on the machine
``quake''. However, the computations can be done on any of the Sun workstations.
Whatever machine your shell window is logged into will actually process the
computations. The network takes care of running the tape drive on quake,
and accessing a disk elsewhere. From any terminal or workstation you can
``rlogin'' to any other machine and do the processing there. Processing the
the MODEL tape may take 16 minutes running on quake, 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 command line at the beginning of the comline file is actually a command
to run a shell script instead of a single program. This script can invoke
many different programs and even other shell scripts to let us carry out
very complex processing sequences. The rdrec program supplies the command
in comline with several arguments describing the data it just extracted.
These arguments are described in ``/rg/rdrec.c''. They can be referenced from
inside the 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 on the MODEL tape, rdrec will execute the command
in comline 50 times.
The command in the comline file is to execute the C-shell script ``stack.sh''.
This 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. 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.
Viewmat can only plot data that are purely binary floats. The modelstack
output is labeled with trace headers, binary structures that describe the
locations of the midpoints. These headers must be stripped off before the
stack can be 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.
Loading the tape
You are now ready to load the MODEL tape and process it with the pre-set
parameters to make a stacked section. If more than one tape were involved, you
would process each tape in turn.
Processing the tape
With a tape loaded you can now begin processing. Log into any of the Sun
workstations or terminals. Change to your directory in /s1 that has all the
files mentioned here. We use our /s1 directories because the processing
involves large chunks of data that may not fit on the disk carrying our home
directories. You will need at least 500 kbytes of space to process the MODEL
tape. Most real datasets would require 10 times as much. Check the available
space on different disks with the UNIX ``df'' command.
Pre-set processes
The most important parameter given to the rdrec program by the rdpar file
is the ``run'' parameter. It is set to the name of a file that contains
a command to be executed once each field record, or shot gather, has been
extracted to disk. The command could do nothing or anything. In this case,
the run parameter is set to the file ``comline'', which contains the command
that processes the data file and then removes it from the disk.
Plotting the result
Once rdrec has finished processing the tape and you have removed it from the
drive, 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''.
ASSIGNMENT
Survey Geometry
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 files are
defined at the beginning of the program ``/rg/label.c''. With this information,
determine the nominal source and receiver spacings, the maximum and minimum
fold, and the minimum possible midpoint spacing. You don't have to plot
the whole stacking diagram, just a little piece of it. Indicate a CMP gather
on the diagram. What parts of the stacked section will have low fold? the
maximum fold? Refer to the par file ``stkpar'' and ``/rg/cmpstack.c'' to see
how the midpoints will be defined.
Stacking
Follow the procedure above to obtain a stacked section from the model tape.
Mark some diffraction hyperbolas on the plot.
Migration
A fast, simple migration can be done with the ``stoltmig'' 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?
Depth Conversion
Depth-convert the migrated stacked section by assuming a constant velocity of
2.2 km/s.
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 par file
plstkpar.
Intermediate Results
Plot the pre-stack shot gather from field record 334 after it has been operated
on by each of the programs in stack.sh. You should obtain 5 different images
showing the progressive effects of ``cull'', ``tegain'', ``label'', ``sphdiv'', and
``mute''. Label all plot axes and title them correctly by making viewmat par
files similar to plstkpar. Note that some of the intermediate
gather files are labeled with trace headers and some aren't. The most direct
way to to this is to construct plotting scripts similar to plstack.sh and call
them from within a modified version of stack.sh; run by rdrec just for the
one record.
Disk Storage
Having to mount a tape every time you want to process a gather is rather
painful. It is usually necessary because most datasets are several gigabytes,
and we only have 10% of the necessary disk space. (Note that the stacked
and migrated sections only take a small fraction of the space that would be
required by the pre-stack data.) The MODEL tape, however, only carries about
10 Mbytes of data, which may be available on the /s1 disk. Propose a method
of extracting the data onto disk first, then using it from disk to make the
stack. You should only have to change some of the shell scripts, perhaps
making a new one that sequentially processes the saved gathers, instead of
rdrec.