The Doctor Rostering Problem - Asser Fahrenholz

TECHNICAL UNIVERSITY OF DENMARK
The Doctor Rostering Problem
by
Asser Stubbe Fahrenholz , s032651
Department of Informatics and Mathematical Modelling
11. November 2008

Preface
This Master Thesis presents the work of Asser Stubbe Fahrenholz, February to November
2008. The work describes a solution for the doctor rostering problem of a small medical
practice housing six doctors, in St. Heddinge, Denmark.
Signed:
Date:
i

TECHNICAL UNIVERSITY OF DENMARK
Abstract
Department of Informatics and Mathematical Modelling
author: Asser Stubbe Fahrenholz , s032651
The Doctor Rostering Problem (DRP) covers the scheduling of doctors to shifts with
respect to a range of constraints, that ensure satisfied employees. The problem is first
modelled mathematically and then solved heuristicly by the use of two metaheuristics,
GRASP and Simulated Annealing. Both heuristics are described in theory and are tested
on real world data, as well as constructed problems that tests the various parameters of
the implementation as well as the effect of more or less constrained problems. A relaxed
version of the problem is solved in GAMS to optimality and the solution is compared to
the solution of the heuristics. The heuristics are implemented in a prototype of a software
program ready to use by the medical practice. Test results indicate that near-optimal to
optimal solutions are found and that the construction heuristic are the dominant factor
for the quality of the solutions.

DANMARKS TEKNISKE UNIVERSITET
Resumé
Institut for Informatik og Matematisk Modellering
forfatter: Asser Stubbe Fahrenholz , s032651
Læge planlægnings problemet dækker over tildelingen af vagter til læger, i forhold til
en række begrænsninger, som sikre de ansattes tilfredshed. Problemet modelleres først
matematisk og løses dernæst heuristisk ved hjælp af to metaheuristikker, GRASP og
Simuleret Udglødning. Teorien for begge heuristikke er beskrevet og begge er testet p˚a
et rigtigt problem instans, s˚avel som problem instanser der tester de forskellige param-
eter og effekten af mere eller mindre begrænsede problemer. En relakseret udgave af
problemet løses i GAMS til optimalitet og løsningen sammenlignes med resultater fra
heuristikkerne. Heuristikkerne implementeres i en software prototype, klar til brug af
lægepraksisen. Test resultater indikerer at nær-optimale til optimale løsninger bliver
fundet og at konstruktionsheuristikken er den dominerende faktor for kvaliteten af
løsningerne.

Acknowledgements
Foremost, I would like to thank my advisor, associate professor Jesper Larsen of the
Department of Informatics and Mathematical Modelling at the Technical University of
Denmark, for his advice and support. Always providing explanations when needed,
encouraging me and helping me keep focus.
I also wish to thank professor Jens Clausen, for his time and advice when my project
seemed to stall and needed to make further progress.
iv

Contents
Preface i
Abstract ii
Resumé iii
Acknowledgements iv
List of Figures viii
List of Tables ix
List of Algorithms x
1 Introduction 1
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 The Doctor Rostering Problem 3
2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 The staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Shift types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Rolling Days Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Literature review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 A mathematical model for the DRP 8
3.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Hard constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Soft constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 The objective function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Problem size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Solving the DRP 15
4.1 DRP complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Exact methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Heuristics for the DRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
v

Contents vi
4.3.1 A construction heuristic . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 Neighborhoods and Local Search . . . . . . . . . . . . . . . . . . . 20
4.3.3 The GRASP metaheuristic . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4 The Simulated Annealing metaheuristic . . . . . . . . . . . . . . . 25
4.3.5 Heuristic bounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Heuristic implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.1 The data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.2 A partial enumeration . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.3 Construction heuristic . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.4 Metaheuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.5 Implementation optimisations . . . . . . . . . . . . . . . . . . . . . 30
5 Optimal solution 31
5.1 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 The DRP Program 34
6.1 The user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 The Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.1 Measuring the quality of the solution . . . . . . . . . . . . . . . . . 40
6.3 End user feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4 From prototype to release candidate . . . . . . . . . . . . . . . . . . . . . 41
7 Metaheuristic tests 42
7.1 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.2 Results and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.1 Instance parameter effects . . . . . . . . . . . . . . . . . . . . . . . 44
7.2.2 Metaheuristic parameter effects . . . . . . . . . . . . . . . . . . . . 46
7.2.3 Metaheuristic performance . . . . . . . . . . . . . . . . . . . . . . 48
7.3 Test conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8 Future considerations 53
8.1 User-added rules - relation/logic of shifts . . . . . . . . . . . . . . . . . . . 53
8.2 Neighborhood delta function and feasibility . . . . . . . . . . . . . . . . . 54
8.3 GRASP learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.3.1 GRASP stop criterion . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.4 SA extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9 Conclusion 57
A Implementation 59
A.1 Neighborhoods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.1.1 Inversion neighborhood . . . . . . . . . . . . . . . . . . . . . . . . 59
A.1.2 Rotation neighborhood . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2 Construction heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.3 GRASP metaheuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.4 Simulated Annealing metaheuristic . . . . . . . . . . . . . . . . . . . . . . 67
A.5 Choosing the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Contents vii
A.5.1 Shift assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.5.2 Permutations of size k chosen from N elements . . . . . . . . . . . 72
A.5.3 Day assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B GAMS Model 76
B.1 The night, evening and wishes . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.2 The GAMS model and report . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.3 The solved model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.3.1 GAMS solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.3.2 The best greedy solution . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3.3 The best GRASP solution . . . . . . . . . . . . . . . . . . . . . . . 86
C Tests 87
C.1 Test instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
C.1.1 Instance 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.1.2 Instance 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
C.1.3 Instance 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.1.4 Instance 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C.1.5 Instance 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1.6 Instance 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
C.1.7 Instance 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
C.1.8 Instance 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
C.1.9 Instance 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.1.10 Instance 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.2 Summarized results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.2.1 RCL performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.2.2 Enum effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.2.3 Weights effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.2.4 Iterations effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.2.5 Highlighted results . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Bibliography 117

List of Figures
4.1 The transformation chain from SAT to Timetable Design . . . . . . . . . 16
4.2 Various types of RCL parameters . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Local and global optima . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 The rotation principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 The inversion principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 The implementation of the schedule . . . . . . . . . . . . . . . . . . . . . 27
4.7 Heuristics inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Comparison of heuristic performances for the GAMS problem . . . . . . . 33
6.1 The main window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 The file menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 Microsoft Excel workbook containing the night and evening shifts . . . . . 36
6.4 The main window w. imported shifts . . . . . . . . . . . . . . . . . . . . . 37
6.5 The settings menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.6 The weights window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.7 The codes window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8 RDO enabled and disabled . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.9 The main window w. generated schedule . . . . . . . . . . . . . . . . . . . 40
7.1 GRASP performance: Test 0 . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 SA performance: Test 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3 GRASP performance: Test 5 . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.4 GRASP performance: Test 6 . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.5 SA performance: Test 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.6 SA performance: Test 2 and 5 . . . . . . . . . . . . . . . . . . . . . . . . . 52
C.1 Optimal solution for test 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.2 Example of the decreasing temperature . . . . . . . . . . . . . . . . . . . 116
viii

List of Tables
2.1 Rolling days off, NDO: no day off . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 The initial solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Test instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Test instance groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Test instance results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.4 RCL effect: Test 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.5 RCL effect: Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.6 RCL effect: Test 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.7 RCL effect: Test 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.8 RCL Effect: All tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.9 Enumeration effect: All tests . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.10 Enumeration effect: Test 4, RCL 1 . . . . . . . . . . . . . . . . . . . . . . 47
7.11 Enumeration effect: Test 7, RCL 50 . . . . . . . . . . . . . . . . . . . . . 47
7.12 Weights effect: All tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.13 Weights effect: Test 0, RCL 1 . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.14 Weights effect: Test 4, RCL 1 . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.15 Iterations effect: All tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.1 Solution found by GAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.2 Best greedy, RCL 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3 Best GRASP, RCL 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
ix

List of Algorithms
4.1 Adaptive greedy - require: RCL parameter p, schedule S . . . . . . . . . . 19
4.2 Local Search - require: schedule S . . . . . . . . . . . . . . . . . . . . . . 22
4.3 GRASP - require: RCL parameter p . . . . . . . . . . . . . . . . . . . . . 24
4.4 Simulated Annealing - require: Schedule S, start temperature T . . . . . 26
8.1 Delta function H0 - require: schedule S . . . . . . . . . . . . . . . . . . . 55
x

Chapter 1
Introduction
During the last five decades, growing interest in optimisation and efficiency has put focus
on developing, not just valid schedules, but good schedules. Even though computerisa-
tion and mathematics has come to the aid of a lot of workplaces, many still use manual
scheduling to satisfy both production needs as well as employee happiness. Without the
aid of decision support tools, the creation of a good solution for any non-trivial problem,
takes overview, coordination and most importantly, time. In health care institutions,
ward managers usually spends upwards 10 to 20 hours each quarter, or even monthly,
to plan a good schedule, and even then, some needs are not met. Finally, measuring
the quality of the schedule is troublesome, due to the constraints and the number of
decisions that needs to be made.
The medical practice in St. Heddinge houses six doctors, taking care of patients in the
immediate vicinity, unless the patient needs hospitalisation. At least one of these six
doctors must be available for treating acute patients during working hours. The Doctor
Rostering Problem (DRP) is the problem of assigning one or more doctors to noon and
afternoon shifts, in such a way that certain shift- and employee-requirements are met.
In this thesis, I take a practical approach to solving the problem.
1.1 Purpose
The purpose of this thesis is to:
1. Develop an objective function or cost function measuring the value of solutions for
the DRP.
2. Provide a solution, within a relatively short amount of time, to the DRP.
1

Chapter 1. Introduction and problem context 2
3. Provide a software implementation that will allow the end user to find solutions.
1.2 Structure
An introduction to the Doctor Rostering Problem (DRP) and a literary review is found
in chapter 2. Chapter 3 contains a mathematical model for the hard and soft con-
straints. Through chapter 4, the problem complexity is analysed and the discussion of a
construction heuristics, the GRASP framework and the Simulated Annealing algorithm
for solving the problem is included along with the implementation of these methods. In
chapter 5 a relaxed DRP problem is solved in GAMS and the solution is compared to
solutions found by the heuristics. Chapter 6 describes the implementation of the DRP
Program that will allow the medical practice to create their own schedules. In chapter
7 the performance of the heuristics is tested on a range of problems and the results
are discussed. Through chapter 8, a discussion of future considerations and extensions
to the solutions is found. Finally, in chapter 9 I summarise the conclusions from each
individual chapter in this thesis.

Chapter 2
The Doctor Rostering Problem
In this chapter, I present the background for the problem, the specific problem concepts
and review literary sources that have served as inspiration to this project.
2.1 Background
Every four months, one of the doctors at the medical practice in St. Heddinge 1 , schedules
the treatment of the acute patients in the immediate vicinity. This treatment must be
done by one or two of the six doctors, subject to higher workloads after weekends and
holidays and before holidays (somehow, people can avoid getting ill during holidays).
The scheduling is done with no computer aided support, takes approximately five to ten
hours and is tedious due to required gathering of available hours from each individual
member of the workforce. The information tells the planner which doctor is available
when, during the next four months. The planner must then assign the doctors to shifts
in such a way that certain shift-patterns are avoided and such that every member of the
workforce receives equally many shifts. This approach to schedule planning, performed
by an employee without decision support tools, is often called self-scheduling (Burke
et al. [5]).
The schedule planned by the doctor is chosen to be non-cyclical, or flexible (Silvestro
and Silvestro [22]), due to the medical practice being a private one, where the members
of the workforce prefer ad-hoc schedules.
This problem is similar in nature to the Nurse Scheduling Problem (NSP) (or Staff
Scheduling Problem). NSP is the problem of assigning a fleet of nurses to shifts of
varying types, in a period of time. The assignments must respect both personal wishes
1 South-east of Køge, Denmark
3

Chapter 2. The Doctor Rostering Problem 4
along with holidays and union contract stipulations. This problem is the main source of
inspiration for this project.
Another problem that shows similar features is the Gotlieb Class-Teacher Problem (or
Timetable Design Problem) of assigning teachers to classes, in such a way that every class
has one teacher and no teacher has two classes at the same time. Very little material
has been found on this, but an important contribution by this field, shall be noted in
chapter 4.
2.1.1 The staff
As opposed to a public health care institution, where the staff is subject to a range of
stipulations and union contracts, the planner in this project has a much higher degree of
control over the work flow of the institution. As the private institution is not subject to
the same form of bureaucracy (due to the small size and being private), the constraints
are not based upon public requirements, but rather personal requests and experiences.
This is a direct consequence of the joint owners of the office controlling their own working
hours and thereby controlling their pay.
In typical NSP, the staff consist of a large number of nurses, divided into categories
based on their qualification level and responsibilities. Several degrees of qualification can
exist allowing a lower qualified member of the staff to be replaced by a higher qualified
member. The staff can also be divided into full time or part time employees and some
NSPs require higher qualified members to supervise the lower qualified members. In the
context of this project, the staff that needs assigning are not divided into qualification
groups. Due to decisions made in the practice, any interns/nurses in the practice will
be assigned shifts manually.
2.1.2 Shift types
This project deals with four shift types: night-, noon-, afternoon- and evening shifts.
The night- and evening shifts are given through a public body and can not be changed,
leaving the noon- and afternoon shifts to be assigned. One or two doctors must be
assigned to these two shifts.
A standard NSP contains the three shifts: night-, day- and evening shifts, and most
often requires more than one nurse to be assigned to the shift.

Chapter 2. The Doctor Rostering Problem 5
Doctor 1 2 3 4 5 6
Week 1 Tuesday NDO Wednesday Thursday Friday Monday
Week 2 NDO Wednesday Thursday Friday Monday Tuesday
Week 3 Wednesday Thursday Friday Monday Tuesday NDO
Week 4 Thursdag Friday Monday Tirsdag NDO Wednesday
Week 5 Friday Monday Tirsdag NDO Wednesday Thursdag
Week 6 Monday Tirsdag NDO Wednesday Thursdag Friday
Table 2.1: Rolling days off, NDO: no day off
2.2 Rolling Days Off
A specific requirement of this project is rolling days off (RDO). These define which
weeks a doctor gets a day off and which weeks contains no day off (NDO) for each
doctor. Table 2.1 illustrates the concept of rolling days off.
A key point of RDO is the fact that all doctors receive weekends where they have both
the predating Friday and the postdating Monday off.
The RDO as a constraint is omitted from the mathematical model of this problem and
is instead implemented as a program mechanism.
2.3 Literature review
Previous work on the nurse scheduling problem (NSP) has been covered by many ap-
proaches, taking different angles and perspectives throughout the problem environment.
In this section, I briefly review articles that has served as inspiration to this project.
Nonobe and Ibaraki [18] applies a general weighted constraint satisfaction problem
(WCSP) solver, using a Tabu Search (TS), to a range of problems, incl. the NSP.
Also applying a weight control mechanism to each iteration of TS works well for them.
They choose to handle hard and soft constraints on the same level of processing.
Dias et al. [7] deals with a relatively large problem. They apply both a Genetic Algorithm
(GA) heuristic and a TS for solving a problem with over 1500 nurses, 30 supervisory
nurses and 30 wards and finds that the two heuristics performs equally well, with one
more time efficient and slightly worse results than the other and vice versa.
In Bard and Purnomo [2] the authors discuss the issue of sudden shortages appearing due
to the fluctuation in patients needing health care. The problems handled are relatively
large, scheduling more than 120 nurses.

Chapter 2. The Doctor Rostering Problem 6
Resende and Ribeiro [20] and Resende and Feo [19] considers the Greedy Random-
ized Adaptive Search Procedure (GRASP). The GRASP described by the authors is
the main source of inspiration for the metaheuristic chosen in this project. They also
implement various improvements to their GRASP, incl. reactive GRASP, automated
RCL adjustments, variable neighborhoods, path-relinking, optimising memory-usage as
well as allowing for efficient cooperative parallel strategies. They show that the use of
GRASP along with these improvements can significantly improve the time required to
find a near-optimal solution compared to basic GRASP. Where Resende and Ribeiro
[20] investigates the use of GRASP on the set covering problem, Resende and Feo [19]
covers the effect of various hybridisations to GRASP.
Burke et al. [5] reviews the state of Nurse Scheduling Problem research. In their review,
they describe how different authors have approached the NSP, including bibliographic
reviews and research papers on various algorithms for solving the NSP. Silvestro and
Silvestro [22] argues that self-scheduling
. . . can easily lead to over- or understaffing, that the schedule is made for
the convenience of staff, and that there are no formal procedures for conflict
solving.
Opposite to this, Hung [14] argues that self-scheduling leads to greater staff-satisfaction
and improves co-operation. Both are different approaches to viewing the subject. Sil-
vestro and Silvestro [22] concludes that the benefits of self-scheduling relies on the size
and complexity of the problem. It can work well in smaller wards where the constraints
remain relatively simple. Burke et al. [5] also notes how finding the optimal solution is
largely meaningless, when most hospital administrators want to get high quality results
in a short amount of time. The administrators prefer quick generation of schedules that
satisfy all hard constraints and as many soft constrains as possible. Another observation
made by Burke et al. [5] is that optimal solutions in the literature tend to simplify the
problem, making them inapplicable for real world problems.
In their section covering TS, they note how Dowsland [8] allows search to go back and
forth from the feasible region, which is an important feature as todays problems in large
health care institutions tend to be nearly impossible to solve, while maintaining fea-
sibility. Contrary to this, Burke et al. [3] develops a model in which search remains
in the feasible part of the solution space. They describe PLANE, a commercial nurse
rostering system which employs a hybrid TS, embodying a TS coupled with either a
diversification mechanism or a shuffling technique to model human scheduling behavior.
Comparing their hybrid algorithm to a basic Steepest Descent (SD) search- or TS al-
gorithm, they find that their hybrid search algorithm performs overall better than the

Chapter 2. The Doctor Rostering Problem 7
original algorithms. Burke et al. [3] applies the model to several hospitals in Belgium,
taking a dynamic, user-defined, set of constraints into account. Burke et al. [5] ends
their review by concluding that very few of the solutions are applicable to real world
problems and highlights a range of areas they believe would benefit from more research.
These includes Robustness (if a person calls in sick, most solutions suffer a chain-reaction
of disruptions) and Ease of Use (no hospital administrator is able to set the parameters
for any algorithm designed to solve a problem), noting how more research is needed on
parameter-less algorithms.
The varying nature of the problems solved in the literature, including the size of the
staff, the complexity and amount of constraints, the type of shifts, demands, preferences
and qualifications to name a few, indicates that NSP can not be classified as only one
problem. For this to be the case, a uniform model of the problem is needed.

Chapter 3
A mathematical model for the
DRP
This chapter describes the mathematical model for the doctor rostering problem stated
by the medical practice. A number of constraints was given; some which has to be satis-
fied (called hard constraints), and some which are not essential, but are preferably and
as much as possible satisfied (the soft constraints). The hard constraints also partitions
the solution space into feasible and infeasible. A solution is said to be feasible when no
hard constraints are violated and infeasible otherwise. In this project, I model the DRP
as a minimisation problem.
3.1 Parameters
The constraints have all been thoroughly discussed with the medical practice throughout
the project. It should be noted that these all stem from personal point-of-views, wishes
etc. as the medical practice is a private one, and not a public institution, which would
no doubt be heavily influenced by union-restrictions and/or laws.
In describing the constraints, the following binary variable is used:
xijk =
1 if on day i, shift j, the doctor is k
0 otherwise
And the following parameters are introduced:
8

Chapter 3. The model and design 9
⎧
1 if on day i, doctor k has a shift
⎪⎨
j outside the house. It follows that
bijk =
the doctor is not available for the surrounding shifts
⎪⎩ 0 otherwise
⎧
⎪⎨
sij =
⎪⎩
⎧
1 if on day i, doctor k has
⎪⎨
requested shift j off. The doctor is then
cijk =
available for the surrounding shifts
⎪⎩ 0 otherwise
l if on day i, shift j must be assigned 1+l
doctors. This happens on noonshifts following weekends and
holidays, and afternoonshifts preceding holidays
0 otherwise
The index j defines: 1: Night shift, 2: Noon shift, 3: Afternoon shift, 4: Evening shift.
Furthermore, shift j is said to be an assignment shift (as) if it doesn’t lie on a holiday,
nor a weekend and is not a night- nor evening shift.
Let n be the number of days in the problem, and m be the number of doctors:
i ={1, 2 . . . n}
k ={1, 2 . . . m}
In the following, I assume the schedule starts on a Monday, that the index of this day
is 1 and that the schedule ends on a Sunday and the index of this day is n.
I also define the sets of days:
3.2 Hard constraints
M : i%7 = 1 ∀i
F : i%7 = 5 ∀i
This section describes the constraints that must be satisfied for the solution to be feasible:

Chapter 3. The model and design 10
H0 No doctor may take two shifts in a row:
xijk + x i(j+1)k ≤ 1 ∀ i, j = {1, 2, 3}, k (H0)
H1 After an evening shift, a doctor cannot have a noon shift on the following day:
bi4k + x (i+1)2k ≤ 1 ∀ i = {1 . . . n − 1}, k (H1)
H2 Following a night shift, a doctor cannot have a noon shift nor an afternoon shift:
bi1k + xi2k + xi3k ≤ 1 ∀ i, k (H2)
H3a Doctors having a shift outside the house cannot have one in the house simultane-
ously:
H3b Requests for a shift off must be granted:
H4 Demands must be met:
xijk + bijk ≤ 1 ∀ i, j, k (H3a)
xijk + cijk ≤ 1 ∀ i, j, k (H3b)
m
xijk = 1 + sij ∀ i, j (H4)
k=1
H5 No afternoon shift before an evening shift:
3.3 Soft constraints
xi3k + bi4k ≤ 1 ∀ i, k (H5)
The soft constraints does not require validity for the solution to be feasible, though the
quality of the solution improves the fewer soft constraints are invalid. Soft constraints are
commonly modelled in the evaluation or objective function, as a sum of the penalties
that arise when not satisfying the individual constraints. Each soft constraint has a
weight δ attached, allowing the user to prioritise certain constraints over others.
I now introduce the following variables:

Chapter 3. The model and design 11
⎧
⎪⎨ 1 if rule o is violated on
yiko =
⎪⎩
0
day i for doctor k
otherwise
⎧
⎪⎨ 1 if rule 3 is violated on day i
yijk3 =
⎪⎩
0
shift j for doctor k
otherwise
⎧
⎪⎨ 1 if the LHS of rule o is zero,
tiko =
⎪⎩
0
allows yiko to remain zero too
otherwise
⎧
⎪⎨ 1 if the LHS of rule 3 is zero,
tijk3 =
⎪⎩
0
allows yijk3 to remain zero too
otherwise
The y-variables are used as counting variables, indicating how many violations of a soft
constraint the doctor has. The t-variables are used for the specific case of the left hand
side of the equation is zero. This variable, and the fact that we are dealing with a
minimisation problem, allows the y-variable to remain zero.
The following are the soft constraints that apply when constructing a model for the
DRP:
B0 No doctor should have both the Monday noon shift and the following Friday afternoon
shift in the same week:
min δB0
i
yik0
∀ k
st. xi2k + x (i+4)3k = 1 + yik0 − tik0
∀ k, i ∈ M
(B0)
B1 No doctor should have both the Friday afternoon shift and the following Monday
noon shift:
min δB1
i
yik1
∀ k
st. xi3k + x (i+3)2k = 1 + yik1 − tik1
∀ k, i ∈ F ∧ i < n − 3
(B1)

Chapter 3. The model and design 12
B2 All shifts assigned should be divided equally among all doctors.
δB2
⎛
⎝max
k
i,j∈sa
xijk − min
k
i,j∈sa
xijk
⎞
⎠ (B2)
B3 No doctor should have two noon shifts nor two afternoon shifts two days in a row:
⎛
min δB3 ⎝
i,j
yijk3
⎞
⎠ ∀ k
st. xijk + x (i+1)jk = 1 + yijk3 − tijk3
∀i = {1 . . . n − 1}, j ∈ sa, k
B4 No doctor should have the afternoon shift the day after an evening shift:
min δB4
i
yik4
∀ k
st. bi4k + x (i+1)3k = 1 + yik4 − tik4
∀i = {1 . . . n − 1}, k
B5 No doctor should have the noon shift the same day as an evening shift:
min δB5
i
yik5
∀ k
st. bi4k + xi2k = 1 + yik5 − tik5
∀i, k
(B3)
(B4)
(B5)
B6 No doctor should have the noon shift the day after an afternoon shift and vice verca:
min δB6a
i
yik6a
∀ k
st. xi3k + x (i+1)2k = 1 + yik6a − tik6a
min δB6b
∀i = {1 . . . n − 1}, k
i
yik6b
∀ k
st. xi2k + x (i+1)3k = 1 + yik6b − tik6b
∀i = {1 . . . n − 1}, k
(B6a)
(B6b)

Chapter 3. The model and design 13
3.4 The objective function
The constraints described in the two previous sections is the complete list of constraints
as the medical practice has described them.
The objective function value of a schedule s is the collective sum of the above described
soft constraints and is denoted z(s):
min z(s) = δB0
+ δB2
i
⎛
yik0
⎝max
k
⎛
+ δB3 ⎝
+ δB5
+ δB6b
i,j
i
i
+ δB1
i,j∈sa
i
yik1
xijk − min
k
⎞
⎠ + δB4
yijk3
yik5
yik6b
+ δB6a
i
∀k
i
i,j∈sa
yik4
yik6a
xijk
⎞
⎠
(Z(S))
An objective function value of 0 means that we have found an optimal solution for any
DRP problem. If the objective function value is positive, it can still be optimal, but
under any circumstances means that one or more soft constraints are invalid. Leaving
the weight, δ, of all the soft constraints equal to 1 means that we can derive from an
objective function value of i.e. 4, that soft constraints are invalid in 4 cases. If we
choose to alter the weights of the rules, the same still applies, but the transparency of
the objective function value decreases.
The objective function thus determines the value of solutions for the DRP and is used
by optimal solvers such as GAMS (see chapter 5) and the heuristics in the next chapter,
which will describe how solutions can be found for the DRP.
3.4.1 Problem size
The amount of variables with 4 shifts per day, 6 doctors and 100 working days:

Chapter 3. The model and design 14
|V ars| = |Shifts| · |Doctors| · |Schedule|
= 4 · m · n = 4 · 6 · 100
= 2400
Given 10 constraints, the total number of constraints for this problem becomes:
|Equations| = |Shifts| · |Doctors| · |Schedule| · |Constraints|
= 4 · m · n · 10 = 4 · 6 · 100 · 10
= 24000
Commonly, problems are big if they have more than 2500 variables and 10000 equations.
This is not ruling out that any larger problems can not be solved, as techniques (i.e.
Cutting-plane method, Branch and cut) exist that, using the constraints, can limit the
search region of the problem. A topic not addressed in this project.

Chapter 4
Solving the DRP
In this chapter, the reader is presented with several methods for solving the DRP. First,
the complexity of the problem is analysed and based on this, an approach is chosen. For
each chosen method I briefly discuss the background, the theory and common extensions.
In the last section I cover how they were implemented in this project.
4.1 DRP complexity
Complexity theory investigates how algorithms scale when the problems given as input
to the algorithms scales. Problems are divided into two main complexity classes, the P
and NP classes. The two classes represent the problems that can be solved in polynomiel
time and those that can be solved nondeterministicly in polynomiel time. The NP-class
also have the property that a postulate in the form of a Yes/No question is verifiable in
polynomiel time. Another class is NP-hard problems, that are defined as those problems
which all NP-problems can be transformed into. NP-hard problems are, put another way,
those which are at least as hard as NP problems (but may be harder). NP-hard problems
does not need to be a postulate in the form of a Yes/No question. Some problems are
also NP-complete and are defined as those which are both NP-hard and are also NP.
With these definitions in mind, one should be aware of the complexity of the problem
for which a solution is sought. The NP-complete problems should be given special
attention, as the time to solve these grow exponentially with the size of the problem.
These problems are also called intractable. Meaning, exploring the entire feasible region
of any but the smallest problems, is impossible in any lifetime.
This means, that if DRP is NP-complete, we can start looking for approximations or
partial solutions since there is little chance an algorithm can be developed able to solve
15

