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
anddlisio.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:
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
anddlisio.dlis.Channel
). There is also an abundance of object-types for storing other metadata: Tool, Parameter, Measurement and Calibration to name a few.object()
andfind()
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()
orLogicalFile.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 withcache_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()
andfind()
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:
- 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 withcurves
.- description#
Textual description of the Frame.
RP66V1 name: DESCRIPTION
- Type:
str
- 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
. Seedtype
. 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 andcurves()
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.- 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)
- 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
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
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
- 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).
- 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)
- 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
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)
- 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).
- dimension#
Dimensions of the parameter values
RP66V1 name: DIMENSION
- Type:
list(int)
- 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:
- 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 | | | -----------------------------------------------
- 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
- 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