TS Supply Optimizer using Finite Heuristic as Start Solution

[eddyizaguirre3]

Hello Optimizer experts,

As I start looking for ways to make a Discretization Optimizer, I thought about raising a question when we enable the option "Use Finite Heuristic as start solution".

We Know from SAP help that Finite Heuristic has some limitations. My question would be when use as starting solution for optimizer, is there any possibilities that my optimization "absorbs" any of the limitations for Finite Heuristic.

For example, the case of Co-Products, would ALL my co-Products and non-stocking products be safe even after enabling this option?

Thanks!

[carsten_schumm · Accepted solution]

Hello Eddy,

the not supported features of the finite heuristic don't limit the used features in the following optimization run.

In the worst case the optimizer may not be able to use the solution of the finite heuristic (e.g. due an infeasibility of a not supported feature).
But often the optimizer can find good solutions based on such start solutions faster than starting from scratch. The benefit is strongly dependent on the used scenario - therefore I recommend to just give a try on your model.

Kind regards,
Carsten

[eddyizaguirre3 · Accepted solution]

Hi Carstem,

Thanks for your answer, I have been trying this even since you suggested it, but I have found that every time I used it the solution goes way above the runtime limit set up in the S&OP Operator profile.

In attachment there is one of the many examples I can give you where that happens, this is after putting a runtime limit of 5400 seconds.

I understand that sometimes optimizer can go out of the way a couple more minutes to find an acceptable solution, but this is going one more hour above the runtime limit.

I have this theory in my head that the Finite Heuristic may take a long time to find a solution, and that the runtime limit is only being applied to the second optimizer run. I have been checking the help but there is no mention that this case can happen.

Is this normal? is it something that can be investigated with an incident?

Thanks!

[carsten_schumm · Accepted solution]

Hello Eddy,

you are correct: the runtime limit only applies to the optimization step. Any pre- and postprocessing does not reduce the runtime limit. Finite heuristic counts as a pre-processing step in that case.

Your description sounds like a performance issue in the finite heuristic that needs to be investigated. Please open an according incident and attach a corresponding optimizer diagnosis file.

Thanks and kind regards, Carsten

[eddyizaguirre3 · Accepted solution]

Hi Carsten,

Thank you! If i'm understanding what you are saying, the Finite Heuristic as Start Solution counts as a pre-processing step. Does that mean that expert setting Numerical Pre-Optimization parameters apply to it? Or are those again only for the optimization step only?

Regarding the ticket I will try a run today to generate the trace file.

Cheers,

EI

[carsten_schumm · Accepted solution]

Hi Eddy,

if the finite heuristic is used a start solution, it will run before the numerical pre-optimization step and it's discrete decisions will be considered there. The runtime portion for numerical pre-optimization isn't affected by any pre- or post-processing and relates purely to the provided overall runtime limit in seconds.

Cheers, Carsten

[former_member654033]

Hi Eddy,

Although I have never used this option in IBP Optimizer so far but I think finite heuristic still has a long way to go (Based on not supported list) before we can use this as first solution for optimizer.

Thanks

Girish