IBP Supply Optimizer with Discretization horizons fails all the time

[eddyizaguirre3]

• Hello Optimizer community,

I am running optimizer with different settings,

• Standard: Delivery Maximization or Profit Maximization, no Discretization horizons, no Fair Share
• Fair Share mode: Delivery Maximization or Profit Maximization, Fair Share, no Discretization horizons,
• Discrete mode: Delivery Maximization or Profit Maximization, Discretization horizons (13 weeks), No fair Share

The first two are running perfectly and are giving me intuitive answers. However, the discrete one is always failing and I have spent already a couple of hours trying to figure it out. Unfortunately I haven't found a lot of documentation about this and business log, even in explanation mode doesn't say much when it fails, it only says the optimizer failed to find a solution.

Here is what i've tried to do:

• Increase runtime to double (almost 30 minutes), I could increase it more, it's just it used to work in shorter time than that
• Check minimum, maximum and incremental lot sizes and compare them with other hard constraints like Maximum Key figures or Capacity

I know that if the first two modes run ok then the issue is in the lot sizes is just is hard to pinpoint the issue. Have anyone experienced this before, any guidelines of what or how to check in this cases would be greatly appreciated.

Thank you in advance!

[former_member654033 · Accepted solution]

Hi Eddy,

What is the reason of failure reported in optimizer business log?

Along with failure reason can you also check if you have left any field in discretization horizon as blank, if yes then put 0 against all such blank fields (Blank means complete discrete horizon and 0 means no discrete horizon). As you are trying to run 13W discrete then maintain 13 only for required discrete parameters that you may need and for rest maintain as zero.

Thanks

Girish

[eddyizaguirre3 · Accepted solution]

Hi Girish, thanks for your answer, this is what I have. Are you telling me that with this configuration I am taking my full horizon?

[former_member654033 · Accepted solution]

Hi Eddy,

Why do you need 13 week for all the discrete constraints as default 13, its adding too much of discrete variables in the optimization problem (90000+ Discrete variables). I assume you will need only for some of them.

Please update the discretization tab of your S&OP operator like defining the relevant fields as actual period and rest as zero and try again.

Maximum run time for any IBP Application job is 12 hours (43200 seconds), you can't run more than that due to limitation from backend.

Thanks

Girish

[eddyizaguirre3 · Accepted solution]

Hi Girish, I appreciate the clarification.

I will test this and also include Satish recommendations, including enabling the "Use finite heuristic as start solution". I hope the improvements are substantial after this.

I will let you know

[eddyizaguirre3 · Accepted solution]

Hi Girish,

I am using as you recommended only the variables that we need.

However, I still have a couple of warnings

Would you have an idea as of why i'm still receiving this warning?

Thanks

[former_member654033 · Accepted solution]

Hi Eddy,

What we have defined is correct, please refer SAP Help for details.

I have seen this message but always ignored as this doesn't make any sense. I would suggest raise the OSS message to get details from SAP on why this warning is coming when discretization horizon is defined as per SAP help page.

Please share if you get any inputs from OSS about this warning message.

BUT do you see any impact on optimizer planning results because of this warning? has your optimizer started running now?

https://help.sap.com/viewer/feae3cea3cc549aaa9d9de7d363a83e6/2005/en-US/74f362b10a5e475094e7a1f7416f...

Thanks

Girish

[eddyizaguirre3 · Accepted solution]

Hey,

It's taking too long yet, I would like to make it work in max 2 - 3 hours. The discretization horizon requirement is 13 weeks. I have done the following

• Remove 1 from minimum lot sizes and incremental lot sizes
• If minimum lot sizes = Rounding value of lot size, We are keeping only the Rounding value of lot size as it seems conditions are overlapping
• I used "Use finite heuristic as start solution" but didn't have a big impact and sometimes It didn't even respect the runtime when I used this option which I found odd

What I haven't tried yet are things like time Aggregation Profiles or Numerical Scaling. Which I will do today.

I will raise an OSS regarding what we have spoken and keep you on the loop.

Cheers,

EI

[former_member654033 · Accepted solution]

Hi Eddy,

Some question to understand your problem better.

- What is your master data summary and optimization variables reported in the optimizer business log?

- What are constraints you have modelled in your optimization problem?

- How many levels of BOM, which all cost key figure and other complexity you have which can potentially make this problem complex?

- Do you model discrete constraints at all levels?

- Currently you get no solution found or you get solution quality with high solution gap?

- What happens when you take a linear optimizer run, how long it takes?

- What happens from solution quality wise when you run optimizer for 12 hours?

- what are other warning messages reported in your optimizer business log?

- What is your planning bucket (Daily/TW/CW?)

- What is your planning Horizon?

Apart from simplifying your optimizer model, other option you have

