Getting started with acoustic well log data using the dlisio Python library on the Volve Data Village dataset¶

Erlend Magnus Viggen¹, Erlend Hårstad², Jørgen Kvalsvik²¶

¹ Centre for Innovative Ultrasound Solutions and Dept. of Circulation and Medical Imaging, Norwegian University of Science and Technology, Trondheim, Norway

Introduction¶

This Jupyter Notebook is a companion to the article of the same name, published in the Proceedings of the 43rd Scandinavian Symposium on Physical Acoustics in 2020. While the article provides more background information and a tidier presentation of the results, this notebook shows the code underlying these results.

The notebook uses the dlisio library to investigate data from a sonic and an ultrasonic tool in an integrity well log file from the open Volve Data Village dataset. The file in question is WL_RAW_PROD_AC-AIMG-CCL-GR_2013-06-05_2.DLIS, from well F-11 B. While investigating acoustic data from two specific tools is the main topic of this notebook, other types of data can be similarly investigated using dlisio.

This notebook is published under an MIT license and the newest version was developed using python 3.9.12. All packages used in this notebook and their versions are listed in requirements.txt in the root folder of this repository. Run pip install -r requirements.txt if you wish to install all the correct versions. The newest version of this notebook can always be found on github.

*Privacy note:* This notebook hides well log parameters that contain people's names. This is to avoid their names being tied to the log file by search engines without their explicit consent. Users of the notebook are of course free to uncomment the code lines that hide these names.

Fetch the file¶

The Volve data is made publically available by Equinor through Azure BlobStore. In the next cell we download the dlis file that we intend to work with in this notebook from that BlobStore. In order to do that, we first need to head over to https://data.equinor.com/dataset/Volve to fetch a sas token (our credentials). After logging in with a Microsoft account and accepting the terms and conditions, scroll to the bottom of the page and copy the sas token from the shared access signature URI. Note that the sas token is only the last part of that URI, i.e. everything after the question mark (excluding the question mark itself). Paste it into the sas variable in the cell below and run it.

Load the file¶

Set encodings for dlisio¶

By default a .DLIS-file should only contain strings that can be decoded with 'utf-8', which is the default encoding in Python. However, a lot of files use different encodings for strings. These need special care. Sadly, there is no way for dlisio to guess which encoding to use, simply because multiple encodings might work but yield different results. However, dlisio can be told to use whatever encoding you believe is used in the file with the set_encodings function.

For the file that we are investigating in this notebook, we need to use the latin1 encoding.

Logical files¶

Before starting to work with DLIS and dlisio, there are a couple of concepts you should be familiar with. Firstly, a DLIS-file may contain multiple logical files. In short, this means that there might be multiple files within a .DLIS disk file. In practice, logical files are independent of each other and you can regard them as such. The dlisio documentation explains the definition of a logical file in more detail.

Because of this, the syntax for opening a DLIS file with dlisio can look a bit strange at a first glance. The syntax we use in the cell below extracts the first logical file into f and puts the remaining logical files into f_tail. dlisio's documentation offers more in-detail examples of loading files.

Origins¶

Secondly, within a logical file there are one or more Origin objects. These describe the origin of the file, and contain information about which field and well the data is from. The fact that there might be multiple origins opens up the possiblity of the logical file containing information from multiple wells. In that case, the origin must be checked for every piece of information in the logical file to avoid misinterpretation of the information.

Luckily the more common case is that a .DLIS-file contains one logical file, with one origin. When this is true, we can safely assume that all the information stems from the same well.

Get an overview of the file¶

All dlisio objects have a describe() function that returns a string containing useful overview information about that object. Describing the file gives an overview of how many frames and channels it contains, and which DLIS sets it contains.

We can also run describe() on the origin object for some overall information about the data:

To explore the parameters and channels in the file, we create a helper function that iterates through a sequence of dlisio objects and compiles a pandas dataframe from selected object attributes. We will show how the function is used in the next cell.

Explore parameters¶

DLIS files contain a number of parameters, which dlisio exposes to the user as Parameter objects. These describe parameters used in the acquisition and processing of data. The parameter value(s) may be scalars or an array.

f.parameters gives us a sequence of all the parameters in the DLIS file. We can apply the just-defined summarize helper function to compile a pandas table out of these parameters. dlisio Parameter objects have several attributes, but the ones we will compile here are name, long_name, and values. Furthermore, parameters can have units. While dlisio does not yet have a high-level interface for reading parameter units, we can use a lower-level units interface to fill in the units in the pandas table.

Some of these parameters give a description of the the logged well and the logging run:

The file also contains a series of remarks describing the logging run in the parameters R1 to R17. We can easily retrieve all of them using a regular expression to find all parameters where the name is R followed by one or two digits:

Explore frames¶

The majority of a DLIS file is typically made up of measurement data taken along the well bore, or computed data based on such measurements. This data is stored in channels, which we will get to soon, and channels are organised in frames, which dlisio exposes as Frame objects. All of the channels in one frame are indexed against the same reference channel, which typically specifies the time or depth of each measurement.

