Delaytime Solution for Shoulder Line

This example is an introduction to the delaytime package included with BSU. We have a classic reverse profile situation with records k008.seg and k009.seg. We begin with executing bref for a normal refraction survey.


bref 0002 2 30 300 0 0 k008.seg k009.seg


This will restrict offsets to the interval of 30 to 300 meters (hopefully excluding direct arrivals). The files created are

The procedure is then to start a Octave session and execute the program delaytm.m from within the Octave text window. If we do this, we will get a faulty solution (negative delay times which would put the refractor above the ground level). The problem is under-determined due to missing data from the offsets less than 30 meters. We have to edit files G0002 and D0002, adding constraint equations. There are 48 channels in these data, so a “G” matrix less than $2x48$ rows will spell trouble. The same is true for the “D” matrix. In fact, we note that there are only 83 rows, not 96. An additional problem (beyond no picks for less than 30 meter offset) is that the shots are offset from the line, beyond the default distance to constrain the delay times to a geophone location. We can obtain a solution by editing the G0002 and D0002 files. We add constraint equations that

  1. Weight the shot delay time to match that of the closest geophone. Thus, the k008.seg shot will match geophone station 1, and the k009.seg shot will match geophone station 48 (check a header dump).
  2. Weight the geophone stations without picks to match the closest station with a pick. Thus, for shot k008.seg we will need 6 constraints, and for shot k009.seg, we will need 7 constraints.

All together, we require 15 constraints (2 for shots, 13 for receivers). We add the constraints at the bottom of files G0002 and D0002. Included in directory headWave you will find the original and modified (with constraints) needed to obtain a solution. Weighting these constraints with a factor of 9 seems to work well. Thus, the geophone constraints will have a +9 and -9 to form an equation which will make two delaytimes equal. The corresponding “data” will be zero. Here is a partial listing.


{list8}
9  0 -9  0  0  0  0  0  0  0 . . .
0  0  9  0  0  0  0  0 -9  0 . . .
0  0  0  9  0  0  0  0 -9  0 . . .
0  0  0  0  9  0  0  0 -9  0 . . . 
0  0  0  0  0  9  0  0 -9  0 . . . 
0  0  0  0  0  0  9  0 -9  0 . . .
0  0  0  0  0  0  0  9 -9  0 . . .
list8



The first two columns are for the shots, the rest for receivers, up to an offset column. The first row equates the shot 8 delay time with geophone 1 delay time (their weighted by 9 sum equals zero, making them equal). The other rows set each geophone delay time equal to that of station 7. Again, the weighted sum of each delay time with that of station 7 will equal zero, making the delaytimes equal in a least squares sense. The match is not exact, since there are many other rows in the “G” matrix. For each constraint row added to the “G” matrix, there will be a an additional row added to the “D” vector, and the value for the data will be zero (to make the equation an equality statement). See section 6.9.5.1 for details on adding constraints.

To obtain a solution, refractor velocity, shot delay times, and geophone delay time constraints were added and can be compared to the original bref generated matrices. Using the *.mod versions, we obtained a solution shown in Figure 33. For details on running program delaytm.m, see section 6.9.11.

Figure 33: Delay time solution for line along road shoulder. The structure plot has been squished vertically to remove most of the vertical exaggeration in a simple figure.
\includegraphics[scale=.6]{FigureR}