Workflow: Buckley–Leverett (pattern level, SSBA v1)
This note explains what the Buckley–Leverett pattern workflow does in Strateon Run—from data resolved from the project dataset (and, when used, workflow-scoped tables) through to results—in allocation and displacement language. It does not list configuration keys or internal code symbols.
1. Problem being solved
In many assets, well-level total rates (liquid, oil, water) are measured or reported, but the split across layers and across injector–producer connections is poorly known. The Buckley–Leverett product line (pattern level with mass-balance injection allocation and Buckley–Leverett production allocation) does two things in sequence:
- Reconcile observed rates with a connection model (who is connected to whom, in which layer, over which time window), enforcing global mass-style balances per timestep.
- Split oil and water along those connections using one-dimensional displacement physics (Buckley–Leverett, with optional capillarity) and an ensemble smoother so phase rates track observations within declared tolerances.
The outcome is a self-consistent set of connection- and layer-resolved rates that respects measurements and a physical flood narrative.
2. Where the data comes from (project dataset)
The path emphasised here is relational data for a project and dataset (and, where applicable, child workflow identifiers in integrated runs), not operator file drops.
2.1 Rates and topology from the dataset
The run expects, at minimum, injection and production histories keyed to the case’s project and dataset.
Connectivity is either:
- Loaded as an explicit injector–producer–layer table with time windows, or
- Derived from completions in the same dataset using distance rules, fault-block rules, and overlapping active dates—depending on how connectivity policy is set for the case.
2.2 Optional user-supplied primary
When the product is told that primary is user-supplied (not “none”), the engine also needs layer-primary rates (and, for the second stage, uncertainty bands per well, layer, and parameter) resolved from the same dataset / workflow contract the orchestrator binds to the run.
2.3 Tuning and expert behaviour
Tuning parameters (e.g. Corey exponents) and expert controls (gross-match tolerances, capillary switch, measurement-error floors, ensemble size, iteration counts) shape the numerics without changing the physical definition of the problem. These travel with the case definition the runtime receives—not as a separate “upload” story.
2.4 Pre-run checks
At minimum, injection, production, and resolvable connectivity must be present. Additional requirements depend on options (user primary, stiffness / KH tables, etc.), all interpreted against the same logical data contract whether rows came from the lake or from a legacy file path outside this document’s scope.
3. First conceptual stage: total-rate reconciliation
3.1 Goal
At each time step, assign connection-level rates (injector–producer–layer) so that:
- Aggregating to producer or injector reproduces observed well rates within tolerance bands;
- Volume-style balances hold between injectors and the producers they support, with slack where the product allows it.
3.2 Method (idea only)
The problem is cast as convex optimisation (quadratic programming) over many coupled unknowns across time—chosen for stability and scale. The output is a consistent gross connection-rate field that becomes the physical input to the second stage.
4. Second conceptual stage: phase split with Buckley–Leverett
4.1 Goal
Given reconciled totals on the connection graph, estimate phase fractions and effective saturations that explain observed oil and water (and, depending on options, restrict the match to oil). Each active connection–layer pair is treated as a 1D tube: relative permeabilities, fractional flow, shocks, and—if enabled—capillary pressure to smooth fronts.
4.2 Assimilation
Because the physics is nonlinear and parameters are uncertain, the product uses an ensemble smoother (ES-MDA) at well scale: perturb parameters, run inexpensive 1D forward models, update the ensemble toward observed phase rates.
4.3 Intermediate bundle
Besides final tabular exports, the runtime typically persists an intermediate bundle for debugging and for compatibility with legacy consumers.
5. Results
5.1 Tabular exports
After the second stage, the case receives CSV and, where enabled, Parquet with:
- rates and allocations at the business grain (connection, layer, well);
- adjusted ensemble parameters;
- auxiliary injection / forecast tables according to the export template.
5.2 Optional publication
As in the Tank workflow, orchestration metadata can trigger a post-run database publication step.
6. Separate “prediction” path (not the main run)
A distinct prediction path loads already calibrated Buckley–Leverett parameters and extends them forward in time with the same 1D solver in parallel. It does not replace the two-stage run for a new case; it only continues a calibrated storyline.
7. How this differs from Tank Level and Integrated
| Aspect | Buckley–Leverett | Tank Level | Integrated |
|---|---|---|---|
| Central question | How to allocate observations across connections and phases with 1D fronts? | How does the tank evolve under index-Darcy balance? | Same as BL, but inputs are staged from a parent Tank project dataset plus child workflow tables |
| Dominant spatial unit | Connection–layer tubes | Layer / pattern tank | Same as BL |
| Typical data source | Project dataset bound to the BL case | Project dataset bound to the Tank case | Parent Tank project+dataset + workflow case IDs for case-scoped tables |
8. Related reading
- Theory notes (material balance, BL, allocation): other
docs/files. - Typed column contracts: backend schema module.