Every E&P shop that runs Schlumberger's Petrel has the same quiet problem, and most of them have made peace with it without noticing. Years of seismic interpretation, well correlations, structural models, and reservoir grids live inside a project format — the .pet file and its companion .ptd folder — that is binary, undocumented, and explicitly not meant to be read by anything but Petrel. Your most valuable subsurface knowledge is real, and it is also, in a meaningful sense, trapped in a container you don't control.

That's not a complaint about Petrel as a tool. Petrel is genuinely excellent at what it does — seismic interpretation, geological modeling, the connection into INTERSECT and ECLIPSE for simulation. The problem isn't the application. It's that the project storage is a one-vendor box, and "your data" turns out to mean "your data, as long as you keep paying for the one program that can open it."

Here's the part most people miss: you don't have to crack that box to get out of it. The data inside it already speaks open standards on the way in and out. You can build an open, vendor-neutral home for your subsurface data fed entirely by Petrel's own lawful export functions — without ever decoding a single proprietary byte. This is how.

The lock-in is the project format, not the data

The key insight is a separation most discussions blur: a Petrel project is a proprietary container holding data types that are, individually, mostly open standards.

The container — .pet, the .ptd data folder, the .bak backups, the .lock sentinel — is undocumented binary. There is no public spec; the community consensus is that you are simply "not supposed to read those files directly," and the internal layout can change between versions without notice. Treat it as a black box. Trying to reverse-engineer it is legally fraught and technically brittle, and — this is the important part — completely unnecessary.

Because the moment you ask Petrel to export, the data comes out in formats the whole industry already documents and shares:

  • Seismic → SEG-Y, the decades-old industry standard for 2D/3D traces and headers, which Petrel treats as its standard seismic exchange format. For fast random access there's ZGY, Petrel's compressed seismic format — and critically, OpenZGY is now an open-source implementation contributed into the OSDU ecosystem, which means ZGY is effectively a documented, open format today.
  • Wells → LAS (2.0/3.0) for logs, DLIS for binary log data, and ASCII for well heads and deviation surveys. For trajectories, markers, and completions there's WITSML, the Energistics XML standard adopted into OSDU.
  • Grids and reservoir models → RESQML (v2.x), the Energistics XML+HDF5 standard for structured grids, depogrids, properties, and structural frameworks. Petrel exports structured grids and depogrids to RESQML as part of its INTERSECT workflows.
  • Simulation → ECLIPSE / INTERSECT decks, which are text-based and, despite their SLB origin, exhaustively documented and read by dozens of third-party tools.
  • Surfaces, production, metadata → ZMAP and VTK meshes for horizons and faults; CSV/Parquet for production and properties; OSDU-style JSON and Energistics EPC packaging for the catalog layer.

So the honest framing isn't "decode Petrel." It's "let Petrel hand you the data through its own front door, and give that data an open home it can never be locked out of again."

This distinction — exports, not internals — is also what keeps the whole effort on defensible legal ground, and it's worth being explicit about the line. (What follows is the engineering rationale, not legal advice; anyone actually doing this should get jurisdiction-specific counsel.)

The defensible zone is built on a simple rule: use lawful exports and open standards; never touch proprietary internals or protections.

Safe to build on Stay away from
Petrel's official SEG-Y / LAS / RESQML / ZGY / ASCII exports Parsing .pet / .ptd internal structure
Published open-standard specs (SEG-Y, LAS, RESQML, OpenZGY) Decompiling Petrel binaries to infer formats
Public OSDU / Energistics schemas Leaked or confidential vendor documentation
Your own schema and object names Copying Petrel's internal object names
Black-box comparison of exported output Bypassing any license check or encryption

The reason this matters beyond compliance: a project built on this boundary is durable. It doesn't depend on a fragile guess about an undocumented binary that breaks at the next Petrel release. It depends on SEG-Y and RESQML and LAS — standards that have outlived multiple software generations and will outlive this one. The legal-safe path and the engineering-robust path are, conveniently, the same path.

The architecture: a manifest, not a monolith

The heart of the design is a reframe of what a "project" even is. Petrel makes a project a single proprietary binary file that owns everything. The open alternative makes a project a manifest — a plain-text description that references open data files sitting in open formats.

A project becomes a small, human-readable YAML file:

project:
  id: grane-open-001
  name: Grane Open Subsurface Project
  version: 0.1.0
  crs:
    horizontal: EPSG:23031
    vertical_datum: MSL
    depth_unit: m
  datasets:
    seismic:
      - id: seismic-main-3d
        format: zgy
        path: seismic/main_3d.zgy
    wells:
      - id: well-15-9-f-1
        path: wells/15_9_F_1/
    grids:
      - id: static-grid-v1
        format: resqml
        path: models/static_grid_v1.epc

