SEP Home

About SEP
TeX Software
Old Versions
SEPlib Overview
Internal Info



The SEPlib software package, has proven to be a very productive tool for seismic research and processing. However, its usefulness is fundamentally limited to processing regularly sampled data. This limitation is too restrictive when tackling problems in 3-D seismic and problems that involve geophysical data other than seismic. Therefore, we designed and implemented a generalization of SEPlib to make it capable of handling irregularly sampled data (from now on we will dub this new version SEPlib3d, while the old version will be referred to as just SEPlib). In SEPlib, few parameters defined in the history file are sufficient to describe the data geometry, since it is assumed to be regular. In SEPlib3d, to describe the irregular data geometry, we associate each seismic trace with a trace header, as is done in the SEGY data format, and in its many derivatives. However, to enable users and programmers to deal with irregularly sampled data with the same simplicity and efficiency that is characteristic of SEPlib, SEPlib3d introduces the following two principles:

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

This section describes the data format of a SEPlib3d data set. A SEPlib3d data set is defined as the collection of all the files (ASCII and binary) that contain the information relevant to the Geophysical data set.

Structure of a SEPlib3d data set

A "complete" SEPlib3d data set is made of 6 files, three ASCII files and three binary files. With the exception of the History File , the existence of all the other files is optional. The six files are connected to each other through pointers contained in the ASCII files. These pointers can be either simple UNIX file paths or more general URLs (the URL option is not implemented yet!). The path to the Header Format File (HFF) is specified by the value of the hff parameter in the History File. The path to the Grid Format File (GFF) is specified by the value of the gff parameter in the History File. Following is a brief ``graphical'' description of the connectivity among the 6 files, with the arrows representing the ASCII pointers.

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 History File contains the usual SEPlib parameters ni, oi, di, labeli (where i=[1,2,3,...]) describing the Data Coordinate System. The length of the axes in the Data Coordinate System must be constant and is given by the values of the respective ni parameter. The number of data values in a data record is given by n1 and the the number of data records is equal to the product (n2*...*ni*...).

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

In general, the order and number of the data records stored in the Data Values File may be different than the order and number of the header records stored in the Header Values File. This happens, for example, if the Header Values File has been reshuffled (e.g. sorted or transposed) while the Data Values File was left untouched. Whether the data and header records are in the same order is indicated by the value of the integer parameter same_record_number in the History File. The value of same_record_number is equal to 1 if the records are in the same order, and equal to 0 if they are not. If same_record_number is missing from the History File it is defaulted to 1. When the data and header records are in the same order (same_record_number=1), the association between header records and data records is given by the positions of the records in the respective binary files, and the Data Coordinate System coincides with the the Header Coordinate System. If data and header records are in different order the association between data records and header records is assured by the reserved header key data_record_number, that contains the data record number of the associated data record. The value of the data record number is defined as equal to the position of the data record in the Data Values File.

Gridding information

The Grid Format File and the associated Grid Values File define the Grid Coordinate System and they contain the information about coordinates of each header records in the Grid Coordinate System. The Grid Coordinate System is a regularly sampled coordinate system defined by the the parameters ni_grid, oi_grid, di_grid, labeli_grid (where i=[1,2,3,...]) in the conventional SEPlib style. The mapping between the grid cells and the header record can be either regular or irregular. A gridding is regular if for each grid cell in the Grid Coordinate System exists a header record, and vice versa, for each header record exists a grid cell. The grid cells and the header records are connects by tables of pointers to header records. These tables have an entry for each grid cell, containing the header record number of the corresponding header record. The value of the header record number is equal to the position of the corresponding header record in the Header Values File. Notice that if same_record_number=0 the header record numbers are different from the data record numbers of the associated data record.

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.


To see the current list of available utilities click here

3-D Prestack Example

The following example shows how to use SEPlib3d programs and libraries to analyze and manipulate 3-D prestack seismic data sets.

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

At the start the data set is in SEPlib3D ungridded format. The seismic traces and the trace headers are in arbitrary order. Our goal is to analyze the information on the geometry of the data and to extract a meaningful subset of the data to be displayed. However, since the data set is relatively bulky (250 Mbytes), we want to explore it without replicating the seismic data themselves; further we want to avoid to perform the sorting and binning operation every time we choose to display a different subset.

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

The choice of the binning parameters for a data set depend on many factors, such as the acquisition geometry and the planned subsequent processing flow. Using Sort3d we can study the effects of choosing different binning parameters in order to select optimal ones. For example, we can vary the bin width along the midpoint axes to determine the trade-off between bin resolution and uniformity in the offset and azimuth coverage within the bins. Sort3d is an efficient tool for this study, because it bins the trace headers and creates the gridding information, without accessing the bulky Data Values File. To assess the quality of a set of binning parameters we can display subsets of the data, as described in the previous section. We can also examine the distribution of the trace headers on the grid by measuring the fold within each of the grid cells. A simple way of measuring the fold is to count the number of elements along the trace_number_in_bin axis created by Sort3d when encountering multiple traces belonging to a single grid cell. The following subroutine performs this task, and outputs the results into a SEPlib3d data set, which can then be displayed and examined. Notice that the subroutine is coded in Fortran 90, and uses a few of the powerful features of the language (e.g. automatic allocation of arrays, reduction intrinsics) that enables the writing of simple and compact code.

! 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
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")


 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

f=0 ! notice array syntax for initilization

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
   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')
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


Numerous subroutines have been added to make navigation SEPlib3D datasets easier. These routines can be broken into three general categories In addition to make writing seismic processing utilities easier, and making conversions from other data formats more straightforward we have defined a standard set of header key conventions:
Name type Description
sx integer Source x location
gx integer Receiver x location
sy integer Source y location
gy integer Receiver y location
trid integer Trace Status( 1=exists 0=padded)
offset integer Offset
cdp integer CDP ensemble number
cdpi integer Trace number within ensemble
data_record_number integer Location of trace
s_x float Source x location
g_x float Receiver x location
s_y float Source y location
g_y float Receiver y location
cmp_x float CDP x location
cmp_y float CDP y location
offset_x float Offset in x direction
offset_y float Offset in y direction
azimuth float Source-receiver azimuth

© 2008 , Stanford Exploration Project
Department of Geophysics
Stanford University

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