a multi-objective bisexual reproduction genetic algorithm for ...

COURSE SCHEDULING IN MULTIPLE FACULTIES USING
A GRID COMPUTING ENVIRONMENT
MR. NGUYEN CONG DANH
A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
FOR THE DEGREE OF MASTER OF SCIENCE (INFORMATION TECHNOLOGY)
GRADUATE COLLEGE
KING MONGKUT'S INSTITUTE OF TECHNOLOGY NORTH BANGKOK
ACADEMIC YEAR 2005
ISBN 974-19-0543-2
COPYRIGHT OF KING MONGKUT'S INSTITUTE OF TECHNOLOGY NORTH BANGKOK

Name : Mr. Nguyen Cong Danh
Thesis Title : Course Scheduling in Multiple Faculties Using a Grid
Computing Environment
Major Field : Information Technology
King Mongkut’s Institute of Technology North Bangkok
Thesis Advisor : Assistant Professor Dr. Yaowadee Temtanapat
Academic Year : 2005
Abstract
Course scheduling for multiple faculty universities is a large and complex
problem. In these universities, each faculty desires to have its own timetable to use its
resources. However, lecturers, courses, rooms and other resources can be shared
between faculties. The data used for the course scheduling thus needs to be shared
across the university. As a result, the constraint conflicts in the timetable can occur
not only in each faculty but also across faculties. The course scheduling problem
becomes more difficult to solve. This study proposes a hybrid centralized and decentralized
approach for the course scheduling. The genetic algorithm and grid
computing environment are used. The genetic algorithm is to solve the hard and soft
constraints while grid computing environment is used as an infrastructure for
distributed and parallel computing. The results of this research indicated that the
proposed system can solve most of required constraints and the grid computing can
improve significantly computing performance of the whole system.
(Total 145 pages)
___________________________________________________________Chairperson
ii

ชื่อ : นายฮูเยน ชอง แดน
ชื่อวิทยานิพนธ : การจัดตารางสอนสําหรับมหาวิทยาลัยที่มีหลายคณะโดยใช
สภาพแวดลอมการประมวลผลแบบกริด
สาขาวิชา : เทคโนโลยีสารสนเทศ
สถาบันเทคโนโลยีพระจอมเกลาพระนครเหนือ
ที่ปรึกษาวิทยานิพนธ : ผูชวยศาสตราจารย ดร. เยาวดี เต็มธนาภัทร
ปการศึกษา : 2548
บทคัดยอ
การจัดตารางสอนสําหรับมหาวิทยาลัยที่มีหลายคณะเปนปญหาที่ใหญและซับซอน ใน
มหาวิทยาลัยเหลานี้ แตละคณะมีความตองการตารางสอนของตนเองโดยใชทรัพยากรที่ตนมีอยู
อยางไรก็ตาม อาจารย วิชา หองและทรัพยากรอื่นก็ยังสามารถที่จะถูกใชงานรวมกันได ขอมูล
สําหรับการจัดตารางสอนจึงจําเปนที่จะตองใชงานรวมกัน ผลก็คือไมใชเพียงจะเกิดความขัดแยงใน
เรื่องของเงื่อนไขของตารางสอนภายในคณะที่ได แตยังรวมไปถึงความขัดแยงของเงื่อนไขที่จะเกิด
ไดในระหวางแตละคณะดวย ทําใหปญหาการจัดตารางสอนในมหาวิทยาลัยเหลานี้จึงเพิ่มความ
ยุงยากยิ่งขึ้นไปอีก ในการศึกษานี้เราจึงนําเสนอวิธีการที่เปนการผสมระหวางการจัดตารางสอน
แบบรวมศูนยและแบบกระจาย โดยใชขั้นตอนวิธีแบบพันธุกรรมรวมกับสภาพแวดลอมการ
ประมวลผลแบบกริด ขั้นตอนวิธีแบบพันธุกรรมใชในการแกปญหาของเงื่อนไขแบบไมผอนปรน
(hard constraint) และแบบอาจผอนปรนไดบาง (soft constraint) สําหรับการประมวลผลใน
สภาพแวดลอมแบบกริดใชเปนพื้นฐานสําหรับการประมวลผลแบบกระจายและแบบขนาน ผลลัพธ
ของงานวิจัยชี้ใหเห็นวา ระบบที่นําเสนอสามารถแกปญหาของเงื่อนไขสวนใหญได และการ
ประมวลผลแบบกริดสามารถเพิ่มประสิทธิภาพการประมวลผลของทั้งระบบไดอยางเห็นไดชัด
(วิทยานิพนธมีจํานวนทั้งสิ้น 145 หนา)
_______________________________ประธานกรรมการที่ปรึกษาวิทยานิพนธ
iii

ACKNOWLEDGEMENTS
First and foremost, I would like to thank Assistant Professor Dr. Yaowadee
Temtanapat for her support and encouragement throughout my time at King
Mongkut’s Institute of Technology North Bangkok (KMITNB). I deeply appreciate
not only her intelligence, knowledge, and willingness to provide guidance for my
thesis, but also her sense of humor and her enthusiasm.
Grateful acknowledgements are addressed to Assistant Professor Dr. Utomporn
Phalavonk, Assistant Professor Dr. Phayung Meesad, Dr. Gareth Clayton, and other
members of the program committee for their valuable and constructive comments on
this thesis.
I wish to express my gratitude to all teachers, staffs at KMITNB for their
knowledge, encouragement and support during my study.
Thanks to my friends, graduate students, for their encouragement. They also
made my time at KMITNB and Thailand an enjoyable experience.
The most sincere thanks to my parents who have always been true believers and
encouraged me in the past two years.
Last but certainly not least, I am especially indebted to my scholarship provider
“DTEC” for their financial support that gave me the opportunity to study at KMITNB.
Nguyen Cong Danh
iv

TABLE OF CONTENTS
Page
Abstract (in English)
ii
Abstract (in Thai)
iii
Acknowledgements
iv
List of Tables
vii
List of Figures
viii
Chapter 1. Introduction 1
1.1 Problem Statement and Background 1
1.2 The Objectives of the Study 3
1.3 The Scope of the Study 3
1.4 The Utilizations of the Study 5
Chapter 2. Literature Review 7
2.1 The Course Scheduling Problems 7
2.2 The Related Works on Course Scheduling Problems 10
2.3 Genetic Algorithms 19
2.4 Grid Computing 24
2.5 Summary 31
Chapter 3. Methodology 33
3.1 System Development 33
3.2 Problem Definition 34
3.3 The System Boundary 36
3.4 The Proposed Course Scheduling System 37
3.5 The Database Design 40
3.6 The Proposed Genetic Algorithm 42
3.7 The System for Experiment 53
3.8 The Grid Components 54
Chapter 4. Experimental Results 61
4.1 The Data for the Experiments 61
4.2 The Experiments and Discussions 66
4.3 The Sample Results 74
v

TABLE OF CONTENTS (CONTINUED)
Page
Chapter 5. Conclusion 79
5.1 Conclusions 79
5.2 Future Works 80
References 81
Appendix A 87
Appendix B 95
Appendix C 109
Appendix D 119
Appendix E 121
Biography 145
vi

LIST OF TABLES
Table
Page
2-1 Courses taught by a department 8
2-2 Teaching assignment 9
2-3 Sample timetable 10
2-4 Tentative list of tools for grid computing 27
4-1 Courses fulfilled by each class 61
4-2 Lecturer and classroom assignment 64
4-3 Timetable created by the centralized scheduling program 74
4-4 Timetable created by the decentralized scheduling program for
Faculty of Engineering 75
4-5 Timetable created by the decentralized scheduling program for
Faculty of Science 76
A-1 Faculty 88
A-2 Department 88
A-3 Lecturer 89
A-4 Busy Time 89
A-5 Building 90
A-6 Classroom 90
A-7 Classroom group 90
A-8 Department controls classroom 91
A-9 Course 91
A-10 Program 92
A-11 Curriculum 92
A-12 Class 93
A-13 Course section 93
A-14 Timetable 94
B-1 Host names, IP addressing, and software 97
B-2 Group, user ID and password 98
B-3 Distinguished name and passphrase 98
vii

LIST OF FIGURES
Figure
Page
1-1 Shared lecturers, courses, and classrooms 1
1-2 Outline of the basic genetic algorithm 2
1-3 Sample timetable for a classroom 4
2-1 Graph of 12 events 11
2-2 Graph after coloring 11
2-3 Local optimal problem 13
2-4 Simulated annealing algorithm 14
2-5 Tabu search algorithm 16
2-6 Multi agent system 19
2-7 Encoding chromosome 20
2-8 Example of crossover 21
2-9 Example of mutation 21
2-10 Roulette wheel selection 23
2-11 Rank selection 24
2-12 Application consists of jobs: B, C, D, and E executed in parallel 25
2-13 Application consist of jobs that are networked 26
2-14 Components of Globus Toolkit 2.2 28
2-15 Simple LDAP configuration 28
2-16 Grid components: a high-level perspective 29
3-1 Shared classrooms in a multiple faculty university 35
3-2 Use case diagram of the course scheduling system 36
3-3 Proposed system 38
3-4 System architecture 39
3-5 Entity relation diagram 41
3-6 High level representation of the proposed genetic algorithm 42
3-7 Sub-timetable of a classroom 43
3-8 Chromosome 44
3-9 Population 44
viii

LIST OF FIGURES (CONTINUED)
Figure
Page
3-10 Creating constraint data 45
3-11 Algorithm for initializing a random population 45
3-12 Pseudo code for creating a random chromosome 46
3-13 Pseudo code for checking small classroom conflicts 47
3-14 Pseudo code for checking lecturer’s busy time 47
3-15 Pseudo code for detecting conflicts about preferable times 48
3-16 Pseudo code for checking conflicts about double scheduled lecturers 48
3-17 Pseudo code for checking conflicts about double scheduled classes 49
3-18 Pseudo code for checking conflicts about double scheduled courses 49
3-19 Crossover 50
3-20 Pseudo code for crossover 51
3-21 Mutation 52
3-22 Pseudo code for mutating a chromosome 52
3-23 Hardware and software for each machine 53
3-24 MDS configuration 54
3-25 Working with a broker 55
3-26 Centralized scheduling 56
3-27 Job scheduler for the grid computing environment 57
3-28 Overview of GRAM and GASS 58
4-1 The average fitness value of hard constraints vs various weights 67
4-2 The average fitness value of soft constraints vs various weights 68
4-3 The average execution time for a resultant solution vs population sizes 69
4-4 The GA with various mutation rates 71
4-5 The execution time versus various models 72
4-6 Parallel execution versus serial execution 73
C-1 Visual-grid-proxy-init 113
C-2 Service configuration 115
C-3 Result in the web browser 117
ix

CHAPTER 1
INTRODUCTION
1.1 Problem Statement and Background
1.1.1 Problem Statement
Course scheduling problems are very common, but very difficult to solve in
practice. They are known as constraint optimization problems, NP hard problems,
these are concerned with the allocations, subject to constraints of given resources to
objects in space and time in such a way as to satisfy a possible set of desirable
objectives [1, 2, 3]. Courses will be scheduled to time and classrooms so that lecturers
can teach and students can attend these courses without any conflicts. A large number
of researches have been carried out on these problems [1, 2, 3]. However, most of the
researches have focused on solving the problems of universities without the
separation of resources between faculties. The course scheduling for a multiple
faculty university still needs more researches [4, 5].
Faculty 1
Lecturers Classrooms
Courses Timetable
Faculty 2
Lecturers Classrooms
Courses Timetable
Shared lecturers, courses, and classrooms
Faculty n
Lecturers Classrooms
Courses Timetable
FIGURE 1-1 Shared lecturers, courses, and classrooms
The course scheduling will become more complex in a multiple faculty
university where each faculty has its own resources such as lecturers, courses, and
classrooms, as illustrated in Figure 1-1. Moreover, these resources can be shared
between faculties. The lecturers working in a faculty can teach courses of other
faculties. The courses can be attended by students who come from different faculties.

2
The classrooms are sometime shared between faculties. Each faculty needs its own
timetable for its own resources. As a result, many problems still exist in the course
scheduling related to the shared resources.
Course scheduling itself contains a large number of conflicts and needs a large
amount of processing time. For course scheduling in the multiple faculties, the data
used for scheduling also needs to be collected and shared across the faculties. This
study proposes a hybrid centralized and de-centralized approach, genetic algorithm,
and grid computing environment to the course scheduling problem in multiple faculty
universities. The proposed approach and the genetic algorithm are used to solve the
NP hard problems. In addition, the grid computing environment is used as
infrastructure for distributed and parallel computing.
1.1.2 Background
The genetic algorithm (GA) is a global search optimization algorithm using
parallel points. While searching for solutions, the GA uses a fitness function that
affects the direction of the search [6]. The GA evaluates the population by using
genetic operators such as selection, crossover, and mutation. The outline of the basic
GA is presented in Figure 1-2.
1 [Start] Generate random population of n chromosomes.
2 [Fitness] Evaluate the fitness f(x) of each chromosome x in the population.
3 [New population] Create a new population by repeating following steps until the new population is
complete.
3.1 [Selection] Select two parent chromosomes from a population according to their fitness (the better
fitness, the bigger chance to be selected).
3.2 [Crossover] With a crossover rate cross over the parents to form new offspring (children). If no
crossover was performed, offspring is the exact copy of parents.
3.3 [Mutation] With a mutation rate mutate new offspring at each locus (position in chromosome).
3.4 [Accepting] Place new offspring in the new population.
4 [Replace] Use new generated population for a further run of the algorithm.
5 [Test] If the end condition is satisfied, stop, and return the best solution in current population.
6 [Loop] Go to step 2.
FIGURE 1-2 Outline of the basic genetic algorithm [6]

3
The GA is based on the principle of survival of the fittest members of the
population to produce the solution. The selected individual according to the fitness
level of the problem domain creates the set of solutions. The GA is an iterative
process that is repeated until the convergence criterion is satisfied.
Grid computing, most simply stated, is distributed computing. The goal is to
create the illusion of a simple yet large and powerful self-managing virtual computer
out of a large collection of connected heterogeneous systems sharing various
combinations of resources [7].
Not all applications are suitable for the use of the grid computing. We need to
look at considerations for an application to run in a grid environment where resources
are dynamically allocated based on actual needs. Normally, an application consists of
jobs that can be executed in parallel, serial, and networked. If an application consists
of several jobs that can be executed in parallel, a grid may be very suitable for
effective execution on dedicated nodes, especially in the case when there is no or a
very limited exchange of data among the jobs [8].
1.2 The Objectives of the Study
The objectives of this study can be defined as follows:
1.2.1 To provide a system that helps multiple faculty universities solve their
course scheduling problems.
1.2.2 To investigate the use of the proposed GA and the grid computing
environment to the course scheduling problem in multiple faculty universities.
1.3 The Scope of the Study
The scope of this study can be defined as follows:
1.3.1 The system must satisfy the following hard constraints:
1.3.1.1 Every course must be scheduled exactly once in a week.
1.3.1.2 For courses at each faculty, values assigned to days in a week are
Monday, Tuesday, Wednesday, Thursday, and Friday. In addition, 8 time-slots is used
in a day. Hours are assigned to time-slots are 08:00-12:00 and 13:00-17:00. No
course is scheduled cross morning and afternoon working sessions. Figure 1-3
presents a sample timetable for a classroom.

4
Classroom i
Time-slot Hour Mon Tue Wed Thu Fri
0 08:00-09:00 Course 1 Course 3 Course 15
1 09:00-10:00 Course 1 Course 4 Course 3 Course 15
2 10:00-11:00 Course 1 Course 4 Course 2 Course 15
3 11:00-12:00 Course 2 Course 15
4 13:00-14:00 Course 8 Course 5 Course 6 Course 7
5 14:00-15:00 Course 8 Course 5 Course 6 Course 7
6 15:00-16:00 Course 13 Course 5 Course 19 Course 7
7 16:00-17:00 Course 13 Course 19 Course 7
FIGURE 1-3 Sample timetable for a classroom
1.3.1.3 Neither a class nor a lecturer nor a classroom is assigned to more
than one course at the same time.
1.3.1.4 Each course must be booked to a classroom that is large enough to
hold students of that course.
1.3.1.5 In each semester, each class of students studies from list of
courses in the curriculum. All these courses have to be scheduled to different times in
each week so that all students in that class can attend.
1.3.1.6 If a course is attended by students who come from different
classes, it has to be scheduled so that these students can attended this course and their
other courses without any time conflicts.
1.3.1.7 Each lecturer can teach courses in his/her faculty and other
faculties.
1.3.1.8 Lecturers can require some unavoidable working-sessions in a
week. For instance, Dr. Tim cannot teach on Monday morning because of a weekly
meeting. Therefore, his courses must be scheduled at another time.
1.3.1.9 Each course must be booked to a classroom of a designated
classroom group.
1.3.2 The system tries to satisfy as much as possible the following soft
constraint:
The system avoids booking lecturers’ courses to their undesired time.

5
Unlike the hard constraint in section 1.3.1.8 that the system must satisfy it, the
soft constraint will be satisfied as much as possible. Several conflicts of this soft
constraint in the resultant solution are acceptable.
All hard and soft constraints are applied to all timetables in all faculties.
1.3.3 The Globus Toolkit 2.2 is used as middleware to implement the grid
computing environment [7, 8].
1.3.4 The efficiency of the proposed GA and the grid computing environment
will be evaluated and discussed on the following.
1.3.4.1 The suitability of the proposed GA against the hard constraints
and soft constraints.
1.3.4.2 Performance measurement of using the grid computing vs. not
using grid computing.
1.4 The Utilizations of the Study
1.4.1 To provide a system that helps multiple faculty universities to resolve their
course scheduling problems.
1.4.2 To investigate the efficiency of using a genetic algorithm and grid
computing to the course scheduling problem in a multiple faculty university.

CHAPTER 2
LITERATURE REVIEW
In this chapter, course scheduling problems, related works, genetic algorithms,
and grid computing are reviewed. Section 2.1 describes the activities that are to
prepare data for the course scheduling. Section 2.2 describes the related works,
including existing researches. Section 2.3 presents the basic knowledge about genetic
algorithms. And finally, section 2.4 presents knowledge about grid computing and the
Globus Toolkit 2.2.
2.1 The Course Scheduling Problems
Course scheduling is a part of a general scheduling problem. It deals with the
satisfactory allocation of resources over time to achieve an organization’s tasks. It is a
decision-making process with the intention of optimizing one or more objectives.
In any optimization problem, there are objectives, decisions to make, available
resources and related constraints. In the course scheduling problem, available
resources are lecturers, students, courses, classrooms, and time periods. A solution
must group these resources together to create a timetable that satisfies the constraints.
There are two types of constraints: hard constraints and soft constraints. Hard
constraints are conditions that must be satisfied, such as no two distinct courses can
be held at the same time and the same classroom. Soft constraints, however, may be
violated, but should be satisfied as much as possible, such as some lecturers dislike
teaching at certain times.
Course scheduling systems are usually quite varied at each university. This is
based on a set of hard and soft constraints as well as requirements about the
management at each university. This section introduces the activities needed for a
basic course scheduling problem. A particular course scheduling system is introduced
in detail in chapter 3.

8
2.1.1 General Activities for Course Scheduling
Each university usually has a central course scheduling office where
experienced staffs are working. In each department of the faculties, several staffs also
have similar responsibilities. The course scheduling activities will need the
cooperation of all these staffs.
2.1.2 The Activities of Staffs in Departments of Each Faculty
Each department has the responsibilities of teaching many courses. To prepare
the data for course scheduling, each department has to make a teaching plan. The
departments have to know the list of courses and corresponding classes that will study
these courses. The departments will make an assignment based on their own resources
such as lecturers and classrooms. The resources that concern the lecturers are
sometime subject to change. For instance, some lecturers are in training or feel bored
if teaching the same course every semester. Some courses sometime need lecturers
from other faculties. Table 2-1 shows an example of courses taught by a department.
TABLE 2-1 Courses taught by a department
Course Class Number of
Students
Section Lecturer Classroom
Group
CSC211 BSCS04A 30
CSC211 BSCS05B 35
CSC221 BSCS04A 30
CSC210 BSCS04A 30
CSC110 BSCS04A 30
CSC113 BSCS04A 30
CSC113 BSCS04B 35
In this case, a class is a group of students who study the same program and have
the same enrolment year. A classroom group is a group of classrooms that have the
same function. A course will be scheduled to a classroom of a designed classroom
group. Of course, each department knows how many students will study a particular
course. This helps the department separate the courses into a suitable number of
sections. A section with too many students usually makes it difficult for a lecturer to

9
teach effectively. However, in some cases, if the department does not have enough
classrooms or lecturers, a section with a large number of students is acceptable.
Finally, an assignment is created for each department, as shown in Table 2-2.
TABLE 2-2 Teaching assignment
Course Class Number of
Students
Section Lecturer Classroom
Group
CSC211 BSCS04A 30 1 00020 CSCCOMLB
CSC211 BSCS05B 35 2 00020 CSCCOMLB
CSC221 BSCS04A 30 1 00012 CSCLECRM
CSC210 BSCS04A 30 1 00012 CSCLECRM
CSC110 BSCS04A 30 1 00015 CSCLECRM
CSC113 BSCS04A 30 1 00023 CSCCOMLB
CSC113 BSCS04B 35 1 00023 CSCCOMLB
In Table 2-2, course CSC211 is studied by two different classes: BSCS04A and
BSCS05B, and it is divided into two distinct sections: 1 and 2. On the other hand,
course CSC113 is also studied by two different classes: BSCS04A and BSCS05B, but
both are mixed to study the same section. CSC211 and CSC113 use classrooms in
group CSCCOMLB whereas CSC221, CSC210, and CSC110 use classrooms in group
CSCLECRM.
2.1.3 Activities of Staffs at the Central Course Scheduling Office
After the central course scheduling office receives all data from the departments,
they will run the course scheduling system to create a timetable. Booking sections of
courses to time-slots in the timetable is a hard job. Its complexity depends on the
complexity of the constraints and rules of each university. The Table 2-3 presents a
sample timetable.
The timetable has to satisfy the constraints. Lecturers who teach several sections
have to be scheduled so that they can teach their sections without any time conflict.
One classroom cannot hold more than one section at the same time. Once a class

10
studies many different courses, these courses also have to be scheduled to different
times. The other constraints are also satisfied.
TABLE 2-3 Sample timetable
Course Section Time Day Classroom Lecturer
CSC211 1 13:00-16:00 W B304A01 00020
CSC211 2 8:00-11:00 W B304A01 00020
CSC221 1 10:00-12:00 T B304A05 00012
CSC210 1 13:00-16:00 M B304A02 00012
CSC110 1 9:00-12:00 F B304A02 00015
CSC113 1 13:00-16:00 T B304A05 00023
2.2 The Related Works on Course Scheduling Problems
Course scheduling is a multi-dimensional NP-Complete problem that has
generated hundreds of papers and thousands of researchers who have attempted to
solve this problem. In this section, we discuss some of the primary approaches that
have been applied to general course scheduling problems, scheduling for courses and
exams. In practice, the main idea used for the course scheduling can be applied to
exam scheduling and vice versa. The approaches can be divided into four groups:
sequential methods, cluster methods, constraint based methods, and meta-heuristic
methods [9].
2.2.1 Sequential Methods
Sequential methods order the events for scheduling using heuristics (often graph
coloring heuristics). They assign the ordered events to valid time periods so that no
events in the period are in conflict with each other, i.e. two events which require the
same resource are not scheduled in the same time period [10].
The graph coloring approach usually presents events as different vertices with
an edge between the two vertices where two respective events conflict in some way.
The graph coloring is the process of allocating different colors to each vertex so that
no two adjacent (conflicting) vertices have the same color.

