every once in a while users of an optimization tool face some of the following conditions:
After an automated planning call one or more orders remain unscheduled or the result tour is supposed to be "not optimal" ("I guess I have a better sequence in mind"). Now the dispatcher wants to know the cause for such a result.
To support the search for the cause we offer two elegant mechanisms I'd like to draw your attention to:
#1: perform a so-called "UnscheduledOrderAnalysis". This will tell you about orders which remain unscheduled after a creative phase (such as construction or improvement)
#2: cross check whether "the better sequence" is really valid, i.e. whether it takes care of 100% of the given restrictions. If not: "it is not a better sequence" which means "the dispatchers assumption was wrong".
Now let's check #1 first:
Be aware that potential causes can be separated into the following categories:
- The order itself is the cause! No resource would be able to deal with the order because of insufficient skills, not matching opening times (or not both at the same time). This is UNSCHEDULED_DUE_TO_VEHICLES (The stop was not planned due to the vehicles. For example there was no suitable vehicle or there are already other stops in the tour.)
- Though there would be resources matching all required skills, opening times and capacity restrictions there is some other (global) restriction that prevents us from scheduling the order, e.g. there are too many orders at all so a tour would exceed an operating interval or maximum tour length. This is a UNSCHEDULED_DUE_TO_PLAN.
- Well: sometimes an order could be scheduled but we just didn't find the solution. Maybe the algorithm requires more time for an improvement phase or the heuristics just fail due to suboptimal processing sequence. This kind of a cause is called FEASIBLE: The stop is not scheduled in the input plan but it could be scheduled without a violation. The reason why this stop is not scheduled is most likely the fact that the construction step refuses to schedule stops that do not match some general conditions such as the maximum earliness. The improvement stop will schedule the stop then, so please switch on the improvement stop. Correction 17.5.2023: Even an active ImprovementStep does NOT guarantee that such a feasible order gets scheduled. This is because IMPRO is also just a heuristic!
- use the UnscheduledOrderAnalysisParams class in combination with an input plan and a set of order IDs
- or use the StandardParams (or any subclass) property maximumNumberOfUnscheduledOrdersToBeAnalyzed which will then determine and analyze some of the unscheduled orders.
Depending on the number of unscheduled orders to be analyzed the performance of a call may decrease.
#2 "better sequence": To evaluate whether the dispatchers assumption is right just provide the input plan based on the better sequence in combination with CalculationParams. Then check whether the output plan is violated (assumption was wrong) or not. In the later case our heuristics may just have failed.
Best regards,
Bernd
