10 Additional Information

Contents
Extending the Wire Set to Match the Checkshot Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Depth to Time Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Notes on Drift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Synthetics for a Vertical Well . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
TVD Synthetics for a Deviated Well . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Sources of Errors in Well to Seismic Ties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-1

Extending the Wire Set to Match the Checkshot Set

When the module joins the OWTIME log in the checkshot set to the depth sonic log in the wire set, any
checkshots outside the depth range of the wire sonic will be discarded. For example, suppose the wire.dt
log extends from 1000 ft to 5000 ft. Any checkshot time with a depth above 1000 ft will not get passed to the
Welltie module, nor will any checkshot time greater than 5000 ft.
The module does not automatically interpolate a checkshot time at the top-most and bottom-most depths of
the sonicthe user must do this manually and edit the checkshot set to add these values.
In addition, sometimes it is preferable to extend the computed TWTIME log from the seismic reference
datum at the surface (or wherever zero time is). If the user attempts to edit the checkshot set to insert a
new value, such as setting depth 100 ft to zero time, this is likely to be outside the wire sonic depth range
and is discarded during the join.
In either case, it is possible to extend the depth range of the wire sonic log so that the join does not discard
checkshots. The steps below will allow users to extend the wire set to the surface:
1. Select General > Log Copy > Log Duplicate to extend the wire set to any depth range:
set the Output Set name (such as WIRE_EXT) to denote an extended wire set;
enter a REFERENCE_TOP value at least to the first checkshot set depth value;
enter a REFERENCE_BOTTOM value to also extend to the last checkshot depth;
set the REFERENCE log to wire.depth;
.set LOG_IN to all the wire set logs, or at least DT and RHOB. If value entered is "ALL" then
all logs in well's Input Set (excluding the reference log) are processed;
Click Start to create a new Reference set and the new extended set (in this example,
WIRE_EXT);
copy any other references, such TVD, from the old Ref set to the new Reference set;
delete the old Ref set.
2. Save the well.
3. Run Geophysics > Utilities > Log Edit > Fill Missings on page 1-19 on the new DT log and
save the well again.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-2

Depth to Time Conversion

To create a synthetic seismic trace from a depth sonic and density log, the user must convert the depth logs
into the time domain, and then compute and filter the synthetic. You may want to reverse these two steps,
but the implicit problems are basically the same. Use the following basic steps to perform the depth to time
conversion:
1. Run Geophysics > Utilities > Log Edit > Fill Missings on page 1-19 to remove missings
from the input sonic and density logs.
2. Run Geophysics > Welltie-Make TWTime(z) > Adjusted Sonic on page 3-11 to derive the
two-way time log in depth, reconciling differences between the integrated sonic times and the
one-way checkshot times.
3. Run General > Sampling > Interpolate on page 1-24 using TWTIME as the new reference
to convert the depth sonic and density logs to linear time at a very fine sampling rate, such as
0.1 msec.
4. Run General > Sampling > Resample on page 1-42 on the 0.1 msec time data, applying an
anti-alias filter to resample back to the sample rate of the seismic data, 1 msec to 4 msec.
Following this, the time sonic and density logs are used to compute a time synthetic trace as follows:
1. Run Geophysics > Utilities > Reflectivity on page 9-25 using the time sonic and density logs
to compute un-bandpassed reflectivity.
2. Run Geophysics >Utilities > Filter on page 2-1 to generate a filter wavelet at the time
sample rate of the reflectivity trace.
3. Run Geophysics > Utilities > Log Operator > Convolve on page 1-11 to convolve one or
more wavelets with the time reflectivity.
Geophysical processors have discovered that it is generally impossible to derive the same synthetic seismic
traces using two different synthetic packages. The primary reason for these difficulties is due to the very
high frequency nature of the reflectivity spike log and its inherent dependency on the basic time conversion
algorithm being used.
Each synthetic package has some method of time conversion that can vary considerably from vendor to
vendor. While the algorithms used to calculate filtered synthetics from the time logs are generally much the
same between synthetic applications, the algorithms used to perform the depth-to-time conversion are not.
The method Geolog6 uses is described in detail below.
Welltie is the module used in Geolog to compute the two-way time curve. The user has the option to include
checkshots (one-way time depth pairs) to help resolve differences between times derived directly from the
sonic log and the seismic. Given a time curve from integrating the sonic log, Welltie calculates the difference
between integration time and checkshot time, defined as:
Drift = Tint - Tcks
where
Tcks is the one-way checkshot time, and
Tint is the one-way sonic integration time.
Welltie then displays the sonic log, the drift log, and the interval velocities over each checkshot derived from
the checkshots and from the sonic log. The user may then edit the checkshot times or the drift log.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-3

