Embed Size (px)
Citation preview
A GENETIC ALGORITHM FOR THEVEHICLE ROUTING PROBLEM WITH
MULTIPLE CONSTRAINTS
by
David Gideon Conradie
Submitted in partial fulfillment of the requirements for the degree of
BACHELORS OF INDUSTRIAL ENGINEERING
in the
FACULTY OF ENGINEERING, BUILT ENVIRONMENT ANDINFORMATION TECHNOLOGY
Promotor: J.W. Joubert
UNIVERSITY OF PRETORIA
PRETORIA
November 2004
Declaration
Name of student: David Gideon ConradieStudent number: 21056472Name of project: A Genetic Algorithm for the Vehicle Routing
Problem with Multiple Constraints
1. I understand what plagiarism entails and am aware of the University’spolicy in this regard.
2. I declare that this final year project is my own, original work. Wheresomeone else’s work was used (whether from a printed source, the inter-net or any other source) due acknowledgement was given and referencewas made according to departmental requirements.
3. I did not make use of another student’s previous work and submittedit as my own.
4. I did not allow and will not allow anyone to copy my work with theintention of presenting it as his or her own work.
Signature: Date:
Executive Summary
Logistical costs within supply chains can be reduced through optimally schedul-ing and routing delivery vehicles. Properly scheduled vehicles boasts poten-tial supply chain cost reductions as shorter distances are traveled, less latedeliveries take place and vehicle maintenance costs are minimised.
To find an optimal route for delivery vehicles, the basic Vehicle RoutingProblem (VRP) is extended to include various additional constraints. Theseconstraints represent situations which often occur in supply chains and whichcomplicate the routing problem. It is arduous to solve the extended VRPwith classic Operations Research techniques, therefore heuristics are used togenerate near-optimal solutions for this problem. Currently there are fewalgorithms available to solve this logistics problem to address specific supplychain needs.
To address the problem of delivery vehicle routing and scheduling, thisproject presents a Genetic Algorithm (GA) to solve a Vehicle Routing Prob-lem (VRP) variation. The uniqueness of this GA lies in the amalgamationof multiple soft time windows, a heterogeneous fleet and double schedulinginto a single VRP solution algorithm.
The principles of natural evolution serve as a foundation for the GA thatwill find approximate optimal solutions for this VRP variation. The selectionof GA operators is based on a careful and intelligent analysis of literature inthe field of evolutionary programming. A path representation chromosomecoding, randomly generated initial solutions, biased roulette wheel selection,a newly developed merge crossover and non-uniform heuristic mutation isapplied in this “route first, cluster second” VRP solution algorithm.
The designed algorithm presented in this document was coded into aprogram with a Graphical User Interface (GUI). This program will addressthe need for a quality algorithm and will in so doing enable companies totake advantage of the potential supply chain cost savings.
The implementation of the GA program can create competitive advantagefor supply chains, consequently empowering them to become market leaders.
i
Bestuursopsomming
Voorsieningskanaal logistieke kostes kan deur middel van optimale roetebe-planning verminder word. Optimale skedulering van aflewerings voertuiehet die potensiaal om logistieke kostes te verminder aangesien korter afs-tande afgele sal word, voertuig dienskostes verminder sal word en minderlaat aflewerings sal plaasvind.
Om optimale roetes vir aflewerings voertuie te vind, word die basieseRoetebeplanning Probleem (RBP) uitgebrei om addisionele randvoorwaardesin te sluit. Hierdie randvoorwaardes verteenwoordig verskeie situasies watgereeld in die bedryf voorkom. Klassieke Operasionele Navorsings tegniekeondervind etlike probleme wanneer daar gepoog word om uitgebreide RBPeop te los. Heuristiese tegnieke word dikwels aangewend om die tekort vanklassieke tegnieke aan te spreek. Tot op hede is daar slegs enkele algoritmesbeskikbaar om die bogenoemde logistieke probleem op te los.
Om optimale roetes vir aflewerings voertuie te vind, word ’n GenetieseAlgoritme (GA) voorgestel om die uitgebreide RBP op te los. Die uniekheidvan hierdie GA le in die samevoeging van veelvuldige “sagte” afleweringsperiodes, heterogene voertuie en dubbel skedulering in ’n enkele RBP oploss-ingsalgoritme.
Die beginsels van natuurlike evolusie dien as grondslag vir die GA watpoog om optimale oplossings vir die bogenoemde RBP te vind. GA opera-teurs is gekies na ’n intelligente analise van GA literatuur. ’n Roetevoorstel-lings chromosoom-kodering, willekeurige begin-oplossings-generasie, subjek-tiewe roulette-wiel-seleksie, ’n nuut ontwikkelde “merge crossover” asook ’nnie-uniforme mutasie operateur word gebruik in hierdie oplossings algoritme.
Die algoritme wat in die dokument voorgestel word is in ’n rekenaarpro-gram omskep met ’n grafiese gebruikersintervlak. Hierdie program sal diehuidige behoefte vir ’n kwaliteit algoritme aanspreek en sal sodoende on-dernemings in staat stel om potensiele logistieke kostebesparings te benut.
Die implementering van die GA program kan kompeterende voordeel virvoorsieningskanale bied en hulle bemagtig om voorlopers in die mark te word.
ii
Nomenclature
DARP The Dail-A-Ride Problem is an example of a VRP including bothpick-ups and deliveries.
Double scheduling The occurrence of a single delivery vehicle complet-ing multiple routes within one day, returning to the depot to refill itscapacity after each route.
EER Enhanced Edge Recombination is a operator that performs crossoversin a Genetic Algorithm. It makes use of an enhanced edge list toperform the crossover.
EP Algorithms in the Evolutionary Program class emulates natural evolu-tion in the solution of optimisation problems. The Genetic Algorithmis an example of an EP.
EVRP Extended Vehicle Routing Problem. A VRP with various added con-straints.
Heterogeneous fleet A fleet of delivery vehicles with different capacitiesin terms maximum loading weight and volume as well as travel speed.
Heuristic An approximation algorithm to solve a problem by “trail and er-ror” when an algorithmic approach is impractical (Winston, 1994:526).
GA The Genetic Algorithm is a metaheuristic that produces good heuristicoptima by emulating the biological evolutionary process.
Logistics “The part of the supply chain that plans, implements and controlsthe efficient, effective flow and storage of goods, services and relatedinformation between point of origin and the point of final product con-sumption in order to meet customers’ requirements” (Council of Logis-tics Management).
Metaheuristic A strategy which guides other heuristics to search for feasi-ble global solutions.
iii
NOMENCLATURE iv
MX Merge Crossover uses a global precedence vector to perform the crossoveroperation in Genetic Algorithms.
OR Operations Research is a scientific decision making process that gener-ates the best designs for systems (Winston, 1994:1).
SA The Simulated Annealing metaheuristic emulates the annealing processof metals to solve optimisation problems.
SGA The Simple Genetic Algorithm uses binary representations combinedwith roulette wheel selection and simple crossovers to solve optimisationproblems.
Soft time windows A time specified by a customer in which the deliveryof goods must occur is a time window. Soft windows are applicablewhen delivery may take place after the specified time window, howevera penalty is incurred for late or early deliveries.
Supply Chain A set of organizations directly involved in the flow of prod-ucts, services, finances and/or information from the raw material sourceto the end customer (Blanchard, 2004).
TS Tabu Search is a metaheuristic which uses intelligent decision makingtechniques and certain forbidden moves to approximate global optima.
TSP The Travelling Salesman Problem is a VRP with one vehicle, the sales-person himself.
VRP The Vehicle Routing Problem assigns specific customers (who requirethe delivery of goods) to be serviced by a specific delivery vehicle.
VRPMC Vehicle Routing Problem with Multiple Constraints. A VRP withmultiple soft time windows, a heterogeneous fleet and double schedul-ing.
VRPTW The Vehicle Routing Problem with Time Windows includes cus-tomer specified delivery times in the VRP.
Contents
1 Research Problem 11.1 Problem Environment . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Aspiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Vehicle Routing 52.1 Basic Vehicle Routing . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 The Vehicle Routing Problem (VRP) . . . . . . . . . . 52.1.2 Complexity Theory . . . . . . . . . . . . . . . . . . . . 92.1.3 The Travelling Salesman Problem (TSP) . . . . . . . . 11
2.2 Vehicle Routing Problem Variations . . . . . . . . . . . . . . . 152.2.1 Additional Constraints . . . . . . . . . . . . . . . . . . 152.2.2 The VRP with Multiple Constraints . . . . . . . . . . 192.2.3 Extended VRP Model . . . . . . . . . . . . . . . . . . 202.2.4 Objective Function Variations . . . . . . . . . . . . . . 22
2.3 VRP Solution Methods . . . . . . . . . . . . . . . . . . . . . . 232.3.1 Optimal Solution Methods . . . . . . . . . . . . . . . . 232.3.2 Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.3 Metaheuristics . . . . . . . . . . . . . . . . . . . . . . . 26
3 GA Theory and Application 303.1 Genetic Algorithms (GA) . . . . . . . . . . . . . . . . . . . . 30
3.1.1 Evolutionary Programming(EP) . . . . . . . . . . . . . 333.1.2 Simple GA Example . . . . . . . . . . . . . . . . . . . 353.1.3 Mathematical Foundations: Schemata Theory . . . . . 393.1.4 Chromosome Coding . . . . . . . . . . . . . . . . . . . 433.1.5 Evaluation Functions . . . . . . . . . . . . . . . . . . . 453.1.6 Initialisation . . . . . . . . . . . . . . . . . . . . . . . . 45
v
CONTENTS vi
3.1.7 Operators . . . . . . . . . . . . . . . . . . . . . . . . . 453.1.8 GAs and the VRPMC . . . . . . . . . . . . . . . . . . 54
3.2 Programming Languages . . . . . . . . . . . . . . . . . . . . . 563.2.1 Investigation of Programming Languages . . . . . . . . 563.2.2 Suggested Language . . . . . . . . . . . . . . . . . . . 58
3.3 Environmental Analysis Outcomes . . . . . . . . . . . . . . . . 58
4 Conceptual Algorithm Design 594.1 GA Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2 Variables and Parameters . . . . . . . . . . . . . . . . . . . . 614.3 Main Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4 GA Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.5 Initial Solution Generation . . . . . . . . . . . . . . . . . . . . 634.6 Search Space Diversification . . . . . . . . . . . . . . . . . . . 654.7 TSP Solution Clustering . . . . . . . . . . . . . . . . . . . . . 654.8 Chromosome Fitness Determination . . . . . . . . . . . . . . . 664.9 Cloning Elites . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.10 Crossover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.11 Mutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Algorithm Development Reflection 715.1 Original Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 725.2 MX Crossover (based on Li) . . . . . . . . . . . . . . . . . . . 725.3 Cluster at End of Route . . . . . . . . . . . . . . . . . . . . . 735.4 Earliest Customer Clustering . . . . . . . . . . . . . . . . . . . 745.5 MX Crossover (based on ei) . . . . . . . . . . . . . . . . . . . 755.6 Constant Mutation Rate . . . . . . . . . . . . . . . . . . . . . 765.7 Previous Route Clustering . . . . . . . . . . . . . . . . . . . . 775.8 Local Optimisation . . . . . . . . . . . . . . . . . . . . . . . . 775.9 Time Window Compatibility . . . . . . . . . . . . . . . . . . . 78
5.9.1 Spare Time Compatibility . . . . . . . . . . . . . . . . 785.9.2 Overlapping Time Compatibility . . . . . . . . . . . . 795.9.3 Position of Incompatible Customers . . . . . . . . . . . 79
5.10 Alternative Selection Methods . . . . . . . . . . . . . . . . . . 805.10.1 Random Selection . . . . . . . . . . . . . . . . . . . . . 805.10.2 Random and Roulette Wheel Selection . . . . . . . . . 805.10.3 Reversed Roulette Wheel Selection . . . . . . . . . . . 80
5.11 Fast Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 815.12 Partially Matched Crossover (PMX) . . . . . . . . . . . . . . . 815.13 Diversification . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.13.1 Random Diversification . . . . . . . . . . . . . . . . . . 82
CONTENTS vii
5.13.2 Diversification using Mutation . . . . . . . . . . . . . . 835.14 Improved Initial Solutions . . . . . . . . . . . . . . . . . . . . 835.15 MX Crossover (based on angles) . . . . . . . . . . . . . . . . . 845.16 MX Crossover (based on angles and Li) . . . . . . . . . . . . . 855.17 Development Conclusion . . . . . . . . . . . . . . . . . . . . . 86
6 GA Variable Refinement 876.1 Convergence Speed . . . . . . . . . . . . . . . . . . . . . . . . 886.2 Number of Elites . . . . . . . . . . . . . . . . . . . . . . . . . 896.3 GA Operator Values . . . . . . . . . . . . . . . . . . . . . . . 896.4 Best GA Variation and Settings . . . . . . . . . . . . . . . . . 91
7 Graphical User Interface 937.1 GA Code Provided . . . . . . . . . . . . . . . . . . . . . . . . 93
7.1.1 Complete GA for the VRPMC . . . . . . . . . . . . . . 937.1.2 Fast GA for the VRPTW . . . . . . . . . . . . . . . . 93
7.2 Opening the GUI . . . . . . . . . . . . . . . . . . . . . . . . . 947.3 Operating the GUI . . . . . . . . . . . . . . . . . . . . . . . . 947.4 Execution Speeds . . . . . . . . . . . . . . . . . . . . . . . . . 97
8 Benchmarking 988.1 Solomon Problem Instances . . . . . . . . . . . . . . . . . . . 988.2 Developing New Benchmarking Problems . . . . . . . . . . . . 101
9 Conclusion and Review 1049.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049.2 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . 105
References 107
A Benchmarking Problems 112
B Best Known Solutions 113
C Customer Datafile Template 117
D Vehicle Fleet Datafile Template 118D.1 GA for the VRPMC . . . . . . . . . . . . . . . . . . . . . . . 118D.2 GA for the VRPTW . . . . . . . . . . . . . . . . . . . . . . . 118
CONTENTS viii
E MATLAB Code 119E.1 GUI Program (GAVRPMC.m) . . . . . . . . . . . . . . . . . . 119E.2 Main Program (VRPMCGA.m) . . . . . . . . . . . . . . . . . 120E.3 Seed Angle Calculation (seedangles.m) . . . . . . . . . . . . . 130E.4 Initial Solution Generation (initialise.m) . . . . . . . . . . . . 131E.5 Diversification (diversify.m) . . . . . . . . . . . . . . . . . . . 133E.6 Clustering (cluster.m and clusterfast.m) . . . . . . . . . . . . 134
E.6.1 cluster.m . . . . . . . . . . . . . . . . . . . . . . . . . . 134E.6.2 cluster.m . . . . . . . . . . . . . . . . . . . . . . . . . . 145
E.7 Fitness Calculation (fitcalc.m) . . . . . . . . . . . . . . . . . . 157E.8 Plot Fitness (plotgen.m) . . . . . . . . . . . . . . . . . . . . . 160E.9 Cloning (clone.m) . . . . . . . . . . . . . . . . . . . . . . . . . 161E.10 Crossover (crossover.m) . . . . . . . . . . . . . . . . . . . . . 163E.11 Mutation (mutation.m) . . . . . . . . . . . . . . . . . . . . . . 184E.12 Display Final Solution (finalsol.m) . . . . . . . . . . . . . . . 185
F Solomon Benhcmarking Results 187
List of Figures
1.1 Project Boundaries . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 The Basic VRP . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Problem Complexity Classifications . . . . . . . . . . . . . . . 102.3 The TSP with subtours . . . . . . . . . . . . . . . . . . . . . . 132.4 The TSP without subtours . . . . . . . . . . . . . . . . . . . . 132.5 Hard Time Windows . . . . . . . . . . . . . . . . . . . . . . . 152.6 Soft Time Windows . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Multiple Soft Time Windows . . . . . . . . . . . . . . . . . . . 162.8 Single Peak Problem . . . . . . . . . . . . . . . . . . . . . . . 242.9 Multiple Peak Problem . . . . . . . . . . . . . . . . . . . . . . 252.10 Local and Global Maxima . . . . . . . . . . . . . . . . . . . . 27
3.1 Chromosome Structure (Source: Thangiah et al. 1991) . . . . 313.2 Genetic Algorithm Flowchart . . . . . . . . . . . . . . . . . . 323.3 Biased Roulette Wheel for Selection . . . . . . . . . . . . . . . 363.4 Function Solved by Goldberg (1987:86) . . . . . . . . . . . . . 383.5 Function Solved by Michalewicz (1999:19) . . . . . . . . . . . 383.6 Function Solved by Michalewicz (1999:34) . . . . . . . . . . . 393.7 Simple Crossover (SXO) . . . . . . . . . . . . . . . . . . . . . 463.8 Double Simple Crossover (DSXO) . . . . . . . . . . . . . . . . 473.9 Delta Function Parameter Settings . . . . . . . . . . . . . . . 533.10 Cluster First Module (Source: Thangiah et al. 1991) . . . . . . 54
4.1 GA Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2 Variable Mutation Rate Graph . . . . . . . . . . . . . . . . . 70
5.1 Original GA Output . . . . . . . . . . . . . . . . . . . . . . . 735.2 GA with MX Output . . . . . . . . . . . . . . . . . . . . . . . 745.3 Clustering Order . . . . . . . . . . . . . . . . . . . . . . . . . 755.4 GA with Earliest Customer Clustering . . . . . . . . . . . . . 765.5 GA with Fast Clustering . . . . . . . . . . . . . . . . . . . . . 82
ix
LIST OF FIGURES x
5.6 GA with MX Based on Angles . . . . . . . . . . . . . . . . . . 85
6.1 Effect of pc and pm on Fitness . . . . . . . . . . . . . . . . . . 90
7.1 GUI Screen Shot . . . . . . . . . . . . . . . . . . . . . . . . . 947.2 GUI First Output Graph . . . . . . . . . . . . . . . . . . . . . 957.3 GUI Second Output Graph . . . . . . . . . . . . . . . . . . . . 96
8.1 Solomon Benchmarking Groups . . . . . . . . . . . . . . . . . 1008.2 Select Solomon Benchmarking Instances . . . . . . . . . . . . 1018.3 Generated Benchmarking Problem Solutions . . . . . . . . . . 102
List of Tables
2.1 Finite Number of VRP Solutions . . . . . . . . . . . . . . . . 72.2 Optimal Solution Time Classifications . . . . . . . . . . . . . . 92.3 Comparison of Complexity Classes . . . . . . . . . . . . . . . 11
3.1 Biological Evolution vs. Genetic Algorithms . . . . . . . . . . 313.2 GA Routing Applications . . . . . . . . . . . . . . . . . . . . 343.3 SGA Initial Population . . . . . . . . . . . . . . . . . . . . . . 353.4 SGA Preliminary Next Generation . . . . . . . . . . . . . . . 363.5 SGA Next Generation . . . . . . . . . . . . . . . . . . . . . . 373.6 ER Edge List . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.7 EER Enhanced Edge List . . . . . . . . . . . . . . . . . . . . 513.8 VRPMC and GA Settings . . . . . . . . . . . . . . . . . . . . 58
4.1 GA Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2 GA Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1 Impact of Population Size and Number of Generations . . . . 886.2 Influence of the Number of Elites . . . . . . . . . . . . . . . . 896.3 Optimal GA Variations and Settings . . . . . . . . . . . . . . 91
7.1 GA Execution Speeds . . . . . . . . . . . . . . . . . . . . . . . 97
8.1 Best Found Solomon Benchmarking Group Average Results . 998.2 VRPMC Benchmarking Problem Results . . . . . . . . . . . . 102
B.1 Best Published Solomon Benchmarking Results - C1 . . . . . . 113B.2 Best Published Solomon Benchmarking Results - C2 . . . . . . 114B.3 Best Published Solomon Benchmarking Results - R1 . . . . . . 114B.4 Best Published Solomon Benchmarking Results - R2 . . . . . . 115B.5 Best Published Solomon Benchmarking Results - CR1 . . . . . 115B.6 Best Published Solomon Benchmarking Results - CR2 . . . . . 116B.7 Best Published Solomon Benchmarking Group Average Results 116
xi
LIST OF TABLES xii
F.1 Best Found Solomon Benchmarking Results - C1 . . . . . . . . 187F.2 Best Found Solomon Benchmarking Results - C2 . . . . . . . . 188F.3 Best Found Solomon Benchmarking Results - R1 . . . . . . . . 188F.4 Best Found Solomon Benchmarking Results - R2 . . . . . . . . 189F.5 Best Found Solomon Benchmarking Results - RC1 . . . . . . . 189F.6 Best Found Solomon Benchmarking Results - RC2 . . . . . . . 190
Chapter 1
Research Problem
1.1 Problem Environment
Road transport and its associated problems have become a definite part ofour daily lives. The problems we are facing include road accidents, trafficcongestion and the pollution of the environment (Uchimura, Sakaguchi &Nakashima, 1994). These problems have a big effect on various businesses,especially on their supply chain logistical activities.
A variety of needs are introduced by these problems. There are economic,environmental as well as social pressures to address these needs (Potter &Bossomaier, 1995). The reduction in both the amount of traffic and latedeliveries are required to meet the needs, and consequently address the roadtransport problems.
In a supply chain environment, the total distance travelled by delivery ve-hicles and the amount of late deliveries can be reduced by optimally schedul-ing and routing these vehicles on a daily basis. The solution for the roadtransport problems lie in the improvement in delivery routes, as they aretypically far from optimal, leading to high logistical costs, more traffic andincreased pollution. The proposed solution has various advantages (Tan, Lee,Zhu & Ou, 2001a):
• Less road accidents, traffic congestion and pollution, since:
– Total travel distance is reduced.
– Less time is spent on the roads.
– A minimum amount of vehicles travel the streets.
1
Research Problem 2
• Supply chain performance is increased by:
– An increase in on-time deliveries, leading to higher customer ser-vice levels (Coyle, Bardi & Langley, 2003:97).
– A decrease in maintenance costs.
– The possible reduction in delivery vehicle fleet size.
Having established that more efficient routes are required, the VehicleRouting Problem (VRP) is solved to optimally route delivery vehicles.
1.2 Problem Statement
A Genetic Algorithm metaheuristic is to be conceptually developed and codedinto a computer program to solve the routing problem with multiple softtime windows, a heterogeneous fleet and double scheduling. This shouldaddress the problem that the VRP with the above mentioned constraintscan currently not be solved satisfactorily.
1.3 Scope
The placement of this project within the general business world is illustratedin Figure 1.1.
Figure 1.1: Project Boundaries
Research Problem 3
The scope of this project regarding the routing problem with multipleconstraints can be defined as follows:
• Solve VRPs with the following characteristics:
– No maximum number of customers
– No maximum number of delivery vehicles
– No maximum on the number of different vehicle capacities
– Multiple soft time windows
– Heterogeneous fleet
– Double scheduling
• Solution method limitations:
– A Genetic Algorithm will be used, although relevant adaptationsmay be made.
– To be computer coded in the most relevant programming lan-guage.
This scope sets high, yet reachable targets in terms of objectives and spe-cific deliverables. These targets are believed to drive superior performance.
1.4 Aspiration
Aspiration is a strong desire to achieve an end. To capture what is desiredin this project, the aspiration can be expressed in terms of a goal, objectivesand specific deliverables. These three items are required to keep the projectexecution on the correct and desired supply chain focused track.
1.4.1 Goal
The goal of this project is to develop and program a Genetic Algorithm meta-heuristic for the swift and accurate solution of routing problems includingvarious additional constraints.
1.4.2 Objectives
The objectives set out for this project:
• Analyse and comprehend literature concerning the following topics:
Research Problem 4
– Routing problems
– Metaheuristics (relevant to complex VRPs)
– Genetic Algorithms
– Comparison of metaheuristics in the routing environment
• Develop a detailed conceptual GA to solve the problem set out in theproblem statement.
– The GA should solve VRPs as limited by the scope.
– The algorithm should incorporate the following aspects:
∗ Clones1 (Rardin (1998) refers to Elites)
∗ Immigrants2 (Rardin, 1998:696)
• Code the conceptual algorithm to solve practical routing problems.
• Analyse and compare the solutions generated to those of other relevantrouting algorithms.
The aspiration addresses the problem definition as it will provide a Ge-netic Algorithm that will be capable of solving the extended supply chainvehicle routing problems in a satisfactory and customer focused manner.
A theoretical framework of the project is provided by the literature study(discussed in the next two chapters) which addresses vehicle routing and thetheory and application of Genetic Algorithms. The conceptual designed ofthe algorithm will then be discussed. A reflection of how the algorithm wasimproved is given, after which the process that was used to refine the al-gorithm’s input variables is shown. A short user’s guide pertaining to thedeveloped Graphical User Interface (GUI) is then included. The comprehen-sive benchmarking that was done is then discussed before final conclusionsand suggestions for further research is made.
1The best solutions are copied from the previous generation to the next generation.2Randomly chosen solutions are added to the next population. Immigrants and muta-
tion both avoid local optima.
Chapter 2
Vehicle Routing
2.1 Basic Vehicle Routing
2.1.1 The Vehicle Routing Problem (VRP)
The basic Vehicle Routing Problem (VRP) assigns specific customers to beserviced by a specific delivery vehicle (Rardin, 1998:592). A simple, genericrouting scenario is illustrated in Figure 2.1, with circles representing cus-tomers (n per route), where each customer is included in one of m routes.Vehicles travel from the depot, visit one or more customers and then returnto the depot (Salmon, 2003:6).
A model used to solve the basic VRP is shown in various pieces of liter-ature (Filipec, Skrlec & Krajcar, 1998; Hwang, 2002; Salmon, 2003:7) andcan be formulated as follows:
Decision Variable:
xijk =
1 if vehicle k travels from node i to j, where
i, j ∈ {1, 2, ..., N |i 6= j}, k ∈ {1, 2, ..., K}0 otherwise
(2.1)
Input Parameters:dij = Distance between node i and j, where i, j ∈ {1, 2, ..., N}N = Total number of customers to be visitedK = Total number of vehicles in fleetqi = Known demand for node i, where i ∈ {1, 2, ..., N}Q = Capacity of vehicles
5
Vehicle Routing 6
Figure 2.1: The Basic VRP
Model:
MinimiseN∑
i=0
N∑j=0j 6=i
K∑k=1
dijxijk (2.2)
Subject to:
N∑i=1i6=j
K∑k=1
xijk = 1 ∀j ∈ {1, 2, ..., N} (2.3)
N∑j=1j 6=i
K∑k=1
xijk = 1 ∀i ∈ {1, 2, ..., N} (2.4)
N∑i=0
K∑k=1
xipk =N∑
j=0
K∑k=1
xpjk ∀k ∈ {1, 2, ..., K}, p ∈ {1, 2, ..., N} (2.5)
N∑j=1
x0jk =N∑
i=1
xi0k = 1 ∀k ∈ {1, 2, ..., K} (2.6)
Vehicle Routing 7
N∑j=1
K∑k=1
x0jk ≤ K (2.7)
N∑i=1
qi
N∑j=0
xijk ≤ Q ∀k ∈ {1, 2, ..., K} (2.8)
xijk ∈ {0, 1} ∀i, j ∈ {1, 2, ..., N}, k ∈ {1, 2, ..., K} (2.9)
The objective function in (2.2) minimises the total distance travelled byall vehicles. Constraints (2.3) and (2.4) ensure that each customer is visitedexactly once. Equation (2.5) ensures route continuity by making sure thatwhen a vehicle enters a node it must also leave that node. Equation (2.6)enforces the rule that all routes start and end at the depot. The maximumnumber of vehicles assigned is limited to the fleet size in (2.7). Constraint(2.8) ensures that the demand for an entire route does not exceed that route’svehicle’s capacity, while (2.9) defines x as a binary variable.
This VRP has a finite number of feasible solutions (Nygard & Kadaba,1991) and is thus a combinatorial optimisation problem (Winston, 1994:519).Table 2.1 illustrates the combinatorial nature of VRPs by listing all possibleroutes (order unimportant) for 2 vehicles in a 3 city VRP.
Table 2.1: Finite Number of VRP Solutions
Solution Vehicle 1 Vehicle 21 - 1 2 32 1 2 33 2 1 34 3 1 25 1 2 36 1 3 27 2 3 18 1 2 3 -
Assumptions
The way in which the basic vehicle routing problem is modelled includes anumber of basic assumptions:
• All customers are visited only once per day.
• A customer can be visited at any time during the day.
Vehicle Routing 8
• Customers have a constant known demand.
• Each delivery vehicle completes one route per day.
• A homogeneous delivery vehicle fleet with vehicles having the samecost, capacity and speed are used.
• A single depot serves all the customers.
It is important to acknowledge these assumptions as they can limit theapplication of the basic routing problem.
VRP Applications
The VRP is applied in various business areas to optimise different processes.The wide application of the problem indicates the importance of having tosolve the vehicle routing problem optimally. Louis, Yin & Yuann (1999) listsvarious business areas where the VRP is applied, including:
• Delivery areas:
– Bank
– Postal
– Retail items
– Overnight delivery services
– Suppliers’ deliveries (Salmon, 2003:6)
• Pick-up applications:
– Industrial refuse removals
– Collections from suppliers
– Timber collection (Karanta, Mikkola, Bounsaythip, Jokinen &Savola, 1999)
• Scheduling environments:
– Passenger operations (e.g. airlines, railways and bus routing)
– Rolling batch planning in steel factories (Chen, Wan & Xu, 1998)describe this type of problem and models it as a VRP with timewindows - whilst previously the basic VRP was insufficiently usedto model this kind of problem)
– Advanced fighter plain mission planning systems (Pellazar, 1994)
– Power distribution planning of electrical power supply betweenmain and substations (Filipec et al., 1998)
Vehicle Routing 9
2.1.2 Complexity Theory
The Complexity Theory’s roots lie in the fact that there are some problemsthat cannot be optimally solved within practical time limits. Heuristics areused to find an approximate solution for these problems, rather than attempt-ing to solve them optimally. The complexity of various problems needs to bestudied to provide a guideline to specify whether optimisation or heuristicalgorithms have to be used to solve different types of problems.
If an algorithm will eventually converge to an optimal answer, it is oftennecessary to know how long it would take the algorithm to converge. Abubble-sort algorithm sorts data by swapping two entries if they are not inthe correctly sorted order. Given that there are n data pieces to sort, thealgorithm will have to make n2 comparisons during its execution. If the dataoriginally was in the correct order, the algorithm will make n comparisons.
Computational difficulty is often expressed in order of time, indicatedwith an O. Based on the bubble-sort algorithm’s worst-case scenario, it canbe classified as an O(n2) algorithm. This means that there is a n0 and someconstant c such that (when n0 ≤ n) the number of computations needed foran optimal solution is less than c · n2.
Algorithms that are O(n2) have computational times which are bound bya polynomial order (the power of 2). These algorithms are then consideredas being efficient and useful to optimally solve problems (within acceptabletimes). Table 2.2 classifies the validity of optimally solving problems withvarious different orders.
Table 2.2: Optimal Solution Time Classifications
Order Solved OptimallyO(n2) Efficient and usefulO(n3) Highly usefulO(n4) WorthwhileO(n5) WorthwhileO(ni) ∀i ≥ 6 InefficientO(cn) Inefficient
Problems are classified in terms of their computational complexity. Thetwo main complexity classes are NP and NP-hard. Most problems aregrouped into the NP class. A problem is classified as NP when a solu-tion of the problem can be verified in polynomial time (the solution canbe generated in either polynomial or non-polynomial time). A problem is
Vehicle Routing 10
NP-hard if solving it in polynomial time would make it possible to solveall NP problems in polynomial time (FOLDOC, 2004) (i.e. the problem isnot known to be solvable in polynomial time). NP-hard problem solutionalgorithms are known to require inordinate computational times (Winston &Venkataramanan, 2004:800). The NP and NP-hard classes are not mutuallyexclusive (FOLDOC, 2004). Their intersection represents the NP-completeclass, which will be discussed later. Figure 2.2 illustrates the computationalcomplexity classifications of problems.
Figure 2.2: Problem Complexity Classifications
The NP class of problems is divided into three classes:
Polynomial (P) Algorithms to solve P class problems is “guaranteed toterminate within a number of steps which is a polynomial function ofthe size of the problem” (FOLDOC, 2004). The generated solution canbe verified in polynomial time.
Nondeterministic Problems of this class can possibly be solved in polyno-mial time. The generated solution can be verified in polynomial time.
NP-Complete Problems are NP-complete when they are part of both theNP and NP-hard classes (a generated solution can thus be verified inpolynomial time).
Table 2.3 compares the different complexity classes in terms of whetherit is possible to solve problems and/or verify their solutions in polynomialtime.
Vehicle Routing 11
Table 2.3: Comparison of Complexity Classes
Polynomially PolynomiallyClass Solvable VerifiableNP Not all YesP Yes YesNondeterministic Possible YesNP-complete No YesNP-hard No Not all
The VRP is classified as NP-hard (Nygard & Kadaba, 1991). It is con-sidered NP-hard to find a feasible solution for the VRP with Time Windows(VRPTW) (Thangiah et al., 1991; Thangiah & Gubbi, 1993; Louis, Yin &Yuan, 1999; Maeda, Nakamura, Ombuki & Onaga, 1999; Tan et al., 2001a;Tan, Lee, Ou & Lee, 2001c; Prins, 2004).
Various brilliant mathematicians have failed to optimally solve NP-completeand NP-hard problems (Winston & Venkataramanan, 2003:804). It is thuspractical to settle for heuristic or approximation algorithms to solve theseproblems (including the VRPTW).
2.1.3 The Travelling Salesman Problem (TSP)
The VRP with one vehicle has exactly the same model as the travellingsalesman problem (TSP). Winston (1994:519) states that the TSP, just likethe VRP, is a combinatorial optimisation problem.
This problem has its origins in marketing. A salesman travel from hishome and must visit each of his/her customers once before returning tohis home. The salesman would like to travel the shortest distance possiblebetween his customers. Skrlec et al. (1997) as well as Winston & Venkatara-manan (2003:802) state that the TSP is a classical example of an NP-completeproblem. To solve this problem, the following integer programming modelneeds to be solved (Rardin, 1998:589):
Decision Variable:
xij =
1 if salesman travels from customer i to j, where
i, j ∈ {1, 2, ..., N |i 6= j}0 otherwise
(2.10)
Vehicle Routing 12
Input Parameters:dij = Distance between customer i and j, where i, j ∈ {1, 2, ..., N}N = Total number of customers to be visitedS = Proper set of customers to be routed
Model:
MinimiseN∑
i=1
N∑j=1
dijxij (2.11)
Subject to:
j<i∑j=1
xij +N∑
j>i
xij = 2 ∀i ∈ {1, 2, ..., N} (2.12)∑i∈S
∑j /∈Sj>i
xij +∑i/∈S
∑j∈Sj>i
xij ≥ 2 ∀S, |S| ≥ 3 (2.13)
xij ∈ {0, 1} ∀i ∈ {1, 2, ..., N} ∀j > i (2.14)
The objective function is shown in (2.11) and ensures that a minimumdistance is travelled by the salesman. The constraint in (2.12) relates to thefact that there are exactly two xij variables for each customer that can beequal to 1. When there is more than one tour present in the solution’s route,subtours are present (Figure 2.3 shows a solution with, and Figure 2.4 showsa route without subtours). Constraint (2.13) ensures that no subtours arepresent in the solution. Equation (2.14) defines x as a binary variable.
The Asymmetric TSP
This variation of the TSP occurs when the distance from node i to j is notequal to the distance between node j to i (Rardin, 1998:585).
The integer programming model of the asymmetric travelling salesmanproblem, as proposed by Rardin (1998:590), is shown in (2.15) through (2.20).The symmetric TSP can also be solved with this model by adjusting theasymmetric distance matrix to a symmetric matrix.
Decision Variable:
xij =
1 if salesman travels from customer i to j, where
i, j ∈ {1, 2, ..., N |i 6= j}0 otherwise
(2.15)
Vehicle Routing 13
Figure 2.3: The TSP with subtours
Figure 2.4: The TSP without subtours
Vehicle Routing 14
Input Parameters:dij = Distance between customer i and j, where i, j ∈ {1, 2, ..., N}N = Total number of customers to be visitedS = Proper set of customers to be routed
Model:
MinimiseN∑
i=1
N∑j=1
dijxij (2.16)
Subject to:
N∑i=1
xij = 1 ∀j ∈ {1, 2, ..., N} (2.17)
N∑j=1
xij = 1 ∀i ∈ {1, 2, ..., N} (2.18)∑i∈S
∑j /∈S
≥ 1 ∀S, |S| ≥ 2 (2.19)
xij ∈ {0, 1} ∀i, j ∈ {1, 2, ..., N} (2.20)
The objective function is shown in (2.16) and ensures that a minimumdistance is travelled by the salesman. The constraints in (2.17) and (2.18)the salesman can enter and leave each node only once. Constraint (2.19)ensures that there are no subtours in the solution. (2.20) defines x as abinary variable.
Equation (2.19) is not the only way to eliminate subtours from the TSP’ssolution. An alternative is to, in the above mentioned model, replace equationwith (2.19) with (2.21) and (2.22) (Winston & Venkataramanan, 2003:536).The proposed equations are formulated as follows:
ui − uj +Nxij ≤ N − 1 ∀i, j ∈ {1, 2, ..., N} | i 6= j (2.21)
uj ≥ 0 ∀j ∈ {1, 2, ..., N} (2.22)
The u variable is not definitely defined, but its value is adjusted by themodel to satisfy equation (2.21) when no subtours are present.
Vehicle Routing 15
2.2 Vehicle Routing Problem Variations
2.2.1 Additional Constraints
Various constraints are introduced into the basic VRP to incorporate thecomplex situations that often occur in logistics and supply chains. Theseconstraints are added to the basic routing problem (as described earlier), toform the a VRP with additional constraints and is described in sections 2.2.1to 2.2.1.
Multiple Time Windows
Customers may specify certain times in which they want the delivery of goodsto occur. Customer i specifies earliest (ei) and latest (li) allowable arrivaltimes (Zhu, 2003). These specified time periods are called time windows.
The VRP with time windows is referred to as the Vehicle Routing Problemwith Time Windows (VRPTW). Although the VRPTW term is mostly usedin literature, Maeda et al. (1999) uses the term VRPTD (VRP with TimeDeadlines) to name this kind of model. The VRPTW has been studiedextensively and has been the focus of numerous studies, including work doneby Thangiah et al. (1991), Thangiah & Gubbi (1993), Chen et al. (1998),Karanta et al. (1999), Louis et al. (1999), Maeda et al. (1999), Braysy(2001), Tan et al. (2001a, 2001b, 2001c), Hwang (2002), Van Schalkwyk(2002), Salmon (2003), Zhu (2003) as well as Berger & Barkaoui (2004).
Hard time windows are defined by customers if delivery must take placewithin the specified times, as shown in Figure 2.5. Soft time windows areapplicable when delivery may take place after time li (Salmon, 2003). How-ever, a penalty of ψi for customer i is coupled to the lateness of the delivery.Maximum lateness (Lmax
i ) may be set for soft time windows (see Figure 2.6).
Figure 2.5: Hard Time Windows
Vehicle Routing 16
Figure 2.6: Soft Time Windows
Multiple time windows per node can be defined by using the variables eai
and lai , where a indicates the number of the current window of the multipletime windows.
Figure 2.7: Multiple Soft Time Windows
When a vehicle arrives at customer i before time ei the vehicle has to waituntil time ei before that customer can be serviced. With the arrival time atcustomer i given by ai, the waiting time at that customer can be calculatedas wi = max{0, ei − ai}. To incorporate hard time windows into the integerprogramming model, both Zhu (2003) and Tan et al. (2001a, 2001b, 2001c)introduced the following constraints (where tij is the travel time betweennode i and j and si denotes the service time at node i):
a0 = w0 = s0 = 0 (2.23)
ei ≤ ai + wi ≤ li ∀i ∈ {1, 2, ..., N} (2.24)
K∑k=0
N∑i=0i6=j
xijk(ai + wi + si + tij) = aj ∀k ∈ {1, 2, ..., K} (2.25)
Vehicle Routing 17
Constraint (2.23) assumes that vehicles are already loaded and ready tostart their tours at time 0. Equation (2.25) determines the actual arrivaltime at the next node, whilst (2.24) ensures that nodes are visited withintime window.
To incorporate soft time windows into the VRP, li in constraint (2.24) ischanged to Lmax
i . Li is then defined as the lateness occurred at node i andcan be calculated with equation (2.26) (Joubert, 2003):
Li = max{0, ai − li} | ai ≤ (Li + Lmaxi ) (2.26)
The lateness penalty at customer i is defined by ψi per time unit. Thenew objective function is then introduced into the model to replace (2.2)(Joubert, 2003):
MinimiseN∑
i=0
N∑j=1j 6=i
K∑k=1
cijkxijk +N∑
i=1
ψi max{0, Li} (2.27)
It is considered NP-hard to find a feasible solution for the VRPTW(Thangiah et al., 1991; Thangiah & Gubbi, 1993; Louis et al., 1999; Maedaet al., 1999; Tan et al., 2001a, 2001c; Prins, 2004).
Heterogeneous Fleet
When all vehicles in a fleet have the same characteristics, the fleet is said tobe homogeneous. However, vehicles used for deliveries often have differentcapacities, costs and travel speeds. The capacity of a vehicle vary in termsof loading volume and loading weight. When a fleet consists of vehicles withdifferent characteristics, a heterogeneous fleet is present. The use of vehiclek in a heterogeneous fleet is coupled with fixed cost of fk.
Each vehicle has a different load capacity, indicated by Qk. This varyingcapacity is introduced by changing the vehicle capacity constraint (2.8) to(Tan et al., 2001a; Zhu, 2003):
N∑i=1
qi
N∑j=0
xijk ≤ Qk ∀k ∈ {1, 2, ..., K} (2.28)
A new objective function, instead of (2.2), is used to incorporate the fixedcosts associated with the use of different vehicles (Filipec et al., 1998):
MinimiseN∑
i=0
N∑j=0j 6=i
K∑k=1
cijxijk +K∑
k=1
N∑j=1
fkxijk (2.29)
Vehicle Routing 18
Ochi, Vianna, Drummond & Victor (1998) states that this VRP variationhas not received a lot of attention. They claim that this is due to the increaseddifficulty of these problems.
Capacitated VRPs
The capacitated VRP (CVRP) is a single depot VRP with limits on thecapacity as well as reach of vehicles (Skrlec, Filipec & Krajcar, 1997). Itshould be noted that the basic VRP already includes the capacity constraint,but that it ignores the maximum reach constraint.
Filipec et al. (1998) indicates that companies have been known to limitthe distance that different vehicles may travel per day by including constraint(2.30) in the VRP model. A new variable tijk is included and it representsthe time for a vehicle k to travel between node i and j. Tk is the daily timelimit placed on vehicle k.
N∑i=0
N∑j=0
tijkxijk ≤ Tk ∀k ∈ {1, 2, ..., K} (2.30)
To introduce the distance constraint shown in (2.31), a dijk variable isincluded and it represents the distance for vehicle k to travel between nodei and j. Dk is the distance limit placed on vehicle k.
N∑i=0
N∑j=0
dijkxijk ≤ Dk ∀k ∈ {1, 2, ..., K} (2.31)
Double Scheduling
During the course of the day a vehicle may return to the depot to refresh(or fill up) its capacity before serving more customers on its next route.This implies that one delivery vehicle can travel multiple routes per day,refilling its capacity at the depot when each route is finished. This process iscontinued until the vehicle returns to the depot at the end of the day (tour).A tour consists of one or more routes (Joubert, 2003).
Although this type of problem has not received much attention in liter-ature, it is proposed that the fleet size constraint (2.7) must be eliminatedfrom the model. Consequently, new constraints to ensure the validity of theextra routes per tour need to be developed.
Vehicle Routing 19
Multiple Depots
Customers might require goods which are located at various depots. The de-livery vehicles must thus serve end-users from different supply depots. Theintroduction of multiple depots into the VRP changes the VRP model dra-matically and requires that a new model has to be developed.
Filipec et al. (1997) describes a VRP with a homogeneous fleet andmultiple depots. They named it the MDCVRP (multi-depot capacitatedVRP) and developed a Genetic Algorithm to solve it.
Pick-Up and Delivery
This situation occurs when certain customers require goods to be deliveredwhilst others require goods to be picked up. The order in which goods arepicked up and delivered is of essential importance in this situation.
The Dial-A-Ride Problem (DARP) falls in this category. This problemmodels the situation where various vehicles must pick-up persons who dialedin for transportation and then take them to their specific destinations. Potter& Bossomaier (1995) studied and developed a Genetic Algorithm to solve thiskind of problem. To minimise both travelling distance and customer waitingtimes, they propose (2.32) as an objective function for the DARP model(where wi is the waiting for customer i and di is the travel distance to thatcustomer).
MinimiseK∑
k=1
N∑i=1
(wi + di) (2.32)
Jih & Hsu (1999) introduced pick-up and delivery as well as time windowconstraints into the VRP and named it the Pick-up and Delivery Problemwith Time Windows (PDPTW).
2.2.2 The VRP with Multiple Constraints (VRPMC)
This project focuses on solving a VRP with the following additional con-straints:
• Multiple soft time windows
• Heterogeneous fleet (varying capacities and travelling speeds)
• Double scheduling
A VRP with the above mentioned constraints is named the VRP withMultiple Constraints (VRPMC). A integer programming model for the VRPMC(without double scheduling) is shown in the next section.
Vehicle Routing 20
2.2.3 Extended VRP Model
Combining multiple soft time windows and heterogeneous fleet constraints,the model for the extended VRP (EVRP) is compiled, as shown below. Thismodel is a combination of models for the VRPTW with a heterogeneous fleetproposed by Tan et al. (2001a), Van Schalkwyk (2002:20) and Zhu (2003).
Decision Variables:
xijk =
1 if vehicle k travels from node i to j, where
i, j ∈ {1, 2, ..., N |i 6= j}, k ∈ {1, 2, ..., K}0 otherwise
(2.33)
TW ai =
1 if time window a at node i is used, where
i ∈ {1, 2, ..., N}, a ∈ {1, 2, ..., A}0 otherwise
(2.34)
wi = Waiting time at node i, where i ∈ {1, 2, ..., N}ai = Arrival time at node i, where i ∈ {1, 2, ..., N}
Input Parameters:dij = Distance between node i and j, where i, j ∈ {1, 2, ..., N}cij = Cost incurred between node i and j, where
i, j ∈ {1, 2, ..., N}tij = Travel time between node i and j, where
i, j ∈ {1, 2, ..., N}N = Total number of customers to be visitedK = Total number of vehicles in fleet
A = Maximum number of time windows allowedqi = Known demand for node i, where i ∈ {1, 2, ..., N}Qk = Capacity of vehicle k, where k ∈ {1, 2, ..., K}si = Service time at node i, where i ∈ {1, 2, ..., N}ei = Earliest arrival time at node i, where i ∈ {1, 2, ..., N}li = Latest arrival time at node i, where i ∈ {1, 2, ..., N}Li = Lateness of arrival at node i, where i ∈ {1, 2, ..., N}Lmax
i = Maximum lateness allowed node i, wherei ∈ {1, 2, ..., N}
ψi = Lateness penalty per time unit at node i, wherei ∈ {1, 2, ..., N}
fk = Fixed cost for vehicle k, where k ∈ {1, 2, ..., K}
Vehicle Routing 21
Tk = Maximum allowed travel time for vehicle k, wherek ∈ {1, 2, ..., K}
Dk = Maximum allowed route distance for vehicle k, wherek ∈ {1, 2, ..., K}
Model:
MinimiseN∑
i=0
N∑j=0j 6=i
K∑k=1
cijxijk +N∑
i=1
ψi max{0, Li}+K∑
k=1
N∑j=1
fkx0jk
(2.35)
Subject to:
N∑i=1i6=j
K∑k=1
xijk = 1 ∀j ∈ {1, 2, ..., N} (2.36)
N∑j=1j 6=i
K∑k=1
xijk = 1 ∀i ∈ {1, 2, ..., N} (2.37)
N∑j=1
x0jk =N∑
i=1
xi0k ≤ 1 ∀k ∈ {1, 2, ..., K} (2.38)
N∑j=1
K∑k=1
x0jk ≤ K (2.39)
N∑i=1
qi
N∑j=0
xijk ≤ Qk ∀k ∈ {1, 2, ..., K} (2.40)
N∑i=0
qi
N∑j=0j 6=i
dijxijk ≤ Dk ∀k ∈ {1, 2, ..., K} (2.41)
N∑i=0
N∑j=0j 6=i
(tij + si + wi)xijk ≤ Tk ∀k ∈ {1, 2, ..., K} (2.42)
t0 = w0 = s0 = 0 (2.43)
N∑i=0i6=j
K∑k=1
xijk(ai + tij + si + wi) ≤ aj ∀j ∈ {1, 2, ..., N} (2.44)
TW ai ei ≤ ai + wi ≤ TW a
i li ∀i ∈ {1, 2, ..., N} (2.45)
Vehicle Routing 22
A∑a=1
TW ai = 1 ∀i ∈ {1, 2, ..., N} (2.46)
TW ai ∈ {0, 1} ∀i ∈ {1, 2, ..., N},∀a ∈ {1, 2, ..., A} (2.47)
xijk ∈ {0, 1} ∀i, j ∈ {1, 2, ..., N},∀k ∈ {1, 2, ..., K} (2.48)
The objective function in (2.35) minimises the total distance travelled,lateness penalties and fixed vehicle cost (i.e. fleet size). Constraints (2.36)and (2.37) ensure that each customer is visited once. (2.38) ensures thatall routes start and end at the depot. Constraint (2.39) specifies that amaximum K routes may be present. Equations (2.40), (2.41) and (2.42)enforces maximum vehicle loading capacity, allowable vehicle travel distanceand maximum travel time per vehicle respectively. Equations (2.44) through(2.47) define multiple soft time windows. Constraints (2.47) and (2.48) defineTW and x as binary variables.
2.2.4 Objective Function Variations
Filipec et al. (1998) states that six objective functions are frequently usedin the application of VRP variations:
1. Minimise total distance travelled by the entire fleet. As shown in (2.2).
2. Minimise the total time taken by all the vehicles, shown in (2.49).With the average speed of each vehicle k indicated by vk, this objectivefunction is expressed as:
MinimiseN∑
i=0
N∑j=0
j 6=i
K∑k=1
vkdijxijk (2.49)
3. Minimise the number of vehicles used and minimise the total distancetravelled. For this objective function a variable yk is introduced, whereyk is defined in (2.50). The objective function of the VRP is thenreplaced by (2.51) and constraint (2.52) is added (where M representsa large integer number such that M ≥ N).
yk =
{1 if vehicle k is used at all, where k ∈ {1, 2, ..., K}0 otherwise
(2.50)
Vehicle Routing 23
MinimiseK∑
k=1
yk +N∑
i=0
N∑j=0
j 6=i
K∑k=1
dijxijk (2.51)
N∑j=1
x0jk ≤Myk (2.52)
4. Minimise the total fleet costs. Here the dij variable is exchanged withcij, with cij equal to the cost occurred between node i and j. Theobjective function then becomes (2.53).
MinimiseN∑
i=0
N∑j=0
j 6=i
K∑k=1
cijxijk (2.53)
5. Minimise vehicle cost and distance travelled. For this objective func-tion, shown in (2.54), both the cost cij and the distance dij (as definedabove) are used.
MinimiseN∑
i=0
N∑j=0
j 6=i
K∑k=1
(cij + dij)xijk (2.54)
6. Fixed fleet acquisition cost. The new objective function to determinetotal cost is shown in (2.55), where Fk denotes the acquisition cost ofvehicle k.
MinimiseN∑
i=0
N∑j=0
j 6=i
K∑k=1
cijxijk +K∑
k=1
N∑j=1
Fkxijk (2.55)
2.3 VRP Solution Methods
2.3.1 Optimal Solution Methods
Winston (1994:526) states that the TSP can be solved optimally using thebranch-and-bound method, but that this technique requires large amountof computer time. He consequently suggests the use of either the nearest-neighbour heuristic (NNH) or the cheapest-insertion heuristic (CIH) methodto solve the TSP.
Malmborg (1996) states that algorithms exist which can optimally solveVRPs with 50 destinations. Problems with 100 destinations have been solved
Vehicle Routing 24
optimally, but with computational times measured in hundreds of minutes.A few instances of VRPTW, with less than 50 destinations, have been opti-mally solved. Malmborg (1996) focuses on heuristics for the solution of theVRPTW as it is the only practical way in which to solve large scale routingproblems.
2.3.2 Heuristics
Various complicated models are solved with heuristics (or approximationalgorithms). Winston (1994:526) defines heuristics as “a method to solve aproblem by trail and error when an algorithmic approach is impractical”.
Goldberg (1989:2) claims that heuristics can be divided into three cate-gories. These categories are classified as follows:
Calculus-based These methods have been studied heavily. This class ofheuristics finds local optima by moving in the direction which has thesteepest increase in objective function values. Problems with a singlepeak (as shown in Figure 2.8) is easily solved by the “hill climbing”approach of calculus-based methods.
Figure 2.8: Single Peak Problem
A major problem with calculus-based methods is that they tend to “getstuck” at local optima instead of finding the global optimal solution.These methods would find any one of the peaks in Figure 2.9 as itssolution, not necessarily the highest peak. The peak that will be pro-duced as the heuristic’s answer depends on where the search started,i.e. the initial solution provided to the heuristic.
Vehicle Routing 25
Figure 2.9: Multiple Peak Problem
Enumerative Here the objective function value of each and every point inthe solution space is analysed. The highest value is then produced asthe global optimal answer, as this method considers all solution pointsand consequently cannot “get stuck” at local optima. The problemwith this method is its lack of efficiency due to the enormous amount ofcomputations that need to be done. Even for moderate size problems,this methods loses its possibility for practical application. Dynamicprogramming also has this problem and the problem of size has beencalled its “curse of dimensionality”.
Random These methods have received a lot of attention and address someof the problems posed by the other two methods. It uses a randomsearch of the solution space to produce its approximate solution. Theefficiency of these methods are also a problem, but not to the extentof enumerative methods. Examples of this method include GeneticAlgorithms and Simulated Annealing.
Heuristic Evaluation
Methods proposed for evaluating routing heuristic include:
Performance Guarantees Winston (1994:528) states that this method usesthe worst-case bound on how far from the optimal the heuristic answercan be. Using this method to analyse CIH it has been shown that theworst tour obtained by this heuristic cannot exceed twice the length ofthe optimal tour.
Vehicle Routing 26
Probabilistic Analysis Assuming a probabilistic customer distribution, theexpected length of the route produced by the heuristic is divided bythe expected length of the optimal tour. The closer the ratio is to 1,the better the performance of the heuristic (Winston, 1994:528).
Empirical Analysis Winston (1994:528) claims that this method can onlybe used when the optimal route length is known because the routegenerated by the heuristic is compared to the optimal route. BothNNH and CIH produce routes which are approximately 15% longerthan the optimal route.
Others Other simple methods proposed include computational time, solu-tion quality and ease of implementation.
Thangiah et al. (1991) tested various VRPTW metaheuristics with 56problem instances, with 100 nodes, provided by Solomon (1987, 2004), seeAppendix A. This study also found that GAs perform exceptionally wellwhen solving routing problems with randomly located customers. Over theyears the 56 Solomon (1987) problem instances with 100 nodes have becomebenchmark problems for solution methods of the VRPTW. These problemsare divided into six types: C1, C2, R1, R2, RC1 and RC2. Type C hasclustered customers, type R has randomly located customers and type RChas a combination of the two (Solomon, 1987; Gambardella, 2000). Type1 problems have narrow time windows and small vehicle capacities (i.e. alarge number of vehicles and routes) whilst type 2 problems have large timewindows with large vehicle capacities (i.e. few vehicles and routes).
The best know solutions for these problems found in the literature isshown in Appendix B.
2.3.3 Metaheuristics
Metaheuristics are master strategies which uses intelligent decision makingtechniques to guide algorithms to find global optimal solutions. Over theyears heuristics have evolved into metaheuristics which often have to allowsteps that temporarily decrease the value of the objective function to ensurethat the algorithm does not get stuck at local optima. This ensures thatmetheuristics it will find the global optimal solution (see Figure 2.10).
Metaheuristics require initial solutions as input for the algorithms. Thealgorithm then improves these initial solutions to try and find an optimalsolution. Many GAs generate their initial population randomly (Skrlec, 1997;Tan et al., 2001a, 2001b; Baker & Ayechew, 2003). Most metaheuristicsdefine their own problem specific initial solution algorithms (Goldberg, 1987;
Vehicle Routing 27
Figure 2.10: Local and Global Maxima
Michalewicz, 1992; Malmborg, 1996; Louis et al., 1999; Baker & Ayechew,2003; Jaszkiewicz & Kominek, 2003; Zhu, 2003). Van Schalkwyk (2002)formulated a Sequential Insertion Heuristics (SIH) to provide initial solutionsfor routing problems.
The use of metaheuristics requires stopping criteria to be defined. Stop-ping criteria are rules used to determine whether the search for the optimalsolution should continue. A computational time and solution quality trade-off exists in metaheuristics techniques.
The three most used metaheuristics that are used to solve VRPs areGenetic Algorithms (GAs), Simulated Annealing (SA) and Tabu Search (TS).TS and SA are described in subsections 2.3.3 and 2.3.3, whilst GAs areseparately described in detail in section 3.1.
Tan et al. (2001a) compared SA, GA and TS and concluded that no onemethod seems to be generic enough to handle all problem situations. Forexample, Thangiah & Gubbi (1993) concludes that the normal unadaptedGA does not perform well when solving routing problems with clusteredcustomers. SA is believed to be the fastest metaheuristic, followed by TSand then GAs (Joubert, 2003).
Vehicle Routing 28
Tabu Search (TS)
Winston & Venkataramanan (2003:815) states that Tabu Search is a meta-heuristic procedure based on intelligent decision making strategies. Intelli-gent decision making emulates the rules that humans use in daily decisionmaking.
The Tabu Search algorithm temporarily forbids moves that would gen-erate recently visited solutions. It is a memory based search algorithm, asit keeps a Tabu list of certain forbidden moves in the solution space. ThisTabu list prevents cycling between possible solutions and helps to find globaloptima by moving away from local optimal solutions (Rardin, 1998:687-688).
To ensure that TS finds high-quality solutions, aspiration criteria aredefined to override the Tabu list as required. Aspiration criteria evaluatesthe quality of possible moves in the solution space and is consequently usedto guide moves by the TS metaheuristic.
To find good solutions, TS is highly dependent on the quality of initialsolutions (Van Breedam, 2001). TS has previously been successfully appliedin various situations to arrive at good approximately optimal solutions.
Simulated Annealing (SA)
This heuristic has its origins in the annealing process of metals (Van Breedam,2001). Various techniques, analogous to the metal annealing process, are usedto find global optima. Without these techniques the heuristics would producelocal suboptimal solutions.
In the annealing process, the temperature of the metal is firstly increasedand then gradually reduced. Increasing the temperature randomly scattersatoms by breaking down the atomic matrix structure of the atoms. Withrandomly positioned atoms, the metal is at its highest energy state. Bylowering the temperature of the metal, the atoms gradually settle down intoa certain stronger matrix-like order (Rardin, 1998:690). The “better” theorder in which the atoms settle, the lower the energy state of the metalwill be. By reducing a metal’s energy state, its yield strength is increased(although it becomes more brittle).
The optimality of a solution is parallel to the energy state of the metal.With the temperature of the metal used as the objective function value, thetemperature of the metal is gradually reduced at each stage of the heuristic.The temperature reductions randomly search for better solutions in the cur-rent solutions’ surroundings (Winston & Venkataramanan, 2003:805). Possi-ble solutions are represented by the order in which atoms settle. This orderis tested to determine whether their associated energy state (i.e. level of op-
Vehicle Routing 29
timality) is lower than others. The energy levels of solutions are determinedby a formula referred to as Boltzman’s function.
According to Michalewicz (1999:16), SA eliminates most of the disadvan-tages of hill-climbing solution methods in that:
• SA is not highly dependent on the quality of initial solutions (unlikeTS).
• Solutions found by SA are usually closer to the global optimal solution.
The next chapter investigates Genetic Algorithms and the programminglanguages that can be used to code the algorithm.
Chapter 3
GA Theory and Application
3.1 Genetic Algorithms (GA)
Genetic Algorithms were developed by John Holland early in the second halfof the previous century. GAs are algorithms that search for global optimalsolutions by intelligently exploiting random search methods. The algorithmemulates biological evolution (Rardin, 1998:694) and is a metaphor for thegenetic evolution of chromosomes in that:
• Populations are represented by groups, each representing a feasiblesolution.
• In a population, parents mate according to natural selection. This isanalogous to randomly selected feasible parent solutions.
• Offspring will be produced by the mating of the selected parents. Theoffspring that is produced is a metaphor for newly created solutions.
• In nature, offspring exhibit some characteristics of each parent sincechromosomes are exchanged to form new chromosome strings. The al-gorithm parallels this by creating two new offspring solutions by swap-ping some parts of the parent solutions. In Operations Research terms,this process is referred to as crossover.
• Survival of the fittest is also incorporated in the GA analogy. Thefitness of a solution can be related to its objective function value. Thefittest solutions will typically reproduce to ensure the survival of thefittest in the next generation.
• Mutation for diversity is represented in the metaheuristic by the ran-dom modification of chromosomes (i.e. possible solutions).
30
GA Theory and Application 31
The analogy between nature and the Genetic Algorithm is summarisedin Table 3.1. It shows the equivalent routing problem terms for the relevantterms used in biological evolution. A typical GA chromosome showing someof the terms in Table 3.1 is illustrated in Figure 3.1.
Table 3.1: Biological Evolution vs. Genetic Algorithms
Natural Evolution Genetic AlgorithmPopulation Feasible solutionsNatural selection Randomly selected parent solutionsReproduction Combining parent solutions to form offspringOffspring New solutions created from parent solutionsChromosome A feasible solution / a stringSurvival of the fittest Good solutions used to create new solutionsMutation Random modification of solutionsFitness Quality of a solutionLocus A position in a feasible solution’s stringAllele The value of a locus
Figure 3.1: Chromosome Structure (Source: Thangiah et al. 1991)
A simplified example, representing a conventional high-level GA meta-heuristic is shown in Figure 3.2.
This project will use the GA approach as the preferred solution methodfor the VRPMC. During the literature study, it became apparent that GAsrepresent a powerful way of solving extended routing problems. The reasonswhy GAs are so powerful in this regard can be summarised in the next points:
• It is a metaheuristic; rather than a normal heuristic.
• GAs are often used to solve complex optimisation problems.
GA Theory and Application 32
Figure 3.2: Genetic Algorithm Flowchart
GA Theory and Application 33
• They are robust, flexible and computationally simple (Goldberg, 1989:1).
• GAs outperform calculus-based, enumerative and random search algo-rithms (Goldberg, 1989:3).
• Proof of why GAs perform so well is theoretically proven by the SchemataTheorem and the Minimum Deceptive Problem (MDP) - see section3.1.3.
The origins of Genetic Algorithms can be traced to the early 1960’s.Goldberg (1987:89-144) lists 84 published applications of GAs up to 1987.Numerous experts in the Operations Research environment promote the useof Genetic Algorithms to solve complex routing problems. The relevant writ-ings of these OR experts can be traced from 1983 onwards, refer to Table 3.2(publications listed by Goldberg (1987:89-144) are indicated with an aster-isks).
Goldberg (1987:9) claims that the GA climbs various hills in parallel, thusreducing the probability that a GA will find only a local optimal solution,to approximately zero. The parallel way in which problems are solved con-tributes to GA’s robustness. Vas (1999:271) concludes that GAs are “effectivein searching complex, highly non-linear, multi-dimensional search spaces”.
Michalewicz (1999:15) states that the GA have been used successfullyto solve wire routing, scheduling, adaptive control, game playing, cognitivemodelling, database query, transportation, travelling salesman and optimalcontrol problems.
The previous points all indicate the various reasons why a Genetic Algo-rithm solution approach will be used in this project for the solution of vehiclerouting problems with multiple soft time windows, a heterogeneous fleet anddouble scheduling.
3.1.1 Evolutionary Programming(EP)
Michalewicz (1992:1) describes Evolution Programs (EP) which encapsulatesalgorithms that imitate the principles of natural evolution in solving optimi-sation problems. EPs are GAs with modified representation of chromosomes.
According to Michalewicz (1992:6) the difference between EPs and GAs isthat classical GAs use binary chromosome string representation and modifiesthe problem to fit this representation. Chromosome representation in EPsare modified to accurately describe and fit the problem. For example, GAsused to solve TSPs and VRPs use integer chromosome string codings andhigher level genetic operators. The major strength of EPs are that they havea wide field of application (Michalewicz, 1992:9).
GA Theory and Application 34
Table 3.2: GA Routing Applications
Year Investigator Application1983 Wetzel* TSP1985 Goldberg & Lingle* TSP1985 Brady* TSP1985 Grefenstette* TSP1987 Raghavan & Agarwal* Adaptive clustering1987 Goldberg* MDP1987 Sirag & Weisser* TSP1987 Suh & Van Gucht* TSP1991 Thangiah et al. VRPTW1992 Michalewicz (Chapter 10) TSP1993 Thangiah & Gubbi VRPTW1994 Pellazar VRP1994 Uchimura et al. VRP1995 Potter & Bossomaier Pick-up and delivery1997 Filipec et al. Multiple depot VRP1997 Skrlec at al. VRP1998 Filipec at al. CVRP1998 Ochi et al. VRP with heterogeneous fleet1999 Louis et al. VRPTW1999 Maeda et al. VRPTW and GIS2001b Tan et al. VRPTW2002 Hwang VRPTW2003 Choi, Kim & Kim ATSP2003 Baker & Ayechew VRP2004 Prins VRP2004 Berger & Barkaoui VRPTW
GA Theory and Application 35
Most publications do not use the terms EP or classical GA, but ratheruses the more accepted terms GA and simple GA. To avoid confusion betweenEP and GA, we will conform to the generally accept terms. This will avoidthe implication that GAs can only solve simple problems.
The terms EP and classical GA will not be used in this project. Algo-rithms that emulate genetic evolution with binary representation and clas-sical genetic operators are referred to as simple GAs (SGA). When otherchromosome codings are used in conjunction with higher level genetic oper-ators in algorithms that simulates natural evolution, the term GA is used.
3.1.2 Simple GA Example
When a simple GA (SGA) is used to solve (find the maximum) of the func-tion f(x) = x3 in the range [0, 31], a binary representation is used to codechromosomes. The global optima that the GA seek is f(31) = 313 = 29791.The GA thus needs to find the value of x = 31. The decimal 31 is convertedto binary as 11111, the maximum binary value x can take on. A populationsize of 4 chosen for illustrative purposes.
To solve this problem, the steps shown in Figure 3.2 are followed. In thefirst step, generation, an initial population of 4 chromosomes is generatedby randomly generating bit values for each locus (see Table 3.3). Crossoverpositions are randomly selected as 2 and 4.
Table 3.3: SGA Initial Population
String Value Fitness P(Selection)1 1 0 0 0 24 13824 0.5910 1 1 0 1 13 2197 0.0940 1 0 0 0 8 512 0.0221 0 0 1 1 19 6859 0.293
Evaluation is the next step and requires the calculation of the fitnessof each chromosome by transforming the binary number represented by thestring to a decimal number and then cubing this decimal value (see Table3.3).
The next step requires selection for reproduction and mating. A biasedroulette wheel is used for the selection of parents. Vas (1999:264) indicatesthat each chromosome in the initial population owns a fraction of the wheelwhich is proportional to the chromosome’s fitness (see Figure 3.3).
GA Theory and Application 36
Figure 3.3: Biased Roulette Wheel for Selection
The wheel is then spun using the generation of a random number and theselection probabilities shown in Figure 3.3. With this process, it is expectedthat two of the 11000 chromosome will be selected and placed in the nextgeneration, one of the 10011 chromosome and one of 01101. A possiblepreliminary next generation, created by the roulette wheel selection method,is shown in Table 3.4 (based on Goldberg (1987:17)).
Table 3.4: SGA Preliminary Next Generation
String Crossover Position1 1|0 0 0 20 1|1 0 1 21 1 0 0|0 41 0 0 1|1 4
For the crossover step, the simple crossover (SXO) is briefly described.The simple crossover of strings A and B is started by randomly selecting acrossover position (Vas, 1999:264). When assuming that the random positionis 4, the part of A to the right of this position is exchanged by the part of B
GA Theory and Application 37
to the right of this position. The simple crossover (at position 4) is appliedto two strings A and B and produces A′ and B′:
A = 1 0 1 0|1 1 1 0B = 1 1 1 1|0 0 0 1
A′ = 1 0 1 0 0 0 0 1B′ = 1 1 1 1 1 1 1 0
The SGA also requires the random pairing of parents. For example, the11000 chromosome pairs up with 01101 and the other 11000 chromosomewith 10111. Crossover positions for chromosomes are randomly selected (forexample 2 and 4 in Table 3.4). Applying the described SXO, we obtain thenext generation of values as shown in Table 3.5.
Table 3.5: SGA Next Generation
String Value Fitness1 1 1 0 1 29 243890 1 0 0 0 8 5121 1 0 0 1 25 156251 0 0 1 0 18 5832
Mutation is when a 0 bit is changed to a 1 bit, or a 1 bit is changed toa 0. When a mutation rate of 1 in a 1000 is used, no random mutations areexpected to occur in the SGA example as only 20 bits are processed. Thefinal next generation is thus shown in Table 3.5.
The best solution in the initial population is 13825, whilst the best solu-tion in the next generation is 24389. This shows a drastic increase in the bestsolution found within only one generation. The above mentioned steps canbe repeated for 30 generations and would probably yield an optimal solution.
Goldberg (1987:86) solved the function f(x) = x10 with x in the range[0,31] (see Figure 3.4) with a similar SGA and found that it does quicklyconverge to near-optimal solutions.
Michalewicz (1999:19-22) successfully solved the function in (3.1) with xin the range [-1,2] (see Figure 3.5) with a SGA. The SGA came within 1%of the global optima.
f(x) = x · sin(10π · x) + 1 (3.1)
GA Theory and Application 38
Figure 3.4: Function Solved by Goldberg (1987:86)
Figure 3.5: Function Solved by Michalewicz (1999:19)
GA Theory and Application 39
The function shown in (3.2), with −3 ≤ x1 ≤ 12.1 and 4.1 ≤ x2 ≤ 5.8(see Figure 3.6), was solved with a SGA with excellent results (Michalewicz1999:31-42).
f(x1, x2) = 21.5 + x1 · sin(4πx1) + x2 · sin(20πx2) (3.2)
Figure 3.6: Function Solved by Michalewicz (1999:34)
These examples illustrate the power of GAs find the global optimal solu-tion in complex solution spaces (difficult to solve problems).
3.1.3 Mathematical Foundations: Schemata Theory
The Schemata Theorem is widely accepted in literature and is discussedin detail by Goldberg (1987), Michalewicz (1992) and Potgieter (1997). Itprovides mathematical proof that GAs will solve problems satisfactorily.
A schema, or similarity template, is a piece of information which is present(similar) in different strings of high fitness. The schema represents a subsetof strings which contribute strongly to the high fitness of these strings. Forexample, in a string of length 5 it is known that when the last 4 positions are1’s, the string will be highly fit. The four 1’s are a schema. The * or “don’t
GA Theory and Application 40
care” symbol is introduced to represent this schema as *1111. This schemarepresents either 11111 or 01111, both of which will have high fitness levels.
With a population size of n and string lengths of l it has been shownthat there are between 2l and n2l schemata present in the population. Theseschemata are called building blocks, as the GA builds better strings with thevery fit short blocks. It has been found that large amounts of these schemataare processed by the GA in a useful way. The high amount of schematausefully processed in a population of n indicates the strength of GAs and isreferred to as implicit parallelism.
Strings are processed by the three basic GA operators. The schematapresent in the population is thus also processed. The number of schema Spresent in a population at time t is given by m(S, t).
Reproduction
Strings are selected for the next generation according to the relative fitnessof a string (roulette wheel selection). The probability of selecting string i,pi, is given as
pi =fi∑fi
(3.3)
with fi defined as the fitness of string i.The number of a specific schema, say schema S, in the next generation is
given by
m(S, t+ 1) = m(S, t) · n · f(S)∑fi
(3.4)
with f(S) the average fitness of strings that include schema S.The average fitness of the population, f , is given by
f =
∑fi
n. (3.5)
Using equation (3.5), (3.4) becomes
m(S, t+ 1) = m(S, t)f(S)
f. (3.6)
Equation (3.6) shows that the number of a specific schema S will be morethan the number of this schema present in the previous generation, m(S, t),if the average fitness of strings that include schema S, f(S), is bigger thanthe average fitness of the entire population, f). S consequently multiplies
GA Theory and Application 41
from generation to generation. If f(S) is less than f , the number of S willdecrease and ultimately die off. Hence it is proven that above average schemawill grow and below average schema will disappear.
The fitness of strings with a schema S is higher than the average of allthe strings by a constant k. This indicates that f(S) = (1 + k)f . (3.6) thenbecomes
m(S, t+ 1) = m(S, t)f + kf
f= (1 + k) ·m(S, t). (3.7)
With k constant over a time period [0, t] and t = 0, equation (3.7) becomes
m(S, t) = m(S, 0) · (1 + k)t. (3.8)
Equation (3.8) indicates that the number of specific schema grows exponen-tially due to the selection process.
Crossover
The length of a string is represented by l. The distance between the firstand last bit positions in a schema is the defining length of a schema S and isdenoted by δ(S). For example δ(101∗) = 3− 1 = 2, δ(1 ∗ ∗ ∗ ∗∗) = 1− 1 = 0and δ(1 ∗ ∗ ∗ 0) = 5− 1 = 4.
The greater the value of δ(S), the higher the probability that crossoverwill destroy the schema S. Since the crossover site is selected uniformlyamong l − 1 possible sites, the probability that schema Si will be destroyedby crossover is pd = δ(Si)/(l− 1). The probability of survival for a schema isps = 1−pd. Crossover is performed with a probability of pc. The probabilityof schemata survival is given by
ps ≥ 1− pc ·δ(S)
l − 1. (3.9)
The number of schema present after reproduction and crossover is calcu-lated by combining (3.6) and (3.9):
m(S, t+ 1) ≥ m(S, t) · f(S)
f·[1− pc ·
δ(S)
l − 1
](3.10)
Two factors influencing schemata survival is presented by (3.10). Itshows that schemata with above average performance and with short defininglengths (δ) will increase exponentially in the next generation.
GA Theory and Application 42
Mutation
The order of a schema S, O(S), is the number of bits in the string (excluding*’s). For example O(10 ∗ 1) = 3 and O(1 ∗ ∗ ∗ 0 ∗ ∗) = 2.
Mutation is the alteration of a random bit value. The probability thata bit will be changed is given by pm. For a schema to survive, none of itsbits can be changed. The probability of survival for one bit is 1 − pm. Thesurvival probability of a schema can then be calculated as (1−pm)O(S). Withpm � 1, the survival probability is approximated as 1−O(S)pm.
The number of schema in the next generation after reproduction, crossoverand mutation is determined by using 1−O(S)pm and (3.10):
m(S, t+ 1) ≥ m(S, t) · f(S)
f·[1− pc ·
δ(S)
l − 1−O(S)pm
](3.11)
It is shown in (3.11) that schemata with above average performance, withshort defining lengths (δ) and small orders (O) will increase exponentially inthe next generation. Using equation (3.11), Michalewicz (1992:51) formulatesthe Schemata Theorem:
Theorem 1 Short, low-order, above-average schemata receive exponentiallyincreasing trials in subsequent generations of a Genetic Algorithm.
The Building Block Hypothesis is also formulated from (3.11) (Michalewicz,1992:51):
Hypothesis 1 A Genetic Algorithm seeks near optimal performance throughthe juxtaposition (combination) of short, low-order, high-performance schemata,called the building blocks.
Equation (3.11) shows that although the GA processes only n strings pergeneration, exponentially more schemata are actually implicitly processed.As stated above, this phenomenon is called implicit parallelism. Goldberg(1987:41) goes on to estimate the number of schemata processed usefully asn3.
The Schemata Theorem provides mathematical proof that GAs are pow-erful tools when used to solve optimisation problems.
To support this mathematical proof, Goldberg (1987:46) formulated prob-lems which are designed to deceive GAs so that they may not converge tothe global optimal solution. The smallest problems than can deceive GAsare referred to as minimal deceptive problems (MDP). Goldberg (1987:54)found that GAs are often not deceived by the MDP.
Both the Schemata Theorem and the MDP provides encouraging proofof why simple GAs can solve difficult optimisation problems.
GA Theory and Application 43
3.1.4 Chromosome Coding
The way in which chromosomes are coded to represent feasible solutions isa difficult and important part of the development of a GA (Michalewicz,1999:4). Nygard & Kadaba (1991) refers to coding as a “key issue” of GAs.The simple GA addressed above uses a binary representation to code chro-mosomes.
The alphabet used in GAs refers to all the values (alleles) that a position(locus) in the chromosome string can have. When binary coding is used, thealphabet used is defined as {0, 1}. If alleles can have values between 1 and9, the alphabet is {1, 2, 3, 4, 5, 6, 7, 8, 9}.
Goldberg (1987:80) claims that two principles need to be adhered to whendeciding on how to code a problem:
1. Coded strings used in GAs must be coded in such a fashion that short,low-order schemata are relevant to the specific application
2. The smallest possible alphabet that can be used to represent the prob-lem should be used.
The binary coding system should not be used to solve TSPs as stringsget extremely long and no operators are available that can process binaryrepresentations of cities in specific routes (Michalewicz, 1992:25,167; Ochi etal., 1998). When integer values are used to code chromosomes, Michalewicz(1992:81) found that the GA performs better and has less computationaltime than a similar GA with binary chromosome representations.
To represent the a possible solution tour for the TSP, integer values(rather than bits) are used within the string. Three ways to represent tourshave been found in literature.
Path Representation
This is the simplest representation for routing type problems. It is a basiccity-to-city representation. For example, the tour T = 3 1 6 5 2 4 meansthat the route goes from city 3 to 1 to 6 to 5 to 2 to 4 and then back to city3 (Michalewicz, 1992:172).
As simple crossover will destroy the validity of tours, various other crossoveroperators have been developed to ensure that tours remain valid and thattours are improved.
Adjacency Representation
With the value j in the ith position, the adjacency representation impliesthat the route goes from city i to j (Michalewicz, 1992:168). For example,
GA Theory and Application 44
the tour T = 3 1 6 5 2 4 means that the route goes from city 1 to 3, from 3to 6 to 4 to 5 to 2 to 1.
Simple crossover also creates impossible and infeasible tours when thistype of representation is used. Goldberg (1987:205) states that heuristicshave been used as crossover operators using the adjacency representationand that fairly good solutions of 200 node problems have been producedusing these methods. Choi et al. (2003) used this representation to solve theasymmetric TSP.
GAP Representation
Baker & Ayechew (2003) uses this presentation to solve VRPs. The chromo-some’s length is the number of customers to be routed. Each allele (value)in the string represents the vehicle number that will serve that customer.Simple crossover can be used with the GAP representation.
Constraints
Constraints are not specifically coded into the GA string representation, butis incorporated in the GA by penalising the fitness value of strings (possiblesolutions) that violate constraints.
Goldberg (1987:85) transforms a model with constraints to a model with-out constraints that can be solved by a GA. The generic model that needsto be solved is:
Minimise f(X) (3.12)
Subject to:
gi(X) ≥ 0 ∀i ∈ {1, 2, ..., n} (3.13)
This model is transformed to one that a GA can solve by introducing ras the penalty coefficient for constraint violations and Φ as the penalty func-tion that determines the penalty of violating a specific constraint (Goldberg,1987:86; Michalewicz, 1992:98):
Minimise f(X) + r ·n∑
i=1
Φ[hi(X)] (3.14)
Goldberg (1987:86) uses penalty functions in his book defined as Φ[hi(X)] =h2
i (X).
GA Theory and Application 45
3.1.5 Evaluation Functions
The GA requires a method to determine the fitness of chromosomes. Theobjective function value of the solution represented by the chromosome isdetermined and is used as the fitness of the chromosome.
The evaluation function will be executed on all solutions generated at anystage by the GA. It is typical to keep track of the solution with the highestfitness level found in any generation in this function (Michalewicz, 1992:42).This is because the highest fitness in generation t+ 1 might be less than thehighest fitness in generation t.
3.1.6 Initialisation
Populations in GAs are often generated in a random way. With a binaryrepresentation this is quite easy, however when integer codings are used torepresent TSP routes or VRP tours, the randomly generate route or tourmight not be feasible. Repair algorithms can be used to create feasible toursout of the infeasible ones.
Vas (1999:263) states that initial solution can be generated randomly orheuristically. Skrlec et al. (1997) found that heuristic methods used for theinitialisation process “can massively reduce the search space, and thus speedup the convergence of the algorithm”. Tan et al. (2001a) also suggests theuse of heuristic methods. It can be concluded that, contrary to what waspreviously believed, GAs are sensitive to the quality of initial solutions.
3.1.7 Operators
Selection
The biased roulette wheel selection method is a simple operator and is ap-plied in numerous GA applications. The roulette wheel selection method isdiscussed in section 3.1.2 and is illustrated in Figure 3.3. The fraction of achromosome’s fitness relative to the fitness of the entire population is usedas the probability of selection for that chromosome.
Elitist models is the same as the roulette wheel method except that thebest solutions from the previous generation are simply copied to the nextgeneration (Michalewicz, 1992:56).
The expected value model is based on roulette wheel selection but keepscount of the number of times that a chromosome has been selected. After thiscount reaches a certain value (the number of copies of a specific chromosomeexpected in the next generation), the chromosome is rendered unavailable forselection (Michalewicz, 1992:56).
GA Theory and Application 46
Michalewicz (1992:56) states that elitist and expected value models canbe combined to form the elitist expected value model. Michalewicz (1992:59)uses this selection approach in a modified GA.
Crowding factor models replaces “old” chromosomes by newly generatedchromosomes. The “old” chromosome to be replaced is selected from thechromosomes that resembles the new string (Michalewicz, 1992:56).
Crossover
Crossover is not always applied to all pairs of parents. Crossover is, however,applied to selected pairs of parents with a crossover probability of pc (Vas,1999:265). The SGA example used all chromosomes for crossover and thusused pc = 1. It should be noted that an even number of chromosomes are re-quired for crossover operations. When an uneven number of chromosomes areselected, the chromosome with lowest fitness need to be removed or anotherchromosome should be selected from the previous population (Michalewicz,1992:38).
Various different crossover have been proposed in literature and all havedifferent applications, advantages and drawbacks. The most prominent crossoveroperators are described below.
Simple Crossover (SXO)
Goldberg (1987:12), Michalewicz (1992:21) and Potgieter (1997:55) state thatthe simple crossover (SXO) is used with a binary string representation. TheSXO of string A and B is started by randomly selecting a crossover position.When assuming that the random position is 4, the part of A to the rightof the position is exchanged by the part of B to the right of this position.The simple crossover (at position 4) is applied to two strings A and B andproduces A′ and B′ (see Figure 3.7).
Figure 3.7: Simple Crossover (SXO)
GA Theory and Application 47
Double Simple Crossover (DSXO)
Vas (1999:265) and Michalewicz (1992:68) describe a two-point or doublesimple crossover (DSXO). The DSXO is applied to binary strings and usestwo randomly selected crossover points. Only the alleles between the crosspoints are exchanged between the parent chromosomes. A and B is crossedover in this fashion and produces A′ and B′, as shown in Figure 3.8.
Figure 3.8: Double Simple Crossover (DSXO)
When solving the TSP integer representations are used in strings. Per-forming a SXO or DSXO on these strings will generate illegal strings ascertain cities will be duplicated in one route. To overcome this problem, thefollowing operators have been developed for use with path representations.
Partially Matched Crossover (PMX)
The partially matched crossover (PMX) is described by Goldberg (1987:170)and Michalewicz (1992:172). This operator is often used with TSP problemswhere integer in stead of binary string codings are present. Two crossing sitesare randomly picked within the selected strings; the values between these twopoints of both strings are exchanged between the two and otherwise staysexactly the same.
A = 1 2|3 4 5|6 7 8 9B = 4 2|1 8 9|6 7 3 5
After exchanging the middle parts of the string, the strings look as follows:
A′ = 1 2|1 8 9|6 7 8 9B′ = 4 2|3 4 5|6 7 3 5
The next step is to position-wise exchange values between strings. Inthis example the 3, 4 and 5 values outside the cross points in string B arechanged to the values above them between the cross points (i.e. 1, 8 and 9respectively). In the same fashion, the 1, 8 and 9 outside the cross points inA are changed to 3, 4 and 5. After this step the crossover is complete andyields the following strings:
GA Theory and Application 48
A′′ = 3 2|1 8 9|6 7 4 5B′′ = 8 2|3 4 5|6 7 1 9
Order Crossover (OX)
Goldberg (1987:174) and Michalewicz (1992:173) claim that in order crossover(OX) two random crossover points are selected. Like PMX, the values be-tween cross points are mapped between the strings. A sliding motion is thenused to fill the gaps left by mapping values.
A = 1 2|3 4 5|6 7 8 9B = 4 2|1 8 9|6 7 3 5
When mapping A to B, cities 1, 8 and 9 leaves gaps (g) in string A:
A′ = g 2|3 4 5|6 7 g g
The gaps are ignored and (from the position to the right of the secondcross point) the values are moved into the next string position. This willleave gaps between the two cross points and values outside these points:
A′ = 4 5|g g g|6 7 2 3
The same procedure is applied to B and then the original values betweenthe cross points are inserted into the other string and in so doing the gapsare replace by values.
A′′ = 4 5|1 8 9|6 7 2 3B′′ = 8 9|3 4 5|6 7 2 1
Cycle Crossover (CX)
The cycle crossover (CX) is described by Goldberg (1987:175) and Michalewicz(1992:174). Goldberg (1987:175) states that CO “performs recombinationunder the constraint that each city name come from one parent or the other”.The process is described with the following string examples:
A = 1 2 3 4 5 6 7 8 9B = 4 2 1 8 9 6 7 3 5
The first (most left) value of A is chosen for string A′:
A′ = 1 ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗City 1 in A is in the same position as 4 in B (1 is above 4), city 4 is
copied from A to A′:
A′ = 1 ∗ ∗ 4 ∗ ∗ ∗ ∗∗
GA Theory and Application 49
City 4 in A is in the same position as 8 in B (4 is above 8), city 8 iscopied from A to A′:
A′ = 1 ∗ ∗ 4 ∗ ∗ ∗ 8 ∗City 8 in A is in the same position as 3 in B (8 is above 3), city 3 is
copied from A to A′:
A′ = 1 ∗ 3 4 ∗ ∗ ∗ 8 ∗City 1 in B is under 3 in A, but cannot be selected as 1 is already present
in A′. The cycle is now complete. All places with * is now replaced by thevalues in those positions in B. Doing this and applying a similar process toB, the following chromosomes are obtained:
A′′ = 1 2 3 4 9 6 7 8 5B′′ = 4 2 1 8 5 6 7 3 9
Arithmetical Crossover (AXO)
A linear combination of the values is used in the AXO. WhenA = a1, a2, ..., al
and B = b1, b2, ..., bl is crossed, the alleles in the chromosomes created arecalculated by ai = kbi + (1− k)ai and bi = kai + (1− k)bi. The parameter kis either a user-defined constant value or a variable that dynamically changeswith the generation number. If k is a variable, the crossover is called aNon-Uniform Arithmetical Crossover.
Edge Recombination Crossover (ER)
Michalewicz (1992:177) describes ER and states that ER produces excel-lent results when used in TSP solution GAs. ER transfers 95% of edges(neighbouring cities) from parents to their offspring. The edges in the tourT = 1 5 4 2 6 3 are (1,5), (5,4), (4,2), (2,6), (6,3) and (3,1). ER ensures thatoffspring consist exclusively of edges found in both parents. An example forthe crossover of A and B is discussed.
A = 1 2 3 4 5 6 7 8 9B = 4 1 2 8 7 6 9 3 5
Table 3.6 represents the edge list that needs to be compiled in the execu-tion of the ER operator. For each city, all of its neighbours in both stringsA and B is written down (duplicates are ignored and it is assumed that thefirst and the last city in a route are neighbours).
The offspring starts with the selection of either A or B’s first city. Thecity with the smallest number of edges is selected. If a tie exists, it is brokenarbitrarily. City 1 and 4 both have 3 edges, city 1 is arbitrarily chosen as
GA Theory and Application 50
Table 3.6: ER Edge List
City Edges1 9 2 42 1 3 83 2 4 9 54 3 5 15 4 6 36 5 7 97 6 88 7 9 29 8 1 6 3
the first allele of the offspring. City 1 is directly coupled to 9, 2 and 4. Thenext allele in the offspring is selected from these three. Once again the citywith the least edges are chosen and ties are broken arbitrarily. Cities 4 and2 are tied at 3 edges each (city 9 has 4 edges), city 4 is chosen as the secondallele. This process is continued and produces offspring C which is made upentirely of edges found in its parents.
C = 1 4 5 6 7 8 2 3 9
Skrlec et al. (1997) used the ER operator to solve VRPs and has foundthat it transfers the most data from parents to offspring (95-99% of connec-tions are transferred to offspring).
Enhanced Edge Recombination Crossover (EER)
ER is enhanced using flagged cities (Michalewicz, 1992:179; Hwang, 2002).When a city is found as the edge to a city in both parents, a “-” characteris used to flag that city. The “-” simply means that the relevant city shouldactually have been listed twice in the edge list. A and B is used to illustrateEER.
A = 1 2 3 4 5 6 7 8 9B = 4 1 2 8 7 6 9 3 5
Table 3.7 represents the edge list that needs to be compiled in the execu-tion of the ER operator.
Where ties were arbitrarily broken in ER, EER gives priority to flaggedcities. The EER performs even better than ER (Michalewicz, 1992:179). Asthe path representation does not represent the important properties of tours
GA Theory and Application 51
Table 3.7: EER Enhanced Edge List
City Edges1 9 -2 42 -1 3 83 2 4 9 54 3 -5 15 -4 6 36 5 -7 97 -6 -88 -7 9 29 8 1 6 3
adequately, ER and EER solves this problem by complementing the pathrepresentation with the edge list.
Merge Crossover (MX)
The merge crossover (MX) is proposed by Chen et al. (1998) and Louis etal. (1999). This operator uses a global precedence among alleles which isindependent of any chromosome. The global precedence requires that allele iis preferred to be inserted before allele j in the chromosome. In the VRPTWthe precedence represents time windows and the alleles are customers. Thecustomers are sorted according to the opening time of their time windows toform the global precedence vector P . For this example, using parents A andB, it is assumed that P = 1 2 3 4 5 6 7 8 9, meaning that the earliest time1 can be serviced is before 2’s earliest service time and so on.
A = 2 5 6 1 7 3 8 4 9B = 4 1 6 9 3 8 2 5 7
We consider the first allele in each parent (the bold values). A’s firstcustomer appears before B’s first customer in P . The customer with earlierprecedence is placed in the offspring (C) and customers 2 and 4 in B isswapped to maintain validity.
A = 2 5 6 1 7 3 8 4 9B = 2 1 6 9 3 8 4 5 7C = 2 ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗
The second values are now processed in the same fashion as above. Cus-tomer 1 and 5 is under consideration. Customer 1 in B is chosen before 5
GA Theory and Application 52
in A and customers 1 and 5 in A is exchanged. This leads to the followingchromosomes:
A = 2 5 6 1 7 3 8 4 9B = 2 1 6 9 3 8 4 5 7C = 2 1 ∗ ∗ ∗ ∗ ∗ ∗∗
This process continues and yields the following offspring:
C = 2 1 6 5 3 7 4 8 9
Crossover Comparison
Michalewicz (1992:175-179) describes other crossover methods (order-based,position-based, inversion and heuristic); these are not discussed as he foundthat their performance are inferior to the crossovers discussed above.
Michalewicz’s (1992:177,179) discussion of crossover operators indicatesthat EER is the best crossover operator, followed by ER, OX and then PMX.
As it was found that 95-99% of connections present in parents are trans-fered to their offspring, Skrlec et al. (1997) claims that ER is the “bestoperator ever used for solving the TSP”. Filipec et al. (1998) and Ochi et al.(1998) also implemented ER into a GA used for the solution of VRPs.
Chen et al. (1998), Louis et al. (1999) and Tan et al. (2001a) claimthat the MX works best for the VRPTW. Louis et al. (1999) states thatthe “merge crossover performs better than traditional ones [referring to ER,PMX and CX] on VRPTW”. Tan et al. (2001a) also make a similar state-ment. Louis et al. (1999) found that MX works better for random customerlocations, however, they went on to build a clustering algorithm which en-sures that non-random locations are processed just as well.
Mutation
The probability that a bit being processed is mutated is referred to as pm
(Vas, 1999:267). When a bit is mutated with binary coding, the bit is simplyinverted, i.e. a 1 is changed to a 0 and a to a 1. Mutation rates are typi-cally very low, so that good chromosomes are left intact. The mutations arerequired to insure that the GA does not get stuck at local optima and con-sequently ensures that the entire solution space is searched (Vas, 1999:267).
Michalewicz (1992:87) introduces a non-uniform mutation operator thatis sometimes used when integer representations are applied. It has beenshown that GAs with non-uniform mutations perform better than GAs withuniform mutation (Michalewicz, 1992:80,94). The non-uniform mutation isresponsible for the fine tuning capabilities of a GA. This non-uniform mu-
GA Theory and Application 53
tation is formulated in (3.15) with V the original value of the locus, V ′ thenew mutated value, [l, u] the range of V and ∆ defined in (3.16).
V ′ =
{V + ∆(t, u− V ) if random bit is 0
V + ∆(t, V − l) if random bit is 1(3.15)
∆(t, y) = y(1− r(1−a)2) (3.16)
In (3.16), the r value is a random number in the range [0,1] and a = tk
with k a user defined value so that a is in [0.5,1]. The higher the value of a,the earlier the ∆ function value becomes closer to 0 (see Figure 3.9).
Figure 3.9: Delta Function Parameter Settings
Equation (3.15) will cause the operator to widely search the solutionspace in earlier generations and to locally search the solution space in latergenerations.
Pellazar (1994) also suggest a non-uniform mutation rate which linearlydecreases from generation to generation, but uses a route optimisation heuris-tic as a mutation operator. Route optimisation heuristics have been used asmutation operators by various researchers (Zhu, 2003; Berger & Barkaoui,2004; Prins, 2004).
Tan et al. (2001b) uses a non-uniform mutation operator that randomlyswaps selected customers within a solution.
GA Theory and Application 54
3.1.8 GAs and the VRPMC
Although the discussion of GA operators focused mainly on routing problems,there is still some uncertainty of how to solve the VRPMC with a GA. Thetwo distinct approaches used to solve the VRPMC with GAs that have beenfound in literature are discussed.
Old Approach: “Cluster First, Route Second”
This approach was popular in early writings, from 1991 to 1999.Thangiah et al. (1991) developed GIDEON, a GA program used to solve
the VRPTW. At the time of publication it was the best algorithm availablefor the VRPTW as it produced the best known solutions for 41 of the 56Solomon (1987). GIDEON has two distinct modules (based on cluster first,route second):
Clustering Module This module assigns customers to specific vehicles in aprocess called genetic clustering. It uses a GA to sector customers intoclusters, with each cluster serviced by one vehicle. Figure 3.10 showsthe sweeping motion that is used together with seed angles to createclusters:
Figure 3.10: Cluster First Module (Source: Thangiah et al. 1991)
Each vehicle’s cluster is routed to minimise route cost, not taking intoaccount vehicle capacities or time windows. The first customer per
GA Theory and Application 55
route was randomly selected out of the cluster, the rest of the routeis formed by determining which customer, when inserted in the route,will produce the lowest route cost (a cheapest insertion algorithm). Thebest set of clusters obtained in this module is transferred to the nextmodule.
Local Route Optimisation Customers are exchanged between clusters toensure the feasibility of the solution - taking into account time windowsand vehicle capacities. To change a customer’s cluster, its angle isartificially altered. When a cluster is changed, a cheapest insertionalgorithm is used to improve the cluster route.
Two iterations of these steps were used by Thangiah et al. (1991). Aroulette wheel selection along with a binary coding system, two point crossover(pc = 0.8) and simple mutation (pm = 0.001) was implemented. A popula-tion size of 50 was used and the maximum number of generations was 25.Their binary representation allocated 3 bits (loci) for the value of the seedangle. With c clusters created, the chromosome’s length is then given by 3 ·c.
The cluster first, route second approach has also been used by Nygard& Kadaba (1991), Thangiah & Gubbi (1993), Malmborg (1996), Filipec etal. (1997), Skrlec et al. (1997) and Karanta et al. (1999). Nygard & Kadaba(1991) found that GAs for VRPs tend not to perform well when customersare geographically clustered and a small fleet is used. For all other probleminstances the GA performs well.
Tan et al. (2001a) claims that this old method, strictly speaking, “is onlya hybrid heuristic that constitutes some GA element”. It was also found thatthe new approach outperforms the old approach.
New Approach: “Route First, Cluster Second”
Path representations are now mostly used for all VRP variations. This rep-resentation is used although it does not indicate were specific routes beginand end. To indicate separate routes in a chromosome, extra partitioningcharacters need to be inserted into the chromosome. These extra charactersrender the GA useless as:
• The Building Block Hypotheses and Schemata Theorem fail (becausebuilding blocks are interrupted by the extra characters.
• GA operators cannot handle chromosomes with partitioning (crossoverwill lead to infeasible routes).
• Chromosome lengths are increased.
GA Theory and Application 56
GAs use two phases to solve VRP variations, with each chromosomerepresenting a specific path through all the customers. In the first phase(routing), the GA improves this long chromosome string by solving a TSP(including all customers into one route). Phase two (clustering) creates aroute for each vehicle out of the long route. This is done by another algorithmthat adds customers to a vehicle (if time windows are not violated) until thevehicle is full. The following customer in the chromosome (long route) isthen assigned to the next vehicle.
Filipec et al. (1998), Ochi et al. (1998), Maeda et al. (1999), Tan etal. (2001a, 2001b), Hwang (2002), Zhu (2003) and Prins (2004) used thisapproach. The GA proposed by Ochi et al. (1998) is more complex than theothers mentioned as a heterogeneous fleet is incorporated into the GA.
Initial solutions for the VRP and its variations are not generated ran-domly. The initial solution is generated through a heuristic technique andthis leads to faster convergence of the GA (Skrlec et al., 1997; Tan et al.,2001a).
3.2 Programming Languages
3.2.1 Investigation of Programming Languages
The following programming languages are compared and analysed in termsof the applicability of the language to the computer coding of a GA for theVRPMC. Discussions are based on Computer Information Literacy (2001).
C
C was developed for the UNIX operating system during the 1970s. In thelate 1980s it was the most widely used language for programming commercialsoftware.
The language is now outdated and is not suggested for use in this project.
C++
C++ is an object-orientated extension of C. It was the most popular object-orientated language in the early 1990s.
It focuses on graphical implementations, not mathematical capabilities.
GA Theory and Application 57
Delphi
Delphi is an approximate object-orientated version of Pascal. It is mainlyused to create graphical applications for database access.
Delphi is not suggested for use in this project as it does not focus onmathematical operations.
Java
Java can be seen as a less complex version of C++. It was developed duringthe 1990s. Java is mostly used for creating web sites.
As Java focuses on web sites, it is not suggest to be used for coding GAs.
MATLAB
MATLAB and SIMULINK forms part of the same package. Both are pack-ages focused on technical computing. MATLAB is used for “high-performancecomputing, modelling and simulation” (Learning MATLAB, 2002:1-3). It al-lows the solution of mathematical problems in much less time than it wouldtake to code a program in a lower level programming language (for exampleC, C++, Delphi, Pascal and Visual Basic).
The SIMULINK package is a “block diagram tool for modelling and sim-ulating dynamic systems” (Learning SIMULINK, 2002:1-2). It will howevernot be used in this project as to many parallel computations with largeamounts of data are required.
A GA toolbox for MATLAB is available, but is much too general for theapplication of complex GAs as it can only be used for SGAs.
Typical MATLAB uses include (Learning MATLAB, 2002:1-15):
• Mathematics and computations
• Algorithm development
• Modelling and simulation
• Application development
All of these points are exactly what is required for this project (i.e. thecoding of a GA for the VRPMC).
Pascal
The 1970s saw the introduction of Pascal. It was widely used by schools anduniversities as a teaching language.
This language will not be used as better options are available.
GA Theory and Application 58
Visual Basic
Visual Basic (VB) is mainly used for the development of graphical applica-tions for Windows operating systems.
As it focuses on graphics, VB will not be used for this project as a math-ematically focused language is required.
3.2.2 Suggested Language
The above analysis indicates that the MATLAB computer package will beused for the coding and development of an application for the solution of theVRPMC with the developed GA.
3.3 Environmental Analysis Outcomes
This project will develop a GA to solve the VRPMC. The most applicablesettings for this GA is deducted from all of the previous data and is sum-marised in Table 3.8.
Table 3.8: VRPMC and GA Settings
Feature Chosen Setting Reason(s)Chromosome coding Path representation Fits new approachEvaluation function Objective function Equation (2.35)Initialisation Randomly GA requirementSelection Biased roulette wheel Commonly usedCrossover All possible Enables comparisonMutation Non-uniform heuristic Better resultsApproach Route then cluster Better resultsProgramming language MATLAB Math capabilitiespc 0.8 Widely usedpm 0.1 Widely usedPopulation size popsize = 100 Widely usedGenerations 200 Zhu (2003)Fleet size No maximum User specifiedTime windows No maximum User specified
The designed algorithm can now be discussed in detail.
Chapter 4
Conceptual Algorithm Design
The previous sections all serve as an introduction and theoretical foundationfor the Genetic Algorithm that will be developed to solve the VRPMC.
The GA is aimed at providing near optimal solutions for the VRP withmultiple soft windows, a heterogeneous fleet and double scheduling. Thefollowing methodology was be used during the algorithm’s development:
1. Design the algorithm outline
2. Define the parameters, variables and input files to be used
3. Write the pseudocode of the algorithm (in more detail than the outline)
4. Program the algorithm using MATLAB
5. Test the GA and benchmark its performance
6. Develop a Graphical User Interface (GUI) for the GA
The first three steps of the methodology are described in this chapter,whilst the following steps will be dealt with later on.
4.1 GA Outline
The algorithm is developed based on the conclusions drawn from the in-vestigation into heuristic, metaheuristic, evolutionary programming, geneticsearch and vehicle routing literature. These conclusions were summarised inTable 3.8.
During development the classic GA steps (as illustrated in Figure 3.2)were used as a guideline. The designed algorithm is shown in the flowchartin Figure 4.1.
59
Conceptual Algorithm Design 60
Figure 4.1: GA Flowchart
Conceptual Algorithm Design 61
Figure 4.1 was translated into high level pseudocode which forms themain program of the MATLAB code. Each of the blocks in Figure 4.1 aredescribed in more detail (by means of high level pseudocode) in the followingsections. A brief description of the pseudocode is also given in these sections.
The MATLAB code (all 13 M-files) has been included in Appendix E andhas extensive comments built in to simplify the interpretation of the code.
4.2 Variables and Parameters
The following definitions of “variable” and “parameter” are used in the designand consequent discussion of the algorithm:
Parameter A value that is defined by the user or by the problem char-acteristics. A parameter stays constant during the execution of thealgorithm.
Variable A value used in the algorithm’s program which may vary as theprogram progresses.
The main parameters and variables that the GA employs are defined inTables 4.1 and 4.2 (global variables and parameters are indicated with capitalletters). These two tables are by no means exhaustive, but summarises themost important parameters and variables which the algorithm will utilise.
Table 4.1: GA Parameters
Parameter DescriptionAVESPD Average speed of vehiclesCUSTFILE Matrix containing all customer informationFLEETFILE Matrix containing the delivery fleet’s dataFLEETSIZE Number of vehicles in delivery fleetlpenalty Lateness penalty pertaining to soft time windowsmaxnumgen Maximum number of generationsNUMCUST Number of customersnumelites Number of elites in each chromosomeNUMTW Maximum number of time windowspc Crossover probabilitypm Initial mutation ratepopsize Number of chromosomes in each populationxotype Type of crossover to be used
Conceptual Algorithm Design 62
Table 4.2: GA Variables
Variable DescriptionBEST Best solution found so farBESTGEN Generation number in which best solution was foundinitpop Initial solution population’s dataFIT List of each generation’s best chromosome’s fitnessgennum Current generation numbermrate Non-uniform mutation rateNEWPOP Data of population being creatednummute Number of mutations per generationnumxo Number of crossovers per generationPOP Current population’s data
4.3 Main Program
The main program is responsible for the control and execution of the al-gorithm and is shown in Pseudocode 1. Within the pseudocode there arereferences to sections within the document; these section describes the rel-evant step in more detail. References are also made to appendixes whichshows the actual MATLAB code for that step.
4.4 GA Settings
The parameters for both the algorithm and type of VRPMC is specifiedin this step. All the main variables that the algorithm will require is theninitialised. Variable initialisation is one of the key steps in speeding upMATLAB program execution (Learning MATLAB, 2002:6-27).
The high level pseudocode for this step is shown in Pseudocode 2. Theparameters that are required (as defined in Table 4.1) are defined by the userin this pseudocode. The user will input these values in the GA application’sGraphical User Interface (GUI).
Two data files are required as input for the algorithm. The first input fileis a Microsoft Excel (xls) file which contains all the customers’ data. Thesecond input file is a Microsoft Excel (xls) file which encapsulates informationregarding the delivery vehicle fleet. The format for these two files mustbe correct and can be seen in Appendixes C and D. Examples of correctlystructured input data files can be found on the accompanying CD.
Conceptual Algorithm Design 63
Pseudocode 1 Main Program
1: Specify GA settings (Section 4.4, Appendix E.2)2: Generate initial solutions (Section 4.5, Appendix E.4)3: For gennum = 1 to (maxnumgen− 1) do4: Diversify search space if required (Section 4.6, Appendix E.5)5: Cluster TSP solutions (Section 4.7, Appendix E.6)6: Determination of chromosome fitness (Section 4.8, Appendix E.7)7: Plot fitness against generations and routes (Appendix E.8)8: Clone elites (Section 4.9, Appendix E.9)9: Perform crossover (Section 4.10, Appendix E.10)
10: Execute mutation (Section 4.11, Appendix E.11)11: End for12: Increment gennum13: Diversify search space if required, Appendix E.214: Cluster TSP solutions (Section 4.7, Appendix E.6)15: Determination of chromosome fitness (Section 4.8, Appendix E.7)16: Plot fitness against generations and routes(Appendix E.8)17: Plot routes (Appendix E.8)18: Display best solution (Appendix E.12)19: Save variables to hard drive
All the variables that the main MATLAB program uses are then initialisedto ensure faster execution of the program (Learning MATLAB, 2002:6-27).
4.5 Initial Solution Generation
The high level pseudocode of this step of the proposed algorithm is shown inPseudocode 3.
In Pseudocode 3 initial solutions for the VRPMC is generated in a randomfashion. The generated population is saved in the initpop structure variable.
For the random initial solution generation, a string (list) of popsize ran-dom numbers are generated. Customer numbers are then assigned fromsmallest to largest over the smallest to largest random numbers (line 4). Therandom order of customers within one of these TSP solutions does not guar-antee that the solution is feasible. This is due to time window and vehiclecapacity constraints that might not be adhered to.
Conceptual Algorithm Design 64
Pseudocode 2 Specify GA Settings1: Set GA settings2: Read in population size (popsize)3: Read in number of generations (maxnumgen)4: Read in crossover probability (pc)5: Read in initial mutation probability (pm)6: Read in crossover to be used (xotype)7: Read in number of elites (numelites)8: Read in lateness penalty (lpenalty)9: Specify VRPMC settings
10: Import customer data file (CUSTFILE )11: Import fleet data file (FLEETFILE )12: Calculate delivery fleet size (FLEETSIZE )13: Calculate maximum number of time windows (NUMTW )14: Set average speed of vehicles (AVESPD)15: Variable initialisation16: BEST.fitness⇐ 999999917: BESTGEN ⇐ 018: FIT ⇐ empty matrix19: numxo⇐ 020: nummute⇐ 021: gennum⇐ 0
Pseudocode 3 Initial Solution Generation1: For tel = 1 to popsize do2: Assign popsize random numbers (between 2 and NUMCUST ) to list3: For tel2 = 1 to (NUMCUST -1) do4: Assign tel to position with minimum random number in list5: End for6: Move random numbers one position to the right7: Assign 1 to the first position8: Assign 1 to the (last+1) position9: initpop(tel).tsp⇐ list
10: initpop(tel).unrouted⇐ list without customer 111: End for
Conceptual Algorithm Design 65
4.6 Search Space Diversification
The GA’s search space is diversified when more than 25 duplicate chromo-somes are present in one population. The diversification is performed by thepseudocode shown in Pseudocode 4.
Pseudocode 4 Diversification1: For tel = 1 to (half the number of duplicates) do2: For count = 1 to 5 do3: pos1 ⇐ random chromosome position4: pos2 ⇐ random chromosome position5: Swap customers in positions pos1 and pos26: End for7: End for
Line 1 ensures that half of all the duplicate chromosomes are modified.The modification process is similar to the mutation operator proposed inSection 4.11.
Lines 3 through 5 swaps the values (customer numbers) found in tworandom positions in the chromosomes. Line 2 repeats the swap process fivetimes per duplicate chromosome.
4.7 TSP Solution Clustering
The TSP solutions will be clustered into routes by the high level pseudocodegiven in Pseudocode 5.
Pseudocode 5 Cluster TSP Solutions1: For chromno = 1 to popsize do2: While all customers not routed3: cust⇐ first unrouted customer4: found⇐ 05: While found = 06: Select route number (routeno)7: Route cust into route routeno8: Try cust from last to first position in route9: If feasible route, found⇐ 1
10: End while11: End while12: End for
Conceptual Algorithm Design 66
This step tries to find a feasible position for a specific customer in apossible route. This is done by trying to fit the customer into the vehicle’sfirst route (where vehicles may have more than one route due to doublescheduling). In lines 6 and 7 the customer is assigned to a route if no timewindow or vehicle capacity constraints are violated.
If all the customers are not routed when all the vehicles’ first routeshave been completed, additional routes can be used (lines 5 and 6). Thisincorporates the principle of double scheduling into the algorithm.
As all vehicles are already acquired, the fixed costs regarding the use ofa specific vehicle is a sunk cost and is consequently assumed to be irrelevantfor decision making purposes (Garrison & Noreen, 2003:57). All the vehiclesin the fleet are therefore filled before double scheduling is brought into play,i.e. before more than one route is assigned to a vehicle.
The clustering procedure involves an enormous amount of calculations be-cause route feasibility testing must be performed. The amount of calculationsrequired for feasibility testing is much more than the amount of calculationsrequired for GA operators. The feasibility testing code is also more complexthan the code required for the GA operators and consequently the algorithmwill spend most of its execution time determining whether routes are feasibleor not.
4.8 Chromosome Fitness Determination
The fitness of the chromosomes in the current generation is calculated by thehigh level pseudocode shown in Pseudocode 6.
Pseudocode 6 Calculate Chromosome Fitness1: For chromno = 1 to popsize do2: Determine number of routes in POP (chromno)3: POP (chromno).numroutes⇐ answer4: End for5: For chromno = 1 to popsize do6: Calculate and sum total lateness penalties of all routes7: Calculate and sum total distance of all routes8: POP (chromno).fitness⇐ lateness penalty + distance9: End for
10: If best fitness in POP < BEST.fitness11: BEST ⇐ best chromosome in POP12: End if
Conceptual Algorithm Design 67
The fitness of a chromosome consists of two parts. The first part (line 6)is the lateness penalties occurred during the deliveries. The second part (line7) is the total distance of all the routes assigned. In line 8 these two values aresummed to determine the chromosome’s fitness. The calculations in lines 6and 7 will require the number of routes present in each chromosome, thereforelines 1 through 3 calculate the number of routes in the current chromosome.
Lines 10 through 12 keeps track of the best fitness and its associatedroutes during the various generations.
4.9 Cloning Elites
The principle of “elites” is incorporated into the algorithm by cloning (copy-ing) the best chromosomes from one generation to the next. Pseudocode 7shows the high level pseudocode that will perform the cloning of chromo-somes.
Pseudocode 7 Clone Elites1: Initialise NEWPOP structure variable2: For num = 1 to numelites do3: Find best chromosome in POP4: plek ⇐ position of best chromosome5: NEWPOP (plek) ⇐ POP (plek)6: End for
The best chromosomes from the current population is copied to the nextgeneration without any changes whatsoever (lines 2 through 6). The clonedchromosomes is copied to the same position in NEWPOP as they were inPOP. The number of elites copied to the next generation is numelites, thenumber of elites specified by the user.
4.10 Crossover
The pseudocode that will perform the crossover operation for this algorithmis listed in Pseudocode 8. The if-else statement in lines 1, 17 and 26 dividesthe crossover code into two sections:
1. The first section performs the Enhanced Edge Recombination (EER)or Merge Crossover (MX). Crossovers in this section produces oneoffspring from its two parents.
Conceptual Algorithm Design 68
Pseudocode 8 Perform Crossover1: If EER, MXL, MXe or MXangle crossover2: For chromno = 1 to popsize do3: If chromosome is not an elite and (random number) ≤ pc
4: Select 2 chromosomes with biased roulette wheel5: Case crossover of6: EER: Create enhanced edge list7: Generate new offspring from edge list8: MXL: Create precedence vector based on Li times9: Generate new offspring using precedence vector
10: MXe: Create precedence vector based on ei times11: Generate new offspring using precedence vector12: MXangle: Create precedence vector based on angles13: Generate new offspring using precedence vector14: End case15: End if16: End for17: Else18: For chromno = 1 to truncate(popsize÷ 2) do19: If (random number) ≤ pc
20: Select 2 chromosomes with biased roulette wheel21: If chromosome is not an elite22: Generate 2 new offspring with PMX23: End if24: End if25: End for26: End if
Conceptual Algorithm Design 69
2. The second section handles all other crossovers which generate twooffspring from their two parents. Only the Partially Matched Crossover(PMX) is coded into this section of the crossover code.
Lines 3 and 19 allows crossovers only to be performed pc% of the time.Lines 3 and 19 also ensures that the cloned elites is not written over by thecrossover. Biassed roulette wheel selection is used for both sections of thecrossover code (lines 4 and 20).
4.11 Mutation
The mutation in this algorithm will be performed by the high level pseu-docode listed in Pseudocode 9.
Pseudocode 9 Execute Mutation1: mrate⇐ pm · e−0.0001·gunnum
2: For chrom = 1 to popsize3: If (random number) ≤ mrate4: Increment nummute5: Swap two randomly selected customers6: End if7: End for
The GA will use a non-uniform mutation rate. The heuristic mutationoperator will swap randomly selected customers in the TSP solution. Theclustering used in the algorithm (see Pseudocode 5) will ensure that feasibleroutes are formed after the swap, i.e. no time window or capacity constraintswill be violated.
Line 1 calculates the mutation rate that is applicable in the current gen-eration. The non-uniform mutation rate decided upon for this algorithm isdefined in (4.1) and is illustrated in Figure 4.2.
mrate = pm · e−0.0001·gennum (4.1)
The probability of mutation taking place in a chromosome is mrate.When mutation must take place, two random customers are swapped in theTSP solution.
The next chapter presents a reflection on the evolution of the algorithmsince its initial development and coding. This evolution lead to the finalalgorithm that was discussed in this chapter.
Conceptual Algorithm Design 70
Figure 4.2: Variable Mutation Rate Graph
Chapter 5
Algorithm DevelopmentReflection
This chapter provides a broad overview of the changes that were made (al-ternatives that were evaluated) during the development of the algorithm toenhance its performance. All the relevant changes are discussed along withtheir effect on the algorithm’s performance.
For all the algorithm performance comparisons done in this chapter, theGA settings listed below was used. These settings have been found to producevery good GA performance. Chapter 6 addresses these GA variables and theirinfluence on algorithm performance in detail.
• Crossover probability: pc = 0.8
• Initial mutation rate: pm = 0.1
• Population size: popsize = 100
• Number of generations: maxnumgen = 15
• Number of elites: numelites = 5
• Solomon C101 benchmarking instance (chosen purely for illustrativereasons; refer to Appendix A for details regarding the Solomon bench-marking problems)
The Solomon C101 benchmark problem was used throughout this chapterso that the performances of the algorithm variations can be compared to eachother (so that one can compare apples with apples). The C101 problem hasclustered customers and it is therefore easy to judge the quality of routesfrom a plot of vehicle routes and customers.
71
Algorithm Development Reflection 72
All the fitness graphs in this chapter have the following legend:
• Dotted line - Maximum fitness
• Dashed line - Average fitness
• Solid line - Minimum fitness
The fitness graph and plot of routes is only shown for alternatives thatproduce better solutions than previous alternatives.
5.1 Original Algorithm
The original algorithm consisted of the following relevant components:
Clustering Customers are inserted into the first feasible position in the firstpossible route.
Crossover Only the EER crossover was programmed.
The final solution of the original algorithm generates is:
• Fitness: 3163.8
• Number of routes: 16
The fitness value of 3163.8 presents a very poor solution to the SolomonC101 problem since the best published result for this problem is 827.2 (seeAppendix B).
The maximum, average and minimum fitness over the various generationsas well as the assigned routes are illustrated in Figure 5.1. The illustrationshows that the GA does not converge to any specific value. The fitnessvalues is reminiscent of the fitness values that a random search heuristic willproduce. The randomness of the GA’s output and the poor fitness valuesfound indicate that a problem exists in the current algorithm.
5.2 MX Crossover (based on Li)
To address the poor performance problem, the GA was adapted so that theuser can specify which crossover is to be used. The MX crossover dramaticallyimproved the algorithm’s performance. The precedence vector for MX wasbased on the closing times (Li) of the customers’ time windows.
Algorithm Development Reflection 73
Figure 5.1: Original GA Output
This GA variation provides the following solution:
• Fitness: 1046.2
• Number of routes: 11
The fitness value of 1046.2 indicates that the MX operator produces muchbetter results than EER.
The maximum, average and minimum fitness over the various generationsas well as the assigned routes are illustrated in Figure 5.2. The fitness valuefound and the graph indicate that MX produces better answers and that theGA converges to a specific minimum fitness value. Further improvement ishowever still required.
5.3 Cluster at End of Route
The clustering part of the algorithm was adapted to firstly try and insertcustomers at the end of the route rather than at the beginning.
Algorithm Development Reflection 74
Figure 5.2: GA with MX Output
The best solution found by the algorithm, as described above, is:
• Fitness: 1143.0
• Number of routes: 11
These values indicate that to perform the clustering at the end of theroute does not enable the algorithm to find better results than to cluster atthe start of the route (as in the previous section).
5.4 Earliest Customer Clustering
The clustering part of the algorithm was again adapted, this time to startthe clustering procedure with the customer who has the earliest time windowdeadline (Li). This procedure is illustrated in Figure 5.3.
After the earliest deadline customer (3) is routed, the rest of the customersin the TSP solution is routed. This is done by starting from the customer tothe right of the earliest deadline customer (5); all the customers to the endof the TSP solution is then routed (arrow A). Next, the first part of the TSP
Algorithm Development Reflection 75
Figure 5.3: Clustering Order
solution is routed up until the customer before the earliest deadline customer(4) (arrow B).
The final solution that the algorithm produces with the above mentionedcomponents:
• Fitness: 1043.4
• Number of routes: 11
For the new best solution, the maximum, average and minimum fitnessover the various generations as well as the assigned routes are illustrated inFigure 5.4.
This variation of the clustering produces slightly better results then thealgorithm variation shown in section 5.2. This variation of the GA will nowbe built on to seek further improvements.
5.5 MX Crossover (based on ei)
The Merge Crossover used in the previous section uses the MX operator baseda precedence vector derived from Li (time windows closing time) values (referto section 5.2). The precedence vector was then derived from the ei (timewindow opening time) values instead. This changed MX operator generatedthe following solution:
• Fitness: 1130.4
• Number of routes: 11
From these results, one may conclude that the MX based on ei values isoutperformed by the MX based on Li values. Other types of improvementopportunities now need to be evaluated.
Algorithm Development Reflection 76
Figure 5.4: GA with Earliest Customer Clustering
5.6 Constant Mutation Rate
For this variation of the algorithm, the mutation rate of the algorithm insection 5.4 was changed as to remain constant over the various generations,i.e. the non-uniform mutation operator was changed to a uniform muta-tion operator. This was done to try and diversify the search space withoutcompromising solution quality.
The solution that the algorithm generates:
• Fitness: 1135.8
• Number of routes: 11
This section showed that the constant mutation rate causes a slight in-crease in the best fitness found by the algorithm. The search space can thusnot be diversified using a constant mutation rate without causing poorer GAperformance. A non-uniform mutation operator, as used previously, will stillbe used.
Algorithm Development Reflection 77
5.7 Previous Route Clustering
This section’s algorithm tested the effect of another kind of clustering. Theclustering used by the algorithm was adjusted to try and route customersinto previously filled routes before creating a new route especially for thecurrent customer.
Customers are inserted into the first feasible position in the first possibleroute. Before a new route is started, the algorithm tries to fit the customerinto one of the previous routes.
The final solution that the algorithm produces with the above mentionedcomponents is summarised below:
• Fitness: 1436.5
• Number of routes: 11
The algorithm results shown above indicate that this type of clusteringproduces worse answers than the algorithm in section 5.4. This is due tothe fact the GA is misled by the clustering procedure. The GA is unableto determine which customers should be located where in the chromosometo increase fitness; this is because the clustering keeps on moving customersto various other positions. This clustering most probably forces the GA toconverge to local optimal solutions.
5.8 Local Optimisation
A local optimisation function was added to the end of the algorithm to locallyimprove the algorithm’s final solution. The local optimisation search heuristictests all the possible combinations of customers in all the routes to determinewhether other combinations improve the overall fitness.
With the GA settings used in section 5.4, the local optimisation proceduredid not find any better combination of the routes’ customers. This is anindication of how well the GA alters the chromosome to ensure that theclustering operator places customers in the best possible routes.
The solution produced with the above mentioned variation of the GA isdescribed below:
• Fitness: 1127.7
• Number of routes: 11
Algorithm Development Reflection 78
The local optimisation did not improve the final solution for this probleminstance. However, when the GA settings are chosen in such a manner thatbad solutions will be generated, the local optimisation will improve finalsolutions. In such a case it is much quicker and more advisable to choosecorrect GA settings rather than to rely on slow local optimisation for thebetter results. Local optimisation will thus not be used further on in theGA.
5.9 Time Window Compatibility
The customers whose time windows are the most incompatible need to bedetermined. These customers can then be routed before any other customersto ensure that they do not cause routing difficulties later on in the algorithm.
5.9.1 Spare Time Compatibility
One way that can be used to quantify the incompatibility of a time windowis to determine how much spare time there is between its closing time (Li)and the arrival time at the customer. One customer’s time window(s) hasdifferent compatibilities to different customers. For this reason a time windowcompatibility matrix is created.
The compatibility of customer i’s time window relative to customer j’stime window is calculated as Li − aji, where aji is the arrival time if onetravels from customer j to i. When aji is later than Li (i.e. i cannot beserved after j) a large negative value is assigned as the compatibility forcustomer i. The compatibility of all the other customers’ time windows arecalculated in the same way. This process is repeated for departing from allcustomers to serve all customers. Given n customers, an n × n matrix ofvarious time window compatibilities will be generated, assuming one timewindow per customer. To quantify the total time window compatibility of acustomer, the row and column of the matrix corresponding to that customeris summed.
The 5% or 10% most incompatible customers are then moved in the chro-mosome to the position where the first customers will be routed from. Thiswill ensure that the time window incompatibile customers are the first cus-tomers to be inserted into routes.
When these concepts are incorporated into the GA, the following solutionis produced:
• Fitness: 1416.9
Algorithm Development Reflection 79
• Number of routes: 12
This solution is much worse than the best solution found so far. Toimprove the solution provided by the time window compatibility variation,the compatibility concept is slightly adjusted under the next heading.
5.9.2 Overlapping Time Compatibility
This GA variation is based on the same principles as stipulated under theprevious heading, except that the individual compatibility values are calcu-lated differently.
In many problems, certain time windows fall in approximately the sametime slot. When narrow time windows are present, two overlapping timewindows will most probably have to be serviced by different vehicles. Toensure this, the amount that time windows overlap is used as the time windowcompatibility value.
The percentage overlap between two windows is calculated using their ei
and Li values. When a customer cannot be served after some other customer,a large positive value is assigned as the compatibility for that customer.
The customers with the least overlap is moved within the chromosome sothat they will be routed before any other customers.
When this time window compatibility variation is incorporated, the fol-lowing solution is found:
• Fitness: 1280.4
• Number of routes: 11
This answer is better than the spare time compatibility variation of timewindow compatibility, but is still not an improvement on the best solutionfound thus far.
5.9.3 Position of Incompatible Customers
In the previous two sections incompatible customers were included at posi-tions in the chromosome so that they will be the first customers to be routed.
Another GA alternative tested was to insert the incompatible customer inthe first positions of all the routes created, with only one incompatible cus-tomer per route. This generated the same solutions as found in the previoustwo sections.
Algorithm Development Reflection 80
5.10 Alternative Selection Methods
Various alternative selection methods was coded into the GA to test theirperformance. The previous GA variations all used biased roulette wheel se-lection.
5.10.1 Random Selection
Instead of biased roulette wheel selection, a simple random selection pro-cedure was used to select chromosome for crossover. This GA alternativegenerated the following solution:
• Fitness: 1130.8
• Number of routes: 12
The random selection method did not improve the quality of the solution.
5.10.2 Random and Roulette Wheel Selection
Another alternative investigated was to use random selection for 50% ofthe selections and biased roulette wheel selection for the other 50% of theselections. This produced the following result:
• Fitness: 1146.6
• Number of routes: 11
This selection method also did not produce a solution better than thebest found so far.
5.10.3 Reversed Roulette Wheel Selection
A major problem contributing to the bad quality of the previous alterna-tives is that a large number of duplicate chromosomes that are created inlater generations (early convergence to non-optimal solutions). To addressthis problem and to diversify the search space, reverse biased roulette wheelselection was tested. For this project, reverse biased roulette wheel selectionis defined as a biased roulette wheel selection method that gives the highestprobability of selection (i.e. biggest part of the wheel) to the chromosomewith the worst fitness. This GA variation produced the following result:
• Fitness: 1188.8
Algorithm Development Reflection 81
• Number of routes: 12
Although the search space was increased and diversified, the GA did notfind better solutions than that was found earlier.
5.11 Fast Clustering
It is suspected that the clustering procedure used so far incorporates toomuch intelligence and that it therefore misleads or deceives the GA. Becauseof the intelligence of the clustering, the GA is unable to determine which cus-tomers should be located in which positions to produce improved solutions.This is because the clustering keeps on moving customers to various otherpositions.
To remove some intelligence from the clustering, the clustering procedurewas changed to only try and route customers at the end of the current route.Currently the clustering strives to route customers in all positions in theroute, starting from the back.
The new clustering will not deceive the GA as much as previously andwill drastically increase the execution time of the algorithm. The executiontime is decreased since much less positions in the routes are now tested forfeasibility (and feasibility checking takes extremely long to execute).
The GA with fast clustering produced the following result:
• Fitness: 1020.6
• Number of routes: 11
The maximum, average and minimum fitness over the various generationsas well as the assigned routes are illustrated in Figure 5.5.
This result is the best result found thus far. Although it is an improve-ment, the best published value of 827.2 is still quite far away.
5.12 Partially Matched Crossover (PMX)
The GA developed so far was adapted to use the PMX crossover. The work-ings of PMX was discussed in section 3.1.7. The PMX based GA found thefollowing result:
• Fitness: 3566.7
• Number of routes: 24
The PMX results in extremely poor GA performance and is consequentlydeemed inappropriate for used when solving vehicle routing problems.
Algorithm Development Reflection 82
Figure 5.5: GA with Fast Clustering
5.13 Diversification
As described earlier, the GA produces a large number of duplicate chromo-somes after about 10 generations. The search space is thus very limited.To diversify the search space again, various diversification techniques wereassessed.
5.13.1 Random Diversification
When more than 25 duplicate chromosomes are present, half of the dupli-cate chromosomes are replaced by randomly generated chromosomes. Thesechromosomes are generated in the same fashion as the random initial solutiongeneration. The newly included random chromosomes replaces the duplicatesto diversify the search space.
With this random diversification, the GA produces the following result:
• Fitness: 1024.1
• Number of routes: 11
Algorithm Development Reflection 83
This result is approximately equal to the previous best solution. As noimprovement was introduced by the random diversification, one may concludethat it does not improve GA performance.
5.13.2 Diversification using Mutation
This method of diversification swaps two random customers in the chromo-some to diversify the search space and to eliminate duplicates. As soon as25 duplicate chromosomes are present, this mutation type diversification isapplied to half of the duplicate chromosomes.
The mutation type diversification variation of the GA produced the fol-lowing solution:
• Fitness: 1020.6
• Number of routes: 11
This result equals the best solution found thus far. The diversificationusing mutation procedure does therefore not improve the solution.
5.14 Improved Initial Solutions
The quality of the initial solution was increased by generation twice as manyrandom chromosomes as required for the population size (popsize). The besthalf of the generated initial solution chromosomes were then chosen as theinitial population.
The better initial solutions did not improve GA quality, but did causethe GA to converge one generation earlier. The best result found was:
• Fitness: 1130.2
• Number of routes: 12
A worse answer is generated because the initial population’s diversity wasdecreased by choosing better initial chromosomes.
One may conclude that GAs are not dependent on the quality of theinitial solutions, although it might speed up the convergence of the GA. Thisagrees with similar conclusions made by Skrlec et al. (1997) and Tan et al.(2001a).
Algorithm Development Reflection 84
5.15 MX Crossover (based on angles)
After all the previous alternatives were evaluated, it was clear that somethingwas still fundamentally wrong with the above mentioned arguments. To findthis flaw, one has to stand back and consider the objective of the algorithm.
The objective of the VRPMC that needs to be solved is to minimise thetotal distance travelled. All the previous alternatives were focused heavilyon optimally addressing time windows. Although most of these argumentsdo contribute to a good solution, one has to consider the minimisation ofthe total distance travelled. Because distance is measured, the GA must befocused mainly on minimising distance and not optimally addressing timewindows.
The most powerful operator that the GA uses is most probably crossover.The crossover operator therefore need to be focused on minimising traveldistance. The current crossover used (MX) is based on time window closingtimes (Li), defeating the purpose of the VRPMC. To ensure that the crossoverminimise distance, the MX needed to be modified.
The new modification suggested for MX requires that its precedence vec-tor be based on angles. This will ensure that customers located close toeach other are incorporated into the same route and in so doing minimisingtotal distance travelled. The angles of all customers around the depot fromthe 0o angle are determined (similar to the steps followed in a sweeping arcalgorihtm). The precedence vector is created by sorting customers from thesmallest to the largest angle. The crossover will now ensure that customerslocated close together will most probably be included in the same route,consequently minimising total distance travelled.
The algorithm with the MX based on angles produced the following re-sults (still using the fast clustering):
• Fitness: 2514.4
• Number of routes: 17
This is a poor result, but this is due to the fact that time windows are nownot properly addressed. To address this problem, the algorithm is adapted touse the original clustering (used before the fast clustering was incorporated;slow clustering). The slow clustering attempts to route the current customerin all positions in the route, not only the last position (as done by fastclustering). This clustering does more effort to optimally position customersin routes considering both distance travelled and time windows.
With the slow clustering, the GA using an angle based MX found thefollowing solution:
Algorithm Development Reflection 85
• Fitness: 883.2
• Number of routes: 10
The proposed angle based MX produces the best results found so far andits results are within 7% of the best published C101 results.
The maximum, average and minimum fitness over the various generationsas well as the assigned routes are illustrated in Figure 5.6.
Figure 5.6: GA with MX Based on Angles
The discussion and logic presented at the beginning of this section ishereby proved to be true as one observes an enormous increase in fitness.
5.16 MX Crossover (based on angles and Li)
For this variation, half the crossovers was done with the MX based on anglesand the other half was done with MX based on Li. This was done to asseswhether the extra importance given to time windows (by incorporating theLi based precedence vector) will improve the algorithm’s performance. Thecombined crossover was coded into the GA and lead to the final solutionlisted below:
Algorithm Development Reflection 86
• Fitness: 1259.9
• Number of routes: 12
The extra emphasis on time windows once again worsened the solutionback to above 1000. The pure MX based on angles is consequently the bestcrossover for this GA that addresses the VRPMC.
5.17 Development Conclusion
It was important to keep the objective (what gets measured) in mind dur-ing the development of the algorithm. Much time and energy could havebeen saved if this principle was followed from the start. However, valuableknowledge regarding GAs and their complex inner workings was gained.
The knowledge and experience gained by evaluating each alternative, pro-vided a base for further improvements and an understanding of issues stillpresent in the algorithm at that time.
To conclude this chapter, the final GA that produced the best solution isdescribed by the following points:
• MX based on angles
• Slow clustering (attempts to insert customers in all positions in route,starting from the back; stops at the first feasible position for the cus-tomer)
• Non-uniform mutation rate
• No local optimisation at end of algorithm
• No time window compatibility
• Biased roulette wheel selection
• Diversification (included as it might help in other problem instances)
• Random initial solutions
The alternatives that were selected for optimal GA performance is hardcoded into the developed program. Various GA variables that will have an in-fluence on the GA’s performance have not yet been discussed. These variablesare the population size, number of generations, number of elites, crossoverprobability and the initial mutation rate. The impact that the combinationof the variables have on the quality of the final solution is analyzed in thenext chapter.
Chapter 6
GA Variable Refinement
This chapter deals with the refinement of the GA’s variables to ensure thatthe combination of the variables will enable the algorithm to produce thebest results that it is capable of producing.
The following GA settings play an important role in the workings of theGA and ultimately in the quality of the final solution:
• Population size
• Number of generations
• Number of elites
• Crossover probability
• Initial mutation rate
The variables listed above can be divided into three groups:
1. Convergence Speed
• Population size
• Number of generations
2. Number of Elites
• Number of elites
3. GA Operator Values
• Crossover probability
• Initial mutation rate
87
GA Variable Refinement 88
These groups are justified and discussed in the next three sections.The GA developed in the previous section will be used in this chapter.
The GA which was used for testing therefore uses a MX based on anglesand the slow clustering procedure. The Solomon C101 benchmark problemwas once again used throughout this chapter so that the performances of thealgorithm variations can be compared to each other.
6.1 Convergence Speed
The algorithm’s convergence speed is mainly influenced by population sizeand the number of generations used.
The GA was tested with various different population sizes. The genera-tion number in which the final answer (the answer to which the GA converge)was reached and the time that was required up to that generation was de-termined. The optimal values for population size and number of generationswas then determined; these optimal values will ensure that the best solutionsare found in the smallest possible execution time.
The values found during this process is shown in Table 6.1. The Gen-eration is the maximum number of generations ever required by the GA toconvergence to an optimal solution. The Time column shows the runningtime of the GA until convergence.
Table 6.1: Impact of Population Size and Number of Generations
Population Size Generation Time (min) Fitness50 11 7.68 1303.0100 11 14.86 883.2150 9 18.08 883.2200 8 21.57 883.2
From this table it can be seen that a population size of at least 100 isrequired to find the best solution. To minimise execution time, a populationsize of 100 should be used.
The number of generations that is suggested for a population size of 100 is15. Although the maximum number of generations required was only 11, thevalue of 15 is suggested as it includes a “margin of safety” of 4 generations.This “margin of safety” will ensure that the GA will always converge to anoptimal solution, given that the MX (based on angles) and slow clusteringare used.
GA Variable Refinement 89
The type of problem solved by the GA, in terms of customer locationsand time window widths, have been found to have only a minor impact onthe algorithm’s convergence speed.
6.2 Number of Elites
Having a set population size of 100 and using 15 generations, the GA was runusing various different number of elites per generation. Both the fitness andexecution time will be used as evaluation criteria to determine the numberof elites required for optimal GA performance.
Table 6.2 summarises the results of the trial runs.
Table 6.2: Influence of the Number of Elites
Number of Elites Fitness Execution Time (min)1 919.3 20.662 919.3 20.493 919.3 20.524 913.0 20.495 883.2 20.236 883.2 20.477 883.2 20.478 919.3 20.509 952.2 20.4310 892.4 20.53
From 1 to 5 elites the fitness found seem to be decreasing, whilst execu-tion time also decreases. From 7 to 10 elites the fitness once again increasetogether with a slight increase in execution time. The GA is therefore ex-pected to produce the best results with between 5 and 7 elites. As 5 elitesrequires the shortest execution time, it is suggested that 5 elites should beused to ensure optimal GA performance with the smallest possible executiontime.
6.3 GA Operator Values
Both the crossover probability (pc) and the initial mutation rate (pm) influ-ence the quality of the solution that the GA will produce. Various previous
GA Variable Refinement 90
runs have indicated that the combination of the two variables, not each ofthem separately, influences the final solution quality.
This relationship between the fitness of the solution produced and thecombination of the two values are shown in Figure 6.1. The average fitnessof the runs made with different pc and pm values are shown.
Figure 6.1: Effect of pc and pm on Fitness
The plot was smoothed (outliers were removed) to make the graph morerepresentative of normal GA behavior. Albright, Winston & Zappe (2002:570-571) warns that removing outliers it is not always appropriate. They suggestthat one should perform the relevant analysis with and without the outliersand then compare the results. The graphs with and without outliers showsthe same global minimum. Since the outliers do not influence the results, theoutliers are removed to smooth out the graph and to consequently increaseits readability.
GA Variable Refinement 91
The 3D plot indicates that the global minimum in terms of fitness (forvarious pc and pm values) exists in the area of 0.75 ≤ pc ≤ 0.85 and 0.05 ≤pm ≤ 0.15. On closer investigation of the graph one can see that the globalminimum fitness value will most probably be found at the following values:
• pc = 0.8
• pm = 0.1
The pc and pm is in the same range as the values that are suggested inGA literature. Zhu (2003) suggest exactly the same values for pc and pm,whilst Tan et al. (2001b) suggests very similar values.
6.4 Best GA Variation and Settings
From all the alternatives that were evaluated in the previous two chapters, thehard coded variations of GA with the final refined variables are summarisedin Table 6.3.
Table 6.3: Optimal GA Variations and Settings
Feature Chosen SettingChromosome coding Path representationPopulation size popsize = 100Number of generations 15Clustering Slow (all route positions)Initialisation RandomlySelection Biased roulette wheelCrossover MX based on anglesMutation Non-uniform heuristicpc 0.8pm 0.1Number of elites 5 (or 5%)Diversification Mutation basedLocal optimisation NoneTime window compatibility None
After the literature study, certain GA variations and settings were sug-gested in Table 3.8. The consistency between Table 3.8 and 6.3 indicates
GA Variable Refinement 92
that the literature study outcomes were quite correct and that the devel-oped algorithm is mostly in line with that which have been suggested in GAliterature.
Since the entire GA has now been developed, it is necessary to providean interface so that the user can solve VRP variations after specifying GAsettings. This user interface is discussed in the following chapter.
Chapter 7
Graphical User Interface
This chapter acts as a very short user’s guide for the coded program. Theprogram has a built-in Graphical User Interface (GUI) from which one caneasily change GA settings, choose input files and execute the GA.
7.1 GA Code Provided
7.1.1 Complete GA for the VRPMC
The algorithm developed so far (and which is shown in Appendic E) is capableof solving VRPs with multiple soft time windows, a heterogeneous fleet (witheach vehicle having a different capacity and average travelling speed) anddouble scheduling. The program and GUI for this GA is included on theaccompanying CD in the MATLAB Code - Complete GA for the VRPMCfolder.
The code provided in this folder should be used to solve VRPMCs.
7.1.2 Fast GA for the VRPTW
The algorithm mentioned in the previous section was scaled down to onlyconsider a single time window, a homogeneous fleet and no double scheduling.This does not affect the performance of the GA in any way, but does decreaseexecution speed when problems with only one hard time window (for examplethe Solomon problems) are solved.
The program and GUI for this “fast” GA is included on the accompanyingCD in the MATLAB Code - Fast GA for the VRPTW folder. The “fast” GArequires only about 50% of the computational time required by the completeGA (see section 7.4).
93
Graphical User Interface 94
The code in the above mentioned folder should thus be used when VRPTWs(i.e. VRPs with one hard time window) are being solved.
The GA code relevant to the user’s needs (i.e. the contents of one of thetwo folders) should be copied into a folder on the user’s computer hard drive.The customer and fleet data spreadsheet files should also be included in thisfolder. The GA will automatically save the results of all runs in this folder.
7.2 Opening the GUI
After copying the relevant code, the first step is to open the MATLAB pro-gram. Once in MATLAB, the Current Directory has to be changed to thefolder in which the GA code has been copied to. The customer and fleet datainput files must also be present in this directory.
To start the program, one types GAVRPMC in MATLAB’s CommandWindow. The GUI screen will now appear.
7.3 Operating the GUI
The GUI screen that will appear is shown in Figure 7.1.
Figure 7.1: GUI Screen Shot
Graphical User Interface 95
The customer and fleet filenames have to be typed in including theirxls extension. The other GA settings has, by default, been set to optimalvalues. To select a GA with the optimal settings as found earlier, the onlyother adjustment that need to be made is to change the type of crossover toMerge Crossover (MX) - Based on angle.
To start the algorithm with the selected settings, the Solve VRPMC withGA button is pressed. During the algorithm’s execution, the best fitnessvalues and routes found so far is dynamically plot on the screen.
When the algorithm has finished, the final solution as well as best routes isplot on the screen. The detailed solution is shown in the Command Window.Two output graphs are generated automatically after each run. The firstgraph is similar to the plot of fitness and routes generated dynamically foreach generation during the algorithm’s execution. A typical example of thisoutput graph is illustrated in Figure 7.2.
Figure 7.2: GUI First Output Graph
The second output graph, shown in Figure 7.3, illustrates the numberof crossovers done per generation, the number of chromosomes that weremutated per generation and the number of duplicate chromosomes per gen-eration.
Graphical User Interface 96
Figure 7.3: GUI Second Output Graph
A RunData folder will be created in the current directory when the al-gorithm has finished. Within this folder a folder with the same name as theExcel customer input file is created. The unusual numbering of the folders inthis folder ensure that no folder will be over written when another problemwith the same Excel file name is solved at a later stage. The newest folder inthe RunData folder includes the final two graphs as well as the variables.matfile which includes all the variables used by the algorithm. These variablescan be loaded into MATLAB by double clicking on the variables.mat file.The variables are now available to the user and he/she may view, edit and/ordelete these variables.
The GUI can be used to determine the optimal settings for very specificproblems, especially if the customer’s delivery environment is very unique.The following alternatives should then be evaluated:
• MX based on angles and slow clustering vs. MX based on Li and fastclustering.
• Other crossovers in conjunction with different types of clustering.
• Different population sizes (and consequently different numbers of gen-erations).
• Different number of elites.
Graphical User Interface 97
• Various different combinations of pm and pc.
7.4 Execution Speeds
The average time (in seconds) taken by the GA (with a population of 100and 15 generations) to solve typical problems with 100 customers is shownin Table 7.1.
Table 7.1: GA Execution Speeds
GA Variation Time (sec)Fast GA: MX (angle) and slow clustering 1223Fast GA: MX(Li) and fast clustering 465Complete GA: MX (angle) and slow clustering 2430Complete GA: MX(Li) and fast clustering 739
The GUI will enable the user to easily operate the GA. Using the de-veloped GA and the GUI, the following chapter provides an analysis of theGA’s performance.
Chapter 8
Benchmarking
This chapter presents the comprehensive benchmarking that has been doneon the final GA. The final variations and variables shown in Table 6.3 wasused for benchmarking purposes.
8.1 Solomon Problem Instances
The Solomon problem instances provides a comprehensive set of benchmark-ing problems to evaluate the performance of algorithms that solve the VRPwith a single hard time window. Although the developed algorithm is ca-pable of addressing much more complex problems (i.e. the VRPMC), theSolomon problems are used for benchmarking due to their popularity. Thebenchmarking in this section serves merely as a stepping stone toward the“real” benchmarking done in the next section, which makes use of complexVRPMC problems (for which the algorithm was designed).
The Solomon problem set, which consists of 56 problems, addresses thefollowing variations in customer locations:
• Clustered customers locations (C)
• Randomly located customers (R)
• Clustered and random locations (RC)
The problem set is further divided into two types:
• Narrow time windows and small vehicle capacities (1)
• Wide time windows and large vehicle capacities (2)
98
Benchmarking 99
The various customer locations and time window groups form six groupsof problems. These are C1, C2, R1, R2, RC1 and RC2. The Solomon probleminstances are described in more detail in Appendix A.
Each of the 56 problems were solved with the GA. The results for eachproblem can be seen in Appendix F. A verification process showed thatthe proposed solutions all adhere to vehicle capacity and time window con-straints. The average results for each group, e.g. C2 or RC1, are calculatedand then compared to the best published averages. Table 8.1 shows thiscomparison.
Table 8.1: Best Found Solomon Benchmarking Group Average Results
Found Best PublishedProblem Class Vehicles Fitness Vehicles Fitness DifferenceC1 10.22 1190.26 6.00 827.54 +43.58%C2 3.63 1318.54 3.00 589.40 +67.39%R1 13.67 1567.85 - 1174.70 +35.19%R2 3.36 1587.00 5.00 929.60 +76.28%RC1 13.88 1863.72 12.33 1269.48 +40.19%RC2 4.13 1940.85 5.80 1080.10 +86.32%
The results can also be shown visually to assist with the performanceevaluation. Figure 8.1 shows the average Solomon group values.
The results shown above as well as Appendix F was used to analyze theperformance of the GA. The average values show that the GA produces muchbetter results for the type 1 class of problems (problems with narrow timewindows and small vehicle capacities). This indicates that the GA is betterequipped to solve highly constrained problems; since narrow time windowsand small vehicle capacities is much more limiting than wide time windowsand large vehicle capacities. Solomon (2004) states that type 2 problemshave “time windows which are hardly constraining”, this also indicates thatthe GA is better at solving tightly packed time window problems.
For problems with narrow time windows, the GA seems to solve prob-lems with randomly located customers better than other problems, whilstclustered customers are solved nearly as well as random customers. The gapbetween random and clustered customer location problems are, however, notnearly as big as is suggested in GA literature (Thangiah et al., 1991).
For problems with wide time windows, clustered customer problems aresolved more efficiently than problems with randomly scattered customers.
Benchmarking 100
Figure 8.1: Solomon Benchmarking Groups
The problems with both randomly located and clustered customers arenot addressed as successfully as the other problems.
Although the averages paint a grim picture, the algorithm is aimed atsolving much more complex problems. Appendix F shows that for some ofthe problems the GA came extremely close to the best published results. Forexample, some problems were solved to within 8% of best published results:
• C101 +6.43%
• C105 +7.84%
• R106 +1.21%
Some of the individual problem instances for which better solutions werefound is illustrated in Figure 8.2.
Although solutions less than 8% more than the best fitness published havebeen found, the average values indicate that various Solomon problems arepoorly solved. An explanation for this is that the GA is aimed at the VRPMCand not just the simple VRP with one hard time window. The GA was thusdeveloped to address highly constrained problems, not the easier VRPs withone hard time window. This is proved by the fact that the GA finds bettersolutions for problems with narrow time windows, as these problems are themore constrained and consequenlty more complex than other problems.
Benchmarking 101
Figure 8.2: Select Solomon Benchmarking Instances
The essence of the developed GA is not tested by the fairly simple Solomonproblem instances. To test the GA one requires problems with a heteroge-neous fleet, double scheduling as well as multiple soft time windows.
8.2 Developing New Benchmarking Problems
To evaluate the performance of the GA when solving the VRPMC, some ofthe Solomon problem instances were adapted to include multiple soft timewindows, a heterogeneous fleet (with varying capacities and travel speeds) aswell as double scheduling. One problem out of each of the six Solomon prob-lem groups were extended to address these constraints (i.e. were extended toa VRPMC). The developed problems operates under the same conditions asthe Solomon problems (except for the additional constraints). The averagevehicle speeds for all vehicles are shown in the delivery fleet input data file.
The VRPMC is much more complex than the VRPTW (VRP with onehard time window). The developed VRPMC problems will therefore test theuniqueness of this algorithm to address all three additional constraints.
The developed benchmarking data is included on the accompanying CD.It should be noted that benchmarking data had to be developed as no
benchmarking problems that address all three constraints could be found invehicle routing literature. No comparison to other algorithms could thus bemade, but the developed benchmarking problems will allow other algorithmsthat might be developed in future to be compared to the this project’s results.
Benchmarking 102
Table 8.2 shows the results found by the GA when evaluating the createdproblem instances. Note that a lateness penalty of 1 for each time unitfor delivery after li is applied. A graphical representation of the VRPMCsolutions is shown in Figure 8.3.
Table 8.2: VRPMC Benchmarking Problem Results
Problem Vehicles FitnessC1 12 1614.94C2 6 1498.84R1 13 1605.28R2 4 1792.15RC1 14 2359.82RC2 5 2296.01
Figure 8.3: Generated Benchmarking Problem Solutions
The results shown in Table 8.2 and Figure 8.3 indicate that randomlyscattered (R) and clustered customers (C) seem to be addressed much betterthan the RC group.
When compared to the relationships of the average Solomon problemgroup data, it is expected that the R2 fitness value should be less than theR1 fitness value. However, the GA is equipped very well to handle the tightly
Benchmarking 103
constrained type 1 problem and actually finds a fitness value for R1 which isless than R2’s fitness.
An analysis and verification of the answers to the VRPMC benchmark-ing problems indicate that the final solutions all adhere to all three of theadditional constraints.
It is interesting to note the GA does not use double scheduling routes forthe developed benchmarking problems. In these problems the GA packs thefirst routes of the vehicles so tightly that no vehicles ever have enough timeto set out on a second (or more) route(s).
Now that the GA has been conceptually designed, coded into a user-friendly program and benchmarked some concluding thoughts are in order.
Chapter 9
Conclusion and Review
This chapter concludes this document by providing an overview of the project,reviewing the algorithm’s results and making suggestions for further research.
9.1 Conclusions
As per the project’s problem statement, a Genetic Algorithm metaheuristicwas developed and coded to solve VRPs with multiple soft time windows, aheterogeneous fleet and double scheduling. The project therefore addressesthe problem that it set out to solve.
The development, and especially the coding of the GA lead to some im-portant discoveries.
First of all, regarding GA theory, it was found that the MX operatoroutperforms all other crossover operators. An angle based (instead of timewindow based) precedence vector is suggested when GAs are used to solveall VRP variations as the angle based MX produced the best results foundin this project.
The coded algorithm indicates that for narrow time windows, GAs solveproblems with randomly scattered customers better than clustered customers.The algorithm also indicate that GAs are better at solving clustered cus-tomers than randomly scattered customers when problems with wide timewindows are addressed.
The author agrees with the similar conclusions drawn by Skrlec (1997),Tan et al. (2001a, 2001b) and Baker & Ayechew (2003) that the quality ofinitial solutions does not affect the quality of the final solution found by GAs.It is, however, suggested that improved initial solutions might ensure slightearlier convergence of some GAs.
When using the “route first, cluster second” approach it was found that
104
Conclusion and Review 105
the clustering algorithm used in conjunction with the GA should includeas little as possible intelligence. This implies that the clustering algorithmshould not do any comparative assessments to determine the best positionof a customer in the applicable route. Comparative assessments will movecustomers to different positions in the route and will in so doing deceive theGA, preventing it from learning where the best position for a customer inthe chromosome is.
The clustering algorithm, even though it does include much intelligence,proved to be (by far) the most time consuming activity performed by theGA
Local optimisation procedures at the end of the GA proved unsuccessfulas it was unable to improve the final solution generated by the GA withinpractical time limits. The local optimisation procedures evaluated used theGA’s clustering algorithm (which includes no intelligence) and this is believedto be the reason why the local improvement heuristics tested did not improvesolution quality.
The GA in conjunction with its GUI provides a vehicle routing andscheduling tool which can be used to add value in most organisations whoare concerned with deliveries or pick ups.
This project can be seen as proof that GAs can be used to solve NP -hardoptimisation problems which are even more complex than the VRPTW. Thedeveloped GA produced fair results when facing extremely complex optimi-sation problems.
9.2 Further Research
To try and improve GA’s performance, various GA variables and alternativeoperators should be tested for all six the developed benchmarking problems.It might then be seen that certain settings proves to work better for certainproblem instances. Even though major improvements are not expected, theanalysis will form a basis from which one can argue that GA settings seemto be independent of the specific problem instance being solved.
A local optimisation heuristic may be developed to try and optimise thefinal solutions generated by metaheuristics. The local optimisation heuris-tic will, however, require an intelligent clustering algorithm, and will mostprobably improve the solutions found by the developed GA.
To speed up the developed GA it is suggested that the MATLAB code bevectorised as much as possible. This approach will speed up the algorithm asMATLAB has much quicker ways of dealing with vectors and matrices thanit has to deal with traditional programming loops.
Conclusion and Review 106
It might be possible to determine why GAs seem to be consistently betterat solving VRPs with randomly scattered customers. When this has beendetermined, the GA should be investigated to see how it would be possiblefor the GA to address clustered customers with the same efficiency.
To establish the developed benchmarking problems, it is suggested thatthe Tabu Search (TS) metaheuristic developed by Salmon (2003) as well as aSimulated Annealing (SA) metaheuristic be coded. These coded metaheuris-tics should be benchmarked against the developed GA using the suggestedVRP with multiple soft time windows, a heterogeneous fleet and doublescheduling benchmarking problems. The benchmarking results of the GA,TS and SA metaheuristics can then be compared and published to establishthe benchmarking problems in the VRP research field.
Another challenge that can add value to the routing environment is tointegrate a GA, TS and SA into a single framework. The framework shoulddetermine which kind of problem is most suited to which metaheuristic andthen use that metaheuristic to solve the problem.
References
ALBRIGHT, S.C., WINSTON, W.L. & ZAPPE, C.J. 2002. Data analysis &decision making with Microsoft Excel. California: Duxbury.
BAKER, B.M. & AYECHEW, M.A. 2003. A genetic algorithm for the vehiclerouting problem. Computers & Operations Research, vol.30, p.787-800.
BERGER, J. & BARKAOUI, M. 2004. A parallel hybrid genetic algorithmfor the vehicle routing problem with time windows. Computers & OperationsResearch, Article in press.
BLANCHARD, B.S. 2004. Logistics engineering and management, sixth edi-tion. New Jersey: Prentice Hall.
BRAYSY, O. 2001. Genetic algorithms for the vehicle routing problem withtime windows. Arpakannus, January 2001, special issue on Bioinformaticsand Genetic Algorithms, p.33-38.
CHEN, X., WAN, W. & XU, X. 1998. Modeling rolling batch planningas vehicle routing problem with time windows. Computers & OperationsResearch, vol.25, no.12, p.1127-1136.
CHOI, I.C., KIM, S.I. & KIM, H.S. 2003. A genetic algorithm with a mixedregion search for the asymmetric traveling salesman problem. Computer &Operations Research, vol.30, p.773-786.
Computer Information Literacy. 2001. Damelin Computer School, ComputerInformation Literature (CIL110) textbook. Pretoria: University of Pretoria.
FILIPEC, M., SKRLEC, D. & KRAJCAR, S. 1997. Darwin meets comput-ers: new approach to multiple depot capacitated vehicle routing problem.IEEE International Conference on Systems, Man, and Cybernetics. Proceed-ings, 12-15 October 1997, p.421-426.
107
References 108
FILIPEC, M., SKRLEC, D. & KRAJCAR, S. 1998. An efficient implemen-tation of genetic algorithms for constrained vehicle routing problem. IEEEInternational Conference on Systems, Man, and Cybernetics Proceedings, 11-14 October 1998, vol.3, p.2231 - 2236.
FOLDOC. In Free On-Line Dictionary Of Computing. http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi? (11 May 2004).
GAMBARDELLA, L.C. Vehicle routing problems. Metaheuristics Network,Technische Universiteit Eindhoven. Short course, 28-29 November 2000.
GARRISON, R.H. & NOREEN, E.W. 2003.Managerial accounting, tenthedition. NY: McGraw-Hill.
GOLDBERG, D.E. 1989. Genetic algorithms in search, optimization andmachine learning. USA: Addison-Wesley.
HWANG, H.S. 2002. An improved model for vehicle routing problem withtime constraints based on genetic algorithm. Computers & Industrial Engi-neering, vol.42, p.361-369.
JASZKIEWICZ, A. & KOMINEK, P. 2003. Genetic local search with dis-tance preserving recombination operator for a vehicle routing problem. Eu-ropean Journal of Operational Research, vol.151, p.352-364.
JIH, W.R. & HSU, J.Y.J. 1999. Dynamic vehicle routing using hybrid ge-netic algorithms. IEEE International Conference on Robotics & Automation.Proceedings, Detroit, May 1999, p.453-458.
JOUBERT, J.W. 2003. An initial solution heuristic for the vehicle rout-ing and scheduling problem. Masters thesis. Faculty of Engineering, BuiltEnvironment and Information Technology, University of Pretoria.
KARANTA, I., MIKKOLA, T., BOUNSAYTHIP, C., JOKINEN, O. & SAVOLA,J. 1999. Genetic algorithms applied to a wood collection problem. IEEE In-ternational Conference on Systems, Man and Cybernetics. Proceedings, 12-15October 1999, vol.4, p.635-639.
Learning MATLAB 6.5. 2002. Manual accompanying MATLAB StudentVersion Release 13, MathWorks.
Learning SIMULINK 5. 2002. Manual accompanying MATLAB StudentVersion Release 13, MathWorks.
References 109
LOUIS, S.J., YIN, X. & YUAN, Z.Y. 1999. Multiple vehicle routing withtime windows using genetic algorithms. Congress on Evolutionary Compu-tation. Proceedings, 6-9 July 1999, vol.3, p.1804-1808.
MAEDA, O. NAKAMURA, M. OMBUKI, B.M. & ONAGA, K. 1999. Agenetic algorithm approach to vehicle routing problem with time deadlinesin geographical information systems. IEEE International Conference on Sys-tems, Man and Cybernetics. Proceedings, 12-15 October 1999, vol.4, p.595-600.
MALMBORG, C.J. 1996. A genetic algorithm for service level based vehiclescheduling. European Journal of Operational Research, vol.93, p.121-134.
MICHALEWICZ, A. 1992. Genetic algorithms + data structures = evolutionprograms. New York: Springer-Verlag.
NYGARD, K.E., KADABA, N. 1991. Algorithm management using geneticsearch for computer-aided vehicle routing. Hawaii International Conferenceon System Sciences, 24th. Proceedings, 8-11 January 1991, vol.3, p.317-399.
OCHI, L.S., VIANNA, D.S., DRUMMOND, L.M.A. & VICTOR, A.O. 1998.A parallel evolutionary algorithm for the vehicle routing problem with het-erogeneous fleet. Future Generation Computer Systems, vol.14, p.285-292.
PELLAZAR, M.B. 1994. Vehicle route planning with constraints using ge-netic algorithms. IEEE National Aerospace and Electronics Conference. Pro-ceedings, 13-17 July 1998, p.392-399.
POTTER, T. & BOSSOMAIER, T. 1995. Solving vehicle routing problemswith genetic algorithms. IEEE International Conference on EvolutionaryComputation. Proceedings, 29 November-1 December 1995, vol.2, p.788-793.
POTGIETER, E. 1997. A genetic algorithm for the discrete structural op-timization of laminated plates. Faculty of Engineering, Built Environmentand Information Technology, University of Pretoria.
PRINS, C. 2004. A simple and effective evolutionary algorithm for the vehiclerouting problem. Computers & Operations Research, Article in press.
RARDIN, R.L. 1998. Optimization in Operations Research. New Jersey:Prentice Hall.
References 110
SALMON, M. 2003. Development of a meta-heuristic for the vehicle routingproblem with various side constraints. Faculty of Engineering, Built Envi-ronment and Information Technology, University of Pretoria.
SKRLEC, D., FILIPEC, M. & KRAJCAR, S. 1997. A heuristic modifica-tion of genetic algorithm used for solving the single depot capacitated vehiclerouting problem. Intelligent Information Systems. Proceedings, 8-10 Decem-ber 1997, p.184-188.
SOLOMON, M. 1987. Algorithms for the vehicle routing and schedulingproblem with time windows. Operations Research, vol.35, p.254-365.
SOLOMON, M. VRPTW Benchmarking Problems. http://web.cba.neu.edu/msolomon/problems.htm (28 April 2004).
TAN, K.C., LEE, L.H., ZHU, Q.L. & OU, K. 2001a. Heuristic methodsfor vehicle routing problems with time windows. Artificial Intelligence inEngineering, January 2001, vol.15, p.281-295.
TAN, K.C., LEE, L.H. & OU, K. 2001b. Artificial intelligence heuristics insolving vehicle routing problems with time window constraints. EngineeringApplications of Artificial Intelligence, February 2001, vol.14, p.825-837.
TAN, K.C., LEE, T.H., OU, K. & LEE, L.H. 2001c. A messy geneticalgorithm for the vehicle routing problem with time window constraints.Congress on Evolutionary Computation. Proceedings, 27-30 May 2001, vol.1,p.679-686.
THANGIAH, S.R., GUBBI, A.V. 1993. Effect of genetic sectoring on vehiclerouting problems with time windows. IEEE International Conference onDeveloping and Managing Intelligent System Projects. Proceedings, 29-31March 1993, p.146-153.
THANGIAH, S.R., NYGARD K.E., & JUELL, P.L. 1991. GIDEON: Agenetic algorithm system for vehicle routing with time windows. IEEE Con-ference on Artificial Intelligence for Applications, 7th. Proceedings, 24-28February 1991, vol.1, p.332-328.
UCHIMURA, K., SAKAGUCHI, H. & NAKASHIMA, T. 1994. Genetic Al-gorithms for vehicle routing problem in delivery system. Vehicle Navigation& Information Systems Conference. Proceedings, p.287-290.
References 111
VAN BREEDAM, A. 2001. Comparing descent heuristics and metaheuristicsfor the vehicle routing problem. Computers & Operations Research, vol. 28,no.4, p.289-315.
VAN SCHALKWYK, W.T. 2002. An algorithm for the vehicle routing prob-lem with various side constraints. Faculty of Engineering, Built Environmentand Information Technology, University of Pretoria.
VAS, P. 1999. Artificial-intelligence-based electrical machines and drives.New York: Oxford University Press.
WINSTON, W.L. 1994. Operations research: Applications and algorithms,third edition. California: Duxbury.
WINSTON, W.L. & VENKATARAMANAN, M. 2003. Operations research:Volume one, Introduction to mathematical programming, fourth edition. Cal-ifornia: Duxbury.
ZHU, K.Q. 2003. A diversity-controlling adaptive genetic algorithm for thevehicle routing problem with time windows. IEEE International Conferenceon Tools with Artificial Intelligence, 15th. Proceedings, 3-5 November 2003,p.176-183.
Appendix A
Benchmarking Problems
The 56 Solomon (1987) problems are used to analyse and compare the qual-ity and performance of various algorithms for the VRPTW. Various otherbenchmarking problems are available for basic VRPs, but they are not dis-cussed as this project includes time windows into its VRPs.
The Solomon (1987) problems are divided into six groups: C1, C2, R1,R2, RC1 and RC2. Type C has clustered customers, type R has randomlylocated customers and type RC have a combination of the two (Solomon,1987; Gambardella, 2000). Type 1 problems have narrow time windows andsmall vehicle capacities (i.e. a large number of vehicles and routes) whilsttype 2 problems have large time windows with large vehicle capacities (i.e.few vehicles and routes).
Solomon (2004) provides the enormous amount of information required forthe 56 problems. Each of the 56 problems has a 100 customers. For each ofthese customers, the customer number, x coordinate, y coordinate, demand,ready time (start of time window), due date (end of time window) and servicetime is given. The information is not given in this text as it would take up toomuch space (approximately 114 pages), but is included on the accompanyingCD.
The information is also readily available from M. Solomon’s website (Solomon,2004). The best know solutions for these problems found in routing literatureare shown in Appendix B.
Other benchmarking problems that include soft time windows, a hetero-geneous fleet and double scheduling will be developed to evaluate the GA’sperformance.
112
Appendix B
Best Known Solutions
The best know heuristic solutions for the 56 Solomon (1987) problems thathave been found in literature is shown in Tables B.1 through B.6. The groupaverages are shown in Table B.7. As the power and speed of computers haveevolved extremely, computational times are rendered useless as 1991 compu-tational times cannot be compared to 2004 computational times. (Referenceswith a * indicate that these referred articles could not be obtained, but thatother authors published them as best known solutions.)
Table B.1: Best Published Solomon Benchmarking Results - C1
Problem Reference Vehicles Distance
C101 Desrochers et al. (1992)* 10 827.30
C102 Desrochers et al. (1992)* 10 827.30
C103 Rochat & Taillard (1995)* 10 828.06
C104 Rochat & Taillard (1995)* 10 824.78
C105 Tan et al. (2001c) 10 828.94
C106 Desrochers et al. (1992)* 10 827.30
C107 Desrochers et al. (1992)* 10 827.30
C108 Desrochers et al. (1992)* 10 827.30
C109 Potvin & Bengio (1993)* 10 828.94
113
Best Known Solutions 114
Table B.2: Best Published Solomon Benchmarking Results - C2
Problem Reference Vehicles Distance
C201 Tan et al. (2001c) 3 591.56
C202 Tan et al. (2001c) 3 591.56
C203 Rochat & Taillard (1995)* 3 591.17
C204 Potvin & Bengio (1993)* 3 590.60
C205 Potvin & Bengio (1993)* 3 588.88
C206 Potvin & Bengio (1993)* 3 588.49
C207 Rochat & Taillard (1995)* 3 588.29
C208 Rochat & Taillard (1995)* 3 588.32
Table B.3: Best Published Solomon Benchmarking Results - R1
Problem Reference Vehicles Distance
R101 Desrochers et al. (1992)* 18 1607.70
R102 Desrochers et al. (1992)* 17 1434.00
R103 Thangiah et al. (1994)* 13 1207.00
R104 Rochat & Taillard (1995)* 10 982.01
R105 Tan et al. (2001c) 15 1372.71
R106 Rochat & Taillard (1995)* 12 1252.03
R107 Shaw (1997)* 10 1104.66
R108 Berger et al. (2001)* 9 960.88
R109 Chaing & Russel (1997)* 12 1013.16
R110 Rochat & Taillard (1995)* 11 1080.36
R111 Tan et al. (2001c) 12 1083.05
R112 Rochat & Taillard (1995)* 10 953.63
Best Known Solutions 115
Table B.4: Best Published Solomon Benchmarking Results - R2
Problem Reference Vehicles Distance
R201 Tan et al. (2001c) 8 1198.15
R202 Tan et al. (2001c) 9 1057.56
R203 Tan et al. (2001c) 5 922.38
R204 Tan et al. (2001c) 5 791.78
R205 Rousseau et al. (In press) 3 994.42
R206 Thangiah et al. (1994)* 3 833.00
R207 Rochat & Taillard (1995)* 3 814.78
R208 Mester (2002)* 2 726.75
R209 Thangiah et al. (1994)* 3 855.00
R210 Mester (2002)* 3 939.34
R211 Tan et al. (2001c) 6 820.31
Table B.5: Best Published Solomon Benchmarking Results - CR1
Problem Reference Vehicles Distance
RC101 Chaing & Russel (1997)* 15 1642.82
RC102 Tan et al. (2001c) 15 1492.10
RC103 Thangiah et al. (1994)* 11 1110.00
RC104 Cordeau et al. (2000) 10 1135.48
RC105 Tan et al. (2001c) 16 1585.31
RC106 Chaing & Russel (1997)* 12 1395.37
RC107 Shaw (1997)* 11 1230.48
RC108 Taillard & Badeau (1997)* 10 1139.82
Best Known Solutions 116
Table B.6: Best Published Solomon Benchmarking Results - CR2
Problem Reference Vehicles Distance
RC201 Thangiah et al. (1994)* 4 1249.00
RC202 Tan et al. (2001c) 8 1151.46
RC203 Tan et al. (2001c) 7 1018.09
RC204 Mester (2002)* 4 798.41
RC205 Tan et al. (2001c) 9 1225.69
RC206 Tan et al. (2001c) 5 1122.23
RC207 Tan et al. (2001c) 6 1047.86
RC208 Ibaraki et al. (2001)* 3 828.14
Table B.7: Best Published Solomon Benchmarking Group Average Results
Problem Shown In Vehicles Distance
C1 Tan et al. (2001a) 6.00 827.54
C2 Tan et al. (2001a) 3.00 589.40
R1 Tan et al. (2001b) - 1174.70
R2 Tan et al. (2001c) 5.00 929.60
RC1 Berger & Barkoui (2004) 12.33 1269.48
RC2 Tan et al. (2001c) 5.80 1080.10
Appendix C
Customer Datafile Template
The file may be named anything, but must have and .xls extension. TheMicrosoft Excel file must have the following heading in row A of the spread-sheet:
1. Customer Number
2. X Coordinate
3. Y Coordinate
4. Demand
5. Service Time
6. e1
7. l1
8. L1
9. e2
10. l2
11. L2
12. ...
The e, l and L entries are continued to ensure all the time windows in aspecific problem is included within the file.
117
Appendix D
Vehicle Fleet Datafile Template
D.1 GA for the VRPMC
The file may be named anything, but must have and .xls extension. TheMicrosoft Excel file must have the following heading in row A of the spread-sheet:
1. Vehicle Number
2. Capacity
3. Average Speed
D.2 GA for the VRPTW
The file may be named anything, but must have and .xls extension. TheMicrosoft Excel file must have the following heading in row A of the spread-sheet:
1. Vehicle Number
2. Capacity
The average speed for all the vehicles in the homogeneous fleet present ina VRPTW is then typed in using the GUI used to execute the program.
118
Appendix
E
MA
TLA
BC
ode
This
appen
dix
show
sth
eG
A’s
MA
TLA
Bco
de.
The
GAV
RPM
C.m
file
isth
efile
that
isru
nin
MAT
LA
Ban
dis
the
file
that
gener
ates
the
GU
I.T
he
VR
PM
CG
A.m
file
isca
lled
by
the
GU
Iw
ith
the
appro
priat
eva
riab
les;
this
file
isth
em
ain
pro
gram
.
E.1
GU
IP
rogra
m(G
AV
RPM
C.m
)
Only
the
edit
edpar
tof
this
MAT
LA
Bge
ner
ated
GU
Ifile
issh
own.
%---
Executes
on
button
press
in
button_solve.
function
button_solve_Callback(hObject,
eventdata,
handles)
%hObject
handle
tobutton_solve
(see
GCBO)
%eventdata
reserved
-to
be
defined
in
afuture
version
of
MATLAB
%handles
structurewith
handles
and
user
data
(see
GUIDATA)
119
MATLAB Code 120%user_input
=get(editbox_handle,’String’);
%eval(user_input)
%VRPMCGA
set(GAVRPMC,’HandleVisibility’,’on’);
clc
set(GAVRPMC,’HandleVisibility’,’off’);
close
all
%disp(’test
close
all’);
popsize
=str2double(get(handles.edit_popsize,’String’));
cust
=get(handles.edit_custfile,’String’);
fleet
=get(handles.edit_fleetfile,’String’);
maxnumgen
=str2double(get(handles.edit_numgen,’String’));
pc
=str2double(get(handles.edit_pc,’String’));
pm
=str2double(get(handles.edit_pm,’String’));
xotype
=get(handles.popupmenu_xotype,’Value’);
clusttype
=get(handles.popupmenu_clusttype,’Value’);
numelites
=str2double(get(handles.edit_numelites,’String’));
lpenalty
=str2double(get(handles.edit_lpenalty,’String’));
avespd
=str2double(get(handles.edit_avespd,’String’));
VRPMCGA(popsize,cust,fleet,maxnumgen,pc,pm,xotype,clusttype,numelites,lpenalty,avespd);
%set(GAVRPMC,’HandleVisibility’,’commandline’);
set(GAVRPMC,’HandleVisibility’,’on’);
E.2
Main
Pro
gra
m(V
RPM
CG
A.m
)
function
VRPMCGA(popsize,cust,fleet,maxnumgen,pc,pm,xotype,clusttype,numelites,lpenalty);
%VRPMCGA
This
program
solves
the
VRPMC
by
means
of
aGA.
MATLAB Code 121%#############################
GA
for
the
VRPMC
#############################
%Important
variables
used
in
this
m-file
(global
variables
shown
below):
%popsize
population
size
%gennum
generation
number
%pc
probability
of
crossover
%pm
initialmutation
probability
%numelites
numberof
elites
per
generation
%lpenalty
latnesspenalty
%maxnumgen
maximumnumber
of
generations
%clustmethod
methodof
clusetring
used
%xotype
type
ofcrossover
used
%numxo
numberof
crossovers
%nummut
numberof
mutations
%Clear
the
memory
of
variables
not
required,
close
all
figures,
save
%beginning
time
and
randomize
the
random
number
generation
procedure.
close
all;
%close
all
open
figures
begintyd
=clock;
%save
beginning
time
rand(’state’,sum(100*clock));
%randomise
random
number
generation
%Declares
global
variables
to
be
used
across
all
functions
global
NUMCUST;
%number
of
customers
global
FLEETSIZE;
%fleet
size
global
NUMTW;
%maximum
number
of
time
windows
present
global
POP;
%current
population
data
global
CUSTFILE;
%matrix
with
customer
data
global
FLEETFILE;
%matrix
with
fleet’s
data
MATLAB Code 122global
FIT;
%list
of
fitnesses
over
generations
global
NEWPOP;
%next
population
data
global
BEST;
%best
routes
found
so
far
global
BESTGEN;
%number
of
best
generation
global
STOPASAP;
global
DS;
%Initialises
variablesrequired
DS
=0;
STOPASAP
=0;
clustmethod
=’johanlocal’;
%to
know
which
clustering
was
used
solomon
=cust;
div
=0;
numxo
=0;
%initialise
variables
nummute
=0;
BEST.fitness
=999999999;
%no
fitness
found
so
far
BESTGEN
=0;
FIT
=[];
gennum
=0;
CUSTFILE
=xlsread(cust);
%read
customer
data
FLEETFILE
=xlsread(fleet);
%read
fleet
data
if
isnan(CUSTFILE(1,1))==
1;
%delete
first
row
of
matrix
if
itdoesn’t
contain
numbers
CUSTFILE(1,:)
=[];
%MATLAB
inserts
a"weird"
first
row
if
all
customers
don’t
have
%an
equal
number
of
time
windows
end;
%if
custfile
for
tempx
=1:size(CUSTFILE,1)
for
tempy
=1:size(CUSTFILE,2)
MATLAB Code 123if
isnan(CUSTFILE(tempx,tempy))
CUSTFILE(tempx,tempy)
=9999999;
%if
no
tw
data
is
avaialable
set
ei,
li
and
Li
end;
%equal
to
large
numbers
end;
end;
NUMCUST
=max(CUSTFILE(:,1));
%determine
number
of
customers
(inlcuding
depot)
FLEETSIZE
=max(FLEETFILE(:,1));
%determine
fleet
size
NUMTW
=(size(CUSTFILE,2)-5)/3;
%determine
number
of
timewindows
CUSTFILE(:,1)
=[];
if
xotype
==
2%create
precedence
vectorfor
MX
based
on
L_i
values
temp
=CUSTFILE(:,7);
for
cust
=2:NUMCUST
klein
=min(temp);
place
=find(temp
==
klein);
precedence(cust-1)
=place(1);
temp(place(1))
=99999999;
end;
%for
cust
elseif
xotype
==
3%create
precedence
vectorfor
MX
based
on
e_i
values
temp
=CUSTFILE(:,5);
temp(1)
=99999999;
for
cust
=2:NUMCUST
klein
=min(temp);
place
=find(temp
==
klein);
precedence(cust-1)
=place(1);
temp(place(1))
=99999999;
end;
%for
cust
elseif
xotype
==
4%create
precedence
vectorfor
MX
based
on
angle
values
temp
=CUSTFILE(:,7);
MATLAB Code 124klein=
min(temp);
place
=find(temp
==
klein);
[seedlist]
=seedangles(place);
temp
=seedlist;
for
cust
=2:NUMCUST
klein
=min(temp);
place
=find(temp
==
klein);
precedence(cust-1)
=place(1);
temp(place(1))
=99999999;
end;
%for
cust
elseif
xotype
==
5%create
precedence
vectorfor
MX
based
on
angle
and
Li
values
tempL
=CUSTFILE(:,5);
tempL(1)
=99999999;
temps
=CUSTFILE(:,7);
klein
=min(temps);
place
=find(temps
==
klein);
[seedlist]
=seedangles(place);
temps
=[seedlist]’;
res
=tempL;
res(1)
=[];
tempL
=tempL/(max(res));
res
=temps;
res(1)
=[];
temps
=temps/(max(res));
temp
=tempL
+temps;
for
cust
=2:NUMCUST
klein
=min(temp);
place
=find(temp
==
klein);
precedence(cust-1)
=place(1);
temp(place(1))
=99999999;
MATLAB Code 125end;
%for
cust
elseprecedence
=0;
end;
%if
xotype
for
temp
=1:NUMCUST
for
tel
=1:NUMCUST
dx
=CUSTFILE(temp,1)-
CUSTFILE(tel,1);
%change
in
xdy
=CUSTFILE(temp,2)-
CUSTFILE(tel,2);
%change
in
yafstand(temp,tel)
=sqrt(dx^2
+dy^2);
%distance
calculation
end;
%for
tel
end;
%for
temp
%####################
Step1
-Initial
TSP
solution
generation
####################
%Executes
the
initial
solution
generation
code
[POP]
=initialise(popsize);
%create
random
initial
TSP
solutions
track{1}
=POP;
%save
current
POP
in
atracking
variable
for
later
user
reference
for
gennum
=1:(maxnumgen-1);
%generation
counter
numdupl(gennum)
=0;
done
=[];
if
div
==
0for
temp
=1:popsize
%count
duplicates
for
temp2
=(temp+1):popsize
kry
=find(done
==
temp2);
if
length(kry)
==
0
MATLAB Code 126if
POP(temp).tsp
==
POP(temp2).tsp
numdupl(gennum)
=numdupl(gennum)+1;
done(length(done)+1)
=temp2;
end;
%if
end;
%if
end;
%for
temp2
end;
%for
temp
if
numdupl(gennum)
>=25
%test
whether
diversification
should
be
done
diversify(done,numdupl(gennum));
div
=div+1;
divgen
=gennum;
end;
%if
numdupl
end;
%if
div
%#########################
Step2
-Cluster
TSP
solutions
#########################
%Executes
the
clustering
code
if
clusttype
==
1cluster(popsize,afstand);
%cluster
TSP
solutions
into
routes
elseclusterfast(popsize,afstand);
%cluster
TSP
solutions
into
routes
end;
if
STOPASAP
==
1%if
no
feasible
solution
found
break
end;
%##########################
Step3
-Fitness
calculations
#########################
%Executes
the
feasibility
calculation
code
MATLAB Code 127
[fitdist,fitlate]=
fitcalc(lpenalty,popsize,gennum);
%calculate
chromosome
fitnesses
timeline(gennum,1)
=max([POP.fitness]);
%save
maximum
fitness
ofPOP
timeline(gennum,2)
=mean([POP.fitness]);
%save
average
fitness
ofPOP
timeline(gennum,3)
=min([POP.fitness]);
%save
minimum
fitness
ofPOP
plotgen(timeline,maxnumgen,gennum,solomon,BEST.fitness);
%plot
the
max,
ave
andmine
values
for
all
generations
up
to
date
%#############################
Step4
-Cloning
elites
############################
%Executes
the
feasibility
calculation
code
clone(numelites,popsize);
%cluster
TSP
solutions
into
routes
%################################
Step5
-Crossover
##############################
%Performs
crossover
[numxo(gennum+1)]
=crossover(xotype,pc,popsize,0,precedence);
%crossover
chromosomes
%################################
Step6
-Mutation
##############################
%Performs
mutation
[nummute(gennum+1)]
=mutation(pm,gennum,popsize,0);
%do
mutation
POP
=NEWPOP;
%copy
new
generation
over
old
generation
end;
%for
gennum
if
STOPASAP
==
1%if
nofeasible
solution
found
MATLAB Code 128return
end;
gennum
=gennum
+1;
%last
generation
number
numdupl(gennum)
=0;
done
=[];
if
div
==
0%if
no
diversification
for
temp
=1:popsize
%count
duplicates
for
temp2
=(temp+1):popsize
kry
=find(done
==
temp2);
if
length(kry)
==
0if
POP(temp).tsp
==POP(temp2).tsp
numdupl(gennum)
=numdupl(gennum)+1;
done(length(done)+1)
=temp2;
div=div+1;
divgen=gennum;
end;
%if
end;
%if
end;
%for
temp2
end;
%for
temp
if
numdupl(gennum)
>=
25
%if
needed
do
diversification
diversify(done,numdupl(gennum));
div
=div+1;
divgen
=gennum;
end;
%if
numdupl
end;
%if
div
if
clusttype
==
1cluster(popsize,afstand);
%cluster
TSP
solutions
into
routes
MATLAB Code 129elseclusterfast(popsize,afstand);
%cluster
TSP
solutions
intoroutes
end;
[fitdist,fitlate]
=fitcalc(lpenalty,popsize,gennum);
%calculate
chromosome
fitnesses
timeline(gennum,1)
=max([POP.fitness]);
%save
maximum
fitnessof
POP
timeline(gennum,2)
=mean([POP.fitness]);
%save
average
fitnessof
POP
timeline(gennum,3)
=min([POP.fitness]);
%save
minimum
fitnessof
POP
plotgen(timeline,maxnumgen,gennum,solomon,BEST.fitness);
%plot
the
max,
ave
and
mine
values
for
all
generations
up
to
date
%Show
values
so
that
user
can
see
whether
the
local
optimisation
improved
%the
final
solution
disp([’Final
solution
distance:
’,num2str(BEST.fitness)]);
%show
new
fitness
value
[timesec]
=finalsol(numxo,nummute,begintyd);
%save
algorithm
ending
time
plotgen(timeline,maxnumgen,gennum,solomon,BEST.fitness);
%plot
routes
and
fitnesses
figure(’Tag’,’GA
Values’);
figure(findobj(’Tag’,’GA
Values’));
axis
auto;
%reset
axis
after
plotgen
plot(1:length(timeline),numxo,’mo-’);
%plot
number
of
crossovers
hold
on;
%plot
next
plot
on
same
graph
plot(1:length(timeline),nummute,’b*-’);
%plot
number
of
mutations
hold
on;
%plot
next
plot
on
same
graph
plot(1:length(timeline),numdupl,’g.:’);
%plot
number
of
mutations
title(’Plot
of
Number
of
Crossovers,
Mutations
and
Duplicates’);%graph
title
legend(’Crossovers’,’Mutations’,’Duplicates’);
%legend
xlabel(’Generation’);
%x-axis
label
ylabel(’Number
in
Generation’);
%y-axis
label
axis
equal;
%set
axis
scales
equal
MATLAB Code 130dirname
=[’RunData\pop’,
num2str(popsize),’\run’
,num2str(fix(sum(clock)*10))];
%create
unique
directory
name
mkdir(dirname);
%create
unique
directory
cd(dirname);
%go
to
this
directory
save
variables;
%save
workspace
variables
for
future
user
reference
saveas(1,’graph.fig’);
%save
plot
of
routes
and
fitnesses
saveas(2,’graph2.fig’);
%save
plot
of
routes
and
fitnesses
cd(’..’);
%go
back
to
original
directory
cd(’..’);
cd(’..’);
E.3
Seed
Angle
Calc
ula
tion
(see
dangle
s.m
)
function
[seedlist]
=seedangles(first)
%SEEDANGLES
Determines
the
seed
angles
of
all
customers,
starting
with
%the
customer
who
has
the
earliest
Li
value.
global
NUMCUST;
global
CUSTFILE;
warning
off
MATLAB:divideByZero
xdepot
=CUSTFILE(1,1);%read
depot
xcoordinate
ydepot
=CUSTFILE(1,2);%read
depot
ycoordinate
for
tel
=2:NUMCUST
%for
customer
except
depot
xcust
=CUSTFILE(tel,1);
%read
xcoordinate
ycust
=CUSTFILE(tel,2);
%read
ycoordinate
dx
=abs(xcust
-xdepot);
%change
in
xcoordinates
MATLAB Code 131dy
=abs(ycust
-ydepot);
%change
in
ycoordinates
if
xcust
>=xdepot
%determine
angles
for
various
quadrants
if
ycust
>=
ydepot
seedlist(tel)
=atan(dy/dx);
%kwadrant
1elseif
xcust
==
xdepot
seedlist(tel)
=pi
+atan(dy/dx);
elseseedlist(tel)
=2*pi
-atan(dy/dx);
%kwadrant
4end;
%if
ycust
elseif
ycust
>=
ydepot
seedlist(tel)
=pi
-atan(dy/dx);
%kwadrant
2elseseedlist(tel)
=pi
+atan(dy/dx);
%kwadrant
3end;
%if
ycust
end;
%if
xcust
end;
%for
tel
seedlist(1)
=9999999999;
%depot’s
"angle"
for
tel
=1:NUMCUST
%for
all
customers
seedlist(tel)
=10
+seedlist(tel);
%increase
angle
by
10
end;
%for
tel
warning
on
MATLAB:divideByZero
E.4
Init
ialSolu
tion
Genera
tion
(initia
lise
.m)
function
[initpop]
=initialise(popsize);
MATLAB Code 132%INITIALISE
This
function
generates
initial
TSP
solutions
for
theproblem.
Initial
%solutions
are
not
guaranteed
to
be
feasible,
as
feasibility
is
addressed
in
%the
next
step
(i.e.
clustering).
%This
function’s
localvariables:
%initpop
generated
initial
solution
population
%tel
chromosome
counter
%tel1
customer
counter
%list
row
ofvalues
(i.e.
chromosome)
%list2
row
ofvalues
for
customer
numbers
%tel2
customer
number
counter
%plek
position
of
minimum
value
in
list
%Specifies
which
globalvariables
are
required
in
this
function
global
NUMCUST;
%Try
to
speed
up
initial
solution
generation
%list
=zeros(1,NUMCUST+1);
%runs
faster
without
thesetwo
%list2
=zeros(1,NUMCUST+1);
%Generate
random
TSP
initial
solutions.
Random
numbers
are
assigned
to
%positions.
These
random
numbers
are
then
transformed
into
customer
%numbers.
The
depot
isthen
added
to
the
start
and
finish
of
thetsp
%route,
but
not
to
theunsourted
vector.
for
tel
=1:popsize
%for
all
chromosomes
in
population
for
tel1
=1:(NUMCUST-1)
%for
all
customers
list(tel1)
=rand;
%assign
random
number
to
positiontel1
MATLAB Code 133end;
%for
tel1
for
tel2
=1:(NUMCUST-1)
%for
all
customers
plek
=find(list
==
min(list));
%find
position
of
min
value
list(plek)
=tel2;
%assign
customer
counter
plek2
tothis
position
end;
%for
tel2
list2
=list+1;
%from
customer
2upward
for
tel1
=1:(NUMCUST-1)
list(tel1+1)
=list2(tel1);
%move
values
1position
right
end;
%for
tel1
list(1)
=1;
%include
depot
at
start
list(NUMCUST+1)
=1;
%include
depot
at
end
%list
=[1,list2,1];
%slower
than
the
5lines
above
initpop(tel).tsp
=list;
%write
list
to
population
initpop(tel).unrouted
=list;
%write
unrouted
customers
initpop(tel).unrouted(NUMCUST+1)
=[];
%remove
depot
from
unrouted
initpop(tel).unrouted(1)=
[];
end;
%for
tel
E.5
Div
ers
ifica
tion
(div
ers
ify.m
)
function
diversify(done,dupl);
%DIVERSIFY
Diversify
the
population
by
means
of
amutation
type
operator
global
POP;
global
NUMCUST;
for
tel
=1:fix(0.5*dupl);
%for
all
customers
for
count
=1:5
%5
times
p1
=fix((NUMCUST-1)*rand)+2;
%generate
random
positions
MATLAB Code 134p2
=fix((NUMCUST-1)*rand)+2;
temp
=POP(done(tel)).tsp(p1);
%swap
customers
in
random
positions
POP(done(tel)).tsp(p1)=
POP(done(tel)).tsp(p2);
POP(done(tel)).tsp(p2)=
temp;
end;
%for
count
end;
%for
cust
E.6
Clu
steri
ng
(clu
ster.m
and
clu
sterf
ast
.m)
E.6
.1cl
ust
er.
m
function
cluster(popsize,afstand);
%CLUSTER
This
function
clusters
the
TSP
initial
solutions
(feasible/not)
%into
various
feasible
routes.
%This
function’s
important
local
variables:
%chromno
chromosome
counter
%temp
fleet
data
%temp2
vehiclecounter
%v
currentvehicle
number
%plek
position
of
max
value
%lys
list
ofvehicle
capacities
%done
booleanfor
all
customers
routed
%num
position
of
customer
to
be
routed
in
unsorted
list
%popsize
numberof
chromosomes
per
generation
%Identifies
global
variables
required
by
this
function.
global
NUMCUST;
MATLAB Code 135global
FLEETSIZE;
global
POP;
global
FLEETFILE;
global
CUSTFILE;
global
CLUST;
global
STOPASAP;
%Variable
initialisation.
for
chromno
=1:popsize
%initialise
pathpart
of
POP
structure
for
temp2
=1:FLEETSIZE
POP(chromno).route(temp2).path
=[1
1];
%depot
at
start
and
end
POP(chromno).route(temp2).vehicle
=0;
%no
vehicle
assigned
end;
%for
temp2
end;
%for
temp
%Sorts
the
vehicle
fleet
from
largest
to
smallest
capacity.
Firstthe
%vehicle
capacities
arewrittin
into
lys.
The
FLEETDATA
is
copiedinto
the
%temp
structure.
The
vehicle
with
maximum
capacity
is
then
foundin
the
%list
and
is
then
placed
in
its
new
position
in
FLEETDATA.
%lys
=zeros(1,FLEETSIZE);
%not
required,
only
slows
execution
down
for
v=
1:FLEETSIZE
%create
vector
of
fleet
capacity
lys(v)
=FLEETFILE(v,2);
%list
of
capacities
end;
%for
v
temp
=FLEETFILE;
for
v=
1:FLEETSIZE
%stores
sorted
numbers
instructure
MATLAB Code 136plek
=find(lys
==
max(lys));
%position
of
max
value
lys(plek(1))
=-10;
%will
not
be
max
value
again
FLEETFILE(v,:)
=temp(plek(1),:);
%assign
vehicle
to
new
position
end;
%for
v
%Creates
routes
for
allchromosomes
in
the
population.
When
all
customers
%are
routed
done
equals1.
The
position
of
the
customer
to
be
routed
in
%the
unsorted
list
is
num.
If
the
customer
is
routed,
it
is
removed
from
%the
unsorted
list.
Otherwise
the
customer
in
the
next
position
in
unsorted
%is
routed.
All
customers
are
routed
is
unrouted
is
empty
or
somecould
not
%be
routed.
for
chromno
=1:popsize
%for
all
chromosomes
done
=0;
%all
customers
not
routed
num
=1;
%route
1st
customer
in
unrouted
string
=POP(chromno).unrouted;
%copy
unrouted
path
for
temp
=1:length(string)
%create
list
of
L_i
values
Li(temp)
=CUSTFILE(string(temp),7);
%only
1st
time
window
ofeach
customer
considered
end;
%for
temp
start
=find(Li
==
min(Li));
%find
earliest
L_i
value’s
position
%The
following
if
creates
anew
tsp
which
starts
with
the
earliest
%deadline
customers,
then
all
the
customers
to
its
right
and
then
all
%customers
to
its
left
(in
original
tsp
order)
if
start(1)
>1
%if
earliest
L_i
is
notthe
first
customer
on
the
route
for
temp
=start(1):length(string)
%copy
right
hand
part
ofstring
tempstring(temp-start(1)+1)
=string(temp);
MATLAB Code 137end;
%for
temp
for
temp
=1:(start(1)-1)
%copy
left
hand
side
of
string
tempstring(length(string)-(start(1)-1)+temp)
=string(temp);
end;
%for
temp
string
=tempstring;
%newly
created
tsp
end;
%if
start
while
done
==
0%while
all
customers
are
not
routed
cust
=string(num);
%tel’st
customer
number
[found]
=route(chromno,cust,afstand);
%call
route
function
if
found
==
1%if
customer
was
routed
string(num)
=[];
%remove
from
unrouted
list
else
%customer
could
not
be
routed
num
=num+1;
%else
try
route
next
customer
disp(’No
feasible
solution
found!’);
%warning
message
if
fleet
size
to
small
if
STOPASAP
==
1break
end;
end;
%if
found
%if
num>1,
all
customers
could
not
be
routed
(thus
no
feasible
solution
found)
if
(length(string)
==0)
|((length(string)
==
num)
&(num
~=
1))
%if
all
routed
or
no
feasible
solution
found
done
=1;
%all
customers
routedif
unrouted
empty
or
orphens
present
end;
%if
size
end;
%while
done
if
STOPASAP
==
1return
end;
end;
%for
chromno
MATLAB Code 138
%##########################################################################
%##########################################################################
%##########################################################################
function
[found]
=route(chromno,cust,afstand);
%ROUTE
This
function
routes
the
required
chromosome’s
current
%customer
into
the
current
route
being
populated.
%This
function’s
localvariables:
%routeno
currentroute
number
%found
booleanfor
if
customer
is
routed
%pos
insertion
position
of
customer
in
route
%tempr
temporary
route
created
%veelvoud
multiple
used
for
double
scheduling
%temp
position
counter
%routesize
size
ofcurrent
route
%rload
total
load
of
route
%rtime
total
route
time
%times
arrivaltimes
at
routed
customers
%Variable
initialisation.
global
POP;
global
FLEETSIZE;
global
CUSTFILE;
global
FLEETFILE;
global
NUMTW;
global
AVESPD;
MATLAB Code 139global
DS;
global
STOPASAP;
routeno
=0;
found
=0;
%Code
for
customer
routing.
Vehicles
are
assigned
to
routes.
Temporary
%routes
are
created
andthen
tested
for
feasibility.
If
the
routeis
%feasible,
data
regarding
the
route
is
saved
in
POP.
go
=0;
dswerknie
=0;
incrfleet
=0;
while
found
==
0%while
not
routed
routeno
=routeno+1;
%next
route
pos
=0;
%initialise
pop
tempr
=[];
%empty
temp
route
if
routeno
<=
FLEETSIZE
%if
less
routes
than
vehicle
POP(chromno).route(routeno).vehicle
=FLEETFILE(routeno,1);
%assign
vehicle
to
route
vehiclespd
=FLEETFILE(POP(chromno).route(routeno).vehicle,3);
DS
=0;
elsego
=go+1;
%count
if
go
==
1%if
first
time
for
truck
=1:FLEETSIZE
%for
all
vehicles
if
POP(chromno).route(truck).time
<=
fix(0.9*CUSTFILE(1,6))
%ifless
than
90%
capacity
used
useds(truck)
=1;
%evaluatedouble
scheduling
else
MATLAB Code 140useds(truck)=
0;
%otherwise-
truck
to
full
end;
%if
POP
%fordouble
scheduling
end;
%for
truck
end;
%if
go
trok
=0;
for
truck
=1:FLEETSIZE
%for
all
vehicles
if
useds(truck)
==
1%if
DS
can
be
used
with
this
vehicle
POP(chromno).route(routeno).vehicle
=FLEETFILE(truck,1);
%assign
vehicle
to
route
vehiclespd
=FLEETFILE(POP(chromno).route(routeno).vehicle,3);
FLEETFILE(truck,2)
=FLEETFILE(truck,2)
-POP(chromno).route(truck).load;
%determine
how
much
vehicle
capacity
is
left
trok
=1;
dsplek
=truck;
break;
end;
end;
%for
truck
DS
=1;
%use
DS
if
trok
==
0%if
novehicle
has
place
for
the
customer
disp(’No
feasible
solution
found,
increase
fleet
size
in
Excel
file’);
disp(’If
possible,
theproblem
will
later
on
again
decrease
the
fleetsize’);
dswerknie
=1;
incrfleet
=incrfleet
+1;
end;
%if
trok
end;
%if
routeno
if
(incrfleet
>=
2*FLEETSIZE)
%if
no
vehicle
has
place
for
thecustomer
disp(’No
feasible
solution
found,
increase
fleet
size’);
STOPASAP
=1;
break
end;
MATLAB Code 141
if
dswerknie
==
0%ifa
place
was
found
for
the
customer
routesize
=length(POP(chromno).route(routeno).path);
%determine
route
size
r=
POP(chromno).route(routeno).path;
%copy
current
vehiclepath
to
rwhile
(pos
<(routesize-1))%
&(found
==
0)
%try
all
positions
in
string
until
routed
pos
=pos+1;
%try
next
position
for
temp
=1:(routesize-pos)
tempr(temp)
=r(temp);
%copy
1st
part
of
route
end;
%for
temp
tempr(routesize-pos+1)=
cust;
%insert
customer
to
be
routed
for
temp
=(routesize-pos+1):routesize
tempr(temp+1)
=r(temp);
%copy
last
part
of
route
end;
%for
temp
if
DS
==
0%if
DS
is
not
used
for
this
vehicleroute
truck
=POP(chromno).route(routeno).vehicle;
plek
=find(FLEETFILE(:,1)
==
truck);
else
%if
current
route
is
aDS
route
plek
=dsplek;
end;
%if
DS
[found,rload,rtime,times,dist]
=testfeas(tempr,CUSTFILE,NUMTW,AVESPD,FLEETFILE,plek,afstand,vehiclespd);
%test
route
feasibilty
if
found
==
1%if
feasible
routecollect
route
data
POP(chromno).route(routeno).path
=tempr;
%copy
route
POP(chromno).route(routeno).load
=rload;
%total
route
demand
POP(chromno).route(routeno).time
=rtime;
%total
route
time
POP(chromno).route(routeno).atimes
=times;
%arrival
times
at
customers
POP(chromno).route(routeno).dist
=dist;
%arrival
times
at
customers
break;
end;
%if
found
end;
%while
pos
MATLAB Code 142%if(DS
==
1)
&(found==
0)
%useds(dsplek)
=0;
%end;
%if
found
end;
%if
dswerknie
end;
%while
found
%##########################################################################
%##########################################################################
%##########################################################################
function
[feas,rload,rtime,arrival,dist]
=testfeas(route,CUSTFILE,NUMTW,AVESPD,FLEETFILE,plek,afst,vehiclespd);
%TESTFEAS
This
function
test
whether
the
received
route
is
feasible
or
%not,
takinginto
consideration
vehicle
capacity
and
time
%windows.
%This
function’s
localvariables:
%routeload
currentroute’s
load
%feas
booleanfor
feasible
route
%fit
time
windows
adhered
to
%temp
position
counter
%rload
total
load
of
route
%rtime
total
route
time
%dx
changein
xcoordinates
%dy
changein
ycoordinates
%dist
distance
between
customers
%traveltime
traveltimes
between
customers
in
route
%ea
earliest
possible
arrivals
at
customers
in
route
%arrival
final
feasible
arrival
time
at
customers
in
route
%etw
earliest
delivery
allowed
by
time
windows
MATLAB Code 143%
temp2
time
window
counter
%Variable
initialisation.
routeload
=0;
feas
=1;
%Test
vehicle
capacities
and
loads
for
feasibility.
The
entire
route’s
%load
is
firstly
determined.
This
is
compared
to
vehicle
capacity.
If
%load
exceeds
capacity,the
route
is
infeasible.
for
temp
=1:size(route,2)
%for
all
positions
in
route,
add
customer
demand
routeload
=routeload
+CUSTFILE(route(temp),3);
end;
%for
temp
if
routeload
>FLEETFILE(plek,2)
%if
load
exceeds
capacity
feas
=0;
%infeasible
route
arrival
=0;
rload
=0;
rtime
=0;
dist
=0;
else
%Test
time
window
feasibility
of
the
current
route.
Travel
times
%between
all
the
customers
are
calculated.
Then
the
eraliest
arrival
%time
at
all
customers
are
calculated.
Finally
time
windows
are
tested
%for
violation.
If
feasible,
route
is
accepted.
dist
=0;
%traveltime
=zeros(1,size(route,2));
%slows
down
execution
MATLAB Code 144traveltime=
1:1:(size(route,2));
for
temp
=2:length(route)
%for
all
positions
except
for
depot
at
start
afstand
=afst(route(temp),route(temp-1));
dist
=dist
+afstand;
%route
distance
calculation
traveltime(temp)
=afstand/vehiclespd;
end;
%for
temp
ea(1)
=0;
arrival(1)
=0;
ea
=zeros(1,size(route,2));
%not
required,
slows
down
execution
arrival
=zeros(1,size(route,2));
%speeds
up
execution
lengte
=size(route,2);
for
temp
=2:lengte
%for
all
positions
except
for
depot
at
start
rt
=route(temp);
for
temp4
=1:NUMTW
%for
all
time
windows
(a)
tws(temp4)
=CUSTFILE(rt,5+3*(temp4-1));
%record
all
opening
times
(b)
end;
%for
temp4
%(c)
etw
=min(tws);
%earliest
time
window
found
(d)
ea(temp)
=arrival(route(temp-1))
+CUSTFILE(route(temp-1),4)
+traveltime(temp);
%arrival
time
calculation
if
ea(temp)
<etw
%if
arrive
to
early
arrival(rt)
=etw;
%wait
for
time
window
opening
elsearrival(rt)
=ea(temp);%else
serve
customer
end;
%if
ea
end;
%for
temp
for
temp
=2:lengte
%for
all
positions
except
for
depotat
start
rt
=route(temp);
MATLAB Code 145fortemp2
=1:NUMTW
numtwfeas(temp2)
=1;
end;
for
temp2
=1:NUMTW
%for
all
time
windows
(e)
if
(arrival(rt)
<CUSTFILE(rt,5+3*(temp2-1)))
|(arrival(rt)
>CUSTFILE(rt,7+3*(temp2-1)))
%if
not
in
atime
windows
numtwfeas(temp2)
=0;
end;
%if
arrival
end;
%for
temp2
(f)
if
sum(numtwfeas)
==
0%if
no
time
window
can
accomodate
thedelivery
feas
=0;
break;
end;
if
feas
==
0;
%if
not
feasible
break;
%jump
out
of
temp
for
loop
end;
%if
feas
end;
%for
temp
rload
=routeload;
%save
route
load
rtime
=arrival(route(size(route,2)));
%save
route
time
end;
%if
routeload
E.6
.2cl
ust
er.
m
function
cluster(popsize,afstand);
%CLUSTER
This
function
clusters
the
TSP
initial
solutions
(feasible/not)
%into
various
feasible
routes.
MATLAB Code 146%Thisfunction’s
important
local
variables:
%chromno
chromosome
counter
%temp
fleet
data
%temp2
vehiclecounter
%v
currentvehicle
number
%plek
position
of
max
value
%lys
list
ofvehicle
capacities
%done
booleanfor
all
customers
routed
%num
position
of
customer
to
be
routed
in
unsorted
list
%popsize
numberof
chromosomes
per
generation
%Identifies
global
variables
required
by
this
function.
global
NUMCUST;
global
FLEETSIZE;
global
POP;
global
FLEETFILE;
global
CUSTFILE;
global
CLUST;
global
STOPASAP;
%Variable
initialisation.
for
chromno
=1:popsize
%initialise
pathpart
of
POP
structure
for
temp2
=1:FLEETSIZE
POP(chromno).route(temp2).path
=[1
1];
%depot
at
start
and
end
POP(chromno).route(temp2).vehicle
=0;
%no
vehicle
assigned
end;
%for
temp2
end;
%for
temp
MATLAB Code 147%Sorts
the
vehicle
fleet
from
largest
to
smallest
capacity.
Firstthe
%vehicle
capacities
arewrittin
into
lys.
The
FLEETDATA
is
copiedinto
the
%temp
structure.
The
vehicle
with
maximum
capacity
is
then
foundin
the
%list
and
is
then
placed
in
its
new
position
in
FLEETDATA.
%lys
=zeros(1,FLEETSIZE);
%not
required,
only
slows
execution
down
for
v=
1:FLEETSIZE
%create
vector
of
fleet
capacity
lys(v)
=FLEETFILE(v,2);
%list
of
capacities
end;
%for
v
temp
=FLEETFILE;
for
v=
1:FLEETSIZE
%stores
sorted
numbers
instructure
plek
=find(lys
==
max(lys));
%position
of
max
value
lys(plek(1))
=-10;
%will
not
be
max
value
again
FLEETFILE(v,:)
=temp(plek(1),:);
%assign
vehicle
to
new
position
end;
%for
v
%Creates
routes
for
allchromosomes
in
the
population.
When
all
customers
%are
routed
done
equals1.
The
position
of
the
customer
to
be
routed
in
%the
unsorted
list
is
num.
If
the
customer
is
routed,
it
is
removed
from
%the
unsorted
list.
Otherwise
the
customer
in
the
next
position
in
unsorted
%is
routed.
All
customers
are
routed
is
unrouted
is
empty
or
somecould
not
%be
routed.
for
chromno
=1:popsize
%for
all
chromosomes
done
=0;
%all
customers
not
routed
num
=1;
%route
1st
customer
in
unrouted
MATLAB Code 148string
=POP(chromno).unrouted;
%copy
unrouted
path
for
temp
=1:length(string)
%create
list
of
L_i
values
Li(temp)
=CUSTFILE(string(temp),7);
%only
1st
time
window
ofeach
customer
considered
end;
%for
temp
start
=find(Li
==
min(Li));
%find
earliest
L_i
value’s
position
%The
following
if
creates
anew
tsp
which
starts
with
the
earliest
%deadline
customers,
then
all
the
customers
to
its
right
and
then
all
%customers
to
its
left
(in
original
tsp
order)
if
start(1)
>1
%if
earliest
L_i
is
notthe
first
customer
on
the
route
for
temp
=start(1):length(string)
%copy
right
hand
part
ofstring
tempstring(temp-start(1)+1)
=string(temp);
end;
%for
temp
for
temp
=1:(start(1)-1)
%copy
left
hand
side
of
string
tempstring(length(string)-(start(1)-1)+temp)
=string(temp);
end;
%for
temp
string
=tempstring;
%newly
created
tsp
end;
%if
start
while
done
==
0%while
all
customers
are
not
routed
cust
=string(num);
%tel’st
customer
number
[found]
=route(chromno,cust,afstand);
%call
route
function
if
found
==
1%if
customer
was
routed
string(num)
=[];
%remove
from
unrouted
list
else
%customer
could
not
be
routed
num
=num+1;
%else
try
route
next
customer
disp(’No
feasible
solution
found!’);
%warning
message
if
fleet
size
to
small
if
STOPASAP
==
1
MATLAB Code 149break
end;
end;
%if
found
%if
num>1,
all
customers
could
not
be
routed
(thus
no
feasible
solution
found)
if
(length(string)
==0)
|((length(string)
==
num)
&(num
~=
1))
%if
all
routed
or
no
feasible
solution
found
done
=1;
%all
customers
routed
if
unrouted
empty
or
orphens
present
end;
%if
size
end;
%while
done
if
STOPASAP
==
1return
end;
end;
%for
chromno
%##########################################################################
%##########################################################################
%##########################################################################
function
[found]
=route(chromno,cust,afstand);
%ROUTE
This
function
routes
the
required
chromosome’s
current
%customer
into
the
current
route
being
populated.
%This
function’s
localvariables:
%routeno
currentroute
number
%found
booleanfor
if
customer
is
routed
%pos
insertion
position
of
customer
in
route
%tempr
temporary
route
created
%veelvoud
multiple
used
for
double
scheduling
MATLAB Code 150%
temp
position
counter
%routesize
size
ofcurrent
route
%rload
total
load
of
route
%rtime
total
route
time
%times
arrivaltimes
at
routed
customers
%Variable
initialisation.
global
POP;
global
FLEETSIZE;
global
CUSTFILE;
global
FLEETFILE;
global
NUMTW;
global
AVESPD;
global
DS;
global
STOPASAP;
routeno
=0;
found
=0;
%Code
for
customer
routing.
Vehicles
are
assigned
to
routes.
Temporary
%routes
are
created
andthen
tested
for
feasibility.
If
the
routeis
%feasible,
data
regarding
the
route
is
saved
in
POP.
go
=0;
dswerknie
=0;
incrfleet
=0;
while
found
==
0%while
not
routed
routeno
=routeno+1;
%next
route
MATLAB Code 151pos=
0;
%initialise
pop
tempr
=[];
%empty
temp
route
if
routeno
<=
FLEETSIZE
%if
less
routes
than
vehicle
POP(chromno).route(routeno).vehicle
=FLEETFILE(routeno,1);
%assign
vehicle
to
route
vehiclespd
=FLEETFILE(POP(chromno).route(routeno).vehicle,3);
DS
=0;
elsego
=go+1;
%count
if
go
==
1%if
first
time
for
truck
=1:FLEETSIZE
%for
all
vehicles
if
POP(chromno).route(truck).time
<=
fix(0.9*CUSTFILE(1,6))
%ifless
than
90%
capacity
used
useds(truck)
=1;
%evaluatedouble
scheduling
elseuseds(truck)
=0;
%otherwise-
truck
to
full
end;
%if
POP
%fordouble
scheduling
end;
%for
truck
end;
%if
go
trok
=0;
for
truck
=1:FLEETSIZE
%for
all
vehicles
if
useds(truck)
==
1%if
DS
can
be
used
with
this
vehicle
POP(chromno).route(routeno).vehicle
=FLEETFILE(truck,1);
%assign
vehicle
to
route
vehiclespd
=FLEETFILE(POP(chromno).route(routeno).vehicle,3);
FLEETFILE(truck,2)
=FLEETFILE(truck,2)
-POP(chromno).route(truck).load;
%determine
how
much
vehicle
capacity
is
left
trok
=1;
dsplek
=truck;
break;
end;
end;
%for
truck
MATLAB Code 152DS
=1;
%use
DS
if
trok
==
0%if
novehicle
has
place
for
the
customer
disp(’No
feasible
solution
found,
increase
fleet
size
in
Excel
file’);
disp(’If
possible,
theproblem
will
later
on
again
decrease
the
fleetsize’);
dswerknie
=1;
incrfleet
=incrfleet
+1;
end;
%if
trok
end;
%if
routeno
if
(incrfleet
>=
2*FLEETSIZE)
%if
no
vehicle
has
place
for
the
customer
disp(’No
feasible
solution
found,
increase
fleet
size’);
STOPASAP
=1;
break
end;
if
dswerknie
==
0%ifa
place
was
found
for
the
customer
routesize
=length(POP(chromno).route(routeno).path);
%determine
route
size
r=
POP(chromno).route(routeno).path;
%copy
current
vehiclepath
to
rif
found
==
0pos
=1;
%try
next
position
for
temp
=1:(routesize-pos)
tempr(temp)
=r(temp);
%copy
1st
part
of
route
end;
%for
temp
tempr(routesize-pos+1)=
cust;
%insert
customer
to
be
routed
for
temp
=(routesize-pos+1):routesize
tempr(temp+1)
=r(temp);
%copy
last
part
of
route
end;
%for
temp
if
DS
==
0%if
DS
is
not
used
for
this
vehicleroute
truck
=POP(chromno).route(routeno).vehicle;
plek
=find(FLEETFILE(:,1)
==
truck);
MATLAB Code 153else
%if
current
route
is
aDS
route
plek
=dsplek;
end;
%if
DS
[found,rload,rtime,times,dist]
=testfeas(tempr,CUSTFILE,NUMTW,AVESPD,FLEETFILE,plek,afstand,vehiclespd);
%test
route
feasibilty
if
found
==
1%if
feasible
routecollect
route
data
POP(chromno).route(routeno).path
=tempr;
%copy
route
POP(chromno).route(routeno).load
=rload;
%total
route
demand
POP(chromno).route(routeno).time
=rtime;
%total
route
time
POP(chromno).route(routeno).atimes
=times;
%arrival
times
at
customers
POP(chromno).route(routeno).dist
=dist;
%arrival
times
at
customers
break;
end;
%if
found
end;
%if
found
%if
(DS
==
1)
&(found==
0)
%useds(dsplek)
=0;
%end;
%if
found
end;
%if
dswerknie
end;
%while
found
%##########################################################################
%##########################################################################
%##########################################################################
function
[feas,rload,rtime,arrival,dist]
=testfeas(route,CUSTFILE,NUMTW,AVESPD,FLEETFILE,plek,afst,vehiclespd);
%TESTFEAS
This
function
test
whether
the
received
route
is
feasible
or
%not,
takinginto
consideration
vehicle
capacity
and
time
%windows.
MATLAB Code 154%Thisfunction’s
localvariables:
%routeload
currentroute’s
load
%feas
booleanfor
feasible
route
%fit
time
windows
adhered
to
%temp
position
counter
%rload
total
load
of
route
%rtime
total
route
time
%dx
changein
xcoordinates
%dy
changein
ycoordinates
%dist
distance
between
customers
%traveltime
traveltimes
between
customers
in
route
%ea
earliest
possible
arrivals
at
customers
in
route
%arrival
final
feasible
arrival
time
at
customers
in
route
%etw
earliest
delivery
allowed
by
time
windows
%temp2
time
window
counter
%Variable
initialisation.
routeload
=0;
feas
=1;
%Test
vehicle
capacities
and
loads
for
feasibility.
The
entire
route’s
%load
is
firstly
determined.
This
is
compared
to
vehicle
capacity.
If
%load
exceeds
capacity,the
route
is
infeasible.
for
temp
=1:size(route,2)
%for
all
positions
in
route,
add
customer
demand
routeload
=routeload
+CUSTFILE(route(temp),3);
end;
%for
temp
if
routeload
>FLEETFILE(plek,2)
%if
load
exceeds
capacity
MATLAB Code 155feas
=0;
%infeasible
route
arrival
=0;
rload
=0;
rtime
=0;
dist
=0;
else
%Test
time
window
feasibility
of
the
current
route.
Travel
times
%between
all
the
customers
are
calculated.
Then
the
eraliest
arrival
%time
at
all
customers
are
calculated.
Finally
time
windows
are
tested
%for
violation.
If
feasible,
route
is
accepted.
dist
=0;
%traveltime
=zeros(1,size(route,2));
%slows
down
execution
traveltime
=1:1:(size(route,2));
for
temp
=2:length(route)
%for
all
positions
except
for
depot
at
start
afstand
=afst(route(temp),route(temp-1));
dist
=dist
+afstand;
%route
distance
calculation
traveltime(temp)
=afstand/vehiclespd;
end;
%for
temp
ea(1)
=0;
arrival(1)
=0;
ea
=zeros(1,size(route,2));
%not
required,
slows
down
execution
arrival
=zeros(1,size(route,2));
%speeds
up
execution
lengte
=size(route,2);
for
temp
=2:lengte
%for
all
positions
except
for
depot
at
start
rt
=route(temp);
MATLAB Code 156fortemp4
=1:NUMTW
%for
all
time
windows
(a)
tws(temp4)
=CUSTFILE(rt,5+3*(temp4-1));
%record
all
opening
times
(b)
end;
%for
temp4
%(c)
etw
=min(tws);
%earliest
time
window
found
(d)
ea(temp)
=arrival(route(temp-1))
+CUSTFILE(route(temp-1),4)
+traveltime(temp);
%arrival
time
calculation
if
ea(temp)
<etw
%if
arrive
to
early
arrival(rt)
=etw;
%wait
for
time
window
opening
elsearrival(rt)
=ea(temp);%else
serve
customer
end;
%if
ea
end;
%for
temp
for
temp
=2:lengte
%for
all
positions
except
for
depotat
start
rt
=route(temp);
for
temp2
=1:NUMTW
numtwfeas(temp2)
=1;
end;
for
temp2
=1:NUMTW
%for
all
time
windows
(e)
if
(arrival(rt)
<CUSTFILE(rt,5+3*(temp2-1)))
|(arrival(rt)
>CUSTFILE(rt,7+3*(temp2-1)))
%if
not
in
atime
windows
numtwfeas(temp2)
=0;
end;
%if
arrival
end;
%for
temp2
(f)
if
sum(numtwfeas)
==
0%if
no
time
window
can
accomodate
thedelivery
feas
=0;
break;
end;
if
feas
==
0;
%if
not
feasible
break;
%jump
out
of
temp
for
loop
end;
%if
feas
MATLAB Code 157end;
%for
temp
rload
=routeload;
%save
route
load
rtime
=arrival(route(size(route,2)));
%save
route
time
end;
%if
routeload
E.7
Fit
ness
Calc
ula
tion
(fitc
alc
.m)
function
fitcalc(lpenalty,popsize,gennum);
%FITCALC
This
function
calculates
the
fitness
of
the
clusteredroutes.
%Fitness
iscomprised
of
travel
distance
and
lateness
penalties.
%This
function’s
important
local
variables:
%chromno
chromosome
counter
%klaar
booleanfor
whether
routes
exist
%num
route
number
counter
%late
total
lateness
penalty
%rsize
route
size
%c
customer
counter
%Identifies
global
variables
required
by
this
function.
global
POP;
global
CUSTFILE;
global
FIT;
global
BEST;
global
BESTGEN;
MATLAB Code 158%Determines
the
numberof
routes
in
each
chromosome.
for
chromno
=1:popsize
%for
all
chromosomes
klaar
=0;
%routes
not
finished
num
=0;
%route
counter
=0
while
klaar
==
0%while
more
routes
num
=num
+1;
%increment
route
if
POP(chromno).route(num).vehicle
==
0%if
no
vehicle
assigned
klaar
=1;
%routes
finished
POP(chromno).numroutes=
num-1;
%save
number
of
routes
end;
%if
POP
end;
%while
klaar
end;
%for
chromno
%Determines
time
windowlateness
penalties.
for
chromno
=1:popsize
%for
all
chromosomes
late(chromno)
=0;
for
num
=1:POP(chromno).numroutes
%for
all
routes
rsize
=size(POP(chromno).route(num).path,2);
%determine
route
size
for
c=
1:rsize
%for
all
customers
on
route
cust
=POP(chromno).route(num).path(c);
arrive
=POP(chromno).route(num).atimes(cust);
%arrival
time
for
tw
=1:NUMTW
%for
all
time
windows
(a)
if
(arrive
>=
CUSTFILE(cust,5))
&(arrive
<=
CUSTFILE(cust,6))
%(b)
l=
CUSTFILE(cust,6);
%if
arrive
within
time
window
(c)
end;
%if
arrive
(d)
end;
%for
tw
(e)
%lines
a,
b,
dand
ecan
be
removed
for
faster
execution
when
%only
1time
windows
isused
MATLAB Code 159if
arrive
>l
%if
penalty
occured
late(chromno)
=late(chromno)
+lpenalty
*(arrive-l);
%penalty
accumalation
end;
%if
arrive
end;
%for
cust
end;
%for
num
end;
%for
chromno
%Determines
total
distance
of
all
routes.
for
chromno
=1:popsize
%for
all
chromosomes
tdist(chromno)
=0;
for
num
=1:POP(chromno).numroutes
%for
all
routes
tdist(chromno)
=tdist(chromno)
+POP(chromno).route(num).dist;
%distance
accumalation
end;
%for
num
end;
%for
chromno
%Save
chromosome
fitness
for
chromno
=1:popsize
%for
all
chromosomes
POP(chromno).fitness
=tdist(chromno)
+late(chromno);
FIT(chromno)
=tdist(chromno)
+late(chromno);
end;
%for
chromno
bestno
=find(FIT
==
min(FIT));
%number
of
best
chromosome
if
POP(bestno(1)).fitness
<BEST.fitness
%is
best
in
this
generation
better
than
best
ever
so
far
BEST
=POP(bestno(1));
%best
population
so
far
BESTGEN
=gennum;
%best
generation
number
end;
%if
POP
MATLAB Code 160E.8
Plo
tFit
ness
(plo
tgen.m
)
function
plotgen(timeline,maxnumgen,gennum);
global
NUMCUST;
global
POP;
global
BEST;
global
CUSTFILE;
figure(1);
%first
figure
set(1,’Position’,[10
100
1000
500]);
%positionon
screen
subplot(1,2,1);
%2
graphsin
one
windows
plot(1:size(timeline,1),timeline(:,3),’r.-’);
%plot
fitnesses
hold
on;
plot(1:size(timeline,1),timeline(:,2),’k.--’);
hold
on;
plot(1:size(timeline,1),timeline(:,1),’b.:’);
set(gca,’YGrid’,’on’);
%create
ygridlines
xlim([1,maxnumgen]);
%set
x-axis
limits
subplot(1,2,2);
%2nd
graphin
window
hold
off;
plot(CUSTFILE(1,1),CUSTFILE(1,2),’o’);
%plot
depot
hold
on;
plot(CUSTFILE(:,1),CUSTFILE(:,2),’.’);
%plot
customers
kleure
=[’bgrcmykbgrcmykbgrcmykbgrcmykbgrcmykbgrcmykbgrcmyk’];
lyne
=[’-------:::::::-------:::::::-------:::::::-------’];
wys
=min([POP.fitness]);
plek
=find([POP.fitness]
==
wys);
plek
=plek(1);
for
r=
1:(POP(plek).numroutes)
%plot
allroutes
between
all
customers
MATLAB Code 161forcust
=2:size(POP(plek).route(r).path,2)
xse
=[CUSTFILE(POP(plek).route(r).path(cust-1),1),CUSTFILE(POP(plek).route(r).path(cust),1)];
yse
=[CUSTFILE(POP(plek).route(r).path(cust-1),2),CUSTFILE(POP(plek).route(r).path(cust),2)];
tipe
=[kleure(r),lyne(r)];
plot(xse,yse,tipe);
end;
%for
cust
end;
%for
cust
plot(CUSTFILE(1,1),CUSTFILE(1,2),’o’);
%plot
depot
hold
on;
plot(CUSTFILE(:,1),CUSTFILE(:,2),’.’);
%plot
customers
axis
equal;
%reset
axis
pause(0.01);
%refresh
time
for
figure
E.9
Clo
nin
g(c
lone.m
)
function
clone(numelites,popsize);
%CLONE
This
functions
clones
the
best
chromosomes
from
the
previous
%generationto
the
next.
It
thus
incorporates
the
principle
of
%elites
intothe
algorithm.
%This
function’s
localvariables:
%popsize
numberof
chromosomes
per
generation
%numelites
numberof
elites
per
generation
%num
elitescounter
%plek
position
of
elite
chromosomes
%temp
temporary
tsp
route
%Variable
initialisation.
MATLAB Code 162
global
NEWPOP;
global
POP;
global
FIT;
global
BEST;
global
NUMCUST;
%Initialise
an
empty
new
structure
variable
for
the
new
population
for
temp
=1:popsize
NEWPOP(temp).tsp
=[];
NEWPOP(temp).unrouted
=[];
NEWPOP(temp).route
=[];
NEWPOP(temp).numroutes
=[];
NEWPOP(temp).fitness
=[];
end;
%for
temp
%Copies
the
elites
in
POP
to
the
same
positions
in
NEWPOP
for
num
=1:numelites
%for
all
elites
plek
=find(FIT
==
min(FIT));
%find
minimum
fitness
chromosome
number
FIT(plek(1))
=9999999;
%over
write
smallest
fitness
value
with
%large
value
to
moreselections
NEWPOP(plek(1)).tsp
=POP(plek(1)).tsp;
%copy
tsp
part
of
POP
structure
temp
=NEWPOP(plek(1)).tsp;
%remove
customer
1out
of
tsp
temp(NUMCUST+1)
=[];
temp(1)
=[];
NEWPOP(plek(1)).unrouted=
temp;
%save
this
route
as
theunrouted
list
end;
%for
num
MATLAB Code 163E.1
0C
ross
over
(cro
ssover.
m)
function
[numxo]
=crossover(xotype,pc,popsize,numxo,precedence);
%CROSSOVER
This
function
performs
the
crossover
operator
of
the
GA.
%The
type
ofcrossover
is
specified
by
the
user.
%This
function’s
localvariables:
%s1
first
selected
chromosome
%s2
secondselected
chromosome
%chromno
chromosome
number
%pc
probability
of
crossover
taking
place
%elites
list
ofelite
chromosomes
%Variables
initialisation
global
POP;
global
NEWPOP;
global
NUMCUST;
tel=0;
%EER,
MXL
and
MXe
creates
one
offspring,
the
rest
two
offsprings.
The
code
%is
thus
split
in
two
to
incorporate
these
two
alternatives
if
xotype
<=
3%if
EER,
MXL,
MXe(1
offspring
part)
for
chromno
=1:popsize
%for
all
chromosomes
if
isempty(NEWPOP(chromno).tsp)
==
1%if
not
elite
if
rand
<=
pc
%do
crossover
with
probabilitypc
[s1,s2]
=select;
%biased
roulette
wheel
selection
switch
xotype
case
1%EER
MATLAB Code 164[offspring]
=eer(s1,s2);
%enhanced
edge
recombination
crossover
case
2%MXL
[offspring]
=mx(s1,s2,popsize,precedence);
%merge
crossover
case
3%MXe
[offspring]
=mx(s1,s2,popsize,precedence);
%merge
crossover
end;
%switch
NEWPOP(chromno).unrouted
=offspring;
%crossed
over
chromosome
offspring
=[1,offspring,1];
%add
depot
NEWPOP(chromno).tsp=
offspring;
%save
new
chromosome
numxo
=numxo
+1;
%count
number
of
crossovers
elseNEWPOP(chromno).tsp=
POP(chromno).tsp;
%no
crossover
take
place
temp
=NEWPOP(chromno).tsp;
%to
remove
depot
from
tsp
temp(NUMCUST+1)
=[];
temp(1)
=[];
NEWPOP(chromno).unrouted
=temp;
%save
tsp
without
depot
end;
%if
rand
end;
%if
POP
end;
%for
chromno
%The
following
code
isfor
crossovers
that
create
two
offspring
-NOT
%WORKING
OR
FINISHED
YET!!!!!!!!!!!!!!!!!!!
else
%if
not
EER,
MXL
or
MXe
(2
offspring
part)
for
chromno
=1:fix(popsize/2)
%for
all
chromosomes
if
rand
<=
pc
%do
crossover
with
probability
pc
[s1,s2]
=select;
%biased
roulette
wheel
selection
if
(isempty(NEWPOP(s1).tsp)
==
1)
&(isempty(NEWPOP(s2).tsp)
==
1)%if
not
elite
switch
xotype
case
4%PMX
MATLAB Code 165[offspring1,offspring2]=
pmx(s1,s2);
%partially
matched
crossover
end;
%switch
NEWPOP((chromno-1)*2+1).unrouted
=offspring1;
%crossed
overchromosome
offspring1
=[1,offspring1,1];
%add
depot
NEWPOP((chromno-1)*2+1).tsp
=offspring1;
%1st
child
NEWPOP((chromno-1)*2+2).unrouted
=offspring2;
%crossed
overchromosome
offspring2
=[1,offspring2,1];
%add
depot
NEWPOP((chromno-1)*2+2).tsp
=offspring2;
%2nd
child
tel=tel+2;
numxo
=numxo
+1;
elseNEWPOP((chromno-1)*2+1).tsp
=POP(s1).tsp;
%no
crossover
temp
=NEWPOP((chromno-1)*2+1).tsp;
temp(NUMCUST+1)
=[];
temp(1)
=[];
NEWPOP((chromno-1)*2+1).unrouted
=temp;
NEWPOP((chromno-1)*2+2).tsp
=POP(s2).tsp;
%no
crossover
temp
=NEWPOP((chromno-1)*2+2).tsp;
temp(NUMCUST+1)
=[];
temp(1)
=[];
NEWPOP((chromno-1)*2+2).unrouted
=temp;
tel=tel+2;
end;
end;
end;
%for
chromno
tel
for
temp=1:popsize
NEWPOP(temp).tsp
end;
%if
xotype
MATLAB Code 166
fortemp=tel:popsize
[s1,s2]
=select;
%biased
roulette
wheel
selection
NEWPOP((chromno-1)*2+1).tsp
=POP(s1).tsp;
%no
crossover
temp
=NEWPOP((chromno-1)*2+1).tsp;
temp(NUMCUST+1)
=[];
temp(1)
=[];
NEWPOP((chromno-1)*2+1).unrouted
=temp;
end;
%for
tel
for
temp=1:popsize
NEWPOP(temp).tsp
end;
%if
xotype
end;
%##########################################################################
%##########################################################################
%##########################################################################
function
[c1,c2]
=select;
%SELECT
Selects
twochromosomes
for
crossover
using
the
biassed
%roulette
wheel
selection
method.
%This
function’s
localvariables:
%c1
first
chromosome
selected
MATLAB Code 167%
c2
second
chromosome
selected
%fsum
sum
of
fitness
%pist
list
of
crossover
probabilities
%kies
chosen
parent
global
POP;
fsum
=sum([POP.fitness]);
%total
summed
fitness
plist
=[POP.fitness]/fsum;
%selection
probablity
calculation
clist
=cumsum(plist);
%cumulative
sum
of
probabilities
kies
=find(clist
>rand);
%choose
1st
parent
c1
=kies(1);
%to
avoid
ties
kies
=find(clist
>rand);
%choose
2nd
parent
c2
=kies(1);
%to
avoid
ties
%##########################################################################
%##########################################################################
%##########################################################################
function
[offspring]
=eer(s1,s2);
%EER
Enhanced
edge
recombination
crossover
%Function’s
important
local
variables:
%c1
first
chromosome
%c2
secondchromosome
%edgetable
eer’s
edge
list
global
NUMCUST;
global
POP;
MATLAB Code 168
c1
=POP(s1).tsp;
%first
chromosome
c2
=POP(s2).tsp;
%second
chromosome
c1(NUMCUST+1)
=[];
%delete
depot
c1(1)
=[];
%delete
depot
c2(NUMCUST+1)
=[];
%delete
depot
c2(1)
=[];
%delete
depot
edgetable
=zeros(NUMCUST-1,6);
%initialise
edge
table
%Creates
the
edge
listrequired
for
EER,
uses
duplicate
values
instead
of
%flagged
values.
for
temp
=2:(NUMCUST)
edgetable(temp-1,1)
=temp;
%number
edge
list
end;
%for
temp
for
temp
=2:(NUMCUST-2)
%for
middle
of
route
cust
=c1(temp);
%add
edge
table
values
cust2
=c2(temp);
edgetable(cust-1,2)
=c1(temp-1);
edgetable(cust-1,3)
=c1(temp+1);
edgetable(cust2-1,4)
=c2(temp-1);
edgetable(cust2-1,5)
=c2(temp+1);
end;
%for
temp
%Code
that
is
used
to
incorporate
the
fact
that
the
first
and
last
%customers
in
achromosome
are
neighbours
cust
=c1(1);
cust2
=c2(1);
MATLAB Code 169edgetable(cust-1,2)=
c1(NUMCUST-1);
%add
value
to
edge
list
edgetable(cust-1,3)
=c1(2);
edgetable(cust2-1,4)
=c2(NUMCUST-1);
edgetable(cust2-1,5)
=c2(2);
cust
=c1(NUMCUST-1);
cust2
=c2(NUMCUST-1);
edgetable(cust-1,2)
=c1(NUMCUST-2);
%add
value
to
edge
list
edgetable(cust-1,3)
=c1(1);
edgetable(cust2-1,4)
=c2(NUMCUST-2);
edgetable(cust2-1,5)
=c2(1);
%Counts
the
number
of
duplicates
for
all
customers
for
temp
=1:(NUMCUST-1)
dupl
=0;
if
(edgetable(temp,4)
==edgetable(temp,2))
|(edgetable(temp,4)
==edgetable(temp,3))
dupl
=dupl
+1;
end;
%if
edgetable
if
(edgetable(temp,5)
==edgetable(temp,2))
|(edgetable(temp,5)
==edgetable(temp,3))
dupl
=dupl
+1;
end;
%if
edgetable
edgetable(temp,6)
=dupl;
end;
%for
temp
ops1
=c1(1);
ops2
=c2(1);
%Choose
customer
with
largest
number
of
duplicates
if
edgetable(ops1-1,6)>=
edgetable(ops2-1,6)
MATLAB Code 170choose
=ops1;
%choose
1st
customer
elsechoose
=ops2;
%choose
2nd
customer
end;
%if
edgetable
offspring(1)
=choose;
for
temp
=1:(NUMCUST-2)
min
=10;
for
temp2
=1:4
%for
all
edge
list
values
per
customer
cust
=edgetable(offspring(temp)-1,temp2+1);
if
edgetable(cust-1,6)<
min
min
=edgetable(cust-1,6);
choose
=cust;
end;
%if
end;
%for
temp2
offspring(temp+1)
=cust;
%assign
customer
to
offspring
end;
%for
temp
%##########################################################################
%##########################################################################
%##########################################################################
function
[offspring]
=mx(s1,s2,popsize,precedence);
%MX
Merge
crossoverwith
precedence
vector
based
on
time
window
opening
%or
closing
times.
%Function’s
important
local
variables:
%c1
first
chromosome
MATLAB Code 171%
c2
secondchromosome
global
NUMCUST;
global
POP;
c1
=POP(s1).tsp;
c2
=POP(s2).tsp;
c1(NUMCUST+1)
=[];
c1(1)
=[];
c2(NUMCUST+1)
=[];
c2(1)
=[];
for
tel
=1:(NUMCUST-1)
%for
all
customers
pre1(1)
=find(precedence
==
c1(tel));
%find
position
in
precedencevector
pre2(1)
=find(precedence
==
c2(tel));
%find
position
in
precedencevector
if
pre1(1)
<=
pre2(1)
%if
1st
customer
earlier
offspring(tel)
=c1(tel);
%choose
customer
swap
=c2(tel);
%swap
to
ensure
selection
feasibility
place
=find(c2
==
c1(tel));
c2(tel)
=c2(place);
c2(place)
=swap;
else
%if
2nd
customer
earlier
offspring(tel)
=c2(tel);
%choose
customer
swap
=c1(tel);
%swap
to
ensure
selection
feasibility
place
=find(c1
==
c2(tel));
c1(tel)
=c1(place);
c1(place)
=swap;
end;
%if
pre1(1)
end;
%for
temp
MATLAB Code 172%##########################################################################
%##########################################################################
%##########################################################################
function
[offspring1,offspring2]
=pmx(s1,s2);
%PMX
STILL
IN
CONSTRUCTION!!!!!!!!!!!!!!!
%Function’s
local
variables:
% global
NUMCUST;
global
POP;
xsite1
=fix(rand*NUMCUST)+1;
xsite2
=fix(rand*NUMCUST)+1;
c1
=POP(s1).tsp;
c2
=POP(s2).tsp;
for
swap
=xsite1:xsite2
temp
=c2(swap);
c2(swap)
=c1(swap);
c1(swap)
=temp;
end;
%for
swap
for
tel
=1:NUMCUST
for
plek
=xsite1:xsite2
end;
%for
plek
end;
%for
tel
MATLAB Code 173offspring1=1;
offspring2=1;
%##########################################################################
%##########################################################################
%##########################################################################
function
cluster(popsize,afstand,traveltime);
%CLUSTER
This
function
clusters
the
TSP
initial
solutions
(feasible/not)
%into
various
feasible
routes.
%This
function’s
important
local
variables:
%chromno
chromosome
counter
%temp
fleet
data
%temp2
vehiclecounter
%v
currentvehicle
number
%plek
position
of
max
value
%lys
list
ofvehicle
capacities
%done
booleanfor
all
customers
routed
%num
position
of
customer
to
be
routed
in
unsorted
list
%popsize
numberof
chromosomes
per
generation
%Identifies
global
variables
required
by
this
function.
global
NUMCUST;
global
FLEETSIZE;
global
POP;
global
FLEETFILE;
global
CUSTFILE;
MATLAB Code 174global
CLUST;
global
STOPASAP;
%Variable
initialisation.
for
chromno
=1:popsize
%initialise
pathpart
of
POP
structure
for
temp2
=1:FLEETSIZE
POP(chromno).route(temp2).path
=[1
1];
%depot
at
start
and
end
POP(chromno).route(temp2).vehicle
=0;
%no
vehicle
assigned
end;
%for
temp2
end;
%for
temp
%Sorts
the
vehicle
fleet
from
largest
to
smallest
capacity.
Firstthe
%vehicle
capacities
arewrittin
into
lys.
The
FLEETDATA
is
copiedinto
the
%temp
structure.
The
vehicle
with
maximum
capacity
is
then
foundin
the
%list
and
is
then
placed
in
its
new
position
in
FLEETDATA.
%lys
=zeros(1,FLEETSIZE);
%not
required,
only
slows
execution
down
for
v=
1:FLEETSIZE
%create
vector
of
fleet
capacity
lys(v)
=FLEETFILE(v,2);
%list
of
capacities
end;
%for
v
temp
=FLEETFILE;
for
v=
1:FLEETSIZE
%stores
sorted
numbers
instructure
plek
=find(lys
==
max(lys));
%position
of
max
value
lys(plek(1))
=-10;
%will
not
be
max
value
again
FLEETFILE(v,:)
=temp(plek(1),:);
%assign
vehicle
to
new
position
end;
%for
v
MATLAB Code 175
%Createsroutes
for
allchromosomes
in
the
population.
When
all
customers
%are
routed
done
equals1.
The
position
of
the
customer
to
be
routed
in
%the
unsorted
list
is
num.
If
the
customer
is
routed,
it
is
removed
from
%the
unsorted
list.
Otherwise
the
customer
in
the
next
position
in
unsorted
%is
routed.
All
customers
are
routed
is
unrouted
is
empty
or
somecould
not
%be
routed.
for
chromno
=1:popsize
%for
all
chromosomes
done
=0;
%all
customers
not
routed
num
=1;
%route
1st
customer
in
unrouted
string
=POP(chromno).unrouted;
%copy
unrouted
path
for
temp
=1:length(string)
%create
list
of
L_i
values
Li(temp)
=CUSTFILE(string(temp),7);
%only
1st
time
window
ofeach
customer
considered
end;
%for
temp
start
=find(Li
==
min(Li));
%find
earliest
L_i
value’s
position
%The
following
if
creates
anew
tsp
which
starts
with
the
earliest
%deadline
customers,
then
all
the
customers
to
its
right
and
then
all
%customers
to
its
left
(in
original
tsp
order)
if
start(1)
>1
%if
earliest
L_i
is
notthe
first
customer
on
the
route
for
temp
=start(1):length(string)
%copy
right
hand
part
ofstring
tempstring(temp-start(1)+1)
=string(temp);
end;
%for
temp
for
temp
=1:(start(1)-1)
%copy
left
hand
side
of
string
tempstring(length(string)-(start(1)-1)+temp)
=string(temp);
end;
%for
temp
MATLAB Code 176string
=tempstring;
%newly
created
tsp
end;
%if
start
while
done
==
0%while
all
customers
are
not
routed
cust
=string(num);
%tel’st
customer
number
[found]
=route(chromno,cust,afstand,traveltime);
%call
route
function
if
found
==
1%if
customer
was
routed
string(num)
=[];
%remove
from
unrouted
list
else
%customer
could
not
be
routed
num
=num+1;
%else
try
route
next
customer
disp(’No
feasible
solution
found!’);
%warning
message
if
fleet
size
to
small
if
STOPASAP
==
1break
end;
end;
%if
found
%if
num>1,
all
customers
could
not
be
routed
(thus
no
feasible
solution
found)
if
(length(string)
==0)
|((length(string)
==
num)
&(num
~=
1))
%if
all
routed
or
no
feasible
solution
found
done
=1;
%all
customers
routed
if
unrouted
empty
or
orphens
present
end;
%if
size
end;
%while
done
if
STOPASAP
==
1return
end;
end;
%for
chromno
%##########################################################################
%##########################################################################
%##########################################################################
MATLAB Code 177
function[found]
=route(chromno,cust,afstand,traveltime);
%ROUTE
This
function
routes
the
required
chromosome’s
current
%customer
into
the
current
route
being
populated.
%This
function’s
localvariables:
%routeno
currentroute
number
%found
booleanfor
if
customer
is
routed
%pos
insertion
position
of
customer
in
route
%tempr
temporary
route
created
%veelvoud
multiple
used
for
double
scheduling
%temp
position
counter
%routesize
size
ofcurrent
route
%rload
total
load
of
route
%rtime
total
route
time
%times
arrivaltimes
at
routed
customers
%Variable
initialisation.
global
POP;
global
FLEETSIZE;
global
CUSTFILE;
global
FLEETFILE;
global
NUMTW;
global
AVESPD;
global
DS;
global
STOPASAP;
routeno
=0;
MATLAB Code 178found=
0;
%Code
for
customer
routing.
Vehicles
are
assigned
to
routes.
Temporary
%routes
are
created
andthen
tested
for
feasibility.
If
the
routeis
%feasible,
data
regarding
the
route
is
saved
in
POP.
go
=0;
dswerknie
=0;
incrfleet
=0;
while
found
==
0%while
not
routed
routeno
=routeno+1;
%next
route
pos
=0;
%initialise
pop
tempr
=[];
%empty
temp
route
if
routeno
<=
FLEETSIZE
%if
less
routes
than
vehicle
POP(chromno).route(routeno).vehicle
=FLEETFILE(routeno,1);
%assign
vehicle
to
route
DS
=0;
elsego
=go+1;
%count
if
go
==
1%if
first
time
for
truck
=1:FLEETSIZE
%for
all
vehicles
if
POP(chromno).route(truck).time
<=
fix(0.9*CUSTFILE(1,6))
%ifless
than
90%
capacity
used
useds(truck)
=1;
%evaluatedouble
scheduling
elseuseds(truck)
=0;
%otherwise-
truck
to
full
end;
%if
POP
%fordouble
scheduling
end;
%for
truck
end;
%if
go
trok
=0;
MATLAB Code 179fortruck
=1:FLEETSIZE
%for
all
vehicles
if
useds(truck)
==
1%if
DS
can
be
used
with
this
vehicle
POP(chromno).route(routeno).vehicle
=FLEETFILE(truck,1);
%assign
vehicle
to
route
FLEETFILE(truck,2)
=FLEETFILE(truck,2)
-POP(chromno).route(truck).load;
%determine
how
much
vehicle
capacity
is
left
trok
=1;
dsplek
=truck;
break;
end;
end;
%for
truck
DS
=1;
%use
DS
if
trok
==
0%if
novehicle
has
place
for
the
customer
disp(’No
feasible
solution
found,
increase
fleet
size
in
Excel
file’);
disp(’If
possible,
theproblem
will
later
on
again
decrease
the
fleetsize’);
dswerknie
=1;
incrfleet
=incrfleet
+1;
end;
%if
trok
end;
%if
routeno
if
(incrfleet
>=
2*FLEETSIZE)
%if
no
vehicle
has
place
for
thecustomer
disp(’No
feasible
solution
found,
increase
fleet
size’);
STOPASAP
=1;
break
end;
if
dswerknie
==
0%if
aplace
was
found
for
the
customer
routesize
=length(POP(chromno).route(routeno).path);
%determine
route
size
r=
POP(chromno).route(routeno).path;
%copy
current
vehiclepath
to
rif
found
==
0pos
=1;
%try
next
position
MATLAB Code 180fortemp
=1:(routesize-pos)
tempr(temp)
=r(temp);
%copy
1st
part
of
route
end;
%for
temp
tempr(routesize-pos+1)=
cust;
%insert
customer
to
be
routed
for
temp
=(routesize-pos+1):routesize
tempr(temp+1)
=r(temp);
%copy
last
part
of
route
end;
%for
temp
if
DS
==
0%if
DS
is
not
used
for
this
vehicleroute
truck
=POP(chromno).route(routeno).vehicle;
plek
=find(FLEETFILE(:,1)
==
truck);
else
%if
current
route
is
aDS
route
plek
=dsplek;
end;
%if
DS
[found,rload,rtime,times,dist]
=testfeas(tempr,CUSTFILE,NUMTW,AVESPD,FLEETFILE,plek,afstand,traveltime);
%test
route
feasibilty
if
found
==
1%if
feasible
routecollect
route
data
POP(chromno).route(routeno).path
=tempr;
%copy
route
POP(chromno).route(routeno).load
=rload;
%total
route
demand
POP(chromno).route(routeno).time
=rtime;
%total
route
time
POP(chromno).route(routeno).atimes
=times;
%arrival
times
at
customers
POP(chromno).route(routeno).dist
=dist;
%arrival
times
at
customers
break;
end;
%if
found
end;
%if
found
%if
(DS
==
1)
&(found==
0)
%useds(dsplek)
=0;
%end;
%if
found
end;
%if
dswerknie
end;
%while
found
MATLAB Code 181
%##########################################################################
%##########################################################################
%##########################################################################
function
[feas,rload,rtime,arrival,dist]
=testfeas(route,CUSTFILE,NUMTW,AVESPD,FLEETFILE,plek,afst,ttime);
%TESTFEAS
This
function
test
whether
the
received
route
is
feasible
or
%not,
takinginto
consideration
vehicle
capacity
and
time
%windows.
%This
function’s
localvariables:
%routeload
currentroute’s
load
%feas
booleanfor
feasible
route
%fit
time
windows
adhered
to
%temp
position
counter
%rload
total
load
of
route
%rtime
total
route
time
%dx
changein
xcoordinates
%dy
changein
ycoordinates
%dist
distance
between
customers
%traveltime
traveltimes
between
customers
in
route
%ea
earliest
possible
arrivals
at
customers
in
route
%arrival
final
feasible
arrival
time
at
customers
in
route
%etw
earliest
delivery
allowed
by
time
windows
%temp2
time
window
counter
%Variable
initialisation.
routeload
=0;
MATLAB Code 182feas
=1;
%Test
vehicle
capacities
and
loads
for
feasibility.
The
entire
route’s
%load
is
firstly
determined.
This
is
compared
to
vehicle
capacity.
If
%load
exceeds
capacity,the
route
is
infeasible.
for
temp
=1:size(route,2)
%for
all
positions
in
route,
add
customer
demand
routeload
=routeload
+CUSTFILE(route(temp),3);
end;
%for
temp
if
routeload
>FLEETFILE(plek,2)
%if
load
exceeds
capacity
feas
=0;
%infeasible
route
arrival
=0;
rload
=0;
rtime
=0;
dist
=0;
else
%Test
time
window
feasibility
of
the
current
route.
Travel
times
%between
all
the
customers
are
calculated.
Then
the
eraliest
arrival
%time
at
all
customers
are
calculated.
Finally
time
windows
are
tested
%for
violation.
If
feasible,
route
is
accepted.
dist
=0;
%traveltime
=zeros(1,size(route,2));
%slows
down
execution
traveltime
=1:1:(size(route,2));
for
temp
=2:length(route)
%for
all
positions
except
for
depot
at
start
afstand
=afst(route(temp),route(temp-1));
dist
=dist
+afstand;
%route
distance
calculation
MATLAB Code 183traveltime(temp)
=ttime(route(temp),route(temp-1));
end;
%for
temp
ea(1)
=0;
arrival(1)
=0;
ea
=zeros(1,size(route,2));
%not
required,
slows
down
execution
arrival
=zeros(1,size(route,2));
%speeds
up
execution
lengte
=size(route,2);
for
temp
=2:lengte
%for
all
positions
except
for
depot
at
start
rt
=route(temp);
for
temp4
=1:NUMTW
%for
all
time
windows
(a)
tws(temp4)
=CUSTFILE(rt,5+3*(temp4-1));
%record
all
opening
times
(b)
end;
%for
temp4
%(c)
etw
=min(tws);
%earliest
time
window
found
(d)
ea(temp)
=arrival(route(temp-1))
+CUSTFILE(route(temp-1),4)
+traveltime(temp);
%arrival
time
calculation
if
ea(temp)
<etw
%if
arrive
to
early
arrival(rt)
=etw;
%wait
for
time
window
opening
elsearrival(rt)
=ea(temp);%else
serve
customer
end;
%if
ea
end;
%for
temp
for
temp
=2:lengte
%for
all
positions
except
for
depotat
start
rt
=route(temp);
for
temp2
=1:NUMTW
numtwfeas(temp2)
=1;
end;
for
temp2
=1:NUMTW
%for
all
time
windows
(e)
MATLAB Code 184if
(arrival(rt)
<CUSTFILE(rt,5+3*(temp2-1)))
|(arrival(rt)
>CUSTFILE(rt,7+3*(temp2-1)))
%if
not
in
atime
window
numtwfeas(temp2)
=0;
end;
%if
arrival
end;
%for
temp2
(f)
if
sum(numtwfeas)
==
0%if
no
time
window
can
accomodate
thedelivery
feas
=0;
break;
end;
if
feas
==
0;
%if
not
feasible
break;
%jump
out
of
temp
for
loop
end;
%if
feas
end;
%for
temp
rload
=routeload;
%save
route
load
rtime
=arrival(route(size(route,2)));
%save
route
time
end;
%if
routeload
%##########################################################################
%##########################################################################
%##########################################################################
E.1
1M
uta
tion
(muta
tion.m
)
function
[nummute]
=mutation(pm,gennum,popsize,nummute);
%MUTATAION
Performs
anon-uniform
heuristic
mutation
by
swappingcustomers
%within
thechromosome.
MATLAB Code 185global
NEWPOP;
global
NUMCUST;
mrate
=pm
*exp(-0.0001*gennum);
%calculate
non-uniform
mutation
rate
for
chrom
=1:popsize;
%for
all
customers
if
rand
<=
mrate
%probability
of
mutation
is
mrate
nummute
=nummute
+1;
p1
=fix((NUMCUST-1)*rand)+2;
%generate
random
positions
p2
=fix((NUMCUST-1)*rand)+2;
temp
=NEWPOP(chrom).tsp(p1);
%swap
customers
in
random
positions
NEWPOP(chrom).tsp(p1)=
NEWPOP(chrom).tsp(p2);
NEWPOP(chrom).tsp(p2)=
temp;
end;
%if
rand
end;
%for
cust
E.1
2D
ispla
yFin
alSolu
tion
(finalsol.m
)
function
[nummute]
=mutation(pm,gennum,popsize,nummute);
%MUTATAION
Performs
anon-uniform
heuristic
mutation
by
swappingcustomers
%within
thechromosome.
global
NEWPOP;
global
NUMCUST;
global
MUTRATE;
mrate
=pm
*exp(-0.01*gennum);
%calculate
non-uniform
mutation
rate
%mrate
=pm;
used
to
test
constant
mutation
rate
MUTRATE
=’var’;
%type
of
mutation
rate
used
MA
TLA
BC
ode
186
for chrom = 1:popsize; %for all customersif rand <= mrate %probability of mutation is mrate
nummute = nummute + 1;p1 = fix((NUMCUST-1)*rand)+2; %generate random positionsp2 = fix((NUMCUST-1)*rand)+2;temp = NEWPOP(chrom).tsp(p1); %swap customers in random positionsNEWPOP(chrom).tsp(p1) = NEWPOP(chrom).tsp(p2);NEWPOP(chrom).tsp(p2) = temp;
end; %if randend; %for cust
Appendix F
Solomon Benhcmarking Results
The best solutions found for the various Solomon problem instances are listedand are then compared to the best published results, as shown in AppendixB.
Table F.1: Best Found Solomon Benchmarking Results - C1
Found Best Published
Problem Vehicles Fitness Vehicles Fitness Difference
C101 10 880.48 10 827.30 +6.43%
C102 10 1293.10 10 827.30 +53.30%
C103 11 1445.39 10 828.06 +74.55%
C104 10 1306.79 10 824.78 +58.44%
C105 10 893.96 10 828.94 +7.84%
C106 10 1000.63 10 827.30 +20.95%
C107 10 1150.22 10 827.30 +39.03%
C108 11 1420.87 10 827.30 +71.75%
C109 10 1300.83 10 828.94 +56.93%
187
Solomon Benhcmarking Results 188
Table F.2: Best Found Solomon Benchmarking Results - C2
Found Best Published
Problem Vehicles Fitness Vehicles Fitness Difference
C201 3 724.56 3 591.56 +22.48%
C202 4 1040.89 3 591.56 +75.96%
C203 4 1320.54 3 591.17 +123.38%
C204 4 907.62 3 590.60 +53.68%
C205 3 728.15 3 588.88 +23.65%
C206 4 1179.89 3 588.49 +100.49%
C207 4 1184.90 3 588.29 +101.41%
C208 3 812.46 3 588.32 +38.10%
Table F.3: Best Found Solomon Benchmarking Results - R1
Found Best Published
Problem Vehicles Fitness Vehicles Fitness Difference
R101 20 2039.06 18 1607.70 +26.83%
R102 18 1948.20 17 1434.00 +35.86%
R103 14 1678.50 13 1207.00 +39.06%
R104 11 1384.83 10 980.01 +41.31%
R105 16 1699.00 15 1372.71 +23.77%
R106 13 1267.20 12 1252.03 +1.21%
R107 12 1490.40 10 1104.66 +47.94%
R108 11 1364.96 9 960.88 +36.61%
R109 13 1595.96 12 1013.16 +50.89%
R110 12 1465.48 11 1080.36 +35.40%
R111 12 1486.47 12 1083.05 +37.25%
R112 12 1394.10 10 953.63 +46.19%
Solomon Benhcmarking Results 189
Table F.4: Best Found Solomon Benchmarking Results - R2
Found Best Published
Problem Vehicles Fitness Vehicles Fitness Difference
R201 4 1770.70 8 1198.15 +47.79%
R202 4 1785.19 9 1057.56 +68.80%
R203 3 1672.00 5 922.38 +81.27%
R204 3 1537.50 5 791.78 +94.18%
R205 4 1576.62 3 994.42 +58.55%
R206 3 1530.50 3 833.00 +83.73%
R207 3 1537.00 3 814.78 +88.64%
R208 3 1473.20 2 726.75 +102.71%
R209 4 1508.10 3 855.00 +76.39%
R210 3 1599.44 3 939.34 +70.27%
R211 3 1367.80 6 820.31 +66.74%
Table F.5: Best Found Solomon Benchmarking Results - RC1
Found Best Published
Problem Vehicles Fitness Vehicles Fitness Difference
RC101 16 2017.77 15 1642.82 +22.82%
RC102 15 1931.70 15 1492.10 +29.46%
RC103 12 1640.24 11 1110.00 +47.77%
RC104 12 1692.08 10 1135.48 +49.02%
RC105 16 2246.18 16 1585.31 +41.69%
RC106 14 1860.68 12 1395.37 +33.35%
RC107 13 1774.60 11 1230.48 +44.22%
RC108 13 1746.50 10 1139.82 +53.23%
Solomon Benhcmarking Results 190
Table F.6: Best Found Solomon Benchmarking Results - RC2
Found Best Published
Problem Vehicles Fitness Vehicles Fitness Difference
RC201 5 2113.90 4 1249.00 +69.25%
RC202 4 2157.57 8 1151.46 +87.38%
RC203 4 1965.19 7 1018.09 +93.03%
RC204 3 1703.06 4 798.41 +113.31%
RC205 5 2168.00 9 1225.69 +76.88%
RC206 4 1832.02 5 1122.23 +63.26%
RC207 4 1802.02 6 1047.86 +71.97%
RC208 4 1784.90 3 828.14 +115.53%
