Read the Solver Log Before You Blame the Model

Most people treat the solver log like a black box status report. They run the model, wait for the answer, and only look at the log when the solve fails. That is backwards. The log is not just something the solver prints while it is thinking. It is a record of what your formulation, your data, your bounds, your numerics, and your business assumptions are doing to the search.

In a real supply chain model, the log is often the first place the truth leaks out. The business says the model is too slow. The engineer says the solver is struggling. The analyst says the data looks fine. The optimizer says the formulation is correct. Then you read the log and realize the model has weak bounds, giant coefficients, an objective that is scaled like a phone number, constraints that barely cut anything, and a root relaxation that is basically telling the solver, “good luck.”

That is not a solver problem. That is evidence.

Start with the decision, not the runtime

Before touching parameters, ask what decision the model is making and what makes that decision hard. A production planning model with clean capacity constraints behaves very differently from a constrained allocation model with substitution, minimum presentation, inventory balance, lead times, service penalties, and thousands of nearly equivalent options. A routing model with crisp costs behaves differently from a replenishment model where tiny cost differences create massive symmetry.

The first question is not, “How do I make the solver faster?” The first question is, “What structure did I give the solver?”

A useful diagnostic conversation starts with questions like these:

• What is the actual decision: order, allocate, route, schedule, reserve, expedite, or cancel?
• Which constraints are physical and which are policy choices someone invented?
• Are there many equivalent solutions that look different mathematically but identical operationally?
• Are the variables bounded tightly enough to represent reality?
• Are costs and penalties on comparable scales?
• Is the model proving optimality for a business objective that is actually meaningful?

If you cannot answer those questions, the log will not save you. It will only expose the confusion faster.

What the log is trying to tell you

The root relaxation is one of the most important parts of the log because it tells you how much guidance the continuous relaxation gives the integer search. If the root bound is far away from the incumbent, the solver is starting with a weak map. That often means the model has loose Big-M values, missing linking constraints, poor variable bounds, or an objective structure that allows fractional solutions to look unrealistically good.

If the root relaxation is strong but the tree explodes, the issue may be symmetry, degeneracy, many close alternatives, or branching decisions that do not quickly separate good operational choices from junk. If the model finds good incumbents quickly but cannot close the gap, the problem might be acceptable from a business perspective even if it is not mathematically proven. If the model finds no incumbent for a long time, that is a different problem entirely. You may need a construction heuristic, a warm start, looser early constraints, or a simplified policy version of the model.

Do not treat all slow solves the same. A model that has no feasible solution, a model that has feasible solutions but no incumbent, a model that has incumbents but a weak bound, and a model that is numerically unstable are different diseases. They require different treatment.

A practical solver-log checklist

When a MILP is slow or unstable, I usually scan for five things before touching any fancy parameter.

First, look at model size and coefficient ranges. If matrix coefficients, objective coefficients, or bounds span too many orders of magnitude, you are asking the solver to reason with distorted economics. In supply chain models this happens all the time: unit costs, annualized penalties, binary activation costs, volume, weight, and service penalties get mixed together without normalization. The model may still be mathematically valid, but the numerical behavior can be ugly.

Second, inspect presolve. Good presolve reductions are a sign that the formulation has structure the solver can exploit. If presolve barely removes anything from a huge model, ask whether the formulation is too loose or too generic. If presolve removes a surprising amount, ask whether your data or constraints imply decisions you thought were flexible but actually are fixed.

Third, study the root relaxation and initial gap. A massive initial gap is usually not something a parameter will magically fix. It is often a formulation problem. Tighten variable bounds. Replace lazy Big-M logic with stronger linking constraints. Add valid inequalities that represent business physics. Separate facility-opening logic from flow logic. Do not make the solver discover obvious operational truths from scratch.

Fourth, watch incumbent discovery. If feasible solutions appear quickly, you may already have something valuable. In many business contexts, a 1% or 3% gap with a stable, explainable incumbent is more useful than a theoretically perfect solution that arrives after the operating window has closed. But if no incumbent appears, you need to help the solver find one. That could mean a greedy initial solution, a previous plan as a warm start, a relaxed model solved first, or a staged model that makes the high-level decisions before the detailed ones.

Fifth, check whether the gap is economically meaningful. A MIP gap is a mathematical certificate, not automatically a business risk measure. A 2% objective gap can be huge if the objective is profit on billions of dollars. It can also be irrelevant if most of the objective is artificial penalty cost used to steer behavior. You need to translate the gap into dollars, units, service impact, or decision instability.

The most common failure mode: tuning before diagnosis

The fastest way to waste time is to start changing solver parameters before understanding what the log is saying. Parameters matter. They can help a lot. But they are not a substitute for a strong formulation.

If the model has bad Big-M values, tune after you fix them. If the objective is scaled poorly, tune after you scale it. If the model has no good incumbent, give it one. If the formulation allows impossible fractional behavior, strengthen the formulation. If the business constraints contradict each other, run an IIS or conflict analysis before arguing about solver performance.

Tuning should come after diagnosis, not before it.

What to do in practice

For production models, I like to save solver logs with the run metadata: data snapshot, model version, parameter set, objective value, best bound, gap, runtime, node count, incumbent timestamp, and key business metrics. This turns solver behavior into an observable system instead of folklore.

That history becomes powerful. You can see when a new data feed made the model harder. You can see when a formulation change improved the root relaxation. You can see whether a timeout strategy is stable. You can see whether better incumbents actually improve business metrics or just improve the objective function. You can see whether a model that “usually solves in one minute” actually has a fat tail that breaks the operation every Friday.

The solver log is not noise. It is instrumentation. It tells you whether your mathematical model is aligned with the business physics of the problem. Read it before you blame the solver, before you blame the data, and definitely before you declare the model impossible.

A serious optimization system does not just produce an answer. It produces evidence that the answer deserves to be trusted.