The edit process should generally be used to correct checkshot times known to be unreliable or considered
to be erroneous. Most users expect the drift from the integrated sonic times and the checkshot times to
follow a general trend with depth. Many programs try to smooth variations in drift by the application of a
least-squares fit of a small degree polynomial to the drift points. The difficulty with this procedure is that
many times the drift has a valid geologic "kink" due to physically distinct velocities between clastics and
carbonates or geo-pressured sections in the earth. A simple linear or quadratic polynomial will not follow
such trends well. If geophysicists want the best time conversion, then they must do the interpretation
themselves, which Geolog allows.
Geolog can generate a continuous drift log at the same sampling rate as the sonic. Geolog then computes
an adjusted or compensated sonic log which, if integrated, will return a zero drift when compared with the
input edited checkshot times. Various methods are used to distribute drift errors across checkshot intervals
to produce the compensated sonic log. These methods differ greatly between synthetics programs. Geolog
provides several methods but the Adjusted Sonic will be described here.
The Adjusted Sonic on page 3-11 available in Geolog computes a compensated sonic log basically using a
spline fit of the drift to smoothly transition across checkshot intervals and yet honor each checkshot. Given
drift as a smoothly varying curve at the same sampling as the sonic log, then two-way time is simply derived
as:
Twtime = Tintg - Drift
and the adjusted sonic is given by
DT_ADJ = Derivative (Twtime)
where:
Tintg is the interval of integrated sonic time
Derivative indicates derivative operations

NOTE Because the drift log is a smooth spline fit to the drift points, it has a continuous derivative.
Other vendors who use a linear, piecewise fit to the drift points will have discontinuities at
each checkshot which, if not artificially processed, will generate erroneous spikes in the
reflectivity.
Geolog users may overplot the original and the adjusted sonic logs along with the drift in depth to view how
the compensation was applied to generate the adjusted sonic log. To demonstrate this, edit one checkshot
so that the compensation is quite different from the general trend. The overplot will indicate that the
compensation is smoothly distributed over the checkshot intervals preceding and following the edited
checkshot. Given the compensated or adjusted sonic, Geolog gives users the option of using it or the original
sonic to compute reflectivity in Synthetic.
The use of Interpolate and Resample, which operate strictly on the TWTIME log, not the adjusted sonic log,
allow users to control the details of the application of an anti-alias filter. Anti-aliasing is required to
effectively compress many depth samples into a single time sample. Without anti-aliasing, the simple
application of a constant depth shift would result in a different time sonic and density log, and a different
reflectivity lognot just a simple time shift in the reflectivity.
Some geophysical programs apply a uniform smoothing to the depth logs to accomplish the high-frequency
attenuation necessary for anti-aliasing. Others will block the depth logs, smoothing over each block, to
perform anti-aliasing. Geolog's method is to retain the lithology dependencies that the seismic is traveling
through and yet not over smooth as interval velocities change with depth.
For example, assume that we desire a synthetic with a 4 msec sampling rate. If the interval velocity is
10,000 ft/sec, then each two-way time sample will span a depth range of 20 feet or 40 samples if the depth
data is at .5 feet. Moreover, if the interval velocity increases to 20,000 ft/sec, then each time sample will

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-4

span a depth range of 40 feet or 80 depth samples. It should be clear that a constant smoothing which works
for 20 feet would not be adequate smoothing for 40 feet data compression and vice versa.
The method employed in Geolog is to time convert to a very fine sampling, such as 0.1 msec, followed by a
resampling to the desired sample rate. The first step to go to the fine sampling rate retains much of the
character of the depth logs as they are converted to time and allows the user to apply a smoothing or antialias filter which is linear in time and non-linear in depth. Resample allows the user to specify the length
of the smoothing filter in terms of the very fine 0.1 msec time samples. This is obviously preferable to antialias filtering which is uniform in the depth domain or those methods that artificially block the logs in
depth.
Geolog separates the depth to time conversion from the reflectivity calculation, giving users control over all
details of synthetic generation. These operations have been consolidated into a single script, Synthetic on
page 4-1, which collects parameters, performs the steps described above to generate the synthetic, and then
generates a display.
Geolog supplies a proven technique for performing depth to time conversion and generating synthetic
seismic traces which can be automated or configured to match empirical information for a known set of
parameters. If a more elaborate enhancement in the processing is required, any of the scripts used to drive
the process can be altered to add a custom algorithm, additional steps, or match a proprietary methodology
or preferred display.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-5

Notes on Drift
Drift is a measure of the difference in time derived from integrating the sonic from the time derived only
from the checkshot times. Usually, the checkshot times are considered more reliable than times derived
from the integration of the sonic. In Welltie, drift is defined as:
Drift = Tintg - Tcks
where:
Tintg is time from sonic integration, and
Tck is time from the checkshots
Hence, a negative drift value indicates that the sonic integration time was less than the equivalent
checkshot time.
Although the Checkshot on page 3-8 methods compute drift, often it is desirable to use drift as input and
to be able to edit or smooth drift (as with a low order polynomial regression) and then use the edited drift
to estimate the two-way time reference, and possibly recompute the checkshot one-way times from the
edited drift log.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-6

Synthetics for a Vertical Well

The basic steps to generate a synthetic for a normal vertical well or a deviated well along the borehole path
in measured depth (MD) are given below.
1. If the sonic has missings, run Geophysics > Utilities > Log Edit > Fill Missings on page 119.
2. Run Geophysics > Welltie-Make TWTime(z) to derive a depth-two-way-time relationship:
if there are no checkshots, use the Tie Point on page 3-3 (or Replacement Velocity) to
integrate the sonic;
if there are checkshots (one-way time, measured depth pairs), then checkshot.depth is
not relative to the sonic (KB elevation); use Geophysics > Utilities > Evaluate on page 118 to apply a depth shift to the checkshot depth log.

NOTE Checkshot logs MUST have an Interpolation style of POINT! To verify or change the
Interpolation style, in Text view (select Well > View > New > Text) and:

select the CHECKSHOT set (if the velocity survey set is not called CHECKSHOT, then
you must copy or rename it);

click on the Log Headers tab to view the logs;

scroll right and, if required, toggle the INTERPOLATION column value to POINT
Geolog will automatically change all logs in the set, as they must have the same
interpolation style.

select Well > Save.

EITHER, select Geophysics > Welltie-Make TWTime(z) > Checkshot and verify that
checkshots do a reasonable job of modeling the sonic by comparing drift with an overplot of
the input sonic and the output adjusted sonic. If required, see Examples of Generating a
Synthetic on page 4-8.
If you wish to edit checkshot times or drift:

select Well > View > New > Text to edit checkshot.time values (difficult), or delete
clearly bad checkshot depth frames, OR

use the Geophysics > Welltie-Make TWTime(z) > Calibrated Sonic on page 3-14 to
get a drift log and use Text view to edit drift values in the checkshot set (not easy in text
mode), or select the drift log and, from the Well menu, Tools > Curve Insert on page 312 to edit interactively, OR

use the Geophysics > Welltie-Make TWTime(z) > Calibrated Sonic on page 3-14 to
fit drift with a smooth low order polynomial, OR

use General > Statistics > Simple Regression on page 1-47 and General >
Evaluate on page 1-18 to create a new edited drift, drift_edit, from a regression on the
drift;

finally, select Geophysics > Welltie-Make TWTime(z) > Calibrated Sonic on

page 3-14 to input the edited drift and output a new adjusted sonic and TWTIME log.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-7

 OR, use the Geophysics > Welltie-Make TWTime(z) > Adjusted Sonic on page 3-11 to
apply drift error to the input sonic.
3. Run Geophysics > Synthetic on page 4-1 to generate and display the synthetic (if sonic and
density logs have missing values, Synthetic will auto-fill-missing):
enter the depth sonic and density logs, plus a shear-sonic if AVO is to be done later (the
sonic may be the adjusted sonic from Welltie);
enter the TWTIME and SRD_DEPTH logs generated by Welltie;
specify one or more synthetic types to generate;
specify one or more filter specs to apply to each synthetic type along with the desired filter
length (DC will be removed from non-reflectivity synthetics prior to filtering). Some
examples of supplied filters are listed belowsee the Geolog6 specs directory for the full
list.

