TS-Based Supply Optimizer finishes before Maximum Solving Runtime with Technical Gap (1 iteration)

[vincentverheyen]

What could be the reason that a TS-Based Supply Optimizer (Profit Maximization Mode, Technical Weeks, Discretization of 20 weeks) finishes before Maximum Solving Runtime, with a Technical Gap (Average technical gap created by product decomposition > 2.7 ... e-05)?

How to reconcile this (the fact that there is a technical gap) with the # Number of subproblems in product decomposition solved to optimality being equal to the # Number of subproblems in product decomposition?

We switched on "Product Decomposition" as well as "Use Remaining Runtime for Non-Optimal Subproblems". Additional Parameter OPT/SNP_PRODUCTDECO/BUSEUPREMAININGRUNTIME is set to YES. "Pre-Optimization" is enabled. "Local Optimization for Discrete Problems" is set to "Use as start solution'.

We monitor that there has only been one iteration of the Planning Run. Why did the run not create more iterations &/or a longer Optimizer solving time, since there was a Technical Gap)?

In our case, the Optimizer solving time was 2500 seconds, which is far below the Maximum Solving Runtime for Optimizer maintained as 15000.

This is a case of MIP due to the lot sizes, while binaries are used for Minimal Lot Size and integers for Incremental Lot Size:
- Continuous Variables: 8 million
- Discrete Variables: 28000
- Binary Variables: 16000
- Linear Constraints: 2 million

Since this is MIP indeed we expect a parameter to decide when to stop searching for a solution, since there is no mathematically optimal solution like with LP. What is the cut-off parameter to determine when a solution is 'optimal' enough?

[carsten_schumm · Accepted solution]

Hello Vincent,

the optimality tolerance is 1e-6 (0,000.001) in IBP supply optimization. If we encounter numerical issues (e.g. infeasible or unbounded problems) we raise the tolerances to 1e-5 as a mitigation option.

The average gap in product decomposition is computed via the sum of all objective values and the sum of all objective bounds over all subproblems. Don't quite see how we can end up in >2.7 ... e-05 in your case. For a deeper analysis we'd need an according optimizer diagnosis file (probably best via a support case).

We don't offer a parameter to influence the tolerances, as changes here rarely result in improved solutions and often can cause other issues (infeasibilities for example). If you see here issues, an option could be to involve our optimization expert consulting (see note 2427153 for more information).

Kind regards,
Carsten

[vincentverheyen · Accepted solution]

@carsten_schumm Thank you for the clarifications. I have created Case 1011700/2024 for further investigation.

[carsten_schumm · Accepted solution]

(see other comment)

[carsten_schumm · Accepted solution]

Hi Vincent, thanks for the case.

As answered there, the technical gap for product decomposition is a percentage. I.e. 2.761e-05% = 2.761e-07 < 1e6 (optimality gap).