Log Ties Seismic to 'Ground Truth'

Seismic to Well Ties with Problematic Sonic Logs — Part I

One of the best ways to tie seismic data back to a "ground truth" is through comparison with a sonic log. This comparison is the link between seismic travel time and depth from the well log.

Although this link may seem obvious, there are influences in both data types that may make the tie difficult to make.

This first part of a two-part discussion serves as a guide for the geologist or geophysicist to use when addressing issues with a problematic well to seismic tie in compacted rock environments.

Overview

Let's briefly examine the differences in the way seismic data and sonic logs measure "the same thing."

First, seismic velocities are deduced statistically to provide the best stack of the reflectors in the data. Stacking is done to collapse a volume of measurements into a single vertical reflectivity profile. This may involve the sampling of hundreds of thousands of cubic feet of rock for any one stacked trace.

Due to the large amount of data required to produce any single seismic trace, the statistics are quite robust.

A sonic log, as opposed to seismic, measures velocity more directly. The actual borehole measurement made is interval transit time (reciprocal velocity). All sonic log measurement methods sample a volume very near the well bore, over a short vertical interval and amount to sampling perhaps a few thousand cubic feet of rock for an entire well.

Image Caption

Figure 3
Relationship between interval transit time and deep conductivity in an invaded shale interval. Note that the data are mirrored for visual clarity. This relationship is used to assess the magnitude of the alteration on apparent sonic log interval transit time.

Please log in to read the full article

One of the best ways to tie seismic data back to a "ground truth" is through comparison with a sonic log. This comparison is the link between seismic travel time and depth from the well log.

Although this link may seem obvious, there are influences in both data types that may make the tie difficult to make.

This first part of a two-part discussion serves as a guide for the geologist or geophysicist to use when addressing issues with a problematic well to seismic tie in compacted rock environments.

Overview

Let's briefly examine the differences in the way seismic data and sonic logs measure "the same thing."

First, seismic velocities are deduced statistically to provide the best stack of the reflectors in the data. Stacking is done to collapse a volume of measurements into a single vertical reflectivity profile. This may involve the sampling of hundreds of thousands of cubic feet of rock for any one stacked trace.

Due to the large amount of data required to produce any single seismic trace, the statistics are quite robust.

A sonic log, as opposed to seismic, measures velocity more directly. The actual borehole measurement made is interval transit time (reciprocal velocity). All sonic log measurement methods sample a volume very near the well bore, over a short vertical interval and amount to sampling perhaps a few thousand cubic feet of rock for an entire well.

Assuming that the well bore is in good condition and that there are no other known problems with the logging environment, the sonic tool is capable of recording a very accurate interval transit time profile with depth.

Clearly, each of these measurement techniques has sampled very different volumes of rock in order to determine velocity and reflectivity at the same physical location. Therefore, we should not necessarily expect there to be a 1:1 correspondence between all reflectors seen in these two data sets.

Because the well to seismic ties are done mostly after final seismic processing, we will assume that the seismic data are of high quality with no significant AVO effects, and that the velocity profile associated with each trace cannot easily be improved. However, there are several items that need to be addressed with the sonic log velocity profile before we can expect a good tie.

What we do not want to do is to stretch and squeeze the synthetic seismogram to force a match with the seismic, as this will litter the sonic log with unreasonable velocity artifacts.

Instead, we need to deterministically edit and calibrate the sonic log, by comparing the sonic log to other wireline data as well as the seismic data.

Sonic Log Problems

It is important to note that using a sonic log to tie to the seismic data is a very sensitive numerical operation.

Because we wish to know the cumulative time from the surface down to any reflector, we need to sum the sonic log in time. By summing, we greatly exaggerate any systematic problems with the sonic log.

With the exception of noise spikes, all of the problems with sonic log data discussed below make the transit time too slow. When combined and summed, these errors can render a sonic log useless.

Raw sonic log problems include:

  • Cycle skips and noise.
  • Short logging runs, or gaps in sonic log coverage.
  • Relative pressure differences between the drilling fluid and the confining stress of the rocks around the wellbore.
  • Shale alteration (principally clay hydration from the drilling fluid).

Specifics

First, in order to be useful, a sonic log must represent actual rock velocities. Spike noise and cycle skips do not represent true rock measurements, and therefore must be removed from the sonic log. Spike noise can be easily removed by "de-spiking."

Cycle skips occur when the sonic tool records an arrival that is not correct (typically one "cycle" in the wave train late). The most common cause of cycle skipping is badly washed out zones. When they represent a significant problem, an intelligent data replacement scheme is required.

Figure 1 illustrates a sonic log where the shales are badly washed out, causing frequent cycle skips and some spike noise.

Gaps in sonic log coverage need to be handled smoothly. Often, there are some log data in this gap, just not sonic data. If we can model a pseudo sonic from another curve and then replace the missing sonic data, we will have a well-behaved synthetic seismogram.

If we must model large vertical intervals without real sonic data, we also need to be able to accurately estimate the low frequency component (burial trend) of the earth's velocity profile.

Figure 2 compares actual raw sonic data with a pseudo sonic modeled from the deep resistivity data in an interval where the borehole conditions are not conducive to recording a good sonic log. This pseudo sonic can now be used to replace bad sonic log data or to fill in gaps in sonic coverage where resistivity data exist.

Shale alteration is a problem where the in-situ shales are desiccated. During the process of drilling, these dry shales are brought into contact with the drilling fluid, which can cause swelling and fracturing of the shales, as well as chemical alteration of the constituent clays.

Figure 3 shows the relationship between interval transit time and deep conductivity. This parabolic trend is used to estimate the magnitude of shale alteration.

Relative pressure differences between the drilling fluid and the confining stress of the rocks around the wellbore will have an effect on the sonic log. Since different logging runs typically use different mud systems, separate sonic log runs will likely need unique velocity calibrations to match the seismic data.

Figure 4 illustrates the difference in the corrections required for different logging runs.

Conclusions

If some or all of the problems described above are present in a well, the likelihood of achieving a quality tie to the seismic data is slim. However, if these issues are addressed in a deterministic way and calibrated to the seismic data, high quality informative ties can be made.

High quality ties can be used for many purposes, including phase determination, relative wavelet extractions, seismic inversions, effective stress calculations, etc.

Next month we'll address solutions to these common sonic log problems with real life data comparing synthetic seismograms from a raw sonic log that exhibits all of the problems listed above to the same log after all of the problems have been corrected.

You may also be interested in ...