TS Supply Optimizer - Big internal calculated costs causing numerical issues

[eddyizaguirre3]

Hello Optimizer community,

I have a question regarding internal hard-coded or calculated costs in IBP time series optimizer with discretization horizons.

I am getting the following messages in the log

which I think is the main reason my discrete optimizer run has weird outlier peaks of value in the optimizer detail, probably making the runtime to take longer than needed.

I've triple checked my costs and even saw the Hana input trace files and I don't see those costs as an user input.

However, I do see them in the Hana trace output file as "FCALCULATEDHIGHESTCOST".

I have the feeling there is a constraint or something that is being broken and maybe I am triggering a violation cost, but nothing on the log is telling me that and I also don't have any adjusted/maximum/minimum key figures populated.

Does anyone knows what causes this and how to prevent it? Is there information where we know how big these internal violation cost are so we know what is triggering it?

Thanks for any information in advance! 🙂

[mkorndoerfer · Accepted solution]

Hi Eddy,

Such high costs can also come from discrete variables. For example, a product with production cost = 100 that has a rounding lot size of 200,000, that leads to a final cost of 100 * 200,000 = 20,000,000.
Because the optimizer can only produce a multiple of 200,000, the minimum production cost for this product should be the result of this multiplication.

If you, however, use a linear model, it's possible that the 96,000,000 is the pseudo-hard cost, result of the highest input cost of your model * 10. Meaning you should a cost of 9,600,000 in your model.

Best regards,
Matheus

[eddyizaguirre3 · Accepted solution]

Hi Matheus,

This makes sense to me. Because I am using a discrete horizon. I should have mentioned that.

Although this changes my understanding on the business logs then, so basically the cost the log is warning about, is not pointing to a specific value on a cost key figure per se, but an overall cost value resulting in the multiplication of a cost key figure and an output key figure for a time series bucket like a Production cost rate * Production receipts or Holding cost rate* Projected stock?

I did notice what you said, when I run it in in linear mode, the warning falls to 100.000

Thanks!

[mkorndoerfer · Accepted solution]

Hi Eddy,

Yes, in your case, the warning message refers to the highest cost as a multiplication of possibly one of the following calculations:

• Production rounding lot size * production cost rate
• Transportation rounding lot size * transportation cost rate

Please note it's the input cost multiplied by the input lot size - not with an output key figure. Because the costs are calculated before the optimization process starts, the optimizer still doesn't have the output key figures values.

To find out the combination with this high cost, you may look for the products with the highest rounding lot sizes - usually they're the reason. If you need assistance, you may create an incident under component SCM-IBP-SUP-OPT and share the optimizer dump, so we can take a look at it.

Best regards,
Matheus

[mkorndoerfer · Accepted solution]

An additional comment is your smallest cost of 5e-5. This is really small and it's likely coming from the inventory holding cost rate.

I'd also suggest you to review these storage costs and why are they so small. Maybe they can be increased or not used at all.
Just some food for thought.

Best regards,
Matheus

[eddyizaguirre3 · Accepted solution]

Thank you,

Yes I created the ticket just in case! You are right, I put those small cost to avoid having overflow. But they are increased now to reduce the gap.

Much appreciated your insights as always Matheus.

Cheers,

[raquel_melo]

Hi Eddy,

From the IBP optimizer log info we can conclude that the costs you are using on your model have very distant values and this can cause the mathematical error "numerical issues".

Models with numerical issues can lead to undesirable results such as poor performance, wrong answers or inconsistent behavior.

To avoid this situation you should review the optimizer input KF that you are using and adjust the values so that you dont have such big ranges. Avoid, for example, small values like 0.001 and in addition large values like 999999. Define a scale of 10 and try to adjust based on this.

Rgds

[eddyizaguirre3]

Hi Raquel,

Thank you for your answer! my problem is that I have checked all the costs and I don't find that 96.000.000 anywhere, I am very sure is not an input I gave the optimizer. This is why it surprises me to see it there on the logs.

From previous conversations with SAP consultants, I know there are costs that are internal and not visible to users, for example, the cost of breaking an adjusted key figure or a minimum one. But as I mentioned, so far I'm not breaking any because those KF are not populated

I opened a ticket to explore this also, I just wanted to check in the community if anyone else had experienced the same issues and gain some insights in the meantime. 🙂