Workflow: Integrated (Tank → Buckley–Leverett)
This note explains what the integrated workflow does: reuse information from a Tank-level reservoir study (material balance / Darcy-style engine) to drive a pattern-level Buckley–Leverett allocation case—without re-entering rates and topology by hand. It does not list configuration keys or internal code symbols.
The focus below is data taken from the project dataset and from workflow-scoped tables in the corporate lake, not file uploads.
1. Problem being solved
A team may first calibrate a Tank model (consistent history, in-place volumes, compartment pressures and saturations). They then want connection-based allocation and 1D flood physics without manually rebuilding injection, production, and the connection graph.
The integrated path automates the bridge: it pulls rates and connectivity from the same project and dataset as the parent Tank model in the data lake, and fills the remaining needs from child workflow runs identified by workflow case identifiers—for example one case contributing layer primary calculated rates, another contributing flood/saturation and drainage-geometry rows, and another contributing the layer rock catalogue used for uncertainty limits.
The final numerical engine is the same two-stage Buckley–Leverett stack as the standalone pattern case: total-rate reconciliation on the connection network, then oil–water split with 1D displacement and ensemble assimilation.
2. Where the data comes from
2.1 Orchestration contract
The integrated case is still a pattern-level Buckley–Leverett family member at the product level. Orchestration metadata marks the run as inherited from Tank, points to the parent project and dataset, and carries the child workflow identifiers (or a single legacy identifier) that select which published tables to read.
2.2 Query service
Reading from the lake requires a service URL and credential available to the compute environment. Without them, the staging phase cannot pull parent injection/production or connections.
2.3 Always from the parent Tank project and dataset
At minimum, the staging layer loads from the parent Tank dataset:
- Injection history by well and layer (and gas when the table model includes it).
- Production history by well.
- Either an explicit connection list (injector–producer–layer with time windows) or completions rich enough to regenerate connections using distance, fault block, and date-overlap rules—according to the connectivity policy declared for the case.
These are the same logical bricks the Tank engine would consume, but served as relational rows tied to project + dataset.
2.4 From child workflows (by case identifier)
The story splits between a legacy single-ID contract and a dual-ID integrated contract.
Dual-ID contract (recommended)
Saturation / secondary-recovery workflow ID: corporate tables with per-well, per-layer primary cutoffs, cumulative primary, thickness, and flood-related fields. Under current product policy this may be read directly from the waterflood-style saturation store, or combined with rock fields from the limits workflow for a radius-based reconstruction of secondary-start saturation—still entirely sourced from database queries keyed by that case ID.
Layer-limits workflow ID: layer properties (Corey exponents, end-point relperms, porosity, irreducible saturations, etc.) versioned for that workflow case. Those rows serve both merging rock into the flood rows (where the product needs porosity and initial water saturation) and building the mean property catalogue for the uncertainty-limit construction.
Legacy single-ID contract
One parent workflow case identifier is reused for calculated primary, waterflood-style saturation, and layer properties in one consistent slice of the lake.
2.5 User-declared primary
When the BL case declares user-supplied primary (not “none”), staging requires a layer-rate primary table aligned with the chosen workflow case (in the dual contract, the same branch as the saturation/recovery case). Without that slice, the chain cannot supply what the two-stage engine expects.
3. Intermediate staging (logical tables for the BL engine)
Before the Buckley–Leverett kernel runs, the runtime materialises the same logical inputs a fully prepared case would have: injection, production, connections or completions-derived connectivity, optional primary, and a long-format layer-limit table (parameter, minimum, maximum per well and layer).
This staging is dataset-driven; the consumer of the next phase is the in-memory bundle, not an “upload your CSV” story.
3.1 How layer limits are obtained
They are usually not a static layer_limits table copied from a child run. They are derived by combining:
- Flood / secondary saturation information at well–layer grain from the saturation branch (or from the intermediate radius reconstruction);
- Topology (which producers and layers participate, including pairs implied by the connection graph);
- The layer property catalogue from the limits workflow case.
For each physical parameter type, a symmetric uncertainty band is built around the mean using fixed multipliers per parameter family (e.g. wider bands for Corey exponents than for porosity). The result is the limit table consumed by the second BL stage when primary is user-supplied.
4. Numerical engine (same as standalone Buckley–Leverett)
After staging:
- Unified load: assemble the time grid, rates, connectivity, tolerances, and smoothing options the two stages share.
- First stage: convex reconciliation of total rates at connection level with per-well, per-timestep balance structure.
- Second stage: oil–water split along 1D Buckley–Leverett tubes with well-scale ensemble assimilation.
- Export: the same families of tabular results as a non-integrated BL case, plus any persisted debug bundle the deployment keeps.
4.1 Optional publication
As in other workflows, orchestration metadata may trigger post-run publication to the corporate database.
5. Common conceptual mistakes
Confusing the parent Tank dataset (rates + graph) with the BL case identifier: the dataset feeds rates and topology; child case IDs select workflow-versioned tables (primary, saturations, properties).
Assuming layer limits always exist as a pre-stored child table: in the flow described, they are computed during staging from the three sources above.
Omitting user primary when that mode is selected: without the case-aligned primary rate table, the integrated chain cannot complete.
6. Quick comparison
| Aspect | Integrated | Tank Level | Standalone Buckley–Leverett |
|---|---|---|---|
| Source of rates + graph | Parent Tank project + dataset | Same Tank binding | BL case project + dataset |
| Source of flood / rock tables | Child workflow case IDs (or one legacy ID) | Tank engine under narrow product conditions | Prior workflow or lake slice for that BL case |
| Final engine | Two-stage BL | Darcy / tank | Two-stage BL |
7. Related reading
- Tank Level workflow (dataset-centric):
STRATEON_RUN_WORKFLOW_TANK_LEVEL.md. - Buckley–Leverett workflow (dataset-centric):
STRATEON_RUN_WORKFLOW_BUCKLEY_LEVERETT.md. - Typed column contracts: backend schema module.