11
The set of vertexes are considered as the set of classes and the edges
corresponding to courses that conflict with each other. For instance, the courses are in
conflict with each other if there is a student who must be in both courses at the same
time. Then, coloring the graph is to assign courses to appropriate periods such that
conflicts are avoided [11].
FIGURE 2-1 Graph of 12 events
The final result of coloring can be presented by a three color graph (denoted by
three different shapes), shown in Figure 2-2.
FIGURE 2-2 Graph after coloring
This result means that the timetable may be constructed in three periods, one
period per color. For larger timetables or graphs this is much less likely to be the case,
since the graph coloring problem is NP-complete. Many researches used a heuristic
algorithm to find a reasonable coloring if not an optimal one [12-13].

12
2.2.2 Cluster methods
Cluster methods split the set of events into groups which are conflict-free and
then assign the groups to the time periods to fulfill the other constraints imposed on
the scheduling problem [14]. This technique can also be applied to schedule courses
or exams. The multiphase exam scheduling package described by Arani et al. consists
of three phases [15]. In the first phase, clusters of exams are formed with the aim of
minimizing the number of students with simultaneous exams. In the second phase,
these clusters are assigned to exam days while minimizing the number of students
with two or more exams per day. Finally the exam days and clusters are arranged to
minimize the number of students with consecutive exams.
The main drawback of these approaches is that the clusters of events are formed
and fixed at the beginning of the algorithm and that may result in a poor quality
timetable.
2.2.3 Constraint Based Methods
A constraint satisfaction problem (CSP) can be expressed in the following form.
Given a set of variables, a set of possible values that can be assigned to each variable,
and a list of constraints, the CSP will find end values of the variables that satisfy
every constraint. For example, given x = {x 1 , x 2 , x 3 }, possible values of x 1 , x 2 , and x 3
in [0..100], find x 1 , x 2 , and x 3 so that they satisfy constraints: x 1 ≠ x 2 , 2x 1 =10x 2 + x 3 ,
and x 1 x 2 < x 3 .
Constraint based approaches model a course scheduling problem as a set of
variables (i.e. courses) to which values (i.e. resources such as classrooms and time
periods) have to be assigned to satisfy a number of constraints (i.e. classroom sizes
and contiguous periods) [16-18].
Constraint Logic Programming (CLP) is usually used for CSP. A labeling
strategy dictates the order in which the search space is traversed, which is vital for an
effective search. There are two orderings. The first order in which the variables are
instantiated (i.e. courses placed), and the second order in which the values (i.e. times
and classrooms) are assigned. Programming languages such as PROLOG, LISP, C,
and C++ can be used to CLP.

13
Gueret et al. have implemented a lecture scheduling system in CHIP called
FELIAC [19]. CHIP is a Constraint Logic Programming language based on Prolog,
which provides several types of constraints. CHIP’s new “cumulative” constraints
limit the amount of a resource which can be used at any time, and Gueret et al. uses
this to implement the classroom capacity constraint. Longest courses are scheduled
first in the day which has the shortest total length of clashing lectures. Relaxation of
constraints is essential for highly constrained CSPs of the course scheduling. (A
problem in which constraints may be relaxed is called a dynamic CSP.) For each
failed assignment, FELIAC stores a “justification”, which identifies the constraints
which the assignment violated. These justifications are used to undo the effects of a
constraint when it is relaxed.
Using the CLP for the course scheduling usually brings advantages such as
short programs and fast execution time.
2.2.4 Meta-heuristic Methods
Over the last two decades a variety of meta-heuristic approaches such as
simulated annealing, tabu search, genetic algorithms, and hybrid approaches have
been investigated for the course scheduling problem. Meta-heuristic methods begin
with one or more initial solutions and employ search strategies that try to avoid local
optima. All of these search algorithms can produce high quality solutions but often
have a considerable computational cost [20-25].
FIGURE 2-3 Local optimal problem

14
2.2.4.1 Simulated Annealing
Simulated annealing (SA) is a Monte-Carlo technique which can be used to find
solutions for optimization problems. The technique simulates the cooling of a
collection of hot vibrating atoms.
The approach comprises of the following:
• A cost function E that associates Energy with the state of the system.
• A ''temperature'' T that decreases slowly
• Various ways to change the state of the system.
Figure 2-4 presents the SA algorithm.
1. Generate an initial timetable s.
2. Set the initial best timetable s* = s.
3. Compute cost of s: C(s).
4. Compute initial temperature T 0 .
5. Set the temperature T = T 0 .
6. While stop criterion is not satisfied do:
a. Repeat Markov chain length (M) times:
i. Select a random neighbor s’ to the cu rrent timetable, (s’ Ns).
ii. Set Δ(C) = C(s’) − C(s).
iii. If (Δ(C) > 0 {downhill move}):
• Set s = s’.
• If C(s) < C(s*) then set s* = s.
iv. If (Δ(C)
> 0 {uphill move}):
• Choose a random number r uniformly from [0; 1].
• If r < e −Δ (C)/T then set s = s’
b. Reduce (or update) temperature T.
7. Return the timetable s*.
FIGURE 2-4 Simulated annealing algorithm
The temperature would increase the cost by Δ(C). Also, s is the current schedule
and s’ is a neighboring schedule obtained from the current neighborhood space (Ns)
by swapping two courses in time and/or space.

15
When the atoms are at a high temperature they are free to move around, and
tend to move with random displacements. However, as the mass cools the interparticle
bonds force the atoms together. When the mass is cool, no movement is
possible, and the configuration is frozen. If the mass is cooled quickly then chance of
obtaining a low cost solution is lower than if it is cooled slowly (or annealed). At any
given temperature a new configuration of atoms is accepted if the system energy is
lowered. However, if the energy is higher, then the configuration is accepted only if
the probability of such an increase is lower than that expected at the given
temperature [26-27].
The SA algorithm has both advantages and disadvantages compared to other
global optimization techniques. It is an extremely popular method and appears
competitive with many of the best heuristics in solving large problems such as course
scheduling, job scheduling, etc. However, it has two drawbacks: one being trapped by
local minima or two taking too long to find a reasonable solution. In order to
overcome these drawbacks, many recent researches combine using SA with other
heuristics such as the genetic algorithms or implemented SA as parallel algorithms.
The main aim is to avoid local minima traps and/or to have faster convergence [28-
29].
2.2.4.2 Tabu Search
Tabu search is a meta-heuristic that guides a local heuristic search procedure to
explore the solution space beyond local optimality. Tabu search has been applied
successfully in a number of combinatorial optimization problems, in particular course
scheduling [30-31].
The basic concept of tabu search as described by Glover is as: “A meta-heuristic
superimposed on another heuristic. The overall approach is to avoid entrainment in
cycles by forbidding or penalizing moves which take the solution, in the next iteration,
to points in the solution space previously visited (“tabu”)” [32].
Tabu Search is a typical local search that explores its neighborhood for a
transformed solution (s’) that can be obtained by a simple local change. Each time
that a solution is entered is known as a move. In simple cases, every move is added
into a tabu list that remembers the N recent moves taken, where N is the size of the
tabu list. A tabu list acts as a short-term memory (like a first in first out) that

16
remembers the N recent moves. Any new move that is already in the tabu list is
avoided, that is, a tabu. This approach prevents the recently tried movements and
prevents the search from cycling round the local optimal area thus driving the search
towards a different direction in the search space, resulting in better opportunity
towards global optimal.
The decision to move to a transformed solution state is usually based on the
steepest descent or mildest ascent in the objective function value. With this strategy, a
heuristic accepts a marginal and temporary deterioration in its objective function
value in exchange for opportunities to escape from a local optimal and move towards
the global optimal, as illustrated in Figure 2-3. Figure 2-5 presents the tabu search
algorithm.
1. Generate an initially random but feasible solution s.
2. Repeat:
i. Attempt to find an improved feasible solution s' with the objective function
value z(s'), avoid using moves already stored in the tabu list.
ii. Compute the moves from s to s’.
iii. Update tabu list by adding the latest move so that it is set as a tabu for some subsequent
moves.
iv. If z(s') < z(s) + (mildest ascent tolerance) then
perform exchanges: s := s', z(s) := z(s')
End if
Until (no improved solution is found) or (stopping criteria is met)
FIGURE 2-5 Tabu search algorithm
Result z(s') is the best estimated minimum, it does not guarantee to find the
global minimum but stands a better chance as compared to gradient descent approach.
2.2.4.3 Genetic Algorithms
The idea of genetic algorithms is based on the evolutionary principle developed
by Darwin [6]. A “population” of feasible timetables is maintained. The “fittest”
timetables are selected to form the basis of the next iteration, or “generation”, thus
improving the overall fitness whilst maintaining diversity.

17
The outline of the basic genetic algorithm is presented in section 1.1.2.
At present, a large number of researches have used the GAs for course
scheduling. The difference of the proposed GAs depends on representing
chromosomes and populations, setting up GAs parameters (population size, crossover
rate, and mutation rate), designing strategies in selection, crossover, and mutation, and
evaluating the fitness function.
The chromosome represents a timetable that is a solution. It can be represented
directly or indirectly. In the former, the timetable is usually a long bit string of
encoding, that stands for when and where each course takes place [33]. Thus, pairs of
selected timetables may be “crossed over” by cutting and splicing the bit strings to
create a new timetable. On the other hand, in the later, the timetable can be
represented by using a data structure such as a multi-dimension array or a linked list.
The indirect representation brings the advantage of processing time and simple GA
operations. However, it needs complex processing to exchange and maintain
constraints between the bit string and real timetable. In contrast, the direct
representation needs more processing time for GA operations, but it is easy to
maintain a large number of constraints for a real timetable. More details of the GAs
will be presented in section 2.3.
2.2.4.4 Hybrid Approaches
The above approaches have been proved that they can create good solutions for
course scheduling problems. However, as above mentioned, they usually need a long
computational time. In order to overcome this problem, many researchers have used
hybrid approaches.
Tuan et al. have successfully combined constraint programming and simulated
annealing for the problem of exam scheduling with real data sets [34]. The proposed
algorithm consists of two phases. A constraint programming phase is to provide an
initial solution. This solution is improved by the simulated annealing phase. Tuan et
al. have applied Kempe chain as neighborhood structure, a special technique for
determining starting temperature T 0 and a mechanism that allows the user to define a
certain period of time in which the algorithm should run. The mentioned mechanism
not only helps to increase the efficiency of the SA algorithm but also makes simulated
annealing experiments easier.

18
Alkan et al. have developed a Memetic Algorithms (MAs) by combining GAs
and local search techniques, hill climbing [1]. This approach has achieved good
computational performance. The idea behind hill climbing approach is to create a hill
climbing method for each type of constraint and combine them under a single hill
climbing method, denoted as AHC. Starting from a high resolution, select a constraint
type based hill climbing method by using a selection method, giving a higher chance
to an operator of the related constraint type causing more violations. There are 3
improvement strategies. First of all, invoke the selected operator for the related type
of constraints, producing a new individual. Second, if this attempt does not make any
improvement on the old one, ignore the new individual. Depending on the constraint
type, a selected block of genes, possibly causing more violations among the other
blocks, are attempted to be corrected. Finally, if this attempt also fails to produce a
better individual, then using the old one, a selected single gene in a block of genes,
possibly causing more violations, is attempted to be corrected. If the fitness of an
individual improves in any case, AHC is reapplied on it.
Some other researchers have also used distributed and parallel computing
models for course scheduling problem. One of them is the Multi Agent System model,
which has mentioned to problems that are similar to our study.
The Multi Agent System (MAS) model has been introduced to the course
scheduling problem by Kaplansky et al. [35]. The architecture is composed of a set of
autonomous scheduling agents (SAis) that solve the course scheduling for each
department. Each agent has its own course scheduling problem and its own goals. The
scheduling agents must coordinate these goals with the other agents in order to
achieve a solution for the whole organization that yields a better result with respect to
the global targets. To achieve a coherent and consistent global solution, the SAs make
use of a sophisticated negotiation protocol among scheduling agents that always ends
in an agreement (not ensured to be optimal). The main functionalities of this protocol
are agent to agent relation definition, a mechanism to approve a chain of request for
changes (RfC) and an electronic marketplace for bidding on preferred common timeslots.

19
As shown in Figure 2-6, first of all, the scheduling agents conduct negotiation
for global timetable. Next, the room agent (RA) adds new constraints to the SAis. The
SAis solve the modified problem and send back a new timetable.
FIGURE 2-6 Multi agent system
2.3 Genetic Algorithms
The genetic algorithms are inspired by Darwin's theory of evolution. Simply
said, problems are solved by an evolutionary process resulting in a best (fittest)
solution - in other words, the solution is evolved.
Algorithm begins with a set of solutions (represented by chromosomes) called
population. Solutions from one population are taken and used to form a new
population. This is motivated by a hope, that the new population will be better than
the old one. Solutions which are then selected to form new solutions (offspring) are
selected according to their fitness - the more suitable they are the more chances they
have to reproduce [6].
The outline of the basic genetic algorithm is presented in section 1.1.2.
2.3.1 Biological Background
2.3.1.1 Chromosome
All living organisms consist of cells. In each cell there is the same set of
chromosomes. The chromosomes are strings of DNA and serve as a model for the
whole organism. A chromosome consists of genes, blocks of DNA. Each gene
encodes a particular protein. Basically, it can be said that each gene encodes a trait,
for example color of eyes. Possible settings for a trait (e.g. blue, brown) are called
alleles. Each gene has its own position in the chromosome. This position is called
locus.

20
Complete set of genetic material (all chromosomes) is called genome. Particular
set of genes in genome is called a genotype. The genotype with later development
after birth is the base for the organism's phenotype, its physical and mental
characteristics, such as eye color, intelligence, etc.
2.3.1.2 Reproduction
During reproduction, recombination (or crossover) first occurs. Genes from
parents combine to form a whole new chromosome. The newly created offspring can
then be mutated. Mutation means that the elements of DNA are a bit changed. These
changes are mainly caused by errors in copying genes from parents.
The fitness of an organism is measured by success of the organism in its life
(survival).
2.3.2 Operators of GA
As presented in the outline of the basic genetic algorithm, the crossover and
mutation are the most important parts of the genetic algorithm. The performance is
influenced mainly by these two operators. Before we can explain more about
crossover and mutation, more information on chromosomes will be outlined.
A chromosome should in some way contain information about the solution that
it represents. The most common way of encoding is a binary string, as shown in
Figure 2-7.
Chromosome 1 1101100100110110
Chromosome 2 1101111000011110
FIGURE 2-7 Encoding chromosome
Each chromosome is represented by a binary string. Each bit in the string can
represent some characteristics of the solution. Another possibility is that the whole
string can represent a number. Of course, there are many other ways of encoding. The
encoding depends mainly on the solved problem. For example, one can encode
directly integer or real numbers. Sometimes it is useful to encode some permutations
and so on.

21
2.3.2.1 Crossover
After we have decided what encoding we will use, we can proceed to crossover
operation. Crossover operates on selected genes from parent chromosomes and
creates a new offspring. The simplest way of doing that is to choose at random some
crossover point and copy everything before this point from the first parent and then
copy everything after the crossover point from the other parent.
Crossover can be illustrated as in Figure 2-8 (| is the crossover point).
Chromosome 1 11011 | 00100110110
Chromosome 2 11011 | 11000011110
Offspring 1 11011 | 11000011110
Offspring 2 11011 | 00100110110
FIGURE 2-8 Example of crossover
There are other ways to make a crossover. For example, we can choose more
crossover points. Crossover can be quite complicated and depends mainly on the
encoding of chromosomes. A specific crossover made for a specific problem can
improve the performance of the genetic algorithm.
2.3.2.2 Mutation
After a crossover is performed, mutation takes place. Mutation is intended to
prevent falling of all solutions in the population into a local optimum of the solved
problem. Mutation operation randomly changes the offspring resulted from crossover.
In case of binary encoding we can switch a few randomly chosen bits from 1 to 0 or
from 0 to 1. Mutation can be then illustrated as in Figure 2-9.
Original offspring 1 1101111000011110
Original offspring 2 1101100100110110
Mutated offspring 1 1100111000011110
Mutated offspring 2 1101101100110110
FIGURE 2-9 Example of mutation

22
The technique of mutation (as well as crossover) depends mainly on the
encoding of chromosomes. For example, when we are encoding permutations,
mutation could be performed as an exchange of two genes.
2.3.3 Parameters of GA
2.3.3.1 Crossover and Mutation Rate
There are two basic parameters of a GA: crossover rate and mutation rate.
The crossover rate describes how often a crossover will be performed. If there is
no crossover, offspring are exact copies of parents. If there is crossover, offspring are
made from parts of both parent's chromosome. If crossover rate is 100%, then all
offspring are made by crossover. If it is 0%, whole new generation is made from exact
copies of chromosomes from the old population. Crossover is made in hope that new
chromosomes will contain good parts of old chromosomes and therefore the new
chromosomes will be better. However, it is good to leave some part of old population
to survive to next generation.
The mutation rate describes how often parts of chromosome will be mutated. If
there is no mutation, offspring are generated immediately after crossover (or directly
copied) without any change. If mutation is performed, one or more parts of a
chromosome are changed. If mutation rate is 100%, whole chromosome is changed, if
it is 0%, nothing is changed. Mutation generally prevents the GA from falling into
local extremes. Mutation should not occur very often because the GA will in fact
change to random search.
2.3.3.2 Other Parameters
One another important parameter is population size. Population size describes
how many chromosomes are in a population. If there are too few chromosomes, the
GA has few possibilities to perform crossover and only a small part of search space is
explored. On the other hand, if there are too many chromosomes, the GA slows down.
Research shows that after some limit (which depends mainly on encoding and the
problem) it is not useful to use very large populations because it does not solve the
problem faster than moderate sized populations.
2.3.4 Methods of Selection
As presented in the outline of the basic genetic algorithm, chromosomes are
selected from the population to be parents for crossover. The problem is how to select

23
these chromosomes. According to Darwin's theory of evolution the best ones survive
to create new offspring. There are many different methods which a GA can use to
select the chromosomes to be copied over into the next generation, but listed below
are some of the most common methods.
2.3.4.1 Roulette Wheel Selection
Parents are selected according to their fitness. The better the chromosomes are,
the more chances to be selected they have. Imagine a roulette wheel where all the
chromosomes in the population are placed. The size of the section in the roulette
wheel is proportional to the value of the fitness function of every chromosome - the
bigger the value is, the larger the section is. Figure 2-10 shows an example.
Chromosome 4
Chromosome 3
Chromosome 2
Chromosome 1
FIGURE 2-10 Roulette wheel selection
A marble is thrown on the roulette wheel and the chromosome where it stops is
selected. Clearly, the chromosomes with bigger fitness value will be selected more
times.
2.3.4.2 Rank Selection
The previous type of selection has problems when there are big differences
between the fitness values. For example, if the best chromosome fitness is 90% of the
sum of all fitness then the other chromosomes will have very few chances to be
selected.
Rank selection ranks the population first and then every chromosome receives
fitness value determined by this ranking, as shown in Figure 2-11. The worst will
have the fitness 1, the second worst 2, etc, and the best will have fitness N.
Now all the chromosomes have a chance to be selected. However this method
can lead to slower convergence, because the best chromosomes do not differ so much
from others.

24
Chromosome 4
Chromosome 3
Chromosome 2
Chromosome 1
Rank Chromosome
1 Chromosome 1
2 Chromosome 2
3 Chromosome 4
4 Chromosome 3
FIGURE 2-11 Rank selection
2.3.4.3 Steady-State Selection
The steady-state selection works in the following way. In every generation a
few good (with higher fitness) chromosomes are selected for creating new offspring.
Then some bad (with lower fitness) chromosomes are removed and the new offspring
is placed in their place. The rest of population survives to new generation.
2.3.4.4 Tournament selection
Subgroups of chromosomes are chosen from a larger population, and members
of each subgroup compete against each other. Only one chromosome from each
subgroup is chosen to reproduce [36].
2.3.4.5 Elitism Selection
Elitism is the name of the method that first copies the best chromosome (or few
best chromosomes) to the new population. The rest of the population can be
constructed in the methods described above. Elitism can rapidly increase the
performance of the GA, because it prevents a loss of the best found solution.
2.4 Grid Computing
Grid computing is a method for sharing computing and data resources. The grid
computing is used for distributed systems that shares resources over a local or wide
area network. The specific focus, that underlies grid computing, is coordinated
resource sharing in a multi-institutional environment [7-8]. It attempts to combine all
types of resources, including supercomputers and clusters of machines, from multiple
institutions, into a resource that is more powerful than any single resource.
This section will introduce grid computing in the following topics: the
application considerations, the Globus Toolkit, the Globus Toolkit 2.2 and the grid
components.

25
2.4.1 Application Considerations
If an application consists of several jobs that can all be executed in parallel, a
grid may be very suitable for effective execution on dedicated nodes, especially in the
case when there is no or a very limited exchange of data among the jobs.
From an initial job, a number of jobs are launched to execute on pre-selected or
dynamically assigned nodes within the grid. Each job may receive a discrete set of
data, and fulfills its computational task independently and delivers its output. The
output is collected by a final job or stored in a defined data store, as shown in Figure
2-12.
FIGURE 2-12 Application consists of jobs: B, C, D, and E executed in parallel
Many other applications can consist of jobs are executable in parallel, but there
are interdependences between them. For example, shown in Figure 2-13, jobs B and C
can be launched simultaneously, but they heavily exchange data with each other. Job
F cannot be launched before B and C have completed, whereas job E or D can be
launched upon completion of B or C respectively. Finally, job G finally collects all
output from the jobs D, E, and F, and its termination and results then represent the
completion of the grid application.
For such applications, a possible approach is to do more analysis to determine
how best to split the application into individual jobs, maximizing parallelism. It also
adds more dependencies on the grid infrastructure services such as schedulers and
brokers, but once that infrastructure is in place, the application can benefit from the
flexibility and utilization of the virtual computing environment. The use of a job flow

26
management service not only can handle the synchronization of the individual results,
but also can create a loose coupling between the jobs to avoid high inter-process
communication and reduces the overheads in the grid [37].
FIGURE 2-13 Application consists of jobs that are networked
2.4.2 The Globus Toolkit
In the most general case, grid resources are supposed to be geographically
distributed and to be owned by different organizations, each with proprietary policies
regarding security, resource allocation, platform maintenance, and so on. Such an
environment depends strongly upon the construction of a robust infrastructure of
fundamental services, able to smooth out mismatches between different machines,
security policies, scheduling policies, operating systems, and platforms. Besides this,
resource sharing must be highly controlled, with resource providers and consumers
clearly defining what is shared, who is allowed to share, and the conditions under
which sharing occurs. Furthermore, access to resources has to be carefully scheduled
in order to extract the maximum performance from the available resources, and
applications should have the possibility of tailoring their behavior dynamically, in
order to cope with resource failure, a highly probable event in such a variegated
context.
All these requirements can be summarized by the need to allow transparent
access to resources, as if they belonged to a single, unified “metacomputer.” There are
many grid projects worldwide aimed at achieving this ambitious goal, shown in Table
2-4. Globus Toolkit is one of the most promising: it is rapidly becoming the de facto
standard grid middleware [39]. Globus Toolkit is a joint initiative of the University of

27
Southern California, the Argonne National Lab, and the University of Chicago. It
provides an open-source set of services addressing fundamental grid issues, such as
security, information discovery, resource management, data management, and
communication. Due to its flexibility and high interoperability with the most
widespread technologies used for distributed and parallel computing, Globus Toolkit
has been chosen for our problem.
TABLE 2-4 Tentative list of tools for grid computing [37]
A bag of services giving basic software infrastructure for grid
GLOBUS development: http://www.glohus.org
LEGION
An object-based project at the University of Virginia:
http:/ilegion.virginia.edu
UNICORE
The UNiform Interface to COmputing Resources is a European
grid computing effort: http://www .unicore.org
NETSOLVE
A client/server system oriented to solve computational science
problems: http://icl.cs.utk.edu/netsolve/
CACTUS
An open-source problem-solving environment designed for
parallel computing and collaborative software development:
http://www.catcuscode.org
The next section introduces about Globus Toolkit 2.2 that will be use for our
study.
2.4.3 Globus Toolkit 2.2
The Globus Toolkit 2.2 provides [7]:
2.4.3.1 A set of basic facilities needed for grid computing, shown in Figure
2-14.

28
FIGURE 2-14 Components of Globus Toolkit 2.2
a) Security: Single sign-on, authentication, authorization, and
secure data transfer.
b) Resource Management provides support for:
- Resource allocation.
- Submitting jobs: Remotely running executable files and
receiving results.
- Managing job status and progress.
c) Data Management provides a system to transfer files among
machines in the grid and for the management of these transfers.
d) Information Services includes directory services of available
resources and their status. It provides support for collecting information in the grid
and for querying this information, based on the Lightweight Directory Access
Protocol (LDAP), shown in Figure 2-15.
FIGURE 2-15 Simple LDAP configuration [7]

