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.
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.
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*...).
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.
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|
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|
! 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 .
|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)|
|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|
Department of Geophysics