Optimisation engine

CEMeridian

Our own LP/MILP solver, written in Rust, that checks its answers.

CEMeridian is our own optimisation engine, written in Rust for the structure of power-system problems. On direct LP solves, a separate certifier re-checks every answer reported as optimal by default, and every solve in CEGridSight production is certified before it is served. On large capacity-expansion planning problems it is several times faster than HiGHS, the leading open-source solver. CEGridSight’s whole day-ahead price model and CECadence run on it, and every engine build is cross-checked against an independent open-source solver before it ships. Every speed result below is dated, including the ones where we are level or slower.

About 7–9× faster
Capacity-expansion master problems, certified
CEMeridian time 0.11–0.15× HiGHS 1.15.1 · 22 Sep 2026 · loaded arm64 Mac workstation (upper bound)
54 s and 73 s vs a 10-minute limit
A large public energy-system planning model (~739,000 constraints)
Certified in 54 s and 73 s; HiGHS at its defaults hit its 600 s limit both times · 22 Sep 2026 · loaded arm64 Mac workstation
0.66–0.79× HiGHS time
Battery-dispatch workloads, the whole product run at 8 / 13 / 26-week horizons
24 Sep 2026 · Linux x86-64 · HiGHS single-threaded on the product’s fixed settings; CEMeridian as production runs it
812 / 812
Production solves independently certified, CEGridSight
Week to 30 Sep 2026
Talk to usLicensing
2 CE products run on itCertified by default on direct solvesRust no runtime dependencies
In production today

Two products run on it in production.

A certificate is an independent check, run after the solve, that the answer really is optimal: every constraint holds, and no better answer exists within a stated tolerance.

CEGridSight’s whole day-ahead price model, both stages, is solved by CEMeridian’s interior-point method and independently certified: 812 of 812 solves in the week to 30 September 2026. The two stages, the national wholesale market and the 17-zone redispatch, cover GB and Europe. That is 28 optimisation problems per forecast cycle, the largest about 2.36 million variables, four cycles a day. Every answer passes two checks before it is served: the engine’s own certifier, and a second certificate on the CEGridSight side that re-checks feasibility, the duality gap (how far the answer could be from the best possible) and the objective.

CECadence solves its battery-dispatch LPs with CEMeridian’s dual simplex, warm-started from the previous basis. Every engine build is cross-checked against an independent open-source solver before it ships, and each upgrade has to pass on real production problems before it reaches a product.

How it works

Five engines behind one entry point

CEMeridian is a general LP and MILP solver. It is tuned for the structure that grid dispatch, nodal markets, unit commitment, contingency screening and capacity expansion have in common, but it accepts any model. One entry point reads the model, routes it to one of five native engines, and reports why it chose that engine, so the choice can be audited.

  • Interior point: a primal-dual Mehrotra predictor-corrector with Gondzio corrections, Ruiz equilibration, supernodal Cholesky factorisation and crossover. This is the engine behind CEGridSight’s large network LPs.
  • Simplex: revised primal and dual simplex, with warm re-solves from a previous basis.
  • PDLP, a matrix-free first-order method (primal-dual hybrid gradient with restarts) for problems too large to factorise, with a GPU implementation.
  • Branch-and-cut for MILPs, with reliability branching, primal heuristics and root cutting planes (lifted covers, MIR, flow covers, cliques, Gomory cuts).
  • Decomposition, for problems that split into a master and subproblems.

An independent verifier with no solver code in its call graph re-checks the answers. A claimed-optimal solution that fails certification returns a non-zero exit code, so your CI can gate on it. Since late August 2026 certification has been the default on direct solves.

The certifier

Why the answers are checked separately

Solvers can fail without saying so: a stale factorisation, a tolerance met in the solver’s scaled units but not in yours, or a status code that reports more than was achieved. CEMeridian keeps the solve and the check in separate code, and when they disagree the check decides.

