.nr PO 1i .nr LL 6.5i .SH .ce3 SEISMIC PROCESSING EXERCISE J. Louie 5 July 1990 .SH Purpose .PP This exercise will let you take seismic data from raw field records to migrated stack in an industry-standard sequence. You should be familiar with the description of the "Resource Geology Seismic Processing System" as it is implemented here. Keep that document on hand for reference. You should also have some experience programming both in the C language and with UNIX C-Shell scripts. .SH .ce PROCEDURES .PP Follow the procedures below to stack the model data supplied on the tape labeled "MODEL". .SH Define records to stack .PP The MODEL tape contains 50 shot records of a seismic experiment created with a finite-difference solution of the acoustic wave equation. The synthetics mimic data from the COCORP Mojave line 5 survey in southern California. The procedures below could also be used to stack the real data. .PP 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". .PP 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 & 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. With the job running in background you can make other use of the window, or even log out and the processing will continue. Simply check the "mon" monitor file periodically to see how the job is progressing. .PP 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. .PP 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). .SH Pre-set processes .PP 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. .PP 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. .PP 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. .SH Plotting the result .PP 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". .PP 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. .PP 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. .SH .ce ASSIGNMENT .PP Begin immediately to accomplish the tasks that follow. Please show me your results of each step as soon as you can. I will be happy to help you at any time with any questions or problems. Save all of your plots and program changes in a notebook, which will help you carry out similar work later on. .SH Survey Geometry .PP 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. .SH Stacking .PP Follow the procedure above to obtain a stacked section from the model tape. Mark some diffraction hyperbolas on the plot. .SH Migration .PP 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? .SH Depth Conversion .PP 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. .SH Intermediate Results .PP 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. .SH Disk Storage .PP 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.