# Time-Series-Based Supply Optimizer: notes on performance

As stated in blog ”Supply Optimizer: the Mathematics behind” the optimizer transforms the business scenario into a mathematical model representation – a mixed-integer linear program (MILP). This MILP is then solved via one of the best solvers available on the market. As the performance of the underlying algorithms strongly depends on the model structure and constraints, it is nearly impossible to make any predictions on the runtimes. Since the model depends on the concrete supply scenario and the used features, it is essential to start early testing on a realistic data set to avoid any larger remodeling at late stages in a project.

This article shows the typical performance influencing aspects and possible mitigation options for the supply optimizer. We present some performance information from our customer base and close with a comparison to APO SNP Optimization and explain how your scenario can help to improve the optimizer performance.

## Performance factors

The main factors are the size of the model, the used features and possible numerical difficulties:

(1) The size of a scenario is mainly defined by:

• the number of valid customer and product-combinations
• the number of valid location and product-combinations
• the number of periods in the planning horizon

For each period and location/product-combination one variable is required to represent the inventory level.
Additional variables represent the sourcing decisions, for example the transported or produced amounts.

Possible mitigation options: (4) + (5) + (6) in next section

(2) Some features require discrete decision variables which make the problem a lot harder to solve. They are used for these features:

• minimum lot-sizes
• incremental lot-sizes
• fixed costs

Especially incremental lot-sizes have a high impact as they require integer variables, for minimum lot-sizes and fixed costs ‘only’ binary variables are used.

Possible mitigation options: (1) + (5) + (6) + (7) in next section

(3) Some features require many additional variables.
The most prominent here is fair-share distribution, as there is one variable required for each segment for all the corresponding customer/products resp. location/products.
Late demand delivery is another candidate, as for each possible period of each demand that may deliver late an additional variable is required.

Possible mitigation options: (4) + (5) in next section

(4) Some features complicate the model by introducing constraints which cover many variables. Typical examples are widely used resources and aggregated constraints.

(5) Numerical difficulties arise when the range of related variables is very high and/or the range in the objective function is very high. Root cause is the floating-point representation: it has only a limited precision which yield in numeric issues due to the imposed inaccuracies. Often the solver requires a lot of time to cope with such inaccuracies and sometimes they can be seen in the results too.
For example, if some products are measured in kilograms and others in tons large coefficients can arise in production sources.
The range in the objective function is primarily defined via the costs. We see often very small values like 0.001 and in addition large values like 999999. With such a range the decisions based on the small coefficients have no significant relevance in the objective function and may therefore yield to unwanted results.
Large incremental lot-sizes have also a bad impact on the numerics as related constraint need to be scaled accordingly.

Possible mitigation options: (2) + (3) in next section

## Best practices

If you encounter performance issues, typically these changes help the most:

(1) Reduce the discrete decisions as far as possible. The easiest way for this is to use the discretization horizons to limit them to the first n periods.
Configuration details can be found in TS-Based Supply Optimizer => Optimizer Parameters => Discretization.

(2) Limit the numeric ranges:

• Keep the cost coefficient range as low as possible, especially don’t use very high cost-values like 99999999. For decisions the optimizer should adhere with a very high priority, it is recommended to use a value based on the highest cost in the model. E.g. if the highest costs are 100 for production, use 10 * 100 = 1000 for such highly rated decisions.
• avoid high global cost factors in the optimizer profile
• avoid high incremental lot-sizes

(3) Avoid minimum and/or adjusted values that can’t be satisfied. They can make up a huge portion in the objective function and cause numerical difficulties.

(4) Reduce the model size as much as possible. Typical options are:

• restrict the planning horizon
• Use subnetworks to optimize possible independent or just loosely coupled parts separately. For example, different factories can often be planned individually.
• restrict the number of fair-share segments as far as possible
• avoid late delivery over many periods
• avoid periods of supply, and maximum coverage over many periods

(5) Use time aggregation. Especially if planning happens on daily periods.

(6) Use product decomposition. See Note 3099058 – Getting started with product decomposition for more information on how to use this feature.

(7) Use local optimization. See also Note 3250159 – Local optimization for discrete problems for more information.

(8) Use the optimization expert consulting service. See SAP note 2427153 for more information.

## Performance numbers

