SEP Home About SEP People Research Courses Software TeX Software SEPlib Changes SEPlibv6.0 Environment Installing Old Versions SEPlib3d SEPlib Overview Internal Info Introduction Utilities Specifications

Introduction

• Separate the geometry information from the seismic data.
  This simple but powerful idea is crucial for efficiently processing large amount of data, such as in 3-D prestack data sets. It allows to minimize the access to the usually bulky seismic data files, while performing many useful operations on the trace headers and on specific subsets of the seismic traces.
• Exploit as much as possible the existing regularity in the data geometry.
  Regularity is important when analyzing and visualizing the data; further, it helps the development of simple and efficient code. SEPlib3d ``regularizes'' an irregularly sampled data sets by associating the data traces with a uniformly sampled multi-dimensional grid. This gridding information is then exploited by SEPlib3d application and utility programs to efficiently select and access the seismic traces.

Another important characteristic of SEPlib3d is that it is a generalization of SEPlib and not a completely new system. There are many good reasons for this choice. From the user point of view, it enables users familiar with SEPlib to quickly master SEPlib3d. Further, it enables SEPlib3d to leverage the considerable amount of coding and brain power that went into SEPlib. In particular we use the SEPlib routines for accessing files (both ASCII and binary), and build SEPlib3d capabilities on the top of these routines.

Data Format

Structure of a SEPlib3d data set

In addition to the links to the other files, the History File contains the processing history of the data set. The Data Values File (DVF) is defined as collection of fixed length records ( data records ) that contain the data values. Typically the data records are seismic traces. The header values are stored in the Header Values File (HVF), that is defined as a collection of fixed length records ( header records ) describing the geometry and properties of the associated data records. The header parameters are described in the Header Format File by a table of header keys. A header keys specifies the name of the header parameter ( key name ), its data type ( key type), and its position in the header record ( key index ). The association between the header records and the data records is described below.

If the data set has been binned on a regularly sampled grid, the Grid Format File contains the description of the grid. The Grid Value File contains the mapping information between the grid cells and the corresponding header records. The Grid Value File does not exist if the gridding is regular; that is, there is a one-to-one correspondence between grid cells and header records.

Data and Headers Coordinate System

The Header Format File contains also the usual SEPlib3d parameters ni, oi, di, labeli(where i=[1,2,3,...]) describing the Header Coordinate System. The number of header keys in the header records is given by n1 and the the number of header records is equal to the product (n2*...*ni*...).

Mapping between the header records and the data records

Gridding information

If the gridding is irregular, there are grid cell for which there is no associated header record. For these cells the pointer in the header record number tables are null (equal to -1). The following schematic illustrates the double-pointer mechanism that connects grid cells to data records, through the header records.

If the data is irregularly gridded the header record number tables are encoded in the Grid Values File. The format of the encoded tables is variable, and can be different from file to file. However, the programming interfaces for accessing the header record number are well defined and independent on the encoding. The encoding is variable because the optimal encoding strongly depends on the sparsity of the grid cells within the Grid Coordinate System, and thus depends on the particular way the header records were binned into the Grid Coordinate System. The gridding tables can be stored and retrieved by using the functions sep_get_grid_window and sep_put_grid_window described in the SEPlib man and html pages.

The Grid Format File and the Grid Values File are optional. When no Grid Format File is associated with a data set, the Grid Coordinate System is assumed to be the same as the Header Coordinate System, and the grid coordinates of the header records are assumed to be regular.

Utilities

3-D Prestack Example

The data set is a single sail line belonging to a 3-D marine data set recorded in the North Sea. The data were recorded by shooting from two sources located at the stern of the recording ship into three streamers being pulled behind the ship. There are about 120,000 traces with 500 time samples in the data. The total size of the Data Values File is about 250 Mbytes. Figure 1 shows the source locations, for one trace out of ten in the data set. Figure 2 shows the receiver location for the same subset of traces in Figure 1. The receiver locations are scattered along the cross-line direction (y) because of a fairly strong cable feather, probably caused by ocean currents during acquisition. The corresponding CMP locations are shown in Figure 3. The cable feather caused a noticeable irregularity in the CMP coverage, with cross-lines overlapping in many places. Figure 4 shows the trace offset-azimuth distribution. Each of the six different trends distinguishable at small offsets corresponds to a source-streamer pair.