Chapter 4. Solving the DRP 16
it in a short amount of time (Hopcroft et al. [13]). If the DRP problem is NP-complete
and an algorithm does exist, able to solve the problem deterministically in polynomial
time, then it would follow that all NP-complete problems are solvable deterministically
in polynomial time and so P = NP , a statement that has been investigated for the last
50 years without any definite results 1 . As such, it is widely believed that P = NP , since
no polynomial time algorithms has been devised to solve an NP-complete problem.
To prove that a problem is NP-complete, one can transform an already known NP-
complete problem (in polynomial time) to the problem for which a proof is sought.
Fortunately, a problem, very close to the DRP, has already been proven NP-complete. It
is stated in Garey and Johnson [10] as [SS19], referring to Even et al. [9] who transformed
the 3SAT (Karp [15]) problem, which again was transformed from the SAT problem
(Cook [6]). The chain of transformations is shown in figure 4.1.
Figure 4.1: The transformation chain from SAT to Timetable Design
Garey and Johnson [10] defines the instance as: A set H of ”work periods”, a set C
of ”craftsmen”, a set T of ”tasks”, a subset A(c) ⊆ H of ”available hours” for each
craftsman c ∈ C, a subset A(t) ⊆ H of available hours for each task t ∈ T , and, for each
pair (c, t) ∈ C × T , a number R(c, t) ∈ Z + 0
of ”required work periods”.
Applying this to the DRP: The set H defines the work periods in which shifts must lie,
the set C is the set of doctors and the set T is the shifts. A(c) defines when a doctor
is available, which in this project is defined by all the hard constraints except H4. A(t)
describes when a shift can be performed and R(c,t) defines how long a shift t takes
for doctor c to perform. In this project R(c, t) = 1 ∀ c, t. This instance describes a
timetable for completing all shifts in time. The Timetable Design problem can thus be
transformed to the DRP and hence, DRP is NP-complete. This means that no known
algorithm can deterministically find an optimal solution to the DRP in polynomiel time.
4.2 Exact methods
Given a set of constraints, as described in chapter 3, the goal of finding a solution to the
problem can be accomplished by using an optimal solver such as GAMS. As concluded
above, solving the DRP to optimality can take an exponential amount of time. Due to
1 One of the Millennium Problems : Claymath.org/millennium/

Chapter 4. Solving the DRP 17
this, only a subproblem of the DRP is tried and tested in an optimal solver (see chapter
5).
To overcome the problem of exponential search time, approximations or heuristics are
used.
4.3 Heuristics for the DRP
Heuristics are trial-and-error methods, using some evaluation or objective function to
evaluate solutions. It is important to note that optimality of the results obtained from
heuristics can not be guaranteed and a measure of how good the heuristic is, can be hard
to find. The main goal of a heuristic is to find high quality or near-optimal approxima-
tions to solutions of a computationally difficult problem, in a relatively short amount
of time. A key part of heuristics is the fact that they are tailored specifically for the
problem to which they are applied, using problem specific knowledge to guide the search
for better solutions. Heuristics can be either deterministic, meaning, given the same
input, then the heuristic will produce the same result every time, or non-deterministic
and are non-exhaustive, since if they were exhaustive, they could be classified as an
exact method, and not an approximation.
Different types of heuristics exist to reach a solution. First, there are constructive- or
construction heuristics, that builds a solution from scratch. These are considered fast
as they are often only used once or in a one-pass manner. The second type of heuristics
are optimisation heuristics, such as the class of Local Search (LS) heuristics, exploring
the solution space around a given solution, using a well defined function. The last
notion of heuristics that will be addressed here, are Metaheuristics. These are a class of
more general, in some sense advanced or sophisticated, heuristics, using some algorithm-
dependent mechanism to guide the search for a better solution. In this project, three
heuristics will be addressed; a greedy construction heuristic, the Greedy Randomized
Adaptive Search Procedure metaheuristic and the Simulated Annealing metaheuristic.
Due to the structure of this problem, I (similar to Dowsland [8]) allow infeasible solutions
in the heuristics, thus not only seeking global optimum of objective function value, but
also seeking minimisation of violations of hard constraints. Minimising these violations
is of higher priority than the objective function value.

Chapter 4. Solving the DRP 18
4.3.1 A construction heuristic
The initial solution is the basis for optimisation and as such, is an important part of any
heuristic modelled to solve this problem. One goal of a construction heuristic is often
to be fast as to allow time to be focused on other parts of the process. In the context of
this DRP, several construction heuristics can be identified:
Zero solution is a straightforward and easy solution to construct and consists of noth-
ing but an empty schedule. This is a very fast (O(1)) solution to generate but is
infeasible (over all shifts) due to constraint H4 on page 10.
Random solution consists of randomly assigning doctors to shifts that are unassigned,
until all shifts are assigned a doctor. This can be done by assigning each shift a
random doctor, or, for each doctor, assigning that doctor to approximately n
m
random shifts. The random solution does not guarantee feasibility and is worse,
in running time (O(n)), than the zero solution.
Greedy solution is based on the concept of choosing what looks best, given a candi-
date set and a selection function, here and now. That is, it bases its choice upon
knowledge of the present and past shifts, but not the future ones as they have not
yet been assigned a doctor. It makes no reconsideration of past choices, contrary
to e.g. dynamic programming algorithms, that bases decisions on all previous de-
cisions and as such, may reconsider the past. Several notions of the candidate set
are used in the literature, but in the context of this project, I define the Local
Candidate List as a list unique to each shift consisting of all doctors, ordered by
their heuristic value when assigning them to the given shift. The greedy algorithm
picks the best doctor from the candidate list and assigns it to the shift at hand.
The basic version of the greedy is deterministic, i.e. given the same input, greedy
always returns the same output. In an adaptive greedy algorithm (Resende and
Ribeiro [20]), the doctor is randomly chosen from the local candidate list. To rule
out the possibility of choosing the worst doctor for the shift, I introduce the Re-
stricted Candidate List as the n best, measured by either a heuristic value or by a
percentage, elements in the candidate list. Figure 4.2 on the next page illustrates
various kinds of RCL parameters for a minimisation problem. Another option for
the RCL list, is to define it as a list of ordered pairs, consisting of all unassigned
shifts coupled with the doctor that has the highest heuristic value when assigned to
the specific shift. This option was discarded due to the time required to construct
the list being O(n · m) and the fact that the list would have to be reconstructed
for each shift. The greedy solution does not guarantee feasible solutions, though
the odds has improved vastly, from that of the random solution.

Chapter 4. Solving the DRP 19
(a) RCL: 50% elements
(rounded
down)
(b) RCL: 5 elements
(c) RCL: Value
below 5.0
Figure 4.2: Various types of RCL parameters
(d) RCL: Value
below 60 % of the
worst
The various construction heuristics all bring advantages and disadvantages. These are
outlined in table 4.1.
Feasible Construction Evaluation
Zero solution No O(1) O(1)
Random solution Perhaps O(n) O(n)
Greedy solution Perhaps O(n · m) O(n)
Table 4.1: The initial solutions
Out of the described heuristics, the adaptive greedy algorithm is chosen as the con-
struction heuristic of this project, along with the RCL parameter type shown in figure
4.2(a). This type of RCL parameter ensures that a certain degree of randomisation can
be achieved, contrary to the RCL parameter shown in figure 4.2(b), where an absolute
size is chosen (this can not ensure a certain degree of randomisation when the size of
the RCL varies).
The adaptive greedy algorithm is outlined in algorithm 4.1.
Algorithm 4.1 Adaptive greedy - require: RCL parameter p, schedule S
for all Unassigned Shift in S do
RCList = {}
for all Doctors do
RCList ← RCList ∪ V alueOf(Doctor, Shift)
end for
Sort(RCList)
Restrict RCList according to p
Pick a doctor randomly from RCList and assign it to Shift
end for

Chapter 4. Solving the DRP 20
Given a schedule, a need to improve upon this schedule arises. This is where neighbor-
hoods comes in.
4.3.2 Neighborhoods and Local Search
To guide the search in finding better solutions, I introduce the well known term Neigh-
borhoods. A neighborhood is defined as:
N(S) = { solutions obtained by applying a single local transformation to S }
A neighbor is a potential replacement for a solution and need only vary from the solution
at hand by a single element. The whole set of replacements produced by some change
or function on the solution is called a neighborhood. The process of moving from one
solution to another in its basic form, is called Local Search (LS) and is, if exhaustive,
able to find a local optimum. Figure 4.3 shows how moving through the solution space
may increase and decrease the heuristic value of the solution. Only accepting solutions
with higher Z(S) is called hill climbing (and analogously hill descending).
Figure 4.3: Local and global optima
For any given problem, several possible neighborhoods often exist. The neighborhoods
identified in this thesis are, thanks to the nature of this problem, two very simple
functions:
Rotation is moving the doctor of all shifts to another shift in the set, such that all
doctors are moved in rotation. The principle is depicted in figure 4.4 on the next
page
Inversion is for all selected shifts, to populate the shifts with another doctor than the
one that is originally assigned to it. Figure 4.5 on the following page illustrates the
principle. One could pass an empty schedule to a Local Search algorithm using

Chapter 4. Solving the DRP 21
Figure 4.4: The rotation principle
this neighborhood and it would then populate the shifts itself. This would then
be similar to the random initial solution.
Figure 4.5: The inversion principle
For each of them, it applies that a random set of shifts are selected, upon which the
function is carried out.
One immediate advantage of these neighborhoods, is that they are simple and easy to
implement. The implementation of these can be found in appendix A.1.
Nielsen [17] also implements the inversion and rotation, which is similar to the insert,
delete and replace moves in the neighborhoods chosen in Meisels and Schaerf [16]. Both
rotation and inversion can be translated to a combination of replace moves. Other than
these sources, very few authors in the literature describe their neighborhood functions
in-depth. This may be due to how the structure and nature of problems often limits the
choices in neighborhoods to a degree, where the choice seems obvious.
It is important to recognise that the generation of neighbors is a factor in the running
time of the entire search. As such, I have placed an upper limit on how many shifts are
randomly selected and used in the neighborhood.

Chapter 4. Solving the DRP 22
Since the two neighborhoods described above are both based on a set of randomly
chosen shifts and we are dealing with a relatively large problem, search exhaustion of
the neighborhoods in any reasonable amount of time is impossible. As one of the goals
of this project is to reach a relatively good solution within a relatively short amount of
time, LS needs another stop-criterion. Two very common criteria are time and iterations
(neighborhoods explored), which is implemented in this project. A less common criteria,
also worth noting, is stopping LS after a certain amount of time has passed without any
improvements to the incumbent solution.
For a minimisation problem algorithm 4.2 lists the basic LS.
Algorithm 4.2 Local Search - require: schedule S
S ← S
while ¬Stop do
S ← choose S from N(S)
if z( S) < z(S) then
S ← S
end if
end while
If the N(S) function selects random neighbors, then the LS in algorithm 4.2 is called
a random improving search, moving to the first (randomly selected) solution that im-
proves the value of the incumbent. Contrary to this approach, there is also the best
improving search, where all members of the neighborhood is inspected and the best is
chosen (Nielsen [17], Resende and Feo [19]) and first improving, where the neighbors are
investigated systematically and the first one to improve the incumbent is chosen (Nielsen
[17]).
When LS is only accepting better solutions, it can suffer the fate of getting stuck in
a local optimum. To get out of these, and hopefully move on to a global optimum,
several techniques exist that allows Local Search to leave a better solution for a worse,
in hope of eventually finding a new best solution. Three such techniques are GRASP,
the Simulated Annealing (SA) algorithm and the Tabu Search (TS). The TS, originally
presented in its final form by Glover [11], enables the search to accept non-improving
solutions, while cycling back to previously explored solutions is prevented through the
Tabu List containing the most recent solutions visited. While both TS and Simulated
Annealing can require extensive parameter tuning for desired results to be reached,
GRASP requires little to none. GRASP and Simulated Annealing was chosen and will
be described in the following sections.

Chapter 4. Solving the DRP 23
4.3.3 The GRASP metaheuristic
When heuristics come up short in the search for an acceptable solution, perhaps getting
stuck in local optima, several improvements can be implemented. The improvement can
be as simple as implementing a restart mechanism into the algorithm. The framework
consisting of such ’outer’ mechanisms that guide heuristics are called metaheuristics.
Burke and Kendall [4] defines a metaheuristics, referring to Glover and Laguna [12], as:
. . . a master strategy that guides and modifies other heuristics to produce
solutions beyond those that are normally generated in a quest for local op-
timality.
which is also implied in the name, derived from the prefix meta (beyond) and heuristic
(to find).
A metaheuristic is a general framework used when knowledge of the problem, that can be
exploited, is sparse or if implementation of a problem-specific algorithm is impractical.
It requires little to no information and as such, acts similar to a black box, taking
a problem as input and if it can find one, gives a solution as output. The fact that
metaheuristics are general search algorithms brings up the issue of whether there exists
a better algorithm for the purpose of solving the problem. Whitley and Watson [25]
concludes from Wolpert and Macready [26] that:
For all possible performance measures, no search algorithm is better than
another when its performance is averaged over all possible discrete functions.
Which is the conclusion of applying the No Free Lunch theorem to search. Whitley and
Watson [25] notes, much as Wolpert and Macready [27] concludes, that search algorithms
need to be tailored to the problem, exploiting problem specific information as much as
possible.
The search algorithms in this project does not, as the above suggests, exploit problem
specific information in the search for better solutions. The two neighborhood functions
described in section 4.3.2 on page 20 can be enhanced to cater for the problem specific
constraints, which is also suggested in section 8.2.
The Greedy Randomized Adaptive Search Procedure (GRASP) is a metaheuristic. GRASP
has very few parameters, namely a RCL parameter and a stop-criterion (commonly time
or iterations) and as such is easy to implement. This allows the developer to put focus
on implementing optimal data structures. GRASP is an iterative process, in which each
iteration consists of two phases:

Chapter 4. Solving the DRP 24
1. Construction of an initial solution, using a given construction heuristic. In this
project, the construction heuristic used in GRASP is the same as the adaptive
greedy algorithm described above. The RCL parameter is used during the con-
struction phase in the same manner, though, in more sophisticated versions of
GRASP, the probabilistic when choosing the random element from the RCL can
be influenced by a learning mechanism (more on this later). Resende and Ribeiro
[20] defines the re-evaluation of the RCL list as the adaptive part of the algorithm.
In this project, re-evaluation of the RCL does not occur as the RCL list is only
created once per shift.
2. Local Search for a better solution.
Over all iterations, the best incumbent solution is kept and at the end returned by the
algorithm.
The basic GRASP algorithm, for a minimisation problem, is listed in algorithm 4.3.
Algorithm 4.3 GRASP - require: RCL parameter p
S ← new empty schedule
S ← ∅
while ¬ Stop do
S ← Greedy(p, S)
S ← Local Search( S)
if z( S) < z(S) then
S ← S
end if
end while
One key point, as noted in Resende and Feo [19] and Resende and Ribeiro [20], of
GRASP is that many initial solutions can be generated in the same amount of time that
one LS takes to finish. The best of these random initial solutions are often better than
the one found by LS. Resende and Feo [19] also notes that while a fully greedy RCL
parameter (one that leaves only the best element in the RCL) may produce a good mean
solution value, it is also often suboptimal. When relaxing the RCL parameter, the mean
value degrades but the variance of the solutions found increases and thus leaves room
for finding a solution that outperforms the mean of the fully greedy RCL parameter.
While being a simple algorithm, GRASP still allows for a number of hybridisations.
These enhancements are meant to remove or improve upon the shortcomings of the
framework. One obvious flaw in the GRASP framework is the lack of memory usage. In
the basic GRASP, all information is discarded between each iteration. Resende and Feo
[19] identifies several enhancements that could well be classified as learning mechanisms.
These include:

Chapter 4. Solving the DRP 25
• Reactive GRASP in which the RCL parameter is automatically tuned in each it-
eration of GRASP, produces better results than a static RCL parameter. Resende
and Ribeiro [20] restates a formulation including a set of RCL parameters coupled
with a probability to choose that exact parameter. The probability for each pa-
rameter is reevaluated each iteration, using the average value of solutions found
through the parameter and the incumbent.
• Cost pertubation is an idea of maintaining a list of prizes corresponding to the
value of adding each element to the solution in the construction phase. This list
is then maintained by two different schemes: Pertubation by elimination, where a
fraction of the element prizes are set to zero, and Pertubation by prize changes, in
which each prize is changed by a factor produced by a parameter.
• Bias functions are probability distributions used to bias the selection of the RCL
elements.
• Intelligent construction: memory and learning that covers long-term memory, such
as the one used in Tabu Search.
• POP in construction, where a Local Search is applied during the construction of
the initial solution.
• Path-relinking, where paths between elite solutions are constructed and explored
in hope of finding better solutions.
The time horizon on this project did not allow implementation of these improvements,
however, specific improvements to the current implementation has been suggested in
chapter 8.
4.3.4 The Simulated Annealing metaheuristic
The Simulated Annealing (SA) algorithm is an analogue to the real world process that
takes place during controlled cooling of solids. If a solid is melted, the particles in the
matter arranges themselves randomly, whereas in a solid state, the particles arranges
themselves in a structured lattice (Aarts et al. [1]). When cooling the melted solid, the
energy of the atoms decreases and the atoms then arrange themselves in the lattice. At
lower temperatures, a change of state in the solid is less likely to occur. The result of the
process, with a high enough maximum temperature and a slow enough cooling, being a
solid whose particles are arranged in the most stable way possible.
Analoguesly, in the appliance of SA to computational problems, the chance of accepting
a neighborhood leading to a worse objective function value (higher energy in the solid)

