7.7 Performance of solution method variants
This section briefly comments the performance of the solution method variants de- scribed in Section 6.7.
The method where the PP is solved as an MIP model that combines the train graph formulations for both directions has been implemented and tested. The solution method has shown to be very time consuming. The integer nature of the PP made it hard to solve especially for lines that share a single-track segment, spending more than a minute in some cases. Moreover, the less conservative approach of just enforcing symmetry in a few stations of the line increased the amount of feasible solutions and, logically, the arc density of the graph. It has been initially tested just for the lines running in the North-West corridor and the estimated average time to find an integer feasible solution for the three lines exceeded the hour. Therefore, the solution method has been discarded and not tested in the whole network.
The idea of starting with an initial pool of ”fast” line train paths has not yield any apparent benefit neither. Due to the symmetry gap allowed and time period, the amount of initial ”shortest paths” for each line is large (roughly O(2|T |K) and the double if the line is using the main old corridor) and the needed time to create them increased considerably. If a subset of them was considered (i.e. the line train paths exactly symmetrical between them), they were almost never part of the final solution, as the symmetry gap is usually used in the solutions to add flexibility to the solution and accommodate the combinations of lines easier. Therefore, it has been decided not to include any initial pool of line train paths in the solution method.
The suggestion of creating an MIP model that extends the current formulation by including the transfer times has shown more promising results. The model was tested by running the algorithm for one iteration until finding an integer feasible solution. Then, the model was extended including the variables to measure the transfer time and converted into an MIP model. In few best cases, the new solutions found, had an improvement of up to 1 % in the passenger travel time which can be considered significant. On the other hand, some cases shown that there was only one optimal solution, and the method did not provide any gain. Furthermore, the integer nature of the problem made it really hard to solve sometimes, especially when the number of columns and the constraints added by separation was high. As a result, this method does not seen attractive to be combined it with the proposed solution method for this study. Nevertheless, it showed potential for providing promising results and should be definitely considered for further studies.
Finally, the strategy proposed to avoid degeneracy has not shown any benefit. After a defined number of CG iterations, if the RMP objective value has not shown any improvement, the CG process is forced to terminate. Depending on the limit of iterations defined, two different outcomes were seen. If the number of iteration set as a limit was low (i.e. less tan 15) then the model tended to infeasiblity more often. If it was too high (i.e. more than 15), then the degeneracy was still present and no apparent gain is achieved. Moreover, from the results analyzed it is noticed that the amount of CG iterations performed is not significantly high and that the degeneracy
100 7 Computational results
CHAPTER
8
Discussion
This chapter conducts an overall discussion about the model and the case studied. The discussion is classified in different topics and for each of them, the limitations of the model are described as well as possible improvements and further studies are suggested.8.1 Modelling
It has been shown that the model is able to find good solutions to the network relatively fast. However, several aspect of the model can be further improved.
8.1.1 Algorithm running time
As it was shown in Section 7.5, more than 60% of the time of the algorithm running time is spent updating the weights of the PP graphs with the dual values related to the Headway constraints. Although this process has been accelerated several times along the implementation of the algorithm, there is still room for improvement. Currently, due to programming requirements, the dual values are included in all the out-going arcs of the related node. A way of boosting the process could be to include the value in the node itself. In this way, iterating over all the out-going arcs is not needed anymore leading to a significant save of time.
8.1.2 Extension of the problem formulation
The formulation of the problem solved by the current model only considers the mini- mization of the path lengths and the algorithm only includes the transfers implicitly based on the previous feasible solution. Since optimizing the PTT is the main focus of this study, including the transfer times in the problem formulation can imply a great advantage. As described in Section 6.7, an extension of the formulation is already presented. Nevertheless, it has been only tested as a post-process improvement rather than including it in the main formulation. The few tests performed showed a great potential for this type of formulation.
102 8 Discussion
8.1.3 Destroy method
The route of the passengers can change completely from one algorithm iteration to the next one. Forcing to have a transfer, that in the previous solution had a large flow, closer in the new solution, can require enlarging the train path in another segments and making the transfer not attractive anymore. Therefore, it cannot be said that there is a clear connection between the destroy method and the improvement of the PTT. However, the destroy method can be used with a different purpose when used in the planning system. Instead of using it as a destroy method that keeps the already found transfers in the next solution, it can be used as a tool to introduce specific transfer priorities. Similarly to the different headway scenarios tested, the destroy method can be used to test different transfer preferences in the network. In fact, the destroy method has already found good solutions were some transfer stations resemble a hub where a lot of possible transfers can be done within a small time interval.
The level of destruction of the solution is quite high. Practically the complete solution is destroyed at each iteration confusing the procedure with the Greedy Ran- domized Adaptive Procedures (GRASP) (Feo and Resende, 1995). However, the solution is not constructed using a greedy procedure and the destroy method does not destroy completely the solution. Still, implementing the model as a GRASP procedure could be explored given the performance of the destroy method.
Another option can be to include a second destroy method that destroys the so- lution in a different way. Examples of alternative destroy methods can consider, for example, only destroying specific lines or parts of them. The options are innumerable. Including multiple destroy or repair methods transforms the model from a LNS to an Adaptive Large Neighborhood Search (ALNS) (Røpke and Pisinger, 2006). This method keeps track of the performance of the destroy and repair methods and priori- tizes the ones that suit better to the problem. An idea of combining multiple destroy methods sounds interesting, however, these type of methods are more suitable for processes with a large amount of iterations which is not strictly the case.