The certifier re-checks every Optimal claim in your model’s own units, not the solver’s scaled internal ones, against a fixed default tolerance of 1e-5. It recomputes primal feasibility, bounds, dual feasibility, complementarity and the objective, and checks the whole-problem duality gap. Each constraint is judged against the size of its own terms, so large and small rows are held to comparable standards. Corrupt model data is refused with a named error rather than solved.

An answer that can’t be certified comes back as a diagnostic naming the failing residual. It is never reported as Optimal.

Results are deterministic: for a given configuration, the same model gives the same answer, bit for bit. We re-verified that under sixteen-way co-tenancy on one machine, and the outputs were identical.

Certified auto mode runs a ladder. It tries the fast rung first, and if the certifier refuses that answer, the solver escalates to a more careful method instead of returning it. This has been the default since 29 August 2026, with an instant opt-out, and it needs no per-model tuning.

Every certified answer carries a SHA-256 fingerprint of the exact model it was proved against, so a certificate can be tied to one input file.

Speed against the leading open-source solver

Every result, dated, with its conditions

Each figure is CEMeridian’s solve time divided by the time HiGHS 1.15.1 takes at its default settings, unless the row says otherwise, on the same machine and the same problem. Below 1 is faster, above 1 is slower. Every row is dated and carries its conditions, and no row is averaged with another.

All results, including where we are level or slower:

WorkloadMeasuredMachineTime ÷ HiGHS timeStanding
Battery dispatch workloads: the whole product run, end to end, at 8 / 13 / 26-week horizons24 Sep 2026Linux x86-64 cloud machine; HiGHS on the product’s fixed settings (threads=1, parallel off, fixed seed), not its defaults0.663 / 0.716 / 0.794Faster
Battery dispatch workloads: the solver’s own work only, single thread, replaying recorded solve sequences exactly, at 8 / 13 / 26 weeks29 Sep 2026arm64 Mac workstation, loaded (upper bounds); HiGHS on the product’s fixed settings (threads=1, parallel off, fixed seed), not its defaults0.68 / 0.74 / 0.84faster on all 524 problems; no objective mismatchesFaster
Capacity-expansion master problems, re-solved inside a decomposition loop, certified22 Sep 2026arm64 Mac workstation, loaded (upper bounds)0.11–0.15Faster
A large public energy-system planning model (about 739,000 constraints)22 Sep 2026arm64 Mac workstation, loaded (upper bounds)below 0.12certified optimal in 54 s and 73 s; HiGHS at its defaults stopped at its 600 s limit both timesFaster
A day-ahead market model: recorded production problems21–22 Sep 2026arm64 Mac workstation, loaded (upper bounds)0.86–1.05Level
US regional price models: nine regions, 81-hour problems (not in production: CEMeridian is not used for our US forecasts)25–26 Sep 2026arm64 Mac workstation, loaded (upper bounds); 8 threads offered to both; HiGHS used one core (its simplex is serial), CEMeridian 2–50.65–0.84 · 0.82–0.92faster on 3 of 9 regions at default settings (0.65–0.84), and on 3 more with an opt-in presolve setting (0.82–0.92); slower today on the other three; we are working to beat it in Q4 2026Mixed
Planning-study operating blocks (not in production)26–27 Sep 2026arm64 Mac workstation, loaded (upper bounds)slower todayWe are working to beat it in Q4 2026Slower
Continental unit commitment: the relaxed LP of a large continental model27 Sep 2026arm64 Mac workstation, 8 threads, loaded (upper bounds)slower todaythe fix (a better fill-reducing ordering) is in progress, and we are working to beat it in Q4 2026Slower

How it’s measured. Both solvers run the same problem on the same machine, one after the other. A “loaded” machine is a shared workstation running other work at the same time, so its times are upper bounds on what either solver needs. Battery-dispatch figures come from two different measurements (the whole product run on a cloud machine, and the solver’s own work on a workstation) and are shown separately, never mixed.

Speed against the leading commercial solver

Faster on battery dispatch, slower today on the largest problems

Here each figure is CEMeridian’s time divided by the leading commercial solver’s time on the same machine and the same problem (CEMeridian time ÷ leading-solver time; below 1 is faster). Against the leading commercial solver, CEMeridian is faster on battery-dispatch workloads (0.69–0.70×, single thread) and, by direction, on decomposed planning; it is slower today on the largest nodal price LPs and on continental unit-commitment relaxations, and we are working to beat it on both in Q4 2026.

WorkloadMeasuredMachineTime ÷ leading-solver timeStanding
Battery dispatch workloads: recorded production solve sequences at 8 / 13 / 26-week horizons, the solver’s own work only, one thread each29 Sep 2026arm64 Mac workstation, loaded (upper bounds)0.69 / 0.69 / 0.70cold solves 0.45–0.63, warm re-solves 0.72–0.90; the leading solver ran dual simplex with a true warm start; objectives agreed on all 7,849 solvesFaster
The largest day-ahead nodal price LPs, up to 3 million rows (not in production)25–26 Sep 2026arm64 Mac workstation, 8 threads each, loaded (upper bounds)slower todaythe leading commercial solver is currently faster; the cause is measured and named, and we are working to beat it in Q4 2026Slower
Continental unit commitment: the relaxed LP of a large continental model27 Sep 2026arm64 Mac workstation, 8 threads each, loaded (upper bounds)slower todaythe leading commercial solver solves the relaxed LP where CEMeridian does not yet converge; this is our top open gap, and we are working to beat it in Q4 2026Slower
Multi-scenario capacity expansion, solved by decompositionJune–July 2026older hardware; to be re-measureddirection only: below 1CEMeridian faster, with the margin growing as scenarios are added; no figure is quoted until it is re-measured on current hardwareFaster

How it’s measured. Both solvers run the same problem on the same machine, under identical load; a loaded machine gives upper bounds. The battery-dispatch figures time the solver’s own work only, replaying solve sequences recorded in production with the open-source solver, and compare objectives rather than certificates. The nodal price and unit-commitment problems are not solved on CEMeridian in production. Workloads not listed here have been measured against the open-source solver only.

Landed in September 2026

Changes this month

The certified board · late August 2026

Eight continental planning blocks, all certified on one setting

A capacity-expansion sweep is only as trustworthy as its worst block. We took eight large blocks from a real continental-scale planning study and ran them through certified auto mode with one setting and no per-block tuning, leaving the solver’s ladder to decide how hard to work on each. In late August 2026 all eight came back Optimal and certified.

The flagship block certified on the first rung in 133 s and agreed with its reference anchor to 9.5×10⁻¹⁰. Three more cleared the same first rung at 110 s, 116 s and 203 s. A fourth was refused there, escalated itself and certified at 433 s.

On four of the eight blocks, the fast rung produced an answer the certifier refused. None of those answers was returned: the solver escalated and came back with a certificate each time.

Seven blocks have a cross-validated reference anchor. Our certified objective agrees with all seven to within 4×10⁻⁸ relative, and with five of them to 10⁻¹⁵ or exactly.

Other measurements

Load, GPU screening and interfaces

A saturation study on 27 August 2026 ran 129 certified solves and 172 certified warm re-solves at up to sixteen-way load. All were Optimal, with bit-identical outputs, at about 125 certified planning blocks per hour per machine, scaling linearly across machines. The work is bound by memory bandwidth, so it scales out rather than up.

A GPU-resident N-1 screener runs about 31× faster than a single core and about 2× faster than a 24-core CPU run (June 2026).

Interfaces: Rust and a CLI, Python over SciPy sparse arrays, a panic-safe C ABI, and a JuMP/Julia binding. There is no JSON on the hot path. Every algorithm traces to the published literature, none is reverse-engineered from another solver, and the leading open-source solver is kept as a permanent correctness oracle.

Commercial licensing: CEMeridian ships inside CE products and is licensed separately to teams that want the engine under their own models. Every benchmark claim traces to a saved, reproducible measurement.
Licensed access

Use the engine under your own models.

For desks and vendors with their own models: bindings for Python, C and Julia, benchmark support against your actual problems, and engineering time to wire it in.

hello@compoundingenergy.comContact