4.3.1
Motivation
The final step in the approach proposed in Section 4.2 is a call to a local search
phase, which produces a schedule SLS. Now, even if the schedule was generated on
the extended, windowed model, all driver reliefs in SLS happen at precise time points.
Therefore, SLS is also a solution for a particular approximated model ALS, namely
that obtained by approximating all windows of relief opportunities by the times at
which the reliefs are taking place in SLS (inactive WROs can be approximated by
e.g. their arrival times). If cost(SLS) < cost(SGaS), it can be argued that ALS is a
better approximated model than the one derived from A, which was used in the GaS
phase.
The GaS approach has been very good in solving approximated models; in partic- ular, TrainTRACS is being successfully used by transport operators for their schedul- ing tasks. Therefore, if restricted to an approximated model, it may happen that GaS/TrainTRACS can perform better than the (somehow basic) local search we have implemented in this chapter. It may thus be wise to attempt solving the problem
for the approximated model ALS using GaS. Once this first loop-back to GaS is
established, it is natural to consider extending the idea to running GaS and local search in a loop, iterating until no further improvements to the approximation can be made. The algorithm is presented in the next section.
4.3.2
A Loop-back Version of the Algorithm
The loop-back version of the algorithm is presented in Figure 4.3. Again, an initial
set A1 of approximations is generated using the arrival times. GaS and Local Search
phases are then carried out in sequence. In step 5, a new set of approximations
Ai+1 is generated according to the times at which reliefs are taking place inside
windows in SLS
i , and the GaS and Local Search loop starts again with this new set
0. set i := 1; generate a set A1 of approximations for the WROs in the set of vehicle blocks B (using arrival times)
1. run Generate and Select on the model approximated by Ai,
obtaining a schedule SGaS
i
2a. run Local Search on an extended (i.e. non-approximated) model
for B, with initial solution SGaS
i , obtaining SiLS
2b. generate a new set of approximations Ai+1 for the windows in B,
based on the active relief opportunities in SLS i
2c. set i := i + 1; go to step 1
Figure 4.3: A loop-back version of the algorithm: a new set of approximations Ai+1 is generated
from the solution SLS
i obtained in the last call to local search, and fed back to the GaS solver
4.3.3
Experiments
We present two sets of experiments on the loop-back mechanisms to GaS. These provide initial evidence that the approach is viable, pointing out at the same time the main issues arising when implementing such a scheme.
One: Unconstrained GaS phases
On the first set of experiments, the only information derived from the local search
phase for the next call to GaS is that of the next set of approximations Ai+1. We
call these unconstrained experiments, because even if we know that solutions with specific cost values exist (we obtained them on the local search phase), we don’t force GaS to equal or better those costs. The results of a typical run are shown in Figure 4.4.
As shown in the figure, the behaviour of the loop is erratic. Since the local search is set to accept only cost-decreasing solutions for these experiments, it is intuitive to expect that the overall behaviour of the cost function during the loop is decreasing. The reason why this is not reflected in the actual results is that the GaS solver is not an exact algorithm, and some heuristics are built into it to speed up the CPU
80 81 82 83 84 85 1 2 3 4 5 6 7 8 9 10 number of shifts 685 690 695 700 705 710 715 720 1 2 3 4 5 6 7 8 9 10 total hours
Figure 4.4: Unconstrained experiments for the GaS and Local Search loop. The x-axis shows the number of iteration of the loop; the y-axis show two measures of cost, number of shifts and payable hours. The objective is to first minimize the number of shifts, and then the total payable hours.
times; for example, with the default settings the branch and bound phase will stop as soon as it reaches a “good enough” solution, which might not be the best that can be achieved if all branches are explored. It is still interesting to see that, even with these settings, the loop has been able to generate better solutions (iterations 9 and 10) than the one obtained on the first iteration. This supports the intuition that considering time windows would lead to more efficient solutions.
Two: Constrained Schedule Size on GaS Phases
For the second set of experiments, we added a hard constraint on the calls to GaS, specifying that the number of shifts in the final solution must not exceed the one obtained in the previous call to the local search. The results are shown on Figure 4.5.
The results show that GaS now enforces the max-schedule-size condition. How- ever, since there was no constraint issued on the total payable hours, the behaviour on that component of the cost is still erratic. It is easy to think of different ways of further constraining the GaS phase to control its behaviour. As an example, we
80 81 82 83 84 85 1 2 3 4 5 6 7 8 9 10 number of shifts 685 690 695 700 705 710 715 720 1 2 3 4 5 6 7 8 9 10 total hours
Figure 4.5: Cost-constrained experiments for the GaS and Local Search loop: schedule size and total payable hours vs. iteration number. While the constraint on schedule size succeeds in controlling the upper limit on size, the end result is worse than the one obtained when the constraint was not enforced. The algorithm is erratic when dealing with payable hours.
tried adding a constraint on the total payable hours; however, this seemed to render the solver unable to find a feasible solution. We don’t have a final explanation for this behaviour. However, we can think of several possible reasons for this; among them:
1. The local search solution is present at some node of the branch-and-bound tree, but a limit on the number of nodes to expand prevents the algorithm from finding it; this limit is currently set to 5,000 nodes.
2. Because the GaS solver we are using includes a preprocessing phase, in which some relief opportunities deemed not useful are taken out of the problem, it may happen that the solution found in the local search (and every other solution with equal or better cost) is actually left out of the solution space considered by the branch-and-bound phase (no matter how many nodes are visited). Forcing TrainTRACS to consider all ROs is not viable, because of the resulting increase in problem size.
3. Because the generation phase is artificially constrained to restrict the number of shifts generated, it might happen that some of the shifts in the local search solution are not available to the next phase of GaS. We can circumvent this problem by explicitly adding those shifts to the pot available for the selection phase; in fact, the choice of shifts to add is not restricted to those in the final schedule SLS
i , but could also include shifts generated during the search
process.
The reasons just described are quite independent from each other, and therefore it is possible that we have to tackle all of them before being able to get GaS to always find a solution that is better than or equal to the one obtained in the previous call to local search. However, tackling any of them would involve relaxing some heuristic rule which was originally added to make the execution time of the GaS phase feasible. This means that we must be intelligent in how to relax them, the way we solved the third problem being an example of that.