MasterThesis_s130496

SCHEDULING OF RAILWAY INFRASTRUCTURE PROJECTS AT

BANEDANMARK

Shyam Sundar Govindaraja Perumal, s130496

Master Thesis, June 2015

Internal Supervisor: External Supervisor:

Jesper Larsen

Professor/Head of Division Msc Director (Engineering Management) Management Science DTU Management Engineering

Dorte-Lene Bacher

Head of BETA Banedanmark Unit for Interdisciplinary Analysis (BETA)

Banedanmark

Scheduling of Railway Infrastructure Projects at Banedanmark

i


This report is submitted by

Shyam Sundar Govindaraja Perumal S130496

Master of Science in Engineering Management Technical University of Denmark (DTU)

Supervisors

Jesper Larsen, Professor, Department of Management Engineering, DTU Dorte-Lene Bacher, Head of BETA, Banedanmark

Submission Date: 26th June 2015 Duration of the thesis: 5 months Credit Points: 30 ECTS

DTU MANAGEMENT ENGINEERING Produktionstorvet Building 426 2800 Kongens Lyngby Denmark

ii


PREFACE

Lyngby, 26th June 2015

This Master Thesis project is the final requirement to achieve the Master of Science (MSc) degree in Engineering

Management at Technical University of Denmark (DTU). The thesis is equivalent to 30 ECTS and has been carried

out between 26th January 2015 and 26th June 2015. This thesis was conducted at the Management Engineering

Department at DTU in collaboration with Banedanmark. Data was provided by Banedanmark to carry out this

thesis and therefore the information contained in this report is determined to be confidential.

I would like to thank my supervisor Jesper Larsen, Professor at DTU Management Engineering, for guiding me

throughout this thesis by providing useful feedbacks and advices. I especially like to him thank for the flexibility

he has shown in supporting me. I would also like to thank Dorte-Lene Bacher, Head of BETA department at

Banedanmark, for making it possible to carry out this thesis in collaboration with a prestigious organization such

as Banedanmark, and taking meetings with me to discuss and answer my queries.

Furthermore, I would like to thank Anders Woelders for assisting me throughout the process of writing this

thesis. Finally, I would like to thank my parents for their constant support.

Shyam Sundar Govindaraja Perumal, s130496

iii


ABSTRACT

Banedanmark have established a portfolio of over 200 railway infrastructure projects that need to be carried out

in different regions of Denmark during the period 2015 – 2030. This thesis mainly seeks to analyze and solve the

project scheduling problem at Banedanmark. The projects need to be scheduled in a manner that the technical

conflicts between the project activities are minimized and the total cost of project activities for all the years is

leveled or balanced. This type of project scheduling problem where the objective is to level the resource usage

is known as Resource Leveling Problem (RLP) in literature. Two integer programming models are presented that

would act as supporting tools in deciding the schedule of projects. The models are tested for sets of 2-4 projects,

9 projects and 36 projects. This thesis discusses the strengths, weaknesses and the computational behavior of

the models.

Dealing with uncertainties such as delays in completion of the project activities is a matter of concern and

Banedanmark are interested in methods to anticipate the consequences of delays. A predictive-reactive

scheduling model, mentioned by (Van de Vonder, et al., 2007), is presented which is used to anticipate the

consequences of delays in the schedule. Dealing with delays constitutes a minor part of this thesis.

Keywords: Project Scheduling, Integer Programming, Resource Leveling Problem

iv


ABBREVATIONS

The following are the abbreviations used in this thesis.

BETA Banedanmark Unit for Interdisciplinary Analysis

DKK Danish Kroner

IP Integer Program

LP Linear Program

LB Lower Bound

MAD Mean Absolute Deviation

RCPSP Resource Constrained Project Scheduling Problem

RLP Resource Levelling Problem

SPT Strategic Planning Tool

v


DANISH TRANSLATIONS

This thesis contains some Danish terms and the following list shows their English translations.

DANSIH ENGLISH

Bane Railway Line

Broer og Konstruktioner Bridges and Constructions

Elektrificering Electrification

Kørestrøm Traction Current

Sikring og Fjernstyring Securing and Remote

Projektering Designing

Stærkstrøm Power Supply

Spor og Anlægsarbejder Tracks and Development workers

Udførsel Execution

vi


TABLE OF CONTENTS

PREFACE

ABSTRACT

ABBREVATIONS

Danish Translations

CHAPTER 1: Introduction ..............................................................................................................................1

1.1 Thesis Objectives ............................................................................................................................................... 2

CHAPTER 2: Problem Description ..................................................................................................................6

2.1 Definitions ......................................................................................................................................................... 6

2.2 Assumptions ...................................................................................................................................................... 6

2.3 Description of order constraints........................................................................................................................ 8

Factor 1: Order of the phases .......................................................................................................................... 8

Factor 2: Simultaneous start of activities on all route sections of the project ................................................ 9

Factor 3: Coordination Principles ................................................................................................................... 10

2.4 Cost Profile ...................................................................................................................................................... 15

CHAPTER 3: Literature Review .................................................................................................................... 16

3.1 Strategic Planning ............................................................................................................................................ 16

3.2 Project Scheduling ........................................................................................................................................... 18

CHAPTER 4: Methodology .......................................................................................................................... 25

CHAPTER 5: Description of the models ........................................................................................................ 29

5.1 Model 1............................................................................................................................................................ 31

5.2 Model 2............................................................................................................................................................ 50

5.3 Discussion ........................................................................................................................................................ 53

CHAPTER 6: Analysis of smaller subsets of data ........................................................................................... 55

6.1 Model 1............................................................................................................................................................ 56

6.2 Model 2............................................................................................................................................................ 59

vii


6.3 Analysis of LP Relaxation ................................................................................................................................. 62

6.4 Discussion ........................................................................................................................................................ 65

CHAPTER 7: Testing for 36 Projects ............................................................................................................. 68

7.1 Model 1............................................................................................................................................................ 70

7.2 Model 2............................................................................................................................................................ 72

7.3 Discussion ........................................................................................................................................................ 74

CHAPTER 8: Scenario Analysis ..................................................................................................................... 75

8.1 Assumptions .................................................................................................................................................... 75

8.2 Predictive Reactive Scheduling Model ............................................................................................................ 80

8.3 Discussion ........................................................................................................................................................ 86

CHAPTER 9: Conclusion .............................................................................................................................. 89

9.1 Recommendations ........................................................................................................................................... 89

9.2 Further work .................................................................................................................................................... 90

9.3 Final Conclusion ............................................................................................................................................... 91

REFERENCES............................................................................................................................................... 93

APPENDIX .................................................................................................................................................. 97

APPENDIX: C++ code for generating coordination principle equations ................................................................ 97

APPENDIX: GAMS code of Model 1 for 9 projects ............................................................................................... 120

viii

Chapter 1: Introduction

CHAPTER 1: INTRODUCTION

Banedanmark is a state-owned Danish company under the Danish ministry of transport and is responsible for

the maintenance and development of the railway network, which covers over 3,000 km of railway tracks in

Denmark. The activities of the company include monitoring the traffic, maintaining the tracks, developing and

planning the construction and renewal of railway projects. Banedanmark’s straregy (Banedanamrk, 2015) is to

ensure that the railway projects are developed, planned and carried out in the most appropriate manner;

efficient and safe. It is a large company with over 2300 employees and is headquartered in Copenhagen. The

CEO of Banedanmark is Jesper Hansen and Figure 1 below shows the different departments at Banedanmark.

Banedanmark plans to renovate the railway tracks in various parts of Denmark during the period 2015-2030 and

thus have established a portfolio of projects that have to be carried out in the coming years.

‘Roskilde_Kalundborg_Elektrificering_Togfonden’ is an example of a project, which is along the Roskilde-

Kalundborg railway line. A project typically involves executing various activities subject to different order

constraints, which will be explained later in this report. There are over 200 projects that Banedanmark handle

simultaneously which have a total cost of approximately 30,000 million DKK. An overview of the projects should

provide the starting dates of its activities along with the technical conflicts between activities and the cost or

budget required for every year during the period 2015-2030. The technical conflicts are called as “coordination

principles” at Banedanmark and will be described in detail later in this report.

Figure 1 Departments in Banedanmark

1


The coordination principles if not abided could cause severe economic, technical and traffic consequences. Due

to the large number of projects that Banedanmark have to handle simultaneously, satisfying all the coordination

principles is a difficult task and therefore one of the objectives of Banedanmark is to schedule the activities of

the projects in such a way that violations of coordination principles are as little as possible. Once a coordination

principle violation between activities is identified, Banedanmark make appropriate tactical plans on field to

rectify the violation. Each of the activities in a project has an estimated cost or budget and is provided based on

its starting year. The total cost in general is unevenly distributed over the years. The stakeholders such as the

decision makers of the projects would be interested in experiencing a cost profile that is constant over the years.

Therefore, the primary concern for Banedanmark is finding an optimized schedule plan of all the activities that

has minimum coordination principle violations and a desired cost profile, which is almost constant for the entire

period.

1.1 THESIS OBJECTIVES

This thesis is carried out in collaboration with the Management Secretariat department. BETA is a subdivision of

Management Secretariat department and is responsible for cross-functional analysis at Banedanmark. Dorte-

Lene Bacher is the head of BETA and handles the communication process concerning the collection of data from

different departments that are required for planning the project schedule. Different departments at

Banedanmark handle different projects and due to the large project portfolio, having an overview of projects

with effective communication and coordination is important. The Finance department is provided with all details

of the projects from the different departments and is in charge of developing a schedule plan of the projects

which has minimized coordination principle violations and a balanced cost profile over the years. Since 2012,

efforts are being made to develop an effective Strategic Planning Tool (SPT), which helps in efficiently gathering

project data from all departments and in deciding the schedule of the projects. Currently, Banedanmark use a

web application designed by (Prognoz, 2015) to plan and analyze the project schedule. The system accumulates

information about the projects, its related activities and the concerned department. The system calculates the

coordination principle violations between activities and enables users to visualize the total cost required for all

the years. However, the system does not try to minimize the violations or level the cost. The users of the system

manually change the starting dates and ending dates of the activities, and subsequently the system calculates

the violations and the cost for every year. The current SPT designed by (Prognoz, 2015) is not fully functional

across all departments and is in the process of being implemented group-wide.

2


To level the cost for all years, the coordination principles have to be violated in order to move the starting times

of activities between the years. Therefore, minimizing the coordination principle violations and leveling the cost

have been found to be conflicting objectives. The users of the system generate different schedules with varying

coordination principle violations and cost profile, and it is up to the decision makers to decide on the best

schedule.

Delays in completion of activities are common occurrence in railway projects due to various reasons. In the past

years, decision makers at Banedanmark had been choosing a baseline schedule, revisiting it every year to

incorporate delays and revising the schedule plan. The departments concerned with the projects estimate the

delays in completion of the activities years in advance and subsequently inform the schedule planners. Delays

could disrupt the baseline schedule and cause severe violations and economic consequences.

Banedanmark’s strategy is to develop, plan, and carry out the railway projects efficiently and safely. The purpose

of building a SPT is to guide Banedanmark on deciding the optimal schedule plan that has minimal economic

consequences. One of the primary requirements for building an effective SPT is the coordination and

communication between all departments that handle the projects. The process of effectively gathering data from

departments and updating the delays of projects frequently would give an overview of all projects to the

schedule planners and the decision makers to make appropriate strategic plans. However, this thesis does not

address the communication process between departments and the organizational set-up at Banedanmark.

Masters student from Technical University of Denmark, Anders Woelders (Woelders, 2015), would analyze the

process required for implementing a successful SPT system in his thesis. This thesis will mainly address the issue

of scheduling the project activities while minimizing the number of coordination principle violations and

simultaneously leveling the total cost for all years. Building a mathematical model that will unify the number of

coordination principle violations and the cost profile as a function of each other will be the primary objective of

this thesis. The mathematical model would potentially act as a supporting tool in the decision-making process at

Banedanmark. Dealing with uncertainties such as delays in completion of the activities is a matter of concern

and Banedanmark would be interested in methods to anticipate the consequences of delays. Therefore, dealing

with delays would constitute a minor part of this thesis.

Two vital documents, an excel sheet ‘Scenarie_analyse.xlxs’ and an access file ‘20141222_Data’, were provided

by Banedanmark to carry out this thesis. The documents hold crucial information about the planned railway

projects including its costs breakdown. The excel sheet holds the updated information about the projects and

the total cost of the projects. Banedanmark is currently not using the access sheet but it contains detailed project

information by its geographic location, which is relevant for building the mathematical model. Therefore, the

access file was chosen as the input for the model. However, given the time restrictions of this thesis scheduling

3


the projects for the whole of Denmark (over 200 projects) seemed to be infeasible. Therefore, in collaboration

with Dorte-Lene Bacher it was decided that this thesis would undertake scheduling projects from the region of

Sealand. The total number of railway projects from the Sealand region was found to be 54, which were taken

from the updated excel sheet. However, only 36 out of the 54 projects had all the required data in the access

file.

Table 1 shows the 36 projects and the department responsible for each of the project. Therefore, this thesis will

try to find an optimal schedule plan for these 36 projects.

SERIAL No. PROJECT DEPARTMENT 1 F/SP/0429 P2020 Finance 2 Forne Bro bane 19 Finance 3 Forny Bro bane 10 Finance 4 Forny Bro bane 11a P2020 Finance 5 Forny Bro bane 12 P2020 Finance 6 Forny Bro bane 13 Finance 7 Forny Bro bane 13 P2020 Finance 8 Forny Bro bane 19 P2020 Finance 9 Forny Bro bane 21 Finance 10 Forny Bro bane 21 P2020 Finance 11 Forny Bro bane 22 Finance 12 Forny Bro bane 22 P2020 Finance 13 Forny Bro bane 40 Finance 14 Forny Bro bane 51 Finance 15 Forny Bro bane 51 P2020 Finance 16 Forny Bro bane 79 Finance 17 Forny Spor bane 10 Finance 18 Forny Spor bane 11a Finance 19 Forny Spor bane 11a P2020 Finance 20 Forny Spor bane 12 P2020 Finance 21 Forny Spor bane 13 P2020 Finance 22 Forny Spor bane 19 Finance 23 Forny Spor bane 19 P2020 Finance 24 Forny Spor bane 21 P2020 Finance 25 Forny Spor bane 22 Finance 26 Forny Spor bane 22 P2020 Finance 27 Forny Spor bane 40 Finance 28 Forny Spor bane 51 Finance 29 Forny Spor bane 51 P2020 Finance 30 Forny Spor bane 79 Finance 31 Hastighedsopgradering Holbæk-Kalundborg Project Development 32 Hastighedsopgradering Køge Nord-Næstved Project Development 33 Hastighedsopgradering Østerport-Helsingør Project Development 34 Ny Ellebjerg – Flyover Project Development 35 Ny Ellebjerg – Perroner Project Development 36 Roskilde_Kalundborg_Elektrificering_Togfonden Project Development

Table 1 Projects from Sealand region of Denmark

4


The mathematical model will be tested for the 36 projects in this thesis but it is a generic model that could test

any number of projects. Even though this thesis was narrowed down to scheduling 36 projects, it could still be

considered as a challenging problem given the numerous activities that each of the projects possess. It would be

interesting to observe the computational complexity of the problem. The following chapter, CHAPTER 2:

Problem Description, will describe the project scheduling problem and the involved mathematical constraints

in detail. Literature review will be conducted on the different types of project scheduling problems and the

available methods in solving them. From literature review, ideas will be gathered to build the model for solving

the project scheduling problem and to develop a method to deal with delays.

The following points summarize the objectives of this thesis:

1. To conduct a detailed literature review on various types of project scheduling problems and the methods

that were used to solve them.

2. Formulating a mathematical model to generate the baseline project schedule for the period 2015-2030

that minimizes the coordination principle violations and simultaneously balances or levels the cost.

3. To study the computational running time of the problem.

4. To develop a method for anticipating the consequences of delays.

5. Testing the mathematical model for 36 railway projects from the Sealand region of Denmark.

Banedanmark’s current SPT system showed over 90,000 coordination principle violations for all the railway

projects without any prior optimization. The access file, which is chosen as the input data for the model, contains

optimized durations of the activities and thus has reduced coordination principle violations. Therefore, due to

the optimized durations of the activities and the consideration of only railway projects from the Sealand region

the number of coordination principle violations that would be optimized by the model is expected to be

significantly less.

One of Banedanmark’s aim is to establish a mathematical model or algorithm as SPT system to solve their project

scheduling problem in the near future. The models developed in this thesis for generating the baseline schedule

and dealing with delays are considered as a SPT as well and could potentially guide Banedanmark in realizing

their plans.

5

Chapter 2: Problem Description

CHAPTER 2: PROBLEM DESCRIPTION

2.1 DEFINITIONS

There are over 200 railway projects that Banedanmark have to undertake during 2015-2030 period.

‘Roskilde_Kalundborg_Elektrificering_Togfonden’ is an example of a project (P), which is along the Roskilde-

Kalundborg railway line. There are multiple projects that need to be carried out on the same railway line. Route

sections (R) or geographic locations are divisions of the railway line such as tracks between the stations and the

stations. ‘Roskilde-Lejre’ is one of the route sections of Roskilde – Kalundborg railway line. In total, there are

over 600 route sections in Denmark and a route section is generally involved in more than one railway project.

For example, the ‘Roskilde-Lejre’ route section is involved in 4 projects. Every project requires a set of asset

groups (A) operations to be carried out on its route sections. The different asset groups are ’Broer og

Konstruktioner’, ’Kørestrøm’, ’Spor og Anlægsarbejder’, ’IT/Tele’, ’Forst’ and ’Sikring og Fjernstyring’. It is

important to note that the projects and the route sections may not necessarily have all the asset groups involved.

A project along with the asset group and route section undergoes four planning phases (F) namely, ‘Definition’,

‘Program’, ‘Projektering’ and ‘Udførsel’. An activity is defined as a four-dimensional parameter which

comprises of a project, route section, asset group, and phase (𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒑𝒑,𝒓𝒓,𝒂𝒂,𝒇𝒇). Figure 2 in the following page

graphically represents the set-up of an activity with few examples. Due to the large number of projects and route

sections, significant number of activities are generated. The 36 projects from Sealand region have a total of 2239

activities. It is for these four-dimensional activities that the starting dates have to be estimated subject to various

order constraints which will be described in the following subsection.

2.2 ASSUMPTIONS

Before describing the order constrains the following assumptions were considered while building the

mathematical model:

• The earliest starting date of all activities irrespective of its project is 1st July 2015 and the deadline to

complete all activities is 31st December 2030.

• There are no limitations on the number of activities that could be started in a year.

• Once an activity is started, it is completed without any interruption.

• Time and cost of every activity are the only resources that are considered in the model.

6


Activity 1 Activity 3 Activity 2

Set o

f Pha

ses (

F)

Set o

f Pro

ject

s (P)

Roskilde_Kalundborg_elektrificering_Togfonden Forny Bro Bane 79 3 4 …

Set o

f Rou

te

Sect

ions

(R)

Roskilde - Lejre 2 3 4 5 6 …

Set o

f Ass

ets (

A)

Broer og Konstruktioner 2 3 4 …

Definition Program 3 4

Activity 1

p: Roskilde_Kalundborg_elektrificering_Togfonden

r: Roskilde - Lejre

a: Broer og Konstruktioner

f: Definition

Activity 2


r: Roskilde - Lejre


f: Program

Activity 3

p: Forny Bro Bane 79

r: Roskilde - Lejre


f: Definition

Figure 2 Example of an activity

7


2.3 DESCRIPTION OF ORDER CONSTRAINTS

3 Factors or sets of order constraints have been found that influence the starting dates of the activities.

FACTOR 1: ORDER OF THE PHASES

The four phases, ‘Definition’, ‘Program’, ‘Projektering’ and ‘Udførsel’, have to be sequenced in a specified order.

Figure 3 and Figure 4 illustrate two feasible sequences of the different phases. An activity having a ‘Program’

phase (example: Activity 2 from Figure 2) should either start simultaneously with activity having ‘Definition’

phase (example: Activity 1 from Figure 2) as shown in Figure 4 or after the end of ‘Definition’ phase but within 1

year as shown in Figure 3. The ‘Projektering’ phase should start after the end of ‘Program’ phase and ‘Udførsel’

phase after ‘Projektering’ but within their respective year gaps. These set of constraints have to be satisfied

under all circumstances and must never be violated.

Timeline

1) Definition

2) Program 3) Projektering 4) Udførsel

≤ 3 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ≤ 1 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦

Start Date

Timeline

1) Definition 2) Program 3) Projektering 4) Udførsel

≤ 3 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ≤ 1 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ≤ 1 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦

Start Date

Figure 4 Type 2 sequence of phases

Figure 3 Type 1 sequence of phases

8


FACTOR 2: SIMULTANEOUS START OF ACTIVITIES ON ALL ROUTE SECTIONS OF THE PROJECT

Activities within the same project, asset and phase need to start simultaneously on all route sections of the

project. For example, ‘Roskilde_Kalundborg_elektrificering_Togfonden’ project has 22 route sections and if

‘Roskide_Kalundborg_elektrificering_Togfonden’ project needs asset ‘Broer og Konstruktioner’, phase

‘Definition’ to be carried out then all the activities with the similar characteristics on the 22 route sections have

to start simultaneously as depicted in Figure 5 below. It is mandatory for these set of constraints to be fulfilled

at all times and cannot be violated.

The black line in the figure represents the railway line between Roskilde and Kalundborg and the red vertical

lines represents the route sections. ‘Roskilde_Kalundborg_elektrificering_Togfonden’ is a project along the

Roskilde-Kalundborg railway line.

Activity 1

Roskilde_Kalundborg_elektrificering_Togfonden project

Roskilde Kalundborg

Roskilde-Lejre

Example: Asset group ‘Broer og Konstruktioner’, ‘Definition’ phase starts simultaneously on all the route sections of Roskilde_Kalundborg_elektrificering_Togfonden project

Figure 5 Simultaneous start of activities on all route sections of a project with similar characteristics

9


FACTOR 3: COORDINATION PRINCIPLES

As mentioned earlier, there are multiple projects that need to be carried out on the same railway line. Figure 6

below shows an example of such instance. Two projects, ‘Roskilde_Kalundborg_elektrificering_Togfonden’ and

‘Forny Bro Bane 79’, have to be carried out on the Roskilde-Kalundborg railway line but may not include all the

route sections from the railway line. There are few route sections that would be involved in both the projects

such as the ‘Roskilde-Lejre’ route section. It is for these route sections that a set of coordination principles apply.

Table 2 in the following page shows the different coordination principles that have to be considered. One of the

coordination principles will be explained with an example.

These are the coordination principles that were introduced while describing the objectives of this thesis. Due to

the large number of projects, it might be infeasible to satisfy all the coordination principles. Therefore, these

principles could be violated but as little as possible which will be one of the objectives of the mathematical

model.

Roskilde_Kalundborg_elektrificering_Togfonden Project

Roskilde Kalundborg

Roskilde-Lejre

Forny Bro Bane 79 Project

Figure 6 Multiple projects on the same railway line

10


The table below shows the 25 different coordination principles that are applied to pair of activities (Activity X

and Activity Y) on the same route section (R).

Table 2 Coordination Principles

11


Activity 1 and 3 could be recalled from Figure 2 to discuss one of the coordination principles. Coordination

Principle 1 (see Table 2) is applied to pair of activities from two different projects that involves asset ‘Broer og

Konstruktioner’ and phase ‘Definition’ on the same route section (r). Activity 1 and 3 fall under the Coordination

Principle 1 category and will be tested to satisfy the ‘Simultaneous’ principle. If the pair fails to satisfy the

‘Simultaneous’ principle then it is denoted as a violation of coordination principle 1 on ‘Roskilde-Lejre’ route

section.

Coordination Principle 2: Activity x includes asset ‘Broer og Konstruktioner’, phase ‘Definition’ from project (p)

and Activity y includes asset ‘Spor og Anlægsarbejder’, phase ‘Definition’ from a different or the same project

(p’). Both the activities are carried out on the same route section (r). These pairs of activities have to satisfy

‘Simultaneous Start’ principle and are considered as a violation of coordination principle 2 on route section (r) if

it fails to satisfy.

The table in the following page (Table 3) illustrates the set-up pair of activities depending on the principle. The

different principles are ‘Simultaneous’, ‘Simultaneous Start’, ‘Simultaneous End’, ‘Before/Simultaneous’ and

‘Before’.

Activity 1


r: Roskilde - Lejre


f: Definition

Activity 3

p’: Forny Bro Bane 79

r: Roskilde - Lejre


f: Definition

12


Principle Description

Before

Simultaneous

or

Simultaneous Start

Simultaneous End

Timeline

Start End Activity X

Start End Activity Y





Start Activity X

Start Activity Y

End Activity X

