Book a demo
Menu

Refinery planning optimization

Refinery planning that solves reliably at the scale you actually need.

Slate solves multi-period, multi-refinery planning models as linked subproblems and reports every decision in margin dollars.

Book a demoRead the technical brief
Decomposition of a regional planning modelSparsity pattern of a planning model shown twice. On the left, rows and columns in their original order look unstructured. On the right, the same nonzeros are reordered into block-angular form: a band of linking constraints across the top, and four blocks on the diagonal labeled A to D, one per refinery.FULL MODELrows, cols as writtenREORDERBLOCK-ANGULARLINKABCD
  • Linking constraints: shared crude supply, product transfers, regional demand
  • Subproblems A to D: one per refinery, solved separately and coordinated
Fig. 1One regional model, reordered into block-angular form: four refinery subproblems tied together by a small set of linking constraints.
  • MILP and MINLP
  • Multi-period
  • Multi-refinery
  • Scenario-aware
  • Inspectable models

01The problem

What breaks as planning models grow.

These come from conversations with refinery LP modelers. If you maintain a large planning model, you have probably built workarounds for most of them.

  1. 01

    Solves that do not hold up

    Large multi-period models are sensitive to the starting point. They become ill-conditioned, stall on zero flows, and return infeasibilities that are hard to trace. Teams keep case portfolios and warm-start files just to get a solution.

  2. 02

    A ceiling on model size

    A single-period model of one large refinery can run to around 20,000 equations. A regional, multi-refinery model is ten times that, and planners still need a good answer in about the same time.

  3. 03

    Decomposition by hand

    Big models need to be split into linked subproblems. Today that is a research project, not a product feature. The hard part is deciding where to draw the boundaries.

  4. 04

    Continuous plans, batch operations

    LP planning averages everything into continuous flows. The plant runs on tanks, cargoes, and batches. The gap shows up on Monday morning.

  5. 05

    Proxy KPIs instead of margin

    Decisions get argued in utilization and yield percentages. They should be argued in margin, with a clear view of what each constraint is costing you.

  6. The technical brief covers the first three in depth: what causes them, and what to do about them.

    Read the technical brief

02How Slate is different

Built for the models planners actually run.

01

Solves reliably at scale.

Slate partitions large models into linked subproblems and coordinates them to one consistent plan. Each piece is solved with modern MILP and MINLP methods. The aim is a regional model you can solve on schedule, without a library of warm starts.

  • Linked subproblems
  • Structure-aware boundaries
  • Traceable infeasibilities

02

Plans the way the plant actually runs.

Continuous planning flows connect to discrete events: tank levels, cargo arrivals, and blend batches. The period plan and the Monday schedule stay consistent with each other.

  • Tank and inventory events
  • Cargo and batch timing
  • Multi-period inventory

03

Shows the dollars behind every decision.

Results are reported in margin. Shadow prices show what each binding constraint is costing you, and cycle-over-cycle comparisons show what changed and why.

  • Margin by decision
  • Shadow prices by constraint
  • Cycle-over-cycle changes

03Workflow

From your current model to a plan you trust.

  1. Step 1

    Bring your model.

    Share your current planning model, its data, and the cases you run each cycle.

  2. Step 2

    We build it with your team.

    We map the model structure and rebuild process-unit submodels alongside your modelers.

  3. Step 3

    Run side by side.

    Both models run the same cases until every material difference is fixed or explained.

  4. Step 4

    Plan with confidence.

    Switch over when the results hold up. Your team can inspect, test, and adjust the model.

How migration works

04Transparency

Not a black box.

Slate is mathematical optimization, not a language model.

Every unit model, constraint, and price is open to inspect, test, and adjust. When the plan changes, you can trace the change to the input or constraint that caused it.

Constraint detail

Illustrative

constraint
fcc_feed_capacity[p]
form
Σ feed[s,p] ≤ cap[fcc,p] for s in FCC_FEEDS
status
binding in periods 2 and 3
shadow price
λ[p] $ per bbl of FCC feed
drivers
vgo_yield[crude], coker_outage[p]
Readable structure
Units, streams, pools, and constraints are named and documented, not buried in a matrix.
Testable submodels
Each process unit can be checked on its own against known operating data.
Traceable results
Every number in a plan links back to the inputs and constraints behind it.

05Results

Benchmarks and results.

  • Solve reliability

    [TODO: benchmark result, needs approval]

    For example, share of cases solved without manual restarts on a large multi-period model.

  • Scale

    [TODO: benchmark result, needs approval]

    For example, regional model size and solve time compared with the single-site model.

  • Margin

    [TODO: pilot result, needs approval]

    For example, margin identified in a side-by-side run, stated with its assumptions.

Next step

See Slate on a model like yours.

Book a working session with the team, or start with the technical brief.

Book a demoGet the technical brief