Reservoir engineering forecasts the asset. Reservoir simulation builds the physics model the forecast is argued against. They sound like the same job — outsiders, and plenty of insiders, collapse them into one. They are not, and the difference is the whole point.

People outside the industry — and plenty inside it — collapse "reservoir engineer" and "reservoir simulation engineer" into one role. Practitioners don't. The reservoir engineer owns the asset: the declines, the reserves, the economics, the daily question of what each well will make. The simulation engineer owns the model — a three-dimensional, grid-by-grid, physics-based digital twin of the reservoir, built to answer the questions a decline curve never can: Where should the next well go? What happens if we inject here? How much more oil does this development plan recover than that one?

It is the most computational seat in petroleum engineering, and it has a daily rhythm unlike any of the others, because the simulation engineer spends a lot of the day waiting on a machine.

Building the model

A simulation starts as geology. The static model — the grid, the structure, the rock and fluid properties — usually comes out of Petrel (SLB) or a comparable geomodeling environment, where millions of fine geological cells are upscaled into a coarser grid the simulator can actually run in human time. Upscaling is its own quiet art: coarsen too aggressively and you average away the very heterogeneity that controls how fluids move; keep it too fine and the model takes a week to run a single case. The simulation engineer lives on that tradeoff.

Then the model has to be initialized — fluids placed in gravity-capillary equilibrium, contacts set, the reservoir put into a believable starting state — and handed to a dynamic simulator. In practice that's Eclipse or its next-generation sibling INTERSECT (SLB), the CMG suite (IMEX for black oil, GEM for compositional, STARS for thermal/EOR), or tNavigator, the GPU-accelerated newcomer that has been eating into the incumbents precisely because run time is the constraint that rules this job.

History matching: the long argument with reality

Here is where the simulation engineer's day really goes. A model that hasn't reproduced the field's past has no business predicting its future — so before it forecasts anything, the model must history-match: reproduce the pressures and production the reservoir has actually delivered over years of operation.

It almost never does on the first try. So begins the slog — adjusting permeability, fault transmissibility, relative permeability curves, aquifer strength — re-running, comparing, adjusting again. The deep frustration of the discipline is non-uniqueness: many different combinations of parameters can match the same history, and only some of them predict the future correctly. A match is not a truth; it's a hypothesis that happens to be consistent with the data so far. The good simulation engineer holds that humility in their hands all day, which is why the better shops lean on assisted history matching and formal uncertainty workflows rather than hand-tuning a single "answer" model and falling in love with it.

The overnight run

The texture of the day is shaped by compute. Build a case in the morning, kick off the run, and — for a large full-field model — you may not see the result until tomorrow. So the simulation engineer learns to batch: queue a sensitivity suite before leaving, walk in to a folder of completed cases, triage which ones matched and which blew up, and design the next batch from what they learned. A meaningful part of the craft is experiment design under a compute budget — deciding which questions are worth a run when runs are the scarce resource. (This is exactly why GPU simulators like tNavigator have made the inroads they have: cut the run from overnight to an hour and you change what's possible to ask.)

Forecasting, and earning the right to be believed

Once a model is matched and its uncertainty is honestly characterized, the payoff arrives: prediction runs. Drill here or there. Inject water, gas, CO₂. Infill the spacing or hold it. Each scenario is a forecast of recovery and rate, and these are the runs that justify hundred-million-dollar development decisions and underpin booked reserves under PRMS. Increasingly the deliverable isn't a single number but a distribution — P10/P50/P90 across an ensemble — because a forecast without its uncertainty is exactly the false precision the reserves auditors (rightly) distrust.

This is the simulation engineer's authority and their burden: their model becomes the artifact the whole asset team argues over. The reservoir engineer cross-checks it against the declines. The completions engineer asks it about spacing. Management wants the one number it can't honestly give without a range attached.

The model nobody updated

And the recurring tragedy of the discipline: the model that went stale. A field-wide simulation takes months to build and is a genuine corporate asset — and then the engineer who built it moves on, new wells come online, and the model quietly drifts out of date because keeping it current is real, unglamorous work nobody budgets for. Six months later someone needs a forecast, opens the model, and discovers it doesn't know about the last two years of the field. The institutional knowledge baked into that grid is one of the most valuable and most perishable things a company owns.

Where this connects to what we build

Simulation is the discipline that most sharply makes Workollab's case for transparency and ownership. A history-matched model is a hypothesis, not an oracle — so the worst thing a tool can do is hide its assumptions inside a black box and hand you a confident single number. Everything we build runs the other way: validate against a known-good reference, keep every assumption visible and auditable, run on infrastructure the operator owns so the model is theirs to keep current instead of a rented dependency that goes dark when the contract lapses. Our browser-native decline and PVT engines are deliberately small, transparent expressions of the same belief that powers a good simulation practice — show your work, characterize your uncertainty, and never ask anyone to trust a number they can't inspect.

The simulation engineer builds the digital twin the whole asset reasons with. The least the tools can do is make that twin honest about what it doesn't know.

One industry, and the same structural gap that shows up in every corner of it: the physics is mature, and the plumbing between the physics and the decision is where the time and the value leak out. That gap is the work.

Tools & terms named in this piece

Geomodeling & gridding: Petrel (SLB); upscaling, initialization. Dynamic simulators: Eclipse and INTERSECT (SLB), CMG IMEX / GEM / STARS, tNavigator (GPU). History matching (incl. assisted history matching) and non-uniqueness; relative permeability, transmissibility, aquifer modeling; sensitivity and uncertainty (P10/P50/P90 ensembles); prediction runs and PRMS reserves. Workflow and tool details drawn from current vendor documentation and reservoir-simulation practice, 2024–2026.

One of Workollab's oil & gas engineering pieces. Related reading covers our browser-native decline-curve (Auto-DCA) and PVT engines, and the open-source reservoir-engineering stack.

Need to turn this engineering logic into a production-ready tool? Explore custom petroleum software development.