Choosing the Optimizer Engine: Multi-Run or Solver

EDGEBIC ships two optimizer engines, a multi-run search and a mathematical solver, and you choose between them in Options under Schedule. The multi-run engine reruns the production scheduling engine with many job orderings and keeps the best complete plan, optimizing every job but making no claim of proven optimality. The mathematical solver models the problem and returns a plan with a proven optimality gap, but it optimizes only the jobs it models natively and locks the rest to the greedy plan. Both honor every constraint and both are clamped never worse than your baseline, so switching is always safe. If the solver is not installed in your deployment, the choice quietly falls back to multi-run.

EDGEBIC by User Solutions defaults to the multi-run engine and makes the mathematical solver a one-click alternative. This post explains how to choose, what each engine can honestly claim, and why the choice carries no risk. For the conceptual contrast, see the two layers of the EDGEBIC optimizer, and for the pillar, the EDGEBIC optimizer guide.

Where the setting lives

The engine choice is a policy setting, not a per-run toggle. Open Options, go to the Schedule section, and select the Optimizer Engine: "Multi-run search," the default, or the mathematical solver. Your choice persists until you change it, and it applies to every optimizer run until then. Because it is a policy rather than a display preference, it lives with the scheduling settings, not with the Gantt appearance settings.

The default is multi-run, which means an existing installation keeps the shipped behavior on upgrade unless someone deliberately switches it.

What each engine does

The two engines take different routes to a better schedule.

The multi-run search never builds a mathematical model. It reruns the same production engine that generates your live schedules, each time with a different global job ordering, scores every complete plan, and keeps the best. Because it stays inside the production engine, it handles every scheduling feature exactly as production does, and it optimizes every job. What it cannot do is prove how far from optimal the winner is. Its badge reads "Best of N schedules tried," an honest statement of a heuristic search.

The mathematical solver represents the problem as variables and constraints, solves the goal's measures in order, and returns a plan together with a proven bound on how close to optimal it is. That proof is its distinctive value. The cost is scope: it natively optimizes plain single-instance sequential jobs and locks any job using a feature it does not yet model to the greedy plan. Its badge can read "proven within a percentage of optimal," or "proven optimal" when the gap is zero.

Why switching is safe

The reason you can experiment freely is that both engines share the guarantees that make the optimizer trustworthy. Both respect every capacity, calendar, and routing constraint. Both are clamped never worse than your baseline, so neither can hand back a plan worse than the one you started with. Both persist nothing until you Accept. Switching engines changes how the search is performed and what the result can claim, never whether the plan is valid.

That means the honest way to choose is to try. Run one engine, read the result, Discard, switch, and run the other on the same plan. Compare the proposals and keep whichever you prefer, or Discard both. Nothing is at stake but the seconds each run takes. For the guarantee that makes this true, see what the never-worse guarantee means.

The safe fallback

There is one more reason selecting the solver can never hurt you. If your deployment does not include the solver component, choosing it does not fail or break scheduling. The selection quietly falls back to the multi-run engine, and you get a valid best-of-N result. Selecting the solver can only decline to it when the component is absent, never error out. If you pick the solver and still see the best-of-N badge, that fallback is why, and your administrator can confirm whether the solver component is installed. What happens when the CP-SAT solver is not installed reads that badge mismatch in full and lists which guarantees survive it.

Which to use

For most shops on most days, the multi-run default is the right choice. It optimizes every job, handles every feature exactly as production does, and returns a solid never-worse plan quickly. Reach for the mathematical solver in two situations. First, when you want the reassurance of a proven gap: a plan the solver certifies as within a small percentage of optimal, or proven optimal outright, carries a confidence the heuristic search cannot offer. Second, when your shop plays to the solver's native strengths, such as sequence-dependent setup on eligible work centers, where it can find changeover savings the greedy engine cannot see. See how the optimizer cuts total setup time and how the optimizer locks features it does not model.

The bottom line

EDGEBIC ships a multi-run search and a mathematical solver, chosen in Options under Schedule, defaulting to multi-run. The multi-run engine optimizes every job with a best-of-N badge; the solver optimizes the jobs it models with a proven-gap badge and locks the rest. Both are never-worse and constraint-honoring, so switching is safe, and selecting the solver falls back to multi-run harmlessly if it is not installed. Try both on the same plan and keep the result you prefer. To choose, open Options, Schedule, Optimizer Engine. Explore the platform at EDGEBIC.