29
2.4.3.2 Application Programming Interfaces (APIs) to the above facilities.
2.4.3.3 C bindings are needed to build and compile programs.
In addition to the above, which are considered the core of the toolkit, other
components are also available that complement or build on top of these facilities. For
instance, Globus provides a rapid development kit known as Commodity Grid (CoG),
which supports technologies such as Java, Python, Web services, CORBA, and so on.
2.4.4 Grid Components
This section describes high level the primary components of the grid
environment, shown in Figure 2-16. Depending on the grid design and its expected
use, some of these components may or may not be required, and in some cases they
may be combined to form a hybrid component.
FIGURE 2-16 Grid components: a high-level perspective [8]
2.4.4.1 Grid portal
The grid portal provides an interface for a user to launch applications that will
utilize the resources and services provided by the grid.
The current Globus Toolkit does not provide any services or tools to generate a
portal.
2.4.4.2 Security
A major requirement for the grid computing is security. There must be
mechanisms to provide security including authentication, authorization, and data
encryption.

30
The Grid Security Infrastructure (GSI) component of the Globus Toolkit
provides robust security mechanisms. The GSI includes an OpenSSL implementation.
It also provides a single sign-on mechanism. Therefore, once a user is authenticated, a
proxy certificate is created and used when performing actions within the grid.
2.4.4.3 Broker
Once authenticated, a user will launch the application. Based on the parameters
provided by the user, the broker will identify the available and appropriate resources
to utilize within the grid.
Though there is no broker implementation provided by Globus Toolkit, there is
an LDAP-based information service. This service is called Grid Resource Information
Service (GRIS), or more commonly the Monitoring and Discovery Service (MDS).
2.4.4.4 Scheduler
Once the resources have been identified, the next logical step is to schedule the
individual jobs to run on the individual nodes within the grid.
Globus Toolkit does not have its own job scheduler to find available resources
and automatically send jobs to suitable machines. Instead, it provides the tools and
interfaces needed to implement schedulers.
2.4.4.5 Data Management
If any data (including application modules) must be moved or made accessible
to the nodes where the application’s jobs will execute, then there needs to be a secure
and reliable method for moving files and data to various nodes within the grid.
The Globus Toolkit contains a data management component that provides such
services. This component, known as Grid Access to Secondary Storage (GASS),
includes facilities such as GridFTP. The GridFTP is built on top of the authentication
and authorization standard FTP protocol, but adds additional functions and utilizes the
GSI for user authentication and authorization.
2.4.4.6 Job and Resource Management
This component provides the services to actually launch a job on a particular
resource, check on its status, and retrieve its results when it is complete.
The Grid Resource Allocation Manager (GRAM) of Globus Toolkit provides
the services for this component.

31
2.5 Summary
The course scheduling is a part of a general scheduling problem. It schedules
courses to periods of time and classrooms so that lecturers can teach and students can
attend their courses without any conflicts.
Many researches have been carried out on course scheduling problems. The
different approaches can be divided into four groups: sequential methods, cluster
methods, constraint based methods, and meta-heuristic methods. Although they have
successfully solved the course scheduling problems, not many researches have
focused on solving the problems of the multiple faculty universities. In such
universities, conflicts can occur across faculties due to both sharing and non sharing
resources.
This study proposes a new system for multiple faculty universities. The
proposed system will apply a hybrid centralized and de-centralized approach, a GA,
and a grid computing environment. The GA is a global search optimization algorithm
using parallel points, so it is suitable and flexible to satisfy constraints in the required
timetable. The combination between the GA and the hybrid centralized and decentralized
approach is able to create solutions without any conflicts between the
resources around the university. The grid computing environment is used as
infrastructure for sharing computing and data over a local or wide area network.

CHAPTER 3
METHODOLOGY
The general course scheduling problem, objectives and scope of our study were
presented in chapter 1. This chapter presents the plan and the phases of analyzing,
designing and implementing the proposed course scheduling system.
3.1 System Development
In order to obtain the expected objectives, we will follow the six phases below:
3.1.1 Phase 1: Systems Analysis
a) To verify the requirements and the objectives of the study.
b) To choose the tools and software to be used to develop the system.
3.1.2 Phase 2: Design
a) To study the genetic algorithms and grid computing environment.
b) To specify the proposed system.
c) To design the interfaces and the module’s functions.
d) To design the database.
e) To design a prototype for connecting between users and the system.
3.1.3 Phase 3: Implementation
a) To study the genetic algorithms and grid computing environment.
b) To install the correct software to develop the system.
c) To install the database.
d) To implement the prototype for connecting between users and the
system.
e) To implement the designed modules.
3.1.4 Phase 4: Testing
a) To test the system.
b) To run a demonstration.
c) To do some evaluations on the effectiveness of the system.

34
3.1.5 Phase 5: Measurement
a) To evaluate the suitability of the proposed GA against the hard and soft
constraints.
b) To measure the performance of using grid computing vs. not using grid
computing.
3.1.6 Phase 6: Documentation
a) To write the user manuals.
b) To write reports.
3.2 Problem Definition
The more realistic the problem the more complex it is for the developers to
overcome. In the real world, course scheduling problems are very complex. For
multiple faculty universities, they are really hard jobs. Also they are strongly based on
the particular requirements of each university. This study will focus on the common
requirements of multiple faculty universities. However, the proposed system with its
solved constraints is strong enough so that not many changes are needed to obtain a
good system for a particular university.
The multiple faculty universities where we have the chance to collect data are
King Mongkut’s Institute Technology North Bangkok in Thailand and Cantho
Univesity in Vietnam. At these universities, each faculty has several departments.
Each department has its own resources that include lecturers, courses, and classrooms.
Each department desires to construct a timetable using its own resources. These
resources can also be shared by other departments in the university.
Each course that is usually divided into many sections belongs to just one
department. However, it is almost always the case that a significant part of the
curriculum of one department is provided by another department. If a course is
provided to more than one department it must be scheduled at the same time-slot on
all the departmental timetables that use this course. These courses are called shared
courses.
Similarly we have shared classrooms. Each department desires to use its own
classrooms. However, some courses sometime need to use the shared classrooms of
the faculty, common buildings or other faculties. Therefore, a group of classrooms

35
used for a particular course has to be assigned before scheduling. A course has to be
scheduled to these classrooms without any conflicts between the departments. Figure
3-1 illustrates an arrangement for the shared classrooms.
Dept1.
l
Faculty 1
Shared classrooms
Deptn. classrooms
Faculty n
Dept1. classrooms Deptm. classrooms
Shared classrooms
Common building
Shared classrooms
FIGURE 3-1 Shared classrooms in a multiple faculty university
Each department has a responsibility to teach a number of courses. Therefore, a
teaching assignment for its lecturers has to be done. Some lecturers from other
faculties are invited to teach. Now we have shared lecturers who are teaching courses
in more than one faculty.
Also we do not schedule for the individual students. However, we will handle
student problems at a class level instead. The students are divided into classes and
expected to chronologically follow their advised pre-requisites in the curriculum of
their respective program. Our responsibility is to schedule a timetable to help the
students fulfill the courses in their curriculum. We say that two courses are in conflict
with each other if they belong to the same curriculum and are scheduled at the same
time.
In many cases, a course can be attended by students who come from classes of
different departments or faculties. This means that the students who study this shared
course can have different curriculums. In any case, we have to schedule so that the
students can attend their courses.

36
All the above problems can be presented in a brief and clear way, included in
section 1.3, the set of hard and soft constraints solved in our study.
3.3 The System Boundary
The system boundary gives a brief application overview through a use case
diagram in Figure 3-2.
Assign classrooms to departments
Faculty Staff
Department Staff
Lecturer
Create classes
Create combined classes
Assign teaching
Schedule courses
View timetable
Request busy time
Request preferable time
University Information
System
Central Office Staff
FIGURE 3-2 Use case diagram of the course scheduling system
There are five actors in the use case diagram of the course scheduling system.
3.3.1 Lecturer: This is a person who can request his/her busy and preferable
times so that the course scheduling programs try to avoid these times. The lecturers
can view the timetable after it is completed.
3.3.2 Department Staff: This is a person who works in the department. The
department staff prepares classes to be scheduled. Based on the teaching plan, and the
department staff will assign lecturers to teach the courses.
3.3.3 Faculty Staff: This is a person who works in the faculty. The faculty staff
can assign the classrooms to the departments in the faculty. Each department can use
these classrooms for its courses. This allocation sometime does not need to be done
in each semester.

37
3.3.4 Central Office Staff: This is a person who works in the central office of the
university. The central office staff will activate the course scheduling system to
schedule all courses for the whole university.
3.3.5 University Information System: This is a system actor that includes a
database and a database management system. It is responsible for storing and
managing the data of the university.
3.4 The Proposed Course Scheduling System
This section presents the proposed system through a scheduling strategy and the
system architecture.
3.4.1 The Scheduling Strategy
In general, there are two approaches to the course scheduling problem, namely
centralized and de-centralized. Both approaches have their own advantages and
disadvantages.
The centralized approach uses software to schedule the timetable for the entire
of the university. This software has a global view of the problem, presenting all the
information necessary to most effectively create a timetable. Unfortunately, the size
of the problem is too big, so the course scheduling program is unable to create a good
timetable. Furthermore, the co-operation between faculties and the central scheduling
office is also a difficult problem [5].
The de-centralized approach lets each faculty schedule its own timetable using
its own resources. However, this approach rapidly becomes infeasible when there are
shared resources across faculties. This approach can only work well if the
communication between faculties is reduced to a minimum [5]. Our study proposes a
hybrid centralized and de-centralized approach. The centralized course scheduling
program only schedules for shared resources whereas the decentralized course
scheduling program schedules for the remaining resources of each faculty. The
proposed course scheduling system is shown in Figure 3-3.
The proposed system is designed to consist of jobs that are processed in parallel.
After clients at all faculties send their own data used in course scheduling to the
Central Manager Host, a client in the central office will run the course scheduling
program. In turn, the following three stages will be performed automatically.

38
Client at a
faculty
Client at the
central office
Data submission
for the course
scheduling
Job submission
for the course
scheduling
Central
Manager Host
Data and job
for execution
Execution Host
schedules for
Facuty 1
. . . .
Execution Host
schedules for
Facuty n
FIGURE 3-3 Proposed system
3.4.1.1 Stage 1
The Central Manager Host requests a job to execute the centralized course
scheduling program on a remote Execution Host to create a timetable of the shared
resources across the faculties. The result will be written into the database on the
Central Manager Host.
3.4.1.2 Stage 2
The Central Manager Host requests jobs to execute the decentralized course
scheduling program in parallel on remote Execution Hosts. In this stage, each remote
host uses the fixed timetable created in Stage 1 as an initial input, and then tries to
find a timetable for each faculty. The decentralized course scheduling program must
give results that do not conflict with the centralized scheduling output. The results
from all remote nodes will also be written into the database on the Central Manager
Host.
3.4.1.3 Stage 3
The Central Manager Host requests a job to merge the results in the database of
Central Manager Host. Finally, the entire timetable for the whole university will be
created.
We will use a genetic algorithm to develop both the centralized course
scheduling program and decentralized course scheduling program. The grid
computing environment is used as infrastructure for distributed and parallel
computing.

39
3.4.2 The System Architecture
The system can be separated into two subsystems: Front End system and Grid
system, shown in Figure 3-4.
The Front End system is based on the 3-tier architecture. This will be used by
the clients in the faculties and in the central office to prepare the data before
scheduling. It includes three components: GUIs, application program and data
storage.
By separating the system into 3 tiers, they can work independently. The
presentation tier involves the graphical user interface. The application tier consists of
the application manager. The last tier, the database tier, consists of a database and its
database management system (DBMS).
Presentation tier
Clients at the faculties
Client at the central office
Client 1 Client 2 Client n Client n+1
Application
tier
Application
Manager
Scheduling
Engine
Commodity Grid
Search available machines
Send data to machines
Send jobs to machines
Distribute job/data
Globus Grid
Environment
Node 1
Node n
Get results from jobs
submitted to the machines
Node 2
Database tier
DBMS
Results
DB
FIGURE 3-4 System architecture

40
The Grid system is only used by a client in the central office to start the
scheduling engine that then activates the grid system. The grid system is also a 3-tier
architecture of the following: Client, Commodity Grid (CoG), and Globus Grid
Environment (Grid).
The Client tier is the interface between users and the grid system. It is
responsible for receiving command to run the scheduling engine.
The CoG tier acts as an interface between the Grid and Client tier. Using the
facilities provided by the API, the CoG is able to allow secure file transfers and also
takes the responsibility of job scheduling and monitoring the status of jobs. There is
one job for centralized course scheduling, and many other jobs for decentralized
course scheduling. When a job needs to be performed, the CoG will look for available
nodes to assign it to. The Management and Discovery Service (MDS) provided by the
Globus Toolkit will provide information about the available nodes within the Grid.
Next, it checks and locates the sequence data to available machines (nodes).
Security (GSI) and reliability is important when transferring data to various nodes
within the Grid. In order to provide for such requirements, the Globus Toolkit
provides a data management component, known as Grid Access to Secondary Storage
(GASS), for secure and reliable data transfers. It uses the GridFTP protocol to
facilitate the checking and transport of data files.
The CoG tier monitors the progress of each job and polls regularly to check if
the jobs are finished. The Grid Resource Allocation Manager (GRAM) provides the
necessary services for these processes. Once compiled, the results will be stored into
the database, and their status will be shown to the Client.
3.5 The Database Design
In the database design, we present an entity relation diagram, shown in Figure
3-5. This design also helps us understand more clearly the system requirements.
Data relations between the entities in the above diagram are very important.
Since the course scheduling programs will not work directly on the database, it works
on the data structures instead. Therefore, the data and its relations need to be loaded
from the database into the corresponding data structures before scheduling. The

41
course scheduling programs have to know the data relations so that they are able to
look for enough information to satisfy the hard and soft constraints.
Building
BuildingID
Faculty
FacultyID
1
BuildingName
1
FacultyName
ClassroomGroupID
has
DeptID
has
consists
of
ClassroomGroupName
N
1 ClassroomGroup N controls M Department
1 1 1
DeptName
ClassroomID
N M
Classroom
M
ClassroomName
Seats
has
N
has
N
Course
has
semester
Curriculum
year
N M
Program 1 has N Class
ProgramID
ProgramName
NumSemesters
Semester
DayinWeek
Year
Time-slot
N
1
classID
className
enrolYear
CourseID
CourseName
Credits
Kind
takes
numStudents
hasTimeTable
consists
of
M N N
CourseSection
N
has
teaches
N
Lecturer
1
SectionNo
Semester
Year
NumStudents
has
1
N
BusyTime
LecturerID
LecturerName
DayinWeek
Working
Session
State
Gender
FIGURE 3-5 Entity relation diagram
The data dictionary is presented in Appendix A.

42
3.6 The Proposed Genetic Algorithm
This section presents the proposed genetic algorithm that includes genetic
representations, processes to create constraint data, initialize a random population,
evaluate fitness function, crossover, and mutate chromosomes. Figure 3-6 presents
the high level representation of this algorithm.
Start
Create constraint data
Initialize a random population of n chromosomes
Is fitness f(x) of
Yes
first chromosome x
satisfied
No
Delete some bad chromosomes (low fitness value)
Output
Solution
Stop
No
Population size < n
Yes
Select 2 chromosomes as parent
Crossover
Breed a new chromosome (offspring)
Mutate
Evaluate the fitness value of the offspring
Add the offspring to the population in order of fitness value
FIGURE 3-6 High level representation of the proposed genetic algorithm
To generate an optimum result, we apply the genetic algorithm to create one or
more solutions that have various fitness values. Based on comparisons, changes, and
creation of new solutions, we can choose a good solution. Of course, we can obtain a
variety of good solutions.
Shown in Figure 3-6, we will insert a new chromosome that has just mutated
into the right position in the population. The crossover and mutation operations are

43
repeated to change the population until the first chromosome of the population obtains
a good enough fitness value f(x). However, if repeated too many times, these
operations will create a large number of chromosomes that is above the preset
population size. To solve this problem, once the number of chromosomes increases up
to a critical value n, we will kill off half of the population.
3.6.1 Representations
This section defines the genetic representations of the chromosomes, the genes,
and the population.
3.6.1.1 Chromosomes
A chromosome is a solution, in our case a timetable of the university. The
timetable contains a number of sub-timetables of classrooms. Each classroom has its
own sub-timetable.
Classroom i
Hour Mon Tue Wed Thu Fri
08:00-09:00 Course 1 Course 2
09:00-10:00 Course 1 Course 2
10:00-11:00 Course 1 Course 2
11:00-12:00
13:00-14:00 Course 3
14:00-15:00 Course 3
15:00-16:00 Course 4
16:00-17:00 Course 4
FIGURE 3-7 Sub-timetable of a classroom
We use a classroom as a ‘storage space’. Courses are scheduled to the time-slots
for each classroom. This direct representation creates a visual view. Here courseis are
courses that are divided into sections. These sections are assigned to be taught by
particular lecturer and studied by a class of students. A look at the data relations in the
database, we have course → lecturer, course→ class. This is a good foundation for
checking the hard and soft constraint conflicts.
The Figure 3-8 illustrates an entire chromosome.

44
Chromosome x i
Fitness = f(x i )
Classroom n
Mon Tue Wed Thu Fri
Classroom 2
Class1
Class2
Mon
Class1
Tue Wed
Class2
Thu Fri
Classroom Class1 1
Class1 Class2 Class2
Mon Class1 Tue Wed Class2 Thu Fri
Course 1
Class1 Class3 Course 2
Class2
Course 1 Class3 Course 2
Course 1
Class3 Course 2
Class4
Class3
Class4
Course 3
Course 3
Class4
Class4
Course 4
Course 4
A gene=A time-slot
FIGURE 3-8 Chromosome
Each chromosome x i has a fitness value f(x i ). We will use this value to look for a
good chromosome (a good solution).
3.6.1.2 Genes
A gene is a time-slot in a chromosome, so there are many genes in a
chromosome. Each gene contains a 0 if no course is held at that position. On the
contrary, the gene contains a course. If changing value of the genes, we will create a
new chromosome.
3.6.1.3 Population
A population is a set of n chromosomes, or n solutions. The population is
always sorted decreasingly in the order of the chromosome’s fitness value. As a
result, the first chromosome has the highest fitness value, thus a candidate for the best
solution, as illustrated in Figure 3-9.
Chromosome x n
Fitness = f(x n )
A population
Chromosome x 2
Fitness = f(x 2 )
Chromosome x 1
Fitness = f(x 1 )
FIGURE 3-9 Population

45
3.6.2 Creating Constraint Data
Figure 3-10 presents processes to prepare data before scheduling.
User Input
Faculties
Departments
Curriculums
Classrooms
Lecturers
Courses
Classes
Assignments
Constraint data
are stored into
Data Structures
GA Parameters
GA
Timetable
FIGURE 3-10 Creating constraint data
All data, and their relations, plus the GA parameters have to be prepared before
running the GA. The data about each faculty, department, curriculum, classroom,
lecturer, course, class and teaching assignment are entered into the database by the
users. Then automatically a program module will extract and store these data into the
data structures. The list data structures are used because they are flexible for
designing the algorithms. The GA parameters such as the population size, mutation
and crossover rates, and penalty costs for the unsatisfied constraints are also prepared
as variables in the program.
3.6.3 Initializing a Random Population of Chromosomes
Start
Initialize an empty population
Population size < n
Yes
Create a random chromosome x
No
Stop
Evaluate the fitness f(x) for new chromosome x
Add the new chromosome x to the population in order of fitness
FIGURE 3-11 Algorithm for initializing a random population

46
A population is a list of n chromosomes. Starting with an empty population, one
after another we create and add new random chromosomes into this population.
A pseudo code for creating this is given in Figure 3-12.
For each course
n= number of time-slots needed for this class (= number of credits)
Repeat
Randomly select a classroom in list of classrooms that are permissible for this course
Search n free time-slots in the chosen classroom
If (n free time-slots are found)
Book the current course to these time-slots
Until (course is booked)
FIGURE 3-12 Pseudo code for creating a random chromosome
3.6.4 Evaluating Fitness Function
As represented above, each chromosome x has a fitness value f(x). In this
section, we discuss how to find f(x).
Assume that we have m hard constraints. Let Hc i denote the number of
conflicted hard constraints i, where i = 1..m. Each hard constraints i is assigned a
penalty cost Penalty_hc i . We use f 1 (x) to denote the fitness value of hard constraints.
1
f1(
x)
= Eq. 3-1
m
1+
Hc Penalty _ hc
∑
i=
1
i
Similarly assume that we have n soft constraints. Let Sc j denote the number of
conflicted soft constraints j, where j = 0..n. Each soft constraint j is assigned a penalty
cost Penalty_sc j . We use f 2 (x) to denote the fitness value of soft constraints.
∑
j=
1
j
sc j
i
1
f
2
( x)
= Eq. 3-2
n
1+
Sc Penalty _
Thus, if a chromosome has a lower number of conflicts, f 1 (x) and f 2 (x) will have
a higher fitness value. We use f(x) to denote the fitness value of the chromosome x.
f ( x)
= W ( ) ( )
Eq. 3-3
1
f1
x + W2
f
2
x

47
where W 1 and W 2 denote weights of hard and soft constraints respectively. We will
do experiments to identify suitable values for these weights.
In this study, we design a course scheduling algorithm to find solutions that
have the highest fitness value f(x). This is a heuristic search, so we will look at
solutions having high fitness value until we meet a solution whose f 1 (x) is equal to 1.
3.6.4.1 Checking Conflicts about Small Classrooms
Each course must be booked to a classroom that is large enough to hold the
students of that course.
A pseudo code for checking this is given in Figure 3-13.
Count=0
For each classroom
For each day in a week
For each time-slot in a day
If ( number of students attending the course held in the current classroom >
number of seats of the current classroom) Count =Count+1
FIGURE 3-13 Pseudo code for checking small classroom conflicts
3.6.4.2 Checking Conflicts Regarding Lecturer’s Busy Time
The courses taught by a lecturer cannot be booked to his/her busy workingsessions
in a week.
A pseudo code for checking this is given in Figure 3-14.
Count=0
For each lecturer
For each day in a week
For each time-slot in a day
For each classroom
If (the current lecturer teaching the class is held in the current classroom and at
this time-slot ) and (the current lecturer is busy at this time) Count=Count+1
FIGURE 3-14 Pseudo code for checking lecturer’s busy time

48
Lecturers register their busy time. This checking will compare their busy time
with the time that is used to book the lecturers courses. If duplicated, an error is
counted.
3.6.4.3 Checking Conflicts about Preferable Time
Some lecturers dislike teaching in some working-sessions in a week. The system
should try to avoid booking their courses to this time.
The course scheduling program tries to book lecturers’ courses in these desired
time periods. Any conflict will be counted as a soft constraint.
A pseudo code for checking this is given in Figure 3-15.
Count=0
For each lecturer
For each day in a week
For each time-slot in a day
For each classroom
If (the current lecturer teaching the class is held in the current classroom and at
this time-slot ) and (the current lecturer dislikes teaching at this time) Count=Count+1
FIGURE 3-15 Pseudo code for detecting conflicts about preferable times
3.6.4.4 Checking Conflicts about Double Booked Lecturers
A lecturer cannot teach more than one course at the same time.
A pseudo code for checking this is given in Figure 3-16.
Count=0
For each lecturer
For each day in a week
For each time-slot in a day
Booked=0
For each classroom
If (course held in this classroom is taught by the current lecturer) Booked = Booked+1
If (Booked>1) Count=Count+1
FIGURE 3-16 Pseudo code for checking conflicts about double scheduled lecturers

49
At the same time, if a lecturer is booked to teach more than one course, a
conflict will be counted.
3.6.4.5 Checking Conflicts about Double Scheduled Classes
Courses attended by the same class of students have to be scheduled to different
time so that all students of that class can attend.
A pseudo code for checking this is given in Figure 3-17.
For each class
For each day in a week
For each time-slot in a day
Count=0
For each classroom
If (the course held in the current time-slot is studied by the current class)
Count=Count+1
FIGURE 3-17 Pseudo code for checking conflicts about double scheduled classes
At the same time, a class cannot be booked to study more than one course. If
double scheduled, a conflict will be counted.
3.6.4.6 Checking Conflicts about Double Scheduled Courses
Every course must be scheduled exactly once in a week.
A pseudo code for checking this is given in Figure 3-18.
Count=0
For each course
Booked=0
For each classroom
For each day in a week
For each time-slot in a day
If (the current course is held in this time period)
Booked=Booked+1
If (Booked> the number of credits of the current course) Count=Count+1
FIGURE 3-18 Pseudo code for checking conflicts about double scheduled courses

50
A course is booked to the time-lots based on the number of its credits. In our
study, the number of credits of a course can be 1, 2, 3, or 4. We stipulate that if a
course has n credits, it will be scheduled to n straight time-slots in a day. For instance,
course MAT125 has 3 credits, so it has to be scheduled to 3 straight time-slots. In any
other case, a conflict will be counted.
3.6.5 Crossover
Two chromosomes from a population are chosen at random as mother and
father. A new offspring is generated by creating an empty chromosome, then inserting
alternately genes (time-slots) from the mother and father, as illustrated in Figure 3-19.
Classroom n
Mon Tue Wed Thu Fri
Classroom 2
Class1 Class2
Mon Class1 Tue Wed Class2 Thu Fri
Classroom
Class1
Class1 1
Class2
Class2
Mon Class1 Tue Wed Class2 Thu Fri
Class1
Class3
Class2
Course 1 Class3 Course 2
Course Class3 1 Course 2 Class4
Course Class3 1 Course 2 Class4
Class4
Class4
Course 3
Course 3
Chromosome x
(Mother)
Course 4
Course 4
Chromosome y
(Father)
Classroom n
Mon Tue Wed Thu Fri
Classroom 2
Class1 Class2
Mon Class1 Tue Wed Class2 Thu Fri
Classroom Class1
Class1 1 Class2
Class2
Mon Class1 Tue Wed Class2 Thu Fri
Class1
Class3
Class2
Course 2 Class3 Course 3
Course Class3 2 Course 3
Class4
Course Class3 2
Class4
Class4
Class4
Course 4
Course 4
New chromosome z
(Offspring)
Classroom n
Mon Tue Wed Thu Fri
Classroom 2
Class1 Class2
Mon Class1 Tue Wed Class2 Thu Fri
Classroom Class1 1
Class1 Class2
Class2
Mon Class1 Tue Wed Class2 Thu Fri
Class1
Class3
Class2
Course 2 Class3 Course 2
Course
Class3 2 Course 2 Class4
Course
Class3 2 Course 2 Course 4 Class4
Course
Class4 4
Class4
Course 3
Course 3
Course 4
Course 4
FIGURE 3-19 Crossover

51
The new offspring is created from an empty chromosome, and then it is inserted
alternately with genes from mother and father. Because a n-credit course will be
scheduled to n successive time-slots, successive time-slots have to be copied from
mother and father. To facilitate this, all time-slots of morning or afternoon working
sessions will be copied from the mother or father to the new offspring.
Usually the new offspring is not correct thus it needs to be repaired. If a course
has not been scheduled yet, it also needs to be scheduled. In the contrary, if a course
has been scheduled more than one time in a week, it has to be removed.
A pseudo code for crossover is given in Figure 3-20.
Crossover rate pc=0.5
Father x= a chromosome is chosen randomly from the population
Mother y= a chromosome is chosen randomly from the population (y≠x)
For each day in a week
For each working-session in [morning, afternoon]
For each classroom
If (random(100) < pc*100)
Copy afternoon time-slots of father x to afternoon time-slots of the new offspring z
Else
Copy morning time-slots of mother y to morning time-slots of the new offspring z
Mutate the new offspring z
Repair the new offspring z
Calculate fitness value for the new offspring z
Insert the new offspring z into the population in order of fitness value
FIGURE 3-20 Pseudo code for crossover
If the crossover rate pc is chosen to be 50%, the 50% of the genes from the
mother and 50% of the genes from father are copied to the new offspring.
3.6.6 Mutation
A new offspring that has just been created by crossover will be mutated with a
mutation rate. This is done via the following process: go through each gene and swap
its content with another gene in the same chromosome.

52
As mentioned in the previous section, a course has to be scheduled to successive
time-slots, so we have to swap the successive time-slots booked for a course with
other successive time-slots. To facilitate this, we choose all time-slots of a working
session to swap with those of another, as illustrated in Figure 3-21.
…
…
Classroom j
Mon Tue Wed Thu Fri
Chromosome x
Course 6 Course 8
Course 6 Course
Classroom i
8
Course6 Course 8
Mon Tue Wed Thu Fri
Course 1 Course 2
Course 1 Course 2
Course 1 Course 2
Course3 Course 9
Course3 Course 9
Course 3
Course 3
Course 4
Course 4
Swap contenst of 2 workingsessions
with each other
FIGURE 3-21 Mutation
A pseudo code for mutating is given in Figure 3-22.
Mutation rate pm=0.02
For each classroom
For each day in a week
For each working-session in [morning, afternoon]
If (random(100) < pm*100)
R= a classroom is chosen randomly from the classroom group that is the
same group of the current classroom
Swap all time-slots of the current working-session of the current classroom
with those of classroom R
FIGURE 3-22 Pseudo code for mutating a chromosome
Because a course is scheduled by only using classrooms in an assigned
classroom group, any swapping has to ensure to use the classrooms within this
classroom group.

53
If the mutation rate is chosen to be 2%, only 2% of the genes are swapped their
contents with others.
3.7 The System for Experiment
The Globus Toolkit 2.2 is used as middleware to develop our grid computing
environment [7, 8]. This section presents the main steps for installing and setting up
this environment.
An Ethernet LAN and three Intel Pentium machines were used to build the grid
environment. Redhat Linux 9.0 and Globus Toolkit 2.2 were installed and set up. In
Figure 3-23, we present this environment with the host names and functions of each
machine.
m2.kmitnb.ac.th
m1.kmitnb.ac.th
Output
Jobs
- Globus client
- J2sdk1.4, Java Cog Kit 1.1
- MySQL 4.0
m3.kmitnb.ac.th
- Centralized course
scheduling program
- Decentralized course
scheduling program
- Globus server
- GIIS, GRIS
- CA
- NTP server
- Decentralized course
scheduling program
- Globus server
- GRIS
FIGURE 3-23 Hardware and software for each machine
The host names are m1, m2 and m3. The machines should have a clock speed of
at least 500 Mhz, at least 128 MB of memory and at least an 8 GB hard drive.
We will configure the Monitoring and Discovery Service (MDS) to have one
Grid Information Index Service (GIIS) on machine m2, which collects the data
reported by the Grid Resource Information Servers (GRIS) on all the machines,
shown in Figure 3-24.
The GRIS servers send information about their respective servers to the GIIS.
We will use this to find the available machines. The user will be able to query the

54
GIIS from the client machine m1. The machine m2 is used as a Certificate Authority
machine.
m2.kmitnb.ac.th
m1.kmitnb.ac.th
GRIS
GIIS
Grid-info-search
GRIS
m3.kmitnb.ac.th
FIGURE 3-24 MDS configuration
The MDS is secured so that only certified users can access the GIIS and only
certified server GRISs can register to send information to the GIIS. The machine m2
is also used as a Network Time Protocol (NTP) server. We have to configure the NTP
clients for the others (m1 and m3). The NTP needs to be installed because the grid
needs the clocks on all of the machines to be synchronized.
The installation and set up process in detail is presented in Appendix B.
3.8 The Grid Components
This section introduces the following grid components: broker, scheduler, and
job and resource management.
3.8.1 Broker
The broker identifies the available resources to utilize within the grid
environment. The Globus Toolkit 2.2 does not provide a broker implementation, but it
provides the necessary functions and framework to create one through the MDS
component.
The broker will communicate via the LDAP protocol in the Globus Toolkit 2.2
with the GIIS and GRIS servers. The broker can be linked with other information

55
stored in the databases or plain files that provide the resource information, shown in
Figure 3-25.
In our study, we use a broker that uses the LDAP APIs provided by the Globus
Toolkit 2.2 to send requests to the GIIS server located on machine m2.
The complete source code for the broker is given in the file GridInfoSearch.java
in Appendix E.
m1.kmitnb.ac.th
Broker
LDAP query
m2.kmitnb.ac.th
GIIS
GRIS
Application
GRIS
GRIS
m3.kmitnb.ac.th
…
FIGURE 3-25 Working with a broker
When called, the GIIS server will return a list of available hosts within the grid.
Each host has gathered the following resource information:
- Host name
- CPU speed (MHz)
- Number of CPU(s)
- Free CPU Percentage
The list of available hosts will be sorted by the weight that measures CPU
workload.
CPU
speed
* CPU
count
* CPU
load
Weight
host
= Eq. 3-4
100
where CPU speed : CPU speed; CPU count : the number of CPU(s); and CPU load : the
current CPU workload.
The most available host will be selected to run a new job.

56
The complete source code for managing the available hosts is given in the file
AvailableHost.java in Appendix E.
3.8.2 Job Scheduler
The job scheduler schedules the individual jobs to run on the individual hosts.
Hamscher et al. [40] presented three job scheduling paradigms for a grid –
centralized, hierarchical and distributed. Our study uses a centralized scheduling
system. In addition, because the Globus Toolkit does not have its own job scheduler,
our study will propose a job scheduler.
In a centralized scheduling paradigm, a central machine acts as a resource
manager to schedule jobs to all the surrounding hosts within the grid environment.
Figure 3-26 presents the architecture of this scheduling.
Jobs
Central
scheduling
Job 1 Job 2 Job 3
Host 1 Host 2 Host 3
FIGURE 3-26 Centralized scheduling
In this scenario, the jobs are first submitted to the central scheduler that then
dispatches the jobs to the appropriate hosts. The jobs that cannot be started on a host
are normally stored in a central job queue for later start.
In our study, the central scheduling is implemented in machine m1. In addition,
there are two kinds of jobs: one is the centralized course scheduling job and two is the
decentralized course scheduling job. These jobs will be run on machine m2 and m3.
Figure 3-27 presents the proposed algorithm for the centralized scheduling.

57
Start
Request the centralized course scheduling job
to be run on a designated host
Stage 1
Wait for the results
The job fails
Yes
No
Select a job from the list of all
decentralized course scheduling jobs
Stage 2
Search a host having the lowest load
Request the decentralized course scheduling
job to be run on the searched host
All decentralized course
scheduling jobs are requested
No
Yes
All jobs were done
No
Select a job from the list of all
decentralized course scheduling jobs
Yes
End
Stage 3
Get status of the job
No
The job failed
Yes
Search a host having the lowest load
Request the failed job to be run on the searched host
FIGURE 3-27 Job scheduler for the grid computing environment
The algorithm can be divided into three stages:
3.8.2.1 Stage 1
The centralized course scheduling job is requested to be executed on a
designated host, machine m2. The system will wait for the results and resubmit if it
fails.

58
3.8.2.2 Stage 2
After the centralized course scheduling job is executed successfully, all
decentralized course scheduling jobs are requested to be executed on remote
machines: m2 and m3.
There is no exchange of data between the decentralized course scheduling jobs,
so these jobs can be requested one after another to be run in parallel in the grid.
After each job is submitted to be executed on a host, the most available host will
be updated.
3.8.2.3 Stage 3
The system monitors all the decentralized course scheduling jobs and resubmit a
job if it fails.
The complete source code for this job scheduler is given in the file
Scheduling.java in Appendix E.
3.8.3 Job and Resource Management
The job and resource management submits a job to a particular resource, queries
job status, and resubmits a job if it fails.
FIGURE 3-28 Overview of GRAM and GASS

59
The job and resource management in the Java Cog Kit is done by using the Grid
Resource Allocation Manager (GRAM) and the Grid Access to Secondary Storage
(GASS), shown in Figure 3-28.
The GRAM is a module that provides the remote execution and status
management of the execution. When a job is submitted by a client, the request is sent
to the remote host and handled by the gatekeeper daemon located in the remote host.
Then the gatekeeper creates a job manager to start and monitor the job. When the job
is finished, the job manager sends the status information back to the client and
terminates.
3.8.3.1 Job
In Globus terminology, a job is a binary executable or command to be run on a
remote resource (machine). In order to run this job, the remote server must have the
Globus Toolkit installed. The remote server is also referred as a gatekeeper.
In our case, we have two jobs that are executable programs: the centralized
course scheduling and decentralized course scheduling. Both are written in C
language. The centralized course scheduling program schedules for courses whose
lecturers are invited from other faculties and courses whose students come from other
faculties. On the other hand, the decentralized scheduling program schedules for
courses of each particular faculty that have not been scheduled yet by the centralized
course scheduling program.
3.8.3.2 The Resource Specific Language (RSL)
RSL is a language used by the clients to submit a job. All job submission
requests are described in RSL, including the executable file and condition on which it
must be executed.
The following is a sample RSL string that requests to execute the file
decentralizedscheduling.exe one time on a remote host. The directory of this file is
also identified.
&(execuatable = decentralizedscheduling.exe)
(directory = /usr/study/coursescheduling)
(arguments = facultyID)(count=1)

60
3.8.3.3 The Gatekeeper
The gatekeeper daemon builds the secure communication between the clients
and the servers. It communicates with the GRAM client and authenticates the right to
submit jobs. After authentication, gatekeeper splits and creates a job manager
delegating the authority to communicate with clients.
The Java CoG Kit provides a personal gatekeeper that can be used as a
lightweight alternative to the Globus gatekeeper. A gridmap file is used by the
gatekeeper to map the Globus credentials to local users. The gridmap file is
introduced in Appendix B.
3.8.3.4 Job manager
The job manager is created by the gatekeeper daemon as part of the job
requesting process. It provides the interfaces that control the allocation of each local
resource manager. The job manager functions are:
a) Parse the RSL.
b) Allocate job requests to the local resource managers. The local
resource manager is usually a job scheduler like PBS, LSF, or LoadLeveler. However,
our study does not use these job schedulers.
c) Send callbacks to clients, if necessary.
d) Receive the status and cancel requests from clients.
e) Send output results to clients using the GASS, if requested.
The GRAM uses the GASS for providing the mechanism to transfer the output
file from servers to clients. Some APIs are provided under the Grid Security
Infrastructure (GSI) protocol to furnish secure transfers.
The complete source code for the job submission is given in the file
GassJob.java in Appendix E.

CHAPTER 4
EXPERIMENTAL RESULTS
The system for the experiment was installed and set up as outlined in section
3.7. This chapter discusses some of the results of our genetic algorithm (GA) and the
grid computing environment. Section 4.1 presents the data used for the experiments.
Section 4.2 presents experiments and discussions. Section 4.3 presents sample results.
4.1 The Data for the Experiments
The data used for the experiments are collected from the three departments of
three different faculties: Department of English – Faculty of Education, Department
of Electrical and Computer Engineering – Faculty of Engineering, and Department of
Computer Science – Faculty of Science, in Cantho University (Vietnam). Twelve
classes will be scheduled to study 76 sections of the courses in their curriculums in
the first semester of 2006. They are Bachelor of Science in Computer Science
(BSCS04A, BSCS04B, BSCS05A, BSCS05B, BSCS06A, and BSCS06B) and
Bachelor of Science in Electrical Engineering (BSEE04A, BSEE04B, BSEE05A,
BSEE05B, BSEE06A, and BSEE06B), shown in Table 4-1.
TABLE 4-1 Courses fulfilled by each class
Class Semester Course Section Credits Number of Students
BSCS04A
5
CSC329
001
3
30
BSCS04A
5
CSC330
001
2
30
BSCS04A
5
ENL307
001
3
30
BSCS04A
5
CSC326
001
3
30
BSCS04A
5
CSC327
001
2
30
BSCS04A
5
CSC328
001
2
30
BSCS04B
5
CSC326
002
3
30
BSCS04B
5
CSC327
002
2
30
BSCS04B
5
CSC328
002
2
30
BSCS04B
5
CSC329
002
3
30

62
TABLE 4-1 (CONTINUED)
Class Semester Course Section Credits Number of Students
BSCS04B
BSCS04B
5
5
CSC330
ENL307
002
001
2
3
30
30
BSCS05A
BSCS05A
BSCS05A
BSCS05A
BSCS05A
BSCS05A
BSCS05A
3
3
3
3
3
3
3
ECE218
MAT220
CSC211
CSC215
CSC221
ECE217
CSC210
001
001
002
002
002
001
002
2
3
4
2
3
2
3
30
30
30
30
30
30
30
BSCS05B
BSCS05B
BSCS05B
BSCS05B
BSCS05B
BSCS05B
BSCS05B
3
3
3
3
3
3
3
CSC215
CSC221
ECE217
ECE218
MAT220
CSC211
CSC210
001
001
002
002
002
001
001
2
3
2
2
3
4
3
30
30
30
30
30
30
30
BSCS06A
BSCS06A
BSCS06A
BSCS06A
BSCS06A
BSCS06A
BSCS06A
1
1
1
1
1
1
1
CSC120
CSC127
ENL101
MAT125
CSC110
CSC113
CSC115
002
002
001
001
002
002
002
3
2
3
3
2
2
2
30
30
30
30
30
30
30
BSCS06B
BSCS06B
BSCS06B
BSCS06B
BSCS06B
BSCS06B
BSCS06B
1
1
1
1
1
1
1
MAT125
CSC113
CSC115
CSC120
CSC127
ENL101
CSC110
001
001
001
001
001
001
001
3
2
2
3
2
3
2
30
30
30
30
30
30
30
BSEE04A
BSEE04A
BSEE04A
5
5
5
ECE320
ECE325
ECE326
001
001
001
2
3
2
30
30
30

63
TABLE 4-1 (CONTINUED)
Class Semester Course Section Credits Number of Students
BSEE04A
BSEE04A
BSEE04A
5
5
5
ENL308
MAT322
SIE305
001
001
001
3
2
3
30
30
30
BSEE04B
BSEE04B
BSEE04B
BSEE04B
BSEE04B
BSEE04B
5
5
5
5
5
5
ECE320
ECE325
ECE326
ENL308
MAT322
SIE305
002
002
002
002
002
002
2
3
2
3
2
3
30
30
30
30
30
30
BSEE05A
BSEE05A
BSEE05A
BSEE05A
BSEE05A
BSEE05A
3
3
3
3
3
3
ECE212
MAT223
PHY241
ECE200
ECE205
ECE203
001
001
001
001
001
001
3
2
3
2
2
2
30
30
30
30
30
30
BSEE05B
BSEE05B
BSEE05B
BSEE05B
BSEE05B
BSEE05B
3
3
3
3
3
3
MAT223
PHY241
ECE200
ECE203
ECE205
ECE212
002
002
002
002
002
002
2
3
2
2
2
3
30
30
30
30
30
30
BSEE06A
BSEE06A
BSEE06A
BSEE06A
BSEE06A
BSEE06A
1
1
1
1
1
1
ENL101
MAT125
CHE103
CHE104
ECE120
ECE102
002
002
006
006
001
001
3
3
3
2
3
2
30
30
30
30
30
30
BSEE06B
BSEE06B
BSEE06B
BSEE06B
BSEE06B
BSEE06B
1
1
1
1
1
1
CHE103
CHE104
ECE102
ENL101
MAT125
ECE120
005
005
002
003
002
002
3
2
2
3
3
3
30
30
30
30
30
30

64
26 lecturers are assigned to teach courses. Classroom groups used for each
“course + section” are identified, shown in Table 4-2.
TABLE 4-2 Lecturer and classroom assignment
Course Section Lecturer Room Group
ENL101
ENL101
ENL101
001
002
003
00001
00001
00001
ENLLECRM
ENLLECRM
ENLLECRM
ENL307
001
00003
ENLLECRM
ENL308
001
00003
ENLLECRM
ENL308
002
00003
ENLLECRM
PHY241 002 00006 PHYLECRM
PHY241 001 00007 PHYLECRM
CSC110
CSC110
CSC113
CSC115
001
002
002
002
00014
00014
00014
00014
CSCLECRM
CSCLECRM
CSCCOMLB
CSCLECRM
CSC120
002
00015
CSCLECRM
CSC127
001
00015
CSCLECRM
CSC127
002
00015
CSCLECRM
CSC210
001
00015
CSCLECRM
CSC113
001
00016
CSCCOMLB
CSC115
001
00016
CSCLECRM
CSC120
001
00016
CSCLECRM
CSC211
001
00016
CSCCOMLB
CSC221
001
00017
CSCLECRM
CSC221
002
00017
CSCLECRM
CSC210
002
00018
CSCLECRM
CSC211
002
00018
CSCCOMLB
CSC215
001
00018
CSCLECRM
CSC215
002
00018
CSCLECRM
CSC326
001
00019
CSCLECRM
CSC326
002
00019
CSCLECRM
CSC327
001
00019
CSCLECRM
CSC327
002
00019
CSCLECRM

