The Petroware AS Log I/O module is a library for accessing
(reading or writing) well log files such as
DLIS,
LAS2,
LAS3,
LIS,
BIT,
XTF,
ASC,
SPWLA or
CSV.
Log I/O utilize high capacity memory mapped non-blocking I/O in
order to get maximum performance for very large (GB) files.

Note that virtually all well logging data from the Norwegian continental
shelf are QC'ed through the Log Studio™ application causing the library to get
extremely well tested.

Log I/O is available for Java (LogIo.jar) and .Net (LogIo.dll).
The libraries are self-contained, they have no external dependencies.

Programming examples

Digital Log Interchange Standard (DLIS) is a digital well log format introduced as
Recommended Practice 66 (RP 66) by the American Petroleum Institute in 1991.
RP 66 exists in two versions,
V1
and
V2.
V2 is not commonly used.
DLIS is a binary (big-endian) data format.

DLIS is an old format in all possible ways. Available DLIS software is limited
and to a large degree orphaned technology. The existence of programming tools
for DLIS are absent. There is no easily accessible DLIS format description available,
dialects exists, and DLIS is in general very hard to digest.

But still, DLIS is the main storage and communication medium for wellbore logging information.
Since logging technology has evolved substantially since the introduction of the format,
the amount of information contained may be vast; multi-GB volumes are commonplace.

Using Log I/O, reading and writing DLIS files becomes trivial.
Note that a physical DLIS file consist of a file header and one or more logical DLIS files, each
containing a number of sets (meta-data), one or more frames containing
curve data, and possibly a set of encrypted records. A frame contains an index curve
and a set of measurement curves. Each curve may be single- or multi-dimensional.

A complete example program for reading a DLIS file with Log I/O is shown below:

Creating DLIS files from scratch includes populating DlisFile instances with
sets, frames and curves and writing them to disk using
the DlisFileWriter class.

Note that the write API is by design low-level and there are many possible ways for
a client to create an inconsistent DLIS file instance. The design is chosen for
simplicity and flexibility. Each client is likely to implement one DLIS writer component anyway,
and following the simple procedure below will ensure consistent DLIS instances:

//
// Create one frame per frame objects in the FRAME set and populate with curves and data.
// The curves must already have been defined in the CHANNEL set above.
//
DlisFrame frame = new DlisFrame(frameSet, frameObject);

Log Interchange Standard (LIS) is the predecessor of DLIS and was
developed by Schlumberger in 1974.

Like DLIS, LIS is a binary (big-endian) format.
It it is based on the VAX binary information standard and has an even more awkward syntax than DLIS.

But still, LIS files are still being produced and immense volumes of historical logging information
exists in this format. Log I/O is a convenient platform for being able to manage and maintain this
information.

A physical LIS file consists of one or more logical LIS files, each containing a
set of records (meta-data) of different types as well as an index curve and
a set of measurement curves. Each curve may have one or several samples per depth measure,
and in addition the curves may be single- or multi-dimensional.

A complete example program for reading a LIS file with Log I/O is shown below:

Creating LIS files from scratch includes populating LisFile instances with
records and curves and writing them to disk
using the LisFileWriter class.

Note that the write API is by design low-level and there are many possible ways for
a client to create an inconsistent LIS file instance. The design is chosen for
simplicity and flexibility. Each client is likely to implement one LIS writer module anyway,
and following the simple procedure below will ensure consistent LIS instances:

LAS popularity is due to its simple syntax and the fact that it contains human readable ASCII text.
Consequently it is easier to work with than the black-box DLIS and LIS files.
The ASCII format has a price however; It requires a lot more storage space than equivalent DLIS files,
so LAS is not useful for very large log volumes. Also, the easily accessible text format combined
with an ambiguous format description has caused many LAS dialects and semantic interpretations over
the years.

Three different versions of LAS exists,
1.2,
2.0 and
3.0.
Current version is 3.0, published in 2000, but version 2.0 is by far the most common.
Log I/O supports all LAS versions, as well as converting between them.
Note that LAS does not support multi-frame nor multi-dimensional curves like DLIS.
LAS 3.0 supports multiple subfiles per physical disk file.

A complete example program for reading a LAS file with Log I/O is shown below:

Creating LAS files from scratch includes populating LasFile instances with
sections and curves and writing them
to disk using the LasFileWriter class.

The mandatory ~VERSION section will be auto-populated. The mandatory ~WELL
section must be created by the client, but parameters associated with the curve data
(STRT, STOP, STEP and NULL)
will be auto-populated if the section is present.

The optional parameter sections must be provided by the client.

The definition section(s) (~CURVE) will be auto-populated based on provided curves.

A complete example program for writing a LAS file with Log I/O is shown below:

The Basic Information Tape (BIT) is a binary well log format created by
Dresser Atlas in in the 1970's.

Each physical BIT disk file can contain one or more logical
BIT files. Each logical file is composed by a simple General Heading record
followed by a number of Data records holding data for a maximum of 20 curves
(not including the index channel of depth or time). All curve data is 4-byte floating point
in the IBM System/360 representation.

The BIT format is no longer in common use, but vast amounts of historic logging data
still exists in this format. The format is quite simple, but no public description
of it is available.

A complete example program for reading a BIT file with Log I/O is shown below:

The XTF format is a binary well log format created by
Western Atlas in the 1990's.
The format does not define its own binary encoding, but reflects the coding of the
originating system (i.e. IEEE, VAX, IBM, big-endian, little-endian etc.).

An XTF file is divided into blocks of 4096 bytes each and keeps a bitmap index defining
valid blocks. Consequently, the information in an XTF file can be extended, replaced or
removed without rewriting the entire file.

An XTF file consists of a predefined file header, a well header, a number of curves, each
having a curve header and single- or multi-dimensional data. Optionally the file can
contain predefined data types such as well variables, zones, section headers or
client defined types.

Unllike most other well log formats an XTF file does not have a common index curve.
Each curve of the file is evenly sampled and keeps reference to its own start index and
sample rate.

A complete example program for reading an XTF file with Log I/O is shown below:

// Loop over all plugs. A plug has a top and a bottom depth
// some properties associated with the plug, and then log measurements
// organized in a SpwlaLogSet, being a compund of SPWLA log curves.
for (SpwlaPlug plug : core.getPlugs()) {
System.out.println(plug);
}
}

ASC is a collective term used in the industry for denoting any ASCII based
file that may contain well log information.

The Log I/O ASC reader uses advanced pattern recognising technology in order to automatically
digest the vast number of different inputs it may be passed. It will handle column based,
token based or delimiter (CSV) based bulk input through a best effort approach,
and it also handles provided header information.
The ASC reader may be used to read any spreadsheet files saved as CSV.

The associated ASC writer may produce pretty printed column based or CSV output as well
as condensed CSV output if required.

A complete example program for reading an ASC file with Log I/O is shown below: