Simplify a network optimization

A useful simplification keeps the business question recognizable while making the calculation easier. Start with the decision you need: selecting a network footprint may need less detail than assigning every customer's orders. Keep the original workflow and inputs so that every proposed change can be compared with them. There is no universal ordering of expensive rules, and removing a rule does not guarantee a faster solve.

Find out what stopped progress¶

Read the run's outcome before changing the model:

Evidence	What it means for the next step
No feasible plan found before time ran out	The solver has not found a plan satisfying all requirements. It has not proved that none exists. Inspect the decisions, data and numerical scale before choosing a simplification.
A feasible plan was kept at the time limit	There is an answer to inspect, but it may be improvable. Decide whether improving the plan or proving its quality matters enough to spend more time.
Infeasibility was proved	The requirements conflict. Investigate the conflict; waiting longer on the same model does not repair it. A Debug mode result may relax requirements and is not a feasible plan for the original model.
A numerical, preparation or memory failure	Identify that failure first. A search-time increase does not necessarily help model construction, poor numerical scaling or memory exhaustion.

Settle what your business already knows¶

A model is often harder than it needs to be because it leaves open what your business has already decided, or blurs what it knows. Some sites are already contracted and others are ruled out. Operations can run only so many sites. A capacity was left at a placeholder. Customers have more detail than the decision needs. The plan only has to be within a few percent of the best. Telling the model these things makes it truer, and often much faster to solve.

Before a long solve, and again after one ends unproven, the run lists where this model's difficulty comes from: its open yes/no choices (optional sites, counts of sites or sources, minimum shipments, stepped costs), its level of detail, the size of its numbers, missing capacities and, after a solve, how close the plan is to the best possible. Each entry comes with the questions that would settle it and the input that records the answer.

Ask your agent to put the two or three most relevant questions to you before proposing any simplification. There are two kinds of answer:

A fact — "these 25 depots are contracted", "we run 33 to 38 depots", "that capacity is really 400 pallets". It corrects the model, so the plan stays valid for your business. Record it in the workflow and rerun.
A trade-off — "only these 65 sites are realistic", "group customers by region". It removes real alternatives or detail and can make the plan worse. Explore it in a separate variant and compare it with the original.

A question you leave unanswered changes nothing. The agent never fixes, shortlists, groups or caps anything you have not confirmed. Which questions matter depends on your data: on one network, a list of contracted sites proves the plan optimal in a minute; on another, narrowing the lanes makes it worse.

Start with one useful experiment¶

Ask your agent to establish the business decision and the requirements that must survive, then follow the path that matches the available evidence:

A saved plan exists: inspect Optimization Details, the objective and any penalties. Decide whether the plan is usable and whether the possible remaining improvement matters to the business before simplifying.
No saved result exists: start with the run diagnostics and the workflow. Inspect decision-generating settings, candidate sites and sources, demand, capacities, units and upstream transformations. Use only evidence actually returned; do not infer model counts, bounds or search progress from a timeout.

Propose one supported change, explain why it may help and whether it changes business requirements, and test it in a separate variant. Compare on the same business basis and check the original requirements before recommending it. The final section gives the full experiment checklist.

Use the sections below as needed: integer choices for a difficult search, aggregation when detail exceeds the decision's needs, and units and bounds when numerical warnings or suspicious magnitudes call for investigation. A slow run alone does not require every investigation.

Understand the plan's remaining uncertainty¶

Finding a good plan and proving that no better plan exists are different jobs. The incumbent is the best feasible plan found. A bound limits how good any plan could still be; the gap measures the remaining uncertainty between them. A large gap does not prove the incumbent is poor: the bound may be weak.

For example, in a cost-minimization model, a feasible plan costing EUR 102,000 and a valid lower bound of EUR 100,000 leave at most EUR 2,000 of possible improvement. This is an illustrative model, not a forecast of savings. For a profit-maximization model, the optimistic bound is an upper bound instead. Use the reported objective, units, status and bound together. Do not turn a profit gap into a percentage of transport costs. If the run does not expose a bound or quality estimate, say that quality is unproven; do not invent one. An optimal result is optimal for the submitted model, within solver tolerances, not proof that the model captures every business requirement.

Read Optimization Details when a result exists¶

Open the optimized scenario in Viewer, switch to Tables, then select Optimization Details. The report brings together the outcome, objective, solve effort, model size and numerics. An agent can inspect the scenario's Optimization details, Objective terms and, when present, Rules and Penalties tables through MCP. These are evidence from that saved solve; changing a workflow does not update an older scenario's report. A run that stops before publishing a scenario may have only run diagnostics. Missing statistics mean unknown, not zero.

Start with the outcome and objective. Proven optimal means the submitted model was solved within tolerances. A time-limited result with a feasible plan can still be useful; read its bound and gap before deciding to spend more time. For a weighted objective, the result is a score with the chosen weights, not necessarily a monetary saving. Objective Terms shows each value, weight and contribution so you can see what the solver was rewarded for improving. In Debug mode, inspect Penalties first: the bound and gap concern the loosened model, and a good gap does not make a loosened plan feasible for the original requirements. To say which rules shaped the plan, read Rules: a binding row is a rule the plan is paying for, and raising or lowering its bound changes the answer; a row that is not binding could be tightened up to its slack without changing it.

For an example, open the demo's European Wine & Spirits Optimized Plan. Its objective is to maximize profit, its objective value and best bound agree, its gap is effectively zero and it is marked proven optimal. Such a report gives no reason to simplify merely to find or prove a good plan. Read it for how a report is laid out, not for how large or fast your model should be.

A linear program (LP) lets quantities vary continuously, such as tonnes shipped, with linear costs and requirements. A mixed-integer program (MIP) also requires some decisions to be whole numbers or yes/no choices. The report's MIP gap is the remaining uncertainty described above for that integer solve.

Start the complexity assessment with integer decisions. Optimization Details reports the number of integer variables as well as the total number of variables. Integer variables include binary yes/no choices and whole-number counts. Their interactions are often the main source of difficulty in a mixed-integer model, so inspect them before treating the total variable or constraint count as the problem. The integer count is part of the total variable count, not added to it; compare the two to see what share of the model is yes/no or whole-number choices.

Model size before and after presolve

Measure	What it counts	How to read the two columns
Variables (total)	Every quantity or choice the solver can change, integer ones included	A large drop means presolve fixed or merged many of them before the search
Constraints	The requirements the plan must meet	Compare as built with after presolve to see how many were redundant or implied
Nonzeros	The coefficients connecting variables to requirements	Another view of the work and storage behind the model, before and after reduction

The reduction in total variables does not reveal how many integer decisions remain.

Variables are quantities or choices the solver can change. Constraints express requirements. Nonzeros count the nonzero coefficients connecting variables to those requirements: they give another view of the amount of work and storage behind a model.

Presolve is the solver's automatic simplification before the main search. When the after-presolve totals are well below the as-built ones, it removed substantial model structure while preserving the optimization problem. Inspect the reduced model as well as the original: removing input rows that presolve already eliminates may buy little. Conversely, little reduction is not proof of a bad model, and a smaller reduced model can still have difficult interacting integer choices. These totals do not identify which business rule is expensive; the agent must inspect the workflow and data.

Coefficient ranges

The report gives a smallest nonzero magnitude, a largest magnitude and the spread between them for four kinds of value: constraint coefficients, objective coefficients, variable bounds and constraint limits.

The spread is the largest magnitude divided by the smallest nonzero magnitude within that row. Constraint coefficients multiply quantities in the rules; objective coefficients price or weight decisions; bounds limit individual variables; constraint limits are the right-hand sides of requirements such as demand or capacity. Ranges use absolute values and exclude zeros and infinite bounds. The bounds row therefore does not say every flow is capped at one; it reports only the finite nonzero bounds in the solver model.

Read both the magnitudes and their spread. A modest spread can still contain very large or very small numbers. Different rows describe different parts of the model, often with different units; do not divide an objective coefficient by a demand limit to invent a conditioning score. Read the largest constraint violation beside the ranges; ranges alone do not establish a numerical problem or justify a unit conversion. The report's numerics verdict reads Worth checking when any row's spread is above a million to one, any magnitude is above a billion or below a billionth, or the largest constraint violation is above a millionth, and Healthy otherwise. Either verdict is a screening result, not a condition-number calculation or proof that the business data is correct, and neither stops a run. HiGHS does not report a condition number here. For the practical numerical checks, see “Improve numerics with sensible units and bounds” below.

Use the report to choose what to investigate next. The agent can interpret specialist effort statistics: branch-and-bound nodes are steps in the solver's search, not workflow nodes or network locations. Simplex iterations are steps in one method for solving the continuous part of the problem; neither statistic counts business decisions.

Evidence to read	What to investigate
A kept plan, best bound and MIP gap	Is the remaining improvement worth pursuing? A large gap can reflect a weak bound rather than a bad plan.
Integer variables and branch-and-bound nodes	Start here when investigating MIP complexity. Trace integer variables to the business choices that create them and identify how they interact. Many search nodes can motivate simplifying those choices; a few costly nodes can also take time. The count alone does not predict difficulty.
Model size before and after presolve	Is most detail removed automatically, or does a large coupled model remain? Test useful aggregation or pruning against the remaining business decision.
Solve time, available presolve time and simplex iterations	Where was solver effort spent? Solve time is not the whole workflow's elapsed time. Presolve time is unavailable for LPs, and missing time is not instant execution.
Coefficient ranges and largest constraint violation	Inspect units, unusually large bounds and tiny coefficients. Validate any conversion in the original business units.

An LP has no integer search, so absent MIP bound, gap and branch-and-bound statistics are expected. For either problem class, compare separate variants under comparable budgets and check feasibility and business consequences; no single cell in this report proves which simplification will help.

Rough guide to when counts and numerics deserve attention¶

Use these as screening heuristics, not limits or forecasts. Difficulty can appear well below these ranges; models with many more variables or much wider coefficient ranges can also solve successfully. Formulation, coupling, presolve, units, hardware and the time budget matter. The count bands below are planning prompts, not benchmarked SCMotif capacity limits. Actual slow progress, numerical warnings or unacceptable violations outweigh a reassuring count or range.

Counts: when to investigate structure or resource use

A continuous relaxation temporarily allows fractional integer decisions, such as half-open plants. Its answer helps bound what is achievable but may not be implementable. A weak relaxation gives an overly optimistic bound, leaving more alternatives for the solver to investigate.

Rough scale	What to do with it
Tens to hundreds of integer variables	Do not assume the model is easy. Even this scale can be difficult when choices interact strongly or the continuous relaxation is weak. Try the original model and inspect the outcome before simplifying.
Thousands of integer variables	Make a representative trial a priority before expanding the model. Inspect which sites, sources, minimum shipments or other choices create the integers, and which are actually needed for the decision.
Tens of thousands of integer variables or more	Plan a deliberate review of choices, coupling and formulation, alongside a resource and time-budget trial. Test justified fixing or shortlisting if progress is poor; a structured model at this scale may still solve quickly.
Around a hundred thousand variables or constraints, or millions of nonzeros	Check model-construction time and memory as well as search. Inspect the presolved size and sparsity. Large sparse continuous models can be easier than much smaller MIPs; these totals are not reasons on their own to aggregate or remove rules.

Integer counts here mean the reported count as built. Use the reported presolved totals to understand automatic reductions, but do not infer a remaining integer count from them. General integer variables with many possible values also differ from binary choices; the same count need not represent the same search problem. Moving to a lower band does not guarantee a speedup, and a higher band does not mean the run will fail.

Numerics: when to inspect units and bounds

Rough signal	What to read from it
Constraint-coefficient spread below about 10⁶ (a million to one)	Less concerning on this particular measure. Still check absolute magnitudes and reported violations; this does not establish good conditioning.
Spread around 10⁶–10⁹ (a million to a billion to one)	Review units and unusually large activation bounds before trusting the range as harmless. Try a mathematically equivalent scaling if justified, and compare feasibility and objective in the original units.
Spread around 10⁹ or above	Treat numerical scaling as a priority investigation. Check tiny coefficients beside large ones, placeholder capacities and weak bounds. A successful solve remains possible; this is a warning sign, not a rejection rule.
Bounds or constraint limits in the millions or billions; very small meaningful coefficients	Inspect magnitudes even if the spread is modest. Consider a scenario Unit of tonnes instead of kilograms, or money stated in thousands consistently across the data. Check tiny coefficients against the solver's handling of small values and tolerances; do not delete them just to improve the range.

The matrix-spread landmarks follow the rough advice in Gurobi's numerical guidance. They are general modeling guidance, not HiGHS settings. The report's Healthy or Worth checking verdict is drawn from landmarks of the same kind, and it refuses nothing. For objective coefficients, bounds and constraint limits, their meaning and absolute size matter as well as their spread. A weighted objective can intentionally span different scales; changing those weights to make numbers look nicer changes the business problem.

These are coefficient-range checks, not condition-number thresholds. Worse scaling or conditioning can still produce an accurate answer for a particular instance. Validate the returned plan in business units rather than accepting or rejecting it from these ranges alone.

Investigate at any scale if the solver reports numerical trouble, important balances or bounds are violated, or mathematically equivalent unit conversions produce materially inconsistent objective values or feasibility conclusions. Different routes alone are not evidence of trouble: there may be multiple equally good plans. Ask the agent to account for the solver's tolerances, translate differences into business units, and check them against the business requirements. Account for unfinished searches and their reported gaps too. A stalled incumbent or bound calls for a search/structure investigation; it does not by itself diagnose poor numerics.

Reduce choices that do not serve the decision¶

Continuous quantities let the solver adjust a little at a time. A yes/no decision forces a choice: open a site or close it, use a source or do not, ship nothing or at least a minimum quantity. These choices interact through shared capacity and demand, creating alternatives the solver must distinguish. A small model with difficult discrete choices can take longer than a much larger continuous flow model. Constraint count alone is a poor difficulty score.

To see why, imagine a temporary version of the model that allows half-open plants or fractional trucks. This continuous relaxation is easier to solve and helps the solver bound what might be achievable. But its answer may not be implementable. The solver must resolve integer choices while retaining valid bounds on unexplored alternatives. Shared capacities, sourcing rules and shipment minimums can couple these choices: deciding one changes what is possible elsewhere. A weak relaxation or many interchangeable alternatives can leave substantial search even when the integer count is modest.

Ask the agent which decisions create the integer variables in this particular model, rather than assuming each input row creates one. Prioritize unnecessary choices: fix decisions already committed by the business, remove alternatives proved redundant, or test a smaller set of genuinely undecided sites, sources or shipment options. Removing an integer variable is not automatically a speedup; formulation strength, bounds, presolve and numerical scale also matter. Allowing fractional decisions changes the model and may produce an unusable plan, so do not treat relaxing integrality as an equivalent simplification.

Inspect where those decisions actually arise. A single-sourcing requirement, for example, can introduce source-selection choices across customers and products. If the requirement only matters for a critical product group, propose keeping it there and allowing split sourcing elsewhere. This may reduce discrete choices, but it changes the sourcing policy: a cheaper plan may owe its savings to an operational freedom the business does not have. Check the current Add Constraint settings before claiming that a rule can be limited that way.

For site choices, distinguish genuinely undecided sites from those already committed by the business. Fixing a committed decision can remove unnecessary search. Fixing an undecided site merely because it looks promising is a restriction: it can exclude the best network or make the model infeasible. Similarly, dropping shipment minimums may remove on/off choices but permit shipments that cannot be bought or operated in practice.

Nearly interchangeable alternatives can create extra search with little business value. Remove an alternative without changing the answer only when you can establish that it is unnecessary under all relevant costs, capacities, service requirements and shared rules. A more expensive lane is not redundant if the cheaper route can fill up. Otherwise call the shortlist a heuristic, retain the excluded alternatives, and test sensitivity to putting them back.

Useful constraints can also make a solve easier: they rule out impossible choices and strengthen the solver's bound. Tight, valid physical capacities often help more than indiscriminately deleting constraints.

Match detail to the question¶

Grouping customers or products can reduce the flow quantities, choices and relationships that the model must consider. Group by the properties that affect the decision, not just by proximity or a convenient product label.

Customers grouped into a region should have compatible sourcing options and service requirements. Preserve total demand and examine how representative transport costs are calculated. A regional average can hide an expensive, remote customer or a capacity bottleneck. Products grouped into a family need compatible units, routes, resource use and production requirements; adding pieces of different sizes as though they were interchangeable loses meaning.

Aggregation normally trades detail for tractability. Solving the aggregate model does not prove that its answer can be allocated back to individual customers and products. Use it to screen strategic choices, then test those choices with the original detail and constraints. If you fix the strategic choices for that second solve, report that its optimum is conditional on those choices. Shared plants, lanes or budgets also mean that solving regions or products independently need not produce a feasible combined plan.

Time detail has the same trade-off in models that represent multiple periods: fewer periods can reduce repeated decisions, but hide peaks, inventory timing and seasonal capacity needs. Network Optimization currently represents a single planning period. Shortening its dates is not a way to remove time-indexed decisions. Changing the period changes demand and the matching capacity and cost assumptions; it may simply answer a different business question.

Improve numerics with sensible units and bounds¶

Start by asking the agent to identify any reported numerical warnings and translate reported violations into business quantities: how many tonnes exceed a capacity, or how much demand is left unmet? Assess those quantities against the actual operating requirements. A reassuring coefficient range alone is not enough, and an unavailable violation measure is not evidence of no error.

