Ex. PGS 2004
`
`EX. PGS 2004
`
`
`
`
`
`
`
`

`
`2/15/2015
`[frame][postscript]
`
`3­D PROCESSING TOOLS
`
`3­D PROCESSING TOOLS
`
`June 28, 1993
`
`Don Wagner, Paul Gutowski
`
`Introduction
`
`This note announces the development of basic processing tools for use with 3­D data. With recent work to extend our
`demultiple process into 3­D, with a current project to stream 3­D data from Landmark & Geoquest Interpretive Workstations
`through USP filters and back, and from a written request from the OBU to construct arbitrary traverses through a stacked 3­D
`data volume; it became necessary to establish an infrastructure to both facilitate and expedite 3­D data within the USP
`framework. This note shows these tools and how to use them.
`Geometry
`
`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.
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`1/9
`
`Ex. PGS 2004
`Page 1
`
`

`
`2/15/2015
`
`Data Storage & Tapes
`
`3­D PROCESSING TOOLS
`
`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.
`Sorting
`
`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.
`Sorting on LI,DI Indexes
`
`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
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`2/9
`
`Ex. PGS 2004
`Page 2
`
`

`
`3­D PROCESSING TOOLS
`2/15/2015
`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.
`Sorting on X,Y Coordinates
`
`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
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`3/9
`
`Ex. PGS 2004
`Page 3
`
`

`
`3­D PROCESSING TOOLS
`2/15/2015
`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.
`
`Bridge between 3­D and 2­D
`
`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.
`
`Super­gathers
`
`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
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`4/9
`
`Ex. PGS 2004
`Page 4
`
`

`
`3­D PROCESSING TOOLS
`2/15/2015
`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.
`
`Interpolating Velocity in 3­D
`
`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
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`5/9
`
`Ex. PGS 2004
`Page 5
`
`

`
`2/15/2015
`vi3d ­dt4 ­e1004 ­Cvi3d.cards ­Ovelgrad
`
`dslice ­Nvelgrad ­s0 ­e1004 ­i1004 ­Ovelslices
`
`3­D PROCESSING TOOLS
`
`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).
`
`Normal Moveout Corrections in 3­D
`
`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.
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`6/9
`
`Ex. PGS 2004
`Page 6
`
`

`
`2/15/2015
`
`Compositing 3­D data
`
`3­D PROCESSING TOOLS
`
`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.
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`7/9
`
`Ex. PGS 2004
`Page 7
`
`

`
`2/15/2015
`
`3­D PROCESSING TOOLS
`
`Arbitrary Traverses in a Stacked 3­D Volume
`
`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.
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`8/9
`
`Ex. PGS 2004
`Page 8
`
`

`
`2/15/2015
`
`3­D PROCESSING TOOLS
`
`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.
`Documentation
`
`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 `­?'.
`Acknowledgements
`
`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.
`
`http://www.freeusp.org/RaceCarWebsite/TechTransfer/Reports/USPNotes/3d_tools/3d.html
`
`9/9
`
`Ex. PGS 2004
`Page 9