Technical
Article
10 THINGS TO KNOW ABOUT
WELL LOGS
In today’s fast-everything society, I am often asked for a short set
of rules for checking the quality of well logs. Since you asked….
By Martin Storey, senior consultant, Well Data Quality Assurance Pty Ltd
H ow does one distill several
decades of learning on rigs
and in tape libraries, data
rooms and offices into a few snappy points?
As with many questions, the answer
depends on the circumstances. The first
rules must therefore have to do with framing
the situation.
1 Distinguish between historical data
and incoming data.
With historical (also known as legacy, old
or pre-existing) data, what is available is
generally all there is, and its quality con-
trol consists of verifying that it is what is
expected for the particular data set.
With incoming (also referred to as new
or future) data, the quality control should
include verifying that all the technical
specifications of the contract for the prod-
uct are met and, if they are not, engaging
with the supplier until they are.
In practice, however, contractual speci-
fications are rarely detailed or exhaustive,
and the incoming data quality control is
shared between the operations and petro-
physics departments, without either side
following a precise script.
2 Distinguish between original data and
derived data.
Original (also known as raw, acquisition or
received) data is the record from an oper-
ation done once and reflects the circum-
stances at that one particular time, never
to be repeated exactly.
Derived (often referred to as evaluated,
processed or interpreted) data is produced
from original data, either within the organ-
ization or by an external party, and could
conceivably be recreated. Derived data al-
most always has an interpretative character,
so it could have more than one version.
In real life, the distinction between
original and derived data is not always
clear-cut, particularly in the past decade
when much original data has already been
subjected to various forms of processing
prior to its initial delivery.
Log data interpreters tend to use
mainly original data, while other users
of log data tend to use derived data.
Original data is often voluminous and
raw, while derived data should have been
conditioned and validated, or generated
from data that has been conditioned and
validated, and is therefore presumed
safer. However, different applications
may require the logs to be conditioned
differently.
LOG CATEGORIES HISTORICAL
• Own records or databases
• Data vendor
ORIGINAL
• Provider of public domain data
• Merger or acquisition
• Own records or databases
• Processed data vendor
DERIVED • P rovider of public domain interpretative
data
• Merger or acquisition
Examples of sources for the different
log data categories are shown in the table
below, which is not exhaustive. The inter-
rupted lines indicate that the distinctions
are not absolute.
As subtle as these distinctions may seem
to some, they largely determine the activ-
ities required to control the quality and
manage the non-quality of the log data. It
is therefore important to keep data sets of
different categories distinct and readily
identifiable.
The original query has now morphed
into four distinct questions, and the first two
rules do not actually serve to accept or reject
data sets. We are getting to that, but we are
not yet done with fundamental principles.
3 Data must be managed for the short
and the long term concurrently.
The point of this rule is that managing only
for the immediate requirements and initial
workflows is insufficient and ultimately
damaging.
INCOMING
• Data acquisition company for own or
joint-venture-project ongoing operations
• Data processing company
• Asset swap
• Data acquisition company for own or
joint-venture-project ongoing operations
• Data processing company
Foundations | Fall 2014 | 19
Technical Article
Log data is generally “hot” for a short
period after it was acquired or generated,
but the initial demands on the data are often
quite light: for most operational decisions or
rush evaluations, high-quality data is not re-
quired and the decisions can be made on the
basis of preliminary data. The data becomes
hot again at various and largely unpredictable
times later on. Eventually, the demands on
the data may become more and more specific,
requiring higher and broader data quality.
People are often surprised to hear that
old data can be as good as modern data,
but it is, and the main impediment to the use
of old data is not its lack of intrinsic value,
but its availability and incompleteness. The
lifespan of data is longer than our own, and
as temporary custodians, we must preserve
its value for future exploitation.
Let us now get practical.
4 Original logs normally come in two
forms—print and tape—and both
are required.
» T he print (or film or image) is frequently
delivered as a digital raster or vector
image file, such as a TIFF or PDF.
» The tape (or CD or digital data) is generally
a digital file in Digital Log Interchange
Standard (DLIS) or Log ASCII Standard
(LAS) format, but historically other
formats have been used, such as the Log
Information Standard (LIS) and TIF.
Both are needed because each may
contain information that is essential for the
valid exploitation of the data and that is
found nowhere else. The image below shows
a barely legible section of a log print that
contains critical information about the data
and the depth reference. This information is
not on the tape and ignoring it could result in
overlooking a prospective interval or per-
forating the wrong formation in a well.
Example of essential information
found exclusively on a log print.
20 | Journal of the Professional Petroleum Data Management Association
5 Original data must be obtained and
stored in the original format, and that
format is usually DLIS or LIS, not LAS.
DLIS frequently contains contextual informa-
tion found nowhere else, while LAS generally
contains very little contextual information.
DLIS and LAS are among the most com-
mon digital formats for log data. DLIS and
its predecessor, LIS, are binary formats,
while LAS files are written in ASCII and
can be read using any text reader. LAS was
first introduced in the late 1980s by the
Canadian Well Logging Society and was
originally intended for exchanging basic
digital log data on floppy disks between
personal computers in a quick and easy-to-
use format. It succeeded, and 25 years later
it remains a convenient format for moving
log data around.
The specifications of LAS have been
enhanced, and LAS has the potential to
contain almost any log data. In practice,
however, LAS files are never complete and
generally contain only the main curves.
DLIS files are much more likely to contain
the ancillary curves, acquisition param-
eters and contextual information required
for the exploitation of the data. DLIS files
can be large, with numerous curves that
can disorient the casual user; however,
these complete files are required in the
record to ensure that the data can be evalu-
ated and interpreted in the future.
If you must also receive data deliveries
in LAS files, the consistency of the DLIS
and LAS data sets needs to be checked
systematically. The LAS set should be
a subset of the DLIS set, and the curve
names, data sampling, depths and data
values should be exactly the same. As an
empirical rule, any conversion from one
format to another results in the loss of
data required by the technical experts for
exploitation or reprocessing. Because of a
lack of a unique digital log data exchange
standard, many data exporter software
programs have produced corrupted files,
which reside incognito in our archives.
6 For the exploitation of any log data,
context is king and must be preserved.
Data without context can only be used
by making arbitrary assumptions that in-
crease the organization’s risk unnecessar-
ily. According to a Society of Professional
Well Log Analysts article, Current
Status of Well Logging Data Deliverables
and A Vision Forward, the first context-
ual feature of a log is its print header,
including the reference metadata, the
remarks section, the description of the
logging tool string configuration and
hopefully more. There is a lot of other
contextual information relating to logs,
including the operations sequence, the
detailed drilling history, mud compos-
ition and tidal conditions, and any of
these may have a critical impact on data
exploitation.
This is not an anecdotal point. Good
interpreters should verify that their con-
clusions are consistent with other relevant
information. The more thoroughly that
consistency can be verified, the more
confidence there will be in the recommen-
dations used to support the organization’s
decisions.
In many countries, the combination of
the original log prints, log tapes and the
operator’s end of well report (sometimes
called a final well report or a completion
report), complete with attachments and
appendices, can normally provide all the
information required for the present and
future exploitation of the original log data.
7 The completeness of the data sets
should be assessed and captured
using a data inventory.
IMAGE: AUSTRALIAN PUBLIC RECORD
Data sets vary in form and content due to
their companies of origin, their locations,
the time when the data was generated, the
vintage of the tools and software used, the
operator’s specific requirements, etc. There
is therefore no standard delivery.
Some data sets contain several different
prints, log quality control prints, image

