Skip to content

Fault sticks and seismic volumes

Two more kinds of subsurface data upload beside logs, tops and surfaces. Both keep their exact original bytes and share, revoke and read like every other upload.

Type File What is kept
Fault sticks OpendTect fault-stick text: one point per line, x y z stick-number (an optional fifth node number is ignored); # comments allowed every stick in the order it first appears, every point in file order, stick numbers as written
Seismic volume SEG-Y revision 1 or 2, big-endian, IBM (format 1) or IEEE (format 5) 4-byte samples, one trace length, a full inline × crossline grid with evenly spaced line numbers the file byte for byte; each inline’s samples as a verified chunk

You declare what the file cannot say: the coordinate system (an EPSG code or “not known”), units and, for a volume, whether samples are time or depth. Nothing you leave empty is guessed.

The reader records every decision it makes and shows them under How the file was read: the textual header’s encoding, the sample interval and how it was interpreted, the sample format, the trace-header byte positions used for inline, crossline and CDP x/y (the SEG-Y revision 1 standard positions 189, 193, 181 and 185), the coordinate scalar and the start time. Traces may be stored in any order; the inline and crossline numbers in the trace headers decide where a trace belongs. A file is refused — and nothing is stored — when traces have different lengths, sample counts or start times, when a position repeats, when the grid is incomplete or unevenly spaced, when an IEEE sample is not a finite number, or when the format is not 1 or 5.

Open a seismic volume to see its grid and sample meaning, then choose Inline, Crossline or Time or depth slice and a line or time. The section is drawn in grey scale, symmetric around zero; nothing is interpolated or resampled. Click a sample or move with the arrow keys: the readout gives the inline, crossline, time or depth and the exact value from the file. Only the chunks holding that section are read on the server, so a section of a large volume costs the same as one of a small volume. A section that does not match its volume, or arrives damaged, is refused and nothing is drawn.

Fault sticks are drawn in plan view (north up); the arrow keys step through the sticks and list their points.

from ophiolite import Client
client = Client.from_configuration("configuration.json")
volume = client.read_data(asset, revision) # the description, not the volume
section = client.read_slice(asset, revision, "inline", 1204, volume=volume)
section.value_at(335, 1500.0) # crossline 335 at 1500 ms
array = section.to_numpy()
bundle = client.export_slices(asset, revision, [("inline", 1204), ("sample", 250)], "slices")

read_slice checks each slice against the volume’s description — asset and revision, direction, axes, sample meaning, shape and the chunks it came from — so a slice cannot be mistaken for another. label is the inline or crossline number from the trace headers, or the sample number counted from 0 for a time or depth slice.

export_slices writes a portable bundle 2.3: the volume’s descriptor and description and each chosen slice exactly as served. The original volume is not included; the bundle names it by its SHA-256 (the revision) and says so. open_bundle checks every slice against the description without a server, the Connectors package or a network. A bundle reader from before 2.3 refuses these bundles; bundles without fault sticks or slices keep their older version. Fault sticks export with export like the other types, original included.

These are pilot readers tested with synthetic files: no NLOG or owner volume with established rights has been read yet, and a round trip through the OpendTect application itself has not been checked (the writer reproduces the geometry of the text format, not its spacing or comments). Little-endian files, variable-length traces, other sample formats, irregular grids, full-volume export, CRS transformation and interpretation tools (horizon or fault picking, attributes) are not included. Uploads are limited by the deployment’s upload limit (at most 32 MiB).