End Activity Y

13


Before/Simultaneous

or

or

Table 3 Set-up pair of activities for different principles







14


2.4 COST PROFILE

As mentioned earlier, the other objective of the mathematical model is to level the cost over the period 2015-

2030. One method of leveling the cost is by defining upper and lower limits on the total cost for all years. The

idea is that by defining “strong” cost limits the cost for every year is closer to the average cost. Minimizing the

cost deviation for every year from the estimated average cost is another method of leveling the cost profile. The

cost profile over the years could be analyzed by using the term mean absolute deviation (MAD). Mean absolute

deviation (Glencoe.com, 2015) of a set of data is defined as the mean of distances between each data value and

the average and is given by the formula,

𝑀𝑀𝑀𝑀𝑀𝑀 = 1𝑛𝑛 � |𝑥𝑥𝑖𝑖 − 𝑥𝑥|

2030

𝑖𝑖=2015

where,

𝑛𝑛, is the number of years.

𝑥𝑥𝑖𝑖, is the cost at year 𝑖𝑖.

𝑥𝑥, is the average cost.

15

Chapter 3: Literature Review

CHAPTER 3: LITERATURE REVIEW

Strategic Planning and Project Scheduling are the two fields of study that were considered for the literature

review. Since Banedanmark consider the mathematical model as a strategic planning tool that guides their

decisions in scheduling the projects, a brief review was carried out for Strategic Planning and the following

questions were considered:

1) What is strategic planning?

2) Why organizations do strategic planning?

3) What makes a good strategic plan?

4) What are difficulties that organizations face during strategic planning and its execution?

5) Any method that could address the difficulty?

Developing a project scheduling model forms the foundation of this thesis and therefore a detailed review was

conducted for Project Scheduling. The following questions were taken into account:

1) What are the different types of project scheduling problems that are available in literature?

2) What techniques were used in solving the project scheduling problems?

3) What are the sizes and solution times of the solved problems?

4) Any techniques used in solving project scheduling problems under non-deterministic circumstances?

5) Discussion on importance or growing research in the project scheduling community.

This section concludes with discussion on key findings from both the fields and how they could be interpreted in

Banedanmark’s case.

3.1 STRATEGIC PLANNING

Alfred D. Chandler, leading strategy theorists from Harvard Business School, defined strategy as “the

determination of the long-run goals and objectives of an enterprise, and the adoption of courses of action and

the allocation of resource necessary for carrying out these goals” (Johnson, et al., 2012). However, there are

many definitions to strategy and all strategy definitions could be summed up as the long-term direction of an

organization (Johnson, et al., 2012). It has been argued that managers should define vision, mission and objective

of the organizations as a strategy statement to summarize the organization’s strategy (Collis & Rukstad, 2008).

With the formation of strategy, planning is decision-making process that organizations use in achieving its goals

(Mintzberg, 1994). Where are we at present? What is our future desired state? How do we achieve it? Are some

of the key questions that organizations take into account during strategic planning process.

16


Corporate leaders in the mid-1960s believed that strategic planning was the best way to devise and implement

strategies (Mintzberg, 1994). Strategic planning has its origins in the military arena and over the recent years

private sector organizations have primarily focused on strategic planning with profits being the driving force

(Kriemadis & Theakou, 2007). Strategic planning has found its importance in the public organizations which

enables them to anticipate, respond and adapt to the future (Bryson, 1995). Public sector organizations have

been increasingly turning to strategic planning systems and models to maximize output within a given budget

(Kriemadis & Theakou, 2007). Some of the characteristics of a great strategic plan include (Schneider & Leslie,

2015):

• Cover an appropriate time horizon: The future-focused strategic plan should cover a time horizon,

typically 10 years, and should be informed about the organization’s strategy, mission and vision.

• Consider multiple scenarios: Scenario analysis is a powerful tool and it is recommended to define 3

scenarios or more to evaluate the impact of the alternatives on the organization.

• Maintain consistent altitude: Since the strategic plan extends for a relatively long time, it is

recommended to avoid overly detailed plan but consistent level of strategy should be maintained. The

strategy of the organization should be the focus and every single step should not be included.

• Revisit multiple times over the planning horizon: The strategic plan should be revisited several times

and changes should be made over the course of time, due to the changing environment which will

unravel important information.

Even though strategic planning is not a new concept, many organizations struggle with it due to requirements of

commitment form top-level managers, effective coordination between all levels of the organization and planning

over extensive time horizon (Mintzberg, 1994) & (Schneider & Leslie, 2015). Another important challenging

factor that organizations face in the strategic planning process is the uncertainty in the real world which has

turned into the focal point for strategic planning (Hanafizadeh, et al., 2009). Traditional strategic plans were

developed based on definite forecast of the future but the environment is full of unexpected changes which

often makes the long-term forecasts worthless (Postma & Liebl, 2005). Scenario analysis has been recognized as

an effective method in dealing with uncertainties (Postma & Liebl, 2005) (Hanafizadeh, et al., 2009). Scenario

analysis is a method of creating alternative images of future development of the environment and finding the

crucial uncertainties that have a major impact on the strategic plan (Postma & Liebl, 2005). (Huss & Honton,

1987) found that emphasis on using scenario analysis had been increasing in the business environment and

argued that scenario analysis provides a means for planners to think much more broadly about the future.

(Maack, 2001) discussed that scenario analysis has been made a standard tool for medium- to long-term planning

by organizations and that the objective of using scenario analysis is to develop robust strategic plans. In

17


conclusion, scenario analysis is a tool that is applicable to the planning process of organizations in picturing the

future under uncertain environments and provides as a supporting tool for strategic decision makers.

3.2 PROJECT SCHEDULING

A project typically has set of activities and project scheduling deals with which activities have to be executed at

a particular time (Herroelen, et al., 1998). It was found that project scheduling has been the subject of extensive

research since the early days of operations research (Herroelen, et al., 1998). In the 1950s, the development of

PERT (program evaluation and review technique) and CPM (critical path method) led to project schedules being

represented as network diagram with nodes and arcs (Icmeli, et al., 1993). However, these techniques were

time-based and did not consider the resource restrictions, which are relevant in real-life. Some examples of

resources are money, crew, equipment (Herroelen, et al., 1997). This led to the rise of resource-constraint

project scheduling problem (RCPSP) techniques. RCPSP has become a standard problem in literature for project

scheduling during the last decades (Hartmann & Briskorn, 2010). Due to the presence of resource constraints

and the precedence relations between activities, project scheduling is a difficult task (Hartmann & Briskorn,

2010). Project scheduling is found to be important in project management and software packages are used in

supporting the scheduling process (Herroelen, 2004) (Hartmann & Briskorn, 2010). The foundation of such

project scheduling software is a model that describes the project by set of scheduling constraints and an

objective function (Hartmann & Briskorn, 2010). (Pollack-Johnson & Liberatore, 1998) disclosed in a survey

conducted with members of Project Management Institute that 95% of the software used was for planning and

80% for control.

A basic RCPSP is to schedule the activities, without interruption, subject to the resource constraints and finish-

start precedence relation between activities with zero lag time such that the project duration (makespan) is

minimized (Herroelen, et al., 1997) (Herroelen, et al., 1998) (Hartmann & Briskorn, 2010). However, over the

years various extensions of the RCPSP based on different types of resources, precedence relations and objectives

have been developed (Hartmann & Briskorn, 2010). Resources could be categorized into renewable and

nonrenewable resources. Manpower and machines are some examples of renewable resources, which are

limited on a per-period basis. Example of a nonrenewable resource is budget of the project, which has a limited

capacity for the entire project (Hartmann & Briskorn, 2010). The different precedence relations between

activities are start-start, start-finish, finish-start and finish-finish with minimal and/or maximal lag time

(Herroelen, et al., 1998). Additionally, projects may have earliest start date and deadline constraints (Hartmann

& Briskorn, 2010). Minimizing project duration under fixed resource constraints has been the most common

version of RCPSP (W. Davis & H. Patterson, 1975). To minimize cost of the project (Philips & Dessouky, 1977), to

minimize total project delay (Kurtulus & Davis, 1982), to maximize a project’s net present value (Yang, et al.,

18


1992) and many other various objectives had been designed as RCPSP in the past. The following problems are

some of the important extensions of RCPSP available in literature (Herroelen, et al., 1997) (Herroelen, et al.,

1998) (Hartmann & Briskorn, 2010):

• Preemptive resource-constrained project scheduling problem (PRCPSP)

- In RCPSP, an activity is not interrupted once started. However, in PRCPSP an activity can be

interrupted and resumed at a later time due to resource availability limitations.

• Resource-constrained project scheduling problem with generalized precedence relations (RCPSP-GPR)

- The RCPSP assumes only finish-start precedence relation between activities with zero lag time.

RCPSP-GPR allows for any of the precedence relations (start-finish, finish-start, finish-finish, start-

start) with minimal and maximal lag time between activities.

• Time/Cost trade-off problems

- In Time/Cost trade-off problems the duration of the activity can vary depending on the type and

amount of resources, and activity cost is represented as a function of activity duration. An example

is assigning more workers to an activity would result in shorter duration at a higher cost. The

activities are bounded by maximal allocation of resources and the objective is to determine the

schedule of all activities within the project while minimizing the total cost of all activities.

• Multi-Mode resource-constrained project scheduling problems (MRCPSP)

- The basic RCPSP assumes that an activity is executed in a single mode with fixed duration and fixed

resource requirements. The MRCPSP allows for multiple modes to achieve an activity and each

mode reflects a feasible combination of duration and resources. Minimizing the project duration

is the most common objective of MRCPSP in literature.

• Resource leveling problems (RLP)

- In RLP, the aim is to schedule the activities in order to level the resource usage. Objectives of

minimizing squared deviations of resources around the average resource requirements and

minimizing the absolute deviations of resource requirements have been found in literature.

19


The following figure, Figure 7, categorizes some of the project scheduling problems found in literature:

Numerous techniques and heuristics have emerged to solve RCPSP and its extensions. The formulation of RCPSP

as a 0-1 integer program is the most common technique but due to computational requirements solving it

directly seems to be impractical (Icmeli, et al., 1993). Attempts have been made to obtain strong lower bounds

and then solving RCPSP by branch and bound algorithm (Fisher, 1973) & (Christofides, et al., 1987). (Christofides,

et al., 1987) obtained lower bounds by LP Relaxation and strengthened it by adding valid cuts. They also

performed Lagrangian relaxation and showed that strengthened LP relaxation produced superior lower bounds.

Lagrangian relaxation, a method of relaxing the resource constraints using lagrangian multipliers, has found

importance in the mathematical programming community due to its ability to generate strong bounds for large-

scale optimization problems (Martin, 1999). However, (Fisher, 1973) pointed out that even though the relaxed

problem is easy to solve, the difficulty lies in determining the lagrangian multipliers that produces the good

solution. Subgradient algorithm is one of the methods commonly used in computing good lagrangian multipliers

(Fisher, 1985).

Project Scheduling

Scheduling in the absence of resource constraints

Scheduling under resource constraints

Time analysis of activity network

PERT/CPM

Maximize the net present

value (NPV) of the project

RCPSP PRCPSP RCPSP-GPR MRCPSP RLP Time/Cost Trade-off problems

Figure 7 Categories of project scheduling problems

20


The following table, Table 4, shows some of the project scheduling problems found in literature that were solved

by different approaches:

(Mattila & Abraham, 1998) presented a Resource leveling Problem (RLP) formulation using integer programming

to schedule 9 activities of a highway construction project with the objective to minimize the sum of absolute

deviation of resources from average. The project involved widening of a segment of U.S. Route 41 located in

northern Michigan and some of the 9 activities consisted of removal of existing concrete paving, gravel paving

and ditch excavation. All the activities used the same resources which were dump trucks with different truck

sizes. The formulation tries to level the total resources required on a day-to-day basis for a period of 38 days.

The integer program model was developed in LINDO software and the model had 86 constraints. The formulation

presented by (Mattila & Abraham, 1998) reduced the optimization model to only the required 24 integer

variables out of 138 and thus claimed it to be efficient, but the computation time in solving the problem was not

reported. However, (Mattila & Abraham, 1998) mentioned that integer programs can efficiently solve only

problems of limited size due to the number of integer variables defined.

Author Problem Type Problem Size Solution Time Approach

(Stinson, et al., 1978) Multiple resource-constrained project scheduling problem

The Patterson problem set of 110 test problems (7 to

50 activities and 1 to 3 renewable

resource types)

All 110 problems solved within the time

limit of 300 seconds

Best-first branch and bound procedure

(Russell, 1986) Max-NPV problem with resource

constraints

More than 1000 activities

NA Tested 6 heuristics scheduling rules. “Minimum slack rule”

and “Target Rule” performed the best for large scale

problems

(Christofides, et al., 1987)

Multiple resource-constrained project scheduling problem

25 activities and 3 resources

Maximum 23 seconds

Branch and bound algorithm. Bounds derived from LP

relaxation and Lagrangian relaxation.

(Yang, et al., 1992) Max-NPV problem with resource

constraints

Sets of 20-30 activities

Average 3357 seconds

Integer Programming

(Mattila & Abraham, 1998)

Resource Leveling Problem (RLP)

9 activities NA Integer Programming

Table 4 Examples of project scheduling problems

21


The figure above, Figure 8, shows the number of publications related to resource-constrained project scheduling

problems (RCPSP) and its extensions found from DTU Findit. As (Hartmann & Briskorn, 2010) pointed out, the

research in this field has grown in the last decades. However, most of the project scheduling research efforts

have been focused on scheduling activities of a single project and literature on scheduling of multiple projects is

found to be comparatively less (Herroelen, 2004). Figure 9 shows the number of publications related to multi-

project scheduling problems over the years.

0 1 18 37275

919

1065

0

200

400

600

800

1000

1200

1950-1959 1960-1969 1970-1979 1980-1989 1990-1999 2000-2009 2010-2015(until May

2015)

No.

of p

ublic

atio

ns re

late

d to

RCP

SP

Period

0 11 14 2965

244230

0

50

100

150

200

250

300

1950-1959 1960-1969 1970-1979 1980-1989 1990-1999 2000-2009 2010-2015(until May

2015)

No.

of p

ublic

atio

ns re

late

d to

mul

ti-pr

ojec

t sch

edul

ing

Period

Figure 9 No. of publications related to multi-project scheduling problems

Figure 8 No. of publications related to RCPSP and its extensions

22


(Liberatore & Pollack-Johnson, 2003) and (Maroto, et al., 1999) found that management typically operate in a

multi-project environment and control more than 5 projects simultaneously with each project containing more

than 150 activities. It has been suggested that even a small improvement in the management of multi-projects

would have a significant impact on the project management field. Therefore, (Herroelen, 2004) concludes that

multi-project scheduling offers research opportunities.

Most of the RCPSP research focus has been on developing procedures to generate baseline schedule under

deterministic circumstances but over the years there are growing efforts for project scheduling under uncertain

situations (Herroelen, 2004). During execution of the project, unexpected events such as delays may occur that

could not be foreseen while determining the baseline schedule (Hartmann & Briskorn, 2010). (De Meyer, et al.,

2002) pointed out that managers have identified the need to set up a project uncertainty profile which

characterizes the effect of the uncertainty on the project. Stochastic project scheduling and proactive/reactive

scheduling are the two approaches that have been used in literature to deal with known unknowns (Herroelen,

2004). The idea of proactive/reactive scheduling is to generate a baseline schedule that is sufficiently stable and

incorporate variability (or disruptions) during project execution. Proactive baseline schedule is a robust schedule

in which anticipated disruptions such as delays have limited effect (Herroelen & Leus, 2004) (Hartmann &

Briskorn, 2010). In contrast to proactive scheduling, the aim of reactive scheduling is to re-optimize the baseline

schedule when disruptions have occurred (Herroelen & Leus, 2004) (Hartmann & Briskorn, 2010). The

combination of the baseline schedule and reactive scheduling procedures is referred to as predictive-reactive

scheduling in literature (Herroelen & Leus, 2004). One of the methods of predictive-reactive scheduling was

proposed by (Van de Vonder, et al., 2007), where the activities are rescheduled with minimized sum of deviations

of the starting times from the initially planned starting times (from the baseline schedule).

The following points summarize the key findings from literature review:

Strategic Planning

• Strategic planning is a decision-making process that organizations use in achieving its long-term goals.

• Dealing with uncertainties is one of the primary difficulties that organizations have to confront while

developing and executing strategic plan.

• Organizations have found scenario analysis as a supporting tool in the decision-making process to

anticipate the impact of uncertainties on strategic plans and adapt accordingly.

23


Project Scheduling

• Resource-constrained project scheduling problems are relevant in the real world and have also found

importance in academic field.

• Resource Leveling Problem (RLP) is the academic name given to resource-constrained project scheduling

problems, which have objectives of leveling the resource usage.

• Integer programming is the most common technique in solving resource-constrained project scheduling

problems but is found to be difficult to solve directly due to computational requirements.

• There is growing research in scheduling problems under uncertain situations and managers find the

need to set up project uncertainty profiles.

• Predictive-reactive scheduling has been found in literature as one of the methods to deal with

unexpected events. The objective of predictive-reactive scheduling is to re-optimize the baseline

schedule when disruptions have occurred.

Banedanmark’s project scheduling problem could be characterized as a Resource Leveling Problem (RLP) subject

to many precedence relation constraints (order constraints) between activities with maximal and minimal lag

times. A set of precedence relation constraints is known as coordination principles and this would form another

objective of the problem with minimum violations. Earliest starting date and deadline constraints will also be

included in Banedanmark’s project scheduling problem. The problem also includes resources, duration and the

cost of all the activities. Integer programming would be employed to solve Banedanmark’s project scheduling

problem but since the problem is set in a multi-project environment the computational complexity is expected

to increase.

Experts from both the fields of study agree that uncertainties disrupt long-term plans or schedules and have to

be dealt with. Various scenarios could be generated by incorporating unexpected events such as delays and

scenario analysis could be carried out with the help of predictive-reactive scheduling to observe the impacts of

scenarios on the baseline schedule. The scenario analysis would help in anticipating the critical activity delays

that would affect the long-term plan. As mentioned earlier, scenario analysis would be an effective method in

preparing for the future and would act as an additional supporting tool for decision-makers.

24

Chapter 4: Methodology

CHAPTER 4: METHODOLOGY

Aligning the objective of the mathematical model to Banedanmark’s strategy of planning and developing projects

in a safe and efficient manner should be the primary focus. Therefore, how to build an effective mathematical

model that helps the decision makers at Banedanmark to decide a safe and efficient project schedule? is the

main question to be answered. A model is considered effective if it schedules the activities in a manner that the

number of coordination principle violations is minimized which causes minimal economic, technical, traffic

consequences and Banedanmark would be able to efficiently use their resources. Another characteristic of an

effective model is if it could simultaneously level the total cost for the period according to the desired use. This

would also help the decision makers in budget plans for every year. It has been found from literature review that

delays in completion of activities could potentially disrupt the schedule. Therefore, a method which helps

Banedanmark to anticipate the impacts of delays on the schedule and adapt accordingly will form an additional

supporting tool.

Two integer programming mathematical models will be developed which have potentials of generating

optimized baseline schedule for the period 2015 – 2030. The objective of Model 1 would be to decrease the

number of coordination principle violations with the introduction of two cost limit constraints (i.e., lower and

upper limits on the total cost for all years). The effect of strengthening the cost limits on the coordination

principle violations will be observed. However, the model does not try to minimize the MAD of the cost profile

but it is believed that the MAD would decrease with tightening cost limit constraints.

Multi-Objective Optimization

During optimization in management and engineering fields, often conflicting objectives have to be satisfied

(Ngatchou, et al., 2005) and this led to the rise of multi-objective optimization problems. A multi-objective

problem is commonly solved by weighted-sum approach, where all the objectives are added using different

weight coefficients for each one of them as shown in the equation below (Coello, 1999). This approach has been

used in wide range of applications but requiring prior knowledge about the relative importance of the objective,

determining the appropriate weights of the objectives are some of the limitations of the weighted sum approach

(Coello, 1999) and (Ngatchou, et al., 2005).

𝑚𝑚𝑖𝑖𝑛𝑛 �𝑤𝑤𝑖𝑖𝑓𝑓𝑖𝑖(𝑥𝑥)𝑘𝑘

𝑖𝑖=1

where 𝑤𝑤𝑖𝑖 ≥ 0 is weight coefficient representing the importance of the objectives and generally ∑ 𝑤𝑤𝑖𝑖 = 1𝑘𝑘𝑖𝑖=1 .

25


Since, minimizing the coordination principle violations and leveling the cost have been found to be conflicting

objectives, Model 2 is defined as a multi-objective optimization problem with the overall objective to minimize

the coordination principle violations and MAD. Model 2 will be tested for varying weight coefficients of each

objective, and their effect on the coordination principle violations and MAD will be observed.

Developing these two models (Model 1 and Model 2) will form the basis of this thesis. Figure 10 illustrates the

overview of the models. The models will be first tested for a smaller problem with 9 projects before testing for

36 projects and the computational running times of the models will be studied. Lower bounds will be generated

by methods such as linear programming relaxation to determine the quality of the attained feasible solutions

and to analyze the strength of the model formulations.

Both the models are developed in GAMS software and all the tests are run on system with 3.60 GHz Intel Core i7

processors and RAM of 16 GB. A method is implemented in C++ to generate coordination principle constraints

(Factor 3: Coordination Principles) that are required for different pairs of activities. The generated constraints

are then manually embedded in the GAMS model for optimization. The method implemented in C++ is described

later in this report.

INPUT

A

Sets:

Activities (Projects, Route sections, Assets, Phases)

Parameters:

Duration and cost of activities.

Objective:

• To minimize coordination principles violations. • To minimize MAD (for Model 2)

Constraints:

• Earliest starting date and deadline constraints. • Factor 1: Order of phases constraints • Factor 2: Simultaneous start constraints • Factor 3: Coordination Principles • Cost limit constraints (For Model 1)

MODEL

OUTPUT

• Start and end date of activities • Number of coordination principle violations • Total cost for every year

Figure 10 Overview of the integer programming models

26


The thesis will mainly answer the following questions:

1. How does decreasing the coordination principle violations and decreasing MAD affect each other?

Model 1 and Model 2 are set-up as two different problems and their results would be analyzed to

determine the relationship between coordination principle violations and MAD.

2. What are the strengths and weaknesses of Model 1 and Model 2?

The benefits that each of the models provide to the decision makers would be discussed along with their

respective downsides. The results from both the models would be compared as well to discuss which

model could potentially generate a better solution in terms of coordination principle violations and MAD

of the cost profile.

3. Could the models be implemented to optimize all the projects at Banedanmark?

There are over 200 projects at Banedanmark and the feasibility to optimize all the projects at

Banmedanmark is probably the most important question to be answered in this thesis. The difficulties

that one would encounter during implementation such as computational running time will be discussed.

Finally, discussion will be carried out on what Banedanmark could take away from this thesis.

A model to incorporate delays will be developed based on predictive-reactive scheduling with the objective of

minimizing deviation from the baseline schedule which was proposed by (Van de Vonder, et al., 2007). Though

delays are not known in advance, the model could be used to test different scenarios with varying activity delays

and its effect on the baseline schedule could be observed. For this thesis, real data on activity delays was not

provided so the scenario analysis is based on assumption but it serves as a tool to foresee the consequences of

the delays. One of the outputs of Model 1 and Model 2 is chosen as the baseline schedule and forms the basis

of the scenario analysis. In real life, the baseline schedule is chosen based on various criteria such as political

interests, technical feasibility, resource availability etc. For this thesis, the model that produces the most

promising schedule in terms of no. of coordination principle violations, MAD will be chosen as the baseline

schedule.

27


The figure below, Figure 11, summarizes the methodology and the 4 steps that will be followed in this thesis.

Developing Model 1 and Model 2 (Step 1) and analyzing the results of the models are the focus of this thesis.

There will be a small section in this thesis regarding the predictive-reactive scheduling model and scenario

analysis.

Figure 11 Methodology

METHODOLOGY

cost limits

28

CHAPTER 5: Description Of The Models

CHAPTER 5: DESCRIPTION OF THE MODELS

In this chapter Model 1 and Model 2 are described and tested for 9 projects. The constraints for both models will

be described along with the method that generates the coordination principle constraints in C++. The objective

function and few constraints are the only differences between the models. The computation time of the different

tests will be studied in this chapter and lower bounds by Linear Programming (LP) relaxation will be generated

to discuss the strength of the model formulations. This chapter concludes with discussion on results obtained

from both the models.

The 9 projects are carried out along the Roskilde-Kalundborg railway line and are shown in Table 5. Table 6 shows

the 22 route sections that are on the Roskilde-Kalundborg railway line. As mentioned in CHAPTER 2: Problem

Description, not all projects consist of all the route sections. Table 7 in the following page shows the projects

