June 28, 1993
Don Wagner, Paul Gutowski
3-D geometry & processing is inherently simpler than its 2-D analogue. This simplicity stems from the use of natural (X,Y) coordinates to locate the position (in plan view) of the sources, receivers, and common midpoint coordinates. Using this plan view, we can draw a series of straight lines parallel to the X and Y axes at constant increments to construct an orthogonal grid that describes a series of rectangular cells. The new system of rectangular cells becomes our relative coordinate system; the X,Y coordinates remain our exact coordinate system
Figure 1 shows the orthogonal grid used for 3-D data. We have altered the original SIS coordinate system definition and placed recording lines parallel to the Y axis rather than parallel to the X axis. This causes the X axis to be synomous with the variable LI (Line Index), and the Y axis to be synonomous withe variable DI (Depth Index). These 2 coordinates (LI,DI) establish the cell boundaries and serve as a relative system of coordinates. Whereas the actual (X,Y) coordinates are generally unwieldy numbers, our simpler (DI,LI) coordinates readily describe the position of cell boundaries.
The variables LI,DI refer to Depth Index and Line Index,respectively. These variable names come from the notion of recording a series of lines parallel to the Y-axis with each new line recorded at a constant increment in the positive X direction from the last line. Consequently, if the first line has an index of 1, the next lines have LI numbers equal to 2,3,4,...,N. Lines parallel to the Y-axis, we call the inline direction. Conversely, lines parallel to the X-axis we call crosslines (e.g. Xlines) and give them DI numbers equal to 1,2,3, ... , M.Thus, 3-D data is totally described by an (X,Y) coordinatesystem that positions sources, receivers, and common midpoint locations within rectangular cells bounded by LI,DI values. There are no artificial indices like source index and group index (SI, GI) that strive to describe 2-D data without using (X,Y) coordinates. Because 3-D data uses a natural coordinate geometry, we know the precise location of all elements from their (X,Y) coordinates, and the relative location of all elements from their (LI,DI) cell boundaries. Therefore, when we sort, correct for normal moveout & statics, composite, and time-slice our 3-D data volume, the geometry of (LI,DI) serves to unify and simplify our 3-D processing tools.To bridge from 3-D to 2-D, we fill each cell with the required number of traces to equal the maximum fold in each cell. This allows us to use all the programs in the conventional USP toolbox.
To process 3-D data, you need adequate storage. We used an 8-bay rack made by National Peripheral Incorporated (NPI) with 7 RS-3550 RARE Disks each with 3.5 gigabytes of memory. Our SPARC 10 system was configured to use disks 1, 2, and 3 as distinct disks, and disks 4-7 concatenated into a single 14 gigabyte data volume. The price including an 8mm tape drive for the 8th slot is ~$25k or ~$1k/gigabyte of disk storage. Thus the cost of purchasing a data storage disk plus 1 man-month of overhead to process a 3-D survey becomes competitive with the cost of a contractor processing a 3-D survey. The final obstacle to overcome is reading multi-volume data sets from a tape stacker. Joe Wade (.x4387) is working on this problem which may already be solved via program cram.
There are two general methods of sorting data in our 3D world: (1) sorting regular binned data on disk and (2) sorting based on X-Y trace coordinates. The first makes use only of the DI and LI indexing; the second is entirely general making use of the fundamental position information about the shot, reciver, and midpoint coordinates of each trace. The first is relatively fast but requires that one complete presorted copy of the data be on disk at any time; the second sorting method can sort from tape onto tape, making use only of a smaller intermediate disk file. Also the second method can be used to extract swaths or lines of data from the original volume.
To sort 3-D data using the the first method, we borrow the sort table concept from USP program presort to develop a 3-D version called presort3d. This program produces a table that allows the actual sort program to seek, select, and order traces according to LI or DI. Using the sort table of presort3d, we run program sisort3d to produce a 3-D data volume sorted on LI as the primary index and DI as the secondary index. The command line arguments for this sorting step are
presort3d -Ninput -Osort.table
sisort3d -Ninput -nsort.table -L -Ooutput
Figures 2 & 3 show the input and output data sets, respectively. In the input data each independent looking record corresponds to a different LI (from 1-6) and each trace corresponds to the same DI's that range from 1-91. So in this figure, the LI resemble RI's in the 2-D world and the DI's resemble trace numbers. In Figure 3, we note that what appear to be records begin with a small number of traces and slowly increase to hold a full suite of traces (equal to the fold). What we are viewing in Figure 3 is the first 500 traces of a record that contains all the traces recorded along LI = 1 ( some 8736 traces in this 3-D data volume). What look like independent records emerging in Figure 3 are actually the traces associated with a new DI. By the time we reach trace 401, we're looking at the traces associated with DI 30.
In addition to sorting using the relative coordinate system decribed by LI,DI, there are many occasions when sorting by X,Y coordinates is necessary. For example, if you select an arbitrary line across a 3-D survey, and select CMP sorted records along this line or even CMP records in a swath that straddles this line, we offer programs sr3d1 and sr3d2. These two modules correspond to the historic SIS module sr3d, which we divide into 2 modules, sr3d1 to produce a sort table, and sr3d2 to actually sort the data so that these two modules in tandem correspond to the presort3d, sisort3d concept previously discussed. Using the grid of Figure 1, Figure 4 below shows the corner numbering system..
An example of the sequence of these two programs might be:
sr3d1 -Ninput -Osr3d1.tbl -x11323500 -y1200100
-y3194200 -x31323200 -dx50 -dy100
where we have chosen to extract a 2-D pre-stack line from the volume along the dark diagonal line across the grid of figure 4 the ends of which are given by the coordinates (x1-y1) and (x3-y3). The desired cell dimensions are given by dx and dy. The default is to do a midpoint sort. An important feature of sr3d1 is the printout file (SR3D1.nnnnnn) which contains several useful reports:
1)Maximum source point X-coordinate = 1.32343E+06
2)Minimum source point X-coordinate = 1.32320E+06
3Maximum source point Y-coordinate = 201058.
4)Minimum source point Y-coordinate = 194261.
5)Maximum receiver point X-coordinate = 1.32365E+06
6)Minimum receiver point X-coordinate = 1.32302E+06
7)Maximum receiver point Y-coordinate = 200016.
8)Minimum receiver point Y-coordinate = 195504.
plus a fold distribution over all cells of the sort. The minimum and maximum X-Ys are for the entire data set and are output regardless of the user input X-Ys. If you don't know what the grid corners are then run sr3d1 with any suitable X-Ys on the command line then read the printout file for the needed information.
The actual physical sorting is done as follows:
sr3d2 -Ninput -Dtmp -Oline -Psr3d1.tbl
where tmp is the intermediate disk file and sr3d1.tbl is the sort table. Once the intermediate disk file has been created subsequent sorts may be done without recreating it by including -go on the sr3d2 command line. This will greatly speed up these subsequent sorts. The results of the above sort is shown below in figure 5 which displays every 10th CDP along the traverse of figure 4. The maximum fold in this case was 39 and each CMP record was filled out to the full fold with dead traces as necessary.
If we knew the proper normal moveout correcttion, we could apply it to this data. Other wise, we can expand the sorted data to fill each distinct (LI,DI) cell with the number of traces equal to the maximum fold and do conventional velocity analysis. Program pack3d serves to bridge the 2-D and 3-D worlds by perfoming this packing or unpacking operation. The command line arguments are
pack3d -N output -O equal_traces
and the resultant output is shown in Figure 6. Note how the distinct looking records have 58 traces now and the data resembles a series of common midpoint records. In effect, line 1 of our 3-D survey has been divided into 231 distinct records each with 58 traces. Here 231 corresponds to the number of distinct DI numbers in the survey, and 58 corresponds to the maximum fold. Additionally, now that the data has an equal number of traces per record, we can filter, deconvolve, mute, . . . this new data set with existing tools.
If no velocity survey from a well is available, form a super CMP gather from all or portions of the 3-D sorted data set to arrive at a single CMP record or a set of CMP records.. Of course, to compute a single velocity spectrum for a 3-D survey implies that the velocity profile is robust and that variances are small perturbations. If this assumption is not valid, subdivide the 3-D volume into mini-volumes until the assumption is valid. The super gather is constructed as an intelligent vertical stack of either LI's or DI's. If for example, you wished to form a super-gather consisting of stacking six LI's together, you would execute the command line
rstak3d -N equal_traces -n 1386 -xf 6000 -xd 100 -O gather
where the arguments -xf6000 and -xd100 specify the model spread for a super-gather with far range of 6000 feet, near range of 0 feet, and cell size of 100 feet; and the argument -n1386 specifies to stack 1386 records (6 times the 231 DI's per line) to form CMP's for lines 1-6, 7-12, 13-18, & 19-24. These four CMP's would each have 61 traces representing offsets 0 - 6000 feet. If we wanted to form one super-gather formed by stacking all 24 LI's together, we would issue the command:
rstack3d -Nequal_traces -n5544 -xf6000 -xd100 -Ogather
to compute a single 61 trace CMP for the entire 3-D survey ( Figure 7).The supergather also shows which parts of the data should be muted.For example, we can apply a surgical mute to remove the inside cone and delete all events inside the air wave (1100 ft/sec), the portion of vibroseis known as the cone of despair. We typically delete this portion of Vibroseis data as shown in Figure 8.
Whether you have a single velocity profile or multiple velocity profiles, it is necessary to interpolate the functions so that each LI,DI cell has a distinct velocity function. We achieve this by extracting module vi3d from SIS program mc3d. Program vi3d reads velocity functions designated at specific LI,DI locations and interpolates in space and time to produce a velocity cube described by a function V(LI,DI,T). To show an example of how this works, let's assume a data volume that's 200 x 200 x 250; and let's input a velocity profile with a linear gradient in time at one corner and a 2nd velocity profile with a different linear velocity gradient in time at the corner diagonally opposite. Now, if we interpolate with program vi3d and examine 2 time-slices from the resulting 3-D velocity cube; we should see velocity gradients on each time-slice and they should be different. The command line arguments are
vi3d -dt4 -e1004 -Cvi3d.cards -Ovelgrad
dslice -Nvelgrad -s0 -e1004 -i1004 -Ovelslices
where -dt4 signifies a 4ms sample interval, -e1004 signifies a trace length of 1004 ms, -Cvi3d.cards points to a card file named vi3d.cards that requests a 200 x 200 velocity grid with a cell geometry of 100 x 100 spatial units. The card file is shown in Figure 9 and mimics the card file of the USP program mc3d. If we slice the 3-D velocity cube at times of 0 and 1000ms with program dslice, we see a velocity gradient on slice 1 that starts at 5000 and increases diagonally to 10000, and a velocity gradient on slice 2 that starts at 10000 and increases diagonally to 15000 (Figure 10).
We apply normal moveout corrections with program anmo3d. The seismic data can be in tape or disk format but the velocity data must reside on disk. The requirement for disk residency stems from the application of a distinct velocity correction trace for each LI,DI cell location. As the seismic traces are read, we interrogate the trace header for LI,DI then randomly access the velocity trace corresponding to this LI,DI. And since the seismic data can come in any order, we cannot predict its LI,DI cell location until we read its trace header. The command line arguments for anmo3d are
anmo3d -Ninput -vvelgrad -Oinput.nmo
where -vvelgrad specifies the disk file that contains the 3-D velocity cube. Figure 11 shows the data of Figure 2 after normal moveout correction.
You guessed it. We stack 3-D data with stack3d. The command line arguments are
stack3d -Ninput.nmo -Oinput.stack
The data must be sorted but does not have to exist in a packed format with an equal number of traces per record. Figure 12 shows record 13 from the above stack. This record corresponds to LI 13. I t represents an inline stack for line 13. Each succeeding record corresponds to the next inline stack. To view crossline stacks, exchange record number & trace number with program resorter (a USP program that exchanges traces with records; type uman resorter for documentation). This program takes the jth trace from each record to form a new crossline record consisting of traces in the jth position. This process is repeated until an input data set of N lines with M traces becomes a data set with M lines and N traces. Figure 13 shows the crossline stack corresponding to DI 178. Even with only 24 traces, it is easy to see a fault dipping from upper left to lower right as it intersects the reflector at 500 ms.
The regular 2D stacking program stack can also be used but the 3D data must first be passed through program pack3d for regularization.
At the request of the OBU, we converted SIS program at3d to the UNIX platform. This program allows the user to select an arbitrary traverse through a 3-D volume by selecting the (LI,DI) coordinates where two linear segments of the traverse intersect. Using a time slice of the 3-D data volume (Figure 14), the user can pick arbitrary points on the time slice and compute a seismic traverse that connects these points with straight line segments. You select the output CMP interval, and the program computes an output trace by a weighted (according to offset from the computed output location) average of the four nearest neighbors. Because each output trace is the composite of its nearest neighbors, it will have a higher S/N ratio than the trace at any arbitrary cell location. Let's compute the section described by the linear traverse in Figure 14. Note how Figure 15 portrays a section (from left-right) that starts in the lower right section of the time slice and extends to the upper left in a seemless fashion. Figure 16 is the corresponding fence traverese that portrays a rectangular box that goes counter-clockwise fromthe upper left corner in Figure 14.
Here again the only clues we have to the traverse changing from inline to crossline is the different mute pattern in the early portion of the trace. The command line arguments for at3d are
at3d -Ndata -Ppick.file -Ccardin -Otraverse
where pick.file is an xsd pick file and the file cardin a replica of the SIS at3d format. Figure 17 shows the card image for the file cardin. The pick file can override the traverse parameters present on the 5AT3D card. In fact, command line arguments exist for all the parameters in the file cardin.
This note describes several new 3-D processing tools and refers to other tools as well. You'll find online documentation through the USP menu program: xuspman under the category 3D. Alternately, each tool has a man page that paints on the screen with the command: uman PROGRAM where PROGRAM signifies a specific processing tool. FInally, you can invoke a short synopsis of the command line arguments by typing the name of the processing tool followed by `-?', e.g. presort3d `-?'.
We would be remiss if we failed to mention Gary Ruckgaber, Gary Murphy and several of the original SIS staff who assembled Amoco's 3-D processing system a decade ago. We were able to stand on their shoulders to create several of the `new' processing tools described herein. Their insight was keen and we used it to create UNIX versions of several of the original SIS codes.
Return to the USP Home Page.
