Comparing Two Optimizer Runs Before You Commit

Comparing two optimizer proposals means running one goal, recording its numbers, discarding, and running the second, because the optimizer holds one proposal at a time and Discard leaves your plan exactly as it was. That sounds like a workaround and it is actually the safest possible arrangement: every run measures against the same unchanged current plan, so the two results are directly comparable rather than stacked on top of each other.

EDGEBIC by User Solutions makes this cheap on purpose. A run costs the time budget you give it, typically thirty seconds, and it writes nothing. This post covers how to run a fair comparison, which numbers to record, and how to decide between two proposals that both look good.

Why sequential comparison is the honest kind

If you could accept one proposal and then run a second on top of it, the second run would be measuring against the first, not against your real plan. Its numbers would look smaller, because the easy wins were already taken, and you would have no way to compare like with like.

Running against the same baseline every time avoids that entirely. Discard drops the proposal and the database is byte for byte as it was, so the next run starts from the identical position. Both results are answering the same question about the same plan, and their numbers can be put in one table.

The one thing that breaks the comparison is data changing between runs. If actuals land from the kiosk or a colleague reschedules while you are working, the baseline moved and the two runs are no longer measuring the same thing. The product notices this at Accept time and refuses a stale proposal rather than overwriting, with a banner offering to rerun on the latest data. See optimizer staleness protection.

The comparison routine

Run the first goal. Pick a goal, pick a time budget, run. Read the verdict.

Record four numbers. Late jobs, weighted lateness in hours, makespan in hours, and the number of moves in the changes list header. Add setup hours if you have setup data.

Copy the Explain text. The Explain dialog produces a plain-language story in five sections and copies to the clipboard. Paste it somewhere before you discard, and you have the whole run captured rather than four numbers scraped from a table.

Discard. The plan is untouched.

Run the second goal and repeat. Then compare.

At the default thirty second budget, four goals take about two minutes plus reading time. That is a cheap way to see the whole trade space before disturbing anyone's day.

What a comparison table looks like

Using the documented worked example as the shape, a comparison sheet reads something like this:

Read it in two passes. First, did the goal deliver on its own terms? On-time first should show the best lateness numbers, Fastest overall finish the best makespan, Fewest changes the smallest move count, Least setup time the lowest changeover hours. If a goal did not win on its own measure, the plan is probably constrained by something sequencing cannot fix.

Second, what did each cost? The move count is the disruption price. Fourteen moves for an extra ninety minutes of plan span is a different proposition from six moves for the same gain, especially mid-week.

Deciding between two good proposals

Three questions settle most cases.

Which constraint is real this week? A customer date usually beats plan span. Plan span usually beats changeover hours unless changeovers are genuinely your bottleneck. If everything is comfortably on time and the plant is full, the shorter plan is the better buy.

How committed is the floor? On Monday morning nothing is set and a fourteen move proposal is fine. On Wednesday afternoon it is expensive, and the Fewest changes goal exists precisely for that situation because it only moves an operation when the gain clearly justifies the disruption. See the Fewest changes preset.

Does the move list contain anything you do not like? The numbers are aggregate and the move list is specific. A proposal with better totals can still contain one move you know is wrong, because the optimizer reasons from master data and master data does not know a fixture is out for repair. See reading the optimizer move list.

Comparing engines rather than goals

The same routine works for comparing the two optimizer engines on one dataset, though the engine is set once in Options under Schedule rather than per run.

The multi-run search reruns the scheduling engine with many different job orderings and returns the best complete schedule it found. Its badge reads best of N schedules tried, and it makes no claim beyond that honest search.

The mathematical solver additionally computes how far any schedule could possibly go, so its badge reports a proven optimality gap, with a gap of zero reading as proven optimal. Both engines are clamped never worse than your current plan, and both build plans that respect every capacity constraint.

Comparing them tells you something worth knowing: if the search and the solver land on the same plan and the solver proves the gap is zero, you know the search found the best answer, not just a good one. See choosing the optimizer engine.

Reproducing a run you discarded

Discard does not archive the proposal, but it does not need to. The search is deterministic: the same inputs with the same goal and the same seed produce the same candidates in the same order. Rerunning a discarded goal on unchanged data returns the same proposal, and the seed is recorded in the run's statistics so a support case can be reproduced months later. See deterministic schedule optimization.

What breaks reproduction is the data moving. That is not a defect, it is the point: a plan built on last hour's actuals should not be reproducible as if it were current.

The bottom line

Compare proposals by running one goal, recording late jobs, weighted lateness, makespan, and the move count, copying the Explain text, discarding, and running the next. Every run measures against the same unchanged plan, so the numbers are comparable, and nothing is written until you choose one and press Accept. Judge the winner by which constraint is real this week and how much disruption the floor can absorb. To try it, open the Optimizer tab in Schedule Jobs and run two goals back to back. For more, read the EDGEBIC optimizer guide and what happens when you discard an optimized schedule, and explore the platform at EDGEBIC.