Start here
A reservoir simulator is a computer model of an underground oil or gas field. It estimates how pressure and fluids change when wells produce or inject.
Think of the field as a sealed box of rock with tiny connected pores. The simulator divides that box into cells and tracks how much oil, water and gas are in each cell, and how they move when a well is opened. The result is a production forecast: how much hydrocarbon may flow, and when.
haql-engine is a from-scratch simulator built to be inspected. It is deliberately smaller than a commercial full-field package, so its physics, assumptions and outputs can be checked line by line.
The short version: it helps you test whether a production forecast is physically consistent, reproducible, and honest about uncertainty — and it shows the evidence instead of asking you to trust a black box.
Understand the idea
Read this page in order. You do not need to know the software or the petroleum-engineering vocabulary before you start.
Inspect the detail
The technical reference covers the numerical method, file structure, commands and test evidence.
Judge the claim
Go straight to the evidence and the limits. Both are part of the product, not footnotes.
Why it exists
Production forecasts influence expensive decisions. Yet a forecast can look precise while resting on assumptions that are hidden, stale or simply wrong.
Four problems are common:
- One model hides uncertainty. A single “best estimate” can look more certain than the science allows.
- Inputs and settings get lost. Months later, nobody can reconstruct exactly what produced a number.
- Errors are hard to see. A plausible-looking curve can still violate mass conservation or use the wrong fluid behaviour.
- Results are hard to reproduce. If another engineer cannot rerun the case, the result is difficult to defend.
haql-engine takes the opposite approach: a narrow, explicit scope; visible assumptions; automated physics checks; and a digital receipt for every run.
The goal is not to make a forecast look certain. The goal is to make its uncertainty and its evidence visible.
What it does
Predict production
Tracks oil, water and gas through a gridded reservoir, including pressure changes, dissolved gas and producing or injecting wells.
Test alternative fields
Runs many plausible versions of the same field — different rock, contacts, structure and operating assumptions — to show a range of outcomes.
Leave a receipt
Records the inputs, settings, outputs and material-balance checks so a reviewer can reproduce and challenge the result.
Current scope: the engine is built around SPE1-style benchmark cases and small rectangular grids. SPE1 is a standard public test case used to compare reservoir simulators. This is a verification and teaching instrument, not a replacement for Eclipse, CMG or tNavigator on a full field.
How it works
Every run follows the same chain of evidence. No step is allowed to disappear into a black box.
Grid, rock properties, fluids, wells and operating rules are read from a case definition.
The engine advances pressure and fluid volumes through time while conserving mass.
It measures whether oil, water and gas have been created or lost by numerical error.
Inputs, settings, output and a digital fingerprint are written into a run record.
For the numerically curious: the engine divides the field into a grid, tracks oil, water and gas cell by cell, and solves the changing pressure and flow through time. The technical reference explains the numerical method in detail.
Reading the results
A run produces more than a single production number. The useful outputs are the curves and checks that explain how the field behaves over time.
| Output | What it means in plain language |
|---|---|
| Production rate | How quickly oil, water or gas is flowing at a given moment. |
| Cumulative production | The total produced over a period; useful for comparing scenarios and checking totals. |
| Pressure | The driving force in the reservoir. A falling pressure may indicate weak support or a difficult production strategy. |
| Water cut | The share of produced liquid that is water. Rising water cut can signal breakthrough or changing flow paths. |
| Material balance | A bookkeeping check: what started in the model should equal what remains plus what left through the wells. |
P10, P50 and P90 summarise a range of scenarios. They are not three measurements of the same field. They are statistical markers across the plausible cases you supplied. The engine records which convention it used, because the labels alone are not enough.
A forecast is a conditional statement: if these inputs, this model and these scenarios are right, this is the range. It is not a promise.
Uncertainty, without the fog
The underground is not measured everywhere. Two engineers can build defensible models that differ in rock quality, fault sealing, fluid contacts or operating assumptions. A single “best estimate” hides that disagreement.
haql-engine represents it as a set of realizations: reproducible versions of the field, each written down before it is run.
Easy to read, but it can look more certain than the evidence allows.
Shows which assumptions move the result, and how often the outcome changes.
The uncertainty layer can vary rock quality and connectivity, rock type, structure and fault throw, fault-flow restriction, fluid contacts, initial pressure, well controls and selected fluid-behaviour multipliers. Each variation is recorded and fingerprinted before the solver sees it.
A fault can now be open, partly restrictive or sealed on the grid face it crosses. The assumption is recorded as a transmissibility multiplier rather than hidden in the solver. See how fault barriers work →
Running many scenarios at once
An uncertainty study is rarely one simulation. It may be dozens or hundreds of independent cases. Running them one after another can turn a useful study into an overnight wait.
The engine can run several scenarios in parallel on one machine. Each scenario remains a separate process with its own output and its own receipt. The individual simulation does not become faster; the set finishes sooner when the machine has spare capacity.
What stays the same: the result order, the digital receipt and the visibility of failed runs. Read the scenario-speed guide →
Can I trust it?
Not because a page says so. Trust comes from specific claims, specific tests, and a clear statement of what has not been tested.
Material balance closed far inside the published gate. Numerical bookkeeping is checked, not assumed.
A published comparison against OPM Flow, an open-source reference simulator. The 1.57% is a root-mean-square difference; pressure differences are larger and are reported openly.
Solver, geology, forecast and receipt checks. A passing test is evidence, not a guarantee.
Every run produces a digital receipt (a provenance record) containing the model input, solver settings, output and file fingerprints. Change one byte and the identity changes. That makes silent edits and accidental substitutions visible.
Read the public evidence summary → · See the technical evidence table →
What this does not prove: that the engine is accurate for every field. It has been checked on a narrow set of benchmarks, not history-matched to a producing asset. Those are different claims.
What it cannot do yet
A credible tool is clear about its boundaries. These are current limits, not temporary disclaimers.
| Current scope | Not yet supported |
|---|---|
| Small rectangular grids and SPE1-style cases | Corner-point/EGRID decks, SPE9 and real full-field grids |
| A limited well and schedule model | Full commercial schedules, multi-segment wells and complex controls |
| Local scenario parallelism on one machine | Cluster scheduling, MPI, GPU and distributed runs |
| Reproducible benchmark and uncertainty studies | History matching, production assimilation and reserves certification |
| Command-line and file-based workflows | A graphical interface or enterprise support desk |
Choose the right tool: if you need a full-field operational simulator today, use a commercial package. If you need an independent, inspectable cross-check on a focused case, this is the right scope.
Who it is for
A second opinion
Test whether a forecast is internally consistent, and see how much the answer moves when the geology or operating assumptions change.
A teachable engine
Inspect a complete reservoir-simulation workflow, from grid and fluids to the solve, the checks and the audit record.
Evidence over adjectives
Review the assumptions, reproduce the case and separate what the model supports from what it merely suggests.
It is not for production operations, reserves certification or replacing the judgement of a reservoir engineer.
Common questions
Is this a replacement for Eclipse, CMG or tNavigator?
No. Those are full-field commercial simulators with broad deck support, complex wells, history matching and operational workflows. haql-engine is a focused, inspectable engine for verification and teaching. It complements a commercial study; it does not replace one.
What is a realization, in ordinary language?
It is one plausible version of the field. If the rock properties are uncertain, you can create many versions that all honour the available data but differ in the unsampled places. Running the set shows a range instead of pretending there is one true answer.
What do P10, P50 and P90 mean?
They are statistical markers across the scenarios. They show where the middle and the edges of the range sit. They are only as meaningful as the scenarios that produced them, and the engine records the convention used to calculate them.
Does parallel running make one simulation faster?
No. It lets several independent simulations run at the same time. If your computer has spare cores and memory, the whole study can finish sooner. It is not a faster solver and it is not a cluster.
Can I use my own field deck?
Not yet. The current reader supports the SPE1-style subset described in the technical reference. A full corner-point deck is outside the present scope.
How do I get a case reviewed or run?
Use the contact link in the header, or start from the haql-engine product page. The useful first step is a short description of the case, the decision it supports, and the evidence you already have.
Feature log
Each shipped feature gets a public explanation, not only a code note.
| Feature | What it means for you | Guide |
|---|---|---|
| Geological uncertainty | Run a range of plausible fields instead of one guess. | Uncertainty |
| Fault-flow barriers | Test an open, partly restrictive or sealed fault without leaving the assumption implicit. | Fault barriers |
| Forecast aggregation | Turn a set of scenarios into a readable range and summary statistics. | Reading results |
| Parallel scenario execution | Finish a scenario study sooner while keeping every result traceable. | Scenario speed |