Want updates? Opt out any time

News
« The digital well scorecard | Main | How to make a geologist happy »
Wednesday
Dec052012

Swimming in acronym soup

In a few rare instances, an abbreviation can become so well-known that it is adopted into everyday language; more familar than the words it used to stand for. It's embarrasing, but I needed to actually look up LASER, and you might feel the same way with SONAR. These acronyms are the exception. Most are obscure barriers to entry in technical conversations. They can be constructs for wielding authority and exclusivity. Welcome to the club, if you know the password.

No domain of subsurface technology is riddled with more acronyms than well log analysis and formation evaluation. This is a big part of — perhaps too much of a part of — why petrophysics is hard. Last week, I came across a well. It has an extended suite of logs, and I wanted make a synthetic. Have a glance at the image and see which curve names you recognize (the size represents the frequency the names are encountered across many files of the same well).

I felt like I was being spoken to by some earlier deliquent: I got yer well logs right here buddy. Have fun sorting this mess out.

The log ASCII standard (*.LAS file) file format goes a long way to exposing descriptive information in the header. But this information is often incomplete, missing, and says nothing about the quality or completeness of the data. I had to scan 5 files to compile this soup. A micro-travesty and a failure, in my opinion. How does one turn this into meaningful information for geoscience?

Whose job is it to sort this out? The service company that collected the data? The operator that paid for it? A third party down the road?

What I need is not only an acronym look-up table, but also a data range tool to show me what I've got in the file (or files), and at which locations and depths I've got it. A database to give me more information about these acronyms would be nice too, and a feature that allows me to compare multiple files, wells, and directories at once. It would be like a life preserver. Maybe we should build it.

I made the word cloud by pasting text into wordle.net. I extracted the text from the data files using the wonderful LASReader written by Warren Weckesser. Yay, open source!

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (4)

Evan,
Before you read on, I should disclose that I am a Petrophysicist, and also that I am independent (not affiliated to any large company).
You are referring to what Schlumberger calls TLA (Three-Letter Acronyms) and the like. Acronyms are necessary as an alternative to longer names, which are themselves necessary to distinguish one curve from another, and yes, there are thousands of acronyms because there are thousands of different curves, "different" as in "apples" vs. "oranges" or sometimes "Macintosh" vs "Golden Delicious", where the difference, whether it makes one to any particular user such as you and me, must be recorded.
In truth, there are quite a few acronyms, and amongst the most commonly used, that are common between different curves. For instance, a curve called "GR" on a log could be a environmentally corrected GR, a raw GR, or something in-between (partly environmentally corrected), and this makes a whole lot of difference to most users, even if they are often oblivious to the situation. In other words, what we really need are more acronyms, not less, if we wanted to have exactly one acronym per fully characterized curve.
This makes log analysis more complicated than it should be, that's true, because the nature of the curves to be used use is often not fully captured which we must manage by making reasonable assumptions a.k.a. educated guesses. Also, one needs a lot of historical knowledge of the different vintages of the different tools of the different companies to make correct sense of the acronyms. Still, people who insist on simplifying often introduce dramatic non-quality that can be very difficult to detect and correct. For instance, there is quite a difference in the nature of the "epithermal neutron porosity" vs. the "thermal neutron porosity", or of the neutron porosity in limestone units vs. in sandstone units, yet often the original data (which contains this information) is simplified to record only that the curve is a "neutron", e.g. NPHI... If the error introduced is very large, it will probably be detected, but if it is significant without being so large that it is obvious, it will probably not. What difference does it make? The answer to this is necessarily case-by-case but I have seen it make the difference between water interpreted as hydrocarbons and vice-versa, not infrequently.
Whose job is it to sort this out? Why, the log interpreter, of course. One of the interpreter's jobs is to take the original logs and interpret them into data sets that are meaningful to the team. Just like you wouldn't let the brain surgeon do the anesthesia, one should not leave that part of the work to the geophysicist, geologist, etc.
Acronym look-up tables: there are many out there - see for instance http://www.spwla.org/technical/mnemonic-listings (the word "mnemonic" is a synonym for "acronym" in petrophysical lingo). Thankfully a given operator often has only so many acronyms to get used to during a particular period of time, so the specific knowledge should be accrued up front, preferably led by the petrophysicist. Also, the customer should insist on the logging company to deliver prints with the long names of the curves, not just the acronyms. Finally, the customer should always, always, always ask for the original data in an original data format, which normally means LIS or Atlas TIF (in the past) or DLIS (more recently), not LAS, even if LAS has the potential to contain the entire information set (a potential seldom exercised).
Tool to show you what is in the file: there are a number of commercial tools out there to do that, and there is a "freeware" available from Schlumberger called the "Toolbox". A well-known search engine provides the following URL for that utility: http://www.slb.com/services/characterization/software/data_utilities/log_data_toolbox.aspx.
I am happy to answer questions on this topic... in fact I enjoy it so much that it's one of the things I do for a profession.

December 6, 2012 | Unregistered CommenterMartin Storey

Martin,
Wow, thanks for sharing these great points. I agree with your notion that, for better curve management (it seems), we need more acronymns not less. The Apples (Golden Delicious, and Granny Smith), and Oranges metaphor is a great one.

December 6, 2012 | Registered CommenterEvan Bianco

Evan, I'd like to add to what Martin has already described, that it's a bit scary when I start thinking about the end user's (say, operating company or a free lancer - both being the customers for me as I work for a service company) perception of log data even if they are conversant with the difference between two mnemonics e.g.: ZDEN and ZDNC. So the questions I would ask if I were a receiving party - is this 'fully' corrected density as the name suggests really corrected for all effects? Is this 'corrected' density was created in the field by the engineer or it was revised by a geoscientist and he/she took the raw curve and made appropriate corrections from the beginning and only then provided the resultant curve? If I decide to endeavour to do corrections by myself do I have/use the relevant charts for that?
Maybe I sound a bit oversuspicious but to me this is actually more important than decyphering mnemonics (which can be a pain of course with big datasets) that can done through look-up tables or by a phone call/e-mail to a provider.
Again I do share your frustration about how to handle this and I believe the answer to your questions can be this: accept the data only when it's understood, explained (Martin's comment on long names) and QC'ed.

December 14, 2012 | Unregistered CommenterAlexander

Gentlepeople,
Following up on what Alexander wrote, I'd like to add that "absolutely! These things matter a great deal and are often overlooked, and the best-qualified persons to handle them are the petrophysicists, whose job it is to make sure they are done right. Absolutely it can be very difficult for us too, but we have ways to mitigate the difficulties, e.g. by making sure that we have also pre-corrected curves and by making sure that the corrections applied are spelled out in the remarks. If some logging engineers do that even if not asked... well done! Corrections are not just difficult in the sense that they have to be done exactly right (with the right methods or charts and the right parameters): they also have to be done exactly once and when there is a sequence of corrections, as is often the case, they have to be done in the right order. If correction 3 of 5 is done incorrectly, corrections 5, 4, and 3 have to be undone in that order, then redone correctly. Of course I may sound like I'm blowing my petrophysicist's horn, but to paraphrase Yogi Berra, it's not because many people do not understand what we do that what we do is not essential.

December 16, 2012 | Unregistered CommenterMartin Storey

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>