and their respective route sections on which activities are carried out. With the inclusion of assets and phases,

the total number of activities for the 9 projects was found to be 856.

Table 5 Projects of Roskilde-Kalundborg railway line

Table 6 Route sections on Roskilde-Kalundborg railway line

Serial No.

Route Sections (R) Identification

Number

1 Roskilde – Lejre 52034

2 Lejre 52041

3 Lejre – Hvalsø 52042

4 Hvalsø 52049

5 Hvalsø – Tølløse 52050

6 Tølløse 52055

7 Tølløse – Vipperød 52056

8 Vipperød 52061

9 Vipperød – Holbæk 52062

10 Holbæk 52067

11 Holbæk – Regstrup 52068

12 Regstrup 52075

13 Regstrup – Mørkøv 52076

14 Mørkøv 52083

15 Mørkøv – Jyderup 52084

16 Jyderup 52089

17 Jyderup - Svebølle 52092

18 Svebølle 52097

19 Svebølle – Værslev 52098

20 Værslev 52103

21 Værslev – Kalundborg 52104

22 Kalundborg 53000

Serial No.

Projects (P)

1 Roskilde_Kalundborg_Elektrificering_Togfonden

2 Forny Spor Bane 79

3 Forny Bro Bane 79

4 E_ROL_8

5 Hastighedsopgradering Holbæk Kalundborg



8 Forny Bro Bane 51

9 Forny Bro Bane P2020

29


Serial No.

Projects (P) Subset of Route sections

1 Roskilde_Kalundborg_Elektrificering_Togfonden 52034, 52041, 52042, 52049, 52050, 52055, 52056, 52061, 52062, 52067, 52068, 52075, 52076, 52083, 52084, 52089, 52092, 52097, 52098, 52103, 52104, 53000

2 Forny Spor Bane 79 52034, 52041, 52042, 52049, 52050, 52055, 52056, 52061, 52062, 52067

3 Forny Bro Bane 79 52034, 52041, 52042, 52049, 52050, 52055, 52056, 52062, 52067

4 E_ROL_8 52034, 52041, 52042, 52049, 52050, 52055, 52056, 52061, 52062, 52067, 52068, 52075, 52076, 52083, 52084, 52089, 52092, 52097, 52098, 52103, 52104, 53000

5 Hastighedsopgradering Holbæk Kalundborg 52068, 52075, 52076, 52083, 52084, 52089, 52092, 52097, 52098, 52103, 52104, 53000

6 Forny Spor Bane 51 52068, 52075, 52083, 52089, 52097, 52098, 52103, 52104, 53000

7 Forny Spor Bane 51 52068, 52075, 52076, 52083, 52084, 52089, 52092, 52097, 52098, 52103, 52104, 53000

8 Forny Bro Bane 51 52068, 52075, 52076, 52083, 52084, 52092, 52103, 52104

9 Forny Bro Bane P2020 52068, 52075, 52076, 52083, 52084, 52092, 52103, 52104

Table 7 Projects with their route sections

30


5.1 MODEL 1

The objective is to minimize the total number of coordination principles violated for all route sections. Two cost

constraints were added in the model which sets the lower and upper cost limits for all the years (2015 to 2030).

The aim is to set the cost limits close to the average cost of all activities and observe its effect on the number of

coordination principles violated. It is expected that by tightening the cost limits for every year closer to the

average, the MAD would eventually decrease. However, the objective function in the model does not specifically

minimize MAD.

Sets

P/P’ Set of projects

R Set of route sections

A Set of Asset Groups

F Set of Phases

C Set of Coordination principles, {1 to 25}

YEAR Set of funding period years, {2015 to 2030}

SIM Set of ‘Simultaneous’ and ‘Before/Simultaneous’ coordination principle constraints.

For instance, coordination principle 1 is a ‘Simultaneous’ principle where the pair of activity could

satisfy either one of the mathematical description (See Table 3 in CHAPTER 2: Problem

Description). Therefore, objects ‘1_1’ and ‘1_2’ was created for each of the descriptions

respectively. Similarly, objects were created for all the ‘Simultaneous’ and ‘Before/Simultaneous’

coordination principles which are coordination principle 4, 5, 6, 7, 8, 10, 12, 13, 14, 15, 17, 19, 20,

22, 24 and 25.

𝑅𝑅𝑅𝑅𝑝𝑝(𝑅𝑅) Subset of route sections (R) that are part of a project p.

Example: For ‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project, subset 𝑅𝑅𝑅𝑅1(𝑅𝑅) was

created with all the involved route sections as shown in Table 7. Similarly, sets 𝑅𝑅𝑅𝑅2(𝑅𝑅) to 𝑅𝑅𝑅𝑅9(𝑅𝑅)

was defined for all the projects from Table 7.

31


Parameters

𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 �1, 𝑖𝑖𝑓𝑓 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑎𝑎𝑝𝑝𝑛𝑛𝑦𝑦𝑖𝑖𝑦𝑦𝑎𝑎𝑦𝑦 𝑝𝑝𝑓𝑓 𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎 𝑝𝑝, 𝑦𝑦𝑝𝑝𝑟𝑟𝑎𝑎𝑦𝑦 𝑦𝑦𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑦𝑦,𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎 𝑦𝑦 𝑦𝑦𝑛𝑛𝑎𝑎 𝑝𝑝ℎ𝑦𝑦𝑦𝑦𝑦𝑦 𝑓𝑓 0, 𝑝𝑝𝑎𝑎ℎ𝑦𝑦𝑦𝑦𝑤𝑤𝑖𝑖𝑦𝑦𝑦𝑦

𝑙𝑙𝑦𝑦𝑛𝑛𝑙𝑙𝑎𝑎ℎ𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 Duration of the activity [months].

𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 Cost of the activity [million DKK].

𝑙𝑙𝑖𝑖𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 Parameter holding the value equivalent to the year. (Example: year 2015 has a value of 2015.)

Variables

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 Start date of activity [Serial day number from 1st January 1900].

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 End date of activity [Serial day number from 1st January 1900].

𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 A binary variable indicating the start year of the activity.

�1, 𝑖𝑖𝑓𝑓 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑦𝑦 𝑖𝑖𝑛𝑛 𝑎𝑎ℎ𝑦𝑦 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 0, 𝑝𝑝𝑎𝑎ℎ𝑦𝑦𝑦𝑦𝑤𝑤𝑖𝑖𝑦𝑦𝑦𝑦

𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 Variable that calculates the total cost for the year [million DKK].

𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎 A binary variable indicating the order of ‘Definition’ and ‘Program’ phase as shown in Factor 1: Order of the phases.

�1, 𝑖𝑖𝑓𝑓 𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎 𝑝𝑝 𝑦𝑦𝑝𝑝𝑟𝑟𝑎𝑎𝑦𝑦 𝑦𝑦𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑦𝑦 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎 𝑦𝑦 𝑝𝑝ℎ𝑦𝑦𝑦𝑦𝑦𝑦 ′𝑃𝑃𝑦𝑦𝑝𝑝𝑙𝑙𝑦𝑦𝑦𝑦𝑚𝑚′ 𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑦𝑦

𝑦𝑦𝑓𝑓𝑎𝑎𝑦𝑦𝑦𝑦 𝑎𝑎ℎ𝑦𝑦 𝑦𝑦𝑛𝑛𝑎𝑎 𝑝𝑝𝑓𝑓 ′𝑀𝑀𝑦𝑦𝑓𝑓𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛′ 0, 𝑖𝑖𝑓𝑓 ′𝑃𝑃𝑦𝑦𝑝𝑝𝑙𝑙𝑦𝑦𝑦𝑦𝑚𝑚′ 𝑝𝑝ℎ𝑦𝑦𝑦𝑦𝑦𝑦 𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑦𝑦 𝑦𝑦𝑖𝑖𝑚𝑚𝑟𝑟𝑙𝑙𝑎𝑎𝑦𝑦𝑛𝑛𝑦𝑦𝑝𝑝𝑟𝑟𝑦𝑦𝑙𝑙𝑦𝑦 𝑤𝑤𝑖𝑖𝑎𝑎ℎ ′𝑀𝑀𝑦𝑦𝑓𝑓𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛′ 𝑝𝑝ℎ𝑦𝑦𝑦𝑦𝑦𝑦

𝑦𝑦𝑟𝑟,𝑐𝑐 A binary variable indicating the coordination principle violation

�1, 𝑖𝑖𝑓𝑓 𝑎𝑎𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑖𝑖𝑛𝑛𝑦𝑦𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑝𝑝𝑦𝑦𝑖𝑖𝑛𝑛𝑎𝑎𝑖𝑖𝑝𝑝𝑙𝑙𝑦𝑦 𝑎𝑎 𝑖𝑖𝑦𝑦 𝑎𝑎𝑖𝑖𝑝𝑝𝑙𝑙𝑦𝑦𝑎𝑎𝑦𝑦𝑎𝑎 𝑝𝑝𝑛𝑛 𝑦𝑦𝑝𝑝𝑟𝑟𝑎𝑎𝑦𝑦 𝑦𝑦𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑦𝑦 0, 𝑝𝑝𝑎𝑎ℎ𝑦𝑦𝑦𝑦𝑤𝑤𝑖𝑖𝑦𝑦𝑦𝑦

𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,𝑠𝑠𝑖𝑖𝑠𝑠 A binary variable that indicates which ‘simultaneous’ or ‘Before/Simultaneous’ principle is chosen while comparing two activities as described in Table 3.

�1, 𝑖𝑖𝑓𝑓 𝑦𝑦𝑖𝑖𝑚𝑚𝑟𝑟𝑙𝑙𝑎𝑎𝑦𝑦𝑛𝑛𝑦𝑦𝑝𝑝𝑟𝑟𝑦𝑦 𝑝𝑝𝑦𝑦𝑖𝑖𝑛𝑛𝑎𝑎𝑖𝑖𝑝𝑝𝑙𝑙𝑦𝑦 𝑦𝑦𝑖𝑖𝑚𝑚 𝑖𝑖𝑦𝑦 𝑛𝑛𝑝𝑝𝑎𝑎 𝑎𝑎ℎ𝑝𝑝𝑦𝑦𝑦𝑦𝑛𝑛 𝑓𝑓𝑝𝑝𝑦𝑦 𝑦𝑦𝑝𝑝𝑟𝑟𝑎𝑎𝑦𝑦 𝑦𝑦𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑦𝑦

𝑏𝑏𝑦𝑦𝑎𝑎𝑤𝑤𝑦𝑦𝑦𝑦𝑛𝑛 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑎𝑎𝑦𝑦 𝑝𝑝𝑓𝑓 𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎 𝑝𝑝 𝑦𝑦𝑛𝑛𝑎𝑎 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑎𝑎𝑦𝑦 𝑝𝑝𝑓𝑓 𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎 𝑝𝑝′ 0, 𝑝𝑝𝑎𝑎ℎ𝑦𝑦𝑦𝑦𝑤𝑤𝑖𝑖𝑦𝑦𝑦𝑦

𝑧𝑧 Objective function that calculates the number of coordination principles violated.

𝑦𝑦, 𝑥𝑥, 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦,𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝 ∈ (0,1)

𝑦𝑦, 𝑦𝑦, 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ∈ 𝑅𝑅+

32


Objective Function

𝑴𝑴𝒂𝒂𝑴𝑴𝒂𝒂𝑴𝑴𝒂𝒂𝑴𝑴𝑴𝑴 𝑴𝑴 = ��𝒂𝒂𝒓𝒓,𝒂𝒂𝒂𝒂∈𝑪𝑪𝒓𝒓∈𝑹𝑹

The objective is to minimize the total number of coordination principles violated on all route sections.

Constraints

Earliest starting date and deadline constraints

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ≥ 𝑝𝑝𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦(2015, 7, 1) ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(1)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 = 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 + 𝑙𝑙𝑦𝑦𝑛𝑛𝑙𝑙𝑎𝑎ℎ𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ∗ 30 ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(2)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ≤ 𝑝𝑝𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦(2030,12,31) ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(3)

Equation (1) states that the activity should start on or after 1st July 2015. jdate (Rosenthal, 2015) is a function in

GAMS that is used to convert a date to a serial day number calculated from 1st January 1900. Equation (2)

calculates the end date of the activity which depends on the start date and the length of the activity. All activities

must end before 31st December 2030 as shown in Equation (3).

Factor 1: Order of phases constraints

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + �𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎 ∗ 𝑀𝑀� ..(4)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − [𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎 ∗ 𝑀𝑀] ..(5)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 1 − ��1 − 𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎� ∗ 𝑀𝑀� ..(6)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 365 + ��1 − 𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎� ∗ 𝑀𝑀� ..(7)

Equation (4) to (7) are defined ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓𝑝𝑝𝑦𝑦 𝑓𝑓 = 𝑀𝑀𝑦𝑦𝑓𝑓𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛,𝑃𝑃𝑦𝑦𝑝𝑝𝑙𝑙𝑦𝑦𝑦𝑦𝑚𝑚. With the help of the binary

variable 𝑝𝑝𝑎𝑎𝑦𝑦𝑚𝑚𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎 and the “Big M method”, the start date of ‘Program’ phase (𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠) could be either

the same start date as the ‘Definition’ phase �𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷�, guided by Equations (4) and (5), or could be a

date after the end of ‘Definition’ phase (𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷) but within 1 year, guided by Equations (6) and (7).

33


𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 + 1 ..(8)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 + (3 ∗ 365) ..(9)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑈𝑈𝑈𝑈𝑓𝑓𝑃𝑃𝑟𝑟𝑠𝑠𝑦𝑦𝑈𝑈 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 1 ..(10)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑈𝑈𝑈𝑈𝑓𝑓𝑃𝑃𝑟𝑟𝑠𝑠𝑦𝑦𝑈𝑈 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 365 ..(11)

Similarly, the ‘Projektering’ phase should start after the finish of ‘Program’ phase but within a maximum gap of

3 years and the ‘Udforsel’ phase after the finish of ‘Projektering’ phase within a maximum gap of 1 year. These

constraints are shown by Equations (8), (9), (10) and (11) respectively.

Equations (8) and (9) are defined ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓𝑝𝑝𝑦𝑦 𝑓𝑓 = 𝑃𝑃𝑦𝑦𝑝𝑝𝑙𝑙𝑦𝑦𝑦𝑦𝑚𝑚,𝑃𝑃𝑦𝑦𝑝𝑝𝑝𝑝𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙.

Equations (10) and (11) are defined ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀, 𝑓𝑓𝑝𝑝𝑦𝑦 𝑓𝑓 = 𝑃𝑃𝑦𝑦𝑝𝑝𝑝𝑝𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙,𝑈𝑈𝑎𝑎𝑓𝑓𝑝𝑝𝑦𝑦𝑦𝑦𝑦𝑦𝑙𝑙.

Factor 2: Simultaneous start on all route sections of the project

Activities that involve the same asset group and phase, must be carried out simultaneously on all the route

sections of the project. The following equation shows the simultaneous start of activities for all the route

sections, subset 𝑅𝑅𝑅𝑅1(𝑅𝑅), on the ‘Roskilde Kalundborg Elektrificering Togfonden’ project.

𝑦𝑦𝑝𝑝 ,𝑟𝑟𝑠𝑠1 ,𝑎𝑎 ,𝑓𝑓 = 𝑦𝑦𝑝𝑝 ,𝑟𝑟𝑠𝑠1+1 ,𝑎𝑎 ,𝑓𝑓 ..(12)

The equations are defined 𝑓𝑓𝑝𝑝𝑦𝑦 𝑝𝑝 = 𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑛𝑛𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛,∀𝑦𝑦𝑦𝑦1 ∈ 𝑅𝑅𝑅𝑅1(𝑅𝑅),𝑦𝑦 ∈

𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹.

Similarly, simultaneous start constraints are created for all the projects from Table 7 with their respective set of

route sections [𝑅𝑅𝑅𝑅2(𝑅𝑅) to 𝑅𝑅𝑅𝑅9(𝑅𝑅)].

34


Factor 3: Coordination Principles

As mentioned in CHAPTER 2: Problem Description, due to the large number of activities it might not be

feasible to satisfy all the coordination principles (Factor 3 constraints). Therefore, a binary variable 𝒂𝒂𝒓𝒓,𝒂𝒂 was

created which is set as 1 if coordination principle 𝑎𝑎 is violated on route section 𝑦𝑦 and the objective of the model

is to minimize these violations. There are 25 coordination principles for every route section (shown in Table 2)

and depending on the coordination principle any of ‘simultaneous’, ‘simultaneous start’, ‘simultaneous end’,

‘before/simultaneous’ and ‘before’ principles needs to be generated as described in Table 3.

The coordination principle constraints are generated using a method implemented in C++. It compares two

activities that are on the same route section at a time and categorizes as to which coordination principle is

needed. Once a pair of activities is recognized to fall under a certain coordination principle, relevant equations

are generated. Finally, all the generated equations are placed in GAMS for optimization.

The following Equations (13) to (17) demonstrate one example each of coordination principles with

‘simultaneous’, ‘simultaneous start’, ‘simultaneous end’, ‘before/simultaneous’ and ‘before’ principles.

• Coordination Principle 1: ‘Simultaneous’ principle

For a pair of activities to fall under coordination principle 1, the activities need to have asset ‘Broer og

Konstruktioner’ and phase ‘Definition’ on the same route section. The pair of activities under coordination

principle 1 need ‘Simultaneous’ constraints. This could be recalled from Table 2.

Figure 13 in the following page illustrates the method for calculating the number of pairs of activities under

coordination principle 1 and generates the relevant equations. The method implemented in C++ was run for all

the activities from the 9 projects and the total number of pairs of activities that need coordination principle 1

constraints was found to be 36. Figure 12 shows a pair of activities that is categorized as coordination principle

1 which needs ‘Simultaneous’ constraints.

Figure 12 Example of pair of activities under Coordination Principle 1

Activity x


r: Roskilde – Lejre (52034)


f: Definition

Activity y

p’: Forny_Bro_Bane_79



f: Definition

35


TRUE

TRUE

FALSE

𝑦𝑦 = 𝑦𝑦 + 1

FALSE

𝑥𝑥 = 𝑥𝑥 + 1

TRUE

FALSE

START

𝐼𝐼𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑙𝑙𝑖𝑖𝑧𝑧𝑦𝑦 𝑥𝑥 = 0

𝑖𝑖𝑓𝑓 (𝑥𝑥 < 𝑛𝑛𝑝𝑝. 𝑝𝑝𝑓𝑓 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑦𝑦)

𝑖𝑖𝑓𝑓 {(𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎[𝑥𝑥] == ′𝐵𝐵𝑦𝑦𝑝𝑝𝑦𝑦𝑦𝑦_𝑝𝑝𝑙𝑙_𝐾𝐾𝑝𝑝𝑛𝑛𝑦𝑦𝑎𝑎𝑦𝑦𝑟𝑟𝑃𝑃𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛𝑦𝑦𝑦𝑦′) &&

(𝑝𝑝ℎ𝑦𝑦𝑦𝑦𝑦𝑦[𝑥𝑥] ==′ 𝑀𝑀𝑦𝑦𝑓𝑓𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛′)}

𝐼𝐼𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑙𝑙𝑖𝑖𝑧𝑧𝑦𝑦 𝑦𝑦 = 𝑥𝑥 + 1

𝑖𝑖𝑓𝑓 (𝑦𝑦 < 𝑛𝑛𝑝𝑝. 𝑝𝑝𝑓𝑓 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑦𝑦)

𝑖𝑖𝑓𝑓 {(𝑦𝑦𝑝𝑝𝑟𝑟𝑎𝑎𝑦𝑦 𝑦𝑦𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛[𝑦𝑦] == 𝑦𝑦𝑝𝑝𝑟𝑟𝑎𝑎𝑦𝑦 𝑦𝑦𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛[𝑥𝑥]) &&

(𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎[𝑦𝑦] == ′𝐵𝐵𝑦𝑦𝑝𝑝𝑦𝑦𝑦𝑦_𝑝𝑝𝑙𝑙_𝐾𝐾𝑝𝑝𝑛𝑛𝑦𝑦𝑎𝑎𝑦𝑦𝑟𝑟𝑃𝑃𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛𝑦𝑦𝑦𝑦′) &&

(𝑝𝑝ℎ𝑦𝑦𝑦𝑦𝑦𝑦[𝑦𝑦] ==′ 𝑀𝑀𝑦𝑦𝑓𝑓𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛′)}

𝑀𝑀𝑖𝑖𝑦𝑦𝑝𝑝𝑙𝑙𝑦𝑦𝑦𝑦 "𝑀𝑀𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑥𝑥 𝑦𝑦𝑛𝑛𝑎𝑎 𝑦𝑦 𝑛𝑛𝑦𝑦𝑦𝑦𝑎𝑎 𝐶𝐶𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑖𝑖𝑛𝑛𝑦𝑦𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑃𝑃𝑦𝑦𝑖𝑖𝑛𝑛𝑎𝑎𝑖𝑖𝑝𝑝𝑙𝑙𝑦𝑦 1"

𝑎𝑎𝑝𝑝1 = 𝑎𝑎𝑝𝑝1 + 1

𝐼𝐼𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑙𝑙𝑖𝑖𝑧𝑧𝑦𝑦 𝑎𝑎𝑝𝑝1 = 0, 𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑦𝑦𝑏𝑏𝑙𝑙𝑦𝑦 𝑎𝑎𝑝𝑝1 𝑎𝑎𝑝𝑝𝑟𝑟𝑛𝑛𝑎𝑎𝑦𝑦 𝑎𝑎ℎ𝑦𝑦 𝑝𝑝𝑦𝑦𝑖𝑖𝑦𝑦𝑦𝑦 𝑝𝑝𝑓𝑓 𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑎𝑎𝑖𝑖𝑦𝑦𝑦𝑦 𝑎𝑎ℎ𝑦𝑦𝑎𝑎 𝑛𝑛𝑦𝑦𝑦𝑦𝑎𝑎 𝑎𝑎𝑝𝑝𝑝𝑝𝑦𝑦𝑎𝑎𝑖𝑖𝑛𝑛𝑦𝑦𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛 𝑝𝑝𝑦𝑦𝑖𝑖𝑛𝑛𝑎𝑎𝑖𝑖𝑝𝑝𝑙𝑙𝑦𝑦 1

𝑀𝑀𝑖𝑖𝑦𝑦𝑝𝑝𝑙𝑙𝑦𝑦𝑦𝑦 𝑎𝑎𝑝𝑝1

END

Figure 13 Method for calculating the number of pairs of activities under coordination principle 1

36


The following are the equations generated for the example shown in Figure 12.

𝑦𝑦𝑝𝑝′ ,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,1_1 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 ..(13A)

𝑦𝑦𝑝𝑝′ ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − 𝑥𝑥𝑝𝑝 ,𝑝𝑝′,𝑟𝑟 ,1_1 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 ..(13B)

𝑦𝑦𝑝𝑝′ ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − 𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,1_2 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 ..(13C)

𝑦𝑦𝑝𝑝′ ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 𝑥𝑥𝑝𝑝,𝑝𝑝′ ,𝑟𝑟 ,1_2 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝑘𝑘𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 ..(13D)

𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,1_1 + 𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,1_2 = (2 − 1) + 𝑦𝑦𝑟𝑟 ,1 ..(13E)

The equations (13A) to (13E) are defined 𝑓𝑓𝑝𝑝𝑦𝑦 𝑝𝑝 = 𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑛𝑛𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛,𝑝𝑝′ =

𝐹𝐹𝑝𝑝𝑦𝑦𝑛𝑛𝑦𝑦 𝐵𝐵𝑦𝑦𝑝𝑝 𝐵𝐵𝑦𝑦𝑛𝑛𝑦𝑦 79, 𝑦𝑦 = 52034.

According to Table 3 in CHAPTER 2: Problem Description, for ‘Simultaneous’ principles, either Equation set

(13A) and (13B) or Equation set (13C) and (13D) need to be satisfied. The equations (13A) to (13D) are modeled

by “Big M method” with binary variables 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏_𝟏𝟏 𝒂𝒂𝑴𝑴𝒂𝒂 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏_𝟐𝟐 . This setup suggests that if Equation set (13A)

and (13B) is chosen then 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_1 is set to 0 and if they are not chosen then the variable (𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_1 = 1)

activates the “Big M” which implies that the LHS could be any value within a large range. This applies to Equation

set (13C) and (13D), and variable 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_2 as well. The “Big M” is set as (16*365), which implies the number of

days in the period (2015 to 2030).

However, if none of the Equation sets [Equations (13A), (13B) and Equations (13C), (13D)] can be satisfied, then

it is a coordination principle violation and both the variables 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_1 𝑦𝑦𝑛𝑛𝑎𝑎 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_2 are set to 1. Equation (13E)

implies that if the coordination principle is violated then the binary variable 𝒂𝒂𝒓𝒓,𝟏𝟏 is set to 1, which means that

