Page 1 of 1

Unexpected planning results

Posted: Wed Jul 20, 2016 12:09 pm
by Martin.Schickbichler
Hello,

we have a use cases for xTour to plan several hundred TransportOrders (all TransportDepot instances) with a small number of vehicles. The vehicles have operating intervals on certain weekdays and go back to the depot every day.

First we noticed that in an experiment with about 1700 TransportOrders we get a result that makes full use of the first vehicle's operating intervals, while the other vehicles are only assinged TransportOrders for the first day (their first operating interval). This result is surprising as many TransportOrders are left unscheduled. We don't see why those TransportOrders can not be planned during free vehicle's operating times.

To facilitate debugging of the issue, we tried smaller experiments.

In an experiment with fewer TransportOrders (165) and only 2 operating intervals for each vehicle (on 2 separate days) we observe unexpected behaviour that might be related:
11 TransportOrders are left unscheduled while 2 of 6 vehicles are not assigned any TransportOrder during their second operating interval, only during their first one. We checked the coordinates of unscheduled TransportOrders, they are pretty close to the start/end depot, so those orders should be perfectly reachable during the free operating intervals of the two vehicles.

We use StandardParams with construction, middle sequencing and improvement step enabled (enabling the tour reduction step is worse: the first operating interval of the last two vehicles also remains unused and thus more orders stay unscheduled).

We already use GoalImportance to set the importance of the goal unplannedOrdersRank to 3 and the importance of all other goals to 1.

We tried the option maximumNumberOfUnscheduledOrdersToBeAnalyzed to get information on the unscheduled orders. For each of the 11 unscheduled TransportOrders we get a tour violation with the status UNSCHEDULED_DUE_TO_PLAN and a violation VEHICLE_OPERATING_INTERVAL for each tour.

We can't explain this behaviour with our input parameters.

The request we use for this experiment is request_sag_1.xml, the response is response_sag_1.xml, both can be found in the attached .zip file.

Are we forgetting to consider anything important? What are the options we can try?

Re: Unexpected planning results

Posted: Thu Jul 21, 2016 8:22 am
by Bernd Welter
Hello Martin,

I took a first glance at the scenario. From what I saw:
  • removing the AvailableMachineTime doesn't produce a better result.
  • about ten orders remain unscheduled while the trucks #5 and #6 are only 50% workload.
  • if I remove the trucks #1,#2,#3,#4 and all the scheduled orders our suspicious orders are planned successful
  • if I also remove the mondays from truck #5 and #6 the orders are scheduled on tuesday - as we would expect this from scratch
From my point of view there is no reason why the xTour couldn't schedule the orders in the original call.

So therefore I decided to forward this task to DEV and asked for quick help.

Best regards Bernd

PS: please be aware that the forum is not a chanel for problems on production! In this case you should always get in touch with support or your consultant!

Re: Unexpected planning results

Posted: Thu Jul 21, 2016 8:35 am
by Bernd Welter
Another interesting info:
The 6 vehicles are linked 1:1 to individual depots but the 6 depots have equal coordinates.
If I link the 6 trucks to the same depot the orders are planned 100%...

Re: Unexpected planning results

Posted: Fri Jul 22, 2016 8:24 am
by Joost
The issue is that there are multiple depots on the same location. Internally xTour will assign orders to a depot and then start the planning process with construction. This is done based on geography (short explanation, internally some more checks are done). What will happen is that a single depot will receive all the orders, although it only has very few vehicles. This causes a bad result coming out of the construction phase and the improvement phase can only improve so much.

You should make your depot geographical unique to avoid this issue.