Workflow: Tank Level (material balance / Darcy-style engine)
This note explains what the Tank Level workflow does in Strateon Run—from data drawn from the project dataset through to results—in reservoir-engineering language. It does not list configuration keys or internal code symbols.
1. Problem being solved
Tank Level treats the field as layer compartments (and, depending on setup, injection–production patterns) where observed well rates must remain consistent with tank state: pressure, saturations, and—in three-phase mode—free gas and solution gas. The engine couples material balance with a Darcy-index style split (mobilities and effective pressure drives) to allocate liquids and, when applicable, gas across layers or patterns.
This is not the connection list + Buckley–Leverett stack; phase splitting here follows the Darcy / tank material-balance family described in the project’s technical reference.
2. Where the data comes from (project dataset)
The canonical path described here is data served from the corporate lake for a given project and dataset, resolved at run time through the query explorer (authenticated service). The same logical entities exist as when a case is fully file-backed, but the transport is relational rows keyed by project and dataset, not operator-uploaded spreadsheets.
2.1 Injected and produced rates
Injection time series: well, layer, time, rates (and gas branch when the schema supports it).
Production time series: well, time, oil/water/gas (and uptime where used).
2.2 Well geometry and rock template
Completion-style records: identifier, layer, well type, active intervals, locations, thickness, fault block, multipliers, and other columns needed to build well–layer participation and, when required, distance-based connectivity.
Layer properties for each layer: initial pressure and saturations, rock compressibility, pore volumes, relative-permeability end-points and Corey-style parameters, PVT indices, optional minimum drainage radius, and related fields used by the tank engine.
2.3 Optional well pressure
When bottomhole pressure is not a simple analytical rule, producer BHP histories can be pulled from the same project/dataset contract.
2.4 PVT and densities
Oil, gas, and water PVT tables (and reference densities) are part of the fluid definition; in database-backed runs they are fetched when not already present as local artefacts tied to the case.
2.5 Pre-run checks
Before the numerical kernel starts, the orchestrator verifies that the chosen model class (two vs three phases, layer vs pattern routing, BHP mode, optional uncertainty assets) has enough populated tables from the dataset. Missing mandatory slices stop the run with a clear failure.
3. Conceptual model preparation
3.1 Fluids and rock
From layer properties and PVT, the engine builds pressure–FVF–viscosity–Rs relationships and, in three-phase mode, the extra couplings needed for gas liberation and solution gas. That yields in-place fluids per layer (oil, water, free gas, solution gas as applicable)—the physical anchor for the balance.
3.2 Connectivity and patterns
Depending on policy:
- Explicit connection rows (injector–producer–layer, active windows), or
- Connections generated from completions using minimum distance, fault-block consistency, and overlapping active dates.
In pattern-level variants, well groupings and injection-allocation rules feed the later solve.
3.3 Exported in-place snapshot
Once layers and PVT are wired, the run emits a layer in-place fluid summary (oil/water/gas by mode). That is an audit artefact and a bridge to downstream workflows (e.g. OOIP targets for other products).
4. Numerical core
4.1 Main line: coupled evolution
The engine marches through the schedule, coupling:
- well rates (observed or imposed),
- compartment pressure and saturations,
- phase splits from mobilities and bottomhole constraints.
In three-phase mode, gas evolution, rock and fluid compressibility, and optional gas-history matching behaviour are controlled from the expert layer of configuration.
4.2 Primary export and forecast (when enabled)
If the product is set to export primary and, under specific combinations, to forecast primary, the engine first produces a primary rate and state trajectory consistent with history, then optionally extends it. That stream can feed later blocks—for example flood-related saturation and drainage geometry only under a narrow product combination: three-phase, layer routing, primary forecast on, and expert controls that include minimum drainage radius and maximum recovery so a post-primary saturation table can be built for downstream consumers.
4.3 Uncertainty and ensembles (variants)
In uncertain-production or uncertain-parameter history-matching modes, the engine runs ensembles and data assimilation against observations or field measurements. The story is unchanged: propose states and parameters inside declared bands that remain compatible with observations.
5. Results
Typical outputs written for the case include:
- Pressure and saturation series per layer (and per pattern when applicable).
- Layer rates consistent with history and model rules.
- Primary tables, and—when the flood block is active—primary forecast plus the waterflood-style saturation/radius table for downstream tools.
- The in-place volume snapshot described above.
- In pattern runs, injection allocation or other aggregation tables for the chosen variant.
Optional push back to the corporate database can be triggered by orchestration metadata after the numerical work is finished; that step publishes results without changing the physics.
6. How this differs from the other workflows
| Aspect | Tank Level | Buckley–Leverett (pattern) | Integrated |
|---|---|---|---|
| Core engine | Material balance + Darcy-style split by layer/pattern | Two stages: total-rate reconciliation + 1D displacement per connection | Same as BL after staging inputs from a parent Tank dataset |
| Dominant spatial unit | Tank / pattern with index-style Darcy | Injector–producer–layer tubes with 1D fronts | Same as BL |
| Typical data source | Project dataset for the Tank case | Project dataset (or workflow-scoped tables) for the BL case | Parent Tank project+dataset for rates/topology; child workflow IDs for case-scoped tables |
7. Related reading
- High-level theory (material balance, Darcy, Buckley–Leverett): other
docs/notes. - Scientific engine and SSBA version map: consolidated technical reference in the repository.