Chapter 4. Solving the DRP 26
decreases over time. Given, a temperature T , an incumbent value z(S) and a neighbor
value z( S), the probability of accepting a neighborhood, in a minimisation problem, is
commonly chosen to be the Metropolis criterion:
pmin(z(S), z( S), T ) =
1 if z( S) ≤ z(S)
exp( z( S)−z(S)
T ) otherwise
When the algorithm starts and the temperature is still high, the criterion accepts arbi-
trarily large deteriorations in solution value, but as the temperature drops only smaller
deteriorations are accepted and finally, when the temperature reaches zero, no deteri-
orations are accepted. At this point, the SA is essentially a basic, hill climbing (or
descending), LS. The temperature is controlled by some scheme, also implemented in
this project, that can be as simple as T = α · T , where α ∈ [0, 1[. This scheme is a static
scheme, but one can also choose a dynamic scheme, such as one based on the ratio of
accepted solutions.
Algorithm 4.4 outlines the basic SA steps.
Algorithm 4.4 Simulated Annealing - require: Schedule S, start temperature T
S ← S
while ¬Stop do
S ← choose S from N(S)
if z(S) > z( S) then
S ← S
else if exp( z( S)−z(S)
T
S ← S
end if
T ← Update(T )
end while
) > random[0,1) then
The initial value and update of the temperature in each iteration is one of the parameters
that need to be tuned to each problem. In this project I set T = 1000 and α = 0.999.
These values was accepted after due tuning and allows the temperature to drop towards
a defined end-temperature in a steady manner. An example is given in figure C.2 in
appendix C.2.5.
4.3.5 Heuristic bounds
It can be useful to describe the bounds of the search algorithm which is chosen. I do
however feel, that proving the bound of the approximations described above is out of
the scope of this project and I thus leave it for future considerations. Chapter 7 includes
(M)

Chapter 4. Solving the DRP 27
Figure 4.6: The implementation of the schedule
tests of the heuristics which should provide an indication of the performance of the
heuristics.
4.4 Heuristic implementations
In this section, I will briefly cover the implementation of the heuristics described in
this chapter, but before doing so, it is necessary to describe the data structure of the
implementation.
4.4.1 The data structure
The language chosen to implement the heuristics is Java. It contains specific JDK 1.6
implementations, meaning that the runtime environment required to run the program is
Java JRE 1.6, which can be downloaded from Sun.com. The fact that one goal of this
project was to deliver a program allowing the end user to produce schedules and that I
had no previous experience with other environments than Java, made this decision easy.
The approach chosen to design the program is one where user friendliness is prioritised.
It was accepted from the beginning that neither I nor the end user would appreciate
a low level language implementation, such as one in C, containing no graphical user
interface.
The implementation is done in an object oriented approach, meaning that every schedule,
shift and day is instantiated as objects. This approach is chosen due to simplicity when
modeling the problem. A downside to this is that the amount of object allocations can
rise quickly when testing several problem instances.
The schedule is modeled as a list (a Vector) of days and days are modeled as a list (an
ArrayList) of shifts. Due to constraint H4, all days contains four shifts, while certain
days contains five or six. The implementation is pictured in figure 4.6.

Chapter 4. Solving the DRP 28
This model, where only a variable for each day and shift is available, is different from
what is done in an optimal solver, i.e. GAMS. The difference lies in the approach of
solving the problem. In my implementation, each shift object is assigned a doctor object,
is chosen. In the GAMS model, a binary variable for every day, shift and doctor exists.
The schedule, being the main object of the implementation also contains the methods
for selecting the best doctor for a given shift or day. These two methods are included in
appendix A.5.
In the following sections, I describe the implementation of the construction heuristic and
the metaheuristics chosen in this project. It is important to note that the implemen-
tations share several methods and therefore are extending the same basic class. This
allows the classes to take advantage of Javas extend, allowing the heuristics to inherit
methods that they share from so called parent classes. This is depicted in figure 4.7.
4.4.2 A partial enumeration
Figure 4.7: Heuristics inheritance
In the construction heuristic, the option of enumerating the assignments of a whole day
of shifts, as opposed to only assigning one shift at a time, is available. The enumeration
algorithm produces all permutations of size k chosen from N elements and is adopted
from Sedgewick and Wayne [21] (which no longer seems to be available as of the time of
writing). Sedgewick and Wayne [21] originally created the class for use with characters
only. I adopted it into a version permuting a list of doctor objects instead. This
permutation class can be found in appendix A.5.2.

Chapter 4. Solving the DRP 29
As there are between two and four shifts on a given day, with six doctors to choose from,
we get between: n!
(n−k)!
= 6!
(6−2)! = 30 and 6!
(6−4)!
= 360 possible combinations, which is,
at maximum, an increase of 6000% in combinations to explore. On a 1 GHz computer,
this results in a solution generation taking several minutes as opposed to no enumeration
solutions taking mere seconds. The increase in time when using enumeration makes fur-
ther enumeration, a whole week for instance (332640 possible combinations), undesirable
to the end user. Testing of this function proved useful as shall be shown in chapter 7.
4.4.3 Construction heuristic
The implementation of the greedy algorithm is, given the data structure, straight for-
ward. The implementation can be found in appendix A.2, and in short, loops through
each day, each shift and requests the best doctor for either the shift or the set of best
doctors for the whole day (depending on whether the enumeration is used) and then
performs the assignments that are returned.
4.4.4 Metaheuristics
For the implementation of the two metaheuristics, it applies that a neighborhood is
investigated by the following procedure:
1. Find neighborhood n
2. Apply neighborhood n
3. Calculate objective function value and feasibility
4. Decide whether:
(a) To keep the new solution
(b) To undo neighborhood n
When applying the neighborhood-transformation to a solution, the information con-
tained in the neighborhood is saved, such that the search procedure can quickly revert
the transformation if the new solution should turn out inferior.
GRASP
My implementation of the GRASP framework is based, to the letter, on the algorithms
describing the adaptive greedy algorithm (algorithm 4.1 on page 19) and Local Search
(algorithm 4.2 on page 22). The entire GRASP class is found in appendix A.3.

Chapter 4. Solving the DRP 30
Simulated Annealing
The Simulated Annealing implementation is based on algorithm 4.4 on page 26 and is
included in appendix A.4.
4.4.5 Implementation optimisations
As noted above, the two heuristics calculate the objective function value and feasibility
every time a neighborhood transformation has been applied. This presents an obvious
area for optimisation. One optimisation that did not make it into the implementation
is that of a delta function, which I describe in detail in chapter 8.
As one of the questions that spring to mind when developing an application could be:
What operations of this implementation are taking the most time?, I was fortunate to
be in possession of a tool to investigate this exact area. The Netbeans IDE 6.1 allows
profiling of the program, enabling the developer to investigate which methods are taking
the most time. When doing so, I found that the operation requiring the most time are
Hash Code checks. Hash Codes are 32 bit signed integers identifying objects by a single
value, found by the use of prime numbers and the values of the class-fields.
The new (optimised) hash code this lead to, can be seen in listing 4.1, where several
lines, now commented out, were previously calculated. Only the ID-number is really
needed to uniquely identify the doctor.
1 public class Doctor implements Comparable < Doctor >, Serializable {
2
.
3 @Override
4 public int hashCode () {
5 // final int prime = 31;
6 // int result = 1;
7 // result = prime * result + IDnumber ;
8 // result = prime * result + (( name == null ) ? 0 : name . hashCode ());
9 // result = prime * result + numberOfShifts ;
10 // result = prime * result + (( shifts == null ) ? 0 : shifts . hashCode ());
11 return IDnumber ;
12 }
13
.
14 }
Listing 4.1: The new hashcode method
The optimisation may not seem that big, but when the calculation of this hash code
is done once per doctor per shift per constraint, every time we need to calculate the
objective function value, it adds up!

Chapter 5
Optimal solution
This chapter provides a comparison of solutions to the DRP provided by GAMS, the
adaptive greedy algorithm and the GRASP metaheuristic described in section 4.3 re-
spectively. Testing of SA has been left to chapter 7. Only a subproblem comparison is
done due to the complexity of the problem and therein the explosion in time required
by GAMS to reach a solution.
The model implemented in GAMS is the mathematical model described in chapter 3. In
this model, a binary variable for every day, shift and doctor exists. It could potentially
be done with positive variables equal to the id of the doctor assigned to each shift, but
then the problem of assigning two doctors to a shift arises.
5.1 Comparison
To properly measure how good the solutions found through the heuristics described in
chapter 4 are, we need to compare them to some solution, whose bounds we can prove.
That is, find an optimal solution and measure the heuristic value of that particular
solution to the heuristic value of schedules found through the heuristics. This will give
an indication of how far from optimum the heuristics are.
Due to the explosion of time when increasing the problem, the length of the schedule
given to GAMS has been reduced to 4 weeks. The GAMS-model included in the GAMS-
report in appendix B.2 includes the night shifts, evening shifts and wishes in appendix
B.1. The subproblem modelled in GAMS is relaxed due to the fact that the RDO
constraint is not included for these four weeks. Should time have allowed, GAMS testing
of several datasets including more and less constrained problems would have been of
higher priority.
31

Chapter 5. Optimal solution 32
The GAMS report, included in appendix B.2, reports that the objective function value
Z(S) = 2 and that the solution is optimal.
Both the greedy algorithm and GRASP are tested with and without the partial enumer-
ation described in section 4.4.2, and RCL equal to 1 (only the best element), 50 (list size
is cut in half) and 100 (list size is unchanged). Three tests are done and the results are
shown in figure 5.1 on the following page, where Z(S) and V (S) indicate the objective
function value and the number of hard constraints that are violated, respectively.
The results indicate that the enumeration makes a difference and that the solutions found
are near-optimal, when using the enumeration. Specifically we can see that the greedy
construction (with enumeration and RCL = 1 finds optimal solution, figure 5.1(a) on
the next page) are superior to grasp (both with and without enumeration, for RCL = 1).
This indicates that the construction heuristic is the dominant factor of performance for
GRASP. Further investigation of this is found in chapter 7. Over all instances and RCL-
parameters, GRASP (w. enumeration) is superior, as it, at worst, finds solution with
V (S) = 1 (see figure 5.1(a) on the following page).
The assigning of a day results in near-optimal to optimal objective function values. As
such, it is a valuable observation that, for this test-instance, further enumeration, such
as assigning a whole week of shifts at the same time, is not needed. In this conclusion,
I recognise the importance of testing GAMS with other instances of the problem. It is
unfortunate that there was not time to do so.
The best greedy solution and the best GRASP solution respectively, can be seen in
appendix B.3 together with the solution found by GAMS. There are, as suspected,
similarities amongst the solutions. This indicates that the solution space is locked to a
certain degree.

Chapter 5. Optimal solution 33
Amount
Amount
Amount
1
0
1
0
1
0
Results
7,1,20 8,50,13 6,50,2 6,100,8 2,1,0 1,100,4 3,1,7 7,50,2 14,1,0 31,50,0 50,100,2 52,100,1
Z(S), RCL (%), V(S)
Greedy-Shift Greedy-Day GRASP-Shift GRASP-Day
(a) Test 1
Results
6,1,19 5,50,16 2,50,1 8,1,0 10,100,10 1,100,4 5,1,2 6,50,5 11,1,0 33,50,0 44,100,1 56,100,0
Z(S), RCL (%), V(S)
Greedy-Shift Greedy-Day GRASP-Shift GRASP-Day
(b) Test 2
Results
6,1,23 10,50,18 9,50,3 6,100,11 3,100,4 4,1,0 4,1,6 2,50,3 13,1,0 19,50,0 47,100,3 62,100,0
Z(S), RCL (%), V(S)
Greedy-Shift Greedy-Day GRASP-Shift GRASP-Day
(c) Test 3
Figure 5.1: Comparison of heuristic performances for the GAMS problem

Chapter 6
The DRP Program
Through this chapter, the reader is presented with the implementation of a graphical
user interface, provided to the medical practice. The various features are described as to
the allow reader to gain an insight into how the user interface connects with the concepts
described in chapters 3 and 4 respectively.
It should be noted that the implementation is a prototype of a software product and will
most likely contain use cases that will cause the program to stop responding, fail or even
crash. This is a direct consequence of the time horizon on this project. The program
does enable the user to create usable schedules within minutes or even seconds. At the
end of this chapter, I briefly review what program features are missing or lacking, for
the program to be commercialised.
The software can be found on the enclosed dvd 1 .
6.1 The user
When developing an application, it is important to keep in mind who will be using the
application. I recognise that the end user of the DRP program is not necessarily, on any
level, good with computers or IT in general. It was a goal of this implementation to allow
both experienced IT users to quickly grasp the features of the program, utilising all of
the features and novice IT users to simply make use of the basic features. There is a fine
line between adding features that enhance the capabilities of the software product and
making it too complex for anyone outside the project to understand. This is also in line
with the conclusion by Burke et al. [5], who recognise the importance of parameterless
implementations.
1 Run the .jar-file, in the ”DRP/dist” folder
34

Chapter 6. The DRP Program 35
Due to the small size of the medical practice in this project, existing commercial so-
lutions, such as PLANE (Burke et al. [3]) or ANSOS (Warner et al. [24]), are simply
too advanced. They would probably work fine after configuration had been done, but
using these systems in a small medical practice would be overkill. This supports the
development of a DRP program, targeted only at small sized medical practices.
6.2 The Graphical User Interface
Several libraries was used in the development of the application, the main being JCal-
endar (Toedter [23]), which is for graphically picking a date.
The Graphical User Interface (GUI) is designed to be accessible, providing an overview
of the problem, allowing for easy changes to the problem and the solution, while main-
taining a simple, non-obtrusive layout. The GUI is designed with the end user in mind,
however, there has been little communication with the end user regarding the design.
Figure 6.1 shows the main application window that appears when starting the program.
Figure 6.1: The main window
One of the first areas of the GUI the user will notice is the calendar. This is the view of
the schedule and the shifts on each day. No information will appear until a schedule is
generated or a set of shifts and wishes have been imported. The menu bar contains two
menus, file and settings. Through the file menu (figure 6.2 on the next page), the user
can save and load the schedule in various forms.

Chapter 6. The DRP Program 36
Figure 6.2: The file menu
The top save and load menu items are linked to serialisations of the schedule. A se-
rialisation is a way to store objects in Java. The bottom save and load are linked to
Microsoft Excel workbooks, allowing the user to inspect the information of the saved
schedule. Finally, an option to save the schedule in a form of overview is available (this
option should be chosen for printing the schedule).
Importing nights and evening shifts is done through means of a Microsoft Excel-workbook
(through load (xls-file)). Each sheet in the workbook represents a doctors night and
evening shifts, which, for convenience can be copy-pasted directly from Laegevagt.net,
where these are delegated. Figure 6.3 shows an example of a sheet ready for import.
For each sheet in the workbook, a doctor is created and imported to the application.
Figure 6.3: Microsoft Excel workbook containing the night and evening shifts
Figure 6.4 shows the application window, after the user has imported a set of shifts.

Chapter 6. The DRP Program 37
Figure 6.4: The main window w. imported shifts
If the user is not importing any shifts, the option of adding doctors manually is also
available. A set of doctors is needed to generate a schedule, so one of these options must
be chosen.
Once a set of doctors has been added the buttons Generate (SLOW) and Generate
(FAST) will be enabled to the user. They represent a single run of the greedy con-
struction heuristic (see section 4.3.1) and the grasp metaheuristic (see section 4.3.3)
respectively.
Before starting the generation of a schedule, several features are available in the Settings-
menu, shown in figure 6.5, that will allow modification of the end-result:
Figure 6.5: The settings menu
Rule weights allows for modification of the weights of the soft constraints. This en-
ables the priority of certain rules over others. Contrary to Nonobe and Ibaraki
[18], where an automated weight control mechanism is implemented, the weights

Chapter 6. The DRP Program 38
of the constraints in this project are ultimately left to the end user to decide. The
weight-window is shown in figure 6.6.
Figure 6.6: The weights window
View codes shows the various shift-abbreviations, their meaning, where the shift takes
place and what shifts it covers (night, noon, afternoon or evening, or a combination
of either). The user can add or delete definitions here. The codes are used when
importing shifts.
Set code file is for loading another code definition list than the one already loaded.
The format used for the codes file is .xls (Microsoft Excel).
Rolling Day Off enables the user to select whether the RDO-mechanism should be
enabled and for which weeks the RDO should include. Figure 6.8 shows the RDO
window. As of now, the mechanism works with six doctors as is the goal. Though a
more dynamic algorithm is preferable, time was of the essence when implementing
the algorithm.
Day starts at 8am specifies whether a day in the sense of shifts starts at 08.00 am or
at 00.00 am. Tradition sometimes dictates that the night shift of the 20 th physically
lies on the 21 st . The underlying function is to move imported night shifts from
day x to day x + 1, and when showing the schedule in the calendar-view, moving
them back.
Pressing either Generate-button, will result in a generated schedule, showing progress in
the status-bar and when the generation of the schedule is done, the value and violations
of the schedule. Figure 6.9 on page 40 shows the application window after a schedule
has been generated.

Chapter 6. The DRP Program 39
Figure 6.7: The codes window
(a) RDO enabled (b) RDO partially enabled (c) RDO disabled
Figure 6.8: RDO enabled and disabled
The final option available to the user is optimising a schedule. When a schedule has been
generated, the optimise button is enabled and the user can now optimise the schedule
shown in the schedule-view. This button initiates the Simulated Annealing algorithm
described in section 4.3.4, on the current schedule.

Chapter 6. The DRP Program 40
Figure 6.9: The main window w. generated schedule
6.2.1 Measuring the quality of the solution
The status bar in the bottom of the application window shows various solution mea-
surements:
Z(S) the heuristic value of the solution.
V(S) the number of hard constraint violations.
Cons is a measurement of how constrained the problem is. If the problem is 100%
constrained, no doctors can be assigned to any shifts without breaking a hard
constraint. It is an average of how many doctors violate one or more rules when
assigned to a shift, over all shifts. Importing shifts and adding RDO to the schedule
are factors that raises this measurement.
6.3 End user feedback
Much like Dias et al. [7], who also develops a user interface, the end user of the software
program described in this chapter, gains the most in time spent creating the schedule.
The gathering of information from the workforce is still a tedious process, though much
improved through the import-function, and the schedule is still inspected manually after
it has been created by the software. It is estimated that the total time required to
produce a schedule, going from 5-10 hours, will be around 0.5 hours. Should previous

Chapter 6. The DRP Program 41
schedules be taken into account in future versions of the program, the total time required
to produce schedules would drop even more.
Not unlike this program, PLANE (Burke et al. [3]) seeks to please the nurses on a per-
sonal level and treats all nurses equally. PLANE is commended by the users for having
high personal preference satisfaction and a low degree of constraint violation.
6.4 From prototype to release candidate
For this product to be commercialised, several things are needed:
Past schedules should be considere. The assignment of unpopular shifts, such as on
new years eve, new years day, christmas day etc., should be divided equally over
several schedules.
The data structure needs to be optimised for faster computations. The implementa-
tion as it is now, does not fully exploit the object reference advantages.
More dynamic coding is needed. The constraints need to be implemented into some
easily editable form. The doctor-objects could also be coded in a more dynamic
sense, letting the user specify fields for the doctors, and afterwards filling them in.
But for the product to be sold, the buyer must be gaining a savings, i.e. if the doctor
planning the roster is paid to do so, then it could save the medical practice money. If,
on the other hand, the doctor is planning the roster for free, then no savings come from
buying the DRP Program.

Chapter 7
Metaheuristic tests
This chapter will show the performance of the metaheuristics, described in chapter 4, on
a set of problems including one real world problem. Two libraries used during testing
(to output diagrams of the heuristic performances and .xls-files containing the primitive
test data) was the JFreeChart 1 and the Apache POI 2 respectively.
I will begin by explaining the setup of the test, wherein the various key parameters
in the test shall be introduced. After the setup has been explained, the effect of the
test instance variations and the effect of varying configurations of metaheuristics will
be covered respectively. I end this chapter by discussing the pros and cons of GRASP
and SA for the DRP, making a few conclusions based on the observations done in this
chapter.
Appendix C on page 87 contains all summarised test results. All primitive data is
included on the enclosed dvd 3 .
7.1 Test setup
The purpose of the tests is to document the performance of GRASP and Simulated
Annealing on real world test instances, and if possible to support the decision of values
for the parameters. It was only possible to procure one real world problem, so other
instances had to be constructed. All constructed test instances have been constructed
to measure the effect of varying problem parameters on the solution.
The test instances can be found in appendix C.
1 http://www.jfree.org/jfreechart/
2 http://poi.apache.org/
3 In the ”DRP/diagrams/Test” folder
42

Chapter 7. Tests, results and discussion 43
Table 7.1 displays the test instances and the problem factors that can affect the solution.
For every instance, Cons notes how constrained the problem is. I expect that adding
more night shifts, evening shifts and wishes (raising the Cons) also make the problem
harder to solve and likewise when decreasing the number of doctors.
Table 7.1: Test instances
Test Length (months) Cons (%) Doctors
0 4 13 6
1 4 17 6
2 4 12 7
3 4 13 5
4 8 13 6
5 4 18 6
6 2 17 7
7 6 13 8
8 4 5 6
9 4 0 6
The test instances can then be partitioned into the groups shown in table 7.2. This
shows the test instances that have equal values in what categories and will be used for
comparing results across groups in the next section.
Table 7.2: Test instance groups
Length Constrained Doctors
{0,1,2,3,5,8,9},
{4}, {6}, {7}
{0,3,4,7}, {1,6},
{2}, {5}, {8}, {9}
{0,1,4,5,8,9},
{2,6}, {3}, {7}
The problem factors will be the starting point for evaluating test results. From there, I
move on to discuss effects of the metaheuristic factors, such as the RCL parameter, the
enumeration and the weight of the constraints. The test instances have all been tested
with the following parameters:
RCL parameter {1 (Leaving only the best element in the list), 50 (cutting the list in
half), 100 (leave the list as it is)}
Enumeration Day, Shift
Constraint weights δi = 1, δi = 2
In the following, I denote the value of the objective function value Z(S) and the num-
ber of invalid hard constraints by V (S). Together they will be noted in the form of
(Z(S), V (S)).

Chapter 7. Tests, results and discussion 44
7.2 Results and discussion
There are two types of test results documented by the tests. The first documents, by
a graph, the performance of the metaheuristic on a given test instance, with given pa-
rameters, which I leave for the last part of this chapter. The second is the metaheuristic
results, given all combinations of the above parameters, on a given instance. I will then,
in the next section, try to perform a well founded instance and parameter evaluation by
comparing each test instance and metaheuristic result to these derived values. I will not
cross-compare every parameter result, as the number of comparisons, given the param-
eters of these tests, are simply too many to be covered in this project. I shall, though,
highlight the cases where a clear observation can be made even if the results are across
parameters.
7.2.1 Instance parameter effects
In this section I will highlight the effects of the problem parameters and on that basis
conclude, if possible, which parameters have what effects.
Table 7.3: Test instance results
Test Cons (%) Z(S) V(S) Doctors
Test 0 13 196,099 14,38281 6
Test 1 17 222,9297 19,58594 6
Test 2 12 164,1276 12,68229 7
Test 3 13 258,3281 18,03646 5
Test 4 13 349,0755 32,41927 6
Test 5 18 251,0703 20,03125 6
Test 6 17 109,6927 6,403646 7
Test 7 13 246,9219 22,96354 8
Test 8 7 127,4193 9,070313 6
Test 9 0 4,364583 2,289063 6
The data in table 7.3 summarises the test results and are averages over all parameters. It
is brought to the readers attention, to underline the effects of varying these parameters,
which will be described in the next sections. Note that the average value of the solutions
generated is not representative of average values of searches for optimal values. They
are averages over all results, including the test runs where weights of the constraints
has been set to 1 and those for which it was set to 2. The comparisons are meant to
highlight numbers relative to each other, not their absolute value.

Chapter 7. Tests, results and discussion 45
Imported shifts
From table 7.3 on the previous page, we can see that test instance 5 with Cons = 18 has
an average metaheuristic output of (251,20), which then decreases, over the results of
e.g. test instance 2 with (164,12), to test instance 9 with (4,2). It clearly does make the
problem harder when we add night shifts, evening shifts and wishes. It would have been
interesting to investigate what amount of these shifts, for each doctor, that is needed,
before feasibility cannot be guaranteed. Unfortunately, there was not time to do so.
Amount of doctors
When comparing test 0 (196,14), 2 (164,12), 3 (258,18) and 6 (109,6), we see the same
results as we did for the effect of varying amounts of imported shifts. There is then the
problematic result of test 7, which actually comes out with the highest average V(S) out
of the four (246,22). This could be due to the instance containing some periods of time
that are over constrained, such that no amount of optimisation could solve that period
to feasibility.
It is peculiar that test 2 and 6 produces the results that they do considering that the
cons of test 6 is higher than that of test 2. I propose that the length of the schedule is
also a factor in how hard the problem is to solve.
Schedule length
When the length of the schedule varies, we see an immediate effect on the numbers in
table 7.3 on the preceding page. Test 4 (349,32) , 6 (109,6) and 7 (246,22) varies the most
in length and also varies greatly in average values. With test instance 4 being the longest,
the test also produces the worst results, contrary to test 6 that actually has a higher Cons
but produces far better results. I conclude that the length of the schedule has great effect
on the average results of tests. This is actually not unexpected, as the implementation
of the neighborhoods is such, that the transformation is done on a random set of shifts.
When the length of the schedule increases, the ”length” between the shifts that are
invalidating constraints also increase. Had there been implemented a form of guiding
mechanism for the neighborhood transformation, targeting the transformations at shifts
that are invalidating one or more constraints, I suspect the results would have been
different from what we see here.

Chapter 7. Tests, results and discussion 46
7.2.2 Metaheuristic parameter effects
In this section I will discuss the effects of changing the metaheuristic parameters. In the
tables presented in this section, the average results of SA is the results of giving SA the
output from GRASP. As such, there are a much higher number of SA runs than there
is GRASP.
The RCL parameter
The RCL parameter is fundamental to GRASP and allows the metaheuristic to ran-
domise the construction of the initial solution in each iteration.
Imps Z(S) V(S)
GRASP 1 17,1875 3,5625 25,9375
GRASP 100 14,625 392,75 19,3125
GRASP 50 13,5 5,625 21,125
Table 7.4: RCL effect: Test 0
Imps Z(S) V(S)
GRASP 1 19,625 5 32
GRASP 100 15,3125 363,6875 27,875
GRASP 50 13,625 6,125 27,5
Table 7.5: RCL effect: Test 1
Table 7.4 shows how, against suspecion, a more random RCL parameter, GRASP 100
(393,19) actually results in a lower V(S). It does come with a cost, namely the high
Z(S). In this case, I suspect that a more balanced result, such as for the GRASP 50
(6,21), would be more preferable to the medical practice. The same goes for test 1,
where GRASP 100 (364,28) produces a lower V(S) than GRASP 1 (5,32). This is, also
described earlier, a key observation, which is not that far from what Resende and Feo
[19] says. A fully greedy RCL may produce good mean values, but when we increase
the randomisation, we may produce better results.
The conclusion that a fully greedy RCL parameter is not optimal is supported by test
8 and 9, shown in table 7.7 and 7.6 respectively. In these tables we see an obvious
reduction in V(S) when going from fully greedy to fully random RCL parameter, even
on test 9 where there are no night shifts, evening shifts or wishes.
Imps Z(S) V(S)
GRASP 1 7,6875 3,375 8,125
GRASP 100 8,75 7,5 1
GRASP 50 6,0625 2,875 3,375
Table 7.6: RCL effect: Test 9
Imps Z(S) V(S)
GRASP 1 15,5 4,9375 19
GRASP 100 11,0625 185,0625 9,625
GRASP 50 14,625 4,625 14,9375
Table 7.7: RCL effect: Test 8
Over all tests, the average values of the solutions grouped by RCL parameters are shown
in table 7.8 on the following page. In this table we can see that the average value of
Z(S) increases significantly when the metaheuristic manage to decrease V(S).

Chapter 7. Tests, results and discussion 47
The enumeration
Table 7.8: RCL Effect: All tests
RCL Z(S) V(S)
GRASP 1 4,125 28,53125
50 5,5 21,98125
100 356,1875 20,34375
The enumeration changes the way the construction heuristic builds the initial solution.
Thus, in the following, we shall, as in the previous section, only focus on how GRASP
performs with and without the enumeration mechanism.
Table 7.9: Enumeration effect: All tests
Z(S) V(S)
Test Day Shift Day Shift
0 112,6667 155,2917 5,625 38,625
1 112,625 137,25 9,458333 48,79167
2 73,125 103,3333 7,916667 32,08333
3 131 186,3333 8,291667 44,45833
4 205,375 288,3333 9 82,54167
5 133,2917 188,75 10,75 47,75
6 52,45833 73,91667 3,125 18,25
7 141,2917 204,7917 7,208333 61,125
8 52,66667 77,08333 2,291667 26,75
9 2,416667 6,75 0 8,333333
From table 7.9, I conclude that the enumeration improves the performance of grasp
considerably. For all instances, it is the case that the average solution of GRASP with
enumeration is superior to the average solutions of GRASP without enumeration. To
highlight the effect, see table 7.10 and 7.11 respectively. These two tables, for RCL 1
and RCL 50 respectively, shows the effect of the enumeration to a great extend. Espe-
cially, table 7.11, where 50% randomisation has been implemented in the construction
mechanism, the enumeration still ensures low average values of V(S).
RCL 1
GRASP Z(S) V(S)
Day 3 0,125
Shift 5,75 110
4,375 55,0625
Table 7.10: Enumeration effect:
Test 4, RCL 1
RCL 50
GRASP Z(S) V(S)
Day 7,875 5,375
Shift 5,625 53,375
6,75 29,375
Table 7.11: Enumeration effect:
Test 7, RCL 50

Chapter 7. Tests, results and discussion 48
The constraint weights
Table 7.12 shows the overall effect of solving problems with weights δR1 = 1 and δR2 = 2
respectively. The V(S), as expected, is not affected by varying weights, but for Z(S) we
see a small increase in objective function value. Note, however, that the Z(S) for R2 is
not double of Z(S) for R1, this means, on average, fewer soft constraints invalidated.
Table 7.12: Weights effect: All tests
Z(S) V(S)
GRASP R1 106,075 23,99167
R2 137,8 23,24583
SA R1 234,8229 8,035417
R2 293,4839 7,877352
Highlighting a few, more in-depth, examples, tables 7.13 and 7.14 shows how Simulated
Annealing ends up with just about equal numbers of soft constraints broken, for both
R1 and R2.
SA Z(S) V(S)
R1 73,875 6,84375
R2 148,5938 7,40625
Ave 111,2344 7,125
Table 7.13: Weights effect: Test
0, RCL 1
The number of iterations
SA Z(S) V(S)
R1 85,65625 20,5625
R2 162,875 20,375
Ave 124,2656 20,46875
Table 7.14: Weights effect: Test
4, RCL 1
Not surprisingly, the number of iterations also has great effect on the quality of the
produced solution. Table 7.15 on the following page shows the average solution values
over all tests, grouped by the number of iterations for each of the metaheuristics. As
expected, Z(S) is also higher on average, for lower values of V(S).
7.2.3 Metaheuristic performance
The performances of the metaheuristics has so far been investigated in the light of
the parameters that guide them and the problems they solve. How the metaheuristics
converge and how they compare to each other, are some of the aspects that will be
discussed in this section.

Chapter 7. Tests, results and discussion 49
Table 7.15: Iterations effect: All tests
Iterations Z(S) V(S)
GRASP 156 105,1354 27,78333
3276 143,3542 19,64583
SA 500 257,9729 12,31146
2500 270,3089 3,597446
Focusing on the real world problem once again, figures 7.1 and 7.2 on the following
page shows the performance of a GRASP and SA taking over from the GRASP. It is
clear that GRASP with enumeration finds near optimal values (using a higher number
of iterations results in actual optimal solutions, see figure C.1 in appendix C.2.5 on
page 115) and compared to that of GRASP without enumeration is greatly superior.
Figure 7.2(b) on the following page shows how SA is able to optimize the output from
GRASP without enumeration, but in minimising V(S), it also increases Z(S). The same
observation applies to figure 7.2(a) on the next page.
20
15
10
5
0
GRASP-Day-1-10-R2-13%
0 25 50 75 100 125 150
Iterations
GRASP-Day-1-10-R2-13%-vio GRASP-Day-1-10-R2-13%-value
Working vio Working score
(a) GRASP, enumeration, R2, RCL 1
100
80
60
40
20
0
GRASP-Shift-1-2-R2-13%
0 25 50 75 100 125 150
Iterations
GRASP-Shift-1-2-R2-13%-vio GRASP-Shift-1-2-R2-13%-value
Working vio Working score
Figure 7.1: GRASP performance: Test 0
(b) GRASP, no enumeration, R2, RCL 1
One observation to be made from figure 7.1(b), is that GRASP without enumeration
restarts too soon. It restarts while it is still able to find improving neighborhoods in LS,
and ends up not being able to improve the incumbent solution again.
Emphasising the effect of the enumeration I refer to figures 7.3 on the next page and 7.4
on page 51.
The effect of the enumeration is so strong, that in most cases, there isn’t anything for SA
to optimise. The following will show that SA is in fact able to optimise poor solutions
produced by GRASP.

Chapter 7. Tests, results and discussion 50
100
80
60
40
20
12
10
8
6
4
2
0
0
SA-Day-1-2-R2-13%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Day-1-2-R2-13%-vio SA-Day-1-2-R2-13%-value
Working vio Working score Temperature
(a) SA, on the output from figure 7.1(a)
GRASP-Day-1-2-R2-18%
0 500 1.000 1.500 2.000 2.500 3.000
Iterations
GRASP-Day-1-2-R2-18%-vio GRASP-Day-1-2-R2-18%-value
Working vio Working score
1.000
(a) Test 5: GRASP, enumeration, R2, RCL 1
900
800
700
600
500
400
300
200
100
Temperature
160
140
120
100
Figure 7.2: SA performance: Test 0
80
60
40
20
0
SA-Shift-1-2-R2-13%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Shift-1-2-R2-13%-vio SA-Shift-1-2-R2-13%-value
Working vio Working score Temperature
(b) SA, on the output from figure 7.1(b)
GRASP-Shift-1-2-R2-18%
1.000
GRASP-Shift-1-2-R2-18%-vio GRASP-Shift-1-2-R2-18%-value
Working vio Working score
Figure 7.3: GRASP performance: Test 5
100
80
60
40
20
0
0 500 1.000 1.500 2.000 2.500 3.000
Iterations
(b) Test 5: GRASP, no enumeration, R2, RCL
1
To comment on the performance of SA, I shall be highlighting test 9 (the empty sched-
ule). In figure 7.5 on the next page it is seen that SA is able to optimise both solutions
to a degree where V(S) = 0.
Observing the performance of SA on more constrained problems, such as test 2 and
test 5, figure 7.5 on the following page also shows how constrained problems makes SA
increase Z(S) as V(S) decreases.
900
800
700
600
500
400
300
200
100
Temperature

Chapter 7. Tests, results and discussion 51
25
20
15
10
5
0
GRASP-Day-Fifty-2-R1-17%
0 500 1.000 1.500 2.000 2.500 3.000
Iterations
GRASP-Day-Fifty-2-R1-17%-vio GRASP-Day-Fifty-2-R1-17%-value
Working vio Working score
(a) Test 6: GRASP, enumeration, R2, RCL 50%
30
25
20
15
10
5
0
SA-Shift-Best-2-R1-0%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Shift-Best-2-R1-0%-vio SA-Shift-Best-2-R1-0%-value
Working vio Working score Temperature
(a) Test 9: SA, R2, RCL 1%
7.3 Test conclusions
35
30
25
20
15
10
5
0
GRASP-Shift-Fifty-2-R1-17%
0 25 50 75 100 125 150
Iterations
GRASP-Shift-Fifty-2-R1-17%-vio
Figure 7.4: GRASP performance: Test 6
1.000
900
800
700
600
500
400
300
200
100
Temperature
Figure 7.5: SA performance: Test 9
GRASP-Shift-Fifty-2-R1-17%-value Working vio Working score
(b) Test 6: GRASP, no enumeration, R2, RCL
50%
35
30
25
20
15
10
5
0
SA-Shift-Best-2-R2-0%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Shift-Best-2-R2-0%-vio SA-Shift-Best-2-R2-0%-value
Working vio Working score Temperature
(b) Test 9: SA, R2, RCL 1%
First of all, it is clear that certain DRP’s pose greater problems, in the aspect of solving
them. Longer schedules, fewer doctors and increasing amounts of imported shifts, pro-
duces worse average results. One must be aware, that the problems are still solvable,
even to optimality, if we choose the right approach. That is, if we choose to enumerate
a whole day and if we use GRASP and SA in conjunction with each other. The obser-
vations on the performance of GRASP and SA does not make one seem superior to the
other, as both finds a niche to perform well in. GRASP is extremely good at finding
good solutions, if we choose to enumerate, but in some cases, does not find optimal
solutions. Should we choose to use SA on these problems, we must be mindful of the
1.000
900
800
700
600
500
400
300
200
100
Temperature

Chapter 7. Tests, results and discussion 52
250
200
150
100
50
0
SA-Shift-1-10-R2-12%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Shift-1-10-R2-12%-vio SA-Shift-1-10-R2-12%-value
Working vio Working score Temperature
(a) Test 2: SA, R2, RCL 1%
1.000
900
800
700
600
500
400
300
200
100
Temperature
100
80
60
40
20
0
SA-Day-Fifty-2-R2-18%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Day-Fifty-2-R2-18%-vio SA-Day-Fifty-2-R2-18%-value
Working vio Working score Temperature
Figure 7.6: SA performance: Test 2 and 5
(b) Test 5: SA, R2, RCL 50%
fact that the Z(S) can increase, sometimes ten-fold, as SA makes V(S) decrease towards
0.
Secondly, an use-case evaluation, given the test results in this chapter, brings me to
the conclusion that GRASP with enumeration, RCL 1-5 % and a number of iterations
between 5000 and 10000, would yield the best results of all possible combinations.
Had there been time to do so, it would have been of great importance to test following:
• Solving test-instances with GAMS, yielding proven bounds and comparing the
heuristic solutions to these bounds.
• How the initial temperature and update of the temperature affects the performance
of SA.
• How a skew distribution of weights would have affected the results of both GRASP
and SA.
1.000
900
800
700
600
500
400
300
200
100
Temperature

Chapter 8
Future considerations
This chapter describes suggested improvements to the implemented methods for solving
the DRP. It is a goal of this chapter that the descriptions are as thorough as possible,
allowing the reader to gain a complete understanding of how it was to be implemented,
should the time horizon on this project have allowed it.
8.1 User-added rules - relation/logic of shifts
As noted earlier, the rules of this project has been hard-coded. This means that no
rules can be added or removed by the end user. For the end the user to be able to
dynamically add rules, a framework is needed, that described how the elements in the
rule are structured and what these elements can consist of. In the following, I describe
the type of some of the rules that chapter 3 covers, such that the reader may gain an
idea of how this was to be implemented if there had been time to do so (note, other
types of rules could be devised as well):
Type 1 is the basic ’if you have this shift, you can not have that shift’-rule: The user
is given a starting point from which to define the rule. To start off, we assume
all doctors to be equal so all rules apply to all doctors and all rules to apply to
all days and shifts. Let us call the starting point of a rule p(i, j), where i defines
the days and j defines the shift on that day. One way to define a user added rule
could be to construct three basic elements in the rule:
1. the starting point: a set P1 of starting points p(i, j)
2. a comparator: =, =, ≤, ≥, < or >
3. the end point: a set P2 of end points
53

Chapter 8. Future considerations 54
Combined, these three elements relate two sets of shifts to each other through a
comparator. The end user specifies the end point through r1 and r2, that are the
offset of days and the offset of shifts. I.e. equation H0 would be modelled by the
comparator = and the offset 0 and 1 respectively. As we move on to implement
other rules, a more specific representation of the subset i and j is needed. Several
subset could be premade and ready for the end user to choose from, e.g. holidays,
weekdays, Mondays, . . . Fridays, and likewise for the shifts.
Type 2 describes demands on certain shifts. A default demand could be specified by
the user, such that only shifts that deferred from this default demand would need
to be specified. These would consist of the following elements:
1. the point p(i, j) on which to specify the demand
2. the demand of doctors
Type 3 is for dividing the assignments of shifts equally. This would simply be hard-
coded and be available for the user to enable or disable.
For all types, the user should be able to specify whether the rule is a hard or soft
constraint.
8.2 Neighborhood delta function and feasibility
The most time consuming task of the heuristics is the calculation of a new objective func-
tion value when exploring a given neighborhood (and feasibility of said neighborhood).
To reduce the time spent on finding the new objective function value, a delta function
can be implemented, allowing the calculation of only the changes a neighborhood brings,
as opposed to the total objective function value.
We note again, that selection of the shifts for a new neighbor is, as described in section
4.3.2, random. Random selection of shifts to rotate or invert also means infeasible
solutions explored in the Local Search. As mentioned earlier, due to how constrained the
problem is, we allow infeasibility. Hence, the heuristics not only seek global optimum of
solution value, but also minimisation of the number of violated shifts. This means, that
it is not enough to check the objective function value when exploring a neighborhood,
but also check the hard constraints (for feasibility).
A delta function is generally a function calculating the value of a change. This means
that we need the value of the old (shift,doctor)-assignments (of the shifts that are affected
by the neighborhood). To do this, it is required, that for each (shift,doctor)-assignment

Chapter 8. Future considerations 55
in the solution, a value of the contribution to the objective function is stored (both
violations of hard constraints, but also the objective function value contribution).
Algorithm 8.1 outlines a possible implementation of a delta function for equation H0.
Algorithm 8.1 Delta function H0 - require: schedule S
∆H0 = 0
Set ← Select random shifts from S
for all Shifti in Set do
Shift2 ← S.getNextShift(Shifti)
if Shifti.getDoctor()= Shift2.getDoctor() then
∆H0 = ∆H0 + 1
end if
end for
Return ∆H0
∆H0 is then the amount of shifts in the new neighborhood that are violating constraint
H0. Similar rules could be devised for the rest of the constraints, keeping hard constraints
violations separated from soft constraints objective function value contribution.
The total ∆ (over all constraints) could then be compared to that of the contribution
made by the shifts affected by the neighborhood.
8.3 GRASP learning
A simple way to improve the GRASP algorithm used in this project would be to incor-
porate one or more of the learning mechanisms described in section 4.3.3. One way to do
this would be to track the (shift,doctor)-assignment that violates one or more rules and
bias that specific assignment such that GRASP would be more inclined not to perform
the same assignment in the next iteration.
Expanding on this, could be more biasing towards (shift,doctor)-assignments that violate
more or less rules than other (shift,doctor)-assignments. The bias-function could then
be introduced through a ranking, where a higher rank means less violations and higher
priority, or a probability distribution, with a probability for each assignment based on
the average number of rules it violated in the previous iterations of GRASP (and perhaps
how many violations it produces in the current).
8.3.1 GRASP stop criterion
An improvement, other than those presented in section 4.3.3, to the GRASP imple-
mentation is that of another stop criterion. As concluded in chapter 7, the GRASP

Chapter 8. Future considerations 56
algorithm may end an iteration even though it has improved the incumbent solution in
the last LS-iteration. As such it could lead to faster convergence if the stop- and restart
criterias was to be changed from time/iterations to ’time/iterations since improvement’.
8.4 SA extensions
The core property of Simulated Annealing is the opportunity to escape local optima,
in search for global optima, done through the Metropolis criteria (see the Metropolis
criterion on page 26). The current implementation of the Update(T )-function, makes
sure that T converges towards a defined end-temperature, as time progresses. But, as
the main feature of the temperature is to allow escape of local optima, it could make
sense to actually increase the temperature if no improvements to the incumbent had
been found in a certain amount of time. This would allow for much more inferior
solutions to be accepted, if such are needed to escape the local optima, in which SA
finds itself. Following this, an update to the α is also needed, seeing as temperature
must converge towards the end-temperature near the end of Simulated Annealing. As
such, some quick math could be done to decrease α by a certain amount, in order to
ensure this convergence.

Chapter 9
Conclusion
This master thesis presents the reader with a solution to a real world doctor rostering
problem, covering the scheduling of a number of doctors over a period of time with
respect to a range of criteria that ensures satisfied work members.
The problem, set down by a roster planning doctor, has been compared to that of
standard nurse scheduling problems and has been found too small, due to problem size,
shift types, and a range of very peculiar constraints, for the solution to be of any real
value in NSP research beyond that of entry level planning. The research presented in this
thesis may be of more value in the area of the Gotlieb class-teacher problem research.
A mathematical model of the hard and soft constraints is described and an objective
function describing the value of solutions is presented along with an estimation on the
size of the problem.
The problem is proven to be NP-complete and on this basis, solving the problem with
heuristics are chosen over exact methods, which would require exponential time to finish.
For these heuristics, various initial solutions are discussed and a greedy approach is se-
lected. Once a solution generation has been established, two simple neighborhoods, the
rotation and inversion, of the solutions and exploration of these through local search is
described. GRASP, a metaheuristic framework is then discussed along with possible ex-
tensions and the Simulated Annealing algorithm used for optimising already constructed
solutions is presented. After the methods for solving the problem has been described,
the steps taken to implement these methods has been described.
The solutions found by the heuristics are then compared to a solution found by an
optimal solver (GAMS). Due to problem size and complexity, only a subproblem of a
given dataset is tested. It is found that GAMS is able to solve the problem to optimality
as is the heuristics.
57

Chapter 9. Conclusion 58
The three heuristics are implemented in a program, written in Java and the program
features are presented. The program is able to model the problem and all of the con-
straints described by the end user. It consists of an intuitive, non-obtrusive layout with
easy to configure settings, able to present a solution to a schedule of any length, with
any number of doctors. Several measures of the solution value are displayed to the user
to allow for solution evaluation. Due to the time horizon on the project, the program is
not bugfree and several parts are hard coded, but it does deliver as promised.
A more thorough testing of the heuristics indicates that the partial enumeration of
the solution space is able to improve the solutions within an acceptable time frame in
the perspective of time and solution trade-off. Larger enumerations is out of bounds
compared to the limitations set down by the end user and the possible gain compared
to the implemented enumeration is too small.
Finally, the reader is presented with considerations for further implementations and
improvements, that could possibly improve the quality of the solutions found and the
implementation respectively. This includes a delta function allowing for the difference in
objective function value to be calculated instead of the entire objective function value.
The DRP has been discussed, analysed, modelled, solved and tested. It is, however,
found that the problem is too specific for the solution to be applied to any other envi-
ronment, such as larger hospitals or other private doctor offices. For this to be the case,
a more dynamic setup of constraints, shifts and the incorporation of qualification levels
is needed.

Appendix A
Implementation
This appendix lists the implementation of key points in the implementation of the heuris-
tics and methods they use.
A.1 Neighborhoods
A.1.1 Inversion neighborhood
1 package changes ;
2
3 import java . util . LinkedHashSet ;
4
5 import ds.Day ;
6 import ds. Doctor ;
7 import ds. Schedule ;
8 import ds. Shift ;
9
10 public class N_invertion extends Change {
11
12 private static final long serialVersionUID = -717097533016180053 L;
13
14 public N_invertion ( int maxRotation , RotationInt rotationInt ) {
15 setChangeType ( ChangeType . nRotation );
16 setRotationInt ( rotationInt );
17 setN ( maxRotation );
18 }
19
20 public Change nextChange ( Schedule s) {
21
22 Change c = new Change ();
23
24 LinkedHashSet < Shift > list = new LinkedHashSet < Shift >() ;
25
26 // find shifts to invert
59

Appendix A. Implementation 60
27 // Random up to N and only N - size
28 Day randDay ;
29 Shift randShift ;
30 int randomSize ;
31 if ( getRotationInt (). compareTo ( RotationInt . RandomUpToN ) == 0) {
32 randomSize = ( int ) ( Math . random () * getN ());
33 } else {
34 randomSize = getN ();
35 }
36 while ( list . size () < randomSize ) {
37 randDay = s. get (( int ) Math . floor ( Math . random () * s. size ()));
38 randShift = randDay . getShift (( int ) Math . floor ( Math . random () * randDay
. size ()));
39 if ( randShift . isMiddayShift () && ! randDay . isWeekend () && ! randDay .
isHoliday ()) {
40 list . add ( randShift );
41 }
42 }
43
44 // invert doctors ( meaning , that particular doctor will not have that
45 // shift afterwards )
46 Object [] al = list . toArray ();
47
48 for ( int i = 0; i < al. length ; i ++) {
49 Shift shi = ( Shift ) al[i];
50 // pick any other doctor for the shift :
51 Doctor d = s. getRandomDoc ();
52 while (d. equals ( shi . getDoctor ())) {
53 d = s. getRandomDoc ();
54 }
55 c. put (shi , d);
56 }
57 return c;
58 }
59 }
A.1.2 Rotation neighborhood
1 package changes ;
2
3 import java . util . LinkedHashSet ;
4
5 import ds.Day ;
6 import ds. Doctor ;
7 import ds. Schedule ;
8 import ds. Shift ;
9
10 public class N_rotation extends Change {
11
12 private static final long serialVersionUID = -2600577434569838673 L;
13
14 public N_rotation ( int maxRotation , RotationInt rotationInt ) {
15 setChangeType ( ChangeType . nRotation );

Appendix A. Implementation 61
16 setRotationInt ( rotationInt );
17 setN ( maxRotation );
18 }
19
20 public Change nextChange ( Schedule s) {
21
22 Change c = new Change ();
23
24 LinkedHashSet < Shift > list = new LinkedHashSet < Shift >() ;
25
26 // find shifts to swap around
27 // Random up to N and only N - size
28 Day randDay ;
29 Shift randShift ;
30 int randomSize ;
31 if ( getRotationInt (). compareTo ( RotationInt . RandomUpToN ) == 0) {
32 randomSize = ( int ) ( Math . random () * getN ());
33 } else {
34 randomSize = getN ();
35 }
36 while ( list . size () < randomSize ) {
37 randDay = s. get (( int ) Math . floor ( Math . random () * s. size ()));
38 randShift = randDay . getShift (( int ) Math . floor ( Math . random () * randDay
. size ()));
39 if ( randShift . isMiddayShift () && ! randDay . isWeekend () && randShift .
isSet () && ! randDay . isHoliday ()) {
40 list . add ( randShift );
41 }
42 }
43
44 // rotate doctors
45 Object [] al = list . toArray ();
46
47 for ( int i = 0; i < al. length ; i ++) {
48 Shift shi = ( Shift ) al[i];
49 // Shift is the first element : Doc should be moved to the shift of
50 // the last element
51 if ( shi == al[al. length - 1]) {
52 Doctor d = (( Shift ) al [0]) . getDoctor ();
53 c. put (shi , d);
54 } else {
55 Doctor d = (( Shift ) al[i + 1]) . getDoctor ();
56 c. put (shi , d);
57 }
58 }
59 return c;
60 }
61 }
A.2 Construction heuristic
1 package heuristic . construction ;

2
Appendix A. Implementation 62
3 import basic . RCLParameter ;
4 import heuristic . Heuristic ;
5
6 import java . util . Vector ;
7
8 import basic . Rules ;
9 import changes . Change ;
10 import ds.Day ;
11 import ds. Doctor ;
12 import ds. Pair ;
13 import ds. Schedule ;
14 import ds. Shift ;
15 import java . util . HashMap ;
16 import java . util . HashSet ;
17
18 /* *
19 * The extended version of the greedy approach to assigning the shifts is based
20 * on a relative behaviour . It examines each doctor for each shift and picks the
21 * best doctor . This doctor is based on a score , which again is based on the
22 * rules documented in the report , as well as in Rules
23 *
24 * @author Asser Fahrenholz
25 */
26 public class GreedyExt extends Heuristic {
27
28 public Vector < Shift > unassignedShifts ;
29 private final RCLParameter RCLsize ;
30 private int newScore ;
31 private int oldScore ;
32 private int newVio ;
33 private int newSoftVio ;
34 private boolean minimize ;
35
36 public GreedyExt ( Rules myRules , RCLParameter RCLsize , Schedule s, DayOrShift
dos , boolean minimize ) {
37 super ( myRules , s, RCLsize , dos );
38 this . minimize = minimize ;
39 this . RCLsize = RCLsize ;
40 }
41
42 public RCLParameter getRCL () {
43 return this . RCLsize ;
44 }
45
46 @Override
47 public Void doInBackground () throws Exception {
48 try {
49 Pair < Integer , Pair < HashMap < Shift , HashSet >>,
HashMap < Shift , HashSet >>>> workingSol = working .
getSolutionValue ( false , getRules ());
50 oldScore = 0;
51
52 newScore = workingSol . getE ();
53 newVio = workingSol . getV (). getE (). size ();

Appendix A. Implementation 63
54 {
55 Day day ;
56 Shift s;
57 Doctor d;
58 for ( int i = 0; i < working . size (); i ++) {
59
60 setProgress (100 * i / working . size ());
61 oldScore = newScore ;
62 workingSol = working . getSolutionValue ( false , getRules ());
63 newScore = workingSol . getE ();
64 newVio = workingSol . getV (). getE (). size ();
65 newSoftVio = workingSol . getV (). getV (). size ();
66 firePropertyChange (" score ", oldScore , newScore );
67 firePropertyChange (" violations ", null , newVio );
68 firePropertyChange (" violationsSoft ", null , newSoftVio );
69 day = working . getDay (i);
70 if (!( day . isWeekend () || day . isHoliday ())) {
71
72 if ( getDoS (). compareTo ( DayOrShift . Day ) == 0) {
73 Change c = working . getBestChange ( day . getDayID () ,
RCLsize , minimize , getRules ());
74 working . performChange (c, false );
75 continue ;
76 }
77
78 Shift :
79 for ( int j = 0; j < day . size (); j ++) {
80 s = day . getShift (j);
81
82 if (s. isMiddayShift ()) {
83 d = working . getBestDoctor (day , s, RCLsize ,
minimize , getRules ());
84 working . assignDoctor2Shift (day , d, s. getShiftInt
() , false );
85 }
86 }
87 }
88 }
89 }
90 working . setConstructorID ( this . hashCode ());
91 working . setRCL ( RCLsize );
92 working . setDoS ( dos );
93
94 setBestSchedule ( working );
95
96 } catch ( Exception e) {
97 System . out . println (" Caught e: " + e. getCause ());
98 e. printStackTrace ();
99 }
100 return null ;
101 }
102 }

Appendix A. Implementation 64
A.3 GRASP metaheuristic
1 package heuristic . meta ;
2
3 import basic . RCLParameter ;
4 import basic . Rules ;
5 import changes . Change ;
6 import changes . RotationInt ;
7 import ds.Day ;
8 import ds. Doctor ;
9 import ds. Pair ;
10 import ds. Schedule ;
11 import ds. Shift ;
12 import heuristic . Metaheuristic ;
13 import java . util . HashMap ;
14 import java . util . HashSet ;
15 import org . jfree . data .xy. XYDataItem ;
16 import org . jfree . data .xy. XYSeries ;
17 import org . jfree . data .xy. XYSeriesCollection ;
18
19 /* *
20 * A GRASP ( Greedy Randomised Adaptive Search Procedure ) class
21 * @author Asser Fahrenholz
22 *
23 */
24 public class GRASP extends Metaheuristic {
25
26 private final RCLParameter RCLsize ;
27 private int localLoopCounter ;
28 private int counter = 0;
29 private boolean minimize ;
30
31 public GRASP ( double timeToRun , int maxRotation , Rules myRules , RotationInt
rotationInt , RCLParameter RCLsize , Schedule s, Type t, int rounds , boolean
diagram , DayOrShift dos , boolean minimize ) {
32 super ( timeToRun , maxRotation , myRules , rotationInt , s, t, rounds , RCLsize
, dos );
33 this . RCLsize = RCLsize ;
34 this . minimize = minimize ;
35 }
36
37 public RCLParameter getRCL () {
38 return this . RCLsize ;
39 }
40
41 @Override
42 public Void doInBackground () throws Exception {
43 XYDataItem point4 ;
44 XYDataItem point3 ;
45 XYDataItem point ;
46 XYDataItem point2 ;
47 try {
48 seriesCol = new XYSeriesCollection ();
49 series = new XYSeries (" Best vio ");
50 series2 = new XYSeries (" Best score ");

Appendix A. Implementation 65
51 series3 = new XYSeries (" Working vio ");
52 series4 = new XYSeries (" Working score ");
53 seriesCol . addSeries ( series );
54 seriesCol . addSeries ( series2 );
55 seriesCol . addSeries ( series3 );
56 seriesCol . addSeries ( series4 );
57
58
59 startTime = System . currentTimeMillis ();
60 boolean test = ( super . type . compareTo ( Type . Rounds ) == 0) ? (
loopCounter < maxRounds ) : ( System . currentTimeMillis () - startTime ) <
getTimeToRun ();
61 while ( test ) {
62 localLoopCounter = 0;
63 int progress = ( super . type . compareTo ( Type . Rounds ) == 0) ? (100 *
64
loopCounter / maxRounds ) : ( int ) (100 * ( System . currentTimeMillis () -
startTime ) / getTimeToRun ());
65 setProgress ( progress );
66 working = getInitialSchedule ();
67 /* GREEDY */
68 {
69 Day day ;
70 Shift s;
71 Doctor d;
72 for ( int i = 0; i < working . size (); i ++) {
73 day = working . getDay (i);
74 if (!( day . isWeekend () || day . isHoliday ())) {
75 if ( getDoS (). compareTo ( DayOrShift . Day ) == 0) {
76 Change change = working . getBestChange ( day .
getDayID () , RCLsize , minimize , getRules ());
77 working . performChange ( change , false );
78 continue ;
79 }
80 for ( int j = 0; j < day . size (); j ++) {
81 s = day . getShift (j);
82 if (s. isMiddayShift ()) {
83 d = working . getBestDoctor (day , s, RCLsize ,
minimize , getRules ());
84 working . assignDoctor2Shift (day , d, s.
getShiftInt () , false );
85 }
86 }
87 }
88 }
89 }
90
91 /* LOCAL SEARCH : */
92 double timeToRunLocal = getTimeToRun () / 5;
93 int newLocalScore ;
94 {
95 double startTimeLocal = System . currentTimeMillis ();
96 boolean test2 = ( super . type . compareTo ( Type . Rounds ) == 0) ? (
localLoopCounter < maxLocalLoops ) : ( System . currentTimeMillis () -
startTimeLocal ) < timeToRunLocal ;

Appendix A. Implementation 66
97 while ( test2 ) {
98 c = Math . random () * 1 > 0.5 ? n_rot . nextChange ( working ) :
n_inv . nextChange ( working );
99 working . performChange (c, false );
100 Pair < Integer , Pair < HashMap < Shift , HashSet >>, HashMap < Shift , HashSet >>>> sol = working .
getSolutionValue ( false , getRules ());
101 newLocalScore = sol . getE ();
102 newLocalVio = sol . getV (). getE (). size ();
103 if ( newLocalVio < bestVio ) {
104 setBestSchedule ( working );
105 localImprovements ++;
106 acceptedSolutions ++;
107 } else if ( newLocalVio == bestVio ) {
108 if (( newLocalScore > bestScore && ! minimize ) || (
newLocalScore < bestScore && minimize )) {
109 setBestSchedule ( working );
110 localImprovements ++;
111 acceptedSolutions ++;
112 } else {
113 working . performChange (c, true );
114 rejectedSolutions ++;
115 }
116 } else {
117 working . performChange (c, true );
118 rejectedSolutions ++;
119 }
120 test2 = ( super . type . compareTo ( Type . Rounds ) == 0) ? (
localLoopCounter ++ < maxLocalLoops ) : ( System . currentTimeMillis () -
startTimeLocal ) < timeToRunLocal ;
121 point = new XYDataItem ( super . type . compareTo ( Type . Rounds )
== 0 ? counter : ( System . currentTimeMillis () - startTime ), bestVio );
122 point2 = new XYDataItem ( super . type . compareTo ( Type . Rounds )
== 0 ? counter : ( System . currentTimeMillis () - startTime ), bestScore );
123 point3 = new XYDataItem ( super . type . compareTo ( Type . Rounds )
== 0 ? counter : ( System . currentTimeMillis () - startTime ), newLocalVio );
124 point4 = new XYDataItem ( super . type . compareTo ( Type . Rounds )
== 0 ? counter ++ : ( System . currentTimeMillis () - startTime ), newLocalScore );
125 series . add ( point );
126 series2 . add ( point2 );
127 series3 . add ( point3 );
128 series4 . add ( point4 );
129 }
130 }
131
132 test = ( super . type . compareTo ( Type . Rounds ) == 0) ? ( loopCounter ++
< maxRounds ) : (( System . currentTimeMillis () - startTime ) < getTimeToRun ());
133 firePropertyChange (" score ", null , bestScore );
134 firePropertyChange (" violations ", null , bestVio );
135 }
136
137 printGRASPStatsToConsole ();
138 printMetaStatsToConsole ();
139 } catch ( Exception e) {
140 System . out . println (" Caught exception : " + e. getCause ());

Appendix A. Implementation 67
141 e. printStackTrace ();
142 }
143
144 getBestSchedule (). setRCL ( this . RCLsize );
145 getBestSchedule (). setConstructorID ( this . hashCode ());
146 getBestSchedule (). setDoS ( this . dos );
147
148 return null ;
149 }
150
151 public void printGRASPStatsToConsole () {
152 Pair < Integer , Pair < HashMap < Shift , HashSet >>, HashMap
< Shift , HashSet >>>> workingSol = working .
getSolutionValue ( false , null );
153 System . out . println (" -------------- GRASP STATS : --------------");
154 System . out . println (" Working value : " + workingSol . getE () + "||" +
workingSol . getV (). getE (). size ());
155 System . out . println (" -------------- --------------");
156 }
157 }
A.4 Simulated Annealing metaheuristic
1 package heuristic . meta ;
2
3 import basic . Rules ;
4 import changes . RotationInt ;
5 import ds. Doctor ;
6 import ds. Pair ;
7 import ds. Schedule ;
8 import ds. Shift ;
9 import heuristic . Metaheuristic ;
10 import java . beans . ExceptionListener ;
11 import java . util . HashMap ;
12 import java . util . HashSet ;
13 import org . jfree . data .xy. XYDataItem ;
14 import org . jfree . data .xy. XYSeries ;
15 import org . jfree . data .xy. XYSeriesCollection ;
16
17 public class Simulated_annealing extends Metaheuristic implements
18
ExceptionListener {
19 private double temp ;
20 private double alpha = 0.999;
21 private double temp_end ;
22 private boolean minimize ;
23 private XYDataItem tempPoint ;
24 private XYSeries tempSeries ;
25
26 public Simulated_annealing ( double timeToRun , int maxRotation , Rules myRules ,
RotationInt rotationInt , Schedule s, Type t, int rounds , boolean diagram ,
boolean minimize ) {

Appendix A. Implementation 68
27 super ( timeToRun , maxRotation , myRules , rotationInt , s, t, rounds );
28 this . minimize = minimize ;
29 this . temp = 1000;
30 this . temp_end = 0.001;
31 }
32
33 @Override
34 public Void doInBackground () {
35 XYDataItem point ;
36 XYDataItem point2 ;
37 XYDataItem point3 ;
38 XYDataItem point4 ;
39 try {
40 seriesCol = new XYSeriesCollection ();
41 series = new XYSeries (" Best vio ");
42 series2 = new XYSeries (" Best score ");
43 series3 = new XYSeries (" Working vio ");
44 series4 = new XYSeries (" Working score ");
45 tempSeries = new XYSeries (" Temperature ");
46 seriesCol . addSeries ( series );
47 seriesCol . addSeries ( series2 );
48 seriesCol . addSeries ( series3 );
49 seriesCol . addSeries ( series4 );
50 startTime = System . currentTimeMillis ();
51 int newLocalScore = 0;
52 int oldScore ;
53 boolean test = ( super . type . compareTo ( Type . Rounds ) == 0) ? (
54
loopCounter < maxRounds ) : ( System . currentTimeMillis () - startTime ) <
getTimeToRun ();
55 int progress = ( super . type . compareTo ( Type . Rounds ) == 0) ? (100 *
loopCounter / maxRounds ) : ( int ) (100 * ( System . currentTimeMillis () -
startTime ) / getTimeToRun ());
56 setProgress ( progress );
57 while ( test && temp > temp_end ) {
58 oldScore = newLocalScore ;
59 c = Math . random () * 1 > 0.5 ? n_rot . nextChange ( working ) : n_inv .
nextChange ( working );
60 working . performChange (c, false );
61 Pair < Integer , Pair < HashMap < Shift , HashSet >>,
HashMap < Shift , HashSet >>>> workingSol = working .
getSolutionValue ( false , getRules ());
62 newLocalScore = workingSol . getE ();
63 newLocalVio = workingSol . getV (). getE (). size ();
64 double solutionValue_increase = newLocalScore - oldScore ;
65 double rand = Math . random ();
66
67 if ( newLocalVio < bestVio ) {
68 setBestSchedule ( working );
69 localImprovements ++;
70 acceptedSolutions ++;
71 } else if ( newLocalVio == bestVio ) {
72 if (( solutionValue_increase > 0 && ! minimize ) || (
solutionValue_increase < 0 && minimize )) {

Appendix A. Implementation 69
73 if (( newLocalScore > bestScore && ! minimize ) || (
newLocalScore < bestScore && minimize )) {
74 setBestSchedule ( working );
75 localImprovements ++;
76 acceptedSolutions ++;
77 }
78 } else {
79 if ( rand < ( Math . exp (( solutionValue_increase ) / temp ))) {
80 acceptedSolutions ++;
81 } else {
82 working . performChange (c, true );
83 rejectedSolutions ++;
84 }
85 }
86 } else {
87 rejectedSolutions ++;
88 working . performChange (c, true );
89 }
90 progress = ( super . type . compareTo ( Type . Rounds ) == 0) ? (100 *
loopCounter / maxRounds ) : ( int ) (100 * ( System . currentTimeMillis () -
startTime ) / getTimeToRun ());
91 setProgress ( progress );
92 firePropertyChange (" score ", null , bestScore );
93 firePropertyChange (" violations ", null , bestVio );
94 test = ( super . type . compareTo ( Type . Rounds ) == 0) ? ( loopCounter <
maxRounds ) : ( System . currentTimeMillis () - startTime ) < getTimeToRun ();
95 temp = alpha * temp ;
96 point = new XYDataItem ( super . type . compareTo ( Type . Rounds ) == 0 ?
loopCounter : ( System . currentTimeMillis () - startTime ), bestVio );
97 point2 = new XYDataItem ( super . type . compareTo ( Type . Rounds ) == 0 ?
loopCounter : ( System . currentTimeMillis () - startTime ), bestScore );
98 point3 = new XYDataItem ( super . type . compareTo ( Type . Rounds ) == 0 ?
loopCounter : ( System . currentTimeMillis () - startTime ), newLocalVio );
99 point4 = new XYDataItem ( super . type . compareTo ( Type . Rounds ) == 0 ?
loopCounter : ( System . currentTimeMillis () - startTime ), newLocalScore );
100 tempPoint = new XYDataItem ( loopCounter ++ , temp );
101 series . add ( point );
102 series2 . add ( point2 );
103 series3 . add ( point3 );
104 series4 . add ( point4 );
105 tempSeries . add ( tempPoint );
106 }
107 printSAStatsToConsole ();
108 printMetaStatsToConsole ();
109 getBestSchedule (). setOptimizer ( this );
110
111 } catch ( Exception e) {
112 System . out . println (" Caught exception : " + e. getCause ());
113 e. printStackTrace ();
114 }
115 return null ;
116 }
117
118 public void printSAStatsToConsole () {

Appendix A. Implementation 70
119 Pair < Integer , Pair < HashMap < Shift , HashSet >>, HashMap
< Shift , HashSet >>>> workingSol = working .
getSolutionValue ( false , null );
120 System . out . println (" -------------- SA STATS : --------------");
121 System . out . println (" Alpha : " + alpha );
122 System . out . println (" Working value : " + workingSol . getE ());
123 System . out . println (" Violations : " + workingSol . getV (). getE (). size ());
124 System . out . println (" Initial value : " + initialScore );
125 System . out . println (" Stopped due to: " + (( System . currentTimeMillis () -
startTime ) > getTimeToRun () ? " Running time "
126 : ( loopCounter > maxRounds ? " Loops " : ( temp < temp_end ? "
Temperature "
127 : " Not running time , temp nor rounds "))));
128 System . out . println (" -------------- --------------");
129 }
130
131 @Override
132 public void exceptionThrown ( Exception e) {
133 System . out . println (" Exception was caught .. I think ... Here it is:" + e.
getCause ());
134 e. printStackTrace ();
135 }
136
137 public XYSeries getTempSeries () {
138 return tempSeries ;
139 }
140 }
A.5 Choosing the assignment
A.5.1 Shift assignments
1 /* *
2 * Returns the best doctor for a given shift on a given day .
3 *
4 * @param day
5 * the day
6 * @param RCLsize
7 * the size of the RCL
8 * @param shift
9 * the shift
10 * @return The best doctor for the shift
11 */
12 public Doctor getBestDoctor (
13 Day day , Shift shift , RCLParameter RCLsize , boolean minimize , Rules
14
rules ) {
15 if ( rules != null ) {
16 this . myRules = rules ;
17 }
18

Appendix A. Implementation 71
19 Vector >> bestDocs = new Vector > >();
20 Pair < Integer , Pair < HashMap < Shift , HashSet >>, HashMap
< Shift , HashSet >>>> sol ;
21 int vio ;
22
23 myFore :
24 for ( Doctor d : docs ) {
25
26 int score = 0;
27 if ( this . isThisDoctorAroundThisShift (d, shift )) {
28 continue myFore ;
29 }
30 sol = this . getShiftValue (d, day . getDayID () , shift . getShiftInt () ,
false , false , true , true );
31 score = sol . getE ();
32 vio = sol . getV (). getE (). size ();
33
34 if ( bestDocs . size () == 0) {
35 bestDocs . add ( new Pair < Doctor , Pair < Integer , Integer > >(d, new Pair
< Integer , Integer >( score , vio )));
36 } else {
37 int size = bestDocs . size ();
38 myFor :
39 for ( int i = 0; i <
40 size ; i ++) {
41 Pair < Doctor , Pair < Integer , Integer >> docScore = bestDocs . get (
i);
42 if ( vio < docScore . getV (). getV ()) {
43 bestDocs . add ( bestDocs . indexOf ( docScore ),
44 new Pair < Doctor , Pair < Integer , Integer > >(d, new
Pair < Integer , Integer >( score , vio )));
45 break myFor ;
46 } else if ( vio == docScore . getV (). getV () && ( docScore . getV ().
getE () = score && minimize )
)) {
47 bestDocs . add ( bestDocs . indexOf ( docScore ),
48 new Pair < Doctor , Pair < Integer , Integer > >(d, new
Pair < Integer , Integer >( score , vio )));
49 break myFor ;
50 } else {
51 bestDocs . add ( new Pair < Doctor , Pair < Integer , Integer > >(d,
new Pair < Integer , Integer >( score , vio )));
52 break myFor ;
53 }
54 }
55 }
56 }
57
58 switch ( RCLsize ) {
59 case Best :
60 bestDocs . setSize (1) ;
61 break ;
62 case Fifty :
63 bestDocs . setSize (( int ) ( bestDocs . size () * 0.5) );

Appendix A. Implementation 72
64 break ;
65 case TwentyFive :
66 bestDocs . setSize (( int ) ( bestDocs . size () * 0.25) );
67 break ;
68 case SeventyFive :
69 bestDocs . setSize (( int ) ( bestDocs . size () * 0.75) );
70 break ;
71 default :
72 break ;
73 }
74
75 double randDoc = Math . random () * bestDocs . size ();
76 Doctor bestDoc = bestDocs . get (( int ) randDoc ). getE ();
77 return bestDoc ;
78 }
Listing A.1: Shift assignments
A.5.2 Permutations of size k chosen from N elements
1 package basic ;
2
3 import java . util . ArrayList ;
4 import ds. Doctor ;
5
6 /* ******************************************************************************
7 * Compilation : javac Perm . java Execution : java Permutations N k
8 *
9 * Enumerates all permutations of size k chosen from N elements . % java
10 * Permutations 4 2 | sort ab ac ad ba bc bd ca cb cd da db dc
11 *
12 * Limitations ----------- * Assumes N > res ;
18
19 private ArrayList < ArrayList < Doctor >> enumerate2 ( ArrayList < Doctor > b, int n,
20
int r) {
21 if (r == 0) {
22 ArrayList < Doctor > subres = new ArrayList < Doctor >() ;
23 for ( int i = n; i < b. size (); i ++) {
24 subres . add (b. get (i));
25 }
26 res . add ( subres );
27
28 } else {
29 for ( int i = 0; i < n; i ++) {
30 swap2 (b, i, n - 1);
31 enumerate2 (b, n - 1, r - 1);
32 swap2 (b, i, n - 1);

Appendix A. Implementation 73
33 }
34 return res ;
35 }
36 return null ;
37 }
38
39 public ArrayList < ArrayList < Doctor >> choose2 ( ArrayList < Doctor > b, int k) {
40 res = new ArrayList < ArrayList < Doctor > >();
41
42 return enumerate2 (b, b. size () , k);
43 }
44
45 private void swap2 ( ArrayList < Doctor > b, int i, int j) {
46 Doctor temp = b. get (i);
47 b. set (i, b. get (j));
48 b. set (j, temp );
49 }
50
51 public ArrayList < ArrayList < Doctor >> getRes () {
52 return res ;
53 }
54 }
A.5.3 Day assignments
1 /* *
2 * Returns the best doctor for a given shift on a given day .
3 *
4 * @param dayInt
5 * the day
6 * @param RCLsize
7 * the size the RCL
8 * @param minimizing
9 * @return The best doctor for the shift
10 */
11 public Change getBestChange (
12 int dayInt , RCLParameter RCLsize , boolean minimizing , Rules rules ) {
13
14 if ( rules != null ) {
15 this . myRules = rules ;
16 }
17
18 Vector >> bestChange = new Vector > >();
20 Permutation t = new Permutation ();
21
22 ArrayList < Doctor > doc = new ArrayList < Doctor >() ;
23 doc . addAll ( docs );
24
25 t. choose2 (doc , this . get ( dayInt ). getAllMiddayShifts (). size ());
26
27 ArrayList < ArrayList < Doctor >> set = t. getRes ();

Appendix A. Implementation 74
28 Change c;
29 for ( int i = 0; i < set . size (); i ++) {
30 c = new Change ();
31 ArrayList < Doctor > subsetDoctors = set . get (i);
32 HashSet < Shift > shiftset = this . get ( dayInt ). getAllMiddayShifts ();
33 ArrayList < Shift > sSet = new ArrayList < Shift >() ;
34 sSet . addAll ( shiftset );
35
36 for ( int j = 0; j < shiftset . size (); j ++) {
37 c. put ( sSet . get (j), subsetDoctors . get (j));
38 }
39
40 Pair < Integer , Pair < HashMap < Shift , HashSet >>,
HashMap < Shift , HashSet >>>> sol = this . getSolutionValue (
false , null );
41 int oldScore = sol . getE ();
42 int oldVio = sol . getV (). getE (). size ();
43
44 this . performChange (c, false );
45
46 Pair < Integer , Pair < HashMap < Shift , HashSet >>,
HashMap < Shift , HashSet >>>> newSol = this .
getSolutionValue ( false , null );
47 int newScore = newSol . getE ();
48 int newvio = newSol . getV (). getE (). size ();
49
50
51 double scoreInc = newScore - oldScore ;
52 int vioInc = newvio - oldVio ;
53 // Undo the change :
54 this . performChange (c, true );
55 // Sort by best change :
56 if ( bestChange . size () == 0) {
57 bestChange . add ( new Pair < Change , Pair < Double , Integer > >(c, new
Pair < Double , Integer >( scoreInc , vioInc )));
58 } else {
59 myFor :
60 for ( int k = 0; k < bestChange . size (); k ++) {
61 Pair < Change , Pair < Double , Integer >> changeScore = bestChange .
get (k);
62 if ( changeScore . getV (). getV () > vioInc ) {
63 bestChange . add ( bestChange . indexOf ( changeScore ),
64 new Pair < Change , Pair < Double , Integer > >(c, new
Pair < Double , Integer >( scoreInc , vioInc )));
65 break myFor ;
66 }
67 if ( changeScore . getV (). getV () == vioInc ) {
68 if (( changeScore . getV (). getE () < scoreInc && ! minimizing )
|| ( changeScore . getV (). getE () > scoreInc && minimizing )) {
69 bestChange . add ( bestChange . indexOf ( changeScore ),
70 new Pair < Change , Pair < Double , Integer > >(c,
new Pair < Double , Integer >( scoreInc , vioInc )));
71 break myFor ;
72 }
73

Appendix A. Implementation 75
74 if ( bestChange . indexOf ( changeScore ) == bestChange . size ()
- 1) {
75 bestChange . add ( new Pair < Change , Pair < Double , Integer
> >(c, new Pair < Double , Integer >( scoreInc , vioInc )));
76 break myFor ;
77 }
78 }
79 }
80 }
81 }
82
83 switch ( RCLsize ) {
84 case Best :
85 bestChange . setSize (1) ;
86 break ;
87 case Fifty :
88 bestChange . setSize (( int ) ( bestChange . size () * 0.5) );
89 break ;
90 case TwentyFive :
91 bestChange . setSize (( int ) ( bestChange . size () * 0.25) );
92 break ;
93 case SeventyFive :
94 bestChange . setSize (( int ) ( bestChange . size () * 0.75) );
95 break ;
96 default :
97 break ;
98 }
99 double randDoc = Math . random () * bestChange . size ();
100 Change out = bestChange . get (( int ) randDoc ). getE ();
101
102 return out ;
103 }
Listing A.2: Day assignments

Appendix B
GAMS Model
This chapter contains the GAMS model for the DRP subproblem described in chapter
5. The model is included in the report that is produced by GAMS. A solution found by
the greedy approach and GRASP is included respectively for comparison.
B.1 The night, evening and wishes
JST PZH HP SDA HMM OSJ
08-09-08 FRI2 02-09-08 V15 15-09-08 V12 20-09-08 V7 01-09-08 V11 01-09-08 FERIE
09-09-08 FRI2 08-09-08 Ss 19-09-08 Ss 21-09-08 V15 06-09-08 K15 02-09-08 FERIE
16-09-08 FRI2 09-09-08 FRI2 01-09-08 FRI2 01-09-08 FRI2 07-09-08 V1 03-09-08 FERIE
04-09-08 V14 19-09-08 FRI2 04-09-08 FRI2 09-09-08 FRI2 11-09-08 V12 04-09-08 FERIE
13-09-08 V8 09-09-08 FRI2 12-09-08 FRI2 16-09-08 Ss 05-09-08 FERIE
14-09-08 V2 18-09-08 FRI2 15-09-08 FERIE 20-09-08 K14 06-09-08 FERIE
B.2 The GAMS model and report
GAMS Rev 140 Sun Sparc / SOLAR
23-09-08 FRI2 26-09-08 FERIE 21-09-08 V3 07-09-08 FERIE
10/28/08 18:25:02 Page 1
25-09-08 K16
08-09-08 FERIE
09-09-08 FERIE
10-09-08 FERIE
11-09-08 FERIE
12-09-08 FERIE
13-09-08 FERIE
14-09-08 FERIE
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
C o m p i l a t i o n
76

Appendix B. GAMS Model 77
2
3 option iterlim =999999999; // avoid limit on iterations
4 option reslim =50000; // timelimit for solver
5 option optcr =0.0; // gap tolerance
6 option solprint = OFF ; // include solution print in . lst file
7 option limrow =0; // limit number of rows in . lst file
8 option limcol =0; // limit number of columns in . lst file
9
//------------------------------------------------------------------------------
10 SETS
11 day days / 1 * 28 /
12 mondays ( day ) mondays / 1, 8,
15 , 22 /
13 fridays ( day ) fridays / 5, 12 ,
19 , 26 /
14 weekend ( day ) weekends / 6, 7,
13 , 14 , 20 , 21 , 27 , 28 /
15 workingdays ( day )
16 shift shifts / 1 * 4 /
17 nightshift ( shift ) night shifts / 1 /
18 noonshift ( shift ) noon shift / 2 /
19 afternoonshift ( shift ) afternoon shift / 3 /
20 eveningshift ( shift ) evening shift / 4 /
21 assignmentshifts ( shift )
22 nonshifts ( shift )
23 doctor doctors / jst , pzh
, hp , sda , hmm , osj /
24 index counting vars for the b-eq ’s / 0 * 7 /
25 index0 ( index ) / 0 /
26 index1 ( index ) / 1 /
27 index2 ( index ) / 2 /
28 index3 ( index ) / 3 /
29 index4 ( index ) / 4 /
30 index6a ( index ) / 6 /
31 index6b ( index ) / 7 /;
32 nonshifts ( shift ) = nightshift ( shift ) + eveningshift
( shift );
33 assignmentshifts ( shift ) = noonshift ( shift ) +
afternoonshift ( shift );
34 workingdays ( day ) = day ( day ) - weekend ( day );
35
36 display workingdays ;
37
38 PARAMETERS
39 b(day , shift , doctor ) define evening and night shifts
40 /(4.4. jst ) 1, (13.2. jst ) 1, (13.3. jst ) 1, (14.2. jst ) 1,
41 (2.4. pzh ) 1, (8.2. pzh ) 1, (8.3. pzh ) 1,
42 (15.4. hp) 1, (19.2. hp) 1, (19.3. hp) 1,
43 (20.2. sda ) 1, (20.3. sda ) 1, (21.4. sda ) 1,
44 (1.4. hmm ) 1, (6.2. hmm ) 1, (6.3. hmm ) 1, (7.2. hmm ) 1, (11.4. hmm ) 1,
(16.2. hmm ) 1, (16.3. hmm ) 1, (20.2. hmm ) 1,
(20.3. hmm ) 1, (21.2. hmm ) 1,
45 (25.4. hmm ) 1/

Appendix B. GAMS Model 78
46 c(day , shift , doctor ) define requests for days off or shifts off
( meaning you can have a shift up to or af
ter a shift off )
47 /(8.3. jst ) 1, (9.3. jst ) 1, (16.3. jst ) 1,
48 (9.3. pzh ) 1, (19.3. pzh ) 1,
49 (1.3. hp) 1, (4.3. hp) 1, (9.3. hp) 1, (18.3. hp) 1, (23.3. hp) 1,
50 (1.3. sda ) 1, (9.3. sda ) 1, (12.3. sda ) 1, (15.2. sda ) 1, (15.3. sda )
1, (26.2. sda ) 1, (26.3. sda ) 1,
51 (8.2. hmm ) 1, (8.3. hmm ) 1, (9.2. hmm ) 1, (9.3. hmm ) 1, (10.2. hmm ) 1,
(10.3. hmm ) 1, (11.2. hmm ) 1, (11.3. hmm ) 1,
(12.2. hmm ) 1, (12.3. hmm ) 1,
GAMS Rev 140 Sun Sparc / SOLAR
10/28/08 18:25:02 Page 2
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
C o m p i l a t i o n
52 (13.2. hmm ) 1, (13.3. hmm ) 1, (14.2. hmm ) 1, (14.3. hmm ) 1,
53 (1.2. osj ) 1, (1.3. osj ) 1, (2.2. osj ) 1, (2.3. osj ) 1, (3.2. osj ) 1,
(3.3. osj ) 1, (4.2. osj ) 1, (4.3. osj ) 1, (5.
2. osj ) 1, (5.3. osj ) 1, (6.2. osj ) 1,
54 (6.3. osj ) 1, (7.2. osj ) 1, (7.3. osj ) 1
55 /
56 s(day , shift ) define extra doctor demands
57 /(1.2) 1, (8.2) 1, (15.2) 1, (22.2) 1/
58
59 VARIABLES
60 x(day , shift , doctor ) doctors on shifts
61 y(day , shift , doctor , index ) counting var
62 z solution value
63 k(day , shift , doctor , index ) counter the the y- vars
64 dmax doctor max
65 dmin doctor min ;
66
67
68 BINARY VARIABLE x(day , shift , doctor ), y(day , shift , doctor , index ), k(day , shift
, doctor , index );
69 POSITIVE VARIABLE dmax , dmin ;
70
71 EQUATIONS
72 VALUE define objective function
73
74 H0a no two assignment shifts in a row
75 H0b no eveningshift after an afternoonshift
76 H0c no nightshift before a noonshift
77 H1 doctor cannot have a noon shift after an evening
shift
78 H2 doctor cannot have a noon shift nor an afternoon
shift after a night shift
79 H3a no shifts must be granted that has been blocked
80 H3b no shifts must be granted that has requested off
81 H4 doctor demands
82 H5 no other assignments
83

Appendix B. GAMS Model 79
84 B0 no doctor should have both monday noon shifts and
friday afternoon shifts in the same week
85 B1 no doctor should have both friday afternoon shift
and the following monday noon shift
86 B2a shifts should be divided equally - the max var
87 B2b shifts should be divided equally - the min var
88 B3 no doctor should have a noon nor afternoon shifts
two days in a row
89 B4 no doctor should have the afternoon shift the day
after an evening shift
90 B5 no doctor should have the noon shift the same day
as an evening shift
91 B6a no doctor should have the noon shift the day after
an afternoon shift
92 B6b no doctor should have the afternoon shift the day
93
after a noon shift ;
94 VALUE .. z =e= sum (( workingdays ( day ),assignmentshifts ( shift
95
),doctor , index ),y(day , shift , doctor , index ))
+ dmax - dmin ;
96 H0a (day , shift , doctor ) .. x(day , shift , doctor
) + x(day , shift +1 , doctor ) =l= 1;
97 H0b (day , eveningshift ( shift ),doctor ).. x(day , shift -1 ,
doctor ) + b(day , shift , doctor ) =l= 1;
98 H0c (day , nightshift ( shift ),doctor ).. x(day , shift +1 ,
doctor ) + b(day , shift , doctor ) =l= 1;
99 H1(day , noonshift ( shift ),doctor ) .. b(day , shift +2 ,
doctor ) + x( day +1 , shift , doctor ) =l= 1;
100 H2(day , nightshift ( shift ),doctor ) .. b(day , shift , doctor
) + x(day , shift +1 , doctor ) + x(day , shift +2 ,
doctor ) =l= 1;
101 H3a (day , shift , doctor ) .. x(day , shift , doctor
) + b(day , shift , doctor ) =l= 1;
GAMS Rev 140 Sun Sparc / SOLAR
10/28/08 18:25:02 Page 3
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
C o m p i l a t i o n
102 H3b (day , shift , doctor ) .. x(day , shift , doctor
) + c(day , shift , doctor ) =l= 1;
103 H4( workingdays ( day ),assignmentshifts ( shift )) .. sum ( doctor ,x(day ,
shift , doctor )) =e= 1 + s(day , shift );
104 H5(day , nonshifts ( shift ),doctor ) .. x(
105
106
day , shift , doctor ) =e= 0;
107 B0( mondays ( day ),noonshift ( shift ),doctor , index0 ( index )) ..x(day , shift , doctor
) + x( day +4 , shift +1 , doctor ) =e=
108 1 + y(day ,
shift , doctor , index ) - k(day , shift , doctor ,in
dex );

Appendix B. GAMS Model 80
109 B1( fridays ( day ),noonshift ( shift ),doctor , index1 ( index )) ..x( day +3 , shift ,
doctor ) + x(day , shift +1 , doctor ) =e=
110 1 + y(day ,
shift , doctor , index ) - k(day , shift , doctor ,in
dex );
111 B2a ( doctor ).. sum (( workingdays (
day ),assignmentshifts ( shift )),x(day , shift ,d
octor )) =l= dmax ;
112 B2b ( doctor ).. sum (( workingdays (
day ),assignmentshifts ( shift )),x(day , shift ,d
octor )) =g= dmin ;
113 B3( workingdays ( day ),assignmentshifts ( shift ),doctor , index4 ( index )).. x(day
, shift , doctor ) + x( day +1 , shift , doctor ) =e=
114 1 + y(day ,
shift , doctor , index ) - k(day , shift , doctor ,in
dex );
115 B4(day , afternoonshift ( shift ),doctor , index2 ( index )) .. x(day , shift , doctor
) + b(day -1 , shift +1 , doctor ) =e=
116 1 + y(day ,
shift , doctor , index ) - k(day , shift , doctor ,in
dex );
117 B5(day , noonshift ( shift ),doctor , index3 ( index )) .. b(day , shift +2 ,
doctor ) + x(day , shift , doctor ) =e=
118 1 + y(day ,
shift , doctor , index ) - k(day , shift , doctor ,in
dex );
119 B6a (day , noonshift ( shift ),doctor , index6a ( index )) .. x(day , shift +1 ,
doctor ) + x( day +1 , shift , doctor ) =e=
120 1 + y(day ,
shift , doctor , index ) - k(day , shift , doctor ,in
dex );
121 B6b (day , noonshift ( shift ),doctor , index6b ( index )) .. x(day , shift , doctor
) + x( day +1 , shift +1 , doctor ) =e=
122 1 + y(day ,
123
shift , doctor , index ) - k(day , shift , doctor ,in
dex );
124 MODEL ASSIGNMENT / VALUE ,H0a ,H0b ,H0c ,H1 ,H2 ,H3a ,H3b ,H4 ,H5 ,B0 ,B1 ,B2a ,B2b ,B3 ,B4
125
,B5 ,B6a , B6b /;
126 SOLVE ASSIGNMENT USING MIP MINIMIZING z;
127
128 display x.l;
COMPILATION TIME = 0.010 SECONDS 3.2 Mb SOL215 -140 Nov 11 , 2004
GAMS Rev 140 Sun Sparc / SOLAR
10/28/08 18:25:02 Page 4
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
E x e c u t i o n
---- 36 SET workingdays

Appendix B. GAMS Model 81
1 , 2 , 3 , 4 , 5 , 8 , 9 , 10 , 11 , 12 , 15 , 16 ,
25 , 26
17 , 18 , 19 , 22 , 23 , 24
GAMS Rev 140 Sun Sparc / SOLAR
10/28/08 18:25:02 Page 5
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
Model Statistics SOLVE ASSIGNMENT Using MIP From line 126
MODEL STATISTICS
BLOCKS OF EQUATIONS 19 SINGLE EQUATIONS 4031
BLOCKS OF VARIABLES 6 SINGLE VARIABLES 3747
NON ZERO ELEMENTS 9831 DISCRETE VARIABLES 3744
GENERATION TIME = 0.148 SECONDS 4.5 Mb SOL215 -140 Nov 11 , 2004
EXECUTION TIME = 0.162 SECONDS 4.5 Mb SOL215 -140 Nov 11 , 2004
GAMS Rev 140 Sun Sparc / SOLAR
10/28/08 18:25:02 Page 6
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
Solution Report SOLVE ASSIGNMENT Using MIP From line 126
S O L V E S U M M A R Y
MODEL ASSIGNMENT OBJECTIVE z
TYPE MIP DIRECTION MINIMIZE
SOLVER CPLEX FROM LINE 126
**** SOLVER STATUS 1 NORMAL COMPLETION
**** MODEL STATUS 1 OPTIMAL
**** OBJECTIVE VALUE 2.0000
RESOURCE USAGE , LIMIT 2.570 50000.000
ITERATION COUNT , LIMIT 603 999999999
GAMS / Cplex Nov 11 , 2004 SOL .CP.CL 21.5 026.029.041. SOL For Cplex 9.0
Cplex 9.0.2 , GAMS Link 26
Using environment variable ILOG_LICENSE_FILE to look for a Cplex license .
Proven optimal solution .
MIP Solution : 2.000000 (603 iterations , 16 nodes )
Final Solve : 2.000000 (0 iterations )
Best possible : 2.000000
Absolute gap : 0.000000
Relative gap : 0.000000

Appendix B. GAMS Model 82
**** REPORT SUMMARY : 0 NONOPT
GAMS Rev 140 Sun Sparc / SOLAR
0 INFEASIBLE
0 UNBOUNDED
10/28/08 18:25:02 Page 7
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
E x e c u t i o n
---- 128 VARIABLE x.L doctors on shifts
jst pzh hp sda hmm osj
1 .2 1.000 1.000
1 .3 1.000
2 .2 1.000
2 .3 1.000
3 .2 1.000
3 .3 1.000
4 .2 1.000
4 .3 1.000
5 .2 1.000
5 .3 1.000
8 .2 1.000 1.000
8 .3 1.000
9 .2 1.000
9 .3 1.000
10.2 1.000
10.3 1.000
11.2 1.000
11.3 1.000
12.2 1.000
12.3 1.000
15.2 1.000 1.000
15.3 1.000
16.2 1.000
16.3 1.000
17.2 1.000
17.3 1.000
18.2 1.000
18.3 1.000
19.2 1.000
19.3 1.000
22.2 1.000 1.000
22.3 1.000
23.2 1.000
23.3 1.000
24.2 1.000
24.3 1.000
25.2 1.000
25.3 1.000
26.2 1.000
26.3 1.000

Appendix B. GAMS Model 83
EXECUTION TIME = 0.020 SECONDS 3.4 Mb SOL215 -140 Nov 11 , 2004
GAMS Rev 140 Sun Sparc / SOLAR
10/28/08 18:25:02 Page 8
G e n e r a l A l g e b r a i c M o d e l i n g S y s t e m
E x e c u t i o n
USER : Informatics and Mathematical Modelling A041202 :1254 AP - SOL
Technical University of Denmark DC2412
License for teaching and research at degree granting institutions
**** FILE SUMMARY
Input / xbar / nas2 / home1 / s03 / s032651 / GAMS / Assignment . gms
Output / xbar / nas2 / home1 / s03 / s032651 / GAMS / Assignment . lst

Appendix B. GAMS Model 84
B.3 The solved model
This section contains the solutions to the subproblem of the DRP.
B.3.1 GAMS solution
Table B.1: Solution found by GAMS
Day JST HMM OSJ SDA PZH HP
01-09-2008 S2, V11, S1, S1,
02-09-2008 S1, S2, V15,
03-09-2008 S2, S1,
04-09-2008 V14, S2, S1,
05-09-2008 S2, S1,
06-09-2008
07-09-2008
08-09-2008 S1, S1, S2,
09-09-2008 S2, S1,
10-09-2008 S2, S1,
11-09-2008 V12, S1, S2,
12-09-2008 S1, S2,
13-09-2008
14-09-2008
15-09-2008 S1, S1, S2, V12,
16-09-2008 S2, S1,
17-09-2008 S2, S1,
18-09-2008 S2, S1,
19-09-2008 S1, S2,
20-09-2008
21-09-2008 V15,
22-09-2008 S1, S2, S1,
23-09-2008 S2, S1,
24-09-2008 S2, S1,
25-09-2008 S1, K16, S2,
26-09-2008 S1, S2,
27-09-2008
28-09-2008

Appendix B. GAMS Model 85
B.3.2 The best greedy solution
Table B.2: Best greedy, RCL 1
Day SDA HMM PZH HP OSJ JST
09-01-08 S1, V11, S2, S1,
09-02-08 S2, V15, S1,
09-03-08 S1, S2,
09-04-08 S2, S1, V14,
09-05-08 S1, S2,
09-06-08
09-07-08
09-08-08 S1, S2, S1,
09-09-08 S1, S2,
09-10-08 S2, S1,
09-11-08 V12, S1, S2,
09-12-08 S2, S1,
09-13-08
09-14-08
09-15-08 S1, S2, V12, S1,
09-16-08 S2, S1,
09-17-08 S1, S2,
09-18-08 S1, S2,
09-19-08 S1, S2,
09-20-08
09-21-08 V15,
09-22-08 S1, S2, S1,
09-23-08 S2, S1,
09-24-08 S1, S2,
09-25-08 K16, S1, S2,
09-26-08 S1, S2,
09-27-08
09-28-08

Appendix B. GAMS Model 86
B.3.3 The best GRASP solution
Table B.3: Best GRASP, RCL 1
Day SDA HMM PZH HP OSJ JST
09-01-08 V11, S1, S1, S2,
09-02-08 S2, V15, S1,
09-03-08 S1, S2,
09-04-08 S2, S1, V14,
09-05-08 S2, S1,
09-06-08
09-07-08
09-08-08 S1, S2, S1,
09-09-08 S1, S2,
09-10-08 S2, S1,
09-11-08 V12, S1, S2,
09-12-08 S1, S2,
09-13-08
09-14-08
09-15-08 S1, V12, S1, S2,
09-16-08 S1, S2,
09-17-08 S2, S1,
09-18-08 S1, S2,
09-19-08 S2, S1,
09-20-08
09-21-08 V15,
09-22-08 S2, S1, S1,
09-23-08 S1, S2,
09-24-08 S2, S1,
09-25-08 K16, S2, S1,
09-26-08 S1, S2,
09-27-08
09-28-08

Appendix C
Tests
This appendix contains the test instances and a summary for each metaheuristic param-
eter that was tested.
C.1 Test instances
The following subsections contains the test instances described by the night and evening
shifts and the doctors wishes.
87

Appendix C. Tests 88
C.1.1 Instance 0
JST PZH HP SDA HMM OSJ
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11 09-01-08 FERIE
09-13-08 V8 09-08-08 Ss 09-19-08 Ss 09-21-08 V15 09-06-08 K15 09-02-08 FERIE
09-14-08 V2 09-29-08 V14 11-01-08 V7 10-10-08 V15 09-07-08 V1 09-03-08 FERIE
10-09-08 Ss 10-25-08 V6 11-09-08 V15 10-11-08 Ss 09-11-08 V12 09-04-08 FERIE
10-13-08 V13 10-26-08 V2 12-01-08 V14 10-16-08 V12 09-16-08 Ss 09-05-08 FERIE
10-25-08 V3 11-05-08 V13 12-22-08 V15 12-16-08 V13 09-20-08 K14 09-06-08 FERIE
10-26-08 V13 11-21-08 V11 10-05-08 V13 12-24-08 V3 09-21-08 V3 09-07-08 FERIE
11-13-08 V11 11-29-08 V4 10-09-08 V13 09-01-08 FRI2 09-25-08 K16 10-13-08 FERIE
11-20-08 V15 11-30-08 V9 09-01-08 FRI2 09-09-08 FRI2 10-04-08 K6 10-14-08 FERIE
12-06-08 V8 12-16-08 V11 09-04-08 FRI2 09-12-08 FRI2 10-05-08 V13 10-15-08 FERIE
12-07-08 V10 12-27-08 V2 09-09-08 FRI2 09-15-08 FERIE 10-09-08 V13
12-22-08 V12 12-28-08 V6 09-18-08 FRI2 09-26-08 FERIE 10-17-08 K16
09-08-08 FRI2 12-31-08 V14 09-23-08 FRI2 09-29-08 FERIE 10-18-08 K19
09-09-08 FRI2 09-09-08 FRI2 09-30-08 FRI2 09-04-08 FERIE 10-19-08 K19
09-16-08 FRI2 09-19-08 FRI2 09-26-08 FERIE 10-02-08 FRI1 10-31-08 K6
09-29-08 FERIE 10-13-08 FERIE 10-07-08 FRI2 10-17-08 FERIE 11-01-08 V3
09-30-08 FERIE 10-14-08 FERIE 10-20-08 FRI2 10-20-08 FERIE 11-02-08 K6
10-01-08 FERIE 10-15-08 FERIE 10-23-08 FRI2 11-06-08 V13
10-02-08 FERIE 10-16-08 FERIE 10-27-08 FRI2 11-10-08 K16
10-03-08 FERIE 10-17-08 FERIE 10-15-08 FERIE 11-18-08 K16
10-04-08 FERIE 10-18-08 FERIE 10-16-08 FERIE 11-29-08 K4
10-05-08 FERIE 10-19-08 FERIE 10-17-08 FERIE 11-30-08 V12
10-06-08 FERIE 11-07-08 FRI1 11-06-08 FRI2 12-04-08 K6
10-07-08 FERIE 11-17-08 FRI1 11-11-08 FRI2 12-13-08 V9
10-22-08 FRI2 12-05-08 FRI2 11-17-08 FRI2 12-14-08 K5
10-23-08 FRI2 12-23-08 FERIE 11-18-08 FRI2 12-18-08 K16
10-31-08 FERIE 12-30-08 FERIE 11-20-08 FRI2 12-25-08 K16
11-05-08 FRI2 11-10-08 FERIE 12-27-08 K14
11-07-08 FRI2 12-05-08 FRI2 12-28-08 K15
11-12-08 FRI2 12-08-08 FRI2 09-08-08 FERIE
11-27-08 FRI2 12-11-08 FRI2 09-09-08 FERIE
12-03-08 FRI2 09-10-08 FERIE
12-04-08 FRI2 09-11-08 FERIE
12-05-08 FRI2 09-12-08 FERIE
12-16-08 FRI2 09-13-08 FERIE
12-17-08 FRI2 09-14-08 FERIE
12-30-08 FERIE

Appendix C. Tests 89

Appendix C. Tests 90
C.1.2 Instance 1
JST PZH HP SDA HMM OSJ
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11 09-01-08 FERIE
09-07-08 V4 09-04-08 V1 09-19-08 Ss 09-21-08 V15 09-06-08 K15 09-02-08 FERIE
09-13-08 V8 09-08-08 Ss 11-01-08 V7 10-10-08 V15 09-07-08 V1 09-03-08 FERIE
09-14-08 V2 09-15-08 V2 11-09-08 V15 10-11-08 Ss 09-11-08 V12 09-04-08 FERIE
09-20-08 V6 09-29-08 V14 12-01-08 V14 10-16-08 V12 09-16-08 Ss 09-05-08 FERIE
09-25-08 V12 09-14-08 V6 12-22-08 V15 12-16-08 V13 09-20-08 K14 09-06-08 FERIE
10-09-08 Ss 10-25-08 V6 10-05-08 V13 12-24-08 V3 09-21-08 V3 09-07-08 FERIE
09-11-08 V1 10-26-08 V2 10-09-08 V13 09-01-08 FRI2 09-25-08 K16 10-13-08 FERIE
10-13-08 V13 11-01-08 V16 09-01-08 FRI2 09-09-08 FRI2 10-04-08 K6 10-14-08 FERIE
10-18-08 V2 11-05-08 V13 09-04-08 FRI2 09-12-08 FRI2 10-05-08 V13 10-15-08 FERIE
10-25-08 V3 11-12-08 V1 09-09-08 FRI2 09-15-08 FERIE 10-09-08 V13 09-20-08 V2
10-26-08 V13 11-21-08 V11 09-18-08 FRI2 09-26-08 FERIE 10-17-08 K16 09-25-08 V1
10-30-08 V7 11-26-08 V12 09-23-08 FRI2 09-29-08 FERIE 10-18-08 K19 10-20-08 V1
10-05-08 V2 11-29-08 V4 09-30-08 FRI2 09-04-08 FERIE 10-19-08 K19 10-27-08 FRI1
11-13-08 V11 11-30-08 V9 09-26-08 FERIE 10-02-08 FRI1 10-31-08 K6 11-05-08 FRI2
11-17-08 V1 12-10-08 V2 10-07-08 FRI2 10-17-08 FERIE 11-01-08 V3 11-12-08 FERIE
11-20-08 V15 12-16-08 V11 10-20-08 FRI2 10-20-08 FERIE 11-02-08 K6 11-17-08 FERIE
11-25-08 V5 12-20-08 V3 10-23-08 FRI2 08-05-08 V1 11-06-08 V13 11-28-08 V2
12-06-08 V8 12-27-08 V2 10-27-08 FRI2 09-27-08 V13 11-10-08 K16 12-06-08 V3
12-07-08 V10 12-28-08 V6 10-15-08 FERIE 10-05-08 V2 11-18-08 K16
12-13-08 V5 12-31-08 V14 10-16-08 FERIE 10-23-08 Ss 11-29-08 K4
12-20-08 V1 09-04-08 V12 10-17-08 FERIE 11-10-08 V9 11-30-08 V12
12-22-08 V12 09-09-08 FRI2 11-06-08 FRI2 11-25-08 FRI1 12-04-08 K6
12-30-08 FRI1 09-13-08 FRI1 11-11-08 FRI2 12-04-08 FRI2 12-13-08 V9
09-08-08 FRI2 09-19-08 FRI2 11-17-08 FRI2 12-14-08 K5
09-09-08 FRI2 10-04-08 FRI1 11-18-08 FRI2 12-18-08 K16
09-13-08 FRI1 10-13-08 FERIE 11-20-08 FRI2 12-25-08 K16
09-16-08 FRI2 10-14-08 FERIE 11-10-08 FERIE 12-27-08 K14
09-23-08 FRI1 10-15-08 FERIE 12-05-08 FRI2 12-28-08 K15
09-29-08 FERIE 10-16-08 FERIE 12-08-08 FRI2 09-08-08 FERIE
09-30-08 FERIE 10-17-08 FERIE 12-11-08 FRI2 09-09-08 FERIE
10-01-08 FERIE 10-18-08 FERIE 09-17-08 V1 09-10-08 FERIE
10-02-08 FERIE 10-19-08 FERIE 09-25-08 V2 09-11-08 FERIE
10-03-08 FERIE 11-02-08 FERIE 10-03-08 V4 09-12-08 FERIE
10-04-08 FERIE 11-07-08 FRI1 10-16-08 V13 09-13-08 FERIE
10-05-08 FERIE 11-14-08 FRI2 11-05-08 V2 09-14-08 FERIE
10-06-08 FERIE 11-17-08 FRI1 11-20-08 Ss
10-07-08 FERIE 11-25-08 FRI1 12-05-08 FERIE
10-15-08 FERIE 12-05-08 FRI2 09-08-08 FRI1
10-22-08 FRI2 12-16-08 FRI2 09-16-08 FRI2
10-23-08 FRI2 12-23-08 FERIE 11-08-08 FRI1
10-26-08 FRI1 12-30-08 FERIE
10-31-08 FERIE
11-02-08 FRI1
11-05-08 FRI2
11-07-08 FRI2
11-12-08 FRI2
11-18-08 FRI2
11-27-08 FRI2
12-03-08 FRI2
12-04-08 FRI2
12-05-08 FRI2
12-10-08 FRI1
12-16-08 FRI2
12-17-08 FRI2
12-30-08 FERIE

Appendix C. Tests 91
C.1.3 Instance 2
JST PZH HP SDA HMM OSJ TEST1
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11 09-01-08 FERIE 09-03-08 V15
09-13-08 V8 09-08-08 Ss 09-19-08 Ss 09-21-08 V15 09-06-08 K15 09-02-08 FERIE 09-07-08 Ss
09-14-08 V2 09-29-08 V14 11-01-08 V7 10-10-08 V15 09-07-08 V1 09-03-08 FERIE 09-30-08 V14
10-09-08 Ss 10-25-08 V6 11-09-08 V15 10-11-08 Ss 09-11-08 V12 09-04-08 FERIE 10-24-08 V6
10-13-08 V13 10-26-08 V2 12-01-08 V14 10-16-08 V12 09-16-08 Ss 09-05-08 FERIE 10-25-08 V2
10-25-08 V3 11-05-08 V13 12-22-08 V15 12-16-08 V13 09-20-08 K14 09-06-08 FERIE 11-02-08 V13
10-26-08 V13 11-21-08 V11 10-05-08 V13 12-24-08 V3 09-21-08 V3 09-07-08 FERIE 11-15-08 V11
11-13-08 V11 11-29-08 V4 10-09-08 V13 09-01-08 FRI2 09-25-08 K16 10-13-08 FERIE 11-29-08 V4
11-20-08 V15 11-30-08 V9 09-01-08 FRI2 09-09-08 FRI2 10-04-08 K6 10-14-08 FERIE 11-30-08 V9
12-06-08 V8 12-16-08 V11 09-04-08 FRI2 09-12-08 FRI2 10-05-08 V13 10-15-08 FERIE 12-03-08 V11
12-07-08 V10 12-27-08 V2 09-09-08 FRI2 09-15-08 FERIE 10-09-08 V13 12-20-08 V2
12-22-08 V12 12-28-08 V6 09-18-08 FRI2 09-26-08 FERIE 10-17-08 K16 12-25-08 V6
09-08-08 FRI2 12-31-08 V14 09-23-08 FRI2 09-29-08 FERIE 10-18-08 K19 12-28-08 V14
09-09-08 FRI2 09-09-08 FRI2 09-30-08 FRI2 09-04-08 FERIE 10-19-08 K19 09-04-08 FRI2
09-16-08 FRI2 09-19-08 FRI2 09-26-08 FERIE 10-02-08 FRI1 10-31-08 K6 09-14-08 FRI2
09-29-08 FERIE 10-13-08 FERIE 10-07-08 FRI2 10-17-08 FERIE 11-01-08 V3 10-12-08 FERIE
09-30-08 FERIE 10-14-08 FERIE 10-20-08 FRI2 10-20-08 FERIE 11-02-08 K6 10-13-08 FERIE
10-01-08 FERIE 10-15-08 FERIE 10-23-08 FRI2 11-06-08 V13 10-16-08 FERIE
10-02-08 FERIE 10-16-08 FERIE 10-27-08 FRI2 11-10-08 K16 10-17-08 FERIE
10-03-08 FERIE 10-17-08 FERIE 10-15-08 FERIE 11-18-08 K16 10-18-08 FERIE
10-04-08 FERIE 10-18-08 FERIE 10-16-08 FERIE 11-29-08 K4 10-19-08 FERIE
10-05-08 FERIE 10-19-08 FERIE 10-17-08 FERIE 11-30-08 V12 10-26-08 FERIE
10-06-08 FERIE 11-07-08 FRI1 11-06-08 FRI2 12-04-08 K6 11-04-08 FRI1
10-07-08 FERIE 11-17-08 FRI1 11-11-08 FRI2 12-13-08 V9 11-23-08 FRI1
10-22-08 FRI2 12-05-08 FRI2 11-17-08 FRI2 12-14-08 K5 12-01-08 FRI2
10-23-08 FRI2 12-23-08 FERIE 11-18-08 FRI2 12-18-08 K16 12-10-08 FERIE
10-31-08 FERIE 12-30-08 FERIE 11-20-08 FRI2 12-25-08 K16 12-28-08 FERIE
11-05-08 FRI2 11-10-08 FERIE 12-27-08 K14
11-07-08 FRI2 12-05-08 FRI2 12-28-08 K15
11-12-08 FRI2 12-08-08 FRI2 09-08-08 FERIE
11-27-08 FRI2 12-11-08 FRI2 09-09-08 FERIE
12-03-08 FRI2 09-10-08 FERIE
12-04-08 FRI2 09-11-08 FERIE
12-05-08 FRI2 09-12-08 FERIE
12-16-08 FRI2 09-13-08 FERIE
12-17-08 FRI2 09-14-08 FERIE
12-30-08 FERIE

Appendix C. Tests 92
C.1.4 Instance 3
JST PZH HP SDA HMM
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11
09-13-08 V8 09-08-08 Ss 09-19-08 Ss 09-21-08 V15 09-06-08 K15
09-14-08 V2 09-29-08 V14 11-01-08 V7 10-10-08 V15 09-07-08 V1
10-09-08 Ss 10-25-08 V6 11-09-08 V15 10-11-08 Ss 09-11-08 V12
10-13-08 V13 10-26-08 V2 12-01-08 V14 10-16-08 V12 09-16-08 Ss
10-25-08 V3 11-05-08 V13 12-22-08 V15 12-16-08 V13 09-20-08 K14
10-26-08 V13 11-21-08 V11 10-05-08 V13 12-24-08 V3 09-21-08 V3
11-13-08 V11 11-29-08 V4 10-09-08 V13 09-01-08 FRI2 09-25-08 K16
11-20-08 V15 11-30-08 V9 09-01-08 FRI2 09-09-08 FRI2 10-04-08 K6
12-06-08 V8 12-16-08 V11 09-04-08 FRI2 09-12-08 FRI2 10-05-08 V13
12-07-08 V10 12-27-08 V2 09-09-08 FRI2 09-15-08 FERIE 10-09-08 V13
12-22-08 V12 12-28-08 V6 09-18-08 FRI2 09-26-08 FERIE 10-17-08 K16
09-08-08 FRI2 12-31-08 V14 09-23-08 FRI2 09-29-08 FERIE 10-18-08 K19
09-09-08 FRI2 09-09-08 FRI2 09-30-08 FRI2 09-04-08 FERIE 10-19-08 K19
09-16-08 FRI2 09-19-08 FRI2 09-26-08 FERIE 10-02-08 FRI1 10-31-08 K6
09-29-08 FERIE 10-13-08 FERIE 10-07-08 FRI2 10-17-08 FERIE 11-01-08 V3
09-30-08 FERIE 10-14-08 FERIE 10-20-08 FRI2 10-20-08 FERIE 11-02-08 K6
10-01-08 FERIE 10-15-08 FERIE 10-23-08 FRI2 11-06-08 V13
10-02-08 FERIE 10-16-08 FERIE 10-27-08 FRI2 11-10-08 K16
10-03-08 FERIE 10-17-08 FERIE 10-15-08 FERIE 11-18-08 K16
10-04-08 FERIE 10-18-08 FERIE 10-16-08 FERIE 11-29-08 K4
10-05-08 FERIE 10-19-08 FERIE 10-17-08 FERIE 11-30-08 V12
10-06-08 FERIE 11-07-08 FRI1 11-06-08 FRI2 12-04-08 K6
10-07-08 FERIE 11-17-08 FRI1 11-11-08 FRI2 12-13-08 V9
10-22-08 FRI2 12-05-08 FRI2 11-17-08 FRI2 12-14-08 K5
10-23-08 FRI2 12-23-08 FERIE 11-18-08 FRI2 12-18-08 K16
10-31-08 FERIE 12-30-08 FERIE 11-20-08 FRI2 12-25-08 K16
11-05-08 FRI2 11-10-08 FERIE 12-27-08 K14
11-07-08 FRI2 12-05-08 FRI2 12-28-08 K15
11-12-08 FRI2 12-08-08 FRI2 09-08-08 FERIE
11-27-08 FRI2 12-11-08 FRI2 09-09-08 FERIE
12-03-08 FRI2 09-10-08 FERIE
12-04-08 FRI2 09-11-08 FERIE
12-05-08 FRI2 09-12-08 FERIE
12-16-08 FRI2 09-13-08 FERIE
12-17-08 FRI2 09-14-08 FERIE
12-30-08 FERIE

Appendix C. Tests 93
C.1.5 Instance 4
JST PZH HP SDA HMM OSJ
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11 09-01-08 FERIE
09-13-08 V8 09-08-08 Ss 09-19-08 Ss 09-21-08 V15 09-06-08 K15 09-02-08 FERIE
09-14-08 V2 09-29-08 V14 11-01-08 V7 10-10-08 V15 09-07-08 V1 09-03-08 FERIE
10-09-08 Ss 10-25-08 V6 11-09-08 V15 10-11-08 Ss 09-11-08 V12 09-04-08 FERIE
10-13-08 V13 10-26-08 V2 12-01-08 V14 10-16-08 V12 09-16-08 Ss 09-05-08 FERIE
10-25-08 V3 11-05-08 V13 12-22-08 V15 12-16-08 V13 09-20-08 K14 09-06-08 FERIE
10-26-08 V13 11-21-08 V11 10-05-08 V13 12-24-08 V3 09-21-08 V3 09-07-08 FERIE
11-13-08 V11 11-29-08 V4 10-09-08 V13 09-01-08 FRI2 09-25-08 K16 10-13-08 FERIE
11-20-08 V15 11-30-08 V9 09-01-08 FRI2 09-09-08 FRI2 10-04-08 K6 10-14-08 FERIE
12-06-08 V8 12-16-08 V11 09-04-08 FRI2 09-12-08 FRI2 10-05-08 V13 10-15-08 FERIE
12-07-08 V10 12-27-08 V2 09-09-08 FRI2 09-15-08 FERIE 10-09-08 V13 01-02-09 K14
12-22-08 V12 12-28-08 V6 09-18-08 FRI2 09-26-08 FERIE 10-17-08 K16 01-07-09 K5
09-08-08 FRI2 12-31-08 V14 09-23-08 FRI2 09-29-08 FERIE 10-18-08 K19 01-10-09 V2
09-09-08 FRI2 09-09-08 FRI2 09-30-08 FRI2 09-04-08 FERIE 10-19-08 K19 01-18-09 V1
09-16-08 FRI2 09-19-08 FRI2 09-26-08 FERIE 10-02-08 FRI1 10-31-08 K6 02-02-09 V15
09-29-08 FERIE 10-13-08 FERIE 10-07-08 FRI2 10-17-08 FERIE 11-01-08 V3 02-04-09 V11
09-30-08 FERIE 10-14-08 FERIE 10-20-08 FRI2 10-20-08 FERIE 11-02-08 K6 02-12-09 V8
10-01-08 FERIE 10-15-08 FERIE 10-23-08 FRI2 01-02-09 V2 11-06-08 V13 02-26-09 V4
10-02-08 FERIE 10-16-08 FERIE 10-27-08 FRI2 01-08-09 V2 11-10-08 K16 03-01-09 K4
10-03-08 FERIE 10-17-08 FERIE 10-15-08 FERIE 01-18-09 V6 11-18-08 K16 03-07-09 K16
10-04-08 FERIE 10-18-08 FERIE 10-16-08 FERIE 01-27-09 V10 11-29-08 K4 03-15-09 V3
10-05-08 FERIE 10-19-08 FERIE 10-17-08 FERIE 02-05-09 V8 11-30-08 V12 03-21-09 V8
10-06-08 FERIE 11-07-08 FRI1 11-06-08 FRI2 02-09-09 V1 12-04-08 K6 04-02-09 Ss
10-07-08 FERIE 11-17-08 FRI1 11-11-08 FRI2 02-19-09 V12 12-13-08 V9 04-15-09 V1
10-22-08 FRI2 12-05-08 FRI2 11-17-08 FRI2 02-24-09 Ss 12-14-08 K5 04-24-09 V12
10-23-08 FRI2 12-23-08 FERIE 11-18-08 FRI2 03-04-09 V3 12-18-08 K16 01-12-09 FERIE
10-31-08 FERIE 12-30-08 FERIE 11-20-08 FRI2 03-08-09 V15 12-25-08 K16 01-13-09 FERIE
11-05-08 FRI2 01-02-09 V5 11-10-08 FERIE 03-23-09 V15 12-27-08 K14 01-14-09 FERIE
11-07-08 FRI2 01-12-09 V10 12-05-08 FRI2 03-29-09 V7 12-28-08 K15 01-15-09 FERIE
11-12-08 FRI2 01-15-09 V3 12-08-08 FRI2 04-03-09 V8 09-08-08 FERIE 01-16-09 FERIE
11-27-08 FRI2 01-27-09 V2 12-11-08 FRI2 04-17-09 V2 09-09-08 FERIE 03-02-09 FERIE

Appendix C. Tests 94
JST PZH HP SDA HMM OSJ
12-03-08 FRI2 02-04-09 V8 01-01-09 V1 04-25-09 V3 09-10-08 FERIE 03-03-09 FERIE
12-04-08 FRI2 02-09-09 V11 01-09-09 V10 04-18-09 FERIE 09-11-08 FERIE 03-12-09 FRI1
12-05-08 FRI2 02-13-09 V13 01-11-09 V8 04-19-09 FERIE 09-12-08 FERIE 03-26-09 FRI1
12-16-08 FRI2 02-23-09 V2 01-19-09 V2 04-20-09 FERIE 09-13-08 FERIE 04-01-09 FRI1
12-17-08 FRI2 03-01-09 V6 01-25-09 V13 04-21-09 FERIE 09-14-08 FERIE 04-10-09 FRI2
12-30-08 FERIE 03-16-09 V14 02-02-09 V13 04-22-09 FERIE 01-04-09 V5 04-22-09 FRI2
01-03-09 V8 03-20-09 Ss 02-10-09 V7 04-23-09 FERIE 01-11-09 V2
01-10-09 V2 03-29-09 V15 02-28-09 V4 01-19-09 V3
01-13-09 V3 04-01-09 V2 03-03-09 V2 01-26-09 V10
01-20-09 V13 04-25-09 V5 03-06-09 V4 02-01-09 V1
02-01-09 V11 04-27-09 V16 03-15-09 V3 02-05-09 V12
02-07-09 V8 01-20-09 FERIE 03-30-09 Ss 02-19-09 K14
02-16-09 V14 01-21-09 FERIE 04-05-09 V12 02-28-09 K19
02-25-09 V15 01-22-09 FERIE 04-20-09 V11 03-02-09 V12
03-03-09 Ss 03-05-09 FERIE 04-28-09 V2 03-09-09 K5
03-10-09 V2 03-06-09 FERIE 04-30-09 V5 03-15-09 K16
03-17-09 V8 01-23-09 FRI1 02-12-09 FERIE 03-22-09 V3
03-24-09 V12 02-16-09 FRI1 02-13-09 FERIE 04-09-09 V2
04-05-09 V16 02-26-09 FRI1 02-14-09 FERIE 04-23-09 K4
04-18-09 V1 03-23-09 FRI1 02-15-09 FERIE 04-29-09 V11
04-29-09 V9 04-10-09 FRI2 02-16-09 FERIE 02-20-09 FERIE
03-11-09 FERIE 02-21-09 FERIE
03-12-09 FERIE 02-22-09 FERIE
03-13-09 FERIE 02-02-09 FERIE
03-14-09 FERIE 02-03-09 FERIE
01-06-09 FRI1 02-04-09 FERIE
02-10-09 FRI1
04-06-09 FRI2
04-23-09 FRI2

Appendix C. Tests 95
C.1.6 Instance 5
JST PZH HP SDA HMM OSJ
09-04-08 V14 09-02-08 V15 09-02-08 V15 09-02-08 FRI1 09-01-08 V11 09-01-08 FERIE
09-07-08 V4 09-04-08 V1 09-04-08 V1 09-09-08 V1 09-06-08 K15 09-02-08 FERIE
09-13-08 V8 09-08-08 Ss 09-08-08 Ss 09-13-08 V2 09-07-08 V1 09-03-08 FERIE
09-14-08 V2 09-15-08 V2 09-14-08 FRI1 09-18-08 FRI2 09-11-08 V12 09-04-08 FERIE
09-15-08 V1 09-18-08 FRI1 09-15-08 V2 09-20-08 V7 09-16-08 Ss 09-05-08 FERIE
09-20-08 V6 09-23-08 FRI2 09-29-08 V14 09-21-08 V15 09-20-08 K14 09-06-08 FERIE
09-25-08 V12 09-29-08 V14 09-14-08 V6 09-25-08 V12 09-21-08 V3 09-07-08 FERIE
09-28-08 V2 09-14-08 V6 09-17-08 FRI1 10-03-08 V8 09-25-08 K16 10-13-08 FERIE
10-03-08 V1 09-19-08 V1 10-25-08 V6 10-10-08 V15 09-30-08 V1 10-14-08 FERIE
10-09-08 Ss 10-25-08 V6 10-26-08 V2 10-11-08 Ss 10-04-08 K6 10-15-08 FERIE
09-11-08 V1 10-26-08 V2 11-01-08 V16 10-16-08 V12 10-05-08 V13 09-20-08 V2
10-13-08 V13 11-01-08 V16 11-05-08 V13 12-16-08 V13 10-09-08 V13 09-25-08 V1
10-18-08 V2 11-05-08 V13 11-12-08 V1 12-24-08 V3 10-14-08 FRI2 10-20-08 V1
10-25-08 V3 11-08-08 FRI2 11-15-08 FRI2 12-29-08 V2 10-17-08 K16 10-27-08 FRI1
10-26-08 V13 11-12-08 V1 11-21-08 V11 09-01-08 FRI2 10-18-08 K19 11-05-08 FRI2
10-30-08 V7 11-21-08 V11 11-26-08 V12 09-09-08 FRI2 10-19-08 K19 11-12-08 FERIE
11-02-08 V1 11-26-08 V12 11-29-08 V4 09-12-08 FRI2 10-26-08 V6 11-17-08 FERIE
10-05-08 V2 11-29-08 V4 11-30-08 V9 09-15-08 FERIE 10-31-08 K6 11-28-08 V2
11-13-08 V11 11-30-08 V9 12-04-08 FRI2 09-26-08 FERIE 11-01-08 V3 12-06-08 V3
11-17-08 V1 12-10-08 V2 12-10-08 V2 09-29-08 FERIE 11-02-08 K6 12-13-08 V1
11-20-08 V15 12-13-08 FRI1 12-16-08 V11 09-04-08 FERIE 11-06-08 V13 12-18-08 K2
11-25-08 V5 12-16-08 V11 12-20-08 V3 10-02-08 FRI1 11-10-08 K16 12-27-08 V5
12-06-08 V8 12-20-08 V3 12-27-08 V2 10-17-08 FERIE 11-15-08 K3
12-07-08 V10 12-27-08 V2 12-28-08 V6 10-20-08 FERIE 11-18-08 K16
12-13-08 V5 12-28-08 V6 12-31-08 V14 08-05-08 V1 11-29-08 K4
12-20-08 V1 12-31-08 V14 09-04-08 V12 09-27-08 V13 11-30-08 V12
12-22-08 V12 09-04-08 V12 09-09-08 FRI2 10-05-08 V2 12-04-08 K6
12-30-08 FRI1 09-09-08 FRI2 09-13-08 FRI1 10-23-08 Ss 12-13-08 V9
09-08-08 FRI2 09-13-08 FRI1 09-19-08 FRI2 11-10-08 V9 12-14-08 K5
09-09-08 FRI2 09-19-08 FRI2 10-04-08 FRI1 11-25-08 FRI1 12-18-08 K16
09-13-08 FRI1 10-04-08 FRI1 10-13-08 FERIE 12-04-08 FRI2 12-25-08 K16

Appendix C. Tests 96
JST PZH HP SDA HMM OSJ
09-16-08 FRI2 10-13-08 FERIE 10-14-08 FERIE 12-27-08 K14
09-23-08 FRI1 10-14-08 FERIE 10-15-08 FERIE 12-28-08 K15
09-29-08 FERIE 10-15-08 FERIE 10-16-08 FERIE 09-08-08 FERIE
09-30-08 FERIE 10-16-08 FERIE 10-17-08 FERIE 09-09-08 FERIE
10-01-08 FERIE 10-17-08 FERIE 10-18-08 FERIE 09-10-08 FERIE
10-02-08 FERIE 10-18-08 FERIE 10-19-08 FERIE 09-11-08 FERIE
10-03-08 FERIE 10-19-08 FERIE 11-02-08 FERIE 09-12-08 FERIE
10-04-08 FERIE 11-02-08 FERIE 11-07-08 FRI1 09-13-08 FERIE
10-05-08 FERIE 11-07-08 FRI1 11-14-08 FRI2 09-14-08 FERIE
10-06-08 FERIE 11-14-08 FRI2 11-17-08 FRI1
10-07-08 FERIE 11-17-08 FRI1 11-25-08 FRI1
10-15-08 FERIE 11-25-08 FRI1 12-05-08 FRI2
10-22-08 FRI2 12-05-08 FRI2 12-16-08 FRI2
10-23-08 FRI2 12-16-08 FRI2 12-23-08 FERIE
10-26-08 FRI1 12-23-08 FERIE 12-30-08 FERIE
10-31-08 FERIE 12-30-08 FERIE
11-02-08 FRI1
11-05-08 FRI2
11-07-08 FRI2
11-12-08 FRI2
11-18-08 FRI2
11-27-08 FRI2
12-03-08 FRI2
12-04-08 FRI2
12-05-08 FRI2
12-10-08 FRI1
12-16-08 FRI2
12-17-08 FRI2
12-30-08 FERIE

Appendix C. Tests 97
C.1.7 Instance 6
JST PZH HP SDA HMM OSJ TEST1
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11 09-01-08 FERIE 09-03-08 V15
09-13-08 V8 09-08-08 Ss 09-19-08 Ss 09-21-08 V15 09-06-08 K15 09-02-08 FERIE 09-07-08 Ss
09-14-08 V2 09-29-08 V14 10-05-08 V13 10-10-08 V15 09-07-08 V1 09-03-08 FERIE 09-30-08 V14
10-09-08 Ss 10-25-08 V6 10-09-08 V13 10-11-08 Ss 09-11-08 V12 09-04-08 FERIE 10-24-08 V6
10-13-08 V13 10-26-08 V2 09-01-08 FRI2 10-16-08 V12 09-16-08 Ss 09-05-08 FERIE 10-25-08 V2
10-25-08 V3 09-09-08 FRI2 09-04-08 FRI2 09-01-08 FRI2 09-20-08 K14 09-06-08 FERIE 09-04-08 FRI2
10-26-08 V13 09-19-08 FRI2 09-09-08 FRI2 09-09-08 FRI2 09-21-08 V3 09-07-08 FERIE 09-14-08 FRI2
09-08-08 FRI2 10-13-08 FERIE 09-18-08 FRI2 09-12-08 FRI2 09-25-08 K16 10-13-08 FERIE 10-12-08 FERIE
09-09-08 FRI2 10-14-08 FERIE 09-23-08 FRI2 09-15-08 FERIE 10-04-08 K6 10-14-08 FERIE 10-13-08 FERIE
09-16-08 FRI2 10-15-08 FERIE 09-30-08 FRI2 09-26-08 FERIE 10-05-08 V13 10-15-08 FERIE 10-16-08 FERIE
09-29-08 FERIE 10-16-08 FERIE 09-26-08 FERIE 09-29-08 FERIE 10-09-08 V13 10-17-08 FERIE
09-30-08 FERIE 10-17-08 FERIE 10-07-08 FRI2 09-04-08 FERIE 10-17-08 K16 10-18-08 FERIE
10-01-08 FERIE 10-18-08 FERIE 10-20-08 FRI2 10-02-08 FRI1 10-18-08 K19 10-19-08 FERIE
10-02-08 FERIE 10-19-08 FERIE 10-23-08 FRI2 10-17-08 FERIE 10-19-08 K19 10-26-08 FERIE
10-03-08 FERIE 10-27-08 FRI2 10-20-08 FERIE 10-31-08 K6
10-04-08 FERIE 10-15-08 FERIE 09-08-08 FERIE
10-05-08 FERIE 10-16-08 FERIE 09-09-08 FERIE
10-06-08 FERIE 10-17-08 FERIE 09-10-08 FERIE
10-07-08 FERIE 09-11-08 FERIE
10-22-08 FRI2 09-12-08 FERIE
10-23-08 FRI2 09-13-08 FERIE
10-31-08 FERIE 09-14-08 FERIE

Appendix C. Tests 98
C.1.8 Instance 7
JST PZH HP SDA HMM OSJ TEST1 TEST2
09-04-08 V14 09-02-08 V15 09-15-08 V12 09-20-08 V7 09-01-08 V11 09-01-08 FERIE 09-04-08 V14 09-20-08 V7
09-13-08 V8 09-08-08 Ss 09-19-08 Ss 09-21-08 V15 09-06-08 K15 09-02-08 FERIE 09-13-08 V8 09-21-08 V15
09-14-08 V2 09-29-08 V14 11-01-08 V7 10-10-08 V15 09-07-08 V1 09-03-08 FERIE 09-14-08 V2 10-10-08 V15
10-09-08 Ss 10-25-08 V6 11-09-08 V15 10-11-08 Ss 09-11-08 V12 09-04-08 FERIE 10-09-08 Ss 10-11-08 Ss
10-13-08 V13 10-26-08 V2 12-01-08 V14 10-16-08 V12 09-16-08 Ss 09-05-08 FERIE 10-13-08 V13 10-16-08 V12
10-25-08 V3 11-05-08 V13 12-22-08 V15 12-16-08 V13 09-20-08 K14 09-06-08 FERIE 10-25-08 V3 09-01-08 FRI2
10-26-08 V13 11-21-08 V11 10-05-08 V13 12-24-08 V3 09-21-08 V3 09-07-08 FERIE 10-26-08 V13 09-09-08 FRI2
11-13-08 V11 11-29-08 V4 10-09-08 V13 09-01-08 FRI2 09-25-08 K16 10-13-08 FERIE 09-08-08 FRI2 09-12-08 FRI2
11-20-08 V15 11-30-08 V9 09-01-08 FRI2 09-09-08 FRI2 10-04-08 K6 10-14-08 FERIE 09-09-08 FRI2 09-15-08 FERIE
12-06-08 V8 12-16-08 V11 09-04-08 FRI2 09-12-08 FRI2 10-05-08 V13 10-15-08 FERIE 09-16-08 FRI2 09-26-08 FERIE
12-07-08 V10 12-27-08 V2 09-09-08 FRI2 09-15-08 FERIE 10-09-08 V13 01-02-09 K14 09-29-08 FERIE 09-29-08 FERIE
12-22-08 V12 12-28-08 V6 09-18-08 FRI2 09-26-08 FERIE 10-17-08 K16 01-07-09 K5 09-30-08 FERIE 09-04-08 FERIE
09-08-08 FRI2 12-31-08 V14 09-23-08 FRI2 09-29-08 FERIE 10-18-08 K19 01-10-09 V2 10-01-08 FERIE 10-02-08 FRI1
09-09-08 FRI2 09-09-08 FRI2 09-30-08 FRI2 09-04-08 FERIE 10-19-08 K19 01-18-09 V1 10-02-08 FERIE 10-17-08 FERIE
09-16-08 FRI2 09-19-08 FRI2 09-26-08 FERIE 10-02-08 FRI1 10-31-08 K6 02-02-09 V15 10-03-08 FERIE 10-20-08 FERIE
09-29-08 FERIE 10-13-08 FERIE 10-07-08 FRI2 10-17-08 FERIE 11-01-08 V3 02-04-09 V11 10-04-08 FERIE 11-01-08 V3
09-30-08 FERIE 10-14-08 FERIE 10-20-08 FRI2 10-20-08 FERIE 11-02-08 K6 02-12-09 V8 10-05-08 FERIE 11-02-08 K6
10-01-08 FERIE 10-15-08 FERIE 10-23-08 FRI2 01-02-09 V2 11-06-08 V13 02-26-09 V4 10-06-08 FERIE 11-06-08 V13
10-02-08 FERIE 10-16-08 FERIE 10-27-08 FRI2 01-08-09 V2 11-10-08 K16 01-12-09 FERIE 10-07-08 FERIE 11-10-08 K16
10-03-08 FERIE 10-17-08 FERIE 10-15-08 FERIE 01-18-09 V6 11-18-08 K16 01-13-09 FERIE 10-22-08 FRI2 11-18-08 K16
10-04-08 FERIE 10-18-08 FERIE 10-16-08 FERIE 01-27-09 V10 11-29-08 K4 01-14-09 FERIE 10-23-08 FRI2 11-29-08 K4
10-05-08 FERIE 10-19-08 FERIE 10-17-08 FERIE 02-05-09 V8 11-30-08 V12 01-15-09 FERIE 10-31-08 FERIE 11-30-08 V12
10-06-08 FERIE 11-07-08 FRI1 11-06-08 FRI2 02-09-09 V1 12-04-08 K6 01-16-09 FERIE 11-05-08 V13 12-04-08 K6
10-07-08 FERIE 11-17-08 FRI1 11-11-08 FRI2 02-19-09 V12 12-13-08 V9 11-21-08 V11 12-13-08 V9
10-22-08 FRI2 12-05-08 FRI2 11-17-08 FRI2 02-24-09 Ss 12-14-08 K5 11-29-08 V4 12-14-08 K5
10-23-08 FRI2 12-23-08 FERIE 11-18-08 FRI2 12-18-08 K16 11-30-08 V9 12-18-08 K16
10-31-08 FERIE 12-30-08 FERIE 11-20-08 FRI2 12-25-08 K16 12-16-08 V11 12-25-08 K16
11-05-08 FRI2 01-02-09 V5 11-10-08 FERIE 12-27-08 K14 12-27-08 V2 12-27-08 K14
11-07-08 FRI2 01-12-09 V10 12-05-08 FRI2 12-28-08 K15 12-28-08 V6 12-28-08 K15
11-12-08 FRI2 01-15-09 V3 12-08-08 FRI2 09-08-08 FERIE 12-31-08 V14 01-02-09 K14
11-27-08 FRI2 01-27-09 V2 12-11-08 FRI2 09-09-08 FERIE 11-07-08 FRI1 01-07-09 K5
12-03-08 FRI2 02-04-09 V8 01-01-09 V1 09-10-08 FERIE 11-17-08 FRI1 01-10-09 V2
12-04-08 FRI2 02-09-09 V11 01-09-09 V10 09-11-08 FERIE 12-05-08 FRI2 01-18-09 V1
12-05-08 FRI2 02-13-09 V13 01-11-09 V8 09-12-08 FERIE 12-23-08 FERIE 02-02-09 V15
12-16-08 FRI2 02-23-09 V2 01-19-09 V2 09-13-08 FERIE 12-30-08 FERIE 02-04-09 V11
12-17-08 FRI2 01-20-09 FERIE 01-25-09 V13 09-14-08 FERIE 02-12-09 V8
12-30-08 FERIE 01-21-09 FERIE 02-02-09 V13 01-04-09 V5 02-26-09 V4
01-03-09 V8 01-22-09 FERIE 02-10-09 V7 01-11-09 V2 01-12-09 FERIE
01-10-09 V2 01-23-09 FRI1 02-28-09 V4 01-19-09 V3 01-13-09 FERIE
01-13-09 V3 02-16-09 FRI1 02-12-09 FERIE 01-26-09 V10 01-14-09 FERIE
01-20-09 V13 02-26-09 FRI1 02-13-09 FERIE 02-01-09 V1 01-15-09 FERIE
02-01-09 V11 02-14-09 FERIE 02-05-09 V12 01-16-09 FERIE
02-07-09 V8 02-15-09 FERIE 02-19-09 K14
02-16-09 V14 02-16-09 FERIE 02-28-09 K19
02-25-09 V15 02-20-09 FERIE
01-06-09 FRI1 02-21-09 FERIE
02-10-09 FRI1 02-22-09 FERIE
02-02-09 FERIE
02-03-09 FERIE
02-04-09 FERIE

Appendix C. Tests 99
C.1.9 Instance 8
JST PZH HP SDA HMM OSJ
09-04-08 V14 09-09-08 FRI2 09-15-08 V12 09-01-08 FRI2 09-11-08 FERIE 09-01-08 FERIE
09-08-08 FRI2 09-19-08 FRI2 09-01-08 FRI2 09-04-08 FERIE 09-12-08 FERIE 09-02-08 FERIE
09-09-08 FRI2 09-29-08 V14 09-23-08 FRI2 09-21-08 V15 09-13-08 FERIE 09-03-08 FERIE
09-13-08 V8 10-17-08 FERIE 09-26-08 FERIE 09-26-08 FERIE 09-14-08 FERIE 09-04-08 FERIE
10-01-08 FERIE 10-18-08 FERIE 09-30-08 FRI2 09-29-08 FERIE 09-16-08 Ss 10-13-08 FERIE
10-02-08 FERIE 10-19-08 FERIE 10-05-08 V13 10-16-08 V12 09-20-08 K14 10-14-08 FERIE
10-03-08 FERIE 10-25-08 V6 10-07-08 FRI2 10-17-08 FERIE 09-21-08 V3
10-04-08 FERIE 10-26-08 V2 10-09-08 V13 10-20-08 FERIE 09-25-08 K16
10-05-08 FERIE 11-21-08 V11 10-23-08 FRI2 12-16-08 V13 10-17-08 K16
10-06-08 FERIE 11-29-08 V4 10-27-08 FRI2 12-24-08 V3 10-18-08 K19
10-07-08 FERIE 11-30-08 V9 11-11-08 FRI2 10-19-08 K19
11-05-08 FRI2 12-27-08 V2 11-17-08 FRI2 10-31-08 K6
11-07-08 FRI2 12-28-08 V6 11-18-08 FRI2 11-01-08 V3
11-12-08 FRI2 12-30-08 FERIE 11-20-08 FRI2 11-02-08 K6
11-13-08 V11 12-31-08 V14 12-01-08 V14 11-29-08 K4
11-20-08 V15 12-05-08 FRI2 11-30-08 V12
11-27-08 FRI2 12-08-08 FRI2 12-04-08 K6
12-07-08 V10 12-13-08 V9
12-16-08 FRI2 12-14-08 K5
12-17-08 FRI2 12-28-08 K15
12-22-08 V12
12-30-08 FERIE
C.1.10 Instance 9
It is the empty instance, with no night- or evening shifts given, nor any wishes.
C.2 Summarized results
C.2.1 RCL performance
Cons 17 Imps Z(S) V(S) Cons 13 Imps Z(S) V(S) Cons 17 Imps Z(S) V(S)
Test 1 GRASP 1 19,625 5 32 Test 3 GRASP 1 16,8125 3,5 30,4375 Test 6 GRASP 1 14,5 4,1875 12,6875
GRASP 100 15,3125 363,6875 27,875 GRASP 100 17,0625 468,1875 23,25 GRASP 100 12,0625 176,8125 10,1875
GRASP 50 13,625 6,125 27,5 GRASP 50 15,25 4,3125 25,4375 GRASP 50 15,25 8,5625 9,1875
SA 1 62,35938 185,9844 8,9375 SA 1 59,65625 162,5156 9,171875 SA 1 41,65625 96,71875 2,1875
SA 100 78,57813 624,9688 11,51563 SA 100 74,14063 689,8906 9,984375 SA 100 53,40625 276,7188 2,234375
SA 50 72,51563 151,8125 9,6875 SA 50 67,34375 221,5625 9,9375 SA 50 39,09375 95,15625 1,9375
Ave: 43,66927 222,9297 19,58594 Ave 41,71094 258,3281 18,03646 Ave 29,32813 109,6927 6,403646
Cons 13 Imps Z(S) V(S) Cons 13 Imps Z(S) V(S) Cons 13 Imps Z(S) V(S)
Test 0 GRASP 1 17,1875 3,5625 25,9375 Test 4 GRASP 1 19,1875 4,375 55,0625 Test 7 GRASP 1 20,875 3,4375 45,8125
GRASP 100 14,625 392,75 19,3125 GRASP 100 17,4375 731,5 37,75 GRASP 100 16,9375 508,9375 27,3125
GRASP 50 13,5 5,625 21,125 GRASP 50 15 4,6875 44,5 GRASP 50 16,5625 6,75 29,375
SA 1 57,40625 111,2344 7,125 SA 1 74,29688 124,2656 20,46875 SA 1 62,84375 87,45313 14,20313
SA 100 54,42188 520,7344 6,15625 SA 100 67,48438 1049,969 17,54688 SA 100 61,82813 761,1563 10,5
SA 50 58,07813 142,6875 6,640625 SA 50 72,875 179,6563 19,1875 SA 50 63,53125 113,7969 10,57813
Ave: 35,86979 196,099 14,38281 Ave 44,38021 349,0755 32,41927 Ave 40,42969 246,9219 22,96354

Appendix C. Tests 100
Cons 12 Imps Z(S) V(S) Cons 18 Imps Z(S) V(S) Cons 7 Imps Z(S) V(S)
Test 2 GRASP 1 17,4375 4,5 25,25 Test 5 GRASP 1 16,8125 4,375 31 Test 8 GRASP 1 15,5 4,9375 19
GRASP 100 12,75 254 18 GRASP 100 13,9375 473,4375 29,125 GRASP 100 11,0625 185,0625 9,625
GRASP 50 17,8125 6,1875 16,75 GRASP 50 13,8125 5,25 27,625 GRASP 50 14,625 4,625 14,9375
SA 1 54,40625 151,4844 6,265625 SA 1 58 165,25 9,6875 SA 1 39,5 180,6719 3,8125
SA 100 59 368,7188 5,375 SA 100 85,35938 686,1875 11,92188 SA 100 37,875 255,3281 2,625
SA 50 44,20313 199,875 4,453125 SA 50 68,29688 171,9219 10,82813 SA 50 43,67188 133,8906 4,421875
Ave: 34,26823 164,1276 12,68229 Ave 42,70313 251,0703 20,03125 Ave 27,03906 127,4193 9,070313
Cons 0 Imps Z(S) V(S)
Test 9 GRASP 1 7,6875 3,375 8,125
GRASP 100 8,75 7,5 1
GRASP 50 6,0625 2,875 3,375
SA 1 7,40625 4 0,859375
SA 100 3,53125 5,3125 0,09375
SA 50 5,234375 3,125 0,28125
Ave: 6,445313 4,364583 2,289063
C.2.2 Enum effect
Test 0 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 2,125 0,375 6,75 4 329,125 12,5 112,6667 5,625
Shift 5 51,5 4,5 38,25 456,375 26,125 155,2917 38,625
Ave 3,5625 25,9375 5,625 21,125 392,75 19,3125 133,9792 22,125
Median
Day 2 0 6 4 410 12,5
Shift 4,5 53,5 4 36 458,5 27
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 94,09375 0,09375 109,0938 1,78125 522,2188 4,5 241,8021 2,125
Shift 128,375 14,15625 176,2813 11,5 519,25 7,8125 274,6354 11,15625
Ave 111,2344 7,125 142,6875 6,640625 520,7344 6,15625 258,2188 6,640625
Median
Day 69 0 85 2 505,5 4,5
Shift 121,5 10 177,5 9,5 506 6,5

Appendix C. Tests 101
Test 1 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 1,875 0,375 7,5 7,75 328,5 20,25 112,625 9,458333
Shift 8,125 63,625 4,75 47,25 398,875 35,5 137,25 48,79167
Ave 5 32 6,125 27,5 363,6875 27,875 124,9375 29,125
Median
Day 2 0 7 7,5 352 20,5
Shift 8 68 4 49 374 35
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 138,375 0,09375 132,6875 4,34375 611 9,28125 294,0208 4,572917
Shift 233,5938 17,78125 170,9375 15,03125 638,9375 13,75 347,8229 15,52083
Ave 185,9844 8,9375 151,8125 9,6875 624,9688 11,51563 320,9219 10,04688
Median
Day 108 0 116 4 569 9
Shift 245,5 16 159,5 12,5 650 14
Test 2 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 2,875 0,25 7,875 11,25 208,625 12,25 73,125 7,916667
Shift 6,125 50,25 4,5 22,25 299,375 23,75 103,3333 32,08333
Ave 4,5 25,25 6,1875 16,75 254 18 88,22917 20
Median
Day 3 0 6 3,5 233,5 11,5
Shift 6 45,5 4 25 299,5 24
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 121,25 0,125 137,5938 1,03125 373,7813 3,9375 210,875 1,697917
Shift 181,7188 12,40625 262,1563 7,875 363,6563 6,8125 269,1771 9,03125
Ave 151,4844 6,265625 199,875 4,453125 368,7188 5,375 240,026 5,364583
Median
Day 100,5 0 66 1 392 3
Shift 180 8 277 6 362 5

Appendix C. Tests 102
Test 3 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 3,25 1,375 4,625 6,625 385,125 16,875 131 8,291667
Shift 3,75 59,5 4 44,25 551,25 29,625 186,3333 44,45833
Ave 3,5 30,4375 4,3125 25,4375 468,1875 23,25 158,6667 26,375
Median
Day 3 1 4 6,5 476 16,5
Shift 3,5 61 4,5 45 555,5 30,5
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 118,5625 1,125 180,8125 4,375 657,625 8,71875 319 4,739583
Shift 206,4688 17,21875 262,3125 15,5 722,1563 11,25 396,9792 14,65625
Ave 162,5156 9,171875 221,5625 9,9375 689,8906 9,984375 357,9896 9,697917
Median
Day 83 1 148,5 4 640 8
Shift 224,5 13,5 252 12,5 723 8,5
Test 4 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 3 0,125 5,25 5,75 607,875 21,125 205,375 9
Shift 5,75 110 4,125 83,25 855,125 54,375 288,3333 82,54167
Ave 4,375 55,0625 4,6875 44,5 731,5 37,75 246,8542 45,77083
Median
Day 3 0 5,5 6 733,5 22
Shift 5 111 4 83,5 860,5 54
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 104,7813 0,0625 135,7813 3,78125 1026,156 11,1875 422,2396 5,010417
Shift 143,75 40,875 223,5313 34,59375 1073,781 23,90625 480,3542 33,125
Ave 124,2656 20,46875 179,6563 19,1875 1049,969 17,54688 451,2969 19,06771
Median
Day 82 0 95 4 1008 11,5
Shift 154,5 36 232,5 30 1078,5 23

Appendix C. Tests 103
Test 5 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 3 0,125 5,5 9,625 391,375 22,5 133,2917 10,75
Shift 5,75 61,875 5 45,625 555,5 35,75 188,75 47,75
Ave 4,375 31 5,25 27,625 473,4375 29,125 161,0208 29,25
Median
Day 3 0 5 11 414,5 22
Shift 6 63 4 46 571 36,5
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 128,3125 0,09375 137,1563 5,6875 699,7813 10,6875 321,75 5,489583
Shift 202,1875 19,28125 206,6875 15,96875 672,5938 13,15625 360,4896 16,13542
Ave 165,25 9,6875 171,9219 10,82813 686,1875 11,92188 341,1198 10,8125
Median
Day 93,5 0 118,5 6 699,5 10,5
Shift 209 14 199 14 666 13
Test 6 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 3,5 0,375 10,75 1,875 143,125 7,125 52,45833 3,125
Shift 4,875 25 6,375 16,5 210,5 13,25 73,91667 18,25
Ave 4,1875 12,6875 8,5625 9,1875 176,8125 10,1875 63,1875 10,6875
Median
Day 4 0 9,5 1,5 152 7
Shift 3,5 25,5 6 16,5 215 11,5
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 82,65625 0,0625 82,9375 0,6875 267,4063 1,78125 144,3333 0,84375
Shift 110,7813 4,3125 107,375 3,1875 286,0313 2,6875 168,0625 3,395833
Ave 96,71875 2,1875 95,15625 1,9375 276,7188 2,234375 156,1979 2,119792
Median
Day 55 0 84 1 242 1
Shift 105 2 107 1,5 286,5 2

Appendix C. Tests 104
Test 7 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 2,375 0 7,875 5,375 413,625 16,25 141,2917 7,208333
Shift 4,5 91,625 5,625 53,375 604,25 38,375 204,7917 61,125
Ave 3,4375 45,8125 6,75 29,375 508,9375 27,3125 173,0417 34,16667
Median
Day 2,5 0 7,5 5 450 16,5
Shift 3,5 92 5 56 590,5 35
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 90,40625 0 94 3,21875 768,3125 7,125 317,5729 3,447917
Shift 84,5 28,40625 133,5938 17,9375 754 13,875 324,0313 20,07292
Ave 87,45313 14,20313 113,7969 10,57813 761,1563 10,5 320,8021 11,76042
Median
Day 81,5 0 102,5 3 749,5 8
Shift 77 21 131,5 16 736,5 12,5
Test 8 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 2,875 0 3,625 1,375 151,5 5,5 52,66667 2,291667
Shift 7 38 5,625 28,5 218,625 13,75 77,08333 26,75
Ave 4,9375 19 4,625 14,9375 185,0625 9,625 64,875 14,52083
Median
Day 3,5 0 3,5 1,5 182,5 5
Shift 6,5 33,5 5 27 221,5 14
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 142,8438 0 116,875 0,46875 253,5 1,9375 171,0729 0,802083
Shift 218,5 7,625 150,9063 8,375 257,1563 3,3125 208,8542 6,4375
Ave 180,6719 3,8125 133,8906 4,421875 255,3281 2,625 189,9635 3,619792
Median
Day 128,5 0 94,5 0 243,5 1
Shift 228 4,5 156 6,5 269,5 2

Appendix C. Tests 105
Test 9 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 1 0 1,25 0 5 0 2,416667 0
Shift 5,75 16,25 4,5 6,75 10 2 6,75 8,333333
Ave 3,375 8,125 2,875 3,375 7,5 1 4,583333 4,166667
Median
Day 1 0 1 0 4,5 0
Shift 4,5 17 3,5 6 8,5 1
SA Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
Day 0,96875 0 1,125 0 3,4375 0 1,84375 0
Shift 7,03125 1,71875 5,125 0,5625 7,1875 0,1875 6,447917 0,822917
Ave 4 0,859375 3,125 0,28125 5,3125 0,09375 4,145833 0,411458
Day 1 0 1 0 3 0
Shift 6,5 0 4 0 6 0
C.2.3 Weights effect
Test 0 RCL 1 RCL 50 RCL 100 Ave:
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 3,625 26,375 6,5 22,5 359,875 18,75 123,3333 22,54167
R2 3,5 25,5 4,75 19,75 425,625 19,875 144,625 21,70833
Ave 3,5625 25,9375 5,625 21,125 392,75 19,3125 133,9792 22,125
Median
R1 3 20 6 18,5 418 18 142,3333 18,83333
R2 2,5 16,5 4,5 18,5 457,5 19,5 154,8333 18,16667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 73,875 6,84375 109,9063 7,15625 494,375 6,40625 226,0521 6,802083
R2 148,5938 7,40625 180,5806 6,258065 547,0938 5,90625 292,0894 6,523522
Ave 111,2344 7,125 145,2434 6,707157 520,7344 6,15625 259,0707 6,662802
Median
R1 80,5 0 92 4 498 6 223,5 3,333333
R2 157 0 200 2 543 4,5 300 2,166667

Appendix C. Tests 106
Test 1 RCL 1 RCL 50 RCL 100 Ave:
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 5,75 31,75 6,125 27,375 287,625 28,5 99,83333 29,20833
R2 4,25 32,25 6,125 27,625 439,75 27,25 150,0417 29,04167
Ave 5 32 6,125 27,5 363,6875 27,875 124,9375 29,125
Median
R1 4,5 23,5 6,5 25 330,5 28 113,8333 25,5
R2 3 21 6 24,5 432,5 27,5 147,1667 24,33333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 128,4688 8,875 116,8438 9,84375 581,375 11,34375 275,5625 10,02083
R2 243,5 9 186,7813 9,53125 668,5625 11,6875 366,2813 10,07292
Ave 185,9844 8,9375 151,8125 9,6875 624,9688 11,51563 320,9219 10,04688
Median
R1 137,5 1 133 6,5 576 11 282,1667 6,166667
R2 279 1 190 6 674,5 11 381,1667 6
Test 2 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 5,625 26 7,125 17,875 214,75 18 75,83333 20,625
R2 3,375 24,5 5,25 15,625 293,25 18 100,625 19,375
Ave 4,5 25,25 6,1875 16,75 254 18 88,22917 20
Median
R1 4 16 5,5 14 260,5 16 90 15,33333
R2 3 14,5 4 12,5 293 15,5 100 14,16667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 123,6875 6,4375 136 4,5625 360,3125 5,53125 206,6667 5,510417
R2 179,2813 6,09375 263,75 4,34375 377,125 5,21875 273,3854 5,21875
Ave 151,4844 6,265625 199,875 4,453125 368,7188 5,375 240,026 5,364583
Median
R1 127,5 1 139 2 361,5 4 209,3333 2,333333
R2 184 0 306 1,5 391,5 4 293,8333 1,833333

Appendix C. Tests 107
Test 3 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 3,25 31,375 4,125 26 415 23,25 140,7917 26,875
R2 3,75 29,5 4,5 24,875 521,375 23,25 176,5417 25,875
Ave 3,5 30,4375 4,3125 25,4375 468,1875 23,25 158,6667 26,375
Median
R1 3 20 4,5 23 496,5 22 168 21,66667
R2 3,5 24 4 21,5 568,5 20,5 192 22
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 119,3438 9 166 10,03125 662 10,46875 315,7813 9,833333
R2 205,6875 9,34375 277,125 9,84375 717,7813 9,5 400,1979 9,5625
Ave 162,5156 9,171875 221,5625 9,9375 689,8906 9,984375 357,9896 9,697917
Median
R1 98,5 2 186,5 6 654 9,5 313 5,833333
R2 238,5 2 315,5 6 738,5 8 430,8333 5,333333
Test 4 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 5,125 54,75 5 47,25 634,5 37,375 214,875 46,45833
R2 3,625 55,375 4,375 41,75 828,5 38,125 278,8333 45,08333
Ave 4,375 55,0625 4,6875 44,5 731,5 37,75 246,8542 45,77083
Median
R1 4 38,5 5 41,5 780 34,5 263 38,16667
R2 2,5 39,5 4 38,5 873 37 293,1667 38,33333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 85,65625 20,5625 141,4063 19,71875 1028,656 16,84375 418,5729 19,04167
R2 162,875 20,375 217,9063 18,65625 1071,281 18,25 484,0208 19,09375
Ave 124,2656 20,46875 179,6563 19,1875 1049,969 17,54688 451,2969 19,06771
Median
R1 91,5 2 145 6,5 1026 14,5 420,8333 7,666667
R2 176,5 1,5 246 6,5 1084 17,5 502,1667 8,5

Appendix C. Tests 108
Test 5 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 4,25 31,75 5,75 27,75 395,875 29,5 135,2917 29,66667
R2 4,5 30,25 4,75 27,5 551 28,75 186,75 28,83333
Ave 4,375 31 5,25 27,625 473,4375 29,125 161,0208 29,25
Median
R1 3,5 21,5 5,5 23 461,5 30,5 156,8333 25
R2 3,5 18 4 21 576,5 24,5 194,6667 21,16667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 118,3438 10 134,5 10,8125 673,4375 12,09375 308,7604 10,96875
R2 212,1563 9,375 209,3438 10,84375 698,9375 11,75 373,4792 10,65625
Ave 165,25 9,6875 171,9219 10,82813 686,1875 11,92188 341,1198 10,8125
Median
R1 118,5 1,5 160,5 7,5 662 12,5 313,6667 7,166667
R2 239,5 1,5 242,5 8,5 693 10,5 391,6667 6,833333
Test 6 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 5,25 12,5 9,75 9,5 161,375 9,625 58,79167 10,54167
R2 3,125 12,875 7,375 8,875 192,25 10,75 67,58333 10,83333
Ave 4,1875 12,6875 8,5625 9,1875 176,8125 10,1875 63,1875 10,6875
Median
R1 4 6,5 8 7 172,5 10 61,5 7,833333
R2 3 8,5 9 6 202,5 9 71,5 7,833333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 70,28125 2,25 80,3125 1,90625 247,125 2,03125 132,5729 2,0625
R2 123,1563 2,125 110 1,96875 306,3125 2,4375 179,8229 2,177083
Ave 96,71875 2,1875 95,15625 1,9375 276,7188 2,234375 156,1979 2,119792
Median
R1 77,5 0 94 0,5 243,5 1 138,3333 0,5
R2 111,5 0 117 1 311 1,5 179,8333 0,833333

Appendix C. Tests 109
Test 7 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 3,625 45,25 7,75 31,25 418,125 28,5 143,1667 35
R2 3,25 46,375 5,75 27,5 599,75 26,125 202,9167 33,33333
Ave 3,4375 45,8125 6,75 29,375 508,9375 27,3125 173,0417 34,16667
Median
R1 3 28,5 7,5 23,5 486,5 24,5 165,6667 25,5
R2 2,5 29 6 24 674,5 22 227,6667 25
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 65,15625 14,1875 104,6563 10,75 736,7813 11,03125 302,1979 11,98958
R2 109,75 14,21875 122,9375 10,40625 785,5313 9,96875 339,4063 11,53125
Ave 87,45313 14,20313 113,7969 10,57813 761,1563 10,5 320,8021 11,76042
Median
R1 68 1 116,5 4,5 735,5 10 306,6667 5,166667
R2 96 0,5 128 5,5 789,5 8,5 337,8333 4,833333
Test 8 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 4,5 19,75 3,75 15,75 184,125 9,5 64,125 15
R2 5,375 18,25 5,5 14,125 186 9,75 65,625 14,04167
Ave 4,9375 19 4,625 14,9375 185,0625 9,625 64,875 14,52083
Median
R1 4 11,5 3,5 12,5 210 8 72,5 10,66667
R2 4,5 11,5 4,5 11,5 188 9,5 65,66667 10,83333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 148,9375 3,875 101,3125 4,4375 223,0313 2,96875 157,7604 3,760417
R2 212,4063 3,75 166,4688 4,40625 287,625 2,28125 222,1667 3,479167
Ave 180,6719 3,8125 133,8906 4,421875 255,3281 2,625 189,9635 3,619792
Median
R1 140,5 0 99,5 1 220,5 2 153,5 1
R2 235 0 173,5 1 291,5 1,5 233,3333 0,833333

Appendix C. Tests 110
Test 9 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 4 7,25 3,125 3,5 7 1,25 4,708333 4
R2 2,75 9 2,625 3,25 8 0,75 4,458333 4,333333
Ave 3,375 8,125 2,875 3,375 7,5 1 4,583333 4,166667
Median
R1 1,5 1 2 1 5,5 0 3 0,666667
R2 1,5 3 1 1 6,5 0 3 1,333333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
R1 4,65625 0,71875 3,25 0,3125 5 0,0625 4,302083 0,364583
R2 3,34375 1 3 0,25 5,625 0,125 3,989583 0,458333
Ave 4 0,859375 3,125 0,28125 5,3125 0,09375 4,145833 0,411458
Median
R1 2 0 2 0 5 0 3 0
R2 2 0 1,5 0 4 0 2,5 0
C.2.4 Iterations effect
Test 0 RCL 1 RCL 50 RCL 100 Ave:
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 4,125 31,875 5,5 24,625 329,125 21,625 112,9167 26,04167
25 3 20 5,75 17,625 456,375 17 155,0417 18,20833
Ave 3,5625 25,9375 5,625 21,125 392,75 19,3125 133,9792 22,125
Median
5 4 30 6 22,5 412 21,5 140,6667 24,66667
25 2 16 4,5 17 461,5 16,5 156 16,5
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 102,5938 11,59375 133,2188 10,75 517,625 10,28125 251,1458 10,875
2500 119,875 2,65625 156,5161 2,548387 523,8438 2,03125 266,745 2,411962
Ave 111,2344 7,125 144,8674 6,649194 520,7344 6,15625 258,9454 6,643481
Median
500 94 5 152,5 6 504,5 9 250,3333 6,666667
2500 100,5 0 174 1 507,5 2 260,6667 1

Appendix C. Tests 111
Test 1 RCL 1 RCL 50 RCL 100 Ave:
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 5,75 39,25 6,75 30,625 278,625 30,375 142,6875 30,5
25 4,25 24,75 5,5 24,375 448,75 25,375 153,3333 29,66667
Ave 5 32 6,125 27,5 363,6875 27,875 124,6875 26,70833
Median
5 5 37,5 7 30,5 343 29,5 175 30
25 2,5 20 4 23,5 413,5 25 140,8333 28,66667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 174,1875 14,65625 143,5938 15,21875 617,9688 17,3125 311,9167 15,72917
2500 197,7813 3,21875 160,0313 4,15625 631,9688 5,71875 329,9271 4,364583
Ave 185,9844 8,9375 151,8125 9,6875 624,9688 11,51563 320,9219 10,04688
Median
500 163 8,5 144,5 9,5 584 16 297,1667 11,33333
2500 209,5 0,5 153,5 3 606,5 4 323,1667 2,5
Test 2 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 5,75 33,625 8 20,125 203 21,375 72,25 25,04167
25 3,25 16,875 4,375 13,375 305 14,625 104,2083 14,95833
Ave 4,5 25,25 6,1875 16,75 254 18 88,22917 20
Median
5 5 26,5 7 19,5 273,5 21 95,16667 22,33333
25 2,5 14 4 11,5 303 13 103,1667 12,83333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 143,3438 10,71875 187,4375 7,625 369,8125 8,9375 233,5313 9,09375
2500 159,625 1,8125 212,3125 1,28125 367,625 1,8125 246,5208 1,635417
Ave 151,4844 6,265625 199,875 4,453125 368,7188 5,375 240,026 5,364583
Median
500 169,5 4 178,5 4,5 367,5 8 238,5 5,5
2500 177 0 229 0 362,5 1,5 256,1667 0,5

Appendix C. Tests 112
Test 3 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 4 37,25 4,625 28,625 385,375 26,875 131,3333 30,91667
25 3 23,625 4 22,25 551 19,625 186 21,83333
Ave 3,5 30,4375 4,3125 25,4375 468,1875 23,25 158,6667 26,375
Median
5 3,5 34,5 4,5 28,5 492,5 27 166,8333 30
25 2,5 19 4 21 557,5 18 188 19,33333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 154,3125 14,0625 209,3125 14,40625 684,625 14,4375 349,4167 14,30208
2500 170,7188 4,28125 233,8125 5,46875 695,1563 5,53125 366,5625 5,09375
Ave 162,5156 9,171875 221,5625 9,9375 689,8906 9,984375 357,9896 9,697917
Median
500 170,5 7 211,5 11 697 13,5 359,6667 10,5
2500 179 1,5 221,5 4,5 711,5 5 370,6667 3,666667
Test 4 RCL RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 3,375 65,125 4 48,5 613,125 42,375 206,8333 52
25 5,375 45 5,375 40,5 849,875 33,125 286,875 39,54167
Ave 4,375 55,0625 4,6875 44,5 731,5 37,75 246,8542 45,77083
Median
5 3,5 60 2,5 43 831 41 279 48
25 4,5 38 5,5 38 847 31,5 285,6667 35,83333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 117,3125 30,1875 169,6563 28,03125 1044,375 25,21875 443,7813 27,8125
2500 131,2188 10,75 189,6563 10,34375 1055,563 9,875 458,8125 10,32292
Ave 124,2656 20,46875 179,6563 19,1875 1049,969 17,54688 451,2969 19,06771
Median
500 101,5 15,5 192 18,5 1056,5 21,5 450 18,5
2500 108,5 1,5 221 5 1070 7 466,5 4,5

Appendix C. Tests 113
Test 5 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 4,375 38,75 5,25 32,625 378,625 32 129,4167 34,45833
25 4,375 23,25 5,25 22,625 568,25 26,25 192,625 24,04167
Ave 4,375 31 5,25 27,625 473,4375 29,125 161,0208 29,25
Median
5 3 36,5 5 30,5 460,5 32 156,1667 33
25 4 18 4 21 580,5 23 196,1667 20,66667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 154,5 15,1875 163,3438 16,53125 687,75 17,5 335,1979 16,40625
2500 176 4,1875 180,5 5,125 684,625 6,34375 347,0417 5,21875
Ave 165,25 9,6875 171,9219 10,82813 686,1875 11,92188 341,1198 10,8125
Median
500 138,5 7 173,5 12,5 673,5 16 328,5 11,83333
2500 186 1,5 179 4 670,5 6 345,1667 3,833333
Test 6 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 4,625 16,75 10,25 12 147,125 12,625 54 13,79167
25 3,75 8,625 6,875 6,375 206,5 7,75 72,375 7,583333
Ave 4,1875 12,6875 8,5625 9,1875 176,8125 10,1875 63,1875 10,6875
Median
5 3,5 14,5 9,5 11,5 172 10,5 61,66667 12,16667
25 4 6 6 5,5 220 7,5 76,66667 6,333333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 89,5 4 89,65625 3,5 271,9688 4,15625 150,375 3,885417
2500 103,9375 0,375 100,6563 0,375 281,4688 0,3125 162,0208 0,354167
Ave 96,71875 2,1875 95,15625 1,9375 276,7188 2,234375 156,1979 2,119792
Median
500 96 2 102 2 254 3,5 150,6667 2,5
2500 101 0 106 0 261,5 0 156,1667 0

Appendix C. Tests 114
Test 7 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 3,375 55,5 5,875 33,75 406,875 31,375 138,7083 40,20833
25 3,5 36,125 7,625 25 611 23,25 207,375 28,125
Ave 3,4375 45,8125 6,75 29,375 508,9375 27,3125 173,0417 34,16667
Median
5 3 48 6 31 484,5 27 164,5 35,33333
25 3 28,5 7 21,5 635 21 215 23,66667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 80,65625 22,53125 108,8438 16,15625 756,625 15,8125 315,375 18,16667
2500 94,25 5,875 118,75 5 765,6875 5,1875 326,2292 5,354167
Ave 87,45313 14,20313 113,7969 10,57813 761,1563 10,5 320,8021 11,76042
Median
500 77 8,5 123 10 742 13 314 10,5
2500 81 0,5 125,5 2 749,5 4 318,6667 2,166667
Test 8 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 5,75 24,625 5,625 18,375 164,375 11,625 58,58333 18,20833
25 4,125 13,375 3,625 11,5 205,75 7,625 71,16667 10,83333
Ave 4,9375 19 4,625 14,9375 185,0625 9,625 64,875 14,52083
Median
5 5,5 17,5 6,5 16 196 11,5 69,33333 15
25 3,5 11,5 3 11 197 7 67,83333 9,833333
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 172,4688 6,6875 126,875 6,96875 252,7813 4,40625 184,0417 6,020833
2500 188,875 0,9375 140,9063 1,875 257,875 0,84375 195,8854 1,21875
Ave 180,6719 3,8125 133,8906 4,421875 255,3281 2,625 189,9635 3,619792
Median
500 197 1,5 121 3,5 243,5 4 187,1667 3
2500 211 0 134,5 0 255,5 0 200,3333 0

Appendix C. Tests 115
Test 9 RCL 1 RCL 50 RCL 100 Ave
GRASP Z(S) V(S) Z(S) V(S) Z(S) V(S)
5 3,375 12,75 2,125 5,25 8,375 2 4,625 6,666667
25 3,375 3,5 3,625 1,5 6,625 0 4,541667 1,666667
Ave 3,375 8,125 2,875 3,375 7,5 1 4,583333 4,166667
Median
5 2 10 1,5 4 8,5 1 4 5
25 1,5 1 1 1 4,5 0 2,333333 0,666667
SA Z(S) V(S) Z(S) V(S) Z(S) V(S)
500 4,625 1,71875 4,0625 0,5625 6,15625 0,1875 4,947917 0,822917
2500 3,375 0 2,1875 0 4,46875 0 3,34375 0
Ave 4 0,859375 3,125 0,28125 5,3125 0,09375 4,145833 0,411458
Median
500 2 0 2 0 5 0 3 0
2500 2 0 1,5 0 3,5 0 2,333333 0
C.2.5 Highlighted results
12
10
8
6
4
2
0
GRASP-Day-1-2-R2-13%
0 500 1.000 1.500 2.000 2.500 3.000
Iterations
GRASP-Day-1-2-R2-13%-vio GRASP-Day-1-2-R2-13%-value
Working vio Working score
Figure C.1: Optimal solution for test 0

Appendix C. Tests 116
160
140
120
100
80
60
40
20
0
SA-Shift-Fifty-2-R2-13%
0 500 1.000 1.500 2.000 2.500
Iterations
SA-Shift-Fifty-2-R2-13%-vio SA-Shift-Fifty-2-R2-13%-value
Working vio Working score Temperature
Figure C.2: Example of the decreasing temperature
1.000
900
800
700
600
500
400
300
200
100
Temperature

Bibliography
[1] Emile Aarts, Jan Korst, and Wil Michiels. Search Methodologies - Introductory Tu-
torials in Optimization and Decision Support Techniques, pages 187–210. Springer,
2005.
[2] Jonathan F. Bard and Hadi W. Purnomo. Short-term nurse scheduling in response
to daily fluctuations in supply and demand. Health Care Management Sciences, 8:
315–324, 2005.
[3] Edmund Burke, Patrick De Causmaecker, and Greet Vanden Berghe. A Hybrid Tabu
Search for the Nurse Rostering Problem, pages 187–194. Springer, 1999. Lecture
Notes in Artificial Intelligence, vol. 1585.
[4] Edmund K. Burke and Graham Kendall. Search Methodologies - Introductory Tu-
torials in Optimization and Decision Support Techniques, pages 5–18. Springer,
2005.
[5] Edmund K. Burke, Patrick De Causmaecker, Greet Vanden Berghe, and Hen-
drik Van Landeghem. The state of the art of nurse rostering. Journal of Scheduling,
7:441–499, 2004.
[6] Stephen Cook, editor. The Complexity of Theorem Proving Procedures, 1971. Pro-
ceedings of the third annual ACM symposium on Theory of computing.
[7] Tiago M. Dias, Daniel F. Ferber, Cid C. de Souza, and Arnaldo V. Moura. Con-
structing nurse schedules at large hospitals. International Transactions In Opera-
tional Research, 10:245–265, 2003.
[8] Kathryn A. Dowsland. Nurse scheduling with tabu search and strategic oscillation.
European Journal of Operational Research, 106(2):393–407, 1998.
[9] S. Even, A. Itai, and A. Shamir. On the complexity of timetable and multicom-
modity flow problems. SIAM J. Comput, 5:691–703, 1976.
117

Bibliography 118
[10] Michael R. Garey and David S. Johnson. Computers and Intractability: A Guide
to the Theory of NP-Completeness. W. H. Freeman & Co. New York, NY, USA,
1979.
[11] F. Glover. Future paths for integer programming and links to artificial intelligence.
Comput. Oper. Res., (13):533–549, 1986.
[12] Fred Glover and Fred Laguna. Tabu Search. Kluwer Academic Publishers, 1997.
[13] John E. Hopcroft, Rajeev Motwani, and Jeffrey D. Ullman. Introduction to Au-
tomata Theory, Languages, and Computation. Addison-Wesley, 2001.
[14] Rudy Hung. Improving productivity and quality through workforce scheduling.
Industrial Management, 34(6):4–6, 1992.
[15] Richard M. Karp. Complexity of Computer Computations, pages 85–103. R. E.
Miller and J. W. Thatcher (editors). New York: Plenum, 1972. Chapter: Re-
ducibility Among Combinatorial Problems.
[16] Amnon Meisels and Andrea Schaerf. Solving employee timetabling problems by
generalized local search. In Proceedings of the 6th Congress of the Italian Associa-
tion for Artificial Intelligence on Advances in Artificial Intelligence, pages 380–389,
1999.
[17] Henrik Berg Nielsen. Algoritmer til vagtplanlægning for sygeplejersker. Master’s
thesis, Syddansk Universitet Odense, Juni 2006.
[18] Koji Nonobe and Toshihide Ibaraki. An improved tabu search method for the
weighted constraint satisfaction problem. INFOR, 39(1):131–151, 2001.
[19] Mauricio G. C. Resende and Thomas A. Feo. Greedy randomized adaptive search
procedures. Technical report, The University of Texas, Austin, TX 78712 USA and
AT&T Bell Laboratories, Murray Hill, NJ 07974 UAS, February 1994.
[20] Mauricio G. C. Resende and Celso C. Ribeiro. Greedy randomized adaptive search
procedures. Technical Report TD-53RSJY, AT&T Labs Research, August 2002.
Version 2. To appear in State of the Art Handbook in Metaheuristics, F. Glover and
G. Kochenberger, eds., Kluwer, 2002.
[21] Robert Sedgewick and Kevin Wayne. Perm.java, 2006–2007. URL http://www.
cs.princeton.edu/introcs/23recursion/Perm.java.html.
[22] Rhian Silvestro and Claudio Silvestro. An evaluation of nurse rostering practices
in the national health service. Journal of Advanced Nursing, 32(3):525–535, 2000.

Bibliography 119
[23] Kai Toedter. Jcalendar, 2008. URL http://www.toedter.com/en/jcalendar/
index.html.
[24] M. Warner, B. Keller, and S. Martel. Automated nurse scheduling. Journal of the
Society for Health Systems, 2(2):66–80, 1991.
[25] Darrell Whitley and Jean Paul Watson. Search Methodologies - Introductory Tuto-
rials in Optimization and Decision Support Techniques, pages 317–339. Springer,
2005.
[26] David H. Wolpert and William G. Macready. No free lunch theorems for search.
Technical report, Santa Fe Institute, 1995.
[27] David H. Wolpert and William G. Macready. No free lunch theorems for opti-
mization. IEEE Transactions on Evolutionary Computation, 1(67), 1997. URL
http://ic.arc.nasa.gov/people/dhw/papers/78.pdf.