coordination principle 1 is violated on route section 𝑦𝑦 and in this case, 𝑦𝑦 is 52034 (Roskilde-Lejre). It can be

recalled that the objective of the model is to minimize the total violations, ∑ ∑ 𝒂𝒂𝒓𝒓,𝒂𝒂𝒂𝒂∈𝑪𝑪𝒓𝒓∈𝑹𝑹 .

In total, 5 equations (13A to 13E) are generated for a pair of activities that is categorized under coordination

principle 1. As mentioned earlier, there were 36 pairs found under coordination principle 1 and equations are

generated for all the pairs in the similar manner.

Coordination Principles 4, 5, 6, 7, 8, 10, 12, 14, 17, 19, 22 and 25 need ’Simultaneous’ constraints and therefore

follow the similar setup as coordination principle 1.

37


• Coordination Principle 2: ‘Simultaneous Start’ principle

Figure 14 above shows a pair of activities that falls under coordination principle 2 which needs ‘Simultaneous

start’ constraints. The following equations are generated for the pair and are defined 𝑓𝑓𝑝𝑝𝑦𝑦 𝑝𝑝 =

𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛,𝑝𝑝′ =

𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑛𝑛𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛, 𝑦𝑦 = 52034.

𝑦𝑦𝑝𝑝′,𝑟𝑟 ,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 𝑦𝑦𝑟𝑟,2 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 ..(14A)

𝑦𝑦𝑝𝑝′,𝑟𝑟 ,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − 𝑦𝑦𝑟𝑟,2 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 ..(14B)

If the coordination principle 2 for route section 52034 is violated then 𝒂𝒂𝟓𝟓𝟐𝟐𝟓𝟓𝟓𝟓𝟓𝟓 ,𝟐𝟐 is set as 1 as shown in Equations

(14A) and (14B). Coordination Principles 3 and 18 follow the principles of ‘Simultaneous Start’ and have the

similar setup as coordination principle 2.

Activity x




f: Definition

Activity y

p’: Roskilde_Kalundborg_elektrificering_Togfonden


a: Spor og Anlægsarbejder

f: Definition

Figure 14 Example of pair of activities under Coordination Principle

38


• Coordination Principle 9: ‘Simultaneous end’ principle

The above pair of activities (Figure 15) is one example that is categorized under coordination principle 9 that

needs ‘Simultaneous End’ constraints.

𝑦𝑦𝑝𝑝′,𝑟𝑟 ,𝑘𝑘𝑃𝑃𝑟𝑟𝑦𝑦𝑠𝑠𝐷𝐷𝑟𝑟𝑃𝑃𝑠𝑠 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 + 𝑦𝑦𝑟𝑟 ,9 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 ..(15A)

𝑦𝑦𝑝𝑝′ ,𝑟𝑟 ,𝑘𝑘𝑃𝑃𝑟𝑟𝑦𝑦𝑠𝑠𝐷𝐷𝑟𝑟𝑃𝑃𝑠𝑠 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 − 𝑦𝑦𝑟𝑟 ,9 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝 ,𝑟𝑟 ,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑟𝑟𝑎𝑎𝑠𝑠 ..(15B)

The equations (15A) and (15B) are defined 𝑓𝑓𝑝𝑝𝑦𝑦 𝑝𝑝 = 𝐹𝐹𝑝𝑝𝑦𝑦𝑛𝑛𝑦𝑦 𝐵𝐵𝑦𝑦𝑝𝑝 𝐵𝐵𝑦𝑦𝑛𝑛𝑦𝑦 79,𝑝𝑝′ =

𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑛𝑛𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛, 𝑦𝑦 = 52034.

If the coordination principle 9 for route section 52034 is violated then 𝒂𝒂𝟓𝟓𝟐𝟐𝟓𝟓𝟓𝟓𝟓𝟓 ,𝟗𝟗 is set as 1 as shown in Equations

(15A) and (15B). Coordination Principle 11 is setup similarly to the model above.

Activity x

p: Forny Bro Bane 79



f: Program

Activity y

p’: Roskilde_Kalundborg_elektrificering_Togfonden


a: Kørestrøm

f: Program


39


• Coordination Principle 13: ‘Before/Simultaneous’ principle

‘Before/simultaneous’ constraints need to be modeled for the above pair of activities (Figure 16) which is under

coordination principle 13. If coordination principle 13 is satisfied, it should choose either Equation set (16A) and

(16B), or Equation set (16C) and (16D), or Equation (16E) as described in Table 3. Similar to the ‘Simultaneous’

constrains, binary variables 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏𝟓𝟓_𝟏𝟏, 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏𝟓𝟓_𝟐𝟐 𝒂𝒂𝑴𝑴𝒂𝒂 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏𝟓𝟓_𝟓𝟓 are created.

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 𝑥𝑥𝑝𝑝 ,𝑝𝑝′,𝑟𝑟,13_1 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ..(16A)

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 − 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟 ,13_1 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ..(16B)

𝑦𝑦𝑝𝑝′,𝑟𝑟 ,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 − 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,13_2 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ..(16C)

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,13_2 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟 ,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ..(16D)

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,13_3 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 ..(16E)

The equations (16A) to (16F) are defined 𝑓𝑓𝑝𝑝𝑦𝑦 𝑝𝑝 = 𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑛𝑛𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛, 𝑝𝑝′ =

𝐹𝐹𝑝𝑝𝑦𝑦𝑛𝑛𝑦𝑦 𝑅𝑅𝑝𝑝𝑝𝑝𝑦𝑦 𝐵𝐵𝑦𝑦𝑛𝑛𝑦𝑦 79, 𝑦𝑦 = 52034. The following equation (16F) indicates that if none of the Equations sets

defined above are chosen (𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏𝟓𝟓_𝟏𝟏, 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏𝟓𝟓_𝟐𝟐 𝒂𝒂𝑴𝑴𝒂𝒂 𝒙𝒙𝒑𝒑,𝒑𝒑′,𝒓𝒓,𝟏𝟏𝟓𝟓𝟓𝟓 = 𝟏𝟏) , then it is termed as a coordination

principle violation and the binary variable 𝒂𝒂𝒓𝒓,𝟏𝟏𝟓𝟓 is set as 1, which implies that coordination principle 13 is violated

on route section 𝑦𝑦 (52034). Coordination Principles 15, 19 and 24 are modeled similarly.

𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,13_1 + 𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,13_2 + 𝑥𝑥𝑝𝑝 ,𝑝𝑝′ ,𝑟𝑟 ,13_3 = (3 − 1) + 𝑦𝑦𝑟𝑟 ,13 ..(16F)

Activity x




f: Projektering

Activity y

p’: Forny Spor Bane 79


a: Spor og Anlægsarbejder

f: Projektering


40


• Coordination Principle 16: ‘Before’ principle

‘Before’ constraints need to be modeled for pair of activities under coordination principle 16 and above is an

example of such activities (Figure 17). Coordination principles 22 and 24 also require ‘Before’ constraints and are

modeled similarly.

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑖𝑖𝑘𝑘𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 𝑃𝑃𝑃𝑃 𝐹𝐹𝑃𝑃𝑦𝑦𝑟𝑟𝐷𝐷𝑠𝑠𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 𝑦𝑦𝑟𝑟,16 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈𝑎𝑎𝑦𝑦𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝑃𝑃𝑟𝑟𝑃𝑃𝑃𝑃𝑦𝑦𝑘𝑘𝐷𝐷𝑦𝑦𝑟𝑟𝑖𝑖𝐷𝐷𝑃𝑃 + 1 ..(17)

Equation (17) is defined 𝑓𝑓𝑝𝑝𝑦𝑦 𝑝𝑝 = 𝑅𝑅𝑝𝑝𝑦𝑦𝑃𝑃𝑖𝑖𝑙𝑙𝑎𝑎𝑦𝑦 𝐾𝐾𝑦𝑦𝑙𝑙𝑟𝑟𝑛𝑛𝑎𝑎𝑏𝑏𝑝𝑝𝑦𝑦𝑙𝑙 𝐸𝐸𝑙𝑙𝑦𝑦𝑃𝑃𝑎𝑎𝑦𝑦𝑖𝑖𝑓𝑓𝑖𝑖𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑛𝑛𝑙𝑙 𝑇𝑇𝑝𝑝𝑙𝑙𝑓𝑓𝑝𝑝𝑛𝑛𝑎𝑎𝑦𝑦𝑛𝑛,𝑝𝑝′ = 𝐸𝐸 𝑅𝑅𝑝𝑝𝑙𝑙 8, 𝑦𝑦 =

52034.

Activity x



a: Spor og Anlaegsarbejder

f: Projektering

Activity y

p’ : E Rol 8


a: Sikring og Fjernstyring

f: Projektering


41


Table 8 shows the number of activity pairs that fall under each coordination principle that were obtained from

the method implemented in C++. Relevant equations are produced for every pair of activities under every

coordination principle. A total of 6898 equations were generated.

From Table 8, it could be seen that number of pairs of activities found under coordination principles 5, 6, 12, 17

and 25 were zero and hence equations were not generated for these coordination principles. Therefore, the

method implemented in C++ is advantageous since it generates only the required equations. However, the

problem is considered to be large due to the generation of 6898 equations.

Coordination Principle Number of activity pairs

1 36

2 144

3 48

4 73

5 0

6 0

7 36

8 144

9 48

10 73

11 65

12 0

13 144

14 73

15 65

16 175

17 0

18 56

19 36

20 144

21 48

22 73

23 65

24 175

25 0

Table 8 Number of pairs of activities under each coordination principle for the 9 projects

42


Constraints to calculate the starting year of the activities and the total cost for every year

∑ 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑝𝑝𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦�𝑙𝑙𝑖𝑖𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟, 1,1�𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟∈𝑌𝑌𝑌𝑌𝐴𝐴𝑌𝑌 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(18)

∑ 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑝𝑝𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦�𝑙𝑙𝑖𝑖𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟, 12,31�𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟∈𝑌𝑌𝑌𝑌𝐴𝐴𝑌𝑌 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅, 𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(19)

∑ 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟∈𝑌𝑌𝑌𝑌𝐴𝐴𝑌𝑌 = 𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(20)

𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 = ∑ ∑ ∑ ∑ (𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓∈𝐹𝐹𝑎𝑎∈𝐴𝐴𝑟𝑟∈𝑌𝑌𝑝𝑝∈𝑃𝑃 ) ∀𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ∈ 𝑌𝑌𝐸𝐸𝑀𝑀𝑅𝑅 ..(21)

Equations (18) and (19) calculates the starting year of the activity based on the starting serial day number variable

denoted by 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓. Binary variable 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 is set as 1 if the activity starts in the 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦. Equation (20)

ensures that an activity is started only once. Variable 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 in Equation (21) calculates the total cost for

the 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦.

Cost limit Constraints

∑ ∑ ∑ ∑ (𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓∈𝐹𝐹𝑎𝑎∈𝐴𝐴𝑟𝑟∈𝑌𝑌𝑝𝑝∈𝑃𝑃 ) ≤ 𝑀𝑀𝑦𝑦𝑥𝑥𝐶𝐶𝑝𝑝𝑦𝑦𝑎𝑎 ∀𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ∈ 𝑌𝑌𝐸𝐸𝑀𝑀𝑅𝑅 ..(22)

∑ ∑ ∑ ∑ (𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓∈𝐹𝐹𝑎𝑎∈𝐴𝐴𝑟𝑟∈𝑌𝑌𝑝𝑝∈𝑃𝑃 ) ≥ 𝑀𝑀𝑖𝑖𝑛𝑛𝐶𝐶𝑝𝑝𝑦𝑦𝑎𝑎 ∀𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ∈ 𝑌𝑌𝐸𝐸𝑀𝑀𝑅𝑅 ..(23)

Equations (22) and (23) set upper and lower cost limits for all years. The values of MaxCost and MinCost vary

with every test.

Input and Output

An Excel sheet contains the details about parameters 𝑝𝑝𝑦𝑦𝑝𝑝𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 , 𝑙𝑙𝑦𝑦𝑛𝑛𝑙𝑙𝑎𝑎ℎ𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 𝑦𝑦𝑛𝑛𝑎𝑎 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓. The excel sheet

serves as an input to the GAMS model. After optimization in GAMS, the variables

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 , 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 , 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 𝑦𝑦𝑛𝑛𝑎𝑎 𝑦𝑦𝑟𝑟,𝑐𝑐 are displayed in another excel sheet.

43


Results

The following table, Table 9, shows the different tests that were run for varying MaxCost and MinCost. Test 1

shows the results when no cost limits were applied. The optimal number of coordination principles violated was

found to be 17 with a computation time of 8 seconds. Figure 18 in the following page shows the attained cost

profile and the MAD was calculated to be 183.40. It was found that the MaxCost could not be lowered below

737.77 million DKK because that was the expense of executing ‘Udførsel’ phase of asset ‘Kørestrøm’ on all

route sections of ‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project. These activities are guided by the

Factor 2 constraints and therefore could not be violated. Hence, 740 million DKK was fixed as the MaxCost for

the following tests with varying MinCost. The computation time limit for all the tests was set as 2500 seconds.

Tests 2 and 3 gave optimal solutions within the time limit and it could be noticed that the computation time to

solve the problem tends to increase when the cost limit constraints are applied or strengthened. All the other

tests were able to attain a feasible solution but a feasible solution could not be found for Test 9 within the limited

time.

Test no.

MaxCost (Million DKK)

MinCost (Million DKK)

Coordination Principles Violated

(Objective function)

Mean Abolute Deviation (MAD)

Computation Time

(< 2500s)

Optimal

1 NA NA 17 183.40 8 Yes

2 740 0 22 154.34 88 Yes

3 740 1 34 145.71 1842 Yes

4 740 2 44 145.63 2500 No

5 740 3 78 124.00 2500 No

6 740 6 88 116.89 2500 No

7 740 8 126 119.72 2500 No

8 740 10 178 109.09 2500 No

9 740 12 No solution found 2500 Table 9 Test results of Model 1 for the 9 projects

44


Figure 18 below shows the cost profile attained from Test 1. The blue line represents the total cost for every year

in the period 2015 – 2030 and the horizontal orange line represents the average cost for all years.

Figure 19 is the cost profile of Test 8 where the MinCost was set as 10 million DKK. The 738.84 million DKK peak

in the year 2026 could be observed which includes the total expense of activities of ‘Udførsel’ phase, ‘Kørestrøm’

asset on all route sections of ‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project.

10,00 14,07 19,05

168,37

71,8219,04

61,4911,38

108,9248,43

268,62

738,84

10,95 32,57

138,90

45,62

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[Mill

ion

DKK]

Year

Cost Average

22,44 12,6344,78

0,00

872,26

0,00

815,96

0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,000,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

900,00

1000,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[Mill

ion

DKK]

Year

Cost Average

Figure 18 Cost profile when no cost limits were applied

Figure 19 Cost profile when MinCost was set as 10 million DKK

45


Figure 20 below depicts the effect of tightening lower cost limit (MinCost) with 740 million DKK as the fixed

MaxCost. The number of coordination principles violated tends to increase with tighter cost limit constraints.

The violations increased from 22 to 178. As mentioned earlier, Model 1 does not optimize MAD and MAD is

calculated manually when the model displays 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 to the excel sheet. It was believed that MAD would

decrease by strengthening the cost limit constraints. From Figure 20, it could be observed that overall the MAD

decreased from 154.34 to 109.09. However, the results of MinCost 6 and 8 million DKK (Tests 6 and 7 from Table

9) show that despite strengthening the lower cost limit constraint from 6 to 8 million DKK the MAD did not

decrease. The number of coordination principles increased from 88 to 126 and the MAD increased from 116.89

to 119.72. Therefore, for this instance the decision maker is presented with a result of increased coordination

principle violations and MAD, which is undesirable. Thus, not able to decrease MAD for certain instances of

strengthened cost limits is recognized as one of the weaknesses of the model.

2234

44

7888

126

178

154,34

145,71145,63

124,00

116,89

119,72 109,09

0

20

40

60

80

100

120

140

160

180

200

0 2 4 6 8 10 12

MinCost [Milliion DKK]

Coordination Principles Violated MAD

Figure 20 Effect of tightening lower cost limit, MinCost

46


Lower Bounds

For some of the tests it was not possible to attain optimal solutions in limited time. Therefore the question to be

answered is how far is the feasible solution from the integer program (IP) optimal solution?

The feasible solutions are considered as primal bounds or upper bounds to the optimal solution (𝑧𝑧 ≥ 𝑧𝑧). Dual

bounds or lower bounds to the optimal solution (𝑧𝑧 ≤ 𝑧𝑧) are commonly obtained by “relaxation” (Wolsey, 1998).

The objective is to find lower and upper bounds such that 𝑧𝑧 = 𝑧𝑧 = 𝑧𝑧. Due to the difficulty of solving integer

programming (IP) problems, algorithms are defined to derive bounds and stops when 𝑧𝑧 − 𝑧𝑧 ≤ 𝜀𝜀, where 𝜀𝜀 is a

small nonnegative value known as optimality gap.

Optimality gap (MosekApS, 2015) is measure of how close the feasible solution is to the optimal solution and is

used to determine the quality of the solution. It guarantees that the feasible solution is within 𝜀𝜀 of the optimal

solution. Absolute optimality gap is given by the formula,

𝜀𝜀 = |(𝑝𝑝𝑏𝑏𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑎𝑎𝑦𝑦𝑙𝑙𝑟𝑟𝑦𝑦 𝑝𝑝𝑓𝑓 𝑎𝑎ℎ𝑦𝑦 𝑓𝑓𝑦𝑦𝑦𝑦𝑦𝑦𝑖𝑖𝑏𝑏𝑙𝑙𝑦𝑦 𝑦𝑦𝑝𝑝𝑙𝑙𝑟𝑟𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛) − (𝑝𝑝𝑏𝑏𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑝𝑝𝑓𝑓 𝑏𝑏𝑝𝑝𝑟𝑟𝑛𝑛𝑎𝑎)|

Relative optimality gap is given by the formula,

𝜀𝜀 = |(𝑝𝑝𝑏𝑏𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑎𝑎𝑦𝑦𝑙𝑙𝑟𝑟𝑦𝑦 𝑝𝑝𝑓𝑓 𝑓𝑓𝑦𝑦𝑦𝑦𝑦𝑦𝑖𝑖𝑏𝑏𝑙𝑙𝑦𝑦 𝑦𝑦𝑝𝑝𝑙𝑙𝑟𝑟𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛) − (𝑝𝑝𝑏𝑏𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑝𝑝𝑓𝑓 𝑏𝑏𝑝𝑝𝑟𝑟𝑛𝑛𝑎𝑎)|

𝑝𝑝𝑏𝑏𝑝𝑝𝑦𝑦𝑎𝑎𝑎𝑎𝑖𝑖𝑎𝑎𝑦𝑦 𝑎𝑎𝑦𝑦𝑙𝑙𝑟𝑟𝑦𝑦 𝑝𝑝𝑓𝑓 𝑓𝑓𝑦𝑦𝑦𝑦𝑦𝑦𝑖𝑖𝑏𝑏𝑙𝑙𝑦𝑦 𝑦𝑦𝑝𝑝𝑙𝑙𝑟𝑟𝑎𝑎𝑖𝑖𝑝𝑝𝑛𝑛

𝑧𝑧

𝑧𝑧1

𝑧𝑧2

𝑧𝑧2

𝑧𝑧1

Figure 21 Bounds for IP

47


Tests 4 to 8 from Table 9 showed feasible solutions and if methods could be applied to derive lower bounds then

the quality of the feasible solutions could be analyzed. The following are the different methods used to obtain

lower bounds:

• LB1 – Without Factor 1 and 2 constraints Factor 1 and 2 constraints are removed to determine lower bounds.

• LB2 – Without Factor 1 constraints The model is solved without Factor 1 constraints to obtain lower bounds.

• LB3 – Without Factor 2 constraints The model is solved without Factor 2 constraints to obtain lower bounds.

• LB4 – Linear Programming Relaxation Only the binary variable 𝑦𝑦𝑟𝑟,𝑐𝑐 is relaxed (0 ≤ 𝑦𝑦𝑟𝑟,𝑐𝑐 ≤ 1).

• LB5 – Best Optimal solution The best optimal solution attained from the previous tests is set as a lower bound. In this case, Test 3

gave the best optimal solution of 34. The optimal solution of the following tests should be equal to or

above 34 due to the tighter cost limit constraints.

The following table shows the obtained lower bounds for the tests. LB1 and LB2 were found to be 0 for all tests

and therefore are irrelevant to analyze the optimality gap. LB3 produced bounds greater than 0 but were not

proven optimal within the limited time. Moreover, the results of LB3 are not found to be significant to analyze

the optimality gap. LP Relaxation (LB4) produced an optimal bound for Test 4 but is found to be a very “weak”

bound with the relative optimality gap of 0.745 (74.5%). LB5 was set as 34 and therefore it is known that the IP

optimal solution of Test 4 is between 34 and 44 (34 ≤ 𝑧𝑧4 ≤ 44) with the relative optimality gap of 22.72%.

Table 10 Lower Bounds

Test no.



Without Factor 1 and 2

constraints (LB1)

Without Factor 1

constraints (LB2)

Without Factor 2 constraints

(LB3)

LP Relaxation (LB4)

Best Optimal solution

(LB5)

1 17*

2 22*

3 34*

4 44 0* 0* 19 11.24* 34

5 78 0* 0* 20 42.94 34

6 88 0* 0* 28 37.34 34

7 126 0* 0* 23 64.74 34

8 178 0* 0* 30 126.91 34

* Proven optimal within the time limit of 2500 seconds.

48


For Test 4, LB5 is the strongest lower bound. However LB5 becomes weaker for the succeeding tests with

increasing strength of cost limit constraints. For tighter cost limit constraints, it appears that the LP relaxation

(LB4) produces stronger lower bounds but it cannot be concluded because the relaxations were not proven

optimal.

However, from the lower bound results it can certainly be concluded that optimality gap is extremely large. Due

to the significant optimality gap, it is doubtful whether the attained feasible solution is far away from the IP

optimal solution or the produced lower bound by LP relaxation is very “weak”. The LP relaxation problem could

be solved for a proven optimal IP problem to determine the quality of the relaxation. LP relaxation of Test 1 was

solved and was found to be 7.08, which is 58.35% away from the IP optimal solution. Thus, it could be said that

the LP relaxation of this model is generally “very weak”. With such “weak” lower bounds it will be difficult to

determine the quality of the feasible solutions using these bounds.

In the following Chapter, CHAPTER 6: Analysis of smaller subsets of data, analysis will be carried out on

smaller problems to conclude if the LP relaxation of the problem is generally “very weak”. If the relaxation is

proven to be weak then the reasons behind it will be discussed.

Another important observation made from the lower bound tests (Table 10) was that when the “hard”

constraints (Factor 1 and Factor 2 constraints) were removed for LB1 and Factor 1 constraints were removed for

LB2, the coordination principles were not violated for all tests in spite of the strengthened cost limit constraints.

This shows evidence that Factor 1 and 2 constraints restrict the flexibility of the activities from being moved

between years and hence cause coordination principle violations.

49


5.2 MODEL 2

As an alternative to Model 1, Model 2 is set as a multi-objective problem with the objectives to minimize both

the coordination principle violations and MAD. The formulation of the model is similar to Model 1 with the

inclusion of absolute deviation constraints and changes in the objective function. The cost limit constraints are

removed.

Mean Absolute Deviation optimization

Large-scale portfolio optimization has been the field of interest for investors in the stock market for several years.

Standard mean variance and mean absolute deviation (MAD) are some of the risk measures used to optimize the

investor’s portfolio choices (Konno & Koshizuka, 2005). The Mean Absolute deviation (MAD) portfolio

optimization model was proposed in 1991 by (Konno & Yamazaki, 1991) and was applied to Tokyo stock market.

Linear programing formulation of the MAD model could be utilized in formulating the deviation of cost every

year from the average for Banedanmark’s case. The following formulation to calculate the deviation was

mentioned by (Konno & Yamazaki, 1991) and (Fung Lam, et al., 1996).

�𝑦𝑦𝑖𝑖𝑃𝑃𝑥𝑥𝑃𝑃𝑘𝑘

𝑃𝑃=1

+ 𝑎𝑎𝑖𝑖 ≥ 𝑎𝑎 ∀𝑖𝑖 ∈ 𝐼𝐼

�𝑦𝑦𝑖𝑖𝑃𝑃𝑥𝑥𝑃𝑃𝑘𝑘

𝑃𝑃=1

− 𝑎𝑎𝑖𝑖 ≤ 𝑎𝑎 ∀𝑖𝑖 ∈ 𝐼𝐼

Objective Function

𝑴𝑴𝒂𝒂𝑴𝑴𝒂𝒂𝑴𝑴𝒂𝒂𝑴𝑴𝑴𝑴 𝑴𝑴 = 𝝅𝝅𝟏𝟏 �𝒂𝒂𝑴𝑴𝒂𝒂𝒂𝒂𝑴𝑴𝒂𝒂𝒓𝒓