We see that all of these frames are indexed by borehole depth. This is the depth measured along the length of the wellbore, also known as measured depth, and should not be confused with true vertical depth. Every frame has an index channel called TDEP, which is stored in units of 0.1 in. We will later have to convert this to metres. Every frame is stored from the bottom of the well to the top. This is because the measurements were made by log tools starting at the bottom of the well and moving up.

Explore channels¶

A channel is a sequence of measured or computed samples that are indexed against some physical quantity, e.g. depth or time, stored in the index channel of the frame that the channel belongs to. The DLIS standard supports multidimensional samples. Each sample can be a scalar or a multidimensional array. dlisio exposes channels as Channel objects.

f.channels gives us a sequence of every channel present in the file. We can use the summarize() helper function again to make a list of all the channels in the file. Out of the attributes of dlisio Channel objects, we will compile name, long_name, units, dimension, and frame:

There are clearly a lot of parameters and channels available in our DLIS file. However, we will soon see how we can find shorter, more managable lists of parameters and channels belonging to a particular tool that we are interested in.

Explore tools¶

DLIS files contain information about which tools were present on the toolstring during the logging run(s) stored in the file. dlisio exposes this information as Tool objects.

Similarly to before, we use f.tools to get a sequence of tools and use summarize() to compile a table out of it:

Investigating the sonic tool¶

The sonic tool's name is "DSLT", which is short for "Digitizing Sonic Logging Tool". Section 15-4.4 of the book Well Cementing from 2006, edited by Erik B. Nelson and Domonique Guillot and published by Schlumberger, gives a good overview of the workings of such tools.

In short, an acoustic transmitter on the tool emits an acoustic pulse that travels along the wellbore. The acoustic pulse reaches two acoustic receivers on the tool, whose distances to the transmitter are 3 ft and 5 ft. The waveforms recorded by the receivers are then analysed to draw out information about the well integrity.

We will get back to the waveforms and what can be drawn from them, but let us first get an overview of the data we have from the sonic tool. Let us look at the overall description of this tool and its data:

Now, let us look at the sonic tool parameters in more detail:

Finally, let us look at the sonic tool channels in more detail:

Investigating sonic waveforms¶

We can see here that we have two channels WF1 and WF2, called "Waveform 1" and "Waveform 2" respectively. Each channel has a number of samples per depth that corresponds to the DWCO (‘Digitizer Word Count’) parameter. We may expect that these channels contain recorded waveforms from the two receivers, but it's hard to say which channel corresponds to which receiver. Let's investigate further.

Both channels are a part of the Frame 20B. This is convenient, as it means that they share the same index. Let us create some convenience functions to get the index and a named channel from a given frame, and use them to get the depth index, WF1, and WF2 as Channel objects:

We can extract all the curves in the Frame as a numpy structured array curves20B, whose field names are the names of the channels in the frame. This lets us look up the curves of any channel in the frame as e.g. curves20B['WF1'].

As a simple example, we can look up the shapes of the curves of the frame's index channel, WF1, and WF2:

The waveform channels' curves contain two-dimensional arrays, e.g. WF1$(i,k)$, where $i$ indexes the depths and $k$ indexes the waveform samples. The actual depth $z_i$ can be found from the curve array of the index channel (in this case called TDEP) as

Next, we create a helper function for plotting two-dimensional arrays as images and use it to plot WF1 and WF2:

This shows us the WF1 and WF2 waveforms recorded by the two receivers. These two channels do not have any units, so it is not yet clear how to convert them to physical units such as millivolts, except that it should involve some scaling factor.

We do not yet know which of these waveforms corresponds to the near and far receiver. Comparing them, we can make a few observations:

• The waveforms arrive earlier in WF2 than in WF1.
• The waveforms are stronger in WF2 than in WF1.
• Some components of the waveforms travel through fast paths and arrive early, while other components travel through slower paths and arrive later. The spread between the components is larger in WF1 than in WF2, indicating that WF1 has been measured further away.

These observations all tell us that WF1 represents the far transducer at 5 ft, while WF2 represents the near transducer at 3 ft.

Finding the time axis of the sonic waveforms¶

While this shows us how to find the waveforms at every depth, we don't yet know what sampling rate they were measured at. Thus, we have no time axis for the waveforms. To solve this, let's look at time-related channels and parameters.

According to section Section 15-4.4.2.5 of Well Cementing, the transit time represents the elapsed time between the transmitter firing a pulse and the first arrival of the pulse in the receiver. Among the sonic tool's channels, we have two transit time channels TT1 and TT2 in frame 20B, which we can assume correspond to WF1 and WF2 respectively.

Let's assume that both waveforms start at $t=0$, when the transmitter fires the pulse. (This may also be what the DDEL ("Digitizing Delay") parameter tells us with its value of 0.) The DSIN ("Digitizer Sample Interval") parameter may be telling us that the sampling period is 10 µs, corresponding to a sampling rate of 100 kHz. To check this, we can assume these values to be true and see if we get a good fit between the transit times and the first arrivals in the waveforms.

To check whether our assumed sampling rate is correct, we can plot the travel time over the waveforms.

A waveform sampling rate of 100 kHz thus gives us an excellent correspondence between the travel time channels and the first arrivals in the waveforms. We have also validated our assumption that the receivers start recording at $t=0$, i.e. the pulse emission time.

We can also compare individual waveforms from WF1 and WF2 at the same depth: