Industry Signals
NVIDIA cuOpt Wins 2026 LPFeas Hans Mittelmann Leaderboard — First GPU Solver to Top an LP Benchmark Category 🔗
Foundation: LP (Linear Programme) feasibility testing asks whether a system of linear constraints Ax ≤ b has any solution at all — whether any assignment of variable values can simultaneously satisfy all constraints. The Hans Mittelmann benchmark leaderboard measures solver wall-clock time on fixed public test sets; the LPFeas category specifically measures how quickly solvers determine LP feasibility. Until 2026, all top-ranked LPFeas solvers were CPU-based — either simplex (a vertex-walking algorithm) or interior-point (a path-following algorithm through the feasible region) methods.
NVIDIA cuOpt — a GPU-accelerated LP and Mixed Integer Programme (MIP)Optimisation where some decision variables are integer-valued, making the problem NP-hard in general. See full concept page. solver — became the first GPU-based solver to win the LPFeas category on the Hans Mittelmann leaderboard in 2026, establishing GPU interior-point methods as competitive with CPU incumbents on a publicly reproducible benchmark. Practitioners with existing GPU infrastructure can evaluate cuOpt for LP feasibility workloads — batch validation, constraint checking, scenario screening — without further solver investment. The case study below details the benchmark structure and practitioner implications.
Tools Watchlist
2 releases · past 14 daysOpen-source solver and modelling-framework releases that passed all four qualification tests.
SDDP.jl v1.13.2 🔗
| Field | Content |
|---|---|
| Version | v1.13.2 — April 2026 |
| What changed |
|
| Impact | Energy practitioners modelling seasonal hydro inflows can now calibrate PAR models directly in SDDP.jl, removing a manual pre-processing step before running hydrothermal scheduling. The documentation reorganisation reduces onboarding friction for new users. |
| Migration | None — v1.13.2 is a minor patch release with no breaking API changes from v1.12.x. |
SCIP Optimization Suite 10.0.2 🔗
| Field | Content |
|---|---|
| Version | 10.0.2 — April 2026 (patch in SCIP 10 series) |
| What changed |
|
| Impact | Conflict analysis in SCIP 10 converts infeasibility proofs into permanent barrier constraints during branch-and-bound — the same technique explained in today's Term of the Day. Practitioners running SCIP on MIP instances with tight feasibility boundaries (scheduling, network design, bin-packing) should see reduced tree sizes without configuration changes. |
| Migration | SCIP 9.x models run unmodified; rational mode requires explicit flag; bundled GCG 4.0.2, SoPlex 8.0.2, ZIMPL 3.7.1, PaPILO 3.0.0. |
Research Papers
Benders Cut Filtering for Mixed-Integer Programs 🔗
Foundation: Benders DecompositionAn algorithm that splits a large MIP into an integer master problem and a continuous LP subproblem, exchanging cuts until convergence. See full concept page. generates one optimality cut per subproblem solve. In large decomposable MILPs — multi-period energy planning, supply-chain network design — the cut pool can grow to tens of thousands before convergence. Not all cuts are equally useful: many are never active at the final solution and only slow the master LP solve. Selecting which cuts to retain is therefore a critical implementation choice.
This paper proposes filtering strategies that screen Benders DecompositionAn algorithm that splits a large MIP into a master problem (integers) and a subproblem (continuous), exchanging cuts until convergence. See full concept page. optimality cuts before they enter the master problem, retaining only those likely to tighten the bound. The authors show that cut selection based on violation magnitude and cut orthogonality can reduce the active pool by an order of magnitude on standard decomposable benchmarks, with negligible degradation in bound quality and measurable reduction in total solution time. The result is directly applicable to any Benders implementation on energy, logistics, or supply-chain models.
Every Benders implementation in production accrues redundant cuts. This paper gives concrete filtering criteria — tested on standard decomposable MILP benchmarks — that practitioners can apply to existing implementations to reduce LP solve time without modifying the decomposition structure or sacrificing convergence guarantees.
Surgical Scheduling with Overtime: A MILP Approach 🔗
Foundation: Operating room scheduling assigns surgical cases to rooms and time slots subject to surgeon availability, room capacity, and case duration estimates. Adding overtime as an explicit decision variable — the binary choice of whether a room continues past its standard end time at additional cost — converts a feasibility assignment into a cost-minimisation Mixed Integer ProgrammingOptimisation where some decision variables are constrained to integer values, making the feasible region non-convex and the problem NP-hard in general. See full concept page. with a rich trade-off surface between throughput and labour expenditure.
This paper formulates surgical scheduling with explicit overtime cost as a Mixed Integer ProgrammingOptimisation where some decision variables are constrained to integer values, making the feasible region non-convex and the problem NP-hard in general. See full concept page. (MILP), minimising total overtime expenditure subject to room capacity, surgeon availability, and stochastic case duration constraints. The model is tested on real scheduling instances from a regulated hospital environment and produces provably near-optimal schedules with solution times tractable for daily scheduling workflows. The authors demonstrate that the overtime-aware MILP consistently outperforms greedy and rule-based schedulers on both cost and room utilisation metrics.
Healthcare practitioners building scheduling tools face pressure from two directions simultaneously — maximising surgical throughput and containing overtime expenditure. This paper provides a concrete MILP formulation that handles both within a single model, validated on real hospital instances in a regulated environment where schedule quality has direct patient safety implications.
Term of the Day
Conflict Analysis
“The real measure of solver progress is not faster optimal solutions — it is smarter infeasibility.” — Achterberg & Wunderling, Mixed Integer Programming: Analyzing 12 Years of Progress (2013)
Conflict analysis is the process by which a MIP (Mixed-Integer Programme) solver converts an infeasibility proof — the sequence of branching decisions and constraint tightenings that made a subproblem impossible to satisfy — into a reusable constraint called a conflict clause or conflict cut, which is added back to the search to prevent the solver from revisiting equivalent infeasible regions. Every modern branch-and-cut solver — SCIP, Gurobi, CPLEX, HiGHS — performs conflict analysis automatically during the branch-and-bound search tree traversal.
A concrete example
Suppose a logistics dispatcher is solving an integer programme (a discrete optimisation problem where decision variables are constrained to integer values) for overnight truck routing. The solver branches on variable x₁ (assign driver A to route 1: yes/no) and x₂ (assign driver B to route 2: yes/no). After setting both to 1, the solver finds the resulting subproblem infeasible: drivers A and B share a mandatory rest stop that cannot accommodate both trucks simultaneously.
Without conflict analysis: the solver records this as a dead branch and backtracks — but it will encounter equivalent infeasible combinations again whenever it branches into x₁=1, x₂=1 from any different ancestor node. The same infeasibility is rediscovered multiple times, wasting solver time on regions already proved dead.
With conflict analysis: the solver extracts the reason the subproblem was infeasible (the shared rest-stop constraint), expresses it as a new linear constraint — x₁ + x₂ ≤ 1 — and adds it to the model. Every subsequent node in the search tree automatically inherits this cut, and the solver never enters x₁=1, x₂=1 again from any node. One infeasibility proof becomes a permanent barrier across the entire tree.
Why practitioners misread this
Practitioners see conflicts: 47 in a solver log and assume the model has 47 constraint violations to fix. It does not — the model is still a valid formulation. That number reports how many conflict clauses (reusable constraints derived from infeasibility proofs) the solver generated during branch-and-bound. A high conflict count usually signals the solver is working near a tight feasibility boundary — it can indicate a well-structured problem, not a modelling error.
A second confusion: conflict analysis is not infeasibility debugging. Infeasibility debugging tells a practitioner why their complete model has no feasible solution at all. Conflict analysis happens inside a feasible model, during the search for an integer-feasible point — it analyses local infeasibilities created by branching decisions, not global infeasibility of the model itself. If your model is globally infeasible, conflict analysis cannot help; you need to examine the constraint set directly.
Where this shows up in practice
Conflict analysis runs inside every modern branch-and-cut MIP solver. In energy planning, hydrothermal unit commitment models (which schedule which generators run each hour subject to ramp rates and minimum up/down time constraints) generate tight feasibility boundaries that produce many branching infeasibilities; conflict clauses derived from these prune the search tree significantly on multi-period instances. In healthcare scheduling, operating room assignment models encounter infeasible subproblems whenever surgeon unavailability or recovery-bed overflow is triggered by a branching decision; each such discovery becomes a permanent cut. In supply chain network design, facility location models with tight capacity constraints generate conflict clauses early in the search, often cutting the effective tree size by an order of magnitude. In vehicle routing, time-window violations discovered during branching are natural candidates for conflict clauses that prevent equivalent infeasible route assignments from being explored again. The first question to ask when evaluating any published MIP implementation: is conflict analysis enabled, and what does the solver log show for conflict clause count?
- cuOpt LPFeas NVIDIA cuOpt became the first GPU solver to top a Mittelmann LP benchmark category, establishing GPU interior-point methods as production-viable for large-scale LP feasibility — relevant to any organisation running batch LP validation or scenario-screening workloads on existing GPU infrastructure.
- SDDP.jl v1.13.2 The new PAR tutorial in SDDP.jl addresses a practical calibration gap for energy practitioners modelling seasonal hydro inflows; the release requires no migration from v1.x and is a drop-in update.
- SCIP 10.0.2 Cut-based conflict analysis — SCIP 10's new mechanism for converting infeasibility proofs into reusable barrier constraints — is the same technique explained in today's Term of the Day, making this release a live practitioner demonstration of the concept.
- Benders Cut Filtering Filtering redundant Benders optimality cuts before pool insertion reduces LP solve time without sacrificing convergence on large decomposable MILPs — a concrete implementation improvement applicable to any existing Benders codebase on energy or supply-chain models.
- Surgical Scheduling MILP A MILP formulation with explicit overtime cost decisions produces provably near-optimal surgical schedules on real hospital instances, validating the approach for regulated healthcare environments where schedule quality carries direct patient safety implications.