That manifest is the open substitute for .pet. Everything else hangs off it in four layers:

  1. Storage layer (open formats only). Seismic as SEG-Y plus ZGY/OpenZGY for fast access; wells as LAS plus WITSML/RESQML; grids and properties as RESQML EPC packages; tabular data as CSV/Parquet. Nothing proprietary touches disk.
  2. Metadata and catalog layer. An OSDU-inspired set of JSON records — projects, datasets, wellbores, seismic surveys, grid models — each pointing at the underlying files by URI, carrying CRS, units, and provenance. This is where "a project" actually lives as a logical aggregation.
  3. APIs and services. REST/GraphQL over the domain objects, plus conversion services that ingest the Petrel exports using mature open libraries — segyio for SEG-Y, lasio for LAS, resqpy for RESQML, OpenZGY for ZGY, xtgeo for grids and surfaces.
  4. Application layer. Open viewers and modeling tools — ResInsight (which already reads ZGY and VDS), ParaView/VTK, GemPy — consuming the canonical store, fully decoupled from Petrel.

The migration pipeline is a straight line, and every arrow is a lawful, documented step:

Petrel official export  →  open exchange files (SEG-Y/ZGY/LAS/RESQML/CSV)
   →  validation & normalization  →  canonical open manifest
   →  open data lake / Git repo / object store  →  open viewers, Python APIs, OSDU-style services

The .pet/.ptd originals get kept as archival artifacts only — the source you exported from, never something you parse.

The honest caveats

This is the part the pitch decks skip, and skipping it is how these projects lose credibility. An open canonical store is a real win, but it is not a free lunch, and it is not literally "replacing Petrel."

  • You're freeing the data, not replicating the application. Petrel's value is the integrated interpretation workflow — the seismic-to-simulation loop in one environment. An open store gives you portable, ownable data; it does not give you Petrel's interpretation UX. For many shops that's exactly the right trade (the data is the asset, the interpretation can happen in several tools), but be honest that you're decoupling storage, not cloning the program.
  • Export fidelity has edges. Round-tripping through open formats is excellent but not bit-perfect. RESQML captures grid geometry and properties well; some Petrel-specific interpretation niceties, workflow state, and derived objects don't have a clean open analog. Validate what survives the export, and document what doesn't.
  • It's integration work, not invention. Every component here exists — the formats, the libraries, the OSDU schemas. The effort is the gluing: the manifest spec, the ingest-and-validate pipeline, the CRS and unit reconciliation, the provenance tracking. That's real engineering, but it's assembly of mature parts, which is exactly why it's achievable for a normal-sized team.
  • Validation is the whole game. Garbage exported is garbage stored. The unglamorous core of this is a validation engine: CRS consistency, unit consistency, well-log depth ranges, seismic bounds, grid-property dimensions, missing provenance, duplicate IDs. Skip it and you've built a faster way to lose track of your data.

None of these kill the idea. They scope it. The claim isn't "throw Petrel away tomorrow." It's "stop letting your decades of subsurface work live somewhere only one vendor can reach."

Why this is the same fight, on a bigger asset

Long-time readers of this blog will recognize the shape. We've argued, over and over, that oil and gas has mature physics and immature plumbing — that the value leaks out in the gap between the engineering and the data layer. We've made that case for decline curves, for PVT, for the reserves workflow, for the open lakehouse. Subsurface project storage is the same argument applied to the single largest, stickiest, most expensive data asset an E&P owns: the interpreted subsurface itself.

It's also the same argument the capital side is making with its checkbook. When Blackstone buys Enverus and the smart money concentrates in the energy data layer, it's confirming that the durable value in oil and gas is migrating to who owns and controls the data. The corollary for an operator is uncomfortable but clear: if your subsurface knowledge only exists inside a vendor's project format, you don't fully own your most important asset. You're renting access to it.

Where this connects to what we build

This is precisely the kind of thing Workollab exists to build: ownable, open, inspectable subsurface tooling that runs on your infrastructure and frees your data from a single-vendor container — without ever reverse-engineering a proprietary format or crossing a clean-room line. An open project manifest, a lawful export-and-ingest pipeline over SEG-Y / LAS / RESQML / ZGY, a validation engine that catches what the export broke, and a canonical store the operator owns outright. Not to replace the interpreter's favorite tool, but to make sure that when the license lapses, the vendor pivots, or the renewal price jumps, the operator's decades of subsurface work are still theirs — readable, portable, and built on standards that don't expire.

Your seismic, your wells, your models, your interpretation. The least the storage can do is let you keep them in a box you actually own.

A note on naming and framing, since this is the kind of project that invites it: anything built this way should be described as an open subsurface data framework that organizes data exported through lawful open formats — and should make explicit that it does not read, decode, or depend on any proprietary project internals. That framing isn't just good manners; it's what keeps the project defensible.

Sources

This article is general technical and industry commentary. It is not legal advice. Reverse-engineering, interoperability, and software-license questions turn on the specific EULA and your jurisdiction — obtain qualified legal counsel before acting. One of Workollab's oil & gas engineering pieces; related reading covers the open-source reservoir-engineering stack and the open lakehouse for oil & gas.

Need help operating this kind of stack securely in production? Explore secure cloud architecture for energy data.