65
TABLE 4-2 (CONTINUED)
Course Section Lecturer Room Group
CSC329
CSC329
CSC330
001
002
001
00020
00020
00020
CSCLECRM
CSCLECRM
CSCLECRM
CSC328
CSC328
CSC330
001
002
002
00021
00021
00021
CSCCOMLB
CSCCOMLB
CSCLECRM
ECE120
ECE120
ECE200
ECE200
001
002
001
002
00031
00031
00031
00031
ECELECRM
ECELECRM
ECEESTLB
ECEESTLB
ECE102
ECE102
ECE205
ECE212
001
002
002
001
00032
00032
00032
00032
ECELECRM
ECELECRM
ECELECRM
ECELECRM
ECE203
ECE203
ECE205
ECE212
001
002
001
002
00033
00033
00033
00033
ECELECRM
ECELECRM
ECELECRM
ECELECRM
ECE217
ECE217
ECE218
ECE218
001
002
001
002
00034
00034
00034
00034
ECELECRM
ECELECRM
ECEDCDLB
ECEDCDLB
ECE320
ECE320
ECE325
ECE325
001
002
001
002
00035
00035
00035
00035
ECELECRM
ECELECRM
ECELECRM
ECELECRM
ECE326
ECE326
001
002
00036
00036
ECEELCLB
ECEELCLB
SIE305 001 00046 SIELECRM
SIE305 002 00047 SIELECRM
MAT125
MAT125
001
002
00059
00059
MATLECRM
MATLECRM
MAT220
MAT220
MAT223
001
002
001
00061
00061
00061
MATLECRM
MATLECRM
MATLECRM

66
TABLE 4-2 (CONTINUED)
Course Section Lecturer Room Group
MAT223 002 00061 MATLECRM
MAT322
MAT322
001
002
00063
00063
MATLECRM
MATLECRM
CHE103
CHE103
005
006
00071
00071
CHELECRM
CHELECRM
CHE104 005 00072 CHEFTCLB
CHE104 006 00073 CHEFTCLB
Similarly, constraints about classroom size and lecturer’s time are also prepared.
4.2 The Experiments and Discussions
4.2.1 Experimental Designs
The aims of the experiments are to evaluate the influence of setting the GA
parameters and the influence of the grid computing environment.
The proposed GA that is presented in chapter 3 is applied to both the centralized
course scheduling program and decentralized course scheduling program. In addition,
the same values of the GA parameters will be applied to these programs. Thus, to
evaluate the efficiency of the GA, we only need to test one of the above course
scheduling programs. Here, we test the centralized course scheduling program. To
evaluate the influence of the grid computing environment, we use the grid system as
shown in section 3.7.
We will do four separate experiments. The first experiment tests the influence of
weighting for hard and soft constraints in the fitness function. The second and third
experiments test the influence of the mutation rate and the population size on the
speed of evolution respectively. Finally, the forth experiment tests the influence of
using the grid computing environment.
The course scheduling is a NP hard problem, and the GA itself is a metaheuristic
algorithm. Therefore, we would obtain a good enough solution if not the best
one. Each experiment will run models until the GA detects the best solution or until
the GA cannot improve the fitness value in 300 consecutive generations. The model
giving a faster fitness value via many runs would be a better one.

