Planning on two days

[melsner]

Hi,

we currently get some results from xTour-planSequence which are not as expected.
We know that there are alternatives to planSequence, but changing this is too much effort at this time.
So we plan a tour, passing an order with a fixed delivery date.
But as we don't know if the customer can be reached when starting the tour at the same day, we pass time windows that allow starting some days before.
For our example, it's a short way to the customer, and he can be visited from 6 am to 6 pm. So we would expect that the tour starts at the delivery date, visiting the customer, and return.
But xTour returns a tour that starts the day before, loads and then continues the next day, so the truck is at the unloading point exactly at 6 am.

Any idea why this is done? I would assume that the total time of the tour is minimized, so it is worse to split the tour over two days. What is the easiest way to force a single-day tour?

Best regards,
Martin

[Bernd Welter]

Hello Martin,

as described in https://xserver.ptvgroup.com/forum/view ... ?f=6&t=489 there are several goals we focus on:
- as few unscheduled orders as possible
- use as few ressources as possible
- short tours
- Tour end as early as possible
- Tour start as late as possible

In the concrete situation you refer to:
what happens if you restrict the vehicles abvailability = operating intervals to the day where you'd expect the to start the tour and to visit the 6to6 customer?

Maybe the KPIs of the output are less good as the ones you get at the moment?

Might be helpful to get the request/response to take a look at it.

Best regards,
Bernd

PS: did you ever try to use planBasicTours for this example? Would be interesting to see whether the additional "improvement step" could lead to the desired result or at least to some bette KPIs.

[melsner]

Hi Bernd,

no, we did not yet use planBasisTours.

Restricting the vehicle operating interval is no solution, as this would have to be done by the user; the tours are built automatically, and in general tours can start one or more days earlier if this is necessary. So the way would be: try with big flexibility (done by the system), check the result (done by the user), restrict to smaller time windows, try again. This is not optimal.

I attached a request and a response with a little example.
If we omit the first three time windows for the loading location, we get a shorter tour, which is curious, as in most cases less flexibility leads to worse results. I tested the case on two xServer installations, so I assume that there are no dependencies to any specific ini file settings.

Regards
Martin

[Bernd Welter]

Hello Martin,

Well, the question "what happens if" was not dedicated to be the solution but for analysis:

By pushing the scenario into this simulated constraint I wanted to get the the desired output and KPI to be able to compare both

Therefore please restrict it, gather new request and response and provide it.
I might have to add DEV to this topic then.

Best regards,
Bernd

[melsner]

Hi Bernd,

here the second try without the first three time windows.

Regards
Martin

[Bernd Welter]

Hello Martin,

I compared some of the two scenario's KPIs and the last event's schedule:

1. the unwanted result

Code: Select all

<ns4:result servicePeriod="6221" coDriverRequired="false" drivingPeriod="879" 
breakPeriod="14200" startTime="424800" period="32100" distance="11959" 
distanceFromFirstToLastTransportPoint="11959" maxDistanceBetweenTransportPoints="11959" 
restPeriod="10800" earliness="25000" waitingPeriod="0" transportPointCount="3" 
startTimeLatest="424800" depotUploadingPeriod="0" depotUnloadingPeriod="0" 
depotAvailabilityForDeliveries="0" tourChanged="false">
<ns4:TourEvent logisticPointId="0" startTime="456900" period="0" tourIndex="0">

2. the manipulated one

Code: Select all

<ns4:result servicePeriod="6221" coDriverRequired="false" drivingPeriod="879" 
breakPeriod="0" startTime="453600" period="7100" distance="11959" 
distanceFromFirstToLastTransportPoint="11959" maxDistanceBetweenTransportPoints="11959" 
restPeriod="0" earliness="0" waitingPeriod="0" transportPointCount="3" 
startTimeLatest="489400" depotUploadingPeriod="0" depotUnloadingPeriod="0" 
depotAvailabilityForDeliveries="0" tourChanged="false">
<ns4:TourEvent logisticPointId="0" startTime="460700" period="0" tourIndex="0">

Of course some of the KPIs are equal: servce period, driving period, distance...

I think the important one in the manipulated scenario is the final event's schedule:
By adding the additional intervals in scenario 1 it is possible to finish the tour at 456900 (=6.1.2019 / 06:55).
Scenario 2 finishes at 460700 (=6.1.2019 / 7:58).

According to the prio of optimization goals mentioned in this post this answers the question.

Best regards,
Bernd

PS: (dates derived from a base date of 1.1.2019 / 0:00)

[Mathias Leu]

Hello Bernd,

I am working with Martin within the project where this case occured.

For the topic you refered to we could find a list of optimization goals ("such as...") for the standard method, is the order of this list the priority of the goals?

We tried to influence the priority of the goals by setting the TourOpt.ini-parameter "CostFactors.TourPeriod" to 1.0, but this had no effect. Is there another way of influencing the priority (or did we use this a wrong way)?

Thanks and regards,
Mathias

[Bernd Welter]

Hello Mathias,

welcome on board of this project
The GOAL importance is relevant for the IMPROVEMENT phase which is not in use in planSequence.
That's one of the reasons why I recommend to use planBasicTours instead of the "quick but less flexible "planSequence".

Please also be careful with changing TourOpt.ini settings without prior contact to PTV DEV: those switches are not documented and only our developers know about potential consequences after changing them. Sometimes this might improve the output but it could also lead to side effects in other cases.

I'll ask DEV to join us here. Maybe we should push this topic to a 1:1 ticket between your project and PTV.

Best regards,
Bernd

[Bernd Welter]

SWITCHED TO 1:1 COMMUNICATION