𝑴𝑴𝒏𝒏𝑴𝑴𝒏𝒏𝑴𝑴𝒓𝒓 𝒐𝒐𝒇𝒇 𝒂𝒂𝑴𝑴𝒂𝒂𝒓𝒓𝒂𝒂𝑴𝑴𝒂𝒂𝒓𝒓∈𝒀𝒀𝒀𝒀𝒀𝒀𝑹𝑹

+ 𝝅𝝅𝟐𝟐��𝒂𝒂𝒓𝒓,𝒂𝒂𝒂𝒂∈𝑪𝑪𝒓𝒓∈𝑹𝑹

Positive variable 𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 is introduced for Model 2, which calculates the absolute cost deviation of 𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 from

the average cost. The objective function tries to minimize both the mean absolute deviation (MAD) and the total

number of coordination principles violated, and is guided by two weight coefficients (𝜋𝜋1𝑦𝑦𝑛𝑛𝑎𝑎 𝜋𝜋2) which decides

the priority of each objective. The coefficients are 𝜋𝜋1,𝜋𝜋2 ≥ 0 𝑦𝑦𝑛𝑛𝑎𝑎 (𝜋𝜋1 + 𝜋𝜋2 = 1).

where c is the average or desired level from which the deviation is calculated and 𝑎𝑎𝑖𝑖 is the variable to calculate the deviation at i.

50


Constraints

Constraints to calculate absolute deviation

The absolute deviation is calculated by positive variables, 𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟, and is formulated as follows. Both the

equations are defined ∀𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦 ∈ 𝑌𝑌𝐸𝐸𝑀𝑀𝑅𝑅 and the RHS is the average cost for all years.

∑ ∑ ∑ ∑ (𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓∈𝐹𝐹𝑎𝑎∈𝐴𝐴𝑟𝑟∈𝑌𝑌𝑝𝑝∈𝑃𝑃 ) + 𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ≥ ∑ ∑ ∑ ∑ 𝑐𝑐𝑃𝑃𝑠𝑠𝐷𝐷𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓𝑎𝑎𝑟𝑟𝑝𝑝𝐷𝐷𝑘𝑘𝑠𝑠𝐴𝐴𝑦𝑦𝑟𝑟 𝑃𝑃𝑓𝑓 𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟𝑠𝑠 ..(24)

∑ ∑ ∑ ∑ (𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓,𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ∗ 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓∈𝐹𝐹𝑎𝑎∈𝐴𝐴𝑟𝑟∈𝑌𝑌𝑝𝑝∈𝑃𝑃 ) − 𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟 ≤ ∑ ∑ ∑ ∑ 𝑐𝑐𝑃𝑃𝑠𝑠𝐷𝐷𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓𝑓𝑓𝑎𝑎𝑟𝑟𝑝𝑝𝐷𝐷𝑘𝑘𝑠𝑠𝐴𝐴𝑦𝑦𝑟𝑟 𝑃𝑃𝑓𝑓 𝑦𝑦𝑦𝑦𝑎𝑎𝑟𝑟𝑠𝑠 ..(25)

The Earliest starting date and deadline constraints, Factor 1, Factor 2 and Factor 3 constraints are set-up in Model

2 which are similar to Model 1. The cost limit constraints, Equations (22) and (23), from Model 1 are removed.

Results

Model 2 was solved with 𝜋𝜋1 𝑦𝑦𝑛𝑛𝑎𝑎 𝜋𝜋2 = 0.5. Optimal solution could not be found in 2500 seconds but a feasible

solution of 122 coordination principle violations with a MAD of 101.52 was found. The figure below, Figure 22,

shows the attained cost profile.

Figure 22 Cost profile attained from Model 2

4,72 15,15 4,95

134,3884,12

0,11 15,92 30,16

108,92116,22

239,81

97,9041,41

737,77

136,53

0,000,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[Mill

ion

DKK]

Year

Average

51


The biggest advantage of Model 2 over Model 1 is that it simultaneously minimizes the MAD and the coordination

principle violations. The test results of Model 2 is shown in Table 11 and Model 2 attained a MAD of 101.52 in

the limited time with just 122 violations, whereas Model 1 (as shown in Table 12) had MAD of 109.09 with 178

coordination principle violations. Therefore, Model 2 was able to attain lower MAD with fewer coordination

principle violations than Model 1. Despite the optimization of MAD by the model, it is not bounded by cost limits.

For instance, year 2030 in the cost profile shown in Figure 22 has zero cost. Therefore, this model does not

guarantee of satisfying certain upper and lower cost limits and this might be one of the weaknesses of the model.

Test no.

MaxCost (Million DKK)

MinCost (Million DKK)



Mean Abolute Deviation (MAD)

Computation Time

(< 2500s)

Optimal

1 NA NA 17 183.40 8 Yes

2 740 0 22 154.34 88 Yes

3 740 1 34 145.71 1842 Yes

4 740 2 44 145.63 2500 No

5 740 3 78 124.00 2500 No

6 740 6 88 116.89 2500 No

7 740 8 126 119.72 2500 No

8 740 10 178 109.09 2500 No

9 740 12 No solution found 2500 Table 12 Test results of Model 1 for the 9 projects

LP relaxation of Model 2 was found to be 70.33 as shown in Table 11 but the relaxation was not proven optimal

within the limited time. It would be interesting to test the model with different weight coefficients of

MAD (𝑦𝑦𝑥𝑥𝑦𝑦𝑚𝑚𝑝𝑝𝑙𝑙𝑦𝑦: 𝜋𝜋1 = 0.25, 0.75). With increasing weight coefficient of MAD, the MAD is expected to decrease

and the coordination principle violations to increase. However, due to the model not able to produce optimal

solutions within the limited time the behavior of different weight coefficients cannot be observed. It would be

possible to observe the behavior for a smaller problem that would give optimal solutions in quicker time.

Test No.

Weight of coordination

Principles

(𝝅𝝅𝟐𝟐)

Weight of MAD

(𝝅𝝅𝟏𝟏)

Objective function

No. Of Coordination

Principles Violated

MAD Computation Time

(< 2500 s)

Optimal LP Relaxation

1 1 0 17 17 183.4 8 Yes

2 0.5 0.5 111.76 122 101.5 2500 No 70.33

Table 11 Test results of Model 2 for the 9 projects

52


5.3 DISCUSSION

From Model 1, it was observed that the number of coordination principles tends to increase as the cost limit

constraints were tightened. By setting the cost limits, there is a high probability of decreasing MAD and Model 1

provided evidence of decreasing MAD. However, there was one instance where in spite of strengthened cost

limit constraints the MAD did not decrease. Another problem of implementing Model 1 is deciding on the upper

and lower cost limits. However, if the decision makers have certain policies on cost limits for the year, then

Model 1 is quite advantageous. Yet, if the limits are tight then the model could run into high optimality gap

issues.

One of the main drawbacks of Model 2 is to decide on the appropriate weights of the objectives and since the

model does not provide optimal solutions in limited time, it is difficult to observe the effect of different weight

coefficients on the number of coordination principle violations and MAD. The decision makers would definitely

find the model helpful if it could provide the results for different weight coefficients (𝜋𝜋1 =

0, 0.25, 0.5 𝑦𝑦𝑛𝑛𝑎𝑎 0.75). Another disadvantage of this model is that it is not bounded by cost limits and thus it

does not guarantee of satisfying certain lower or upper cost limits, which could be a concern for the decision

makers. However, the advantage of Model 2 is that it optimizes the number of coordination principle violations

and MAD simultaneously.

Another important observation form the results of both the models was that the cost profile had certain

significant peaks that are inevitable due to the Factor 2 constraints. Therefore, it might not be possible to reduce

the cost for all years below a certain limit (as shown by the 737.77 million DKK peak for the set of 9 projects).

Both the models seem to have a common problem, which is running into high optimality gaps. From the test

results, it could be noticed that the computation time is relatively low (8 seconds) when minimizing the number

of coordination principle violations was solved without any cost limit constraints. The difficulty of the problem

tends to increase when cost limit constraints are strengthened or the objective to minimize MAD is applied,

which causes high optimality gap issues. Moreover, it was difficult to analyze if the produced lower bounds by

LP relaxation were “weak” or the attained feasible solutions were far away from the IP optimal solutions. There

was just one instance where it showed that the LP relaxation was “very weak”. If smaller sets of data (smaller

problems) were solved, then it would be possible to attain IP optimal solutions in quick time and the quality of

the lower bounds can be analyzed further. This analysis with smaller sets of data would provide stronger

evidence that the generated lower bounds are “very weak”. Moreover, Model 2 could be tested with different

weight coefficients so that their effect on the number of coordination principle violations and MAD could be

studied.

53


Therefore, in the following Chapter, the models are tested for smaller subsets of data with 2-4 projects and the

objectives are as following:

1. To determine the quality of the lower bounds produced by LP Relaxation (LB4) and without Factor 2

constraints (LB3).

2. If LP relaxation is proven to be “weak”, then analyze the reasons for it.

3. To execute Model 2 with different weight coefficients (𝜋𝜋1 = 0, 0.25, 0.5 𝑦𝑦𝑛𝑛𝑎𝑎 0.75) and observe their

respective effect on the number of coordination principle violations and MAD.

54

CHAPTER 6: Analysis Of Smaller Subsets Of Data

CHAPTER 6: ANALYSIS OF SMALLER SUBSETS OF DATA

Figure 23 below shows the 3 arbitrarily chosen subsets with their respective projects and the number of activities

involved for which further analysis of lower bounds and Model 2 are carried out. For such smaller problems, it is

believed that IP optimal solutions would be found for all the tests, which could be used to analyze the generated

lower bounds. LP relaxation (LB4) and without Factor 2 constraints (LB3) are tested for the subsets. Model 2 is

tested for the subsets with different weight coefficients(𝜋𝜋1 = 0, 0.25, 0.5 𝑦𝑦𝑛𝑛𝑎𝑎 0.75). At the end of this Chapter,

discussions will be carried out about the obtained results of the different subsets.

SUBSETS

SUBSET 1

Projects:

1. Forny_Spor_Bane_79 2. Forny_Bro_Bane_79 3. E_ROL_8 4. Hastighedsopgradering_H

olbaek_Kalundborg

Total of 268 Activities

Projects:

1. Hastighedsopgradering_Holbaek_Kalundborg

2. Forny_Spor_bane_51 3. Forny_Bro_bane_51


SUBSET 2

Projects:

1. Roskilde_Kalundborg_Elektrificering_Togfonden

2. Forny_Spor_Bane_79


SUBSET 3

Figure 23 Subsets

55


6.1 MODEL 1

Subset 1

The following table, Table 13, shows the test results of Model 1 for subset 1 and all solutions were proven

optimal. The MaxCost could not be decreased below 240 million DKK due to the Factor 2 constraints and

therefore the following tests were carried out with increasing MinCost. It was also found that MinCost could not

be increased above a certain point and in this case it was 0.5 million DKK. Any value above this point was found

to be infeasible as shown in Test 7. The infeasibility is believed to be caused by Factor 1 and 2 constraints which

restrict the cost from being distributed above 0.5 million DKK for all the years. Therefore for a given set of data,

the cost profile has definite upper and lower limits beyond which solutions cannot be determined.

Nevertheless, within the cost boundaries for Subset 1 the number of coordination principles violated was found

to be 9 as shown in Test no. 6 and the MAD was calculated to be 35.04.

Test No.

MaxCost (million Dkk)

MinCost (million Dkk)

Coordination Principles violated

(Objective Function)

MAD Computation Time (seconds)

Optimal

1 NA NA 0 42.154 1 Yes

2 300 0 0 40.163 1 Yes

3 240 0 0 39.87 1 Yes

4 240 0.1 0 35.04 8 Yes

5 240 0.25 0 35.03 167 Yes

6 240 0.5 9 35.04 382 Yes

7 240 1 Infeasible Table 13 Test results of Model 1 for subset 1

Only Test 6 from Table 13 was considered for the lower bounds. Lower bounds by LP relaxation (LB4) and without

Factor 2 constraints (LB3) were found and are shown in the table below, Table 14. The bounds were found to be

“very weak” with LB3 as 0 and LB4 as 0.288.

Test No. Optimal Solution


(LB3)

LP Relaxation (LB4)

Optimality gap

6 9 0 0.288 96.8%

Table 14 Lower bounds for subset 1

56


Subset 2

For Subset 2, the cost boundaries influenced by Factor 1 and 2 constraints were found to be upper limit of 58

million DKK and lower limit of 0.25 million DKK. The number of coordination principles violated for these limits

were found to be 25 (shown in Table 15). LP bound (lower bound produced by LP relaxation) was found to be

19.63, which is 21.48% within the IP optimal solution (shown in Table 16 ). This could be considered as a “good”

bound, though not the best. (Christofides, et al., 1987) in one of their RCPSP problems had an optimality gap of

35.8% and strengthened the LP bound by devising a collection of cutting planes. The improved LP bound was

equivalent to the IP optimal solution.

Most generated LP bounds have been found to be “weak” but Subset 2 provided a much stronger bound. The

strength of the LP bound appears to be problem specific. The subsection, 6.3 Analysis of LP Relaxation, would

discuss and analyze the factors that influence the strength of LP bounds. LB3 was determined to be zero again

and hence can be concluded as an incompetent bound.

Test No. MaxCost (million DKK)

MinCost (million DKK)

Coordination principles violated



(seconds)

Optimal

1 NA NA 0 15.946 1 Yes

2 100 0 0 15.113 1 Yes

3 58 0 0 14.437 2 Yes

4 58 0.25 25 13.003 1061 Yes

5 58 0.5 Infeasible

Table 15 Test results of Model 1 for subset 2

Test No. Optimal Solution


(LB3)

LP Relaxation (LB4)

Optimality Gap

4 25 0 19.63 21.48%

Table 16 Lower bounds for subset 2

57


Subset 3

For Subset 3, no feasible solution could be found for any lower cost limit greater than zero. The Factor 1 and

Factor 2 constraints restrict the problem from decreasing the cost for all the years below 740 million DKK and

increasing the cost above zero million DKK. Without MaxCost and MinCost limits, no coordination principles

were violated with a MAD of 132.78.

Test No. MaxCost (million DKK)

MinCost

(Million DKK)

Coordination principles violated



(seconds)

Optimal

1 NA NA 0 132.78 2 Yes

2 740 0.1 Infeasible Table 17 Test results of Model 1 for subset 3

From the test results of Model 1 for all the three subsets, it was observed that the upper and lower cost limits

could not be tightened beyond certain boundaries and the gaps between the cost limits were significantly

large. The leveling of cost for all years is found to be a difficult problem to solve due to the presence of the Factor

1 and 2 constraints and the MAD of the cost profile would not decrease any further as shown in the Model 1

results of the subsets. However, the advantage of Model 1 is that it was able to identify these cost boundaries

influenced by Factor 1 and 2 constraints.

Moreover, it was observed from the lower bound results of subset 1 and 2 (Table 14 and Table 16) that when

the Factor 2 constraints were removed (LB3), “very weak” bounds were produced that are not suitable to analyze

the quality of the feasible solutions. However, by summarizing all the lower bound results (from Table 10, Table

14 and Table 16) it can be observed that when the “hard” constraints were removed for LB1, LB2 and LB3 the

coordination principles were not violated for all tests. Therefore, it appears that the “hard” constraints (Factor

1 and Factor 2) are causing the coordination principle violations.

58


6.2 MODEL 2

Subset 1

The following table,Table 18, shows the results of Model 2 with different weight coefficients. For Subset 1, it was

observed that the MAD of the cost profile reduced to 35.03 when the weight of MAD was introduced (𝜋𝜋1 =

0.25). The MAD did not decrease further with increasing weight coefficients of MAD and therefore 35.03 is

proved to be the lowest MAD for subset 1. Another observation is that the lowest MAD was achieved without

any violations, whereas Model 1 had 9 violations (shown in Table 13). This result shows more evidence that

Model 2 could decrease MAD with fewer violations than Model 1. Figure 24 illustrates the results of different

weight coefficients of MAD(𝜋𝜋1).

Test No. Weight of coordination

principles (𝝅𝝅𝟐𝟐)

Weight of MAD (𝝅𝝅𝟏𝟏)

Objective function



(seconds)

Optimal

1 1 0 0 0 42.154 1 Yes

2 0.75 0.25 8.76 0 35.03 626 Yes

3 0.5 0.5 17.51 0 35.03 1391 Yes

4 0.25 0.75 26.27 0 35.03 1512 Yes


0 0 0 0

42,154

35,03 35,03 35,03

0

5

10

15

20

25

30

35

40

45

0 0,25 0,5 0,75

Weight of MAD (π1)

Coordination Principles violated MAD

Figure 24 Results of different weight coefficients of MAD for subset 1

59


Subset 2

Table 19 shows the results of Model 2 for subset 2 when tested with different weight coefficients.



Weight of MAD

(𝝅𝝅𝟏𝟏)

Objective function



Optimal

1 1 0 0 0 15.946 1 Yes

2 0.75 0.25 3.247 0 12.989 35 Yes

3 0.5 0.5 6.494 0 12.989 33 Yes

4 0.25 0.75 9.741 0 12.989 116 Yes


The Model 2 results of Subset 2 is illustrated in Figure 25, which is similar to the results of Subset 1. Model 2

was able to attain the lowest MAD (12.989) with 0 violations whereas Model 1 had 25 violations with 13.003

MAD (shown in Table 15). Therefore, Model 2 has proved again to achieve lower MAD with fewer coordination

principle violations than Model 1.

Figure 25 Results of different coefficients of MAD for subset 2

0 0 0 0

15,946

12,989 12,989 12,989

0

2

4

6

8

10

12

14

16

18

0 0,25 0,5 0,75

Weight of MAD (π1)


60


Subset 3

The table below, Table 20, shows the results of Model 2 for Subset 3.



Weight of MAD

(𝝅𝝅𝟏𝟏)

Objective function



Optimal

1 1 0 0 0 132.78 2 Yes

2 0.75 0.25 46.88 24 115.52 260 Yes

3 0.5 0.5 69.76 24 115.52 931 Yes

4 0.25 0.75 92.64 24 115.52 2500 No Table 20 Test results of Model 2 for subset 3

The MAD was decreased to a minimal of 115.52 when the weight coefficient of MAD was increased. However,

24 coordination principles were violated while decreasing the MAD. Model 1 (shown in Table 17) was not able

to decrease MAD any further than 132.78 due to the restrictions of the cost boundary limits for all years. Since

Model 2 is not bounded by any cost limits for all years, it is flexible in positioning the cost for every individual

year in order to decrease MAD. Model 2 being unbounded was pointed out as a weakness in CHAPTER 5:

Description of the models, but it could also be seen as its biggest strength if the decision makers are keen on

achieving the lowest MAD.

Figure 26 Results of different weight coefficients of MAD for subset 3

0

24 24 24

132,78115,52 115,52 115,52

0

20

40

60

80

100

120

140

0 0,25 0,5 0,75

Weight of MAD (π1)


61


For all the three subsets, the MAD was decreased to its lowest when the weight coefficient (𝜋𝜋1) was increased

to 0.25. Subset 1 and 2 had zero violations whereas 24 coordination principles were violated for Subset 3. The

behavior of Model 2 for different weight coefficients also can be termed as problem specific. It is highly possible

that for sets with higher number of activities the results would differ for coefficients 𝜋𝜋1 = 0.5 𝑦𝑦𝑛𝑛𝑎𝑎 0.75 .

However, from the results of Subset 1, 2 and 3, it can be concluded that Model 2 decreases the MAD with

increasing weight coefficient(𝜋𝜋1) with more or the same number of coordination principle violations. Moreover,

it was observed from the results of Subset 1 and 2 that Model 2 was able to attain the lowest MAD with fewer

violations than Model 1. In conclusion, Model 2 sets up a profile with different weight coefficients and indicates

the lowest attainable MAD, which make the model a valuable tool for the decision makers at Banedanmark.

6.3 ANALYSIS OF LP RELAXATION

The LP relaxation has been found to be “weak” for almost all the tests, meaning that the solution of the linear

program is far away from the underlying integer programming problem. Integer programming problems can be

formulated in many ways and a “good” integer program formulation of a problem is one that has its LP relaxation

not too different (Bosch & Trick, 2005). This implies that that the current integer programming formulation

implemented in Model 1 and Model 2 may not be an ideal formulation of the problem.

Due to the problem requiring a lot of logical constraints for the coordination principles, the “Big M method” was

used extensively to model the coordination principles. By using “Big M”, sometimes arbitrarily large, the feasible

region of the LP relaxation is unreasonably expanded which allows for many fractional values (Camm, et al.,

1990) & (Bosch & Trick, 2005).

(Camm, et al., 1990) analyzed the effect of “Big M method” by implementing it in a production planning problem

(or Lot-Sizing problem). The constraint with the “Big M” is shown below and an example is illustrated to describe

the detrimental effects if M is too large.

𝑋𝑋𝑖𝑖𝑃𝑃 ≤ 𝑀𝑀𝑌𝑌𝑖𝑖𝑃𝑃 ∀𝑖𝑖 ∈ 𝐼𝐼, 𝑝𝑝 ∈ 𝐽𝐽

𝑤𝑤ℎ𝑦𝑦𝑦𝑦𝑦𝑦,𝑋𝑋𝑖𝑖𝑃𝑃 𝑖𝑖𝑦𝑦 𝑎𝑎ℎ𝑦𝑦 𝑦𝑦𝑚𝑚𝑝𝑝𝑟𝑟𝑛𝑛𝑎𝑎 𝑝𝑝𝑓𝑓 𝑝𝑝𝑦𝑦𝑝𝑝𝑎𝑎𝑟𝑟𝑎𝑎𝑎𝑎 𝑖𝑖 𝑎𝑎𝑝𝑝 𝑝𝑝𝑦𝑦𝑝𝑝𝑎𝑎𝑟𝑟𝑎𝑎𝑦𝑦 𝑖𝑖𝑛𝑛 𝑝𝑝𝑦𝑦𝑦𝑦𝑖𝑖𝑝𝑝𝑎𝑎 𝑝𝑝

𝑌𝑌𝑖𝑖𝑃𝑃 𝑖𝑖𝑦𝑦 1 𝑖𝑖𝑓𝑓 𝑝𝑝𝑦𝑦𝑝𝑝𝑎𝑎𝑟𝑟𝑎𝑎𝑎𝑎 𝑖𝑖 𝑖𝑖𝑦𝑦 𝑝𝑝𝑦𝑦𝑝𝑝𝑎𝑎𝑟𝑟𝑎𝑎𝑦𝑦𝑎𝑎 𝑖𝑖𝑛𝑛 𝑝𝑝𝑦𝑦𝑦𝑦𝑖𝑖𝑝𝑝𝑎𝑎 𝑝𝑝 𝑦𝑦𝑛𝑛𝑎𝑎 0 𝑝𝑝𝑎𝑎ℎ𝑦𝑦𝑦𝑦𝑤𝑤𝑖𝑖𝑦𝑦𝑦𝑦

For instance, if 𝑋𝑋11 = 100 𝑦𝑦𝑛𝑛𝑎𝑎 𝑀𝑀 = 10,000. The LP relaxation of the model will set 𝑌𝑌11 𝑦𝑦𝑦𝑦 0.01, which is 99%

far away from the IP optimal solution (𝑌𝑌11 = 1).

62


Therefore, for such poor implementation of “Big M method” the relaxation of IP model is “very weak” which

leads to excessive branching that causes increase in computation time (Rubin, 2011) (YALMIP, 2015). (Camm, et

al., 1990) observed that even for reasonably size problem with 32 binary variable and 72 constraints, the size of

M affects the computational efficiency of the problem. Figure 27 shows the computation time for different values

of M reported by (Camm, et al., 1990). Therefore, it is advantageous if smaller value of M is chosen which does

not affect the feasible region but attains a LP relaxation closer to the IP optimal solution. However, practitioners

are also recommended to consider alternatives to the “Big M method” which could be more efficient (Richards

& How, 2005).

Figure 27 Computation time for different values of M (Camm, et al., 1990)

63


All the coordination principle constraints were implemented with a single M value of (16*365) which represents

the number of days between 2015 and 2030. As mentioned in CHAPTER 5: Description of the models,

‘Simultaneous’ and ‘Before/Simultaneous’ principles are modeled similarly, and ‘Simultaneous Start’,

‘Simultaneous End’ and ‘Before’ principles are modeled similarly.

The following is the generic formulation of coordination principle 1 which is a ‘Simultaneous’ principle.

‘Before/Simultaneous’ principle is modeled similarly

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_1 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_1 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_2 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_2 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷

𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_1 + 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,1_2 = (2 − 1) + 𝑦𝑦𝑟𝑟,1