67
4.2.2 Experiment 1: Hard and Soft Constraint Weight Test
The aim of this experiment is to analyze the behavior of the GA as weights W 1
and W 2 in the fitness function f x)
= W f ( x)
+ W f ( ) are modified. More details
(
1 1
2 2
x
about this function were presented in section 3.6.4.
To perform this experiment, the centralized course scheduling program will be
run on one Pentium IV 1.7 GHz machine with the following GA settings:
- Population size : 10
- Crossover rate : 0.5
- Mutation rate : 0.02
- Selection method : Steady state
- Hard constraint weight W 1 : Varied
- Soft constraint weight W 2 : Varied
This experiment is performed for 3 different pairs of weights as below:
- W 1 =1.0 and W 2 =0.0
- W 1 =0.75 and W 2 =0.25
- W 1 =0.5 and W 2 =0.5
Each pair of weights is tested 5 times. Figure 4-1 presents the average fitness
value f 1 (x) of hard constraints after 500 generations.
The Fitness Value of Hard Constraints vs Various Weights
1.00000
Fitness Value f1(x)
0.50000
0.00000
1 51 101 151 201 251 301 351 401 451 501
Generation
W1=1.0 & W2=0.0 W1=0.75 & W2=0.25 W1=0.5 & W2=0.5
FIGURE 4-1 The average fitness value of hard constraints vs various weights

68
This result shows that the GA rapidly obtains a high fitness value f 1 (x) if we use
a large value W 1. This is because the solutions that have a high fitness value of hard
constraints will have more chance to be selected for survival. When W 1 is 1.0, the GA
gives the fastest evolution of hard constraints.
Now, we will consider what will happen for fitness value f 2 (x) of soft
constraints. Figure 4-2 presents the average fitness values f 2 (x) after 500 generations.
The result also shows that the GA rapidly obtains a high value f 2 (x) if we use a
large value W 2. When W 2 is 0.5, the GA gives the fastest evolution of soft constraints.
1.00000
The Fitness Value of Soft Constraints vs Various Weights
Fitness Value f2(x)
0.50000
0.00000
1 51 101 151 201 251 301 351 401 451 501
Generation
W1=1.0 & W2=0.0 W1=0.75 & W2= 0.25 W1=0.5 & W2= 0.5
FIGURE 4-2 The average fitness value of soft constraints vs various weights
However, using a larger weight for the hard constraints means using smaller
weight for the soft constraints. We have to balance between hard and soft constraints.
In our study, there are nine hard constraints and only one soft constraint. Therefore,
the pair of W 1 =0.75 and W 2 =0.25 seems the most suitable one for our GA.
4.2.3 Experiment 2: Population Size Test
The aim of this experiment is to analyze the behavior of the GA as population
size is modified.

69
To perform this experiment, the centralized course scheduling program will be
run on one Pentium IV 1.7 GHz machine with the following GA settings:
- Crossover rate : 0.5
- Mutation rate : 0.02
- Selection method : Steady state
- Hard constraint weight W 1 : 0.75
- Soft constraint weight W 2 : 0.25
- Population size : Varied
This experiment is performed for 3 different population sizes: 5, 10 and 15.
Each the population size is tested 5 times. The chart of average execution time for a
resultant solution as the population size is changed is given in Figure 4-3.
The Average Time for a Resultant Solution
Population Size
15
10
5
2842.6
2652.8
5829
0 1000 2000 3000 4000 5000 6000 7000
Execution Time in Secconds
FIGURE 4-3 The average execution time for a resultant solution vs population sizes
We know that a large population contains many different individuals. This
creates a diversity of possible solutions. Using a large population size, the GA can
obtain a resultant solution after a small number of generations. However, our
experiment shows that in term of time, the GA with a small population size converges
to a solution faster than the GA with a large size population. To explain this result, we

70
should revise the chromosome representation, presented in section 3.6.1. Each
chromosome represents directly a timetable or a solution, so it stores a large amount
of data. It also has a large amount of related data from the database. As a result, the
larger population needs more memory and more processing time for GA operations.
This experiment also shows that with the smallest population size (five) we
have the fastest GA.
The GAs with a large population do not give a faster speed of evolution.
However, in order to have diversity of solutions, it may be safe to keep the population
size larger than an optimum size although it is a little slower to execute. We will use
the population of 10 for our GA.
4.2.4 Experiment 3: Mutation Rate Test
The aim of this experiment is to analyze the behavior of the GA as mutation rate
is modified.
To perform this experiment, the centralized course scheduling program will be
run on one Pentium IV 1.7 GHz machine with the following GA settings:
- Population size : 10
- Crossover rate : 0.5
- Selection method : Steady state
- Hard constraint weight W 1 : 0.75
- Soft constraint weight W 2 : 0.25
- Mutation rate : Varied
This experiment is performed for 4 different mutation rates: 0.00, 0.02, 0.20 and
0.40. Each rate is tested 5 times. The chart of the average fitness value f(x) after 500
generations versus different mutation rates is given in Figure 4-4.
The best mutation rate is found to be 0.02. The mutation rates that are lower or
higher than this rate give slower evolution. This is shown definitely. If there is no
mutation (0.00), offspring are generated immediately after crossover without any
change. Therefore, the GA would fall into local optimum. On the other hand, the high
mutation rates usually cause the exploration of search space. The GA now can fall
into a random search space instead of searching from offspring of good parents.

71
The GA with Various Mutation Rates
1.00000
Fitness Value f(x)
0.50000
0.00000
1 51 101 151 201 251 301 351 401 451 501
Generation
0.00 0.02 0.20 0.40
FIGURE 4-4 The GA with various mutation rates
4.2.5 Experiment 4: Parallel Execution on the Grid Computing Environment
The aim of this experiment is to evaluate the influence of the grid computing
environment to the resultant solutions.
The experiment tests three different models. The first model uses a single
machine to perform the centralized course scheduling strategy as introduced in section
3.4.1. The centralized course scheduling program is used to test a centralized
execution that schedules for all courses. The second model also uses a single machine,
but both the centralized course scheduling program and the decentralized course
scheduling program are used for a serial execution. First, the centralized course
scheduling program schedules for all shared resources, and then one after another the
decentralized course scheduling program schedules for the remaining resources of
each faculty. Finally, the third model uses a grid computing environment for parallel
execution. First, the centralized course scheduling program is executed on a machine,
and then the decentralized course scheduling program is executed in parallel on
remote machines.
Both the centralized course scheduling program and the decentralized course
scheduling program will set up with the following GA settings:

72
- Population size : 10
- Crossover rate : 0.5
- Mutation rate : 0.02
- Selection method : Steady state
- Hard constraint weight W 1 : 0.75
- Soft constraint weight W 2 : 0.25
The first and second models are performed on a Pentium IV 1.7 GHz machine.
On the other hand, the third model is performed on a gird computing environment of 3
machines, as shown in Figure 3-23. The Central Manager Host m1 is a Pentium III
700 MHz machine. The remote machines m2 and m3 are Pentium IV 1.7 GHz
machines.
Figure 4-5 presents a chart of the average execution time of each model after 5
runs. Each model is executed until the GA finds a resultant solution.
Execution Time vs Models
Parallel Execution on the
Grid
439.6
Model
Serial Execution
852.6
Centralized Execution
2842.6
0 500 1000 1500 2000 2500 3000
Execution Time in Seconds
FIGURE 4-5 The execution time versus various models
The first model is slower than the second model. The first model has a global
view of the whole data, so it should have given a resultant solution within a short time
interval. However, it gave an unexpected result. This is because when the whole data
are centralized to be processed on a single machine, the size of the problem becomes

73
too big. Certainly, the GA is slowed down when it works on large size chromosomes
with a large number of conflicted hard and soft constraints. However, if the data are
separated to be processed one after another by the centralized course scheduling
program and the decentralized course scheduling program, the overall execution time
will be shorter.
The parallel execution of the third model is significant faster than the serial
execution of the second model. It is almost definitely understood. Instead course
scheduling jobs are performed one after another; some of them are performed in
parallel by many different processors, as illustrated in Figure 4-6.
Processors
Parallel
Execution
Centralized Course
Scheduling Program
Decentralized Course
Scheduling Program for
Faculty of Engineering
Decentralized Course
Scheduling Program for
Faculty of Education
Centralized Course
Scheduling Program
Decentralized Course
Scheduling Program
for Faculty of Science
Decentralized Course
Scheduling Program for
Faculty of Engineering
Decentralized Course
Scheduling Program for
Faculty of Education
Serial
Execution
Decentralized Course
Scheduling Program
for Faculty of Science
Execution Time
FIGURE 4-6 Parallel execution versus serial execution
The total execution time for a complete resultant solution of the third model can
be presented as follow:
Total parallel execution time = Time for the centralized course scheduling +
Max(Time for the decentralized course scheduling on remote machines)
The data that is used for the course scheduling programs is transferred from the
central database to the remote machines once before they are processed. In addition,
there are not any exchanges of data while the programs are being executed. The time

74
for network communication is much smaller than the execution time of each program,
so this time is not considered in this experiment.
4.3 The Sample Results
This section presents the results that are obtained by running the third model
that is presented in the previous section.
First of all, the centralized course scheduling program is executed on machine
m2. It schedules for shared resources that consist of courses whose lecturers are
invited from other faculties and courses whose students come from other faculties.
The results are presented in Table 4-3. Then the decentralized course scheduling
program is submitted to be executed in parallel on the machines m2 and m3. It
schedules for the remaining resources of each faculty. All courses taught by the
Faculty of Education have been scheduled by the centralized course scheduling
program, so now the decentralized course scheduling program only schedules for
courses taught by the Faculty of Engineering and the Faculty of Science. The results
are presented in Table 4-4 and Table 4-5.
TABLE 4-3 Timetable created by the centralized course scheduling program
Course Section Classroom Day Time-slot Class Lecturer
ENL307 001 B201A01 3 4->6 BSCS04A 00003
ENL307 001 B201A01 3 4->6 BSCS04B 00003
ECE218
ECE217
001
001
B301B02
B301A07
4
2
2->3
4->5
BSCS05A
BSCS05A
00034
00034
ECE218
ECE217
002
002
B301B02
B301A06
1
1
6->7
2->3
BSCS05B
BSCS05B
00034
00034
ENL101 001 B201A01 2 4->6 BSCS06A 00001
ENL101 001 B201A01 2 4->6 BSCS06B 00001
MAT322
ENL308
001
001
B101A09
B201A03
0
4
6->7
0->2
BSEE04A
BSEE04A
00063
00003
ENL308
MAT322
002
002
B201A03
B101A10
4
4
4->6
2->3
BSEE04B
BSEE04B
00003
00063
MAT223
PHY241
001
001
B101A12
B102A04
1
2
4->5
0->2
BSEE05A
BSEE05A
00061
00007

75
TABLE 4-3 (CONTINUED)
Course Section Classroom Day Time-slot Class Lecturer
MAT223
PHY241
002
002
B101A08
B102A06
0
3
2->3
4->6
BSEE05B
BSEE05B
00061
00006
CHE104
ENL101
MAT125
CHE103
006
002
002
006
B103A15
B201A02
B101A01
B103A06
0
3
2
0
2->3
0->2
0->2
4->6
BSEE06A
BSEE06A
BSEE06A
BSEE06A
00073
00001
00059
00071
MAT125
002
B101A01
2
0->2
BSEE06B
00059
CHE103
005
B103A01
4
0->2
BSEE06B
00071
CHE104
005
B103A11
4
6->7
BSEE06B
00072
ENL101
003
B201A01
1
0->2
BSEE06B
00001
TABLE 4-4 Timetable created by the decentralized course scheduling program for
Faculty of Engineering
Course Section Classroom Day Time-slot Class Lecturer
ECE325
ECE326
SIE305
ECE320
001
001
001
001
B301A04
B301B01
B302A03
B301A01
3
2
4
1
0->2
4->5
4->6
2->3
BSEE04A
BSEE04A
BSEE04A
BSEE04A
00035
00036
00046
00035
ECE320
002
B301A10
0
2->3
BSEE04B
00035
ECE325
002
B301A10
2
0->2
BSEE04B
00035
SIE305
002
B302A02
1
4->6
BSEE04B
00047
ECE326
002
B301B01
4
0->1
BSEE04B
00036
ECE212
001
B301A01
3
4->6
BSEE05A
00032
ECE203
001
B301A02
4
0->1
BSEE05A
00033
ECE200
001
B301B05
4
4->5
BSEE05A
00031
ECE205
001
B301A01
1
0->1
BSEE05A
00033
ECE205
002
B301A01
4
4->5
BSEE05B
00032
ECE212
002
B301A09
2
0->2
BSEE05B
00033
ECE200
002
B301B05
4
6->7
BSEE05B
00031
ECE203
002
B301A08
0
4->5
BSEE05B
00033
ECE102
001
B301A07
4
6->7
BSEE06A
00032
ECE120
001
B301A08
2
4->6
BSEE06A
00031
ECE120
002
B301A08
3
0->2
BSEE06B
00031
ECE102
002
B301A01
0
0->1
BSEE06B
00032

76
TABLE 4-5 Timetable created by the decentralized course scheduling program for
Faculty of Science
Course Section Classroom Day Time-slot Class Lecturer
CSC328
CSC326
CSC329
CSC327
CSC330
001
001
001
001
001
B104B18
B104B05
B104B11
B104B05
B104B02
2
1
0
4
4
2->3
0->2
0->2
6->7
2->3
BSCS04A
BSCS04A
BSCS04A
BSCS04A
BSCS04A
00021
00019
00020
00019
00020
CSC328
CSC329
CSC326
CSC330
CSC327
002
002
002
002
002
B104B16
B104B09
B104B10
B104B03
B104B01
1
0
2
4
2
2->3
4->6
4->6
6->7
2->3
BSCS04B
BSCS04B
BSCS04B
BSCS04B
BSCS04B
00021
00020
00019
00021
00019
CSC210
CSC215
CSC221
MAT220
CSC211
002
002
002
001
002
B104B06
B104B04
B104B03
B101A02
B104B17
3
4
1
0
2
4->6
6->7
4->6
4->6
0->3
BSCS05A
BSCS05A
BSCS05A
BSCS05A
BSCS05A
00018
00018
00017
00061
00018
MAT220
CSC221
CSC211
CSC210
CSC215
002
001
001
001
001
B101A11
B104B09
B104B15
B104B08
B104B04
2
2
3
0
3
4->6
0->2
4->7
0->2
2->3
BSCS05B
BSCS05B
BSCS05B
BSCS05B
BSCS05B
00061
00017
00016
00015
00018
MAT125
CSC120
CSC115
CSC110
CSC127
CSC113
001
002
002
002
002
002
B101A03
B104B07
B104B12
B104B06
B104B01
B104B14
4
3
1
3
4
4
4->6
4->6
0->1
0->1
2->3
0->1
BSCS06A
BSCS06A
BSCS06A
BSCS06A
BSCS06A
BSCS06A
00059
00015
00014
00014
00015
00014
CSC120
CSC110
MAT125
CSC127
CSC113
CSC115
001
001
001
001
001
001
B104B12
B104B08
B101A03
B104B04
B104B14
B104B08
4
3
4
1
3
2
0->2
6->7
4->6
4->5
2->3
0->1
BSCS06B
BSCS06B
BSCS06B
BSCS06B
BSCS06B
BSCS06B
00016
00014
00059
00015
00016
00016

77
These results show that all constraints presented in section 1.3 have been
satisfied. Every “course + section” is scheduled exactly once in a week. No course is
scheduled cross morning and afternoon working sessions. Neither a class nor a
lecturer nor a classroom is assigned to more than one course at the same time. For
example, shown in Table 4-3, section 001 of course ENL308 is scheduled for lecturer
00003 using classroom B201A03 on day 4 (Friday) and in the time-slots: 0, 1, and 2.
Therefore, this lecturer and this classroom are not booked for other courses at this
time.
Once a class of students studies from a list of courses, these courses have to be
scheduled to different time periods. For example, shown in Table 4-1, class BSCS05B
studies section 001 of courses: CSC215, CSC221, CSC210, and CSC211, and section
002 of courses: ECE217, ECE218, and MAT220. Therefore these “course + section”
are scheduled to different time periods. Another example is shown in Table 4-3.
Section 001 of course ENL307 is attended by both classes: BSCS04A and BSCS04B.
Therefore, this course section is scheduled to the same time periods and the same
classroom so that these classes can attend it as well as their other courses.
Other constraints presented in section 1.3 have also been satisfied, but they are
not introduced here.
The decentralized course scheduling program must give results that do not
conflict with the centralized course scheduling output. If a class is scheduled by the
centralized course scheduling program, then the decentralized course scheduling
program has to schedule the remaining courses that concern this class to another time.
For example, shown in Table 4-3, the centralized course scheduling program
scheduled the courses that are attended by class BSEE06A. Therefore, the
decentralized course scheduling program scheduled other courses studied by this class
to another time, shown in Table 4-4.

CHAPTER 5
CONCLUSION
5.1 Conclusions
This study proposed a hybrid centralized and de-centralized approach, a genetic
algorithm, and a grid computing environment for course scheduling in multiple
faculty universities.
The proposed GA demonstrated its ability for solving a complex optimization
problem, the highly constrained course scheduling problem. The direct representation
of chromosomes is convenient for representing a large number of constraints of a
realistic timetable. Additional constraints can easily be added into the model without
much modification on the basic model.
The speed of evolution of the GA is significantly different dependent on GA
parameters used. The GAs with large populations do not give a faster speed of
convergence. However, in order to have diversity of solutions, it may be safe to keep
the population size larger than an optimum size although it is a little slower. The
experiments also show that the use of mutation is very important for the GA. A small
enough rate is effective. No mutation or mutation with high rates gives a slower
evolution. The weighting for hard and soft constraints in the fitness function should be
based on the number and importance of them. The hard constraints should be
weighted larger than the soft constraints.
The hybrid centralized and de-centralized approach was used. The centralized
course scheduling program only schedules for shared resources whereas the
decentralized course scheduling program schedules for remaining resources of each
faculty. The results showed that this approach gave the expected solutions without
any constraint conflicts between resources around the university. The resultant
solution can help lecturers not only teach at their faculty but also at other faculties. A
course can be attended by many different classes.
The grid computing environment is used as infrastructure for distributed and
parallel computing. There is a combination of the hybrid centralized and de-

80
centralized approach and grid computing environment. Now the centralized course
scheduling program and decentralized course scheduling program are considered as
jobs. These jobs are scheduled to be executed. The centralized course scheduling job
is performed first, and then the decentralized course scheduling jobs are performed in
parallel on separate machines. The decentralized course scheduling program must
give results that do not conflict with the centralized course scheduling output.
The use of the grid computing environment gave a high level of efficiency. It
reduces significantly the overall execution time for a resultant solution. This is
because a very large problem with many conflicted constraints is now separated into
small size problems to be processed in parallel by many different machines instead of
using only one machine.
5.2 Future Works
Overall, our preliminary experiments suggested that the proposed model has
been successful to satisfy the objectives in our proposal. We have worked on two
interesting areas: the genetic algorithm and the grid computing. They are wide areas,
so what has been obtained is a foundation for further research.
Our experiments identified the GA parameters for an effective GA. Further
experiments should be done for various data and more soft constraints. We also need
design algorithms that are able to automatically identify suitable values for the GA
parameters.
Local search techniques should be used to improve the speed of the GA. The
local search algorithms should also help the GA to create solutions that are able to
minimize use of university resources, e.g. the number of used classrooms and the
stretch of lecturer time.
To satisfy both hard and soft constraints in a balanced way, the multi-objective
genetic algorithm should be researched.
The grid computing environment was implemented on Linux machines. For
more flexible use, it should be developed for heterogeneous environments with more
machines added.

REFERENCES
1. Alkan, A. and Ozcan, E. “Memetic Algorithms for Timetabling.” IEEE Congress
on Evolutionary Computation. 3 (2003, December 8-12) : 1796-1802.
2. Marc Buf, Tim Fischer, et al. “Automated solution of a highly constrained school
timetabling problem - preliminary results.” Applications of Evolutionary
Computing : EvoWorkshops 2001: EvoCOP, EvoFlight, EvoIASP, EvoLearn,
and EvoSTIM, Como, Italy. (2001, April 18-20) : 431-440.
3 Goulas, G. and Housos, E. “SchedSP: Providing GRID-enabled Real - World
Scheduling Solutions as Application Services.” EuroWeb 2002 Conference,
St Anne's College, Oxford, UK. (2002, December 17-18).
4. Kaplansky, E., Kendall, G., et al. “Distributed Examination Timetabling.”
PATAT '04 Proceedings of the 5th International Conference on the Practice
and Theory of Automated Timetabling, Pittsburgh, PA USA. (2004, August
18-20) : 511-516.
5. Lim, A., Ang, J. C., et al. “UTTSExam: A Campus-Wide University Exam-
Timetabling System”. Proceedings of the Eighteenth National Conference
on Artificial Intelligence and Fourteenth Conference on Innovative
Applications of Artificial Intelligence, Edmonton, Alberta, Canada. (2002,
July 28 - August 1) : 838-844.
6. Genetic Algorithm [Online]. Available from:
http://cs.felk.cvut.cz/~xobitko/ga/gaintro.html [2005, May 2].
7. Luis Ferreira, et al. Introduction to Grid Computing with Globus. IBM Redbooks,
September 2003.
8. Bart Jacob, et al. Enabling Applications for Grid Computing with Globus. IBM
Redbooks, June 2003.
9. Carter, M. W. and Laporte, G. “Recent Developments in Practical Course
Timetabling.” In Edmund Burke and Michael Carter, editors, Practice and
Theory of Automated Timetabling II, Springer-Verlag LNCS. 1408 (1998) :
3-19.

82
10. Carter, M. W. “A Survey of Practical Applications of Examination Timetabling
Algorithms.” Operations Research. 34 (1986) : 193-202.
11. Burke, E. K., Elliman, D. G., et al. “University Timetabling System Based on
Graph Colouring and Constraint Manipulation.” Journal of Research on
Computing in Education. 27(1) (1993) : 1-18.
12. Burke, E. K., Dror, M., et al. “Hybrid Graph Heuristics within a Hyper-heuristic
Approach to Exam Timetabling Problems.” The Next Wave in Computing,
Optimization, and Decision Technologies. (2005) : 79-91.
13. Redl, T. A. “A Study of University Timetabling that Blends Graph Coloring with
the Satisfaction of Various Essential and Preferential Conditions.”
PhD.Thesis, Rice University, Houston, Texas, 2004.
14. Balakrishnan, N., Lucena, A. and Wong, R. T. “Scheduling Examinations to
Reduce Second-Order Conflicts.” Computers & Operations Research. 19
(1992) : 353-361.
15. Arani, T. and Lotfi, V. “A Three Phased Approach to Final Exam Scheduling.”
IIE Trans. 21 (1989) : 86-96.
16. Sally C. Brailsford, Chris N. Potts, et al. ”Constraint Satisfaction Problems:
Algorithms and Applications.” European Journal of Operational Research.
119 (1999) : 557-581.
17. White, G. M. “Constrained Satisfaction, Not So Constrained Satisfaction and the
Timetabling Problem.” PATAT '00 Proceedings of the 3rd International
Conference on the Practice and Theory of Automated Timetabling, Konstanz,
Germany. 1 (2000, August 16-18) : 32-47.
18. Valouxis, C. and Housos, E.. “Constraint Programming Approach for School
Timetabling.” Computers & Operations Research. 30(1) (2003, September) :
1555–1572.
19. Gueret, C., Jussien, N., et al. “Building University timetables using Constraint
Logic Programming.” Proceedings of the First International Conference on
the Practice and Theory of Automated Timetabling (ICPTAT '95), France.
(1995) : 393-408.

83
20. Burke, E. K. and Newall, J. P. “A Multi-Stage Evolutionary Algorithm for the
Timetable Problem.” The IEEE Transactions on Evolutionary Computation.
3(1) (1999, April) : 63-74.
21. Paechter, B., Rankin, R. C. and Cumming, A. “Improving a Lecture Timetabling
System for University-Wide Use.” In: Burke, E., Carter, M. (eds.): The
Practice and Theory of Automated Timetabling II: Selected Papers
(PATAT ’97, University of Toronto), Lecture Notes in Computer Science,
Springer-Verlag, Berlin Heidelberg New York. 1408 (1998) : 156-165.
22. Ross, P., Hart, E. and Corne, D. “Some Observations about GA based
Timetabling.” In: Burke, E., Carter, M. (eds.): The Practice and Theory of
Automated Timetabling II: Selected Papers (PATAT ’97, University of
Toronto, Lecture Notes in Computer Science, Springer-Verlag, Berlin
Heidelberg New York. 1408 (1998) : 115-129.
23. Elmohamed, S., Coddington, P. and Fox., F. A. “Comparison of Annealing
Techniques for Academic Course Scheduling.” In: Burke, E., Carter, M.
(eds.): The Practice and Theory of Automated Timetabling II: Selected
Papers (PATAT ’97, University of Toronto), Lecture Notes in Computer
Science, Springer-Verlag, Berlin Heidelberg New York. 1408 (1998) : 92-
112.
24. White, G. M. and Zhang, J. “Generating Complete University Timetables by
Combining Tabu Search with Constraint Logic.” In: Burke, E., Carter, M.
(eds.): The Practice and Theory of Automated Timetabling II: Selected
Papers (PATAT ’97, University of Toronto), Lecture Notes in Computer
Science, Springer-Verlag, Berlin Heidelberg New York. 1408 (1998) : 187-
210.
25. Dowsland, K. A. “Off the Peg or Made to Measure.” In: Burke, E., Carter, M.
(eds.): The Practice and Theory of Automated Timetabling II: Selected
Papers (PATAT ’97, University of Toronto), Lecture Notes in Computer
Science, Springer-Verlag, Berlin Heidelberg New York. 1408 (1998) : 37-52.
26. Elmohamed, S., et al. “A Comparison of Annealing Techniques for Academic
Course Scheduling.” Lecture Notes in Computer Science. 1408 (1998) : 92-
114.

84
27. Abramson, D. “Constructing School Timetables using Simulated Annealing:
Sequential and Parallel Algorithms.” Management Science. 37(1) (1991,
January) : 98 – 113.
28. Aydin, M. E. “A Distributed Evolutionary Simulated Annealing Algorithm for
Combinatorial Optimisation Problems.” Journal of Heuristics. 10 (2004) :
269–292.
29. Calaor, A. E., Hermosilla, A.Y., et al. “Parallel Hybrid Adventures with
Simulated Annealing and Genetic Algorithms.” Proceedings of the
International Symposium on Parallel Architectures, Algorithms and
Networks (ISPAN.02). (2002, May 22-24) : 33-38.
30. Alvarez-valdes, R. “A Tabu Search Algorithm to Schedule University
Examinations.” QUESTIIO. 21 (1997) : 201-215.
31. Burke, E. K., Kendall, G. and Soubeiga, E. “Tabu-Search Hyperheuristic for
Timetabling and Rostering.” Journal of Heuristics. 9 (2003) : 451–470.
32. Tabu Search [Online]. Available from:
http://www.cs.sandia.gov/opt/survey/ts.html [2005, September 12].
33. Wang, Y. Z. “A GA-based methodology to determine an optimal curriculum for
schools.” Expert Systems with Applications. 28 (2005) : 163–174.
34. Tuan, D. A. and Kim, H. L. “Combining Constraint Programming and Simulated
Annealing on University Exam Timetabling.” International Conference,
RIVF’04, Hanoi, Vietnam. (2004, February 2-5) : 205-210.
35. Kaplansky, E. and Meisels, A. “Negotiation among Scheduling Agents for
Distributed Timetabling.” In Submitted to the 5th International Conference
on the Practice and Theory of Automated Timetabling PATAT'04, Pittsburgh,
PA USA. (2004, August) : 84-105.
36. Marczyk, A. Genetic Algorithms and Evolutionary Computation [Online].
Available from: http://www.talkorigins.org/faqs/genalg/genalg.html [2005,
September 18].
37. Esposito, A. and Tarricone, L. “Grid Computing for Electromagnetics: A
Beginner’s Guide with Applications.” IEEE Antennas and Propagation
Magazine. 45(2) (2003, April) : 91-100.

85
38. Globus Toolkit [Online]. Available From: http://www.globus.org [2005,
September 20].
39. Foster, I., Kesselman, C. and Tuecke, S. “The Anatomy of the Grid: Enabling
Scalable Virtual Organizations.” International Journal of High Performance
Computing Applications. 15(3) (2001) : 200-222.
40. Hamscher, V., Schwiegelshohn, U., et al. “Evaluation of Job-Scheduling
Strategies for Grid Computing.” In Proceedings of the 7th International
Conference on High Performance Computing HiPC-2000, Springer, Berlin,
Lecture Notes in Computer Science LNCS 1971, Bangalore, Indien. (2000,
December) : 192-202.

APPENDIX A
DATA DICTIONARY

88
This section presents the structure of the tables in the database that is created for
the entity relationship diagram shown in Figure 3-5.
A.1 Faculty
TABLE A-1 Faculty
Table: Faculty
Field Type Key Description
FacultyID char(2) Primary ID of faculty
FacultyName char(100) Name of faculty
The university has several faculties, e.g. Faculty of Science, Faculty of
Engineering, and Faculty of Education.
A.2 Department
TABLE A-2 Department
Table: Department
Field Type Key Description
DeptID char(3) Primary ID of department
DeptName char(255) Name of department
FacultyID char(2) Foreign ID of faculty
Each faculty has several departments that include a set of lecturers and courses
within the same scientific domain, e.g. Department of Computer Science, Department
of Mathematics, and Department of Physics.

89
A.3 Lecturer
TABLE A-3 Lecturer
Table: Lecturer
Field Type Key Description
LecturerID char(5) Primary ID of lecturer
LecturerName char(40) Name of lecturer
Gender char(1) Gender of lecturer
DeptID char(3) Foreign ID of department
Lecturers are responsible for teaching several courses. Each lecturer is member
of a department.
A.4 Busy Time
TABLE A-4 Busy Time
Table: BusyTime
Field Type Key Description
LecturerID char(5) Primary ID of lecturer
Day int(2) Date in a week
Workingsession int(2) Working session in a day
State int(1) State of lecturer
Not all working sessions of a day in each week are available to be scheduled for
a lecturer. For instance, Mr. Tim cannot teach on every Monday morning because of
weekly meeting. Some other lecturers dislike teaching in some working sessions. For
instance, Miss Mary dislikes teaching on Friday mornings. Based on data stored in the
BusyTime table, the system tries to satisfy lecturers’ desires. A state has one of the
following three states: 0, 1, or 2. The value of 2 presents a available working session.
The value of 1 is used if the lecturer dislikes teaching at this time (soft constraint).
Finally, the value of 0 is used if the lecturer cannot teach at this time (hard constraint).

90
A.5 Building
TABLE A-5 Building
Table: Building
Field Type Key Description
BuildingID char(2) Primary ID of building
BuildingName char(100) Name of building
The university has several buildings that have a number of classrooms.
A.6 Classroom
TABLE A-6 Classroom
Table: Classoom
Field Type Key Description
ClassroomID char(7) Primary ID of classroom
ClassroomName char(10) Name of classroom
Seats int(3) Number of seats
BuildingID char(2) Foreign ID of building
ClasssroomGroupID char(8) Foreign ID of classroom group
A classroom in a building belongs to a certain classroom group.
A.7 Classroom Group
TABLE A-7 Classroom group
Table: ClassroomGroup
Field Type Key Description
ClassroomGroupID char(8) Primary ID of classroom group
ClassroomGroupName char(100) Name of classroom group

91
Classrooms are grouped into groups. A course is scheduled to a classroom of
designated groups. For instance, course ECE218 (Digital Circuit Design Lab) is only
expected to be scheduled to group ECEDCDLB (Digital Circuit Design Labs).
A.8 Department Controls Rooms
TABLE A-8 Department controls classroom
Table: DeptControlRoom
Field Type Key Description
DeptID char(3) Primary ID of department
ClassroomGroupID char(8) Primary ID of classroom group
A department owns a number of classroom groups that are used for its courses.
A.9 Course
TABLE A-9 Course
Table: Course
Field Type Key Description
CourseID char(6) Primary ID of course
CourseName char(80) Name of course
Credits int(2) Number of credits
Kind char(1) Kind : lecture or practice
DeptID char(3) Foreign ID of a department
A course belongs to a department.

92
A.10 Program
TABLE A-10 Program
Table: Program
Field Type Key Description
ProgramID char(4) Primary ID of program
ProgramName char(255) Name of program
NumSemesters int(2) Number of semesters
DeptID char(3) Foreign ID of department
The university has a number of programs. After studying a program that
includes a number of courses, a student will get a degree, e.g. Bachelor of Science in
Computer Science. A program belongs to a department.
A.11 Curriculum
TABLE A-11 Curriculum
Table: Curriculum
Field Type Key Description
ProgramID char(4) Primary ID of program
CourseID char(6) Primary ID of course
Semester int(2) Semester has this course
Year int(4) Enrolment year of students
for applying this curriculum
To take a degree a student has to fulfill a list of courses in each semester. For
instance, in the first semester, students of Bachelor of Science in Computer Science
take courses: ENL101, CSC110, CSC113, MAT125, CSC115, CSC120, and CSC127.
A curriculum is applied to students based on their enrolment year.

93
A.12 Class
TABLE A-12 Class
Table: Class
Field Type Key Description
ClassID char(7) Primary ID of class
ClassName char(100) Name of class
NumStudents int(3) Number of students
EnrolYear int(4) Enrolment year
ProgramID char(4) Foreign ID of program
Students who study the same program and have the same enrolment year are
grouped into classes.
A.13 Course Section
TABLE A-13 Course section
Table: CourseSection
Field Type Key Description
ClassID char(7) Primary ID of class
Semester int(2) Primary Current semester
Year int(4) Primary Current year
CourseID char(6) Primary ID of course
SectionNo char(3) Section number
LecturerID char(5) ID of lecturer
NumStudents char(4) Number of student
A section is used as an instance of a course taught by a lecturer. “A section of a
course + a lecturer + an estimated number of attended students” is that we will
schedule to time-slots of a certain classroom.

94
A.14 Timetable
TABLE A-14 Timetable
Table: Timetable
Field Type Key Description
RoomID char(7) Primary ID of room
Day int(2) Primary Day in a week
Hour int(2) Primary Hour in a day
CourseSectionID char(9) CourseID+ SectionID
Although this timetable looks simple, it stores the results from the whole course
scheduling system. A section of a course will be schedule to successive time-slots.

APPENDIX B
INSTALLING GRID ENVIRONMENT

96
This section presents in detail steps for installing and setting up the grid
environment that includes Red Hat Linux, Network Time Protocol, Globus, and a
Certificate Authority.
The following topics are discussed:
- Required software
- Hardware environment
- Operating system installation
- Globus installation and setup
- CA installation and setup
B.1 Required Software
Globus Toolkit 2.2 is used in this study. Globus Toolkit 2.x supports Red Hat
Linux on xSeries and AIX on pSeries. We select Red Hat Linux 9.0 as our host
operating system.
The below is the list of required files to be downloaded:
- Globus Packaging Technology: gpt-2.2.2-src.tar.gz
- Globus client: globus-all-client-2.2.3-i686-pc-linux-gnu-bin.tar.gz
- Server bundle: globus-all-server-2.2.3-i686-pc-linux-gnu-bin.tar.gz
- Certificate Authority: globus_simple_ca_bundle-0.9.tar.gz
- Network Time Protocol (NTP): ntp-4.1.1-1.i386.rpm
Place these files in the directory /usr/src. These Globus files can be downloaded
from the address: ftp://ftp.globus.org/pub/gt2/2.2/.
The NTP package already is installed in Red Hat Linux 9.0, so we do not need
to download and install it. However, for other versions of Linux, we have to set up the
NTP on hosts.
B.2 Setting Up the Environment
An Ethernet LAN and three Intel Pentium machines were used to build the grid
environment. Figure 3-23 presents this environment with the host names and
functions to be installed in each machine.
The host names are m1, m2, and m3. The machines should have a clock speed
of at least 500 Mhz, at least 128 MB of memory, and at least 8 GB hard drives.

97
There are dependencies among steps of installing and setting up, so they require
to be performed in the order.
The major steps to set up the grid environment include installing:
- Red Hat Linux 9.0 on each machine
- Network Time Protocol server on one machine (here we use m2) and
configuring NTP clients for the others (m1 and m3)
- Globus Packaging Technology on each machine
- Globus Server on the m2 and m3 machines
- Globus Client on m1
- Globus Simple Certificate Authority on m2
The grid is configured using the below major steps:
- Sign the certificate requests from all components and users needing them
- Set up gridmap files for each system
- Set up automated grid startup
- Set up each GRIS to talk to one GIIS
- Set up MDS security
B.2.1 Naming and Addressing Planning
The Table B-1 shows names, IP addresses, and software to be installed on
machines.
TABLE B-1 Host names, IP addressing, and software
Host name IP Software
m1.kmitnb.ac.th 192.168.10.241 Globus client, centralized scheduling program, MySQL 4.0
m2.kmitnb.ac.th 192.168.10.242 Globus server, CA, and NTP server
m3.kmitnb.ac.th 192.168.10.243 Globus server
We also define the user IDs, groups, and passwords before implementation,
shown in Table B-2.
The root and globususer ID are used on all machines. Some machines have no
password for snobol and adminca ID because the corresponding machine does not
have that user ID installed on it.

98
TABLE B-2 Group, user ID and password
User ID Group ID m1 password m2 password m3 password
Root Root pwrtm1 pwrm2 pwrm3
globususer globus pwgbm1 pwgm2 pwgm3
snobol snobol pwsbm1
adminca adminca pwamm2
The globususer ID is used to run jobs on the grid for the user. Since this user ID
has more than eight characters, we will need to install it later, rather than installing it
as part of the Linux install process. The other user IDs can be installed as part of the
Linux installation or later.
The snobol ID is used to submit jobs to the grid.
The adminca ID is used to receive certificate requests for the Certificate
Authority. The adminca ID could be used to ftp the certificate requests to the machine
m2 in our install. The certificates will be signed using the root ID on machine m2.
Before installing the Globus Simple Certificate Authority, we must define the
distinguished name (DN) that will be used by the CA in our environment. Table B-3
describes the distinguished name used for the Certificate Authority in our
environment. The distinguished names for the users and for the Globus services will
be generated automatically.
TABLE B-3 Distinguished name and passphrase
Certificate Authority DN
cn=my test CA, ou=m2.kmitnb.ac.th, ou=demotest, o=grid
Passphrase
mycapw
The distinguished name (DN) and passphrase will be used by the Certificate
Authority to sign certificate requests.
B.2.2 Installing Linux
Install Linux on all of the machines using the “server” install, selecting all
packages and “no firewall”. Each system should use a fixed network IP address with a
corresponding host name, given in Table B-1, and do not use DHCP.
After installing Linux on each system, we create user IDs in Table B-2. The
below is an example of how to add the globususer ID on machine m1.

99
Add a group for globus by executing:
groupadd -g 900 globus
Add the user globususer (with password globususer) by executing:
adduser -u 900 -g globus -d /home/globususer -n globususer
Change the globususer ID’s password from globususer to pwsbm1 or other
password by executing:
passwd globususer
B.2.3 Installing Network Time Protocol (NTP)
NTP needs to be installed because the grid needs the clocks on the systems to be
synchronized. The security process creates proxy certificates that are valid for specific
times. If the systems do not have their clocks synchronized, then the users may not be
able to use the grid, because the proxy certificates may look like they have expired or
are not yet valid.
On all of the grid machines, install NTP as follows using the root ID:
$ rpm -ivh /usr/src/ntp-4.1.1-1.i386.rpm
If the package is already installed as a part of the Linux distribution, ignore the
error message and continue to set up the NTP server. Proceed by setting up the server
and daemons.
Edit the file /etc/ntp.conf on the machine designated to be the time server,
machine m2, and leave the following four lines as the only un-commented ones,
commenting all others with a leading “#” character:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /etc/ntp/drift
broadcastdelay 0.008
Also, on the NTP server machine (m2), use the settings ntsysv command to
enable the NTP daemon (ntpd) on the next reboot. We can also start the Red Hat
Service Configuration tool by clicking on Main Menu System Setting Server
Setting Services. Scroll down the list of services on the left side until we get to the
ntpd service. Click on the ntpd service and click Start to run it.
On the other machines in the grid (m1 and m3), change the file /etc/ntp.conf to
leave only the following lines un-commented:
server m2.kmitnb.ac.th
driftfile /etc/ntp/drift

100
broadcastdelay 0.008
authenticate no
Next, execute the following command to have them check for the time from the
above server machine m2:
ntpdate -b m2.kmitnb.ac.th
This should be executed at least once per boot, and could be set up to run
periodically using crond and crontab.
B.2.4 Setting Up Host Files and Environment Variables on Each Machine
As root, use an editor to edit the hosts file /etc/hosts on each machine with the
following lines:
127.0.0.1 localhost
192.168.10.241 m1.kmitnb.ac.th m1
192.168.10.242 m2.kmitnb.ac.th m2
192.168.10.243 m3.kmitnb.ac.th m3
Verify machine connectivity after the next reboot, using the ping command to
ping each of the other machines by name.
Edit the file /etc/profile in each machine. Insert the following three lines after
the line in /etc/profile that says “export PATH USER ...”:
export GPT_LOCATION=/usr/local/gpt
export GLOBUS_LOCATION=/usr/local/globus
export PATH=$PATH:$GLOBUS_LOCATION/bin:$GLOBUS_LOCATION/sbin
Log off and log back on the machines after modifying the file /etc/profile so that
the above settings take effect.
B.2.5 Installing the GPT
Log on as root and install GPT on all of the machines. Please ignore all
warnings from Globus:
cd /usr/src
tar -xzvf gpt-2.2.2-src.tar.gz
cd gpt-2.2.2
./build_gpt
ls ${GPT_LOCATION}/sbin | wc -l
The final ls command should show 29 gpt-* executable files.
B.2.6 Installing a Globus Server Bundle
The following is used to install the server bundle on each server machine.
Perform these steps on each machine that will be a server. In our demo, we will use
machines m2 and m3 as servers.

101
As root, run:
cd /usr/src
export PATH=$PATH:$GPT_LOCATION/sbin
gpt-install globus-all-server-2.2.3-i686-pc-linux-gnu-bin.tar.gz
gpt-postinstall
/usr/local/globus/setup/globus/setup-gsi
y
q
B.2.7 Installing a Globus Client Bundle
The following is used to install the client bundle on any machines that will be
used to query or submit jobs to the grid. In our application, we will install the client
on the machine m1.
As root, run:
cd /usr/src
export PATH=$PATH:$GPT_LOCATION/sbin
gpt-install globus-all-client-2.2.3-i686-pc-linux-gnu-bin.tar.gz
gpt-postinstall
/usr/local/globus/setup/globus/setup-gsi
y
q
B.2.8 Installing the Globus Simple Certificate Authority
To install the Globus Simple Certificate Authority, one of the Globus bundles
(server or client) needs to be installed on the machine due to a dependency. We will
install the CA and a Globus server on the machine m2.
As root, run:
cd /usr/src
export PATH=$PATH:$GPT_LOCATION/sbin
gpt-build -nosrc gcc32
gpt-build globus_simple_ca_bundle-0.9.tar.gz gcc32
gpt-postinstall
...
Do you want to keep this as the CA subject (y/n) [y]: n
Enter a unique subject name for this CA:
cn=my test CA, ou=m2.kmitnb.ac.th, ou=demotest, o=grid
Enter the email of the CA:
adminca@m2.kmitnb.ac.th
[default 5 years] 1825

102
mycapw
[enter]
During the above process, a hash number is generated and used as part of the
file name. Please note this number for use in the next steps. Run the script name
printed at the end of the prior install, substituting the hex hash number printed by the
above process in place of the shown below, adding the “-default” argument:
/usr/local/globus/setup/globus_simple_ca__setup/setup-gsi -default
y
q
The file /root/.globus/simpleCA/private/cakey.pem is the CA’s private key and
should not be given out to anyone else. The file /root/.globus/simpleCA/cacert.pem
contains the CA’s public key.
The following is used to install the CA’s certificate on each of the other grid
machines. /root/.globus/simpleCA/globus_simple_ca__setup-0.9.tar.gz is the
file containing the public CA key and other information needed to participate in this
grid. This must be copied to each of the other machines and installed using the gptbuild
command.
First, on machine m2, use ftp to copy the file
/root/.globus/simpleCA/globus_simple_ca__setup-0.9.tar.gz to the directory
/usr/src/ of each of the other grid machines. This can be done in two steps by ftp-ing
them to the directory /home/globususer on each of those machines using globususer
ID. Then, using root, this file can be moved to the directory /usr/src. Next, issue the
following commands on each of those machines as root:
gpt-build /usr/src/globus_simple_ca__setup-0.9.tar.gz
gpt-postinstall
/usr/local/globus/setup/globus_simple_ca__setup/setup-gsi -default
y
q
B.2.9 Requesting and Signing Gatekeeper Certificates for Servers
On each of the server machines (m2 and m3), we perform the following steps to
request and sign certificates:
grid-cert-request -host
Use ftp or e-mail (if available and using the adminca ID) to copy the file
/etc/grid-security/hostcert_request.pem to the CA machine and put it into the directory
/root. On the CA machine, as root, sign the certificate using the following:

103
grid-ca-sign -in /root/hostcert_request.pem -out /root/hostcert.pem
mycapw
Then, ftp the file /root/hostcert.pem back to the server machine and place it in
the directory /etc/grid-security.
B.2.10 Requesting and Signing User Certificates
For each user who will use the grid (in our example, user snobol on the client
machine m1), the following procedure must be executed by the user and Certificate
Authority. On the snobol user’s logon, run:
grid-cert-request
The user should make up his own passphrase for his certificate. He will use this
same passphrase later with the grid-proxy-init command to authenticate with the
grid. In our example, the snobol user’s login password could be used here.
The user must then send the file /home//.globus/usercert_request.pem
to the Certificate Authority (machine m2) for signing. On the CA machine (m2), sign
the certificate using root with the following command, adjusting the location of
usercert_request.pem to point to wherever the above request file is now stored on m2:
grid-ca-sign -in usercert_request.pem -out usercert.pem
mycapw
Securely send the file usercert.pem back the requesting user. The user should
put the file usercert.pem into his /home//.globus directory.
The user should also be added to the grid-mapfile (on machine m2 under root)
using the following command (note the backward apostrophe characters next to the
double quote characters):
grid-mapfile-add-entry -dn “`grid-cert-info -f usercert.pem –subject`” –ln globususer
Copy grid-mapfile in /etc/grid-security/grid-mapfile to each of the other servers
(m2) so that all of the servers have this file.
B.2.11 Setting Up the Gatekeepers
On each server (m2 and m3), add the following two lines to the file
/etc/services:
gsigatekeeper 2119/tcp #globus gatekeeper
gsiftp 2811/tcp #globus wuftp
Create the file /etc/xinetd.d/gsigatekeeper on each server, containing the lines:

104
service gsigatekeeper
{
socket_type = stream
protocol = tcp
wait = no
user = root
env = LD_LIBRARY_PATH=/usr/local/globus/lib
server = /usr/local/globus/sbin/globus-gatekeeper
server_args = -conf /usr/local/globus/etc/globus-gatekeeper.conf
disable = no
}
Create the file /etc/xinetd.d/gsiftp on each server, containing the lines:
service gsiftp
{
instances = 1000
socket_type = stream
wait = no
user = root
env = LD_LIBRARY_PATH=/usr/local/globus/lib
server = /usr/local/globus/sbin/in.ftpd
server_args = -l -a -G /usr/local/globus
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = no
}
Now reboot all of the machines.
B.3 Setting Up the MDS
We will configure the Monitoring and Discovery Service (MDS) to have one
Grid Information Index Service (GIIS) in the machine m2, which collects the data
reported by the Grid Resource Information Servers (GRIS) in all of the machines.
The GRIS servers send information about their respective servers to the GIIS. In
the demo application, we will use this to find machines that are not too busy. The user
will be able to query the GIIS from the client machine m1.

105
To set up this structure, we need to modify several configuration files. These
files name the GIIS and GRIS, and show how these components should register with
each other.
Figure 3-24 presents the relationship among the MDS components in our
application.
B.3.1 Setting Up the GIIS and GRIS on the Machine m2
On m2, make the following modifications to the conf files in the directory
$GLOBUS_LOCATION/etc.
In the file grid-info-slapd.conf, name the GIIS on machine m2. Change the
second of the lines:
to
to
database giis
suffix “Mds-Vo-name=site, o=Grid”
database giis
suffix “Mds-Vo-name=m2.kmitnb.ac.th, o=Grid”
In the file grid-info-site-policy.conf, allow registrations from the domain.
Change the below line:
policydata: (&(Mds-Service-hn=site) (Mds-Service-port=2135))
policydata: (&(Mds-Service-hn=*.kmitnb.ac.th) (Mds-Service-port=2135))
In the file grid-info-resource-register.conf, tell the m2 GRIS to register with the
m2 GIIS. Change the two matching lines to the settings shown below:
dn: Mds-Vo-Op-name=register, Mds-Vo-name=m2.kmitnb.ac.th, o=grid
reghn: m2.kmitnb.ac.th
B.3.2 Setting Up the GRIS on m3
On all of the other server machines (here we have only m3), make the following
modifications to the conf files in the directory $GLOBUS_LOCATION/etc.
In the file grid-info-slapd.conf, remove the GIIS server from these machines.
Remove the block of lines starting with the following lines:
database giis
suffix “Mds-Vo-name=site, o=Grid”
In the file grid-info-resource-register.conf, tell the GRIS which GIIS to register
with. Change the two matching lines as shown below:
dn: Mds-Vo-Op-name=register, Mds-Vo-name=m2.kmitnb.ac.th, o=grid
reghn: m2.kmitnb.ac.th

106
B.3.3 Starting the MDS on All of the Servers
Start the MDS on all of the servers (m2 and m3) using:
globus-mds start
This can be automated by putting it in /etc/rc.d/rc.5 per the usual conventions.
Copy the globus-mds script into the directory /etc/init.d/. Then create two symbolic
links as follows:
cp $GLOBUS_LOCATION/sbin/globus-mds /etc/init.d/
cd /etc/rc.d/rc5.d/
ln -s /etc/init.d/globus-mds S92globus-mds
ln -s /etc/init.d/globus-mds K92globus-mds
B.3.4 Setting Up the MDS Client m1
Modify the file $GLOBUS_LOCATION/etc/grid-info.conf lines shown below
so that searches go to the GIIS on machine m2:
GRID_INFO_HOST=”m2.kmitnb.ac.th”
GRID_INFO_ORGANIZATION_DN=”Mds-Vo-name=m2.kmitnb.ac.th, o=Grid”
B.3.5 Setting Up a Secure MDS
So far, we have set up an MDS that permits anonymous access. The grid-infosearch
command should use the -x flag to indicate an anonymous search request.
However, the MDS can be secured so that only certified users can access the GIIS and
only certified server GRISs can register to send information to the GIIS. The
following steps should be performed.
B.3.5.1 Requesting and Signing Certificates for Each Server Machine
For each of the server machines (m2 and m3) request LDAP certificates, sign
them using the Certificate Authority on m2, and copy the signed certificates to the
proper location. The steps for one of the servers (m3) are shown below.
On the server machine (m3) under root, run:
grid-cert-request -service ldap -host m3.kmitnb.ac.th
Copy the request certificate from /etc/grid-security/ldap/ldapcert_request.pem to
the Certificate Authority machine (m2) using ftp or any other desired method. Sign
the certificate using root on m2 substituting the correct locations for the request
certificate and signed certificates:
grid-ca-sign -in ldapcert_request.pem -out ldapcert.pem

107
Copy the resulting signed certificate file ldapcert.pem from the Certificate
Authority machine (m2) to the file the server machine (m3) location /etc/gridsecurity/ldap/ldapcert.pem.
B.3.5.2 Changing the conf Files
Change the following configuration files on the servers.
Change $GLOBUS_LOCATION/etc/grid-info-slapd.conf to change the
anonymousbind setting(s) as follows:
anonymousbind yes
Change the files $GLOBUS_LOCATION/etc/grid-info-resource-register.conf
on the servers to require authentication when registering:
bindmethod: ANONYM-ONLY
At this point, the registration "authentication" bind method has been specified.
Who can register with whom and how, but when anonymous bind has been
deactivated, each registrant node must be informed that the GIIS (m2) is authorized to
receive resource information.
To authorize m2 (the GIIS) to receive registration information, m2's ldap
subject name must be entered in the grid-mapfile file. To get m2's ldap subject name,
we run "grid-cert-info" on m3 as follows, in directory /etc/grid-security, with the
assumption that m3's ldap subject name would be similar.
% grid-cert-info -f /etc/grid-security/ldap/ldapcert.pem -subject
The name was
/O=grid/OU=demotest/OU=m2.kmitnb.ac.th/CN=ldap/m3.kmitnb.ac.th
Since direct editing of the grid-mapfile is discouraged, we run the following
command using the name obtained from above, substituting "m2" for "m3."
% grid-mapfile-add-entry \
-dn "/O=grid/OU=demotest/OU=m2.kmitnb.ac.th/CN=ldap/ m2.kmitnb.ac.th" \
-ln globususer
Successful entry was indicated with the following string returned:
(1) entry added
After making all of these changes, the server machines should be rebooted or
the following should be used to restart the MDS on each of the servers (m2 and m3):
globus-mds stop
globus-mds start

108
B.4 Checking the Installation
To check the installations on each machine, as root use the command:
$GPT_LOCATION/sbin/gpt-verify
The following commands can be used on a server machine to see if the GRAM
and GridFTP are listening on their respective ports:
netstat -an | grep 2119
netstat -an | grep 2811
From the client machine (m1) logged on as the user snobol, do the following:
This command sets up the environment so that Globus commands can be issued
by the user. One may want to add this line to one’s login profile:
. $GLOBUS_LOCATION/etc/globus-user-env.sh
This command refreshes the proxy certificate for the user (snobol):
grid-proxy-init
The following commands send a simple job to the server machine. This test
whether jobs can be submitted to each of the server machines:
globus-job-run m2.kmitnb.ac.th “/bin/hostname”
globus-job-run m3.kmitnb.ac.th “/bin/hostname”
To refine the search to look for processors having more than 90 percent free of
CPU utilization for the last minute, use:
grid-info-search -x “(&(Mds-Device-Group-name=processors)(Mds-Cpu-Free-1minX100>=90))”
Now we are ready to install and run the course scheduling application.

APPENDIX C
INSTALLING SOFTWARE

110
This section introduces the steps for installing and setting up MySQL 4.0,
J2sdk1.4, Java Cog Kit 1.1, Tomcat 5.0, mod_jk2 and JDBC driver on Redhat Linux
9.0 (RH9). In this study, we will install this software on machine m1.
C.1 Installing MySQL 4.0
First, make sure there is no previous version of MySQL installed on the system.
As root execute the command:
#rpm –q mysql
If there is none, proceed to install phase, otherwise uninstall it by the command:
#rpm –e mysql
Download the rpm packages for MySQL’s server, client and dynamic shared
libraries:
- MySQL-server-4.0.24-0.i386.rpm
- MySQL-client-4.0.24-0.i386.rpm
- MySQL-shared-4.0.24-0.i386.rpm
- MySQL-devel-4.0.24-0.i386.rpm
Then install them one by one by using the following commands as root:
#rpm -ivh MySQL-server-4.0.24-0.i386.rpm
#rpm -ivh MySQL-client-4.0.24-0.i386.rpm
#rpm -ivh MySQL-shared-4.0.24-0.i386.rpm
#rpm -ivh MySQL-devel-4.0.24-0.i386.rpm
The MySQL database has been created in /var/lib/mysql.
Initialize MySQL database after installation by typing:
#mysql_install_db
Do not forget to set the mysqlclient.so path into search path file /etc/ld.so.conf.
For example, we have:
/usr/lib/libmysqlclient.so
Make sure /etc/ld.so.conf contains:
/usr/lib
Then run
#/usr/sbin/ldconfig
The following instructions are to change the default empty password for
MySQL users to what we like. For example, change the empty password to ncdanh:
#/usr/bin/mysqladmin –u root password ncdanh
Now, try to log in MySQL with the new password. As root, type:

111
#mysql –u root
Enter password: ncdanh
mysql>
C.2 Installing J2sdk1.4
To install J2sdk1.4, do the following steps:
- Download j2sdk-1_4_2_10-linux-i586.bin file and copy it to /usr/local:
[root@m1 root]#cp –p j2sdk-1_4_2_10-linux-i586.bin /usr/local
- Run the above file:
[root@m1 root]#./j2sdk-1_4_2_10-linux-i586.bin
This leaves directory /usr/local/j2sdk-1.4.2_10.
- Insert the following lines inside file /etc/profile or /root/.bashrc:
export JAVA_HOME= /usr/local/j2sdk1.4.2_10
export CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/jre/lib/rt.jar:./
C.3 Installing Java Cog Kit 1.1
This section presents how to download, install and configure the Java CoG Kit
1.1.
Installation is the first step that needs to be accomplished before the Java CoG
Kit can be used. It ensures that the Java CoG Kit exists on our local machine in a
proper state. After installation, configuration is needed to adjust various parameters
that are specific to our environment.
C.3.1 Downloading the Java Cog Kit
This study uses jglobus stable binary. Using this version, we are interested in
just the jar files without modifying them.
The stable binary distribution of the jglobus is available from the web-site:
http://www.globus.org/cog/java/1.1/cog-1.1-bin.tar.gz.
As root, do the following steps:
- Download cog-1.1-bin.tar.gz file and copy to /usr/local.
- Unpack this file:
[root@m1 root]#cd /usr/local
[root@m1 local]#tar –xzf cog-1.1-bin.tar.gz
A directory named cog-1.1 will be created. This directory will, from now on, be
referred to as

112
C.3.2 Configuration
This section shows how to configure the Java CoG Kit.
C.3.2.1 Environment Variables
The COG_INSTALL_PATH environment variable is used to determine the
installation location of the Java CoG Kit. The COG_INSTALL_PATH should point to
the directory.
It is also highly recommended that you add the /bin directory
to the binary search path (named PATH on most systems).
Add the following commands to the /etc/profile:
export COG_INSTALL_PATH=/usr/local/cog-1.1
export PATH=$ COG_INSTALL_PATH/bin
Log out and log in the RH9 machine to active the above profile.
C.3.2.2 Configuration
Manual configuration of the Java CoG Kit is also possible. Using an Editor, we
create the configuration file named cog.properties and locate it in the directory /.globus.
In our situation, this directory is /home/snobol/.globus (The snobol
user is created in Appendix B).
A sample Java CoG Kit configuration file is shown as follows:
#Java CoG Kit Configuration File
#Mon Dec 26 10:30:30 CST 2005
usercert=/home/snobol/.globus/usercert.pem
userkey=/home/snobol/.globus/userkey.pem
proxy=/tmp/x509up_u800
cacert=/usr/local/globus/etc/grid-security/certificates/42864e48.0
ip=192.168.10.241
It includes a number of important properties. These properties are:
- usercert: points to the location of the Globus user certificate.
- userkey: points to the location of the private key associated with the Globus
user certificate.
- proxy: points to the location of the user proxy. The proxy is located in a
temporary directory, and has its name composed of the string x509up_u and a user id
(OS specific). In the above example, the user id is 1000.
- cacert: contains a comma separated list of certificate authorities that the user
trusts.

113
- ip: represents the IP address of the machine the Java CoG Kit will be run
from.
C.3.2.3 Managing Certificates and Proxies
Currently, the Java CoG Kit provides some GUI-based tools for credential
management. These tools need the environment variable COG_INSTALL_PATH to
be set to .
One of the tools is Visual-grid-proxy-init. This tool allows creation of a proxy.
Lifetime and cryptographic strength of the proxy can be specified. Also, the locations
of user’s long-term credentials and the location of the resulting proxy file can be
specified.
FIGURE C-1 Visual-grid-proxy-init
To run this tool, as root, do the following steps:
- Run the following command:
[root@m1 root]# visual-grid-proxy-init
The system will show a dialog box as presented in Figure C-1.
- Input password: pwsbm1.
- Input the options with the following values:
• Proxy lifetime : 12h
• Strength : 512
• Proxy file : /tmp/x509up_u800
• User certificate : /home/snobol/.globus/usercert.pem
• User private key : /home/snobol/.globus/userkey.pem
- Press ”Create” button.
For testing, after running the proxy file, run some following commands:
- Display information regarding a proxy

114
[root@m1 root]#grid-proxy-info
- Execute a command on remote machine m2 from local machine m1:
[root@m1 root]#globusrun –r m2.kmitnb.ac.th –o “&(executable=/bin/ls)”
C.4 Installing Tomcat 5.0
C.4.1 Installing Tomcat 5.0
To install Tomcat 5.0, do the following steps:
- Download file jakarta-tomcat-5.0.28.tar.gz and copy it to /usr/local/opt.
[root@m1 root]#cp –p jakarta-tomcat-5.0.28.tar.gz /usr/local/opt
- Change into /usr/local/opt and do the following commands:
[root@m1 root]# cd /usr/local/opt
[root@m1 opt]# tar –zxvf jakarta-tomcat-5.0.28.tar.gz
[root@m1 opt]# ln –s jakarta-tomcat-5.0.28 tomcat
Tomcat has been installed into /usr/local/opt/jakarta-tomcat-5.0.28 and
linked to /usr/local/opt/tomcat.
- Insert the following line inside file /etc/profile or /root/.bashrc:
export CATALINA_HOME=/usr/local/opt/tomcat
Now, log out and then log in the RH9 machine to ensure that all changes
take effect.
C.4.2 Starting and Stopping Tomcat 5.0
First of all, we need to ensure that CATALINA_HOME and JAVA_HOME are
correctly set. To do this, open a terminal and type the following commands:
# echo $JAVA_HOME
# echo $CATALINA_HOME
If we get a blank line, or if the directory points anywhere besides where it is
supposed to, we will have to correct these environment variables first, before
continuing.
If everything is fine, we can start Tomcat with the following command. As root,
# $CATALINA_HOME/bin/startup.sh
To check if Tomcat is running fine, we should open a browser and point the
URL to http://localhost:8080. We should see the default Tomcat welcome page.
To stop Tomcat, as root,
# $CATALINA_HOME/bin/shutdown.sh

115
If Tomcat does not start and we downloaded the zip file, the cause is probably
due to permissions. Ensure that the following files are executable inside directory
$CATALINA_HOME/bin,
# chmod +x startup.sh
# chmod +x shutdown.sh
# chmod +x tomcat.sh
After making the files executable, we try starting and stopping Tomcat again.
C.5 Installing mod_jk
We will use the Apache server included in RH9, instead of installing another
one. The httpd service was installed in /etc/httpd.
Before installing mod_jk, we should shutdown both the httpd service and
Tomcat. The httpd service can be shutdown from Menu bar of RH9 (System
Settings/Server Settings/Services), shown in Figure C-2. Select httpd and press
“Stop”.
FIGURE C-2 Service configuration
Now, to install mod_jk do the following steps:
- Download file mod_jk2-2.0.4-2jpp.i386.rpm (We can download at
http://rpm.pbone.net) and copy it to /usr/software.
[root@m1 root]#cd /usr/software
- Install this file:
[root@m1 software]#rpm –ihv mod_jk2-2.0.4-2jpp.i386.rpm

116
The system will automatically put both mod_jk2.so and jkjni.so into
/etc/httpd/modules of RH9.
Now we configure for the following files: server.xml, workers2.properties and
httpd.conf.
C.5.1 Editing server.xml File
Open the file CATALINA_HOME/conf/server.xml and look for the "non-SSL
Coyote HTTP/1.1 Connector". This is a standard Tomcat-only connector. Comment it
out since we will be using Apache for handling HTTP requests:
C.5.2 Creating workers2.properties File
Create file /etc/httpd/conf/workers2.properties with the following contents:
[shm]
file=/etc/httpd/logs/shm.file
size=1048576
# socket channel
[channel.socket:localhost:8009]
port=8009
host=127.0.0.1
# worker for the connector
[ajp13:localhost:8009]
channel=channel.socket:localhost:8009
Note that the port matches that defined in the file server.xml for Tomcat.
C.5.3 Editing httpd.conf File
Open the file /etc/httpd/conf/httpd.conf and add the following lines at the end of
the list of modules loaded into Apache.
LoadModule jk2_module modules/mod_jk2.so
JkUriSet worker ajp13:localhost:8009
JkUriSet worker ajp13:localhost:8009

117
JkUriSet worker ajp13:localhost:8009
JkUriSet worker ajp13:localhost:8009
JkUriSet worker ajp13:localhost:8009
For testing, we will create the directory
CATALINA_HOME/webapps/ROOT/scheduling to store the JSP or html files for our
system, then create a simple file test.jsp and put this file into the above directory. The
file test.jsp has the following content:
Now, try to access it from a web browser as presented in Figure C-3.
FIGURE C-3 Result in the web browser
Tomcat will automatically create the following files:
CATALINA/work/Catalina/localhost/_/org/apache/jsp/scheduling/*.class

118
C.6 Installing JDBC Driver on Linux
Assume that we already have MySQL installed on the Redhat Linux machine.
To access MySQL from Java or JSP programs, we need to download the MySQL
Connector-J from its website. This study uses MySQL Connector/J 3.2.
- Download the file mysql-connector-java-3.2.0-alpha.tar.gz (We can
download it from http://www.mysql.com/products/connector/j/index.html).
- Unzip, untar this tar.gz file and then place the above file into /usr/local.
- Copy the file mysql-connector-java-3.2.0-alpha-bin.jar to the directory
JAVA_HOME/jre/lib/ext.
- Copy the file Driver.class to JAVA_HOME/jre/lib/ext. This will allow the
java interpreter to find the driver.
- Finally, insert the following lines inside file /etc/profile or /root/.bashrc.
export CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/jre/lib/rt.jar:
$JAVA_HOME/jre/lib/ext/mysql-connector-java-3.2.0-alpha-bin.jar:./

APPENDIX D
INSTALLING CENTRALIZED AND DECENTRLIZED COURSE
SCHEDULING PROGRAMS

120
This section presents how to compile the centralized and decentralized course
scheduling programs. These programs are written in C language that was included in
the Redhat Linux 9.0 installation.
D.1 The Centralized Course Scheduling Program
This program will be installed on machine m2. On machine m2, we do the
following steps:
- Copy the file centralizedscheduling.c to /usr/study/coursescheduling.
- Run the following commands as root:
[root@m2 root]#cd /usr/study/coursescheduling
[root@m2 coursescheduling]# gcc –I/usr/include/mysql centralizedscheduling.c –I/usr/lib/mysql –
lmysqlclient –lz –o centralizedscheduling.exe
The file centralizedscheduling.exe has been created in the same directory.
For testing, we can run the following command.
[root@m2 coursescheduling]#./centralizedscheduling.exe
D.2 The Decentralized Course Scheduling Program
This program will be installed on machines m2 and m3. The following steps are
to compile it on machine m2.
- Copy the file decentralizedscheduling.c to /usr/study/coursescheduling.
- Run the following commands as root:
[root@m2 root]#cd /usr/study/coursescheduling
[root@m2 coursescheduling]# gcc –I/usr/include/mysql decentralizedscheduling.c –I/usr/lib/mysql –
lmysqlclient –lz –o decentralizedscheduling.exe
The file decentralizedscheduling.exe has been created in the same directory.

APPENDIX E
JAVA SOURCE CODE FOR GRID SYSTEM

122
All the following files are complied and stored in the directory
/usr/study/gridsystem on machine m1.
GridInfoSearch.java
import java.util.Hashtable;
import java.util.Enumeration;
import java.net.InetAddress;
import java.net.UnknownHostException;
import javax.naming.Context;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
import javax.naming.directory.Attribute;
import javax.naming.directory.SearchControls;
import javax.naming.directory.SearchResult;
import javax.naming.directory.Attributes;
import javax.naming.ldap.LdapContext;
import javax.naming.ldap.InitialLdapContext;
import org.globus.mds.gsi.common.GSIMechanism;
// we could add: aliasing, referral support
public class GridInfoSearch {
//Default values
private static final String version = org.globus.common.Version.getVersion();
private static final String DEFAULT_CTX ="com.sun.jndi.ldap.LdapCtxFactory";
private String hostname = "m2.sched.grid.com";
private int port = 2135;
private String baseDN = "mds-vo-name=m2.sched.grid.com, o=grid";
private int scope = SearchControls.SUBTREE_SCOPE;
private int ldapVersion = 3;
private int sizeLimit = 0;
private int timeLimit = 0;
private boolean ldapTrace = false;
private String saslMech;
private String bindDN;
private String password;
private String qop = "auth"; //could be auth, auth-int, auth-conf
private static AvailableHost ob;//static mean that the values of ob will exist until the program finishs
public GridInfoSearch(){
}

123
public String getTheBestHost(){
GridInfoSearch gridInfoSearch = new GridInfoSearch();
String filter = "(&(Mds-Device-Group-name=processors)(Mds-Cpu-Free-1minX100>=0))";
gridInfoSearch.search(filter);
ob.displayHost();
System.out.println("the best:"+ob.getBestHost());
return ob.getBestHost();
}
//Search the ldap server for the filter specified in the main function
private void search(String filter) {
Hashtable env = new Hashtable();
String url = "ldap://" + hostname + ":" + port;
env.put("java.naming.ldap.version", String.valueOf(ldapVersion));
env.put(Context.INITIAL_CONTEXT_FACTORY, DEFAULT_CTX);
env.put(Context.PROVIDER_URL, url);
if (bindDN != null) {
env.put(Context.SECURITY_PRINCIPAL, bindDN);
}
//use GSI authentication from grid-proxy-init certificate
saslMech = GSIMechanism.NAME;
env.put("javax.security.sasl.client.pkgs",
"org.globus.mds.gsi.jndi");
env.put(Context.SECURITY_AUTHENTICATION, saslMech);
env.put("javax.security.sasl.qop", qop);
LdapContext ctx = null;
//create a new ldap context to hold perform search on filter
try {
ctx = new InitialLdapContext(env, null);
SearchControls constraints = new SearchControls();
constraints.setSearchScope(scope);
constraints.setCountLimit(sizeLimit);
constraints.setTimeLimit(timeLimit);
//store the results of the search in the results variable
NamingEnumeration results = ctx.search(baseDN, filter, constraints);
//displayResults(results);
getAvailableHosts(results);//the results will be stored in ob
} catch (Exception e) {
System.err.println("Failed to search: " + e.getMessage());
} finally {
if (ctx != null) {

124
}
}
}
try { ctx.close(); } catch (Exception e) {}
// Display results of search
private void displayResults(NamingEnumeration results) throws NamingException {
if (results == null) return;
String dn;
String attribute;
Attributes attrs;
Attribute at;
SearchResult si;
}//while
}
//use the results variable from search method and store them in a printable variable.
while (results.hasMoreElements()) {
si = (SearchResult)results.next();
attrs = si.getAttributes();
if (si.getName().trim().length() == 0) {
dn = baseDN;
} else {
dn = si.getName() + ", " + baseDN;
if(dn.substring(0,11).equals("Mds-Host-hn")){
System.out.println("dn: " + dn);
for (NamingEnumeration ae = attrs.getAll(); ae.hasMoreElements();) {
at = (Attribute)ae.next();
attribute = at.getID();
if(attribute.equals("Mds-Cpu-Free-1minX100")){
Enumeration vals = at.getAll();
while(vals.hasMoreElements()) {
System.out.println(attribute + ": " + vals.nextElement());
}
}
}
System.out.println();
}
}//else

125
// Display results of search
private void getAvailableHosts(NamingEnumeration results)throws NamingException {
if (results == null) return;
String dn;
String attribute;
Attributes attrs;
Attribute at;
SearchResult si;
int Mds_Cpu_speedMHz=0;
int Mds_Memory_Ram_Total_freeMB=0;
int Mds_Cpu_Total_count=0;
String Mds_Host_hn="";
int Mds_Cpu_Free_1minX100=0;
//use the results variable from search method and store them in a printable variable.
ob=new AvailableHost();
while (results.hasMoreElements()) {
si = (SearchResult)results.next();
attrs = si.getAttributes();
if (si.getName().trim().length() == 0) {
dn = baseDN;
} else {
dn = si.getName() + ", " + baseDN;
if(dn.substring(0,32).equals("Mds-Device-Group-name=processors")){
System.out.println("dn: " + dn);
for (NamingEnumeration ae = attrs.getAll(); ae.hasMoreElements();) {
at = (Attribute)ae.next();
attribute = at.getID();
if(attribute.equals("Mds-Cpu-speedMHz")){
Enumeration vals = at.getAll();
Mds_Cpu_speedMHz=Integer.parseInt((String)vals.nextElement());
System.out.println(attribute + ": " + Mds_Cpu_speedMHz);
}else if(attribute.equals("Mds-Memory-Ram-Total-freeMB")){
Enumeration vals = at.getAll();
Mds_Memory_Ram_Total_freeMB=
Integer.parseInt((String)vals.nextElement());
System.out.println(attribute + ": " + Mds_Memory_Ram_Total_freeMB);
}else if(attribute.equals("Mds-Cpu-Total-count")){
Enumeration vals = at.getAll();
Mds_Cpu_Total_count=Integer.parseInt((String)vals.nextElement());
System.out.println(attribute + ": " + Mds_Cpu_Total_count);

126
}//for
}else if(attribute.equals("Mds-Host-hn")){
Enumeration vals = at.getAll();
Mds_Host_hn=(String)vals.nextElement();
System.out.println(attribute + ": " + Mds_Host_hn);
}else if(attribute.equals("Mds-Cpu-Free-1minX100")){
Enumeration vals = at.getAll();
Mds_Cpu_Free_1minX100=
Integer.parseInt((String)vals.nextElement());
System.out.println(attribute + ": " + Mds_Cpu_Free_1minX100);
}//else if
}//while
//extract hostname from dn
Mds_Host_hn=(String)dn.substring(dn.indexOf("Mds-Host-hn")+12,
dn.indexOf("mds-vo-name")-2);
System.out.println(Mds_Host_hn);
//add hosts into ArrayList
ob.addHost( Mds_Host_hn,
Mds_Cpu_speedMHz,
Mds_Memory_Ram_Total_freeMB,
Mds_Cpu_Total_count,
Mds_Cpu_Free_1minX100);
}
System.out.println();
}
}
}
//Create new instance of MyGridInfoSearch and use specified filter string
public static void main( String [] args ) {
GridInfoSearch gridInfoSearch = new GridInfoSearch();
String filter = "(&(Mds-Device-Group-name=processors)(Mds-Cpu-Free-1minX100>=0))";
gridInfoSearch.search(filter);
}

127
AvailableHost.java
import java.util.*;
public class AvailableHost{
ArrayList ar;
public AvailableHost() {
ar = new ArrayList();
}
public void addHost( String Mds_Host_hn,
int Mds_Cpu_speedMHz,
int Mds_Memory_Ram_Total_freeMB,
int Mds_Cpu_Total_count,
int Mds_Cpu_Free_1minX100){
ar.add(new Host( Mds_Host_hn,
Mds_Cpu_speedMHz,
Mds_Memory_Ram_Total_freeMB,
Mds_Cpu_Total_count,
Mds_Cpu_Free_1minX100));
}
public void displayHost(){
for(int i=0; i

128
public static void main(String args[]){
AvailableHost ob = new AvailableHost();
ob.addHost("m1.sched.grid.com",2000/*MHz*/,123/*MB*/,1/*cpu*/,70/*%freeCPU*/);
ob.addHost("m2.sched.grid.com",2000/*MHz*/,123/*MB*/,1/*cpu*/,90/*%freeCPU*/);
ob.addHost("m3.sched.grid.com",2000/*MHz*/,123/*MB*/,1/*cpu*/,80/*%freeCPU*/);
ob.displayHost();
ob.displayBestHost();
}//main
}//class AvailableHost
class Host implements Comparable {
private int Mds_Cpu_speedMHz;
private int Mds_Memory_Ram_Total_freeMB;
private int Mds_Cpu_Total_count;
private String Mds_Host_hn;
private int Mds_Cpu_Free_1minX100;
private int Weight;
public Host(
String Mds_Host_hn,
int Mds_Cpu_speedMHz,
int Mds_Memory_Ram_Total_freeMB,
int Mds_Cpu_Total_count,
int Mds_Cpu_Free_1minX100){
}
this.Mds_Host_hn=Mds_Host_hn;
this.Mds_Cpu_speedMHz=Mds_Cpu_speedMHz;
this.Mds_Memory_Ram_Total_freeMB=Mds_Memory_Ram_Total_freeMB;
this.Mds_Cpu_Total_count=Mds_Cpu_Total_count;
this.Mds_Cpu_Free_1minX100=Mds_Cpu_Free_1minX100;
this.Weight=
(int)(Mds_Cpu_Free_1minX100*Mds_Cpu_speedMHz*Mds_Cpu_Total_count/100.00);
public String getHostname(){
return Mds_Host_hn;
}
public int getWeight(){
return Weight;
}

129
public String toString() {
}
return Mds_Host_hn + "\t" + Weight;
//Order by cpu
public int compareTo(Object ob) throws ClassCastException{
Host temp = (Host)ob;
int cpu1=Weight,cpu2=temp.Weight;
if(cpu2>cpu1){
return 1;}
else if(cpu2

130
System.out.println(CentralizedSchedulingJobOut);
System.out.println(gassJob[0].doGetStatus());
// if failed, resubmit it
// waiting for the result
System.out.println("\nWaiting for the centralized scheduling job to finish");
do {
stillRunningJob=false;
if (jobListeners[0].stillActive()) {
stillRunningJob = true;
}
if(jobListeners[0].fail()){
System.out.println("Resubmit:"+CentralizedSchedulingRSL);
gassJob[0]=new GassJob(centralmachine,false);
CentralizedSchedulingJobOut =
gassJob[0].GlobusRun(CentralizedSchedulingRSL);
jobListeners[0]=gassJob[0].getInteractiveJobListener();
stillRunningJob = true;
}//esle if
System.out.print(".");
delay(1000);
jobs.updateJobId(0, gassJob[0].doGetJobId());
jobs.updateStatus(0,gassJob[0].doGetStatus());
} while (stillRunningJob);
System.out.println("\n");
/********************************
*Decentralized scheduling
********************************/
String gassJobOut;
String deRSL;
String theBestMachine;

131
//request all these jobs
for(int i=1; i

132
gassJob[jobCount]=new GassJob(theBestMachine,false);
gassJobOut = gassJob[jobCount].GlobusRun(deRSL);
jobListeners[jobCount]=
gassJob[jobCount].getInteractiveJobListener();
//wait to receive a jobid
//update jobid for this Job
jobs.updateJobId(jobCount, gassJob[jobCount].doGetJobId());
//update machine that is used for this job
jobs.updateMachine(jobCount, theBestMachine);
jobs.updateStatus(jobCount,gassJob[jobCount].doGetStatus());
stillRunningJob = true;
delay(30000);
}//if
}//for
System.out.print(".");
delay(5000);
} while (stillRunningJob);
System.out.println("\n");
}
}//main
GassJob.java
import org.globus.gram.*;
import org.gridforum.jgss.*;
import org.ietf.jgss.*;
import org.globus.security.gridmap.*;
import org.globus.io.gass.server.*;
import org.globus.util.deactivator.Deactivator;
import COM.claymoresystems.sslg.*;
import xjava.security.interfaces.*;
import cryptix.asn1.lang.*;
/**
* Java CoG Job submission class
**/
public class GassJob implements JobOutputListener
{
private GassServer m_gassServer; // GASS Server: required to get job output
private String m_gassURL = null; // URL of the GASS server
private GramJob m_job = null; // GRAM JOB to be executed

133
private String m_jobOutput = "";
private boolean m_batch = false;
private String m_remoteHost = null;
private GSSCredential m_proxy=null;
// job output as string
// Submission modes: batch=do not wait for output
// non-batch=wait for output.
// host where job will run
InteractiveJobListener jobListeners;
// Globus proxy used for authentication against gatekeeper
// Job output variables:
// Used for non-batch mode jobs to receive output from
// gatekeeper through the GASS server
private JobOutputStream m_stdoutStream = null;
private JobOutputStream m_stderrStream = null;
private String m_jobid = null; // Globus job id on the form:
//https://server.com:39374/15621/1021382777/
public GassJob(String Contact, boolean batch) {
m_remoteHost = Contact; // remote host
m_batch = batch; // submission mode
}
/**
* Start the Globus GASS Server. Used to get the output from the server
* back to the client.
*/
private boolean startGassServer(GSSCredential proxy) {
if (m_gassServer != null) return true;
try {
m_gassServer = new GassServer(proxy, 0);
m_gassURL = m_gassServer.getURL();
} catch(Exception e) {
System.err.println("gass server failed to start!");
e.printStackTrace();
return false;
}
m_gassServer.registerDefaultDeactivator();
return true;
}

134
/**
* Init job out listeners for non-batch mode jobs.
*/
private void initJobOutListeners() throws Exception {
if ( m_stdoutStream != null ) return;
// job output vars
m_stdoutStream = new JobOutputStream(this);
m_stderrStream = new JobOutputStream(this);
m_jobid = String.valueOf(System.currentTimeMillis());
}
// register output listeners
m_gassServer.registerJobOutputStream("err-" + m_jobid, m_stderrStream);
m_gassServer.registerJobOutputStream("out-" + m_jobid, m_stdoutStream);
return;
/**
* This method is used to notify the implementer when the status of a
* GramJob has changed.
*
* @param job The GramJob whose status has changed.
*/
public void statusChanged(GramJob job) {
try {
if ( job.getStatus() == GramJob.STATUS_DONE ) {
// notify waiting thread when job ready
m_jobOutput = "Job sent. url=" + job.getIDAsString();
// if notify enabled return URL as output
synchronized(this) {
notify();
}
}
}
catch (Exception ex) {
System.out.println("statusChanged Error:" + ex.getMessage());
}
}

135
/**
* This method is used to get the status of the job
*/
public String doGetStatus(){
return jobListeners.doGetStatus();
}
/**
* This method is used to get the status of the job
*/
public String doGetJobId(){
return m_job.getIDAsString();
}
public InteractiveJobListener getInteractiveJobListener(){
return jobListeners;
}
/**
* It is called whenever the job's output
* has been updated.
*
* @param output new output
*/
public void outputChanged(String output) {
m_jobOutput += output;
}
/**
* It is called whenever job finished
* and no more output will be generated.
*/
public void outputClosed() {
}
public synchronized String GlobusRun(String RSL) {
try {
// load default Globus proxy. Java CoG kit must be installed
//and a user certificate setup properly
ExtendedGSSManager manager =
(ExtendedGSSManager)ExtendedGSSManager.getInstance();
GSSCredential m_proxy =
manager.createCredential(GSSCredential.INITIATE_AND_ACCEPT);

136
// Start GASS server
if (! startGassServer(m_proxy)) {
throw new Exception("Unable to stat GASS server.");
}
// setup Job Output listeners
initJobOutListeners();
// Append GASS URL to job String so we can get some output back
String newRSL = null;
// if non-batch, then get some output back
if ( !m_batch) {
newRSL = "&" + RSL.substring(0, RSL.indexOf('&')) +
"(rsl_substitution=(GLOBUSRUN_GASS_URL " + m_gassURL + "))" +
RSL.substring(RSL.indexOf('&') + 1, RSL.length()) +
"(stdout=$(GLOBUSRUN_GASS_URL)/dev/stdout-" + m_jobid + ")" +
"(stderr=$(GLOBUSRUN_GASS_URL)/dev/stderr-" + m_jobid + ")";
}
else {
// format batching RSL so output can be retrieved later on using any GTK commands
newRSL = RSL +
"(stdout=x-gass-cache://$(GLOBUS_GRAM_JOB_CONTACT)stdout anExtraTag)"
+ "(stderr=x-gass-cache://$(GLOBUS_GRAM_JOB_CONTACT)stderr anExtraTag)";
}
m_job = new GramJob(newRSL);
// set proxy. CoG kit and user credentials must be installed and set
// up properly
m_job.setCredentials(m_proxy);
// if non-batch then listen for output
jobListeners=new InteractiveJobListener(false);
m_job.addListener(jobListeners);
System.out.println("Sending job request to: " + m_remoteHost);
m_job.request(m_remoteHost, m_batch, false);
m_jobOutput = "Job sent. url=" + m_job.getIDAsString();
}
catch (Exception ex) {

137
}
}
if ( m_gassServer != null ) {
// unregister from gass server
m_gassServer.unregisterJobOutputStream("err-" + m_jobid);
m_gassServer.unregisterJobOutputStream("out-" + m_jobid);
}
m_jobOutput = "Error submitting job: " + ex.getClass() + ":"
+ ex.getMessage();
}
// cleanup
//Deactivator.deactivateAll();
return m_jobOutput;
InteractiveJobListener.java
import java.io.*;
import org.globus.gram.Gram;
import org.globus.gram.GramJob;
import org.globus.gram.GramException;
import org.globus.gram.WaitingForCommitException;
import org.globus.gram.GramJobListener;
class InteractiveJobListener extends JobListener {
private boolean quiet;
private boolean finished = false;
private boolean fail=false;
private String strStatus="";
public InteractiveJobListener(boolean quiet) {
this.quiet = quiet;
}
public boolean stillActive() {
}
return !this.finished;
public boolean fail(){
}
return this.fail;

138
// waits for DONE or FAILED status
public synchronized void waitFor() throws InterruptedException {
while (!finished) {
wait();
}
}
public synchronized String doGetStatus(){
}
return strStatus;
public synchronized void statusChanged(GramJob job) {
if (!quiet) {
System.out.println("Job: "+ job.getStatusAsString());
}
status = job.getStatus();
strStatus=job.getStatusAsString();
}
}
if (status == GramJob.STATUS_DONE) {
finished = true;
error = 0;
notify();
} else if (job.getStatus() == GramJob.STATUS_FAILED) {
finished = true;
fail=true;
error = job.getError();
notify();
}
JobListener.java
import org.globus.gram.GramJob;
import org.globus.gram.GramJobListener;
abstract class JobListener implements GramJobListener {
protected int status = 0;
protected int error = 0;
public abstract void waitFor() throws InterruptedException;

139
public int getError() {
}
return error;
public int getStatus() {
}
return status;
public boolean isFinished() {
}
return (status == GramJob.STATUS_DONE ||status == GramJob.STATUS_FAILED);
}
Jobs.java
import java.util.*;
public class Jobs{
public static ArrayList ar;
public Jobs() {
ar = new ArrayList();
ar.add(new Job("centralizedscheduling","",
"& (executable =/usr/study/coursescheduling/centralizedscheduling)","m2.sched.grid.com","",0));
ar.add(new Job("decentralizedschedulingER","",
"& (executable =/usr/study/coursescheduling/decentralizedscheduling.exe)
(arguments=ER)", "","",0));
ar.add(new Job("decentralizedschedulingSC","",
"& (executable =/usr/study/coursescheduling/decentralizedscheduling.exe)
(arguments=SC)", "","",0));
ar.add(new Job("decentralizedschedulingED","",
"& (executable =/usr/study/coursescheduling/decentralizedscheduling.exe)
(arguments=ED)", "","",0));
}
//get a job that has index i
public Job getJob(int i){
return (Job) ar.get(i);
}
public int getSize(){
return (int) ar.size();
}

140
//get RSL of Job having index i
public String getRSL(int i){
Job ob= getJob(i);
return ob.getRSL();
}
//get Machine of Job having index i
public String getMachine(int i){
Job ob= getJob(i);
return ob.getMachine();
}
//get Status of Job having index i
public String getStatus(int i){
Job ob= getJob(i);
return ob.getStatus();
}
//update a new jobid for the job that has index i
public void updateJobId(int i, String jobid ){
Job oldJob= getJob(i);
ar.set(i, new Job( oldJob.getJobName(),
jobid,
oldJob.getRSL(),
oldJob.getMachine(),
oldJob.getStatus(),
oldJob.getExectime()));
}
//update a new machine for the job that has index i
public void updateMachine(int i, String machine){
Job oldJob= getJob(i);
ar.set(i, new Job( oldJob.getJobName(),
oldJob.getJobId(),
oldJob.getRSL(),
machine,
oldJob.getStatus(),
oldJob.getExectime()));
}

141
//update a new jobid for the job that has index i
public void updateStatus(int i, String status){
Job oldJob= getJob(i);
ar.set(i, new Job( oldJob.getJobName(),
oldJob.getJobId(),
oldJob.getRSL(),
oldJob.getMachine(),
status,
oldJob.getExectime()));
}
public void displayJobs(){
for(int i=0; i

142
class Job {
private String jobname;
private String jobid;
private String RSL;
private String machine;
private String status;
private int exectime;
public Job(String jobname, String jobid, String RSL, String machine, String status, int exectime){
this.jobname = jobname;
this.jobid = jobid;
this.RSL = RSL;
this.machine = machine;
this.status = status;
this.exectime= exectime;
}
public String getJobName(){
return jobname;
}
public String getRSL(){
}
return RSL;
public String getJobId(){
}
return jobid;
public String getMachine(){
}
return machine;
public String getStatus(){
}
return status;
public int getExectime(){
}
return exectime;

143
public void updateJobId(String jobid ){
}
this.jobid = jobid;
public void updateMachine(String machine ){
}
this.machine = machine;
public void updateStatus(String status){
}
this.status = status;
public String toString() {
}
return jobname + "\t" + machine + "\t" + status + "\t" + exectime;
}//class Job

145
BIOGRAPHY
Name : Mr. Nguyen Cong Danh
Thesis Title : Course Scheduling in Multiple Faculties Using a Grid Computing
Environment
Major Field : Information Technology
Biography
I graduated with a bachelor’s degree in Computer Science from Cantho
University (Vietnam) in 2000.
My contact address is 1 Ly Tu Trong street, Ninh Kieu district, Cantho city,
Vietnam. My e-mail address is ncdanh@cit.ctu.edu.vn.