- Use Expert settings (Read this SAP Blog written by Carsten -

https://blogs.sap.com/2020/01/03/expert-settings-for-ibp-supply-optimization/ )

- If no other available options then contact SAP, they may advice solutions including Product De-composition method.

Thanks

Girish

[eddyizaguirre3 · Accepted solution]

Hi Girish,

On my most complex scenario, that failed after 12 hours this is what I had.

• After cleaning up these warnings, plus using Finite Heuristic as Starting solution and Time Aggregation profile ( first 13 periods in weeks and rest Month), I can find a solution after 3,000 seconds. But the technical Gap is huge (99.8%). So for my next few tests I am checking if increasing significantly the runtime (close to 12 hours) will bring a solution gap near zero.
• A Linear optimizer run takes less than 6 minutes to run with a technical gap of 0%
• I can have up to 4 levels of BOM with production costs
• I am modeling Discrete Variables only at Production and Location source of supply, without fixed costs.

One way or another as you said, i'm hoping to get some SAP help for performance tuning. Also I'm not really sure as we discussed about the Use of Finite Heuristic as a start solution and it seems you are not a fan as well.

From your experience, do you think Product De-Composition might be needed?

Cheers,

EI

[former_member654033 · Accepted solution]

Hi Eddy,

Based on the warning messages

1. Please avoid Rounding value = 1

2. Check if you squeeze your cost model to reduce cost variations or try with Numerical parameters available in expert setting option.

3. Discrete variable is too high, you have to reduce them (First try with limited discrete parameters like only with Minimum Production lot size and then add others one by one). wherever it can be avoided, try your run without it. rounding value has more performance intensive compare to minimum lot size.

4. Check if you can break your optimizer run in smaller problems by using subnetworks.

5. check if you can go for higher planning time buckets to reduce discrete constaints total

if nothing works, either you have to trade off on some of the discrete constraints or have to try product decomposition approach with help of additional parameters from SAP.

Thanks

Girish

[eddyizaguirre3 · Accepted solution]

Hi Girish,

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?

I know there would be some drawbacks in terms of pre-building inventory, and I assume I would have to copy Projected Stocck KF in Stock on hand to make it happen, but not sure if you have tried something like this in the past.

Cheers,

EI

[former_member654033 · Accepted solution]

Hi Eddy,

I haven't tried this and I do not recommend this approach as it creates planning issues during overlapping horizon so not a best practice as per me.

the rest of 130 weeks are anyways linear so I don't think running them together/separately will create any performance difference

Even if you need to try that

1. take first run with longer horizon than 13 weeks as discrete + XX week as linear (If you have inputs in days like safety stock days for XX weeks) so you will need more number of weeks to have the correct calculation at end of W13 for inventory target, Projected inventory etc

2. Copy PROJECTEDINVENTORY of W13 as INITIALINVENTORY of W14 and take the second run starting W14 till end of planning horizon.

I hope this helps

Girish

[eddyizaguirre3 · Accepted solution]

Hi Girish,

That's what I thought as well,doesn't seem a good practice.

However, weirdly enough, the performance does improve in total ( 2 hours the whole horizon vs 1 Hour Two planning separately).

We did it for 13 weeks discrete and 13 weeks linear. I would think that is because it doesn't have to iterate between overlapping periods, and depends on lot size amount this may affect or XX amount of periods in the future.

Thanks for discussing this topic with me!

[eddyizaguirre3]

Thank you all for your answers and follow up,

We reduced a lot the runtime by cleaning the master data to the detail.with all your recommendations.

We need some tuning but i'm confident we'll get there,

I'll post other actions once we get where we want.

Cheers,

EI

[neeraj_deshkar1]

This could just be a performance issue. Try running Optimiser for just a single product. If it works then try increasing Optimiser run time or split subnetwork.

Observe no. of discrete variables in Optimiser log of each run.

-- Neeraj

[eddyizaguirre3]

I strongly believe as well that you may be right and is due to performance. We are trying with runtime limit of 999999999 and see what we have, for a full horizon of 130 weeks.

As an example for 15 periods (TW), this is what I have

Periods (TW)15

Number of variables 1,687,907

Linear constraints 1,037,830

# Discrete Variables 90,259

[SatishWaghmare]

Hello,

I suggest you to check following:

1. If possible, try increasing the Maximum Solving Runtime for Optimizer.
2. Discretization horizon of 13 weeks for all discrete decisions, I know there’s no guideline to the ideal number, but it’s always good to keep it as short as possible. Shorter horizon can prevent possible performance issues and more complexity into the model.

3. Review Minimum Lot Sizes and Rounding Values for Production and Transportation Lot Sizes. For Example if they are set to 1, then you could remove those. This will reduce the complexity.

4. Please enable "Use finite heuristic as start solution" option within TS Based S&OP Optimizer Profile.
Copied from SAP Help:
Use Finite Heuristic as Start Solution : You can use this switch to have the finite heuristic run before the optimizer. Just like the latter the finite heuristic considers resource capacities. If discrete decisions are involved in the scenario, the optimizer takes over the discrete decisions taken by the finite heuristic as start solution. Then it reevaluates those discrete decisions to make sure that all constraints from the relevant features are respected in a cost-optimal way. Using the finite heuristic as start solution can reduce the algorithm runtime, depending on the specific scenario.

4. Additional Reference : Please refer this blog for Best practices / recommendations

https://blogs.sap.com/2018/06/08/time-series-based-supply-optimizer-notes-on-performance/

Hope this helps.

Thank you

Satish Waghmare

[eddyizaguirre3]

Thank you Sattish! This is great I hadn't stumble with this on the help yet, I will introduce it in my tests, right now we are running a big one without this setting, I will check how much it will reduce the performance and let you know

[eddyizaguirre3]

Hi Satish, I Activated the option "Use Finite Heuristic as Start Solution", And I noticed that with this option the optimizer seems to not respect Maximum Solving Runtime for Optimizer (Seconds).

Has that happened to you?

Thanks

[SatishWaghmare]

Hi Eddy,

That's strange. I did not experience this issue.

The optimizer must respect the maximum solving runtime regardless of this option is enabled or not.

If no feasible solution is found within permissible maximum runtime then optimizer fails with error message in the log.

Thank you

Satish Waghmare