Practical Well Log Standards

Background

As the results of Phase I were combined and published in February 2001, dialogue ensued concerning the approach taken to the classification of curves. 

What was the approach at that point in time?

• The Phase I results presented two curve classifications: 
  • A Property Type classification based on a broad-based, pre-existing property classification
  • A Curve Type classification based on mnemonic token sequences
• The two classifications were presented in parallel, i.e. with an explicit mapping between them. 

The two classifications were described at the time of the Version 1.0 release Web page as follows:

• Curve Type [Curve Type Short]
  A classification based on, and linked to, the Property Type (see below). While Property Type is a generic classification, the Curve Type is designed to be more specific to the petrophysical domain. The Curve Type will group curves of a similar physical measurement (for example, acoustic slowness) or that have similar usage (for example, density quality). The Curve Type is a mnemonic or token-based system that uses a '.' (dot) character to visually separate the components. The examples above would be 'AC.SLO.' and 'DEN.QUAL.' respectively.

  Curve Types can be used to provide context filters on a curve set. For example, a user may specify only Curve Type 'DEN' on a search (possibly in conjunction with Business Value = 'High') and only have density-related curves returned. The context filter could be applied manually through a query request screen or automatically by an application requiring certain Curve Types for an analysis.

  Alternatively, a search for all curves sorted by Curve Type would list the curves by the primary petrophysical measurement. This would make it easier to select required curves compared to sorting on the curve mnemonics.

  There is a one-to-one mapping between the Curve Types and the Property Types.

• Property Type [Curve Type Long]
  This is a generic classification based on the physical property being measured. The defined Property Types are based on Schlumberger's original Property Type Classifications. Extensions have been made in this project. 

  The Property Type is a full-text description using an underscore separator.

  The Property Type can be used to provide a context filter in the same way as the Curve Type.

Divergent Points of View

At least four points of view were expressed about the curve classification situation. These can be generalized and expressed as follows:

• Property Type is all that is needed for classification and use. The Curve Type is an unnecessary, second classification scheme expressed in an undesirable composite mnemonic form.
• Curve Type is the preferred classification approach and is well suited to help search and use curve data. The Property Type hierarchy and leaf node names don't add anything useful.
• The dual classification system is unnecessary and costly to maintain. It will invite different usage patterns by service companies and software vendors. An early project decision to link the two systems via an algorithmic method of generating one from the other was not fulfilled. Put 'practical' back into the project results.
• The dual classification system may not be needed, but it is best to leave it in place for a period of time to see whether one or the other system will demonstrate its advantages or whether the need for both will become accepted.

What Happened Just After the V1.0 Release?

Just prior to publication, the three stage-based spreadsheets were combined into a single Tool/Curve spreadsheet. Soon after publication, it was noted that the column headings for Property Type and Curve Type appeared as Curve Type Long and Curve Type Short. This was a result of pasting later stage results into an early stage spreadsheet file. These two sets of titles reflect two different viewpoints from Phase I. The column titles were changed to reflect the later stage viewpoint.

Participants in Phase I exchanged messages which taken together represented the four points of view listed above.

Work on an Implementation

During this process, the spreadsheet results were validated and several kinds of errors were found. These were reviewed and corrected as they were identified.

In April '01, the new Web-based interface was ready for testing, but this work was not released pending resolution of the classification issue and adjustment of the implementation to the agreed approach.

Examining the Phase I Results

In order to help reach a resolution of the classification issue, a fresh analysis of the Phase I results was conducted in an attempt to determine whether there is substantive justification for maintaining dual classifications. 

As further analysis progressed, the justification for dual classifications has become less clear. As aspects of the differences became understood and as the consequences of a dual approach were considered, the basis for a renewed effort to avoid the dual approach has emerged.

The essence of the problem was found to be the attempt to derive the meaning of the classification from the name of the class. This is inherently wrong.

As of June 2001, the sets of names used in each approach were found to be very close to each other. Consider the following details about some of the key differences:

• The number of extensions made to the classification hierarchy during the Phase I work was relatively small (about 5%).
• Only two of the 399 classifications express different concepts, namely: (property type versus curve type)
  • Nom_Borehole_Diameter versus Bit_Size
  • Gamma_Ray_Minus_Uranium versus Gamma_Ray_Potassium_Thorium
• There are a relatively small number of word usage differences, e.g., (property type usage <=> curve type usage)
  • Sonic is used 6 times, Acoustic is used 8 times and /omit/ 20 times <=> Acoustic
  • Undisturbed zone <=> Formation (all 6 times)
  • (Mineral) Concentration <=> /omit/ (all 5 times)
  • specific mineral names <=> Element with the names (10 times) and Mineral with the names (30 times)
  • Filter Cake <=> Mud Cake (all 5 times)
  • Free <=> Free Fluid Index (2 times)
  • Borehole is used 5 times, Hole is used 2 times, and /omit/ 2 times <=> Borehole
  • Speed is used 2 times and Velocity is used 7 times <=> Velocity
  • Nuclear Magnetic is used once, NMR is used 5 times, and /omit/ 4 times <=> NMR
  • Thermal Gradient <=> Temperature Gradient
  • Apparent is used 3 times <=> 18 times
  • Electromagnetic is used 7 times and /omit/ 4 times <=> Electromagnetic
  • Tool is used 7 times and /omit/ 2 times <=> Tool
  • Shallow is used 6 times and /omit/ 2 times <=> Shallow
  • vertical depths are used two times <=> extra word Depth added
  • Propagation Time is used 3 times <=> Time (but Time is used to simply mean Time 3 other times)
  • Density is used 25 times and Bulk Density is used 2 times <=> Density
  • MWD is used once <=> /omit/
  • Volume Fraction is used 57 times <=> Volume Fraction is used 56 times and /omit/ once
• There were a few inconsistencies in the mnemonics used, e.g., the two Archie Porosity entries, Exponent has two mnemonic spellings, the same mnemonic represents Sand and Sandstone.
• About half of the classifications differ in word order. The Curve Type word order was found to be very disciplined, presumably from the goal that it be used for sorting and searching. This raised the possibility that the word order is in fact deterministic. The Property Type word order, on the other hand, is well suited to spoken and written English usage.  

Applying the Results of the Analysis 

A concept emerged from the analysis. Instead of considering Property Type and Curve Type as dual classification schemes, maybe we can unify them by taking the strong points from each one.

• Maintain the Property Type word order as the classification Identifier, given its foundation in a broader scope and its value as a natural language descriptor.
• Consider the mnemonic components that form the Curve Type as a set of characteristics that can be useful for finding and searching.
• Confirm that there is a well-defined sequence of component sets that can be used in an automated way to generate the current Curve Type mnemonic ordering. (Work on this has been very encouraging. This should support a very flexible user interface for search / query operations and eliminate any order dependence in working with these classification characteristics.)
• The characteristics can be determined from the Property Type name, parentage, and definition. 

The Way Forward

It was recommended that the project address the alternative resolutions to the curve classification issue: The alternatives include:

• Keep Property Type. Drop Curve Type.
• Keep Curve Type. Drop Property Type.
• Keep both as defined and as mapped in the Version 1.0 release files.
• Take the results of the analysis as a blueprint for defining a unified classification approach.

The last alternative was recommended and taken forward to produce what will be called Version 2. 

Last modified: July 28, 2003. Send questions and comments to webmaster@posc.org

Copyright © 2001-3 Petrotechnical Open Standards Consortium, Inc. All rights reserved.
POSC ®, the POSC logo ® and Epicentre ® are registered trademarks of Petrotechnical Open Standards Consortium, Inc.