For LP relaxation (LB4), only 𝑎𝑎𝑦𝑦𝑦𝑦𝑖𝑖𝑦𝑦𝑏𝑏𝑙𝑙𝑦𝑦 𝑦𝑦𝑟𝑟,𝑐𝑐 was relaxed. Since variable 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,𝑠𝑠𝑖𝑖𝑠𝑠 is not relaxed, 𝑦𝑦𝑟𝑟,𝑐𝑐 for the

above formulation is always forced to 0 or 1.

The equations below illustrate the generic formulation of coordination principle 2 which is a ‘Simultaneous

Start’ principle. ‘Simultaneous End’ and ‘Before’ principles are formulated similarly.

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈æ𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 + 𝑦𝑦𝑟𝑟,2 ∗ 𝑀𝑀 ≥ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷

𝑦𝑦𝑝𝑝′,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈æ𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 − 𝑦𝑦𝑟𝑟,2 ∗ 𝑀𝑀 ≤ 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷

The formulation states that if the coordination principle is violated (𝑦𝑦𝑟𝑟,2 = 1) , then

𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 can start any day between 16 years after and 16 years

before 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈æ𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷. Considering the relevant constraints that activities should start after

1st July 2015 and should end before 31st December 2030 [Equations (1) and (3)], the above formulation

unnecessarily expands the feasible region. For example, if 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑆𝑆𝑝𝑝𝑃𝑃𝑟𝑟 𝑃𝑃𝑃𝑃 𝐴𝐴𝐷𝐷𝑈𝑈æ𝑃𝑃𝑠𝑠𝑎𝑎𝑟𝑟𝐴𝐴𝑦𝑦𝑃𝑃𝑈𝑈𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 starts in the year

2020, then according to the above formulation 𝑦𝑦𝑝𝑝,𝑟𝑟,𝐵𝐵𝑟𝑟𝑃𝑃𝑦𝑦𝑟𝑟 𝑃𝑃𝑃𝑃 𝐾𝐾𝑃𝑃𝐷𝐷𝑠𝑠𝐷𝐷𝑟𝑟𝑘𝑘𝑘𝑘𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷𝑦𝑦𝑟𝑟,𝐷𝐷𝑦𝑦𝑓𝑓𝑖𝑖𝐷𝐷𝑖𝑖𝐷𝐷𝑖𝑖𝑃𝑃𝐷𝐷 could start anywhere

between 2004 and 2036 provided the principle is violated. Therefore, the value of M implemented in the models

is considered to be large which allows for fractional values when the problem is relaxed. This was the reason the

obtained LP bounds for most of the tests were “very weak”.

64


The strength of the LP relaxation is also influenced by which coordination principles are violated. Test 4 of Model

1 for 9 projects (shown in Table 9) showed a feasible solution of 44 violations. The model was tested once again

with ‘only Simultaneous and Before/Simultaneous principles’ and another test with ‘only Simultaneous Start,

Simultaneous End and Before principles’. The test with ‘only Simultaneous and Before/Simultaneous

principles’ showed a strong LP relaxation and the LP relaxation of the test with ‘only Simultaneous Start,

Simultaneous End and Before principles’ provided a weak bound with an optimality gap of 89.07%. The table

below, Table 21, shows the results of the tests.

Subset 2 was the only test that provided a “good” lower bound by LP relaxation with an optimality gap of 21.48%

(shown in Table 16) and it is believed that it was because most of the coordination principles violated were

‘Simultaneous’ and ‘Before/Simultaneous’ principle. However, it could be said that ‘Simultaneous’ and

‘Before/Simultaneous’ principles are weakly formulated too since the binary variable 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,𝑠𝑠𝑖𝑖𝑠𝑠 is also attached

to the large M value and so if the variable 𝑥𝑥𝑝𝑝,𝑝𝑝′,𝑟𝑟,𝑠𝑠𝑖𝑖𝑠𝑠 was also relaxed then the problem would result in a “weak”

LP relaxation as well. The improper implementation of “Big M method” has caused “weak” LP relaxations, which

has affected the computational efficiency in solving the IP problem.

6.4 DISCUSSION

From the analysis of the LP relaxation, it can be concluded that the formulation of the problem in both the models

is “weak” which causes longer computation time to find the IP optimal solution. Though the “Big M method” has

helped in successfully modeling the problem, it has caused great difficulty in successfully solving the problem.

Integer programs are generally difficult to solve and by imposing the “Big M method”, one would encounter

computational pitfalls that can be detrimental in solving the IP model (Camm, et al., 1990). Therefore with the

current IP models that have poor computational performance, the question arises if they could be used to solve

the problem for all the projects (over 200) at Banedanmark. Optimal solutions for just 9 projects could not be

found in 2500 seconds and thus with the increase in the number of projects the computation time to solve the

Table 21 Test results of different principles

Test No.

Description Objective function

Optimal Computation time

(seconds)

LP Relaxation

Optimality Gap

1 Only simultaneous and before/simultaneous principles

7 Yes 97 7 0%

2 Only simultaneous start, end and before principles

29 Yes 571 3.169 89.07%

3 All coordination principles 44 No 2500 11.23 74.48%

65


problem is expected to rise significantly, which may not be practical. In conclusion, computational consequences

of the model formulation could be considered as a weakness of this thesis.

The methods to derive the lower bounds for determining the quality of the attained feasible solutions were

found to be incompetent. Lagrangian relaxation, a method of dualizing the cost limit constraints [Equations (22)

and (23)], was tried to obtain stronger lower bounds and the subgradient algorithm was used to obtain the

lagrangian multipliers. However, the technique could not be implemented successfully and therefore this thesis

failed in generating strong lower bounds that could be used to determine the quality of the feasible solutions.

Within the limited computational performance of the models, the final chapter of this report carries out

discussion about the benefits that the models provide and recommendations on the usage of the models that

would potentially be helpful at Banedanmark. Besides the computational weakness of the models, the analysis

of the subsets has provided some promising findings about Model 1 and Model 2. The most important

observation made from the analysis of Model 1 for all the subsets was that the lower and upper cost limits could

not be tightened beyond certain boundaries due to restrictions of the “hard” Factor 1 and Factor 2 constraints.

The gaps between the cost limits were significantly large and thus solving resource leveling problem was

difficult. Moreover, from the results of the lower bound tests, it appeared that the “hard” Factor 1 and Factor 2

constraints were influencing the coordination principle violations.

The following tables summarize the strengths and weaknesses of both the models that were discussed in

CHAPTER 5: Description of the models and CHAPTER 6: Analysis of smaller subsets of data.

Model 1

Strengths Weakness

1. Showed evidence that the number of coordination

principles violated tends to increase with tighter cost

limit constraints.

1. The model does not optimize MAD.

2. Advantageous if the decision makers have certain

polices on cost limits. (Example: Maximum of 50

million DKK is allowed in a year)

2. Though the overall MAD of cost profile decreases,

there could be few instances where the MAD does not

decrease with strengthened cost limit constraints.

3. Identifies the cost boundaries beyond which solutions

cannot be found.

3. The gap between the lower and upper cost limits are

significantly large and cannot be tightened further

due to the restrictions of Factor 1 and 2 constraints.

Table 22 Strengths and Weaknesses of Model 1

66


Model 2

Strengths Weakness

1. The model optimizes the coordination principle

violations and MAD of cost profile simultaneously.

1. The model is not bounded by any cost limits.

Therefore, the cost for an individual year could be

very low which might be a concern for the decision

makers.

2. For increasing weight coefficients of MAD, the model

results in decreasing MAD with more or the same

coordination principle violations. This profile with

different weight coefficients would be an effective

supporting tool for the decision makers.

2. Due to the poor computational performance, the

actual behavior of the model for different weight

coefficients would not be visible with only feasible

solutions.

3. The model not being bounded by any cost limits is also

its biggest strength. Due to the flexibility of the model,

the lowest MAD of the cost profile is attainable.

4. Showed evidence that the lowest MAD could be

attained with fewer coordination principle violations

than Model 1.

Table 23 Strengths and Weaknesses of Model 2

Since Model 2 is able to show the coordination principle violations and MAD as function of each other by

obtaining results for different weight coefficient, it could be beneficial to the decision makers. Moreover, as

shown in the results of the subsets, Model 2 attains the lowest MAD with fewer coordination principle violations

than Model 1. Therefore, considering only the results of coordination principle violations and MAD as criteria

for choosing the baseline schedule, the schedule from Model 2 for the 9 projects will be chosen as the baseline

schedule, which forms the basis for ‘Scenario Analysis’ in CHAPTER 8: Scenario Analysis.

67

CHAPTER 7: Testing For 36 Projects

CHAPTER 7: TESTING FOR 36 PROJECTS

As mentioned in CHAPTER 1: Introduction, one of the objectives of this thesis is to test the models (Model 1

and Model 2) for scheduling railway projects from the Sealand region of Denmark. The region is highlighted in

red in the figure shown below, Figure 28. There are 36 railway projects from this region as shown in Table 1. The

region has 140 route sections and with the inclusion of assets and phases, the total number of activities is 2239.

The method implemented in C++, which is used to generate the relevant coordination principle equations

depending on the characteristics of the pair of activities, was run for the 2239 activities. Table 24 in the following

page shows the number of pairs of activities that were categorized under each coordination principle. Equations

were generated for every pair under every coordination principle and a total of 12,651 equations were

generated.

Figure 28 Sealand region of Denmark

68


Coordination Principle No. of activity pairs

1 89

2 343

3 51

4 112

5 0

6 3

7 89

8 343

9 84

10 112

11 105

12 0

13 343

14 112

15 105

16 163

17 0

18 52

19 89

20 343

21 84

22 112

23 105

24 163

25 0

Table 24 No. of pairs of activities under each coordination principle for the 36 projects

69


7.1 MODEL 1

Table 25 shows the results of Model 1. The computational time limit for all the tests was set as 3600 seconds.

For Test 1, when no cost limits were applied, the number of coordination principles violated was found to be 25.

The optimal solution was found in 46 seconds. Test 2 produced optimal solution within the time limit but the

succeeding tests were only able to attain feasible solutions. When the lower cost limit (MinCost) was introduced

in Test 6, no solution could be found within the time limit. Moreover, the cost limit (MaxCost) could not be

lowered below 737.77 million DKK due to the same reason (Factor 2 constraint) explained in Model 1 results for

the 9 projects.

The figure below, Figure 29, shows the cost profile from Test 1 when there were no cost limits applied and the

MAD of the cost profile was calculated to be 457.41.

Figure 29 Cost profile when no cost limits were applied

Test No.

MaxCost (million DKK)

MinCost (million DKK)



MAD Computation Time (<3600s)

Optimal

1 NA NA 25 457.41 46 Yes

2 1500 0 33 367.90 325 Yes

3 1000 0 33 345.74 3600 No

4 800 0 39 296.08 3600 No

5 740 0 84 241.47 3600 No

6 740 1 No solution found 3600


142,9084,70

636,44

1151,48

1788,97

52,78

1431,69

10,97 0,00 0,00 15,71 19,01 0,33 8,32

470,21

9,020,00

200,00

400,00

600,00

800,00

1000,00

1200,00

1400,00

1600,00

1800,00

2000,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[Mill

ion

DKK]

Year

Cost Average

70


Figure 30 shows the cost profile of Test 5 where the MaxCost was set at 740 million DKK and the MAD was

calculated to be 242.47.

Figure 31 depicts the effect of tightening the upper cost limit (MaxCost), where the number of coordination

principles tends to increase and the MAD of the cost profile to decrease. Model 1 in this case provided decreasing

MAD for all tests.

Figure 31 Effect of tightening the upper cost limit MaxCost

25 33 33 3984

457,41

367,90345,74

296,08

241,47

0

50

100

150

200

250

300

350

400

450

500

NA 1500 1000 800 740

MaxCost [Million DKK]

Coordination Principles Violated MAD

117,2086,39

399,86

733,19 708,69

591,09

683,74

295,70

91,06 83,00

479,11509,57

218,97

87,21

737,77

0,000,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[mill

ion

DKK]

Year

Cost Average

Figure 30 Cost profile when MaxCost was set as 740 million DKK

71


7.2 MODEL 2

Model 2 was tested for the 36 projects with different weight coefficients of MAD (𝜋𝜋1 = 0, 0.25, 0.5, 0.75) and

the table below, Table 26, shows the results of the tests. Optimal solutions could not be found within the limited

time (3600 seconds) when the weight coefficient of MAD(𝜋𝜋1) was increased above zero.

Test

No.

Weight of

Coordination

Principles

(𝝅𝝅𝟐𝟐)

Weight of

MAD

(𝝅𝝅𝟏𝟏)

Objective

Function

No. of coordination

principles violated


(<3600s)

Optimal

1 1 0 25 25 457.41 46 Yes

2 0.75 0.25 303.57 265 419.30 3600 No

3 0.5 0.5 207.01 251 163.02 3600 No

4 0.25 0.75 392.5 417 384.33 3600 No


The figure below, Figure 32, shows the results of coordination principles violated and MAD for increasing weight

coefficient of MAD (𝜋𝜋1). In CHAPTER 6: Analysis of smaller subsets of data, it was found that Model 2 sets-

up the profile of increasing coordination principle violations and decreasing MAD for increasing weight

coefficient of MAD, which would be beneficial to the decision makers. However, this behavior cannot be

observed with feasible solutions.

25

265 251

417457,41

419,30

163,02

384,33

0

50

100

150

200

250

300

350

400

450

500

0 0,25 0,5 0,75

Weight of MAD (π1)

Coordination Principles violation MAD

Figure 32 Results of different weight coefficients of MAD

72


The figure below, Figure 33, is the cost profile attained when 𝜋𝜋1 𝑦𝑦𝑛𝑛𝑎𝑎 𝜋𝜋2 were set as 0.5 in Model 2. The MAD of

the cost profile was found to be 163.02.

Figure 34 shows the total number of activities that start in every year. One of the assumptions made in this thesis

and in the model is that there are no restrictions on the number of activities that could start in a year. Moreover,

Banedanmark did not present it as one of their problems. However, it is quite interesting to see the number of

activities that start in a year and further statistics could be shown on the number of activities that start from

each phase (‘Definition’, ‘Program’, Projektering’ and ‘Udforsel’) or within a project in the year. These figures

along with the cost profile could provide an overview of the schedule for the period 2015 - 2030 that would act

as a supporting tool for the decision makers in resource planning.

324

532

153

57 69 56 53 73 6333

216

62

139

219

106 84

0

100

200

300

400

500

600

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

No.

of a

ctiv

ities

star

ting

in th

e ye

ar

YearFigure 34 No. of activities that start in the year

72,65

344,84

713,04

818,11

363,33 351,83405,99

246,41

439,43

747,11

117,33

360,92

154,37

216,28

150,62

320,30

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

900,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[Mill

ion

DKK]

Year

Cost Average

Figure 33 Cost profile attained from Model 2

73


7.3 DISCUSSION

For large number of projects (36 projects), it was observed from Model 1 that solutions may not be found for

tight cost constraints within the limited time (3600 seconds). To find the optimal solution, the model might take

several hours depending on the strength of the cost limits. The extent of computation time that Banedanmark

are willing to run the models is unknown to the author of this thesis, but solving the problem for more than 36

projects would definitely not be practical. Moreover, without implementation of methods to derive strong lower

bounds, it is difficult to determine how far the feasible solution is from the optimal solution (optimality gap).

From the results of Model 2, it can be observed that the profile of decreasing MAD and increasing coordination

principle violations for increasing weight coefficient of MAD is unachievable with feasible solutions. Optimal

solutions are required for Model 2 to be an effective supporting tool for the decision makers in deciding the best

result. But, it can be concluded that within a limited time (3600 seconds) optimal solutions are unattainable for

large number of projects.

Therefore, the computational complexity of the models and lack of methods to derive strong lower bounds are

obstructions in solving the scheduling problem for large number of projects and hinders the decision making

process in deciding the best schedule. The following points summarize the issues the decision makers would

encounter while solving the scheduling problem:

1. The models would take several hours, which may not be practical, to obtain the optimal solution.

2. With only feasible solutions, it is difficult to make analysis on deciding the best result or schedule.

3. Without strong lower bounds, determining the quality of the feasible solutions will be difficult.

Hence, due to the severity of the issues the models appear to be ineffective in solving the project scheduling

problem for large sets of projects.

74

Chapter 8: Scenario Analysis

CHAPTER 8: SCENARIO ANALYSIS

8.1 ASSUMPTIONS

As mentioned in CHAPTER 3: Literature Review, majority of the project scheduling efforts have been on

developing methods to generate the baseline schedule while assuming complete information in a deterministic

environment. However, experts from the fields of Strategic Planning and Project Scheduling have pointed out

that during execution projects may be subject to various uncertainties which leads to disruptions of the schedule.

Some of the uncertainties are, activities taking longer time to complete than planned (delays), resource

availability may vary, due dates of activities may change, new activities might have to be included (Van de

Vonder, et al., 2007). Organizations have found scenario analysis as a supporting tool in the decision-making

process to anticipate the consequences of uncertainties on strategic plans or long-term schedules and adapt

accordingly.

As mentioned in CHAPTER 1: Introduction, the decision makers at Banedanmark in the past years had been

choosing a baseline schedule and making changes accordingly when the delays or new due dates are known.

Measures of how Banedanmark plan for the unexpected events in advance are not known to the author of this

thesis but Banedanmark are interested in methods to anticipate the consequences of the unexpected events.

This thesis limits itself to dealing only with delays in completion of the activities and no real data on the delays

are known. Dealing with changes in the due dates of activities, inclusion of new activities are some of the other

uncertainties that researchers in the project scheduling community have included (Van de Vonder, et al., 2007).

From literature review, it was found that scenario analysis is a supporting tool for dealing with uncertainties and

predictive-reactive scheduling, mentioned by (Van de Vonder, et al., 2007) (Herroelen & Leus, 2004), is a method

to re-optimize the baseline schedule when the unexpected events have occurred. Therefore, scenarios are

constructed with different assumed sets of activity delays and their respective impacts on the baseline schedule

could be observed using the predictive-reactive scheduling model. The model will indicate the deviation of the

new re-optimized schedule from the baseline schedule and analysis could be carried out on the scenarios that

would disrupt the baseline schedule. The objective of the predictive-reactive scheduling model will be described

later in this section. The sole purpose of the scenario analysis in this thesis is to present a method to

Banedanmark that could potentially help in anticipating the consequences of delays.

75


Due to the delays, the new activity durations may deviate from the planned durations in the baseline schedule

(Van de Vonder, et al., 2007). Therefore, for every scenario in this thesis, the assumed delays of activities are

incorporated by introducing parameter 𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂𝒑𝒑,𝒓𝒓,𝒂𝒂,𝒇𝒇, where delay of activity is given in number of months ,

and by altering Equation (2) to 𝑴𝑴𝑴𝑴𝒂𝒂 𝒂𝒂𝒂𝒂𝒂𝒂𝑴𝑴 𝒐𝒐𝒇𝒇 𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂 �𝑴𝑴𝒑𝒑,𝒓𝒓,𝒂𝒂,𝒇𝒇� = 𝒔𝒔𝒂𝒂𝒂𝒂𝒓𝒓𝒂𝒂 𝒂𝒂𝒂𝒂𝒂𝒂𝑴𝑴 𝒐𝒐𝒇𝒇 𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂 �𝒔𝒔𝒑𝒑,𝒓𝒓,𝒂𝒂,𝒇𝒇� +

𝒅𝒅𝑴𝑴𝑴𝑴𝒍𝒍𝒂𝒂𝒍𝒍 𝒐𝒐𝒇𝒇 𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂 (𝒅𝒅𝑴𝑴𝑴𝑴𝒍𝒍𝒍𝒍𝒂𝒂𝒑𝒑,𝒓𝒓,𝒂𝒂,𝒇𝒇) + 𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂 𝒐𝒐𝒇𝒇 𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂𝒂(𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂𝒑𝒑,𝒓𝒓,𝒂𝒂,𝒇𝒇).

In collaboration with Dorte-Lene Bacher, the different scenarios could be set-up with activity delays of 6 months

or 12 months. Moreover, Dorte-Lene Bacher would also be interested in observing the impacts of delays in

completion of activities from each of the four phases (‘Definition’, ‘Program’, ‘Projektering’ and ‘Udførsel’)

within a project. As mentioned in 6.4 Discussion subsection of CHAPTER 6: Analysis of smaller subsets of

data, Model 2 results for the 9 projects is chosen as the baseline schedule for scenario analysis. The total number

of activities in the 9 projects was found to be 856. Out of these 856 activities, 440 of them were under the

‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project. This project is arbitrarily chosen as the basis for the

set-up for all scenarios.

Scenario 1

Out of the total 440 activities in the ‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project, 110 activities

were found to have ‘Definition’ phase. For Scenario 1, all these 110 activities are delayed by 6 months as shown

below. The rest of the activities in the 9 projects have no delays.

𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂𝑹𝑹𝒐𝒐𝒔𝒔𝑹𝑹𝒂𝒂𝒅𝒅𝒂𝒂𝑴𝑴_𝑲𝑲𝒂𝒂𝒅𝒅𝒏𝒏𝑴𝑴𝒂𝒂𝒏𝒏𝒐𝒐𝒓𝒓𝒍𝒍_𝒀𝒀𝒅𝒅𝑴𝑴𝑹𝑹𝒂𝒂𝒓𝒓𝒂𝒂𝒇𝒇𝒂𝒂𝒂𝒂𝑴𝑴𝒓𝒓𝒂𝒂𝑴𝑴𝒍𝒍_𝑻𝑻𝒐𝒐𝒍𝒍𝒇𝒇𝒐𝒐𝑴𝑴𝒂𝒂𝑴𝑴𝑴𝑴 ,𝒓𝒓𝒔𝒔𝟏𝟏 ,𝒂𝒂 ,𝑫𝑫𝑴𝑴𝒇𝒇𝒂𝒂𝑴𝑴𝒂𝒂𝒂𝒂𝒂𝒂𝒐𝒐𝑴𝑴 = 𝟔𝟔 𝑴𝑴𝒐𝒐𝑴𝑴𝒂𝒂𝒍𝒍𝒔𝒔 ∀𝒓𝒓𝒔𝒔𝟏𝟏 ∈ 𝑹𝑹𝑹𝑹𝟏𝟏(𝑹𝑹),𝒂𝒂 ∈ 𝒀𝒀

Scenario 2


were found to have ‘Program’ phase. For Scenario 2, all these 110 activities are delayed by 6 months as set-up

below.

𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂𝑹𝑹𝒐𝒐𝒔𝒔𝑹𝑹𝒂𝒂𝒅𝒅𝒂𝒂𝑴𝑴_𝑲𝑲𝒂𝒂𝒅𝒅𝒏𝒏𝑴𝑴𝒂𝒂𝒏𝒏𝒐𝒐𝒓𝒓𝒍𝒍_𝒀𝒀𝒅𝒅𝑴𝑴𝑹𝑹𝒂𝒂𝒓𝒓𝒂𝒂𝒇𝒇𝒂𝒂𝒂𝒂𝑴𝑴𝒓𝒓𝒂𝒂𝑴𝑴𝒍𝒍_𝑻𝑻𝒐𝒐𝒍𝒍𝒇𝒇𝒐𝒐𝑴𝑴𝒂𝒂𝑴𝑴𝑴𝑴 ,𝒓𝒓𝒔𝒔𝟏𝟏 ,𝒂𝒂 ,𝑷𝑷𝒓𝒓𝒐𝒐𝒍𝒍𝒓𝒓𝒂𝒂𝑴𝑴 = 𝟔𝟔 𝑴𝑴𝒐𝒐𝑴𝑴𝒂𝒂𝒍𝒍𝒔𝒔 ∀𝒓𝒓𝒔𝒔𝟏𝟏 ∈ 𝑹𝑹𝑹𝑹𝟏𝟏(𝑹𝑹),𝒂𝒂 ∈ 𝒀𝒀

76


Scenario 3

110 activities out of 440 in the ‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project were found to have

‘Projektering’ phase and these 110 activities are delayed by 6 months for Scenario 3.

𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂𝑹𝑹𝒐𝒐𝒔𝒔𝑹𝑹𝒂𝒂𝒅𝒅𝒂𝒂𝑴𝑴_𝑲𝑲𝒂𝒂𝒅𝒅𝒏𝒏𝑴𝑴𝒂𝒂𝒏𝒏𝒐𝒐𝒓𝒓𝒍𝒍_𝒀𝒀𝒅𝒅𝑴𝑴𝑹𝑹𝒂𝒂𝒓𝒓𝒂𝒂𝒇𝒇𝒂𝒂𝒂𝒂𝑴𝑴𝒓𝒓𝒂𝒂𝑴𝑴𝒍𝒍_𝑻𝑻𝒐𝒐𝒍𝒍𝒇𝒇𝒐𝒐𝑴𝑴𝒂𝒂𝑴𝑴𝑴𝑴 ,𝒓𝒓𝒔𝒔𝟏𝟏 ,𝒂𝒂 ,𝑷𝑷𝒓𝒓𝒐𝒐𝑷𝑷𝑴𝑴𝑹𝑹𝒂𝒂𝑴𝑴𝒓𝒓𝒂𝒂𝑴𝑴𝒍𝒍 = 𝟔𝟔 𝑴𝑴𝒐𝒐𝑴𝑴𝒂𝒂𝒍𝒍𝒔𝒔 ∀𝒓𝒓𝒔𝒔𝟏𝟏 ∈ 𝑹𝑹𝑹𝑹𝟏𝟏(𝑹𝑹),𝒂𝒂 ∈ 𝒀𝒀

Scenario 4


were found to have ‘Udførsel’ phase. For Scenario 4, all these 110 activities are delayed by 6 months as set-up

below. The rest of the activities in the 9 projects have no delays.

𝒂𝒂𝑴𝑴𝒅𝒅𝒂𝒂𝒂𝒂𝑹𝑹𝒐𝒐𝒔𝒔𝑹𝑹𝒂𝒂𝒅𝒅𝒂𝒂𝑴𝑴_𝑲𝑲𝒂𝒂𝒅𝒅𝒏𝒏𝑴𝑴𝒂𝒂𝒏𝒏𝒐𝒐𝒓𝒓𝒍𝒍_𝒀𝒀𝒅𝒅𝑴𝑴𝑹𝑹𝒂𝒂𝒓𝒓𝒂𝒂𝒇𝒇𝒂𝒂𝒂𝒂𝑴𝑴𝒓𝒓𝒂𝒂𝑴𝑴𝒍𝒍_𝑻𝑻𝒐𝒐𝒍𝒍𝒇𝒇𝒐𝒐𝑴𝑴𝒂𝒂𝑴𝑴𝑴𝑴 ,𝒓𝒓𝒔𝒔𝟏𝟏 ,𝒂𝒂 ,𝑼𝑼𝒂𝒂𝒇𝒇ø𝒓𝒓𝒔𝒔𝑴𝑴𝒅𝒅 = 𝟔𝟔 𝑴𝑴𝒐𝒐𝑴𝑴𝒂𝒂𝒍𝒍𝒔𝒔 ∀𝒓𝒓𝒔𝒔𝟏𝟏 ∈ 𝑹𝑹𝑹𝑹𝟏𝟏(𝑹𝑹),𝒂𝒂 ∈ 𝒀𝒀

One should remember that all the 4 scenarios constructed are assumed and not real data. In summary,

‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project has 110 activities of each phase and they are set-up as

different scenarios with 6-month delays. The figure below, Figure 35, illustrates the set-up of the different

scenarios.

Scenario 3 Scenario 4 Scenario 2 Scenario 1

SCENARIOS

Delays in all 110 activities of

’Definition’ phase


’Program’ phase


’Projektering’ phase


’Udførsel’ phase

All 440 activities are within ‘Roskilde_Kalundborg_Electrificering_Togfo

nden’ project and delays of 6 months.

Figure 35 Scenarios

77


The schedule of the 9 projects obtained from Model 2 (when 𝜋𝜋1 = 𝜋𝜋2 = 0.5) is chosen as the baseline schedule

for the scenario analysis and the baseline schedule has 122 coordination principle violations (shown in Table 11).

One of the objectives of the scenario analysis is to observe the effect of different scenarios on the coordination

principle violations.

In the railway construction industry, delays have been the foremost problem and it is believed that an activity is

rarely completed within the specified time (Aswathi & Thomas, 2013). Delays occur due to various reasons such

as performance of construction stakeholders, site and weather conditions, availability of resources (Aswathi &

Thomas, 2013). Delays in completion of the projects inevitably leads to cost escalation. (Flyvbjerg, et al., 2004)

pointed out from a survey of 258 transport infrastructure projects that 9 out of 10 projects have their cost

escalated. It was demonstrated that construction costs are overrun by 4.86% points per year of delay (Flyvbjerg,

et al., 2004). In this thesis, the cost of the activity is assumed to increase by 4.86% for one-year of delay.

A predictive-reactive scheduling model in this thesis is developed to observe the impacts of different scenarios

on the baseline schedule. The objective of the predictive-reactive scheduling model mentioned by (Van de

Vonder, et al., 2007) is as follows,

�𝑤𝑤𝑃𝑃�𝑹𝑹𝑃𝑃 − 𝑦𝑦𝑃𝑃�𝑃𝑃∈𝐽𝐽

where, 𝑹𝑹𝑃𝑃 is the new or realized starting time of activity j

𝑦𝑦𝑃𝑃 is the planned starting time of activity j from the baseline schedule

𝑤𝑤𝑃𝑃 is the weight of activity j that represents the cost of starting the activity j later or earlier than

planned in the baseline schedule.

The objective was to minimize the weighted sum of absolute deviation of the new starting times of activities

from the planned starting times. For this thesis, the weight of the activities that represents the cost function

(𝑤𝑤𝑃𝑃) is not considered. Moreover, it is assumed that the new starting time of the activity can only be after the

planned starting time from the baseline schedule. Therefore, the activity cannot start earlier than planned.

Hence, the objective of the predictive-reactive scheduling model will be changed to ∑ (𝑹𝑹𝑃𝑃 − 𝑦𝑦𝑃𝑃)𝑃𝑃∈𝐽𝐽 .

Banedanmark would also prefer if the re-optimized schedule has as little coordination principle violations as

possible. Therefore, minimizing the coordination principle violations will be added to the objective function. In

conclusion, the objective function of the predictive-reactive scheduling model would signify the deviation of

the new schedule from the baseline schedule and the coordination principles violated in the new schedule.

78


It can be recalled that the cost of an activity is provided based on its starting year. Due to the delays, the new

starting times of activities might move to different years than planned, which cause changes in the cost profile.

Therefore, for every scenario, the cost profile of the new schedule could be compared to that of the baseline

schedule. The changes in the cost profile would depict the deviation of the new schedule from the baseline

schedule.

The MAD of the baseline schedule is 101.52. The predictive-reactive schedule model does not consider

minimizing MAD but the MAD is expected to change for the new schedule due to the possibility of starting times

of activities moved to different years than initially planned and the consideration of increase in cost for delayed

activities.

The following points summarize all the assumptions that were considered while conducting the scenario analysis:

1. Delay in completion of the activities is the only parameter incorporated in the different scenarios.

2. Four scenarios are constructed with different sets of activities that have 6-month delays.

3. 4.86% of the cost is increased for one-year delay in completion of the activity.

4. The schedule of the 9 projects obtained from Model 2 (when 𝜋𝜋1 = 𝜋𝜋2 = 0.5) is set as the baseline

schedule.

5. With the incorporation of the delays for the scenario, the objective of the predictive-reactive

scheduling model is to minimize the deviation of the new starting times of activities from the planned

starting times activities and to minimize the number of coordination principles violated in the re-

optimized schedule.

6. The new starting times should be on or after the planned starting times from the baseline schedule.

79


8.2 PREDICTIVE REACTIVE SCHEDULING MODEL

There are few changes in the predictive-reactive scheduling model when compared to Model 1 and Model 2. The

cost limit and deviation constraints from the models are removed. The objective function is changed and few

other parameters are added. The following are the descriptions of the predictive-reactive scheduling method.

Parameter 𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑙𝑙𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 is introduced, which is the planned starting date of the activities obtained from

the baseline schedule. Delay parameter, 𝑎𝑎𝑦𝑦𝑙𝑙𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎𝑓𝑓 [months], is the delay in completion of activities.

Variable 𝑅𝑅𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 calculates the new starting dates of the activities. Since 4.86% of the cost is increased for one-

year delay of an activity, the new cost parameter 𝐼𝐼𝑛𝑛𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎_𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 updates the cost of the activity.

𝐼𝐼𝑛𝑛𝑎𝑎𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑦𝑎𝑎_𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 = 𝑎𝑎𝑝𝑝𝑦𝑦𝑎𝑎𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 �1 + 0.0486 ∗ 𝑎𝑎𝑦𝑦𝑙𝑙𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓

12 �

Objective Function

𝑀𝑀𝑖𝑖𝑛𝑛𝑖𝑖𝑚𝑚𝑖𝑖𝑧𝑧𝑦𝑦 ��(𝑅𝑅𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 − 𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑙𝑙𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓)𝐹𝐹∈𝐹𝐹

+ ��𝑦𝑦𝑟𝑟,𝑐𝑐𝑐𝑐∈𝐶𝐶𝑟𝑟∈𝑌𝑌𝐴𝐴∈𝐴𝐴𝑟𝑟∈𝑌𝑌𝑝𝑝∈𝑃𝑃

The objective is to minimize the sum of deviations of the new starting times of all activities from the planned

starting times. Since the new re-optimized schedule should also consider minimizing coordination principle

violations, it is included in the objective function as well.

Constraints

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ≥ 𝑖𝑖𝑛𝑛𝑖𝑖𝑎𝑎𝑖𝑖𝑦𝑦𝑙𝑙𝑎𝑎𝑦𝑦𝑎𝑎𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(26)

𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 = 𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 + (𝑙𝑙𝑦𝑦𝑛𝑛𝑙𝑙𝑎𝑎ℎ𝑝𝑝,𝑟𝑟,𝑎𝑎,𝑓𝑓 ∗ 30) + (𝑎𝑎𝑦𝑦𝑙𝑙𝑦𝑦𝑦𝑦𝑝𝑝,𝑟𝑟,𝑎𝑎𝑓𝑓 ∗ 30) ∀𝑝𝑝 ∈ 𝑃𝑃, 𝑦𝑦 ∈ 𝑅𝑅,𝑦𝑦 ∈ 𝑀𝑀,𝑓𝑓 ∈ 𝐹𝐹 ..(27)

The new starting date of an activity should be on or after its initial planned starting date, which is given by

Equation (26). The delay of the activity should also be taken into account while estimating the end date as shown

in Equation (27).

Factor 1, Factor 2 and factor 3 constraints are set-up similar to Model 1 and Model 2.

80


Results

The following table, Table 27, shows the results of the different scenarios. All the solutions were proven to be

optimal and were obtained in less than computation time of 10 seconds. The objective function for every

scenario indicates the sum of total number of days the new starting times of all activities deviate from the

planned starting times and the number of coordination principles violated in the new schedule.

Scenario Objective Function

Deviation of new starting times of all activities from the planned

starting times [days]

No. of Coordination Principles Violated

MAD Optimal

Baseline Schedule

122 101.52

1 122 0 122 101.52 Yes

2 12031 11880 151 111.98 Yes

3 15319 15180 139 115.99 Yes

4 144 0 144 103.66 Yes

Table 27 Results of the different scenarios

81


Scenario 1

The baseline schedule has 122 violations of the coordination principles with a MAD of 101.52. Scenario 1 includes

delays of 6 months in 110 activities within the ‘Roskilde_Kalundborg_Elektrificering_Togfonden’ project that

have ‘Definition’ phase and from the results it appears that Scenario 1 does not cause any disruptions to the

baseline schedule. The objective function showed a value of 122 which is the number of coordination principles

violated. Hence, for Scenario 1 the starting dates of the new schedule is the same as that of the planned starting

dates. Figure 36 compares the cost profiles of the new schedule and the baseline schedule and it can be observed

that there is no deviation from the baseline schedule.

Figure 36 Cost profiles of Baseline Schedule and Scenario 1

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[mill

ion

DKK]

Year

Baseline Schedule Scenario 1

82


Scenario 2

Scenario 2 involves delays in 110 activities that have ‘Program’ phase within

‘Roskilde_Kalundborg_Elektrificering’ project. This scenario disrupts the baseline schedule with the total number

of days the new starting times of all activities deviating from the planned starting times calculated to be 11,880

and the number of coordination principles violated in the new schedule was found to be 151. The figure below,

Figure 37, shows the comparison of cost profiles of the new schedule and the baseline schedule. Major changes

occur in the years 2018 and 2019.


0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[mill

ion

DKK]

Year


83


Scenario 3

Scenario 3, which involves delays in 110 activities with ‘Projektering’ phase, also disrupts the baseline schedule

with the total deviation found to be 15,180 days. The figure below, Figure 38, shows the deviation of the cost

profile of the new schedule from the baseline schedule, with most of the changes occurring in the years 2018,

2019, 2027 and 2028.

The number of coordination principles violated in the new schedule was found to be 139 which is fewer than the

Scenario 2 schedule. Therefore, it appears that the relation between the deviation of the new schedule from the

baseline schedule and the number of coordination principles violated differ with every scenario. Another

important observation made from the results of Scenario 3 was that due to the delays, some of the activities

were forced to end beyond their deadline. The deadline constraint is given by Equation (3), which states that all

activities must end before 31st December 2030.

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

900,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[mill

ion

DKK]

Year



84


The figure below, Figure 39, shows the number of activities that end every year and the number of activities that

end in 2031 was found to be 22.

Scenario 4

Scenario 4 involves delays in 110 activities which have ‘Udførsel’ phase and it was found that this scenario does

not cause any deviation from the baseline schedule. In the new schedule, all the activities start as planned times

in the baseline schedule. However, similar to Scenario 3, 22 activities were forced to end beyond 31st December

2030. Figure 40 in the following page shows that there is no deviation in the cost profile of the new schedule

from the cost profile of the baseline schedule.

Even though, all the activities start as planned it was found that due to the delays in ‘Udførsel’ activities 144

coordination principles were violated. Therefore, this result confirms that there is no generic relation for all

scenarios between the deviation of the new schedule from the baseline schedule and the coordination principles

violated in the new schedule.

69

51

13

47

1226

186

44

89

54

3344

78

44 44

22

0

20

40

60

80

100

120

140

160

180

200

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2030 2031

No.

of a

ctiv

ties e

nd in

the

year

Year

Figure 39 No. of activities end in the year

85


8.3 DISCUSSION

From analyzing the results of all four scenarios, it can be said that the consequences of activity delays is problem

specific. An activity is interrelated to many other activities through the Factor 1 and 2 constraints and hence

extending the duration of an activity affects the starting dates of all its interrelated activities. Therefore, the

consequences depend on the characteristics of the activity that is delayed such as its phase, the project it belongs

to and also the length of the delay. Due to the impacts of activity delays being problem specific, different

scenarios have varying effect on the cost profile deviation from the baseline schedule and the coordination

principle violations. Scenarios 2 and 3 showed deviation from the baseline schedule and increase in number of

coordination principles violated whereas Scenario 4 had an increase in number of coordination principles

violated in spite of causing no deviation from the baseline schedule. Therefore, it was observed that there is no

generic relation between the deviation from the baseline schedule and the coordination principle violations, and

appears to be differing with every scenario. Furthermore, the predictive-reactive scheduling method showed

that some scenarios could cause the activities to violate the due date constraint as shown by Scenario 3 and 4,

which had 22 activities end beyond 31st December 2030. In conclusion, given the large number of activities and

the complexity of interrelation of all activities, it would be difficult to predict the consequences of activity delays

on the whole schedule.

0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

800,00

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

Cost

[mill

ion

DKK]

Year



86


However, the predictive-reactive scheduling model makes it possible to test scenarios with different sets of

activity delays and indicate in advance various impacts the scenarios would have on the baseline schedule. It is

unknown to the author of this thesis if Banedanmark would prefer less deviation of the new schedule from the

baseline schedule or fewer coordination principle violations in the new schedule. Further work could be to test

every scenario in predictive-reactive scheduling model with different weight coefficients (𝜋𝜋1,𝜋𝜋2) of the

deviation and the coordination principle violations, and observe their behavior for every scenario. The results of

the scenarios show that there is also increase in MAD and whether Banedanmark would also desire minimized

MAD of the cost profile in the new schedule is unknown to the author. Due to the time restrictions of this thesis,

more concrete objective of predictive-reactive scheduling model could not be developed. Nevertheless, within

the assumptions made the model is able to indicate the various impacts of scenarios on the baseline schedule

and the following points summarize the benefits of the developed predictive-reactive scheduling model:

1. The model illustrates the changes in cost profile of the new schedule as a consequence of the scenario,

and presents which years undergo major deviation from the baseline schedule.

2. The model also indicates if the scenario causes increase in the number of coordination principles violated.

3. Some scenarios would cause activities to end beyond their respective due dates and the model is able to

identify this as well.

4. The method that Banedanmark use to make the changes in the baseline schedule when delay of an

activity is recognized is not known. To interpret the consequences of an activity delay could be a tedious

task due to the interrelation of activities. However, the predictive-reactive scheduling model is able to re-

optimize the baseline schedule without any computational issues while considering the Factor 1 and 2

constraints that all the activities are tied to. This makes the predictive-reactive scheduling model a

dynamic tool that could test various scenarios with different sets of activity delays and foresee their

consequences in quick time.

In conclusion, the predictive-reactive scheduling model could be used to anticipate the consequences of different

scenarios with delays. It could also be used as a tool to re-optimize the baseline schedule when a delay of an

activity is known. However, at the moment the model only considers the delays in completion of activities, which

is a limitation of the model. In real life, the baseline schedule is prone to disruptions due to various other

uncertainties. The model would be a valuable tool if it could also test scenarios with the incorporation of other

uncertainties that the decision makers would be interested in. Moreover, the objective of the predictive-

reactive scheduling model should be defined clearly. The model was tested for scenarios with assumed sets of

activity delays. If the model could be tested with a small set of real data and compared to the method that

Banedanmark use in reacting to activity delays, then the benefits of the model could be validated. One of the

objectives of this thesis is to present a method that potentially helps in anticipating the consequences of delays

87


and the predictive-reactive scheduling model fulfills this purpose. But, it is believed that the model is in the initial

stages of its development and further work needs to be carried out in creating a valuable supporting tool for the

decision makers at Banedanmark.

88

Chapter 9: Final Conclusion

CHAPTER 9: CONCLUSION

9.1 RECOMMENDATIONS

From the discussions in CHAPTER 7: Testing for 36 Projects, it can be concluded that solving the project

scheduling problem for all the projects at Banedanmark is impractical due to the computational inefficiency of

the models. However, the project scheduling problem was modeled successfully with Model 1 demonstrating

the relationship between the coordination principle violations and the cost limits, and Model 2 unifying the

coordination principle violations and the MAD of the cost profile as function of each other. Within the limited

computational performance of the developed models, the following tasks could be carried out that would act as

supporting results for the decision makers in the strategic planning process of deciding the project schedule.

1) Optimizing small sets of projects

The models were proved to be competent for small sets of projects with the optimal solutions being attained

within the limited time and the solutions clearly showing the relationship between the coordination

principle violations and the cost profile. With a maximum computational time limit of 1 hour, optimal

solutions could most probably be attained for problem sizes of less than 9 projects (856 activities). Decision

makers could potentially use the models in finding the optimized schedule plan for a small set of projects

carried out along a railway line. The models could also be used to solve the projects scheduling problem for

different small sets of projects and their optimized schedules could be merged.

2) Optimization without leveling the resource

Solving the project scheduling problem without leveling the resource is a secondary recommendation. The

test results of Model 1 and Model 2 for the sets of 9 projects and 36 projects showed that without leveling

the cost the optimal solutions were attained in 8 seconds and 46 seconds respectively. From the test results

it was observed that when the cost limit constraints were strengthened or minimizing MAD objective was

applied, the computational complexity in solving the problem increased. Therefore, the scheduling problem

for large sets of projects (36 projects or more) could be solved by the models without much computational

difficulty when the objective is only to minimize the number of coordination principles violated.

89


9.2 FURTHER WORK

Factor 1 and 2 constraints

All the lower bound results, showed that when the “hard” constraints (Factor 1 and factor 2) were removed for

LB1, LB2, and LB3, the coordination principles were not violated. These were evidences that the Factor 1 and

Factor 2 constraints influence the coordination principle violations. Another important observations made from

all the Model 1 results was that due to the presence of Factor 1 and Factor 2 constraints, the gaps between the

cost limits were significantly large and could not be reduced further. The “hard” constraints restrict the flexibility

of the activities from being moved between years and thus cause the leveling of cost to be a difficult problem to

solve.

Further work could be carried out on solving the resource leveling problem by adding the “hard” Factor 1 and

Factor 2 constraints one at a time to observe their impacts. In the Model 1 results of the 9 projects, it was

observed that the cost limit could not be lowered below 737.77 million because it was the total cost of activities

of ‘Udførsel’ phase, ‘Kørestrøm’ asset on all route sections of ‘Roskilde-Kalundborg_Elektrificering_Togfonden’,

which were guided by the Factor 2 constraint. By adding the “hard” constraints one at a time, the critical activities

that create the significant peaks in the cost profile can be observed. Moreover, the constraints that cause the

coordination principle violations can be identified. In the midst of scheduling activities from the large project

portfolio, this detailed study of impacts of each “hard” constraints would enable Banedanmark to identify the

critical activities that would cause coordination principle violations and restrict the leveling of cost.

Big M Method

The “Big M method” had caused the formulation of the models to be “very weak” which affected the

computational performance of the models in solving the problem. Further work needs to be carried out in

improving the model formulation so that the LP relaxation is closer to the optimal solution.

The models had a single value of “M” for all the coordination principle equations. Paul Rubin (Rubin, 2011), a

mathematician from Michigan State University, suggested in his blog ‘OR in an OB World’ that instead of setting

one single value of “M” for all constraints the value of “M” should differ for every constraint. The “Big M method”

should be implemented in the models in such a way that every coordination principle equation has a differed

value of “M”, which would set the equations closer to the feasible region defined by the earliest starting date

constraint (1st July 2015) and the deadline constraint (31st December 2030). However, (Rubin, 2011) and

(Richards & How, 2005) have recommended practitioners to consider alternatives to the “Big M method” that

could be more efficient. Therefore, alternative approaches should be considered to model the coordination

principle constraints.

90


Lower bounds

All the methods used in this thesis to derive lower bounds were found to be incompetent to determine the

quality of the feasible solutions. Lagrangian relaxation was not implemented successfully in this thesis and should

be further worked on. Lagrangian relaxation is said to provide strong dual (lower) bounds (Fisher, 1985) and

could be used to analyze the quality of the feasible solutions.

(Christofides, et. al., 1987) obtained lower bounds by LP relaxation and Lagrangian relaxation, and used them to

solve RCPSP by branch and bound algorithm. Therefore, the branch and bound algorithm could be considered as

an alternative to solving the IP models directly.

Predictive-Reactive scheduling model

The predictive-reactive scheduling model tested scenarios with different assumed sets of activity delays and

showed their respective impacts on the baseline schedule. The model illustrated the cost profile deviation from

the baseline schedule and the increase in coordination principle violations due to the delays. However, for the

model to be a validated as a valuable tool in anticipating the consequences of delays or other uncertainties,

precise sets of scenarios that the decision makers are interested in need to be constructed and tested. Moreover,

the objective of the model should be defined clearly.

9.3 FINAL CONCLUSION

In this thesis, two mathematical models were developed which would minimize the number of coordination

principles violated and simultaneously level the cost for all the years in the period 2015 – 2030. One of the

outputs of the models was chosen as the baseline schedule and formed the basis of the scenario analysis.

Scenarios were constructed with different sets of activity delays and their impacts on the baseline schedule were

observed using the predictive-reactive scheduling model. As mentioned in the methodology (Figure 11), the

primary focus of this thesis was on developing and analyzing the mathematical models.

Two integer programming models were implemented to solve the project scheduling problem at Banedanmark.

The objective of Model 1 was to minimize the number of coordination principles violated within the cost limit

constraints. Model 2 was set as a multi-objective optimization problem with the objective to minimize the

number of coordination principles violated and the mean absolute deviation (MAD) of the cost profile. Both the

models were tested for sets of 2-4 projects, 9 projects and 36 projects. The strengths, weaknesses and

computational running times of the models were analyzed and reported.

91


The models were examined to be computationally inefficient in solving the problem and therefore were

concluded to be impractical to optimize all the projects at Banedanmark. However, recommendations were

made on how the developed models could be utilized as a supporting tool for the decision makers in planning

the schedule of projects. Further work to improve the computational efficiency of the models were discussed.

One of the most important findings in this thesis was that the Banedanmark’s resource leveling problem was

difficult to solve due to the presence of the “hard” Factor 1 and Factor 2 constraints, which restricted the

flexibility of activities from being moved between years. Hence, the gaps between the upper and lower cost

limits were found to be significantly large. Further work to be carried out in identifying the critical activities and

the constraints that restrict the leveling of cost were discussed.

92

References

REFERENCES

1. Aswathi, R. & Thomas, C., 2013. Development of a delay analysis system for a railway construction project. International Journal of Innovative Research in Science, Engineering and Technology, 2(1), pp. 531-541.