Figure 1:Source locations of data traces	Figure 2:Receiver locations of data traces
Figure 3:CDP locations of data traces	Figure 4:Offset-azimuth of data traces

Exploring the data

The first step is to sort and bin the trace headers on a regular grid, by using the Sort3d program. We define a three-dimensional grid, with the grid axes being the absolute value of the offset, the in-line midpoint coordinate, and the cross-line midpoint coordinate. Since for 3-D data the source-receiver offset is a vector, we could define azimuth of this vector as an additional grid axes; we leave this possibility as an exercise to the reader. The midpoint distribution is irregular Figure 3), therefore it is likely that more than one trace belong to the same grid cell. If this overlap happens, Sort3d automatically adds an axis (called trace_number_in_bin ) to the grid, making the grid a four-dimensional object. Notice that the sorting and binning is performed on the trace headers and does not require access to the seismic traces. However, as an option, Sort3d can reorder the data themselves after having sorted and binned the headers.

Once the grid has been computed we can extract many interesting subsets of the data by using the windowing program Window3d . This program can extract specified slices from the four-dimensional grid created by Sort3d . For example we can display at the subset of traces that correspond to grid cells with the same offset and cross-line midpoint. Figure 5 show one "common-offset" section. We can see the complex structures below the surface, with plenty of faulting and diffractions. Similarly we can extract a CMP gather at any desired locations, such as the one shown in Figure 6. Because the sorting and the binning has been done once by Sort3d , and the pointers to the data traces corresponding to the grid cells is stored in the Grid Value File, Window3d can extract these subsets very quickly without the need to go through the whole data set, by extracting the desired traces from the Data Value File.

Figure 5:Constant offset and cross-line midpoint section	Figure 6:CDP gather

Analyzing binning parameters

! subroutine that computes the fold from the gridding information of the
subroutine comp_fold(n2_grid,n_vect)

implicit none

integer sep_get_grid_window,srite
integer n2_grid,n_vect,ierr
integer n(2),f(2),j(2)

integer grid_val(n2_grid,n_vect) ! notice automatic allocation
real fold(n_vect) ! notice automatic allocation
n_vect=1
copy_grid: do i_axes=3,num_grid_axes  ! noticed the "named" do loop

 if (sep_get_grid_axis_par('in',i_axes,n_grid,o_grid,d_grid,label_grid) /= 0)  &
  call seperr("Error in sep_get_grid_axis_par \n")

 n_vect=n_vect*n_grid

 if (sep_put_data_axis_par('out',i_axes-2,n_grid,o_grid,d_grid,label_grid) /= 0)
  &
  call seperr("Error in sep_put_data_axis_par \n")
end do copy_grid


n(1)=n2_grid
n(2)=n_vect
f=0 ! notice array syntax for initilization
j=1

if (sep_get_grid_window('in',3,n,n,f,j,grid_val) /= 0) &
  call seperr('error in sep_get_grid_window')

where (grid_val > 0)
   grid_val =1 !There is a trace if the pointer is non-negative
elsewhere
   grid_val =0 !There is NO trace if the pointer is negative
end where

fold=float(sum(grid_val,dim=1)) !notice use of reduction intrinsic SUM

if(srite('out',fold,n_vect*4) /= n_vect*4) call seperr('error in srite')
 
return
end subroutine comp_fold

This subroutine is the main subroutine of a SEPlib3d application program ( Fold3d ). Figure 7 shows the fold values for cross-line of the data set computed using Fold3d .

Figure 7:Fold values for constant cross-line midpoint

Specifications

• data access routines
• header access routines
• grid access routines

Department of Geophysics Stanford University

Modified: 02/18/08, 17:53:04 PST , by altheyab
Page Maintainer: bob `AT' sep.stanford.edu

---