DLIS API Reference#

Load a DLIS-file#

dlisio.dlis.load(path, error_handler=None)#

Loads a file and returns one filehandle pr logical file.

Load does more than just opening the file. A DLIS file has no random access in itself, so load scans the entire file and creates its own index to emulate random access.

DLIS-files are segmented into Logical Files, see dlisio.dlis.PhysicalFile and dlisio.dlis.LogicalFile. The partitioning into Logical Files also happens at load.

Parameters:
  • path (str_like) –

  • error_handler (dlisio.common.ErrorHandler, optional) – Error handling rules. Default rules will apply if none supplied. Handler will be added to all the logical files, so users may modify the behavior at any time.

Returns:

dlis

Return type:

dlisio.dlis.PhysicalFile

Notes

It’s not uncommon that DLIS files are stored with different file extensions than .DLIS. For example .TIF [1]. Load does not care about file extension at all. As long as the content adheres to the Digital Log Interchange Standard, load will read it as such.

[1] TIF in this case refers to TapeImageFormat, and is not to be confused

with the image format TIFF.

Examples

Load is designed to work with python’s with-statement:

>>> from dlisio import dlis
>>> with dlis.load(filename) as files:
...     for f in files:
...         pass

Automatically unpack the first logical file and store the remaining logical files in tail

>>> with dlis.load(filename) as (f, *tail):
...     pass

Note that the parentheses are needed when unpacking directly in the with- statement. The asterisk allows an arbitrary number of extra logical files to be stored in tail. Use len(tail) to check how many extra logical files there are.

Physical File#

class dlisio.dlis.PhysicalFile#

A Physical File

A physical DLIS file, i.e. a regular file on disk, is segmented into multiple Logical Files (LF). Think of a DLIS file as a folder-structure. The DLIS-file itself is the folder, and the Logical Files are the actual files:

your_file.dlis
|
|-> Logical File 0
|-> Logical File 1
|-> Logical File 2
...
|-> Logical File n

Each LF is a logical grouping of log data and metadata related to the acquisition of those logs. The LF’s are independent of each other and can be thought of as separate files.

This class is essentially a tuple of all the Logical Files in a regular file, and is what’s being returned by dlisio.dlis.load(). The LFs can be unpacked following standard Python tuple unpacking rules.

Notes

The DLIS-specification, rp66v1, opens up for a Logical File to span multiple physical files. dlisio does not currently have cross-file support. We have yet to see any files in the wild using this feature. Note that dlisio will still be able to open such files, but any internal cross-referencing will be lost.

See also

dlisio.dlis.load

Open and Index a DLIS-file

dlisio.dlis.LogicalFile

Interface for working with a single Logical File

close()#

Close the file handles of all Logical Files

describe(width=80, indent='')#

Describe

Returns a human-readable and printable summary of the current Physical File.

Logical Files#

class dlisio.dlis.LogicalFile#

Logical file (LF)

This class supplies the main interface for working with a single Logical File. A Logical File contains log data and metadata related to the acquisition of the logs. The metadata is stored as ‘objects’ - in lack of a better word. There are different object-types for different types of data. The logs can be acquired through Frame- and Channel-objects (dlisio.dlis.Frame and dlisio.dlis.Channel). There is also an abundance of object-types for storing other metadata: Tool, Parameter, Measurement and Calibration to name a few.

object() and find() let you access specific objects or search for objects matching a regular expression. Unknown objects such as vendor-specific objects are accessible through the ‘unknown’-attribute.

Uniquely identifying an object within a logical file can be a bit cumbersome, and confusing. It requires no less than 4 attributes! Namely, the object’s type, name, origin and copynumber. The standard allows for two objects of the same type to have the same name, as long as either their origin or copynumber differ. E.g. there may exist two channels with the same name/mnemonic.

Metadata caching

All metadata (e.g. Frame, Channel, Parameter) are cached by default. This avoids re-creation of the same objects.

Note that changes to settings such as dlisio.common.set_encodings() or LogicalFile.error_handler after loading the file will not propagate to already-cached objects. It’s therefore advisable that such settings are set before loading the file. Alternatively, you can manually toggle on and off caching to clear it with cache_metadata().

types = {}#

Dispatch-table for turning dlisio.core.basic_object into type-specific python objects like Channel and Frame. This is mainly intended for internal use so the typical user can safely ignore this attribute.

Object-types not present in the table are considered as unknowns. They can still be reached through object() and find() but lack the syntactic sugar added by the type-specific classes.

It is possible to monkey-patch the dispatch-table with your own custom classes. However this is considered to be a fairly advanced usage and it’s then the users responsibility of ensuring correctness for the custom class.

Type:

dict

close()#

Close the file handle

It is not necessary to call this method if you’re using the with statement, which will close the file for you.

cache_metadata(cache)#

Toggle caching of metadata objects

By default, the metadata objects are cached to avoid unnecessary re-creation of objects. Like all caching, this trades CPU time for memory usage.

Parameters:

cache (bool) – Toggle caching on/off

property fileheader#

Return the Fileheader

Returns:

fileheader

Return type:

Fileheader

axes = None#
calibrations = None#
channels = None#
coefficients = None#
comments = None#
computations = None#
equipments = None#
frames = None#
groups = None#
longnames = None#
measurements = None#
messages = None#
origins = None#
parameters = None#
paths = None#
processes = None#
splices = None#
tools = None#
wellrefs = None#
zones = None#
noformats = None#
property unknowns#

Return all objects that are unknown to dlisio.

Unknown objects are object-types that dlisio does not know about. By default, any metadata object not defined by rp66v1 [1]. The are all parsed as dlisio.dlis.Unknown, that implements a dict interface.

[1] http://w3.energistics.org/rp66/v1/Toc/main.html

Notes

Adding a custom python class for an object-type to dlis.types will in-effect remove all objects of that type from unknowns.

Returns:

objects – A defaultdict index by object-type

Return type:

defaultdict(dict)

find(objecttype, objectname=None, matcher=None)#

Find objects in the logical file

Find searches and returns all objects matching objecttype, and if specified, objectname. By default find uses python’s re module with case-insensitivity when searching for objects matching objecttype and objectname. See examples for how to use.

Parameters:
  • objectype (str) – type of objects to be looked for

  • objectname (str, optional) – name / mnemonic of objects to be looked for

  • matcher (Any matcher derived from dlisio.core.matcher, optional) – matcher object to be used when comparing objecttype, objectname to file content. Default is dlisio.dlis.regex.

Returns:

objects – A list of all objects in the logicalfile that matches objecttype (and objectname)

Return type:

list

See also

dlisio.dlis.utils.exact_matcher

str comparison w/ str.__eq__

dlisio.dlis.utils.regex_matcher

str comparison w/ python’s re module

Examples

Query for all Channels where the name / mnemonic contains ‘GR’:

>>> f.find('CHANNEL', '.*GR.*')
[Channel(GR), Channel(GR1)]

Query for all Channel-like objects. I.e. both regular Channels and vendor-specific ones:

>>> f.find('.*CHANNEL')
[Channel(TDEP), Channel(GR), Channel(GR1), 440channel(GR2)]

The two queries above can be combined:

>>> f.find('.*CHANNEL', '.*GR.*')
[Channel(GR), Channel(GR1), 440channel(GR2)]

Omitting the objectname yields all objects matching objecttype:

>>> f.find('FRAME')
[Frame(60B), Frame(20B), Frame(10B)]

If your query does not include a regular expression and you care about performance, tell find to use the default exact matcher. For large files there is a significant difference between comparing strings with self.exact and compiling- and comparing regex expressions with self.regex.

>>> f.find('FRAME', matcher=dlisio.dlis.exact)
[Frame(60B), Frame(20B), Frame(10B)]
object(type, name, origin=None, copynr=None)#

Direct access to a single object. dlis-objects are uniquely identifiable by the combination of type, name, origin and copynumber of the object. However, in most cases type and name are sufficient to identify a specific object. If origin and/or copynr is omitted in the function call, and there are multiple objects matching the type and name, a ValueError is raised.

Parameters:
  • type (str) – type as specified in RP66

  • name (str) – name

  • origin (number, optional) – number specifying which origin object the current object belongs to

  • copynr (number, optional) – number specifying the copynumber of current object

Returns:

obj

Return type:

searched object

Examples

>>> ch = f.object("CHANNEL", "MKAP", 2, 0)
>>> print(ch.name)
MKAP
describe(width=80, indent='')#