The following table gives some examples from our customer base.

 Scenario 1 2 3 4 5 6 7 8 Mathematical properties #Continuous variables 1118213 2169704 3183937 73332 4213133 52940641 515368 17338547 #Binary/discrete variables 32072 0 9894 42756 3865 0 79146 323828 #Linear Constraints 901863 1526762 2653542 47265 2594364 42484856 369630 12771908 Business properties #Customers + locations 141 10681 206 16 156 1800 97 2901 #Products 1336 1382 606 114 277 5494 2171 2099 #Resources 90 394 17 4 40 536 128 166 #Demands 99 500252 496869 3957 71471 4426845 11495 3570461 #Periods in horizon 175 25 25 27 366 105 37 98 Discretization horizon 36 0 6 26 42 0 36 98 Used features Time aggregation X Late delivery X X X X Minimum resource consumption X X Delivery maximization X X Runtime (seconds) 25 81 359 182 1836 1539 7009 3842

Clearly the optimization runtimes don’t necessarily depend on the model size, typically the number of discrete decisions and numerical challenges are the more impacting factors. Due to the various influencing factors it is very hard to make any estimations about performance without a proof of concept.

## Comparison to APO SNP Optimization

We are often asked how the performance can be compared to the optimizer in APO SNP. In general, they perform relatively similar, in fact they share large coding parts. But due to different models and available features there are some differences. Some performance features of the SNP optimizer like decomposition techniques aren’t yet available in IBP. Due to the SAP HANA usage in IBP the necessary pre- and post-processing steps are usually a lot faster and the optimizer always has the latest performance improvements from us and our solver-provider.

## Final remarks

We are working closely with the solver-provider to tune and improve the performance on our typical models. Additionally we constantly seek performance improvements via model refinements and/or additional pre-solving steps. For this we are depending on a large set of typical scenarios. Therefore customers who are willing to let us use their models in an anonymized way are always very welcome! We will use these data sets for regular performance tests. This ensures also an early detection in case of performance degradations on specific scenarios. Please open an incident on component SCM-IBP-SUP-OPT to give us your consent and access to the necessary data.

### Assigned Tags

You must be Logged on to comment or reply to a post.

Very good Blog Carsten.

Thanks for sharing this information with us.

Thanks & Regards,

Hello Carsten,

We are working on fine tuning our Optimizer run, currently the run takes more than 8 hours for a product location combination of 2500. We are running the Optimizer with 26 weeks discretization on Transports and Production constraints.

I want to know if there is any internal product/resource decomposition happening? I was not able to see any in the trace file. I have run Optimizer with varying discrete horizons, i could sent the detailed analysis and the trace files if you need.

Could you please  suggest if any options for improving the run-time?

Thanks,

Amit

Carsten Schumm
Blog Post Author

Hello Amit,

no, there is currently no decomposition happening.

Have you set a runtime limit? Usually the optimizer finds good solutions relatively fast, but takes a long time to prove the optimality on discrete scenarios.
Please try shorter runtimes (e.g. 1, 2, 4 hours) and check the solution quality.

Please provide us your scenario via an incident on component SCM-IBP-SUP-OPT and give us your consent to keep it in an anonymized way. We'll also provide a short check of the scenario and give according performance tips via the incident, if applicable.

Thanks and kind regards,
Carsten

Thanks Carsten,

We did tested the Optimizer run results by gradually decreasing the run-times from 8-6-4-3-2 hours. The solution quality was consistent till 4 hours of run time, after that the demand and Inventory target fulfillment rates fell significantly at 3 hours and lower run times.

Thanks,

Amit

Hi Carstem,

A quick question, Have you ever tried running different time periods separately?

For example if 13 weeks Horizon of discretization, and 130 weeks in total of planning horizon.

If I run in one 13 weeks with discretization in one JOB and then the rest of the horizon is ran in another job without a discretization horizon. Would it make sense performance wise?

I know there would be some drawbacks in terms of overlapping periods. But if performance is being a pain in the neck, what do you think of this approach?

Would time aggregation with Months starting on week 14 makes more sense?

Cheers,

EI

Carsten Schumm
Blog Post Author

Hello Eddy,

theoretically that should work. But I have never tried it or heard from similar setups. Additionally the performance improvement is most likely not that large.
Usually time aggregation is used and the discretization is held to a minimum.

But if you see a performance improvement by running the discrete decisions separately and can cope with the effects on the overlap I see no issues.

Kind regards, Carsten

Hi Carsten,

I read somewhere that executing check mode operator before optimizer generates some internal subnetworks which accelerates the optimizer execution. Any ideas how this is done? are there any parameters to be mentioned in the profile? Any help will be highly appreciated.

Regards,

Zeeshan

Carsten Schumm
Blog Post Author

Hello Zeeshan,

I am not aware of any special handling in check mode before optimization.

The subnetwork logic is handled outside the optimizer. The optimizer only receives the relevant data for the current selection plus the dependent stuff from the border.