Butterworth Filter:

bw1040

Ormsby Filter:

or1040

or1050

or1060

Ricker Filter:

rick20

rick30

rick40

Trapezoidal (Turning) Filter:

tp1040

tp1050

tp1060

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

bw1050

bw1060

Additional Information 10-8

TVD Synthetics for a Deviated Well

For synthetics in measured-depth space (i.e., along the borehole path), use the procedure described in
"Synthetics for a Vertical Well" on page 10-7 with everything in measured depth references.
It is simple to compute a synthetic for a deviated well in the true vertical depth (TVD) domain. It is not
necessary to convert the wire measured depth sonic log into a linear TVD set, or convert measured depth
checkshot times into a linear TVD set. Because domain translation can be done on both the reading and
writing of log data, checkshots and logs are left in measured depth and Datum on page 2-5 vertical
reference is changed to TVD (assuming TVD has already been computed and exists in the Reference set).
For synthetics in TVD space (i.e., vertical borehole equivalent), the procedure is basically identical to the
procedure for MD except the Datum on page 2-5 vertical reference is set to TVD, not Depth.

NOTE This assumes checkshot depths are entered as measured depths, not as TVD depths. When
the checkshot OWTIME log is joined with the wire.dt log, both logs must be in the same
domain. If checkshot.depth is TVD, then wire.dt must be converted to TVD domain by
running General > Sampling > Interpolate on page 1-24 and creating a new set.
Geolog assumes the checkshot depth log datum is KB, the same as the wireline sonic log.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-9

Sources of Errors in Well to Seismic Ties

Geophysical well log processors should be aware of the following items when creating synthetics and
attempting to tie the synthetic to the seismic. There can be problems with both the well and seismic data.
A poor quality tie needs to be resolved, but keep an open mind when searching for the problem.

Sources of well log problems

Poor quality logs (rugged hole).

No checkshot survey.

Well log synthetics have a different wavelet from the seismic.

Edit problems exist with sonic and density logs, washouts.

Well drilled into an anomaly.

Well is far from the seismic line tie.

Well is projected into the wrong position on the seismic line.

Sources of seismic problems

Data acquisition

Noise in recording (60 Hz, shot generated, etc.).

Marine guns not all firing or not in phase.

Marine cable ghost problems.

Poor quality land crews.

Bad vibroseis sweep correlation.

Seismic processing

Bad stacking velocities.

Bad statics.

Incorrect de-absorption, lateral variation.

Multiples left in stack.

Not deconvolved well, residual phase errors.

Migration noise, aliasing.

Noise from out of the seismic plane.

Ray paths not symmetric (permafrost).

Marine gun or cable depth are incorrect.

Bad depulsing filter, laterally changing wavelet.

Bad dereverberation; reverbs not stationary.

Navigation errors.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-10

Bad idents (incorrect water-bottom).

Earth is not white.

Tune-up decon did not do its job.

Amplitude vs. offset errors on stack.

Norm or gain control problems.

Low frequency noise.

Data reduced to too large a time sampling.

Not enough statistics for a good decon.

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-11

Index
C
checkshots
avoid discarding 2
outside depth range 2
set Interpolation style 7

D
data
well/seismic errors in 10
depth
to time conversion, basic steps 3
deviated wells
basics steps to generate synthetic for 7
discarded checkshots 2
drift
definition of in Welltie 6
edit or smooth 6
points and discontinuities 4
valid geologic "kinks" 4

E
errors in well to seismic ties 10
extend depth range of wire sonic log 2

P
problems
with well/seismic data 10

S
synthetic
deviated well, basics steps to generate synthetic for 7
vertical well, basic steps to generate synthetic for 7

V
vertical
well, basic steps to generate synthetic for 7

W
welltie
definition of drift in 6
edit Body smooth drift 6
wire set, extend depth range 2

Paradigm Rock & Fluid Canvas 2009 | Epos 4.0

Additional Information 10-12