Printable summary of the logical file

Parameters:
  • width (int) – maximum width of each line.

  • indent (str) – string that will be prepended to each line.

Returns:

summary – A printable summary of the logical file

Return type:

dlisio.dlis.utils.Summary

load()#

Force load all objects - mainly indended for debugging

storage_label()#

Return the storage label of the physical file

Notes

This method is mainly intended for internal use.

DLIS Frame#

class dlisio.dlis.Frame(BasicObject)#

Frame

A Frame is a logical gathering of multiple Channels (curves), typically Channels from the same run. A Frame containing three Channels would look something like this:

 TDEP     AIBK    TENS_SL
-------  -------  -------
|          |           |
 |          |         |
  |         |        |
   |       |        |
    |       |       |
     |     |         |

Usually, the first channel in the channel list is considered to be the index-channel of the Frame. See:attr:index_type for more information about the index channels.

All Channels belonging to a Frame are directly accessible through channels. A full table of all the curve-data can be accessed with curves.

description#

Textual description of the Frame.

RP66V1 name: DESCRIPTION

Type:

str

channels#

Channels in the frame

RP66V1 name: CHANNELS

Type:

list(Channel)

index_type#

The measurement of the index, e.g. borehole-depth. If not None, the first channel is considered to be an index channel. If index_type is None, then the Frame has no index channel and is implicitly indexed by samplenumber i.e. 0, 1, …, n.

RP66V1 name: INDEX-TYPE

Type:

str

direction#

Direction of the index (Increasing or decreasing)

RP66V1 name: DIRECTION

Type:

str

spacing#

Constant spacing in the index

RP66V1 name: SPACING

index_min#

Minimum value of the index

RP66V1 name: INDEX-MIN

index_max#

Maximum value of the index

RP66V1 name: INDEX-MAX

encrypted#

If the frame was encrypted

RP66V1 name: ENCRYPTED

Type:

bool

See also

BasicObject

The basic object that Frame is derived from

Channel

Channel objects

Notes

The Frame object reflects the logical record type FRAME, defined in rp66. FRAME objects are listed in Appendix A.2 - Logical Record Types, and described in detail in Chapter 5.7.1 - Static and Frame Data, FRAME objects.

