Solver timeout/cancellation on large batch of same-date demand orders (300–2000 SKUs)

[udayv1389]

Hello Community,

I am currently evaluating the frepple planning engine, testing both the Community Edition and the Enterprise Edition (trial). I have encountered a critical performance issue where the solver fails to complete or times out when processing a specific volume of demand orders with overlapping constraints.

When loading a sales order dataset containing between 300 to 2,000 demand orders all scheduled for the same date, the solver performance degrades significantly. These orders involve various SKUs but share common Bill of Materials (BOM) structures or resource requirements.

In these scenarios:

The solver takes an excessive amount of time to calculate a solution.
The process frequently times out or is manually cancelled after running for 7+ hours.
No solution is returned within a reasonable timeframe.

Is this something expected out of the system? I tried setting the parameter of fixBrokenSupplyPath to true, in my situtation, i don't have much broken supply chain and also tired setting minimumdelay parameter to a higher value, none of these helped in improving the planning run completion.

Your valuable suggestion or pointer would help.

Regards,

[jdetaeye]

It's normal that the planning time increases if the planning problem has tighter and interacting constraints. A run time of 7 hours is however not right.

Some suggestions:

• Set the parameter "plan.loglevel" to a higher number to get a more verbose log of where the solver is spending its time. A loglevel of 9 will create a huge log file in your case. Use the MAXTOTALLOGFILESIZE setting to control the size.
• Set (or add) the parameter "plan.minimumdelay" to a value to 86400 or higher to decrease the granularity of the search. The plan will be slightly less optimized, but the runtime can dramatically decrease.
• Some features are known to have an impact on the planning time as well; eg post-operation times at multiple levels, low values of the demand minshipment field, etc. The log file should provide some insights to unserstand where the solver is having a hard time with.

[udayv1389]

Hello Johan,

Thank you for sharing these suggestion.

plan.minimumdelay does not help much even increasing to 1 year, but what i did notice tough the performance bottleneck mainly occurs when it needs to replenish stock over and over again.

At the moment, since I'm starting out to understand the system better i have every plain setup without any post-operation or calendar assigned or not even any min and max qty for operations and defined safety stock limits expect for one or two, even these one or two i added after noticing from the log these item are in my deepest in my BOM hierarchy which is being shared across almost all of my demand items.

From the log, shared below sample snippet screenshot which i could noticed when running with some small subset where the material constraint is the biggest where it keeps trying to remove redundant operationplan.

Is there any kind of tip that we could utilize.

[jdetaeye]

If the search is inefficient, you'll see many loops trying to plan the same demand over and over again.
That's what you need to check for: why did the iteration N fail, and how is iteration N+1 better.

Another approach is to release some of the constraints: eg plan without purchasing lead time if you see the iteration-loops have to do with material shortages, eg mark some resources unconstrained if they appear continuously in the iteratio-loops.