Time-to-depth conversion means that each seismic data point in the time domain will be given a depth coordinate. Each point keeps its XY location. There is no lateral displacement, only a vertical one. Such approach is insufficient in complex domains such as structural plays or salt plays. There, depth-migration and not time-to-depth conversion will likely be applied. This topic isn’t discussed hereafter. Only time-to-depth conversion is. Readers interested in depth-migration can refer for example to Jones, 2010) for more details. For more details about time-to-depth conversion, the reader can refer to (Al-Chalabi, 2014).
Well logs, such as sonic, are used to transfer the wells to the time domain. A sonic log quantifies the reverse of the instantaneous wave velocity of the rocks in the vicinity of the borehole. Converting the wells to the time domain is also the time when the geophysicist must decide which seismic event can be associated with which well top. It guides the seismic interpretation of the seismic cube; that is to say the picking of the horizons and faults from the seismic cube. Details on how to integrate a seismic interpretation in geomodeling are covered in the two next sections. Before doing so though, the seismic interpretation must be converted to the depth domain. That’s where time-to-depth conversion is being used.

While sonic logs are being used to convert the wells from depth to time in great details, sonic is usually not used for converting the seismic data to depth. It can be extremely challenging to extrapolate sonic logs data between the wells. It has the same level of uncertainty than extrapolating facies data or petrophysical data in 3D. Such an approach is sometimes needed though and the topic will be discussed in more detail later in this section.
Instead of defining the time-to-depth conversion from the sonic log, interval velocities or average velocity are used.

An interval velocity is the mean velocity between two horizons at a given XY location. Interval velocities are computed along each well. Figure 1A illustrates the concept with interval velocities computed for the shallow unit between the ground (for onshore seismic) and the first key horizon HrzA, then for the unit A between HrzA and HrzB and lastly for the unit B between HrzB and HrzC. In a given unit, sonic shows that the velocity varies vertically. The interval velocity is an integration of these local vertical variations. Well tops are all we need to compute an interval velocity. The depth of top horizon and of the bottom horizon are known (by definition). As the well has been converted to time, the time two‑way-time (TWT) is known too. The interval velocity is the ratio between the delta-depth and the delta-TWT. If the interval velocity is more or less constant at each well, an average constant interval velocity might be assigned to the whole unit over the lease. This approach is also used when there are too few wells to interpolate the interval velocity on the map in any meaningful way. On the contrary, if we have enough wells and if the interval velocity varies from well to well, interpolation techniques are used to generate an interval velocity map between the well interval velocities. For every XY location, the interval velocity value from the map is then assigned to every point of the seismic cube at this coordinate. Having done this for each geological unit, the seismic cube can be converted to the depth domain with all the seismic interpretation. If only the seismic horizons need to be converted, it is done directly from the interval velocity maps.

An average velocity is the mean velocity not between two horizons, as for the interval velocity, but between the ground and a given horizon (example, Figure 1B). Once the average velocity for a given horizon is known at each well, a map of average velocity is defined, either as a constant everywhere, or using interpolation techniques. The average velocity maps are then used to convert the seismic cube and/or interpretation to the depth domain.
Interval velocities are preferred to average velocities for units with lateral changes of interval velocity (Figure 2). In this example, the two first layers have more or less constant interval velocity of 2,500m/s and 5,000m/s respectively (Figure 2A) while the deepest layer has a sharp lateral change of interval velocity. The layer is a shale unit (3000m/s) truncated by a sand channel (4000m/s). Facies is one of the key factors to control the distribution of velocity in a geological unit. This lateral change of facies has an impact on the geometry of the seismic horizon of HrzC (Figure 2B). Where we are in the sand, the layer appears thinner, in the time domain, than where we are in the shale; while in the depth domain, the thickness changes smoothly between wells 2 and 3. In such a reservoir, it is essential to properly capture the limit between the zone where the wells have an interval velocity of more or less 3000m/s and are in the shale, to the zone where the wells are in the sand and show an interval velocity of 4000m/s. It means tracking the limit sand-shale between the wells and then to interpolate the interval velocities within each facies domain.

All these approaches of computing velocities at each well and then interpolating maps from them can also be done in a geomodeling package, if this is more convenient for the asset team to do so. Geostatistical algorithms, as introduced in the previous papers of this series, are perfect for interpolating the velocity maps. Not only to capture trends in the velocities, but also to generate multiple possible velocity maps, and so capture the velocity uncertainty between the wells.

No matter where these maps are generated, the geomodeler should make sure that these maps do include all the wells needed for the geomodeling workflow, and not only those used by geophysicist. In many projects, some wells might have facies and petrophysical logs, but they might not have a sonic log. Such wells would not be converted to the time domain by the geophysicist. It might be perfectly fine for seismic interpretation: once the time-converted wells have confirmed which seismic event shall be picked, the interpreter can follow these events in the whole cube, even around wells without a sonic log. The geophysicist might have the reflex, or be forced by his software, to create the velocity maps only from the time-converted wells. As a result, the depth-converted horizons, while fitting nicely to the wells with sonic, may not match to the wells without sonic. Such mismatches can be cleaned in the geomodeling workflow, as discussed in the next section, but it might be more elegant to create the velocity maps from all the wells in the first place, as well tops are all that is required to compute interval and average velocities. Sonic is not needed.

While illustrating the concept of lateral change of velocity, Figure 2 was also overly simplistic. In many reservoirs, the heterogeneity is such that facies do change both laterally and vertically, in very complex ways, and difficult to predict from wells. The velocities in such geological units might be better defined by creating geomodeling 3D-grid in the time-domain. A 3D facies model can then be built with geostatistical algorithms, and then the velocity can be modeled by facies. In such reservoirs, it might be necessary to interpolate sonic logs by facies instead of interval velocities, to really capture the heterogeneity. This geomodel will create multiple cubes of velocity for this unit, each one representing a possible distribution of the facies and the velocity in 3D. Overall, geomodeling packages are better equipped than geophysical packages to do such complex time-to-depth conversions.