attributes = {'CHANNELS': 3, 'DESCRIPTION': 2, 'DIRECTION': 2, 'ENCRYPTED': 1, 'INDEX-MAX': 2, 'INDEX-MIN': 2, 'INDEX-TYPE': 2, 'SPACING': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

curves(strict=True)#

All curves belonging to this frame

Get all the curves in this frame as a structured numpy array. The frame includes the frame number (FRAMENO), to detect errors such as missing entries and out-of-order frames.

Parameters:

strict (boolean, optional) – By default (strict=True) curves() raises a ValueError if there are multiple channel with the same values for both name, origin and copynumber. This would be a clear violation of the dlis-spec. Setting strict=False lifts this restriction and dlisio will append numerical values (i.e. 0, 1, 2 ..) to the labels used for column-names in the returned array.

Returns:

curves – curves with dtype = self.dtype

Return type:

np.ndarray

Raises:

ValueError – If there multiple channels with identical name, origin, copynumber in Frame.channels. This can be suppressed by passing strict=False

See also

Channel.curves

Access the curve-data directly through the Channel objects

Frame.dtype

dtype of the array

Examples

The returned array supports both horizontal- and vertical slicing. Do a vertical slice by specifying a single Channel

>>> curves = frame.curves()
>>> curves['CHANN1']
array([16677259., 852606., 16678259., 852606.])

Access a subset of Channels, note the double-bracket syntax

>>> curves[['CHANN2', 'CHANN3']]
array([
    (16677259., 852606.),
    (16678259., 852606.),
    (16679259., 852606.),
    (16680259., 852606.)
])

Do a horizontal slice of all Channels, i.e. read a subset of samples from all channels

>>> curves[0:2]
array([
    (16677259., 852606., 2233., 852606.),
    (16678259., 852606., 2237., 852606.)])

Horizontal and vertical slicing can be combined

>>> curves['CHANN2'][0]
16677259.0

And here the subscription order is irrelevant

>>> curves[0]['CHANN2']
16677259.0

Some curves, like image curves, have multi-dimensional samples. Accessing a single sample from a 2-dimensional curve

>>> curves = frame.curves()
>>> sample = curves['MULTI_D_CHANNEL'][0]
>>> sample
array([[ 1,  2,  3],
       [ 4,  5,  6],
       [ 7,  8,  9],
       [10, 11,  12]])

This sample is a 2-dimensional array of size 4x3. We can continue to slice this sample. Note that now the subscription order here does matter. Here we read the two last rows

>>> sample[-2:]
array([[  7,  8,  9],
       [ 10, 11, 12]])

Lets read every second column

>>> sample[:,::2]
array([[ 1, 3],
       [ 4, 6],
       [ 7, 9],
       [10, 12]])

Note the syntax. Within the brackets, everything before the ‘,’ is row- operations and everything after are column-operations. Read it as: keep all rows (:) and then from first to last column, keep every 2nd column (::2). The comma syntax for indexing different axes extends to array’s with higher orders as well.

Combine the two to read a specific element

>>> sample[0,0]
1

If you prefer to work with pandas over numpy, the conversion is trivial

>>> import pandas as pd
>>> curves = pd.DataFrame(frame.curves())

Note that pandas (and CSV) only supports scalar sample values. I.e. frames containing one or more channels that have none-scalar sample values cannot be converted to pandas.DataFrame or CSV directly.

If the Frame contains an index Channel, use that as index in the DataFrame

>>> curves = frame.curves()
>>> pdcurves = pd.DataFrame(curves, index=curves[frame.index])
>>> pdcurves.index.name = frame.index

By default the returned np.ndarray have column-names that reflects the mnemonics of each Channel

>>> frame.channels
[Channel(TDEP), Channel(TIME), Channel(GR)]
>>> curves = frame.curves()
>>> curves.dtype.names
('FRAMENO', 'TDEP', 'TIME', 'GR')

Sometimes a Frame can contain multiple Channels with the same name/mnemonic, in that case the labels are augmented with the origin and copynumber:

>>> frame.channels
[Channel(TDEP), Channel(TDEP), Channel(GR)]
>>> curves = frame.curves()
>>> curves.dtype.names
('FRAMENO', 'TDEP.0.0', 'TDEP.0.1', 'GR')

This augmentation is customizable by changing dtype_fmt. See dtype. Some frames have multiple instances of the same channel or mulitple channels where name, origin and copynumber are identical. This is a clear violation of the dlis spec and curves() will raise an ValueError by default.

>>> frame.channels
[Channel(TDEP), Channel(TDEP), Channel(GR)]
>>> Frame.curves()
ValueError: field 'TDEP.0.0' occurs more than once

However, curves() offers an escape-hatch to get the underlying data. By passing strict=False dlisio appends numerical values to the identical channels

>>> curves = frame.curves(strict=False)
>>> curves.dtype.names
('FRAMENO', 'TDEP.0.0(0)', 'TDEP.0.0(1)', 'GR')
dtype(strict=True)#

data-type of each frame, i.e. the sum of channel.dtype of each channel in self.channels. The first column is always FRAMENO.

If all curve mnemonics are unique, then dtype.names == [‘FRAMENO’] + [ch.name for ch in self.channels]. If there are more than one channel with the same name for this frame, all duplicated mnemonics are enriched with origin and copynumber.

Consider a frame with the channels mnemonics [(‘TIME’, 0, 0), (‘TDEP’, 0, 0), (‘TIME, 1, 0)]: dtype.names for this frame would be (‘FRAMENO’, ‘TIME.0.0’, ‘TDEP’, ‘TIME.1.0’).

Duplicated mnemonics are formatted by the dtype_fmt attribute. To use a custom format for a specific frame instance, set dtype_fmt for the Frame object. If you want to have some other formatting for all dtypes, set the dtype_format class attribute. It has to be a 3-element format-string taking a string and two ints. Custom formatting is particularly useful for peculiar files where the full stop (.) appears in the mnemonic itself, and a consistent way of parsing origin and copynumber are needed.

In addition to the customizable dtype.names, ch.fingerprint is always used as field title, which serves as an alias for the name.

Returns:

dtype

Return type:

np.dtype

Examples

A frame with two TIME channels:

>>> dtype = frame.dtype()
>>> dtype.names
dtype([('FRAMENO', '<i4'),
       (('T.CHANNEL-I.TIME-O.0-C.0','TIME.0.0'), '<f4'),
       (('T.CHANNEL-I.TDEP-O.0-C.0','TDEP'), '<i2'),
       (('T.CHANNEL-I.TIME-O.1-C.0','TIME.1.0'), '<i2')])

Override instance-specific mnemonic formatting

>>> frame.dtype().names
(FRAMENO', 'TIME.0.0', 'TDEP', 'TIME.1.0')
>>> frame.dtype_fmt = '{:s}-{:d}-{:d}'
>>> frame.dtype()
(FRAMENO','TIME-0-0', 'TDEP','TIME-1-0')
property index#

Mnemonic of the channel all channels in this Frame are indexed against, if any. See Frame.index_type for definition of existing index channel.

Returns:

mnemonic

Return type:

str

linkage = {'CHANNELS': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

DLIS Channel#

class dlisio.dlis.Channel(BasicObject)#

A channel is a sequence of measured or computed samples that are indexed against some physical quantity e.g. depth or time. The standard supports multi-dimensional samples. Each sample can be a scalar or a n-dimensional array. In addition to giving access to the actual curve-data, the Channel object contains metadata about the curve.

All Channels are a part of one, and only one, Frame. The parent Frame can be reached directly through frame.

Refer to the curves() to see some examples on how to access the curve-data.

long_name#

Descriptive name of the channel.

RP66V1 name: LONG-NAME

Type:

str or Longname

reprc#

Representation code

RP66V1 name: REPRESENTATION-CODE

Type:

int

units#

Physical units of each element in the channel’s sample arrays

RP66V1 name: UNITS

Type:

str

properties#

Property indicators that summarizes the characteristics of the channel and the processing that have produced it.

RP66V1 name: PROPERTIES

Type:

list(str)

dimension#

Dimensions of the samples

RP66V1 name: DIMENSION

Type:

list(int)

axis#

Coordinate axes of the samples

RP66V1 name: AXIS

Type:

list(Axis)

element_limit#

The maximum size of the sample dimensions

RP66V1 name: ELEMENT-LIMIT

Type:

list(int)

source#

The source of the channel. Returns the source object, if any

RP66V1 name: SOURCE

frame#

Frame to which channel belongs to

Type:

Frame

See also

BasicObject

The basic object that Channel is derived from

Notes

The Channel object reflects the logical record type CHANNEL, defined in rp66. CHANNEL records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.5.1 - Static and Frame Data, CHANNEL objects.

attributes = {'AXIS': 4, 'DIMENSION': 4, 'ELEMENT-LIMIT': 4, 'LONG-NAME': 2, 'PROPERTIES': 3, 'REPRESENTATION-CODE': 2, 'SOURCE': 2, 'UNITS': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

curves()#

Returns a numpy ndarray with the curves-values.

Returns:

curves

Return type:

np.ndarray or None

See also

Frame.curves

Notes

This method should only be used if there is only one channel of interest in a particular frame.

Due to the memory-layout of dlis-files, reading a single channel from disk and reading the entire frame is almost equally fast. That means reading channels from the same frame one-by-one with this method is _way_ slower than reading the entire frame with Frame.curves() and then indexing on the channels-of-interest.

Examples

Read the full curve

>>> curve = channel.curves()
>>> curve
array([1.1, 2.2, 3.3, 4.4])

The returned array supports common slicing operations

>>> curve[::2]
array([1.1, 3.3])

Read the full curve from a multidimensional channel

>>> curve = multichannel.curves()
>>> curve
array([[[  1,  2,  3],
        [  4,  5,  6]],
       [[  7,  8,  9],
        [ 10, 11,  12]]])

This curve has two samples, that both are of size 2x3. From the 1st sample, read the element located in the 2nd row, 3rd column

>>> curve[0][1][2]
6
property dtype#

data-type of each sample in the channel’s sample array. The dtype-label is channel.name.id.

Returns:

dtype

Return type:

np.dtype

linkage = {'AXIS': <function obname.<locals>.fingerprint>, 'LONG-NAME': <function obname.<locals>.fingerprint>, 'SOURCE': <function objref>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Other Metadata#

Basic Object#

class dlisio.dlis.BasicObject#

A Basic object that all other object-types derive from

BasicObject is mainly an implementation detail. Its the least common denominator of all object-types.

When working with dlisio you need not care too much about the BasicObject. However, keep in mind that all other object-types inherit BasicObject’s attributes and methods and they can be called directly on the objects. Hence it might be a good idea to somewhat familiarize yourself with its features.

When reading the documentation keep in mind that the attributes defined on the BasicObject are not documented again on the derived object.

An object is uniquely identifiable within a logical file by the combination of its type, name, origin and copynumber. I.e. no two objects can have the same type, name, origin AND copynumber. This means that the standard allows for e.g. two Channels to have the same name/mnemonic, which can easily become a bit confusing.

type#

Type of the object, e.g. rp66 object-types as CHANNEL or FRAME

Type:

str

name#

Mnemonic / name

Type:

str

origin#

Defines which origin the object belongs to

Type:

int

copynumber#

There may exist several copies of the same object, the copynumber is used to distinguish them

Type:

int

attic#

Attic refers the underlying basic_object, which is a dict-representation of the data on disk. The attic can be None if this particular instance was not loaded from disk.

Type:

dict_like

attributes = {}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

property fingerprint#

Object fingerprint

Return the fingerprint, a unique identifier, for this object. This is basically an objref type from the RP66 standard, but with a pythonic flavour, and suitable for keys in dicts.

Returns:

fingerprint

Return type:

str

property stash#

Attributes unknown to dlisio

It is not uncommon for objects to have ‘extra’ attributes that are not defined by the standard. Because such attributes are unknown to dlisio, they cannot be reach through normal attributes.

Returns:

stash – all attributes not defined in attributes

Return type:

dict

describe(width=80, indent='', exclude='er')#

Printable summary of the object

Parameters:
  • width (int) – the maximum width of each line.

  • indent (str) – string that will be prepended to each line.

  • exclude (str) – exclude certain parts of the object in the summary.

Returns:

summary – A printable summary of the object

Return type:

utils.Summary

Notes

The exclude parameter gives the option to omit parts of the summary. The table below states the different modes available.

option

Description

‘h’

header

‘a’

known attributes

‘s’

attributes from stash

‘u’

units

‘i’

attributes that violates the standard [1]

‘e’

attributes with empty values (default) [2]

[1] Only applicable to attributes that should be interpreted in a specific way, such as Parameter.values. If not applicable, it is ignored.

[2] Do not print attributes that have no value.

Axis#

class dlisio.dlis.Axis(BasicObject)#

Axis

The Axis object describes the coordinate axis of an array, e.g. the sample array of channels. One axis object describes only one coordinate axis. I.e a three dimensional array is described by three Axis objects.

axis_id#

Axis identifier

RP66V1 name: AXIS-ID

Type:

str

coordinates#

Explicit coordinate value along the axis

RP66V1 name: COORDINATES

Type:

list

spacing#

Constant, signed spacing along the axis between successive coordinates

RP66V1 name: SPACING

See also

BasicObject

The basic object that Axis is derived from

Notes

The Axis object reflects the logical record type AXIS, defined in rp66. AXIS objects are listed in Appendix A.2 - Logical Record Types, and described in detail in Chapter 5.3.1 - Static and Frame Data, Axis Objects.

attributes = {'AXIS-ID': 2, 'COORDINATES': 3, 'SPACING': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Calibration#

class dlisio.dlis.Calibration(BasicObject)#

Calibration objects are a collection of measurements and coefficients that defines the calibration process of channel objects.

method#

Computational method used to calibrate the channels

RP66V1 name: METHOD

Type:

str

calibrated#

Calibrated channels

RP66V1 name: CALIBRATED-CHANNELS

Type:

list(Channel)

uncalibrated#

Uncalibrated channels. I.e. the channels as they where before calibration

RP66V1 name: UNCALIBRATED-CHANNELS

Type:

list(Channel)

coefficients#

Coefficients

RP66V1 name: COEFFICIENTS

Type:

list(Coefficient)

measurements#

Measurements

RP66V1 name: MEASUREMENTS

Type:

list(Measurement)

parameters#

Parameters containing numerical and textual information assosiated with the calibration process.

RP66V1 name: PARAMETERS

Type:

list(Parameter)

See also

BasicObject

The basic object that Calibration is derived from

Notes

The Calibration reflects the logical record type CALIBRATION, defined in rp66. CALIBRATION records are listen in Appendix A.2 - Logical Record Types and described detail in Chapter 5.8.7.3 - Static and Frame Data, CALIBRATION objects.

attributes = {'CALIBRATED-CHANNELS': 3, 'COEFFICIENTS': 3, 'MEASUREMENTS': 3, 'METHOD': 2, 'PARAMETERS': 3, 'UNCALIBRATED-CHANNELS': 3}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'CALIBRATED-CHANNELS': <function obname.<locals>.fingerprint>, 'COEFFICIENTS': <function obname.<locals>.fingerprint>, 'MEASUREMENTS': <function obname.<locals>.fingerprint>, 'PARAMETERS': <function obname.<locals>.fingerprint>, 'UNCALIBRATED-CHANNELS': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Coefficent#

class dlisio.dlis.Coefficient(BasicObject)#

Records of measurements, references, and tolerances used in the calibration of channels.

label#

Identify the coefficient-role in the calibration process

RP66V1 name: LABEL

Type:

str

coefficients#

Coefficients corresponding to the label

RP66V1 name: COEFFICIENTS

Type:

list

references#

Nominal values for each coefficient

RP66V1 name: REFERENCES

Type:

list

plus_tolerance#

Maximum value that a sample can exceed the reference and still be “within tolerance”

RP66V1 name: PLUS-TOLERANCES

Type:

list

minus_tolerance#

Maximum value that a sample can fall below the reference and still be “within tolerance”

RP66V1 name: MINUS-TOLERANCES

Type:

list

See also

BasicObject

The basic object that Coefficient is derived from

Notes

The Coefficient object reflects the logical record type CALIBRATION-COEFFICIENT, defined in rp66. CALIBRATION-COEFFICIENT records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.8.7.2 - Static and Frame Data, CALIBRATION-COEFFICIENT objects.

attributes = {'COEFFICIENTS': 3, 'LABEL': 2, 'MINUS-TOLERANCES': 3, 'PLUS-TOLERANCES': 3, 'REFERENCES': 3}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Comment#

class dlisio.dlis.Comment(BasicObject)#

Comment objects contains arbitrary messages that may be interesting for the consumer e.g. a drilling report.

text#

Textual comments

RP66V1 name: TEXT

Type:

list(str)

See also

BasicObject

The basic object that Comment is derived from

Notes

The Comment object reflects the logical record type COMMENT, described in rp66. COMMENT objects are defined in Appendix A.2 - Logical Record Types, described in detail in Chapter 6.1.2 - Transient Data, Comment objects.

attributes = {'TEXT': 3}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Computation#

class dlisio.dlis.Computation(BasicObject)#

Results of computations that are more appropriately expressed as static information rather than as channels.

The computation value(s) may be scalars or an array. In the later case, the structure of the array is defined in the dimension attribute. The zones attribute specifies which zones the computations is defined. If there are no zones the computation is defined everywhere.

The axis attribute, if present, defines axis labels for multidimensional value(s).

long_name#

Descriptive name of the computation

RP66V1 name: LONG-NAME

Type:

str or Longname

properties#

Property indicators that summarizes the characteristics of the computation and the processing that has occurred to produce it

RP66V1 name: PROPERTIES

Type:

list(str)

dimension#

Array structure of a single value

RP66V1 name: DIMENSION

Type:

list(int)

axis#

Coordinate axes of the values

RP66V1 name: AXIS

Type:

list(Axis)

zones#

Mutually disjoint zones over which the value of the current computation is constant

RP66V1 name: ZONES

Type:

list(Zone)

source#

The immediate source of the Computation

RP66V1 name: SOURCE

See also

BasicObject

The basic object that Computation is derived from

Notes

The Computation object reflects the logical record type COMPUTATION, defined in rp66. COMPUTATION objects are listed in Appendix A.2 - Logical Record Types, and described in detail in Chapter 5.8.6 - Static and Frame Data, COMPUTATION objects.

attributes = {'AXIS': 4, 'DIMENSION': 4, 'LONG-NAME': 2, 'PROPERTIES': 3, 'SOURCE': 2, 'VALUES': 3, 'ZONES': 3}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'AXIS': <function obname.<locals>.fingerprint>, 'LONG-NAME': <function obname.<locals>.fingerprint>, 'SOURCE': <function objref>, 'ZONES': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

property values#

Computation values

Computation value(s) may be scalar or array’s. The size/dimensionallity of each value is defined in the dimensions attribute.

Each value may or may not be zoned, i.e. it is only defined in a certain zone. If this is the case the first zone, computation.zones[0], will correspond to the first value, computation.values[0] and so on. If there is no zones, there should only be one value, which is said to be unzoned, i.e. it is defined everywhere.

RP66V1 name: VALUES

Raises:

ValueError – Unable to structure the values based on the information available.

Returns:

values

Return type:

structured np.ndarray

Notes

If dlisio is unable to structure the values due to insufficient or contradictory information in the object, an ValueError is raised. The raw array can still be accessed through attic, but note that in this case, the semantic meaning of the array is undefined.

Examples

First value:

>>> computation.values[0]
[10, 20, 30]

Zone (if any) where that parameter value is valid:

>>> computation.zones[0]
Zone('ZONE-A')

Equipment#

class dlisio.dlis.Equipment(BasicObject)#

Equipment objects contains information about individual pieces of surface and downhole equipment used in the acquistion of the data. Typically, tools (specified by the Tool object) is a composition of equipment.

trademark_name#

The producer’s name for the equipment

RP66V1 name: TRADEMARK-NAME

Type:

str

status#

Operational status

RP66V1 name: STATUS

Type:

bool

generic_type#

Generic type

RP66V1 name: TYPE

Type:

str

serial_number#

Serial number

RP66V1 name: SERIAL-NUMBER

Type:

str

location#

General location of equipment during acqusition

RP66V1 name: LOCATION

Type:

str

height#

Heigth

RP66V1 name: HEIGHT

length#

Length

RP66V1 name: LENGTH

diameter_min#

Minimum diameter

RP66V1 name: MINIMUM-DIAMETER

diameter_max#

Maximum diameter

RP66V1 name: MAXIMUM-DIAMETER

volume#

Volume

RP66V1 name: VOLUME

weight#

Weight

RP66V1 name: WEIGHT

hole_size#

Hole size

RP66V1 name: HOLE-SIZE

pressure#

Pressure

RP66V1 name: PRESSURE

temperature#

Temperature

RP66V1 name: TEMPERATURE

vertical_depth#

Vertical depth

RP66V1 name: VERTICAL-DEPTH

radial_drift#

Radial drift

RP66V1 name: RADIAL-DRIFT

angular_drift#

Angular drift

RP66V1 name: ANGULAR-DRIFT

See also

BasicObject

The basic object that Equipment is derived from

Notes

The Equipment object reflects the logical record type EQUIPMENT, defined in rp66. EQUIPMENT records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.8.3 - Static and Frame Data, EQUIPMENT objects.

attributes = {'ANGULAR-DRIFT': 2, 'HEIGHT': 2, 'HOLE-SIZE': 2, 'LENGTH': 2, 'LOCATION': 2, 'MAXIMUM-DIAMETER': 2, 'MINIMUM-DIAMETER': 2, 'PRESSURE': 2, 'RADIAL-DRIFT': 2, 'SERIAL-NUMBER': 2, 'STATUS': 1, 'TEMPERATURE': 2, 'TRADEMARK-NAME': 2, 'TYPE': 2, 'VERTICAL-DEPTH': 2, 'VOLUME': 2, 'WEIGHT': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Fileheader#

class dlisio.dlis.Fileheader(BasicObject)#

The Fileheader is an identifier for the Logical File. Below follows a description of the relationship between a DLIS-file, Logical File, File Set, and Storeage Set:

DLIS-file - single dlis-file may or may not consists of multiple logical files:

 ---------------------------------------
| Logical File 1 | ... | Logical File n |
 ---------------------------------------

Logical File - Each Logical File has exactly one Fileheader, but can have mutiple origins:

 ---------------------------------------------
| Fileheader | Origin | Frame | Channel | ... |
 ---------------------------------------------

File Set - A File set consists of multiple Logical Files which may spand across multiple DLIS-files. Logical Files are grouped into File Sets by producer defined criterias:

 ---------------------------------------
| Logical File 1 | ... | Logical File n |
 ---------------------------------------

Storage Set - A Storage Set consist of multiple DLIS-files. A Storage Set may or may not coincide with a File Set:

 ---------------------------------
| DLIS-file 1 | ... | DLIS-File n |
 ---------------------------------
sequencenr#

Sequential position of the logical file in a storage set

RP66V1 name: SEQUENCE-NUMBER

Type:

str

id#

Descriptive identification of the logical file

RP66V1 name: ID

Type:

str

See also

BasicObject

The basic object that Fileheader is derived from

Notes

The Fileheader object reflects the logical record type FILE-HEADER, defined in rp66. FILE-HEADER records are listed in Appendix A.2 - Logical Record Types and described in Chapter 5.1 - Static and Frame Data, File Header Logical Record (FHLR).

attributes = {'ID': 2, 'SEQUENCE-NUMBER': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Group#

class dlisio.dlis.Group(BasicObject)#

Group Objects indicate logical groupings of other Objects. A Group is defined by the producer by any associations deemed useful.

description#

RP66V1 name: DESCRIPTION

Type:

str

object_type#

Specifies the type of object that is referenced in the object list attribute.

RP66V1 name: OBJECT-TYPE

Type:

str

object_list#

References to arbitrary objects.

RP66V1 name: OBJECT-LIST

Type:

list

group_list#

Reference to other Group objects

RP66V1 name: GROUP-LIST

Type:

list(Group)

Notes

The Group object reflects the logical record type Group, defined in rp66. Group records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.8.8 - Static and Frame Data, Group objects.

attributes = {'DESCRIPTION': 2, 'GROUP-LIST': 3, 'OBJECT-LIST': 3, 'OBJECT-TYPE': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'GROUP-LIST': <function obname.<locals>.fingerprint>, 'OBJECT-LIST': <function objref>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Longname#

class dlisio.dlis.Longname(BasicObject)#

Structured names of other objects.

modifier#

General modifier

RP66V1 name: GENERAL-MODIFIER

Type:

list(str)

quantity#

Something that is measureable E.g. the diameter of a pipe

RP66V1 name: QUANTITY

Type:

str

quantity_mod#

Specialization of a quantity

RP66V1 name: QUANTITY-MODIFIER

Type:

list(str)

altered_form#

Altered form of the quantity. E.g. standard deviation is an altered form of a temperature quantity.

RP66V1 name: ALTERED-FORM

Type:

str

entity#

The entity of which the quantity is measured. E.g. entity = borehole, quantity = diameter

RP66V1 name: ENTITY

Type:

str

entity_mod#

Specialization of an entity

RP66V1 name: ENTITY-MODIFIER

Type:

list(str)

entity_nr#

Distinguishes multiple instances of the same entity

RP66V1 name: ENTITY-NUMBER

Type:

str

entity_part#

Part of an entity

RP66V1 name: ENTITY-PART

Type:

str

entity_part_nr#

Distinguishes multiple instances of the same entity part

RP66V1 name: ENTITY-PART-NUMBER

Type:

str

generic_source#

The source of the information

RP66V1 name: GENERIC-SOURCE

Type:

str

source_part#

A specific part of the source information. E.g. “transmitter”

RP66V1 name: SOURCE-PART

Type:

list(str)

source_part_nr#

Distinguishes multiple instances of the same source part

RP66V1 name: SOURCE-PART-NUMBER

Type:

list(str)

conditions#

Conditions applicable at the time the information was acquired or generated

RP66V1 name: CONDITIONS

Type:

list(str)

standard_symbol#

Industry-standardized symbolic name by which the information is known. The possible values are specified by POSC

RP66V1 name: STANDARD-SYMBOL

Type:

str

private_symbol#

Association between the recorded information and corresponding records or objects of the Producer’s internal or corporate database

RP66V1 name: PRIVATE-SYMBOL

Type:

str

See also

BasicObject

The basic object that Longname is derived from

Notes

The Longname object reflects the logical record type LONG-NAME, defined in rp66. LONG-NAME objects are listed in Appendix A.2 - Logical Record Types, and described in detail in Chapter 5.4.1 - Static and Frame Data, Long-Name Objects.

attributes = {'ALTERED-FORM': 2, 'CONDITIONS': 3, 'ENTITY': 2, 'ENTITY-MODIFIER': 3, 'ENTITY-NUMBER': 2, 'ENTITY-PART': 2, 'ENTITY-PART-NUMBER': 2, 'GENERAL-MODIFIER': 3, 'GENERIC-SOURCE': 2, 'PRIVATE-SYMBOL': 2, 'QUANTITY': 2, 'QUANTITY-MODIFIER': 3, 'SOURCE-PART': 3, 'SOURCE-PART-NUMBER': 3, 'STANDARD-SYMBOL': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Measurement#

class dlisio.dlis.Measurement(BasicObject)#

Records of measurements, references, and tolerances used to compute calibration coefficients.

phase#

In what phase of the overall job sequence the measurement as acquired

RP66V1 name: PHASE

Type:

str

source#

Source the measurement

RP66V1 name: MEASUREMENT-SOURCE

mtype#

Type of measurement

RP66V1 name: TYPE

Type:

str

dimension#

Structure of the sample array

RP66V1 name: DIMENSION

Type:

list(int)

axis#

Coordinate axis of the sample array

RP66V1 name: AXIS

Type:

list(Axis)

samplecount#

Number of samples used to compute the max/std_deviation

RP66V1 name: SAMPLE-COUNT

Type:

int

begin_time#

Time of the sample acquisition. Either an absolute time represented by datetime or elapsed time from file-creation (see Origin.creation_time).

RP66V1 name: BEGIN-TIME

duration#

Time duration of the sample acquisition

RP66V1 name: DURATION

standard#

Measurable quantity of the calibration standard used to produce the sample

RP66V1 name: STANDARD

See also

BasicObject

The basic object that Measurement derived from

Notes

The Measurement object reflects the logical record type CALIBRATION-MEASUREMENT, defined in rp66. CHANNEL records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.8.7.1 - Static and Frame Data, CALIBRATION-MEASUREMENT objects.

attributes = {'AXIS': 4, 'BEGIN-TIME': 2, 'DIMENSION': 4, 'DURATION': 2, 'MAXIMUM-DEVIATION': 3, 'MEASUREMENT': 3, 'MEASUREMENT-SOURCE': 2, 'MINUS-TOLERANCE': 3, 'PHASE': 2, 'PLUS-TOLERANCE': 3, 'REFERENCE': 3, 'SAMPLE-COUNT': 2, 'STANDARD': 3, 'STANDARD-DEVIATION': 3, 'TYPE': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'AXIS': <function obname.<locals>.fingerprint>, 'MEASUREMENT-SOURCE': <function objref>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

property max_deviation#

Maximum deviation

Only applicable when the sample attribute contains mean values. In that case, this is maximum deviation from the mean of any value used to compute the mean.

Each sample may be a scalar of ndarray, but should have the same structure as the samples in the sample attribute.

RP66V1 name: MAXIMUM-DEVIATION

property minus_tolerance#

The maximum value that any sample (in samples) can fall below the reference and still be ‘within tolerance’. Should be all non-negative numbers. If this attribute is empty, the minus tolerance is implicity infinite.

Each sample may be a scalar of ndarray, but should have the same structure as the samples in the sample attribute.

RP66V1 name: MINUS-TOLERANCE

property plus_tolerance#

The maximum value that any sample (in samples) can exceed the reference and still be ‘within tolerance’. Should be all non-negative numbers. If this attribute is empty, the plus tolerance is implicity infinite.

Each sample may be a scalar of ndarray, but should have the same structure as the samples in the sample attribute.

RP66V1 name: PLUS-TOLERANCE

property reference#

The nominal value of each sample in the samples attribute

Each sample may be a scalar of ndarray, but should have the same structure as the samples in the sample attribute.

RP66V1 name: REFERENCE

property samples#

Measurment samples

The type of measurment is described by the type attribute. Each sample may be either a scalar or ndarray

RP66V1 name: MEASUREMENT

property std_deviation#

Standard deviation

Only applicable when the sample attribute contains mean values. In that case, this is the standard deviation of the samples used to compute the mean.

Each sample may be a scalar of ndarray, but should have the same structure as the samples in the sample attribute.

RP66V1 name: STANDARD-DEVIATION

Message#

class dlisio.dlis.Message(BasicObject)#

Textual messages tied to other data by means of time and/or position of tool zero point when the message was recorded

message_type#

source and purpose of the message.

RP66V1 name: TYPE

Type:

str

time#

time the message was issued. Either an absolute time represented by datetime or elapsed time from file-creation (see Origin.creation_time).

RP66V1 name: TIME

borehole_drift#

borehole drift of the tool zero point when message was issued.

RP66V1 name: BOREHOLE-DRIFT

vertical_depth#

vertical depth of the tool zero point when message was issued.

RP66V1 name: VERTICAL-DEPTH

radial_drift#

radial drift of the tool zero point when message was issued.

RP66V1 name: RADIAL-DRIFT

angular_drift#

angular drift of the tool zero point when message was issued.

RP66V1 name: ANGULAR-DRIFT

text#

message(s).

RP66V1 name: TEXT

Type:

list(str)

See also

BasicObject

The basic object that Message is derived from

Notes

The Message object reflects the logical record type MESSAGE, described in rp66. MESSAGE objects are defined in Appendix A.2 - Logical Record Types, described in detail in Chapter 6.1.1 - Transient Data, message objects.

attributes = {'ANGULAR-DRIFT': 2, 'BOREHOLE-DRIFT': 2, 'RADIAL-DRIFT': 2, 'TEXT': 3, 'TIME': 2, 'TYPE': 2, 'VERTICAL-DEPTH': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

No Format#

class dlisio.dlis.Noformat(BasicObject)#

Noformat objects contain description of unformatted data present in files.

consumer_name#

Client-provided name for the data, for example an external file specification

RP66V1 name: CONSUMER-NAME

Type:

str

description#

Textual description

RP66V1 name: DESCRIPTION

Type:

str

See also

BasicObject

The basic object that Nofromat is derived from

Notes

The Noformat object reflects the logical record type NO-FORMAT, described in rp66. NO-FORMAT objects are defined in Appendix A.2 - Logical Record Types, described in detail in Chapter 5.10.1 Static and Frame Data, No-Format Objects.

attributes = {'CONSUMER-NAME': 2, 'DESCRIPTION': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

data()#

Raw data

A raw byte buffer of all the records corresponding to the noform-object. Content of this data is not defined by rp66v1. However, the name and description of the no-format object might give an indication about its content.

Returns:

data – Raw bytes

Return type:

bytes

Examples

Look at the description of the no-format object to see if it contains information about nature of the data

>>> print(noformat.describe())
---------
No-format
---------
name   : 2
origin : 0
copy   : 0
---
Consumer name : FILE
Description   : /home/files.txt

Save the data

>>> out = open('noformat.txt', 'wb')
>>> out.write(noformat.data())
>>> out.close()

It is not uncommon that the no-format object itself is not enough to understand its content. Some vendors store additional information in other custom object types. In that case some manual digging into the file might reveal the information necessary to correctly understand the no-format content:

>>> images = f.find('.*IMAGE.*', matcher=dlisio.dlis.utils.regex_matcher())
>>> for image in images:
>>>     print(image.describe())
---------
my_image
---------
name   : MYIMAGE
origin : 0
copy   : 0
---
Unknown attributes
--
NAME          : MYIMAGE.PNG
NOFORMAT-NAME : dlisio.core.obname(id='MYIMAGE', origin=0, copynum=0)

Check for no-format records:

>>> for noformat in f.noformats:
>>>     print(noformat.describe())
---------
No-format
---------
name   : NOFORMAT-MYIMAGE
origin : 0
copy   : 0
---
Consumer name : MYIMAGE
Description   : My very important image

Store the result:

>>> noformat = f.object("NO-FORMAT", "NOFORMAT-MYIMAGE")
>>> out = open('MYIMAGE.PNG', 'wb')
>>> out.write(noformat.data())
>>> out.close()

Origin#

class dlisio.dlis.Origin(BasicObject)#

Describes the creation of the logical file.

Origin objects is an unique indentifier for a Logical File and it describes the circumstances under which the file was created. The Origin object also spesify the Logical File’s relation to a DLIS-file and to which Logical Set it belongs.

A logical file may have several Origin objects, whereas the first Origin object is the Defining object. No two logical files should have identical Defining Origins.

file_id#

An exact copy of Fileheader.id

RP66V1 name: FILE-ID

Type:

str

file_set_name#

The name of the File Set that the Logical File is a part of

RP66V1 name: FILE-SET-NAME

Type:

str

file_set_nr#

The number of the File Set that the Logical File is a part of

RP66V1 name: FILE-SET-NUMBER

Type:

int

file_nr#

The file number of the Logical File within a File Set

RP66V1 name: FILE-NUMBER

Type:

int

file_type#

A producer spesified File-Type that signifies the content of the DLIS-file

RP66V1 name: FILE-TYPE

Type:

str

product#

Name of the software product that produced the DLIS-file

RP66V1 name: PRODUCT

Type:

str

version#

The version of the software product that created the DLIS-file

RP66V1 name: VERSION

Type:

str

programs#

Other programs and services that was a part of the software that created the DLIS-file

RP66V1 name: PROGRAMS

Type:

list(str)

creation_time#

Date and time at which the DLIS-File was created

RP66V1 name: CREATION-TIME

Type:

datetime

order_nr#

An unique accounting number assosiated with the creation of the DLIS-File

RP66V1 name: ORDER-NUMBER

Type:

str

descent_nr#

The meaning of this number must be obtained directly from the producer

RP66V1 name: DESCENT-NUMBER

run_nr#

The meaning of this number must be obtained directly from the company

RP66V1 name: RUN-NUMBER

well_id#

Id of the well at which the measurements where acquired

RP66V1 name: WELL-ID

well_name#

Name of the well at which the measurements where acquired

RP66V1 name: WELL-NAME

Type:

str

field_name#

The field to which the well belongs

RP66V1 name: FIELD-NAME

Type:

str

producer_code#

The producer’s identifying code

RP66V1 name: PRODUCER-CODE

Type:

int

producer_name#

The producer’s name

RP66V1 name: PRODUCER-NAME

Type:

str

company#

The name of the client company which the log was produced for

RP66V1 name: COMPANY

Type:

str

namespace_name#

(DLIS internal) A producer-defined namespace for which the object names for this origin are defined under

RP66V1 name: NAME-SPACE-NAME

Type:

str

namespace_version#

(DLIS internal) The version of the namespace.

RP66V1 name: NAME-SPACE-VERSION

Type:

int

See also

BasicObject

The basic object that Origin is derived from

Fileheader

Fileheader

Notes

The Origin object reflects the logical record type ORIGIN, defined in rp66. ORIGIN records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.1 - Static and Frame Data, Origin objects.

attributes = {'COMPANY': 2, 'CREATION-TIME': 2, 'DESCENT-NUMBER': 3, 'FIELD-NAME': 2, 'FILE-ID': 2, 'FILE-NUMBER': 2, 'FILE-SET-NAME': 2, 'FILE-SET-NUMBER': 2, 'FILE-TYPE': 2, 'NAME-SPACE-NAME': 2, 'NAME-SPACE-VERSION': 2, 'ORDER-NUMBER': 2, 'PRODUCER-CODE': 2, 'PRODUCER-NAME': 2, 'PRODUCT': 2, 'PROGRAMS': 3, 'RUN-NUMBER': 3, 'VERSION': 2, 'WELL-ID': 2, 'WELL-NAME': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Parameter#

class dlisio.dlis.Parameter(BasicObject)#

Parameter

A parameter object describes a parameter used in the acquisition and processing of data. The parameter value(s) may be scalars or an array. In the later case, the structure of the array is defined in the dimension attribute. The zones attribute specifies which zones the parameter is defined. If there are no zones the parameter is defined everywhere.

The axis attribute, if present, defines axis labels for multidimensional value(s).

long_name#

Descriptive name of the channel.

RP66V1 name: LONG-NAME

Type:

Longname

dimension#

Dimensions of the parameter values

RP66V1 name: DIMENSION

Type:

list(int)

axis#

Coordinate axes of the parameter values

RP66V1 name: AXIS

Type:

list(Axis)

zones#

Mutually disjoint intervals where the parameter values is constant

RP66V1 name: ZONES

Type:

list(Zone)

See also

BasicObject

The basic object that Parameter is derived from

Notes

The Parameter object reflects the logical record type PARAMETER, described in rp66. PARAMETER objects are defined in Appendix A.2 - Logical Record Types, described in detail in Chapter 5.8.2 - Static and Frame Data, PARAMETER objects.

attributes = {'AXIS': 4, 'DIMENSION': 4, 'LONG-NAME': 2, 'VALUES': 3, 'ZONES': 3}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'AXIS': <function obname.<locals>.fingerprint>, 'LONG-NAME': <function obname.<locals>.fingerprint>, 'ZONES': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

property values#

Parameter values

Parameter value(s) may be scalar or array’s. The size/dimensionallity of each value is defined in the dimensions attribute.

Each value may or may not be zoned, i.e. it is only defined in a certain zone. If this is the case the first zone, parameter.zones[0], will correspond to the first value, parameter.values[0] and so on. If there is no zones, there should only be one value, which is said to be unzoned, i.e. it is defined everywere.

RP66V1 name: VALUES

Raises:

ValueError – Unable to structure the values based on the information available.

Returns:

values

Return type:

structured np.ndarray

Notes

If dlisio is unable to structure the values due to insufficient or contradictory information in the object, an ValueError is raised. The raw array can still be accessed through attic, but note that in this case, the semantic meaning of the array is undefined.

Examples

First value:

>>> parameter.values[0]
[10, 20, 30]

Zone (if any) where that parameter value is valid:

>>> parameter.zones[0]
Zone('ZONE-A')

Path#

class dlisio.dlis.Path(BasicObject)#

Path Objects defines Channels in the Data Frames of a given Frame Type and are combined to define part or all of a Data Path, and variation in the alignment.

frame_type#

The frame in which the channel’s of the current path are recorded.

RP66V1 name: FRAME-TYPE

Type:

Frame

well_reference_point#

Well Reference Point

RP66V1 name: WELL-REFERENCE-POINT

Type:

Wellref

value#

Value Channel for the current Path.

RP66V1 name: VALUE

Type:

list(Channel)

borehole_depth#

Specifies the constant Borehole Depth coordinate for the current Path, It may or may not be described by a channel object.

RP66V1 name: BOREHOLE-DEPTH

vertical_depth#

Specifies the constant Vertical Depth coordinate for the current Path, It may or may not be described by a channel object.

RP66V1 name: VERTICAL-DEPTH

radial_drift#

Specifies the constant Radial Drift coordinate for the current Path, It may or may not be described by a channel object.

RP66V1 name: RADIAL-DRIFT

angular_drift#

Specifies the constant Angular Drift coordinate for the current Path, It may or may not be described by a channel object.

RP66V1 name: ANGULAR-DRIFT

time#

Specifies the constant Time coordinate for the current Path, It may or may not be described by a channel object. Either an absolute time represented by datetime or elapsed time from file-creation (see Origin.creation_time).

RP66V1 name: TIME

depth_offset#

Specifies the Depth Offset, which indicates how much the value is “off depth”.

RP66V1 name: DEPTH-OFFSET

measure_point_offset#

Specifies a Measure Point Offset, which indicates a fixed distance along Borehole Depth from the Value Channel’s Measure Point to a Data Reference Point.

RP66V1 name: MEASURE-POINT-OFFSET

tool_zero_offset#

Distance of the Data Reference Point for the current Path above the tool string’s Tool Zero Point.

RP66V1 name: TOOL-ZERO-OFFSET

See also

BasicObject

The basic object that Parameter is derived from

Notes

The Path object reflects the logical record type PATH, defined in rp66. PATH records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.7.2 - Static and Frame Data, PATH objects.

attributes = {'ANGULAR-DRIFT': 2, 'BOREHOLE-DEPTH': 2, 'DEPTH-OFFSET': 2, 'FRAME-TYPE': 2, 'MEASURE-POINT-OFFSET': 2, 'RADIAL-DRIFT': 2, 'TIME': 2, 'TOOL-ZERO-OFFSET': 2, 'VALUE': 3, 'VERTICAL-DEPTH': 2, 'WELL-REFERENCE-POINT': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'ANGULAR-DRIFT': <function obname.<locals>.fingerprint>, 'BOREHOLE-DEPTH': <function obname.<locals>.fingerprint>, 'FRAME-TYPE': <function obname.<locals>.fingerprint>, 'RADIAL-DRIFT': <function obname.<locals>.fingerprint>, 'TIME': <function obname.<locals>.fingerprint>, 'VALUE': <function obname.<locals>.fingerprint>, 'VERTICAL-DEPTH': <function obname.<locals>.fingerprint>, 'WELL-REFERENCE-POINT': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Process#

class dlisio.dlis.Process(BasicObject)#

Process objects describes a specific process or computation applied to input objects to get output objects.

description#

RP66V1 name: DESCRIPTION

Type:

str

trademark_name#

Trademark name refers to the process and its products.

RP66V1 name: TRADEMARK-NAME

Type:

str

version#

Software version.

RP66V1 name: VERSION

Type:

str

properties#

Properties that applies to the output of the process, as a result of the process.

RP66V1 name: PROPERTIES

Type:

list(str)

status#

Indicated the status of the process. It’s typically updated to indicate when the process is completed or aborted.

RP66V1 name: STATUS

Type:

str

input_channels#

Channels that are used directly by this Process.

RP66V1 name: INPUT-CHANNELS

Type:

list(Channel)

output_channels#

Channels that are produced directly by this Process.

RP66V1 name: OUTPUT-CHANNELS

Type:

list(Channel)

input_computations#

Computations that are used directly by this Process.

RP66V1 name: INPUT-COMPUTATIONS

Type:

list(Computation)

output_computations#

Computations that are produced directly by this Process.

RP66V1 name: OUTPUT-COMPUTATIONS

Type:

list(Computation)

parameters#

Parameters that are used by the Process or that directly affect the operation of the Process.

RP66V1 name: PARAMETERS

Type:

list(Parameter)

comments#

Comments contains information specific to the particular execution of the process.

RP66V1 name: COMMENTS

Type:

list(str)

See also

BasicObject

The basic object that Parameter is derived from

Notes

The Process object reflects the logical record type Process, defined in rp66. PROCESS records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.8.5 - Static and Frame Data, Process objects.

attributes = {'COMMENTS': 3, 'DESCRIPTION': 2, 'INPUT-CHANNELS': 3, 'INPUT-COMPUTATIONS': 3, 'OUTPUT-CHANNELS': 3, 'OUTPUT-COMPUTATIONS': 3, 'PARAMETERS': 3, 'PROPERTIES': 3, 'STATUS': 2, 'TRADEMARK-NAME': 2, 'VERSION': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'DESCRIPTION': <function obname.<locals>.fingerprint>, 'INPUT-CHANNELS': <function obname.<locals>.fingerprint>, 'INPUT-COMPUTATIONS': <function obname.<locals>.fingerprint>, 'OUTPUT-CHANNELS': <function obname.<locals>.fingerprint>, 'OUTPUT-COMPUTATIONS': <function obname.<locals>.fingerprint>, 'PARAMETERS': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Splice#

class dlisio.dlis.Splice(BasicObject)#

Splice describes the process of concatinating multiple channels into one. The concatination is defined by the zone objects, where the first zone object corresponds to the first input channel and so on. The zones must be mutually disjoint but the ordering is arbitrary:

Input Ch 1    input Ch 2  -> Output
-----------------------------------------------
    |            |             |
    |           |              |         Zone1
    |          |               |
-----------------------------------------------
    |         |               None
-----------------------------------------------
    |           |               |
    |            |               |       Zone2
    |             |               |
-----------------------------------------------
output_channel#

Concatenation of all input channels

RP66V1 name: OUTPUT-CHANNELS

Type:

Channel

input_channels#

Channels that where used to create the output channel

RP66V1 name: INPUT-CHANNELS

Type:

list(Channel)

zones#

Zones of each input channel that is used in the concatination process

RP66V1 name: ZONES

Type:

list(Zone)

See also

BasicObject

The basic object that Splice is derived from

Notes

The Splice object reflects the logical record type SPLICE, defined in rp66. SPLICE records are listed in Appendix A.2 - Logical Record Types and described in detail in Chapter 5.8.9 - Static and Frame Data, SPLICE objects.

attributes = {'INPUT-CHANNELS': 3, 'OUTPUT-CHANNEL': 2, 'ZONES': 3}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'INPUT-CHANNELS': <function obname.<locals>.fingerprint>, 'OUTPUT-CHANNEL': <function obname.<locals>.fingerprint>, 'ZONES': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Tool#

class dlisio.dlis.Tool(BasicObject)#

A tool is an ensembly of equiptment that as a whole provide measurements or services. The list of equiptment that makes up the tool can be found in tool.parts. Tools objects also keep a list of all channels that where produced by the tool in tool.channels.

description#

Textual description of the tool

RP66V1 name: DESCRIPTION

Type:

str

trademark_name#

The producer’s name for the tool

RP66V1 name: TRADEMARK-NAME

Type:

str

generic_name#

The name generally used by the industry to describe such a tool

RP66V1 name: GENERIC-NAME

Type:

str

status#

If the tool is enabled to provide information to the acquisition system

RP66V1 name: STATUS

Type:

bool

parts#

Equipments that makes up the tool

RP66V1 name: PARTS

Type:

list(Equipment)

channels#

Channels that are produced by this tool

RP66V1 name: CHANNELS

Type:

list(Channel)

parameters#

Parameters that directly affect or reflect the operation of the tool

RP66V1 name: PARAMETERS

Type:

list(Parameter)

See also

BasicObject

The basic object that Tool is derived from

Notes

The tool object reflects the logical record type TOOL defined in rp66. TOOL objects are listed in Appendix A.2 - Logical Record Types, described in detail in Chapter 5.8.4 - Static and Frame Data, TOOL objects.

attributes = {'CHANNELS': 3, 'DESCRIPTION': 2, 'GENERIC-NAME': 2, 'PARAMETERS': 3, 'PARTS': 3, 'STATUS': 1, 'TRADEMARK-NAME': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

linkage = {'CHANNELS': <function obname.<locals>.fingerprint>, 'PARAMETERS': <function obname.<locals>.fingerprint>, 'PARTS': <function obname.<locals>.fingerprint>}#

Defines which attributes contain references to other objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

Object-to-object references often contains implicit information. E.g. Frame.channels implicitly reference Channel object, so the type ‘CHANNEL’ is not specified in the file. Hence dlisio needs to be told about this.

Like for attributes, this behavior is customizable.

Examples

Change how dlisio parses Channel.source:

>>> from dlisio.dlis.utils import obname
>>> Channel.linkage['SOURCE'] = obname('PARAMETER')
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('channel', 'TDEP')
...     ch.source
Parameter('2000T')

The same can be achieved for a _specific_ object. Forcing a copy of the linkage-dict makes sure your changes only apply to that specific object:

>>> ch = f.object('channel', 'TDEP')
>>> ch.linkage = dict(ch.linkage)
>>> ch.linkage['SOURCE'] = dlisio.plumbing.parse.obname('PARAMETER')
>>> ch.source
Parameter('2000T')
Type:

dict

Wellref#

class dlisio.dlis.Wellref(BasicObject)#

Well reference defines origin of well with coordinates.

permanent_datum#

Level from where vertical distance is measured

RP66V1 name: PERMANENT-DATUM

Type:

str

vertical_zero#

Vertical zero is an entity that corresponds to zero depth.

RP66V1 name: VERTICAL-ZERO

Type:

str

permanent_datum_elevation#

Permanent datum, structure or entity from which the vertical distance can be measured.

RP66V1 name: PERMANENT-DATUM-ELEVATION

above_permanent_datum#

Distance of permanent Datum above mean sea level. Negative values indicates that the Permanent datum is below mean sea level

RP66V1 name: ABOVE-PERMANENT-DATUM

magnetic_declination#

Angle between the line of direction to geographic north and the line of direction to magnetic north. This defines angle with vertex at well reference point.

RP66V1 name: MAGNETIC-DECLINATION

coordinate#

Independent spatial coordinates. Typically, latitude, longitude and elevation

RP66V1 names: COORDINATE-1-NAME, COORDINATE-1-VALUE, COORDINATE-2-NAME, COORDINATE-2-VALUE, COORDINATE-3-NAME, COORDINATE-3-VALUE

Type:

dict

See also

BasicObject

The basic object that Wellref is derived from

Notes

The Well Reference object reflects the well reference point of a well, defined in rp66. Well reference records are listed in Appendix A.2 - Logical Record Types are described in detail in Chapter 5.2.2 - Static and Frame Data, Well reference objects.

attributes = {'ABOVE-PERMANENT-DATUM': 2, 'COORDINATE-1-NAME': 2, 'COORDINATE-1-VALUE': 2, 'COORDINATE-2-NAME': 2, 'COORDINATE-2-VALUE': 2, 'COORDINATE-3-NAME': 2, 'COORDINATE-3-VALUE': 2, 'MAGNETIC-DECLINATION': 2, 'PERMANENT-DATUM': 2, 'PERMANENT-DATUM-ELEVATION': 2, 'VERTICAL-ZERO': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Zone#

class dlisio.dlis.Zone(BasicObject)#

A Zone objects specifies a single interval in depth or time. Other objects use zones to define spesific regions in wells or time intervals where the object data is valid.

description#

Description of the zone

RP66V1 name: DESCRIPTION

Type:

str

domain#

Type of interval, e.g. borhole-depth, time or vertical-depth

RP66V1 name: DOMAIN

Type:

str

maximum#

Latest time or deepest point, not inclusive

RP66V1 name: MAXIMUM

minimum#

Earliest time or shallowest point, inclusive

RP66V1 name: MINIMUM

See also

BasicObject

The basic object that Zone is derived from

Notes

The Zone object reflects the logical record type ZONE, defined in rp66. ZONE objects are listed in Appendix A.2 - Logical Record Types, and described in detail in Chapter 5.8.1 - Static and Frame Data, Zone Objects.

attributes = {'DESCRIPTION': 2, 'DOMAIN': 2, 'MAXIMUM': 2, 'MINIMUM': 2}#

Parsing guide for native dlis objects. The typical user can safely ignore this attribute. It is mainly intended for internal use and advanced customization of dlisio’s parsing routine.

In short, this dictionary tells dlisio parse each attribute for a given object. By default it implements rules defined by the dlis-spec. However it can easily be customized if you’d like dlisio to parse your file in a different way.

Examples

Lets take a look at Channel.attributes, it looks like this:

attributes = {
    'LONG-NAME'          : scalar,
    'REPRESENTATION-CODE': scalar,
    'UNITS'              : scalar,
    'PROPERTIES'         : vector,
    'DIMENSION'          : reverse,
    'AXIS'               : reverse,
    'ELEMENT-LIMIT'      : reverse,
    'SOURCE'             : scalar,
}

The keys are from the dlis-spec, i.e. this is how the attributes of a CHANNEL-object are named in the file. The values tells dlisio how to interpret these keys. In the dlis-spec it’s defined that ‘UNITS’ only contains a single value. This is communicated to dlisio with the ‘scalar’-keyword. I.e. Channels __getitem__ will return a single value:

>>> channel['UNITS']
'm/s'

The __getitem__ is not intended for direct use. However it is called internally from all properties of the Channel-object. I.e. you observe the same here:

>>> channel.units
'm/s'

The following example might be a bit absurd, but keep in mind that this approach can be applied to _any_ attribute of _any_ object-type, even Unknown object-types.

But now let’s say that you are in possession of a file that you know is structured differently from what the standard specifies. It contains some weird Channel’s where there are multiple units per Channel. Simply update the attribute-dict before loading the file and dlisio will parse ‘UNITS’ as a list:

>>> from dlisio.dlis.utils import vector
>>> Channel.attributes['UNITS'] = vector
>>> with dlisio.dlis.load('file.dlis') as (f, *_):
...     ch = f.object('CHANNEL', 'TDEP')
...     ch.units
['m/s', 'rad/s']

The same can be achieved for a _specific_ object. Forcing a copy of the attribute-dict for a given object before altering it makes sure your changes only apply _that_ object

>>> ch = f.object('CHANNEL', 'TDEP')
>>> ch.attributes = dict(ch.attributes)
>>> Channel.attributes['UNITS'] = vector
>>> ch.units
['m/s', 'rad/s']

References

[1] http://w3.energistics.org/RP66/V1/Toc/main.html

Type:

dict

Unknown#

class dlisio.dlis.Unknown(BasicObject)#

The unknown object is intended as a fall-back object if the object-type is not recognized by dlisio, e.g. vendor spesific object types

See also

BasicObject

The basic object that Unknown is derived from