The CP-SAT Optimizer Fell Back to Multi-Run: Causes and Fixes

When you select the solver-based optimizer but the run behaves like multi-run, the solver engine was not available in the host that executed the optimization, so the plan fell back to the multi-run engine on purpose rather than failing. EDGEBIC by User Solutions routes optimization to the engine you choose when it is present and defaults to multi-run when it is not, so selecting the solver can never leave you without a schedule.

This post covers the wrong-engine symptom in the EDGEBIC troubleshooting guide. It differs from why the optimizer returned the same schedule, which is about a run that produced no change at all. For what the solver engine actually does when it is present, see how the CP-SAT solver models your schedule, and for the scheduling fundamentals underneath both engines, what production scheduling is.

What You Are Seeing

You set the optimizer engine to the solver in the Options screen, ran optimization, and the result reads like the multi-run engine: it describes the best of a number of complete schedules it tried, with no optimality gap percentage. The plan improved, but the certificate is not the solver's.

Why It Happens

Cause 1: The Solver Engine Is Not Present in This Host

Engine selection checks whether the chosen optimizer is registered in the host that runs the optimization. If the solver engine is not present, the run falls back to multi-run rather than erroring. The setting is honored where the engine exists and safely ignored where it does not.

How to tell: the result carries best-of-N wording and no gap, which is the multi-run signature.

Cause 2: The Setting Did Not Save

Less common, but check it. If the engine selection in Options did not commit, the run used the default engine, which is multi-run. The symptom looks identical to the fallback.

How to tell: re-open Options and the engine selection is not the solver you expected.

Cause 3: You Are Reading the Wrong Signal

The two engines both produce a valid, improved plan. If you assumed a fallback because the numbers changed less than hoped, confirm by the certificate wording, not by the size of the improvement.

How to tell: the result actually reports a proven optimality gap, in which case the solver did run.

How to Fix It

• Run optimization from the host where the solver engine ships. The desktop application carries the solver; run there to get the solver behavior and its optimality gap.
• Re-select and re-save the engine in Options, then confirm the selection stuck before running.
• Read the certificate to confirm which engine ran. A proven optimality gap means the solver; best-of-N means multi-run.
• Accept the fallback when it is expected. In a host without the solver, multi-run is the correct, safe result, not a failure to fix.

How to Diagnose It, in Order

1. Read the result wording. Best-of-N with no gap is multi-run; a proven gap percentage is the solver.
2. Confirm the engine selection saved in Options.
3. Confirm you are running in the host where the solver is present, since selection cannot summon an engine that is not there.
4. Re-run and check the certificate again.
5. If multi-run is expected in this host, stop: the never-worse plan it produced is correct and safe.

How to Prevent It

• Know which host carries the solver engine, and run optimization there when you need the proven optimality gap.
• Verify the engine selection saved before a run, so the default does not quietly take over.
• Judge the run by its certificate, not its size. The engine that ran is stated in the result wording, not inferred from how much the plan moved.
• Rely on the fallback as a safety property. A selection a host cannot honor returns a valid, never-worse plan instead of an error, which is why optimization is safe to leave enabled. For the guarantee behind both engines, see the business case for risk-free optimization.