Contents 1 Introduction 1.1 Acknowledgements 1.2 Use of Diagrams in Other Places 2 Business Process Overview 2.1 Acquisition Methods 2.2 Post Well-Site Acquisition 2.3 Definitions 2.3.1 Job 2.3.2 Run 2.3.3 Trip 2.3.4 Pass 2.3.5 Log 2.3.6 File 2.3.7 Parameter 2.3.8 Frame 2.3.9 Curve 2.4 Use Cases 2.4.1 1. Digital Well Log Data (DLIS, LIS, BIT, LAS) Archival. 2.4.2 2. Programmatically generated Log Data. 2.4.3 3. Well Log Image Archival. 2.4.4 4. Digitized Log Data. 2.5 Digital Well Log Data 2.5.1 LIS 2.5.2 DLIS 2.5.3 BIT 2.5.4 LAS 2.5.5 WellLogML 2.6 Programmatically Generated Log Data 2.7 Well Log Image Data 2.8 Digitized Log Data 2.8.1 Header Entry 2.8.2 Scanning the Log 2.8.3 Grid Detection 2.8.4 Curve Vectorization 3 References

Introduction

The first well log was probably acquired by Professor James D. Forbes from the Edinburgh Observatory, when, from 1837 to 1842, he lowered temperature sensors into three shafts in order to record temperature variations with depth and time. This data was later used by physicist Lord Kelvin in calculating the age of the earth.

During the early days of commercial drilling and well logging the only subsurface information recorded was gathered by looking at the sample cuttings brought to the surface. Additional information was recorded such as the rate of penetration, drilling breaks and any events that were relevant. Now the term “Log” is used to describe any data recorded in a well. This data is recorded digitally and presented on a “log” and displayed as a function of depth or time. This data is recorded primarily to determine if a particular formation contains commercial quantities of hydrocarbons. The measurement types have grown significantly over the last decade from basic sonic, resistivity and porosity measurements to now include more sophisticated measurements such as magnetic resonance to help better evaluate the pore space and borehole imaging to help to better understand the structure of the reservoir. Basic formation pressure test measurements have improved and now provide the ability to perform real-time fluid analysis downhole. Uncontaminated samples are taken at in-situ reservoir conditions and returned to surface for additional evaluation.

Acknowledgements

The PPDM Association would like to express its appreciation to IHS Energy and Oilware Inc for their kind permission to use the illustrations contained in this document.

Use of Diagrams in Other Places

While PPDM members may use these diagrams, you are asked to include acknowledgements to IHS and the PPDM Association when reproducing this material. Contact Zane Reynolds (Zane.Reynolds@ihs.com) for more information.

Business Process Overview

Acquisition Methods

There are three methods of acquiring log data:

• Mud Logging
• Wireline Logging
• Measurement While Drilling (MWD, LWD, FEWD)

Mud Logging requires a surface acquisition system and is manned by a team of 2 to 4 persons. During drilling operations, sensors are placed to record various drilling data and samples of the cuttings are caught and analyzed. The information recorded includes:

• Mechanical, hydraulic, and engineering parameters (Depth, ROP, RPM, WOB, Torque, Drilling Mud parameters etc.)
• Drilled cuttings are analyzed to provide geologic data (lithology, fluorescents
• Gas analysis measured from the mud returns

Wireline Logging requires four different types of equipment: the downhole instruments which contain the sensors that measure the data, the surface data acquisition system, the cable or wireline which serves as both mechanical and data communication link with the downhole instruments, and the hoisting equipment to raise and lower the instruments.

Measurement While Drilling (MWD) Logging requires similar equipment to Wireline logging. The primary difference is that the downhole instruments are an integral part of the Bottom Hole Assembly (BHA) so the drilling process acts as the hoisting equipment to raise and lower the instruments. Data transmission usually involves digitally encoding data and transmitting to the surface as pressure pulses in the mud system. Additionally, the data is recorded in memory modules and this data is downloaded once the instruments are retrieved from the well bore.

Post Well-Site Acquisition

Regardless of the acquisition method involved or the deliverable format received some process of identity resolution and data indexing is generally necessary to accurately catalog well log data.

Identity resolution involves verifying the identification of the particular well log making sure that the location information on the log matches a standard such as PI/D Well Information, the 5010 Borehole file from the Minerals Management Service (MMS), existing data in an internal database or any other suitable resource.

Once the well header information has been verified, the well log may be further indexed capturing additional attributes that will aid in classification. Examples of attributes are as follows:

• Service Company
• Service Name
• Log Scale
• Reference
  • Measured Depth
  • Total Vertical Depth
  • Time
• Top and Bottom logged interval
• Logging dates
• Log quality
• Source of the log

Definitions

While the following terms may be described in a number of different ways, these definitions attempt to describe each term in the context of the PPDM model.

Job

A Job encompasses all of the activities performed by a Business Entity (generally a Service Company), while it is engaged by the Operator of the Well to perform services. The scope of services for the Job is generally specified under the terms of a contract or service order. The Job begins when the Service Company arrives at the Well and ends when it leaves. As an example, for a land based well, a Job begins when the Logging Crew arrives in the truck at the well site and it ends when they drive away.

Run

The definition of Run is nearly the same as for a Job with the exception of its scope. The designation of a Run number attempts to track and differentiate between the types of services performed in a Job. An example might be the best way to illustrate the differences between Job and Run. Let's say that a service company is called to a well and performs an induction/sonic from 1000 to 3000 ft. The logging crew leaves and the Job is complete. Then, a week later, the service company comes back and runs another induction/sonic from 3000 to 5000 ft AND runs an FDC/CNL from 4000 to 5000 ft. The FIRST induction/sonic would be RUN 1 and the second induction/sonic would be RUN 2. However, the FDC/CNL, even though it was run during the same JOB as Run 2 of the induction/sonic would be RUN 1. In summary, there were two Jobs and two Runs, but they don't necessarily match up.

Trip

A Trip encompasses all of the activities performed by a Business Entity (generally a Service Company), while a particular Logging Tool String is in the Well borehole. The Trip begins when the tool is inserted into the hole and end when it is pulled out. Trips exist within the context of a Run and there may be 0, 1, or more Trips per Run.

Pass

A Pass is any continuous recording of sensor readings for the logging instruments within a Trip. A Pass begins when data recording is started and ends when data recording is stopped. For depth based data acquisition, the Tool String is generally moving up or down the Well borehole during a Pass, whereas it may be stationary for time based data acquisition. Passes exist within the context of a Trip and there may be 0, 1, or more Passes per Trip.

Log

A log is a group of one or more curves. These curves, when taken together, are often assigned a name, such as Induction/Sonic, or FDC/CNL. When dealing with digitally delivered well log data, a log is generally synonymous with Pass or File. This definition is a bit vague, but serves as a starting point on which to build.

File

A File is the basic unit of digital well log data interchange. DLIS, LIS, and BIT are multi-file tape formats, which can be encapsulated and created on, or copied to disk as a single physical File. Each logical File within this physical disk File is roughly comparable to the information contained in one LAS File. The basic semantically relevant package of information is the file for ASCII formats or the logical file for DLIS, LIS, or BIT. The File contains all of the information related to an acquisition Pass.

Parameter

Each file may contain one or more sets of mnemonic/value pairs. Regardless of how this information is semantically related, it is organized in a simple table structure. There are over 13,000 recognized mnemonics which may appear in these tables. Some are easily recognizable and are commonly used, however there are no enforced standard for these mnemonics or their meanings. It is very common to find more than one mnemonic for the same item of information. For example, if one was looking for the temperature at the surface when the well was logged, one would have to search for the mnemonics SHT, ST, STEM, SURFACE_TEMPERATURE, or TSUR. New mnemonics may be added at any time by anyone, and put into use without any prior authorization or warning to the industry. Further complicating matters, some values are intended to be identified as one of a set of possible values. For example, the value for the permanent datum of the well (identified by the mnemonic PDAT), may be found to contain 'GL', 'G.L.', 'GROUND LEVEL' or some other variation (generally in English), all meaning ground level. Standardization for these sets of values is even less formal than the parameter mnemonics themselves.

Frame

The term Frame has two closely related meanings depending on its context. A "Frame of Data" contains one sample of each curve associated with a specific primary index value (e.g. depth or time). In this case, a sample may be a single value, or a complex multi dimensional array. The primary index is most commonly depth or time, but may be anything. The "Frame Specification" specifies which curves are to be grouped together, the type of the common index (depth, time, etc.), and the sampling characteristics (regular, irregular, spacing between samples if regular, etc.)

The only digital log data format that specifically exposes frames is DLIS. The other formats (LIS, LAS, BIT, etc.) all use frames, but since there is only ever one Frame Specification per File, it is often lumped in with the information about the File. DLIS, on the other hand, provides for multiple Frame Specifications (and consequently instances of each type of frame specified). This information is important, and must be retained in any system that tracks information about DLIS tapes or files. (Technically, LIS provides a mechanism for recording multiple frame types per File, but this has never been utilized and has therefore been ignored.)

Curve

Also known as a Channel, a Curve is a set of values with a corresponding index (e.g. depth or time) for each value. In digital well log interchange formats, a Curve may be associated with only one Frame. The simplest of curves contains one value for each index value of depth or time. Curves can, however, be very complex entities containing multi-dimensional arrays of data values in each Frame.

Use Cases

Use cases for the PPDM Well Log Model were used to validate the work as the model was developed. The four use cases described below represent cases that were deemed important by the developers of the model. Other uses cases and combinations of use cases are possible, but were not specifically validated.

1. Digital Well Log Data (DLIS, LIS, BIT, LAS) Archival.

DLIS, LIS, BIT, LAS, and other ASCII well log data files are to be managed using the PPDM database. These interchange formats are primarily organized by their physical elements of Files, Frames, Curves, Parameters, and others. The relationship of the information contained in each File is generally associated with a specific Pass, but its relationship to Job, Run, and Trip is not always known or easily determined. Tracking the Well associated with each File is mandatory. All of the necessary information needed to find and retrieve Curves and well site information must be stored in the PPDM database. The data (digits) may be stored in an external file system, or within the PPDM database. There are probably other use cases, but these 4 seem to be the ones under current discussion regarding log data management. Log data acquisition (including activities and equipment) is outside the scope of the current model proposal.

2. Programmatically generated Log Data.

Curves are generated by a program (often referred to as “results data”) are placed directly in the database. There may be no acquisition information associated with the curve and it may only need to be associated with a Well. No external file may ever exist so document tracking is not necessarily required.

3. Well Log Image Archival.

A well log image file or "picture" of the log is to be stored and managed by the PPDM database. Individual Curves depicted are not necessarily tracked, however the "name" or type of the Log depicted, the depth interval or intervals presented and information concerning the location within the image is tracked. The external image file is considered to be a document, which will be managed by the PPDM database, probably in the Records Management Module.

4. Digitized Log Data.

Digitized Log Data is, for all intents and purposes, the same data as described in “Digital Well Log Data.” The primary difference is this data is vectorized (created) from a paper or digital image of the log print. The significance of separating this data is that the quality of the curve is dependant upon the quality of the source document and the vectorization process used to convert the log image to digital curves so the user may choose to handle this data differently than the original tape data.

Curves associated with a Log are digitized as required and associated with a specific Job/Run and Trip. No external data file exists, and hence does not need to be tracked. The organization of Curves into groups as they would have been in acquisition is the same. A paper document or image may need to be tracked.

Digital Well Log Data

Digital Well Log Data is delivered in a variety of formats encoded on a number of mediums. Over the past 30 years, delivery mediums have included all forms of magnetic tape (9-track, 4mm, 8mm, DLT, etc.), Floppy Disk, CD ROM, DVD ROM, FTP, and email, to name a few. Depending on the media used, a number of encapsulation techniques have been utilized to transports formats specific to one medium encoded on another medium. An example of this Tape Image Format (TIF, a.k.a. TAP) was created by Atlas Wireline Services in 1988 for writing tape based formats such as LIS and BIT onto random access media such as hard drives and CD’s. While there have been many formats created for transporting well log data, 5 formats stand out for use in public interchange. These formats are:

• LIS - The Log Information Standard
• DLIS - The Digital Log Interchange Standard
• BIT - The Basic Information Tape
• LAS - The Log ASCII Standard
• WellLogML - The Well Log XML Standard

Since these 5 are the most common and most likely to be loaded into PPDM, they will be described in more detail below.

LIS

The Log Information Standard (LIS) Tape format was developed by Schlumberger in 1974 and is documented in the manual Log Information Standard, Customer Subset dated October 1981, and later revised in 1986. While this standard was never officially adopted by any standards organization, it quickly became the de facto standard for the exchange or delivery of well log data from the late 1970’s well into the mid 1990’s. Because of its longevity, there is a large volume of data archived in this format on a variety of media.

LIS was designed primarily for use on magnetic tape, but with the use of an encapsulation technique, has been extended to random access media. LIS is a layered format that attempts to define separation among the data content, logical structure and physical structure. In a very simplistic sense, the data is recorded as tables of information stored in a variety of logical records, bound to media using physical records.

DLIS

The Digital Log Interchange Standard V1.00 (DLIS) was introduced on May 1, 1991 as Recommended Practice 66 (RP 66) by the American Petroleum Institute. Version 2.0 was introduced in June 1996, however Version 1.00 is still primarily used for the interchange of well log data. DLIS is probably the best and least well understood means for interchanging well log data. In an extremely simplistic view, it can be thought of as an object-like database, which has been serialized and bound to a sequential format. Like LIS, DLIS too separates data into layers. In order from the lowest to the highest layer, they are Media, Format, Model, Schema, and Dictionary. The first three layers are often referred to as RP66, while the addition of the fourth and optionally the fifth layer constitute DLIS. Other formats (e.g. Geoshare) have been created utilizing the first 3 layers with a modified 4th and 5th layer. The layers are as follows:

• Media - This layer is concerned with how data is written to physical media, such as tape, disk, or even communication links. This includes tape marks, and records for tape devices, stream file encoding of data for random access media, and data layer mapping for communications protocols.
• Format - This layer is concerned with the low-level organization of the data. This includes the concept of logical records, the mapping of logical records onto physical records, and the representation of numbers, characters and other special data.
• Model - This layer specifies the data model supported by RP66. The data model is the application-level view of how data is organized. In a relational database, for example, this is the concept of tables, columns, views, joins, etc. In RP66, two types if data organization is supported. The first type is somewhat object-oriented. An object in RP66 is a self-describing collection of information that represents some entity. This entity may represent a physical thing, or may be an event or activity. The second type of data organization provides for encoding large volumes of sequential data with as little overhead as possible.
• Schema - This layer contains the descriptions of the specific objects used by any particular industry or company. The Model layer specifies what an object is; the Schema layer describes what each object contains and all of the objects, which comprise a standard such as DLIS or Geoshare.
• Dictionary - The dictionary layer contains two distinct parts. The first part consists of objects used to describe other objects that make up a specific schema. This is similar to the TABLE table and COLUMN table of a relational database. The second part of the dictionary contains the names, definitions, and restrictions placed on the objects.

BIT

The Basic Information Tape (BIT) was created by Dresser Atlas in the 1970’s for binding digital well logs onto 9-track tape. Each BIT tape can contain 1 or more files. Each file is composed of only two types of records. The General Heading record contains minimal well identification and information required to read and process the Data records. Each file on the tape begins with one General Heading record and is followed by one or more data records. Each file on a BIT tape may contain up to a maximum of 20 single sampled curves (not including the index channel of depth or time). The data records are all of a fixed length determined by the number of curves present and are recorded in a block multiplexed mode. BIT tapes are not commonly used for the interchange of data today, but are still found in many well log tape archives.

LAS

The Log ASCII Standard was created by the Canadian Well Logging Society in the late 1980’s. LAS was intended to supply basic digital log data to users of personal computers in a format that was quick and easy to use. LAS is an ASCII file with minimal header information, intended for optically presented log curves. LAS was designed around a collection of file “sections.” Each section began with a title line, and that title line was marked with a tilde (“~”) at the beginning of the line. LAS Version 1.2 was fist documented in a paper by the CWLS on September 1, 1990. LAS 2.0 was published on September 25, 1992, but was fundamentally the same as V1.2 in information content.

The sections that make up LAS Version 1.2 or 2.0 files are as follows:

~V - contains version and wrap mode information

~W - contains well identification

~C - contains curve information

~P - contains parameters or constants (this section is optional)

~O - contains other information such as comments (this section is optional)

~A - contains ASCII log data (always the last section)

LAS Version 3.0, published June 10, 2000 represents a major change to the original LAS concept of simplicity. LAS 3.0 added many new features, including:

1. New Data types. (Core, Drilling, etc.).
2. "Structure" rules separated from "Content" rules.
3. New delimiters and structures.
4. Comma Tab and Space delimited data.
5. 1D, 2D and 3D array handling.
6. Multiple Runs Support
7. Parameter Zoning.
8. Floating point, string, integer, Date and Time formats Support.
9. Addition of User defined data
10. WRAP mode no longer supported.
11. ~Other section removed.
12. 23 predefined “~” section names, with the ability to add an unlimited number of user defined sections.

WellLogML

WellLogML is an XML based, ASCII well Log data format that was designed for exchanging well log data over networks (Internet and intranets). WellLogML (due to the nature of XML) is organized hierarchically into sections as follows:

1. Document Information
2. Well Information
3. Curve Information
4. Parameter Information
5. Downhole Information
6. Other Information
7. Curve Data or Frame Data

Each section is itself composed of subsections identified by Markup tags. The scope and content of a WellLogML file is similar to LAS. Notable features are its ability to handle Array channels, parameter information grouped by run number, and multiple means of curve data organization. The curve data organization options are as follows:

1. Frames – This is the most common organization of data in which one sample (single value or array) of each curve is aligned with the index (depth, time, etc.) at which it was acquired. (Same style used by LAS.)
2. Block Multiplexed Frames – This organization allows for multiple samples of each curve to be grouped into separate identifiable blocks.
3. Curve Sequential – This organization is not commonly used in log analysis software, but it is particularly useful for files that are intended to be rendered graphically. The curves are organized such that all samples of the index curve are grouped together, followed by all samples of each dependent curve.
4. Block Multiplexed Curve Sequential – This organization allows for each curve to be broken down into multiple, identifiable, groups of samples.

Programmatically Generated Log Data

To further enhance the usefulness of digital well log data, advanced analysis is often required. New algorithms are continually developed to attempt to garner greater understanding of rock and fluid properties. The “results curves” of this analysis may be stored along with the raw data or as a separate log.

Well Log Image Data

A Well Log Image may be described as a computerized picture of a well log. Digital vector data is graphically presented in a form that is meaningful for a geoscientist to perform analysis. The origin of the well log image file may be a scanned paper plot or an image rendered using digital curve data. For example, some applications allow a user to import digital log data, view, annotate and output the resulting image to a variety of graphic file formats including PDF, BMP, JPEG, CGM and TIFF.

Today, information is being captured and added to these image files significantly enhancing their value. Very often the well log is characterized with respect to the image representation itself. That is, data about the well log within the context of the image file is recorded and stored. For instance, the key positions within the image file of various parts of the well log may be recorded. Calibration or registration of a well log image may be performed in any number of ways. For instance, a well log image may contain a number of sections representing a variety of section types. Section types could be defined in any number of ways. The following figure depicts one fairly simple example of the types of sections in a raster, well log image:

In the figure above well log sections could be defined as:

• Header
• Tool String Configuration
• Upper Scale
• Lower Scale
• Log Sections
• Trailer
• Miscellaneous

Log sections could be further classified as:

• Main Pass
• Uplog
• Downlog
• High Resolution
• Repeat Pass, etc.

For well log image calibration, it’s important to capture a number of points in order to accurately represent those sections of a well log image deemed interesting. In the following example, non-depth related X, Y value pairs could be captured for the Header and Parameter sections of the well log image:

The most common calibration information obtained is a depth registration in which X and Y pixel values are captured at each depth of interest within a well log section. In the first diagram below, X and Y value pairs are recorded and stored with several key depths. However, many X and Y value pairs could be stored with each depth captured to further represent the well log image and lend accuracy to the end user’s analysis process. Furthermore, these extra points are useful for identifying and correcting problems such as skew and paper stretch that may have occurred during the scanning process.

The following partial well log image depicts a possible calibration scenario. X, Y value pairs associated with depths in a log section are represented by the diamond shape while arrows represent possible X, Y values of interest that are not related to depth values. In this instance, the top-left and bottom-right X, Y values have been captured for both the upper and lower, horizontal scale sections.

Additional sections of the well log may be delineated that again do not include an associated depth value. For instance, it is often very useful for geoscientist to view the tool configuration diagram while processing the well log. The following example illustrates the points that might be captured to lend easy access of the tool configuration section:

In the next example, X, Y values are captured for these sections:

• Lower Scale
• Parameter Section
• Trailer

Digitized Log Data

Digitizing paper log plots is another means of obtaining digital log data. Since the digital log provides the ultimate data set with no hindrance to performing any log analysis functions that are present with images or paper logs, it is often necessary to digitize curves when the digital version is unavailable. The digitizing process has been around for quite some time and will be covered only in general terms in this guide. Digitizing became a commercial process in the late 1970’s but remains a very specialized service. A typical modern digitizing process may include identity resolution, data entry of the well header and run parameter data, scanning the log, grid detection and curve vectorization.

Header Entry

To enable the usage of a digitized log to its fullest, additional information on the log must be captured. The well header information including location and elevation information and all run parameter data must be captured and stored with the log curves. The quality of analysis and environmental correction operations may be diminished in the absence of this information.

Scanning the Log

Typically a log is scanned using specialized scanning software and hardware designed to accommodate very long documents not typically encountered outside the industry.

Grid Detection

Grid Detection is a method by which the digitizing software identifies and quantifies the grid of a log section. During grid detection, an operator supplies key information for each track to be digitized. The software attempts to optically sense the track’s grid. In the example below, nodes are assigned to each grid line intersection. The operator then reviews and modifies the nodes assigned by the software until an optimal result is achieved. In this manner, the grid pixels can be discerned from the actual curve trace pixels.

Curve Vectorization

Curve vectorization is the process by which a sequence of vectors is generated corresponding to the individual well log curve traces. Vectors are applied along all continuous lines on the well log image. Only the grid lines are ignored as a result of being defined as such during the grid detection process described above. The following image depicts the results of the automated vectorization process:

After automated vectorization, an operator must visually inspect the resulting curve vectors and correct all problems that may have resulted from overlapping curve traces or poor well log image quality. Once digitized, the resulting log data can be used in any way that originally captured digital log data may be used.

References

Luthi, Stefan (2001) The History of Logging (taken from the book: Geological Well Logs, their use in reservoir modeling, Springer-Verlag)