prints, processing results, time-based
data, raw and corrected data, special tool
documentation and several successive
deliverables. A good way to stay organized
is for the main people involved—opera-
tions geologist, petrophysicist, reservoir
engineer—to compile an inventory of the
expected data beforehand. This is not
always done, but it helps everyone clarify
the content and timing of deliverables and
plan their work accordingly.
Later, the inventory should be a central
feature of the data management system, so
that a prospective user can establish what
a data set contains and whether its various
components are available.
8 Validate the metadata first.
The validation of the prints’ metadata
is essentially the confirmation that the
header data is correct, clear and coherent.
Bad metadata is a major contributor
to data loss, according to Guy Holmes in
Search and Rescue: The Data Lost and Found
Initiative. Not finding a data item when it
is needed can result in severe opportunity
loss and additional costs. Although it may
not appear in the record, more than one
well has been drilled to re-acquire data that
could no longer be found. It is often said that
data acquisition companies are very good
at doing the hard stuff and not so good at
doing the easy stuff.
In fairness, metadata is often provided
to data acquisition companies by the oper-
ating company. Getting the reference
information right is basic quality assur-
ance and everyone’s responsibility. Well
coordinates and elevations are notoriously
unreliable on logs, but more disconcert-
ingly, so are wellbore names, which are
often the main handle of a data set. Data
sets are surprisingly often registered
against the wrong wellbore—Laurel-1
instead of Laurel-1ST1—or against the
wrong well name—Hardy 1 instead of
Hardy-1—rendering the data difficult to
locate. Validating the metadata may be
feasible with programmatic rules if this
does not interfere with the data user’s
day-to-day work, and it may be best driven
by the data management team. The PPDM
Association’s What Is A Well is a valuable
reference for this.
9 Perform basic checks on the original
data prints.
Once the metadata has been verified, the
data itself should be checked. From the
data management perspective, the main
items to consider are:
» Prints should have a header and a tail so
that it is clear that no section of the log print
has been torn out or is otherwise missing.
» In between the header and the tail, in
approximate top-to-bottom order, most
prints should include:
• a full log header including remarks;
• tool sketch with the sensor measure
points;
• a well sketch;
• one or several log sections, preferably
clearly labelled (ex. main log; repeat
section; correlation pass; main log,
1:200 scale);
• a repeat section in the case of forma-
tion evaluation logs;
• parameter listings for each log sec-
tion; and
• a tool calibration section.
» Modern logs should also contain:
• a job chronology;
• a depth information box;
• a survey listing; and
• quality-control plots.
» Some logs are presented on logarithmic
scales. If the grid scales are not consistent
with the data scales serious interpretation
errors can occur, so it is wise to check
these, too.
10 Basic checks on the original
data tape.
Many things can go wrong with log data,
and there is no set list of rules to check or a
certain way to assure quality.
In spite of several competent people
having been involved in the production of
the log data, such as the logging engineer,
a wellsite witness, line managers and a
petrophysicist, errors often slip in.
Moreover, each set delivered is liable to
have new errors that were not in the previ-
ous delivery—perhaps a wholly or partially
missing curve, missing vector data or a
sampling interval set slightly incorrectly at
0.152 metres instead of 0.1524 metres.
Every tape delivered must therefore be
verified. Aspects that can easily be checked
Technical Article
by the data management group include the
tape’s legibility using the organization’s
normal readers and the presence of at least
one file per log section.
Some logs are acquired and put on
the tape but not presented in print. For
instance, logs recorded while running in
the hole and a gamma ray log recorded in
casing up to the ground level.
Again, metadata is a frequent problem
with tapes: is the tape correctly labelled and
is each file on the tape clearly identified?
Both the logging date and the tape creation
date must be specified on the label. When
several versions of a tape exist, the latest one
normally supersedes all previous ones, which
should be destroyed to minimize future con-
fusion—even if all are labelled “final.”
The checking of derived data is even
less generic, although similar principles
apply: the data must be fully identified and
complete, and it must contain all neces-
sary contextual information or references,
and preferably be stored in a future-proof
format. Actual checks and processes will
depend on the organization’s systems.
Well log data quality assurance is not
straightforward because no one person in
the chain of custody is at the same time ful-
ly informed, competent and enabled to do
it all. From the perspective of data manage-
ment and with the aim to “provide the right
data at the right time to the right people,”
it is essential to work with all stakeholders
to maximize the quality of the incoming
data, as well as to minimize quality erosion
during its life cycle.
In essence, most of the rules apply to
other categories of well data, for instance,
mud log data or even core analysis data. The
likelihood that data will be exploited for its
original purpose, as well as for initially un-
foreseen purposes, is directly related to its
quality and availability: the better these are,
the more easily the data can be exploited
and the more value can be obtained from it,
even decades after it was acquired.
Martin Storey started in the oil and gas in-
dustry as a logging engineer, then became a
wellsite petroleum engineer and a petrophys-
icist. He is now an independent practitioner,
consultant and trainer in petrophysics and
data management based in Australia.
Foundations | Fall 2014 | 21