Solvers calculate with finite precision. Huge and tiny numbers together can make meaningful differences difficult to resolve. Sensible units can improve this numerical scaling without removing a decision.

Consider an illustrative bulk-flow model with 2,000,000 kg of demand and a transport rate of EUR 0.004/kg. The same shipment is 2,000 tonnes at EUR 4/tonne; the cost remains EUR 8,000. This gives the solver different numerical magnitudes while preserving the physical shipment and its cost.

The model is built in the scenario's Unit, set on the Create Scenario that feeds Network Optimization. Before the solve, every row's quantities, capacities, minimums and rates per unit are converted into it, using the conversions from Map Units & Conversions and the built-in metric steps. To rescale quantities, change that Unit, for example from kg to t; do not convert the data by hand. Changing the unit a row is uploaded in barely changes the model, because the row is converted anyway. A limit that states its own unit on a lane open to several products, or on an Add Constraint rule, stays in that unit. Results come back in the new unit, so compare them with the original in the same unit.

Money is not converted: Currency on Create Scenario labels amounts without converting them. To state money in thousands, change every cost, revenue, fixed cost and monetary limit in the data consistently. If an objective combines cost and emissions, preserve the intended trade-off.

Bounds matter too. An on/off relationship often needs a maximum possible quantity, sometimes called big-M. An unnecessarily large bound weakens the solver's optimistic estimate and can magnify tolerance effects. Supply a real, justified capacity when one exists, rather than a huge placeholder meaning “unlimited.” A bound that is too small silently excludes valid plans. Total customer demand alone is not always a valid bound on a lane: circulation and production can change what passes through it. Let the model derive its bounds from supported data; do not guess a solver coefficient.

Numerical tolerances accept small residual errors. After changing units, the same numerical residual can represent a different physical quantity. Check returned flows, balances, capacities and discrete decisions in the original business units, including small but important shipments. Rounding away small flows or loosening feasibility tolerances can change which plans are accepted; neither is an equivalent unit conversion. Tighter tolerances can cost time and do not repair poorly scaled data by themselves.

Further explanation: scaling and conditioning¶

Conditioning describes how much small numerical perturbations can affect a calculation. Coefficient ranges describe numerical scale; they do not measure conditioning. For example, two equations that impose almost the same relation can make a calculation sensitive even with ordinary-looking coefficients. Changing units can improve scaling but does not necessarily remove that sensitivity. This is why warnings and validation of the returned answer matter more than a range alone.

Choose the next experiment from evidence¶

More time is useful when a feasible plan is improving, its bound is improving, or the current budget is too short to make meaningful progress. Where only a final outcome is available, compare controlled runs rather than claiming to have observed search progress. An unchanged result after one longer run does not prove further time is useless, but it is a reason to investigate structure and scale. No simplification here promises a particular speedup.

Ask your agent to use this guide as follows:

Inspect the specific model. Read the workflow, upstream transformations, data and units, current node settings, and the run's diagnostics. Establish the objective and the business requirements that must survive. Distinguish observed evidence from a hypothesis about what makes the solve difficult.
Propose a concrete change. Name the affected step and data scope, why the change may help, what remains equivalent, and which decisions or detail would be lost. Verify that the current product supports the proposal. Ask the planner to approve any change to a business requirement.
Compare a separate variant. Keep the original, change one factor, and use comparable compute and time budgets. Record the outcome, time, objective, service, capacity use and reported quality where available. If no feasible plan exists, mark plan-dependent metrics unavailable. State whether objectives cover the same demand, planning period, units and objective definition, and identify any changed business rules. If they are not directly comparable, label the result as a changed scenario rather than claiming an improvement. Keep each bound and gap attached to its own model. Evaluate the candidate against the original requirements where possible; label savings that depend on relaxed requirements. For aggregation, check the detailed allocation. For scaling, compare in the original units.
Recommend with limits. Separate measured improvement from expected benefit. A small gap for a simplified model says nothing about the error introduced by simplification. Keep only changes whose business consequences are acceptable and whose result passes the relevant checks.

For example: “Your workflow allows each customer one origin for every product. If only the regulated products require it, we could keep that rule for those products and test split sourcing for the rest. This may remove source-selection choices, but changes the operating policy. I will first check which products the rule actually covers and whether shared capacities make the proposal useful.” That is a hypothesis to investigate, not a diagnosis inferred from a timeout.