2. Banedanamrk, 2015. [Online] Available at: http://uk.bane.dk/visArtikel_eng.asp?artikelID=1095 [Accessed March 2015].

3. Bosch, R. & Trick, M., 2005. Integer Programming. In: E. K. Burke & G. Kendall, eds. Search Methodologies. s.l.:Springer, pp. 69 - 95.

4. Bryson, J., 1995. Strategic Planning for Public and Nonprofit organizations: A Guide to strengtening and sustaining organizational achievement. San Francisco: Jossey-Bass.

5. Camm, J. D., Raturi, A. S. & Tsubakitani, S., 1990. Cutting Big M down to size. Interfaces, 20(5), pp. 61-66.

6. Christofides, N., Alvarez-Valdez, R. & Tamarit, J., 1987. Project Scheduling with resource constraints: A branch and bound approach. European Journal of Operations Research, Volume 29, pp. 262-273.

7. Coello, C. A., 1999. A comprehensive survey of evolutionary based multiobjective optimization techniques. Knowledge and Information systems, pp. 269-308.

8. Collis, D. & Rukstad, M., 2008. Can you say what your strategy is?. Harvard Business Review, Issue April, pp. 63-73.

9. De Meyer, A., Loch, C. & Tisch, M., 2002. Managing project uncertainty: from variation to chaos. MIT Sloan Management Review, pp. 60-67.

10. Fisher, M., 1973. Optimal Solution of scheduling problems using lagrange multipliers. Operations Research, Volume 21, pp. 1114 - 1127 .

11. Fisher, M. L., 1985. An Application Oriented Guide to Lagrangian Relaxation. Interfaces, 15(2), pp. 10-21.

12. Flyvbjerg, B., Holm, M. K. S. & Buhl, S. L., 2004. What causes cost overrun in transport infrastructure projects. Transport Reviews, 24(1), pp. 3-18.

13. Fung Lam, K., Ung Choo, E. & W.Moy, J., 1996. Minimizing deviations from the group mean: A new linear programming approach for the two-group classification problem. European Journal of Operattional Research, pp. 358-367.

14. Glencoe.com, 2015. [Online] Available at: http://www.glencoe.com/sites/pdfs/impact_math/ls9_c1_mean_absolute_deviation.pdf [Accessed February 2015].

93

References

15. Hanafizadeh, P., Hashemi, A. & Parvin, E. S., 2009. Robust Strategic Planning Employing Scenario Planning amd Fuzzy Inference System. International Journal of Decision Support System Technology , 1(3), pp. 21-45.

16. Hartmann, S. & Briskorn, D., 2010. A survey of variants and extensions of the resource-constrained project scheduling problem. European Journal of Operational Research, Volume 207, pp. 1-14.

17. Herroelen, W., 2004. Project Scheduling - Theory and practice, Leuven: K.U.Leuven.

18. Herroelen, W., De Reyck, B. & Demeulemeester, E., 1998. Resource-Constrained Project Scheduling: A survey of recent developments. Computers Ops Res. , 25(4), pp. 279-302.

19. Herroelen, W., Demeulemeester, E. & De Reyck, B., 1997. A classification scheme for project scheduling problems, Leuven (Belgium): Katholieke Universiteit Leuven.

20. Herroelen, W. & Leus, R., 2004. Robust and reactive project scheduling : A review and classification of procedures. International Journal of Production Research, 42(8), pp. 1599-1620.

21. Huss, W. R. & Honton, E. J., 1987. Scenario Planning - What Style Should You Use?. Long Range Planning, 20(4), pp. 21-29.

22. Icmeli, O., Erenguc, S. S. & Zappe, C., 1993. Project Scheduling Problems: A survey. Internation Journal of Operations and Production Management, 13(11), pp. 80-91.

23. Johnson, G., Whittington, R. & Scholes, K., 2012. Fundamanetals of Strategy. Essex: Pearson Education Limited.

24. Konno, H. & Koshizuka, T., 2005. Mean-absolute deviation model. IIE Transactions, Volume 37, pp. 893-900.

25. Konno, H. & Yamazaki, H., 1991. Mean-Absolute Deviation Portfolio Optimization Model and its Applications to the Tokyo Stock Market. Management Science, 37(5), pp. 519-531.

26. Kriemadis, T. & Theakou, E., 2007. Strategic Planning Models in Public and Non-profit sport organizations. Sport Management International Journal, 3(2), pp. 27-37.

27. Kurtulus, I. & Davis, E., 1982. Multi-Project scheduling: categorization of heuristic rules performance. Management Science, 28(2), pp. 161-172.

28. Liberatore, M. & Pollack-Johnson, B., 2003. Factors influencing the usage and selection of project software. IEEE Transactions on Engineering Management, 50(2), pp. 164-174.

29. Maroto, C., Tormos, P. & Lova, A., 1999. The evolution of software quality in project scheduling. In: Project Scheduling - Recent models, algorithms and applications. Boston: Kluwer Academic Publishers, p. Chapter 11.

30. Martin, R. K., 1999. Large Scale Linear and Integer Optimization: A Unifed Approach. Chicago: Kluwer Academic Publishers.

94

References

31. Mattila, K. G. & Abraham, D. M., 1998. Resource Leveling of Linear Schedules using Integer Linear Programming. Journal of Construction Engineering and Management, 124(3), pp. 232-244.

32. Mintzberg, H., 1994. The fall and rise of strategic planning. Harvard Business Review, pp. 107-114.

33. MosekApS, 2015. Mosek.com. [Online] Available at: http://docs.mosek.com/7.0/capi/The_optimizers_for_mixed-integer_problem.html [Accessed May 2015].

34. Maack, J. N., 2001. Scenario Analysis: A Tool for Task Managers. In: Social Analysis: Selected Tools and Techniques. Washington D.C: Social Development Department, The World Bank, pp. 62-87.

35. Ngatchou, P., Zarei, A. & El-Sharkawi, M., 2005. Pareto Multi Objective Optimization, Seattle: University of Washington.

36. Philips, S. & Dessouky, M., 1977. Solving the TIme/Cost trade-off problem using the minimal cut concept. Management Science, 24(4), pp. 393-400.

37. Pollack-Johnson, B. & Liberatore, M., 1998. Project management softwrae usage patterns and suggested research directions for future developments. Project Management Journal, pp. 19-28.

38. Postma, T. J. & Liebl, F., 2005. How to improve scenario analysis as a strategic management tool?. Technological Forecasting and Social Change, Volume 72, pp. 161-173.

39. Prognoz, 2015. [Online] Available at: http://www.prognoz.com/ [Accessed April 2015].

40. Richards, A. & How, J., 2005. Mixed-Integer programming for control. Portland, USA, American Control Conference.

41. Rosenthal, R. E., 2015. GAMS User Guide. [Online] Available at: http://www.gams.com/dd/docs/bigdocs/GAMSUsersGuide.pdf [Accessed February 2015].

42. Rubin, P., 2011. OR in an OB World. [Online] Available at: http://orinanobworld.blogspot.dk/2011/07/perils-of-big-m.html [Accessed May 2015].

43. Russell, R., 1986. A comparison of heuristics for scheduling projects with cash flows and resource restrictions. Management Science, 32(10), pp. 1291-1300.

44. Schneider, T. & Leslie, B., 2015. 10 Chatracteristics of a Great Strategic Plan, Seattle: Switch Point LLC.

45. Stinson, J., Davis, E. & Khumawala, B., 1978. Multiple Resource-constrained scheduling using branch and bound. AIIE Transactions, 10(3), pp. 252-259.

46. Van de Vonder, S., Demeulemeester, E. & Herroelen, W., 2007. A classificaton of predictive-reactive project scheduling procedures. Journal of Scheduling, 10(3), pp. 195-207.

95

References

47. W. Davis, E. & H. Patterson, J., 1975. A comparison of heuristics and optimum soliution in resource-constrained project scheduling. Management Science, April, 21(8), pp. 944-955.

48. Woelders, A., 2015. The Implementation of IT-Systems at Banedanmark: A Study of Two Cases, Lyngby, Denmark: Master Thesis, Technical University of Denmark, DTU Management Engineering.

49. Wolsey, L. A., 1998. Integer Programming. s.l.:John Wiley & Sons Inc..

50. YALMIP, 2015. YALMIP Wiki Tutorials. [Online] Available at: http://users.isy.liu.se/johanl/yalmip/pmwiki.php?n=Tutorials.Big-MAndConvexHulls [Accessed May 2015].

51. Yang, K. K., Talbot, F. B. & H. Patterson, J., 1992. Scheduling a project to maximize its net present value: An integer programming approach. European Journal of Operations Research, Volume 64, pp. 188-198.

SPECIAL RECOGNITION

Willy Herroelen

Professor at K.U.Leuven, Belgium

Emeritus Professor of Operations Management at the Research Centre for Operations Management of the Department of Decision Sciences and Information Management at the Faculty of Business and Economics (K.U.Leuven)

(Personal Website: http://feb.kuleuven.be/public/NDBAA49/)

(Reasearch Gate Profile: http://www.researchgate.net/profile/Willy_Herroelen)

Professor Willy Herroelen is an eminent researcher within the project scheduling community with 118

publications. Resource-Constrained project planning and scheduling is his research domain and five of his articles

were cited in this thesis (References [17] [18] [19] [20] and [46]). His survey articles were used in learning the

classifications of project scheduling problems and scheduling under non-deterministic circumstances such as the

predictive-reactive scheduling method, which were very helpful in carrying out this thesis.

96

http://feb.kuleuven.be/public/NDBAA49/

http://www.researchgate.net/profile/Willy_Herroelen

APPENDIX: C++ Code For Generating Coordination Principle Equations

APPENDIX

APPENDIX: C++ CODE FOR GENERATING COORDINATION PRINCIPLE EQUATIONS

Refer file “c++.cpp” for original code

// Method Implemented in C++ to generate coordination principle equations // main.cpp // coordinationprinciples // // Created by Shyam Sundar on 4/24/15. // Copyright (c) 2015 Shyam Sundar. All rights reserved. // Shyam Sundar Govindraja Perumal, s130496 // Master Thesis: Scheduling of Railway Infrastructure Projects at Banedanmark //-------------------------------------------------------------------------------------------------------------------------------------- #include <iostream> #include <iomanip> #include <vector> #include <fstream> #include <string> using namespace std; int main() { vector<string> project ; //Variable to hold all the projects vector<string> routesection; //Variable to hold all the route sections vector<string> asset ; //Variable to hold all the assets vector<string> phase; //Variable to hold all the phases string a,b,c,d; // Variables that are used to read-in projects, route sections, assets and phases from the excel sheet //Input of the 9 projects from Excel Sheet ifstream inputprojects("/Users/shyamsundar/Desktop/cp/9_Projects/Projects.csv"); ifstream inputroutesections("/Users/shyamsundar/Desktop/cp/9_Projects/Routesections.csv"); ifstream inputassets("/Users/shyamsundar/Desktop/cp/9_Projects/Assets.csv"); ifstream inputphases("/Users/shyamsundar/Desktop/cp/9_Projects/Phases.csv"); while(inputprojects>>a) { project.push_back(a); //Storing all the projetcs in the variable project } while(inputroutesections>>b) { routesection.push_back(b); //Storing all the route sections in the variable routesection }

97


while(inputassets>>c) { asset.push_back(c); //Storing all the assets in the variable asset } while(inputphases>>d) { phase.push_back(d); //Storing all the phases in the variable phase } //Output to text file ofstream output ("/Users/shyamsundar/Desktop/cp/9_Projects/output.txt"); //Output the relevant coordination principle equations ofstream total ("/Users/shyamsundar/Desktop/cp/9_Projects/total.txt"); //Output the total number of activity pairs under each coordination principle string iterproject, iterroutesection, iterasset, iterphase; //Variable to hold the current project, route section, asset and phase in the iteration //Variables to calculate the number of activity pairs under each coordination principle int cp1 =0; int cp2 =0; int cp3 =0; int cp4 =0; int cp5 =0; int cp6 =0; int cp7 =0; int cp8 =0; int cp9 =0; int cp10 =0; int cp11 =0; int cp12 =0; int cp13 =0; int cp14 =0; int cp15 =0; int cp16 =0; int cp17 =0; int cp18 =0; int cp19 =0; int cp20 =0; int cp21 =0; int cp22 =0; int cp23 =0; int cp24 =0; int cp25 =0; int eq =1; int si =1;

98


//Start of Method //-------------------------------------------------------------------------------------------------------------------------------------- //-------------------------------------------------------------------------------------------------------------------------------------- for(int i=0; i<project.size();i++) { iterproject = project[i]; iterroutesection = routesection[i]; iterasset = asset[i]; iterphase = phase[i]; //Coordination Principles 1,2 and 3 if((iterasset == "Broer_og_Konstruktioner")&&(iterphase=="Definition")) { //Coordination Principle 1: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Broer_og_Konstruktioner")&&(phase[k]=="Definition")) { //Printing equations for pair of activity under coordination principle 1 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','1_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','1_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','1_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','1_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','1_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','1_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','1');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 1"<<endl;

99


cp1++; } } //Coordination Principle 2: Simultaneous Start for(int k= 0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Definition")) { //Printing equations for pair of activity under coordination principle 2 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t+\t"<<"y('"<<iterroutesection<<"','2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t-\t"<<"y('"<<iterroutesection<<"','2')"<<"*(16*365);"<<endl; eq++; // cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 2"<<endl; cp2++; } //Coordination Principle 3: Simultaneous Start if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Definition")) { //Printing equations for pair of activity under coordination principle 3 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Definition')"<<"\t+\t"<<"y('"<<iterroutesection<<"','3')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Definition')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Definition')"<<"\t-\t"<<"y('"<<iterroutesection<<"','3')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"\tand\t"<<k<<"\tNeed CP 3"<<endl; cp3++; } } } //--------------------------------------------------------------------------------------------------------------------------------------

100


//Coordination Principles 4: Simultaneous if((iterasset == "Spor_og_Anlaegsarbejder")&&(iterphase=="Definition")) { for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Definition")) { //Printing equations for pair of activity under coordination principle 4 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','4_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','4_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','4_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','4_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','4_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','4_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','4');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 4"<<endl; cp4++; } } } //--------------------------------------------------------------------------------------------------------------------------------------

101


//Coordination Principles 5 and 6 if((iterasset == "Korestrom")&&(iterphase=="Definition")) { //Coordination Principle 5: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Definition")) { //Printing equations for pair of activity under coordination principle 5 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','5_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','5_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','5_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','5_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','5_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','5_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','5');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 5"<<endl; cp5++; } }

102


//Coordination Principle 6: Simultaneous for(int k=0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Staerkstrom")&&(phase[k]=="Definition")) { //Printing equations for pair of activity under coordination principle 6 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Staerkstrom','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','6_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Staerkstrom','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','6_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Staerkstrom','Definition')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','6_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Definition')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Staerkstrom','Definition')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','6_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','6_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','6_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','6');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 6"<<endl; cp6++; } } } //--------------------------------------------------------------------------------------------------------------------------------------

103


//Coordination Principles 7,8 and 9 if((iterasset == "Broer_og_Konstruktioner")&&(iterphase=="Program")) { //Coordination Principle 7: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Broer_og_Konstruktioner")&&(phase[k]=="Program")) { //Printing equations for pair of activity under coordination principle 7 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','7_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','7_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','7_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','7_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','7_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','7_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','7');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 7"<<endl; cp7++; } }

104


for(int k=0; k<project.size();k++) { //Coordination Principle 8: Simultaneous if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Program")) { //Printing equations for pair of activity under coordination principle 8 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','8_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','8_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','8_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','8_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','8_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','8_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','8');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 8"<<endl; cp8++; } //Coordination Principle 9: Simultaneous End if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Program")) { //Printing equations for pair of activity under coordination principle 9 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Program')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t+\t"<<"y('"<<iterroutesection<<"','9')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutese

105


ction<<"','Broer_og_Konstruktioner','Program')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t-\t"<<"y('"<<iterroutesection<<"','9')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"\tand\t"<<k<<"\tNeed CP 9"<<endl; cp9++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principles 10 and 11 if((iterasset == "Spor_og_Anlaegsarbejder")&&(iterphase=="Program")) { //Coordination Principle 10: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Program")) { //Printing equations for pair of activity under coordination principle 10 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','10_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','10_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','10_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','10_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','10_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','10_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','10');"<<endl; si++;

106


//cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 10"<<endl; cp10++; } } //Coordination Principle 11: Simultaneous End for(int k= 0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Program")) { //Printing equations for pair of activity under coordination principle 11 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t+\t"<<"y('"<<iterroutesection<<"','11')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Program')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t-\t"<<"y('"<<iterroutesection<<"','11')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 11"<<endl; cp11++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principle 12: Simultaneous if((iterasset == "Korestrom")&&(iterphase=="Program")) { for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Program")) { //Printing equations for pair of activity under coordination principle 12 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Program')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','12_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Program')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','12_1')"<<"*(16*365);"<<endl; eq++;

107


output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Program')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','12_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Program')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Program')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','12_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','12_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','12_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','12');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 12"<<endl; cp12++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principle 13: Before/Simultaneous if((iterasset == "Broer_og_Konstruktioner")&&(iterphase=="Projektering")) { for(int k=0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Projektering")) { //Printing equations for pair of activity under coordination principle 13 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Projektering')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Projektering')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t-

108


\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Projektering')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_3')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_2')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','13_3')" <<"\t=e=\t"<<"(3-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','13');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 13"<<endl; cp13++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principles 14, 15 and 16 if((iterasset == "Spor_og_Anlaegsarbejder")&&(iterphase=="Projektering")) { //Coordination Principle 14: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Projektering")) { //Printing equations for pair of activity under coordination principle 14 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','14_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','14_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutese

109


ction<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','14_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','14_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','14_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','14_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','14');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 14"<<endl; cp14++; } } //Coordination Principle 15: Before/Simultaneous for(int k= 0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Projektering")) { //Printing equations for pair of activity under coordination principle 15 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_2')"<<"*(16*365);"<<endl; eq++;

110


output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_3')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_2')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','15_3')" <<"\t=e=\t"<<"(3-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','15');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 15"<<endl; cp15++; } //Coordination Principle 16: Before if((iterroutesection == routesection[k])&&(asset[k]== "Sikring_og_Fjernstyring")&&(phase[k]=="Projektering")) { //Printing equations for pair of activity under coordination principle 16 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Projektering')"<<"\t+\t1"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Projektering')"<<"\t+\t"<<"y('"<<iterroutesection<<"','16')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 16"<<endl; cp16++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principle 17 and 18 if((iterasset == "Korestrom")&&(iterphase=="Projektering")) { //Coordination Principle 17: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Projektering")) { //Printing equations for pair of activity under coordination principle 17

111


output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','17_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Projektering')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','17_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Projektering')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','17_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Projektering')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Projektering')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','17_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','17_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','17_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','17');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 17"<<endl; cp17++; } } //Coordination Principle 18: Simultaneous Start for(int k=0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Sikring_og_Fjernstyring")&&(phase[k]=="Projektering")) { //Printing equations for pair of activity under coordination principle 18 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Projektering')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Projektering')"<<"\t+\t"<<"y('"<<iterroutesection<<"','18')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutese

112


ction<<"','Korestrom','Projektering')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Projektering')"<<"\t-\t"<<"y('"<<iterroutesection<<"','18')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 18"<<endl; cp18++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principles 19,20 and 21 if((iterasset == "Broer_og_Konstruktioner")&&(iterphase=="Udforsel")) { //Coordination Principle 19: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Broer_og_Konstruktioner")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 19 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','19_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','19_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','19_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','19_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','19_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<

113


<iterroutesection<<"','19_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','19');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 19"<<endl; cp19++; } } //Coordination Principle 20: Before/Simultaneous for(int k= 0; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 20 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_3')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_2')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','20_3')" <<"\t=e=\t"<<"(3-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','20');"<<endl; si++;

114


//cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 20"<<endl; cp20++; } //Coordination Principle 21: Before if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 21 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Broer_og_Konstruktioner','Udforsel')"<<"\t+\t1"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Udforsel')"<<"\t+\t"<<"y('"<<iterroutesection<<"','21')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"\tand\t"<<k<<"\tNeed CP 21"<<endl; cp21++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Princples 22, 23 and 24 if((iterasset == "Spor_og_Anlaegsarbejder")&&(iterphase=="Udforsel")) { //Coordination Principle 22: Simultaneous for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Spor_og_Anlaegsarbejder")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 22 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','22_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','22_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','22_2')"<<"*(16*365);"<<endl; eq++;

115


output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','22_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','22_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','22_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','22');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 22"<<endl; cp22++; } } for(int k= 0; k<project.size();k++) { //Coordination Principle 23: Before if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 23 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t+\t1"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Udforsel')"<<"\t+\t"<<"y('"<<iterroutesection<<"','23')"<<"*(16*365);"<<endl; eq++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 23"<<endl; cp23++; } //Coordination Principle 24: Before/Simultaneous if((iterroutesection == routesection[k])&&(asset[k]== "Sikring_og_Fjernstyring")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 24 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutese

116


ction<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Spor_og_Anlaegsarbejder','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Sikring_og_Fjernstyring','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_3')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_2')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','24_3')" <<"\t=e=\t"<<"(3-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','24');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 24"<<endl; cp24++; } } } //-------------------------------------------------------------------------------------------------------------------------------------- //Coordination Principle 25: Simultaneous if((iterasset == "Korestrom")&&(iterphase=="Udforsel")) { for(int k= i+1; k<project.size();k++) { if((iterroutesection == routesection[k])&&(asset[k]== "Korestrom")&&(phase[k]=="Udforsel")) { //Printing equations for pair of activity under coordination principle 25 output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Udforsel')"<<"\t=l=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','25_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Udforsel')"<<"\t=g=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Udforsel')"<<"\t-

117


\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','25_1')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"s('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Udforsel')"<<"\t=g=\t"<<"s('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Udforsel')"<<"\t-\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','25_2')"<<"*(16*365);"<<endl; eq++; output<<"eq"<<eq<<"(p,'"<<iterroutesection<<"',a,'"<<iterphase<<"').."<<"e('"<<iterproject<<"','"<<iterroutesection<<"','Korestrom','Udforsel')"<<"\t=l=\t"<<"e('"<<project[k]<<"','"<<routesection[k]<<"','Korestrom','Udforsel')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','25_2')"<<"*(16*365);"<<endl; eq++; output<<"si"<<si<<"('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"',sim).."<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','25_1')"<<"\t+\t"<<"x('"<<iterproject<<"','"<<project[k]<<"','"<<iterroutesection<<"','25_2')"<<"\t=e=\t"<<"(2-1)"<<"\t+\t"<<"y('"<<iterroutesection<<"','25');"<<endl; si++; //cout<<"Activity\t"<<i<<"and\t"<<k<<"\tNeed CP 25"<<endl; cp25++; } } } } // End of Method //-------------------------------------------------------------------------------------------------------------------------------------- //-------------------------------------------------------------------------------------------------------------------------------------- //Output on the number of activtiy pairs under each coordination principle total<<"Cp1:\t"<<cp1<<endl; total<<"Cp2:\t"<<cp2<<endl; total<<"Cp3:\t"<<cp3<<endl; total<<"Cp4:\t"<<cp4<<endl; total<<"Cp5:\t"<<cp5<<endl; total<<"Cp6:\t"<<cp6<<endl; total<<"Cp7:\t"<<cp7<<endl; total<<"Cp8:\t"<<cp8<<endl; total<<"Cp9:\t"<<cp9<<endl; total<<"Cp10:\t"<<cp10<<endl; total<<"Cp11:\t"<<cp11<<endl; total<<"Cp12:\t"<<cp12<<endl; total<<"Cp13:\t"<<cp13<<endl; total<<"Cp14:\t"<<cp14<<endl; total<<"Cp15:\t"<<cp15<<endl; total<<"Cp16:\t"<<cp16<<endl; total<<"Cp17:\t"<<cp17<<endl;

118


total<<"Cp18:\t"<<cp18<<endl; total<<"Cp19:\t"<<cp19<<endl; total<<"Cp20:\t"<<cp20<<endl; total<<"Cp21:\t"<<cp21<<endl; total<<"Cp22:\t"<<cp22<<endl; total<<"Cp23:\t"<<cp23<<endl; total<<"Cp24:\t"<<cp24<<endl; total<<"Cp25:\t"<<cp25<<endl; //-------------------------------------------------------------------------------------------------------------------------------------- return 0; } //-------------------------------------------------------------------------------------------------------------------------------------- //--------------------------------------------------------------------------------------------------------------------------------------

119

APPENDIX: GAMS Code Of Model 1 For 9 Projects

APPENDIX: GAMS CODE OF MODEL 1 FOR 9 PROJECTS

Refer Text File “Model_1.txt” for GAMS code of Model 1 for the 9 projects.

120

MasterThesis_s130496

Documents

Transcript of MasterThesis_s130496