where the offset record had cdp numbers ranging from 1 to 60. The time-interval velocity function is input in the manner shown above, i.e., as a series of comma delimited numbers enclosed by double quotes. It is input as a time function and converted to depth internally. We copied this mode of input of simple time functions from the CWP folks. Future versions of this code will support flat file input of time-velocity. The results are shown in Figure 3.
There is a stretch mute parameter called -smute which controls the amount of stretch muting to apply to the nmo corrcted data. This in effect defines the minimum time of interest. The default smute parameter is 1.0. Running the same dmovz commend line above but adding -smute2.0 results in Figure 4. Thus increasing this parameter reduces the effects of stretch muting.
Of course the choice of velocities was entirely arbitrary and served only to illustrate the cleanliness of the dmovz operator which is comparable to that of dmofast.
Real Example
Figure 7 shows a midrange offset from a Gulf of Suez line. Checking the presort table used in the sorting to common offsets the top part of the table looks like Figure 5.The first line is a flag used by the sort programs; the second line is the number of live traces in the entire data set; the third line are read in pairs (i.e., the number of group gathers and the number of traces per gather; the number of shots and the number of traces per shot; the number of CDPs and the number of traces per CDP; ...); the fourth line is used internally by the sort programs. The first three numbers in the fifth (through the last) line are the primary sort indexes in the order group, shot, CDP. From this line we find the first depth point in the data set is 562.
Similarly looking at the bottom of the sort table (Figure 6) we see the last depth point for this data set is 979. The V(z) dmo command line is
where the minimum and maximum cdp numbers were obtained from the presort table. If you don't get these correct then you either end up truncating some output offsets (because the range of cdps fell outside the command line range causing those traces to be not processed), or using more machine memory than necessary (e.g., we could have used 1 - 1000 for cdp numbers above and the offset would have been processed ok but we would have used almost double the required memory).
The speed factor governs the density of ray coverage, i.e., the larger the speed factor the less dense is the coverage and hence the faster the code runs. The default value is 1.0. Increasing this to 2.0 causes the code to run at about double the speed (i.e., about the speed of dmofast) and in most cases the ray coverage should be dense enough to avoid aliasing problems.
The output is shown in Figure 5. The comparable run for dmofast is
The results are comparable in quality; only by animation between the two outputs can we see differences. These differences tend to be more noticeable of course where structure is more steeply dipping and when the input offset is larger.
dmovz also represents the first attempt to import CWP consortium software into USP.dmovz -N
x.1427 -O vzx.1427 -speed2.0stretch -N x.1427 -tmin100 | dmofast -dx25 | stretch -O fastx.1427 -tmin100 -R
Conclusions
dmovz is a new and potentially useful tool in the USP toolki. Given run times that are less than double dmofast (default speed and smute parameters) along with a comparably clean operator it seems to be a viable alternative to dmofast with little reason not to use it. In most cases using a -speed2.0 (instead of 1.0) will produce dmo results that are hardly degraded from the default case but should make dmovz run about the same speed as dmofast. The capability of handling depth variable velocities has great potential in a number of exploration areas.
Return to the USP Home Page
