Download Using Graph Coloring and more Study Guides, Projects, Research Operational Research in PDF only on Docsity!
On Using Graph Coloring to Create University Timetables with
Essential and Preferential Conditions
TIMOTHY A. REDL
University of Houston-Downtown Department of Computer and Mathematical Sciences One Main Street, Suite S705, Houston, Texas UNITED STATES OF AMERICA [email protected]
Abstract: We develop and describe a mathematical and computational model for creating university timetables us- ing techniques and heuristics of graph coloring that incorporates the satisfaction of both essential and preferential timetabling conditions. The model involves creating a conflict graph from assembled university course data, prop- erly coloring the conflict graph, and transforming this coloring into a conflict-free timetable of courses. From this timetable, one can then assign the courses to classrooms based on room capacity and availability. Once a course timetable is constructed, a conflict-free schedule of final examinations for the courses can quite easily be obtained.
Key–Words: university timetabling, graph coloring
1 Introduction
Timetabling is the scheduling of a set of related events in a minimal block of time such that no resource is required simultaneously by more than one event. In university timetabling, the resources involved, which we assume may be required by no more than one course at any particular time, are instructors, class- rooms, and students. University timetabling is a prac- tical application of graph coloring. The minimum col- oring problem and the timetabling problem have been classified as NP-hard problems in the general case. This means that it is unlikely that it will be possi- ble to find fast (i.e., polynomial-time) algorithms to solve these problems. In order to find optimal solu- tions to such NP-hard problems, it is usually neces- sary to consider all possible solutions to choose the best one. However, solutions to large-scale practical problems, including timetabling, are often desired and needed much more quickly than any exhaustive search algorithm could hope to provide. As a result, numer- ous heuristics have been developed for such problems which produce “near-optimal” satisfactory solutions in much less time. University course timetabling problems involve pairwise restrictions on the courses being scheduled. That is, there exist restrictions on which courses can be scheduled simultaneously. Restrictions involved in creating a timetable of courses may be divided into two categories, which we call essential and preferen- tial timetabling conditions.
1.1 Essential and Preferential Conditions
Essential timetabling conditions are conditions or constraints that must be satisfied in order to produce a legal or feasible timetable. A few examples of essen- tial timetabling conditions include the following:
- Two or more courses taught by the same instruc- tor cannot be scheduled for the same time slot [7, among others].
- Two or more courses that require the same class- room cannot be scheduled for the same time slot [7, among others].
- Equivalently, two or more courses scheduled for the same time slot cannot be assigned the same classroom [5, among others].
- Instructors must be available at the times their courses are scheduled [4].
- Each course must be scheduled for exactly one time slot and one room, to remain constant throughout the scheduling period [3].
- Some courses are required to meet a certain fixed number of times per week (e.g., 3 times per week, 2 times per week, or 1 time per week) [5].
- Each course must be scheduled in an available classroom that can accommodate its size [1, among others].
- Specific outlined room requirements/type for a particular course, if any (e.g., a laboratory workspace, or a computer workstation with pro- jection screen) should be taken into account [5, among others].
- Any courses marked as “prescheduled” should be scheduled to the specified time [3, among oth- ers].
- Courses which enroll the same set of students (for example, a chemistry lecture course and its accompanying laboratory course) cannot be scheduled for the same time slot [5].
Preferential timetabling conditions are additional conditions or constraints that need not necessarily be satisfied to produce a legal or legitimate timetable, but if satisfied may very well produce a more “acceptable” timetable for students and/or faculty members. These conditions are requests that should be fulfilled, if pos- sible. Preferential timetabling conditions are often reasonable, but it may or may not be possible to fulfill each of them in addition to all of the essential con- ditions. A few examples of preferential timetabling conditions might include the following:
- An instructor may have a time preference as to when a course is scheduled to meet (e.g., in the morning, afternoon, or evening).
- An instructor may have a specific room request for a course, beyond the scope of the outlined room requirements specified above (this is an ex- ample illustrating the sometimes “fine line” be- tween an essential and preferential timetabling condition).
- It might be preferable to assign each course to a classroom that is located in or close to the build- ing in which that course’s department or school is based, and/or close to the office of the course’s instructor [3, among others].
- Most courses should not be scheduled in the evening, but rather during the morning and after- noon (i.e., during “normal business hours”), un- less an evening time slot is specifically requested for a particular course [1, among others].
- Try to schedule sufficiently large courses at times that “minimize pain for students” [8].
- Classrooms should be just large enough to hold the courses in them, in order to eliminate the presence of unused empty space [3]. - Minimize the number of classrooms used or needed when scheduling the courses [1]. - Attempt for an even distribution of courses among time slots; this will aid in room assign- ment and also allow for maximum utilization of resources [2, among others].
In addition to the above as well as other essential and preferential timetabling conditions, we also incor- porate the following observations in our model:
- Many university courses meeting 3 times per week are usually scheduled to meet on Mon- days, Wednesdays and Fridays for periods of 1 hour each (or 50 minutes, allowing 10 minutes of travel time for students between classes), for a total of 3 hours per week.
- Many university courses meeting 2 times per week are usually scheduled to meet on Tuesdays and Thursdays for periods of 1 12 hours each (or 80 minutes, allowing 10 minutes of travel time for students between classes), for a total of 3 hours per week.
- Many university courses meeting 1 time per week are usually scheduled to meet for a period of 3 hours (or 170 minutes, allowing 10 minutes of travel time for students between classes) on either Mondays, Tuesdays, Wednesdays, Thurs- days, or Fridays (i.e., there are no Saturday or Sunday courses).
2 Assembling Course Data
Before the timetabling of university courses for a particular semester can take place, we must first assemble a collection of university course data for that semester, to serve as input to our problem in- stance. Each course to be scheduled constitutes a data entry, containing the required or optional information below. Such information is expected to be supplied by either the instructor of the course, the academic department or school to which the course belongs, or some other appropriate source.
Required Data Fields :
- COURSEID : The “name” of the course, identi- fied by academic department and course number (for example, MATH101). If a course has mul- tiple sections, each section will be entered as a different course.
allow all r of those courses to be assigned that room, then we introduce a clique of order r to our graph, so that each of the r courses is scheduled for a different time slot. We may not be able to honor all or even most requests for a particular room. However, there are often several rooms of the same room type at a university. If a requested room is unavailable, there may be another available room of similar type and size that would suit just as well. We can also add an edge between: (1) each vertex in Group 1 and Group 5, and (2) each vertex in Group 1 and Group 6, and (3) each vertex in Group 1 and Group 7, and (4) each vertex in Group 1 and Group 8, and (5) each vertex in Group 2 and Group 5, and (6) each vertex in Group 2 and Group 6, and (7) each vertex in Group 2 and Group 7, and (8) each vertex in Group 2 and Group 8, and (9) each vertex in Group 3 and Group 5, and (10) each vertex in Group 3 and Group 6, and (11) each vertex in Group 3 and Group 7, and (12) each vertex in Group 3 and Group 8, and (13) each vertex in Group 4 and Group 5, and (14) each vertex in Group 4 and Group 6, and (15) each vertex in Group 4 and Group 7, and (16) each vertex in Group 4 and Group 8. Lines (1) through (16) above reflect both NUM- DAYS and DAYS preferences. A course ci that re- quests to meet 3 days (MWF) per week will be sched- uled for a different time slot than a course cj that re- quests to meet 2 days (TR) per week. We can also add an edge between: (17) each vertex in Group 1 and Group 2, and (18) each vertex in Group 1 and Group 3, and (19) each vertex in Group 2 and Group 3, and (20) each vertex in Group 5 and Group 6, and (21) each vertex in Group 5 and Group 7, and (22) each vertex in Group 6 and Group 7. Lines (17) through (22) above strictly reflect TIMEOFDAY preferences. Two courses that request to meet on the same days but at different general times of the day will be scheduled for different time slots. We can also add an edge between: (23) each vertex in Group 3 and each vertex vi in Group 4, if TIMEOFDAY of course ci = “4”, and (24) each vertex in Group 7 and each vertex vi in Group 8, if TIMEOFDAY of course ci = “4”. Lines (23) and (24) above specifically reflect “not in the evening” TIMEOFDAY preferences. Courses that request “not in the evening” will not be scheduled for evening time slots. To reflect TIMEOFDAY preferences for courses represented by vertices in Group 9, we add edges to G as follows. For each vertex vi in Group 9 correspond- ing to a course ci, we add an edge between:
(25) vi and Groups 2, 3, 6 & 7, if TIMEOFDAY of ci = “1”, or (26) vi and Groups 1, 3, 5 & 7, if TIMEOFDAY of ci = “2”, or (27) vi and Groups 1, 2, 5 & 6, if TIMEOFDAY of ci = “3”, or (28) vi and Groups 3 & 7 if TIMEOFDAY of ci = “4”. Finally, we reflect DAYS and/or TIMEOFDAY preferences for courses represented by vertices in Group 10 by adding edges to G as follows. For each vertex vi in Group 10 corresponding to a course ci, we add an edge between: (29) vi and Groups 5, 6, 7 & 8, if DAY of ci = “M”, “W”, or “F”, or (30) vi and Groups 1, 2, 3 & 4, if DAY of ci = “T” or “R”, and (31) vi and Groups 2, 3, 6 & 7, if TIMEOFDAY of ci = “1”, or (32) vi and Groups 1, 3, 5 & 7, if TIMEOFDAY of ci = “2”, or (33) vi and Groups 1, 2, 5 & 6, if TIMEOFDAY of ci = “3”, or (34) vi and Groups 3 & 7, if TIMEOFDAY of ci = “4”.
4 Coloring the Conflict Graph
After constructing our course conflict graph, we can then properly color its vertices, and ultimately use that proper vertex coloring to construct a conflict-free timetable of courses. Recall that in a proper vertex coloring of a graph G, a pair of vertices vi and vj are colored with different colors if there is an edge be- tween them. Vertices that do not share an edge may be colored with either different colors or the same color. Our general approach will follow that of the se- quential graph coloring algorithm. Sequential graph coloring algorithms are commonly referred to as “greedy algorithms”. A greedy graph coloring algo- rithm examines each vertex of the graph one at a time according to some particular order and tries to color the vertex with one of the colors used so far; that is, it tries to add the vertex to one of the existing color classes. If this is not possible, then a new color class is created and the vertex is assigned the color of that new class. Greedy sequential graph coloring algorithms at- tempt to properly color a graph using the minimum number of colors possible. Four greedy graph coloring algorithms (SIMPLE- SEARCH GREEDY (SSG), LARGEST-FIRST- SEARCH GREEDY (LFSG), SMALLEST-FIRST- SEARCH GREEDY (SFSG), and RANDOM- SEARCH GREEDY (RSG)) were each implemented with the ability to accommodate each of four different
initial orderings of the vertices of the graph: 1) a specific predefined ordering (SO); 2) an ordering by decreasing degree (DD) (i.e., largest-degreed vertices first); 3) an ordering by smallest degree (SD) (i.e., smallest-degreed vertices first); and 4) a purely ran- dom ordering of the vertices (RO). These four greedy graph coloring algorithms (SSG, LFSG, SFSG, and RSG), each with four potentially different initial vertex orderings (SO, DD, SD, and RO), resulted in implementations of 16 different variations of the greedy or sequential approach to graph coloring [6]. Our goal is to properly color the vertices of our conflict graph using one of the 16 above greedy graph coloring variations and thereby partition our vertices into independent color classes. These color classes designate sets of courses which can safely be assigned to the same time slot without conflicts. Vertices corre- sponding to courses which cannot be assigned to the same time slot due to potential conflicts will be col- ored with different colors in our model. We propose coloring the vertices of our graph in “Group Order”, by first coloring all the vertices in Group 1, then Group 2, then Group 3, then Group 4, then Group 5, then Group 6, then Group 7, then Group 8, then Group 9, and then finally Group 10. Additionally, there are various ways in which we can order the courses/vertices in each group. Within each vertex group we could:
- sort courses by COURSEID , (e.g., departments with a larger number of courses to be scheduled in a particular vertex group would be colored be- fore departments with fewer courses), or
- sort courses by INSTRUCTOR , (e.g., instructors with greater seniority or more courses to be scheduled in a particular vertex group would be colored before instructors with less seniority or fewer courses to be scheduled, and any courses currently without a known instructor could be colored last), or
- sort courses in the order in which their preference requests were received by the scheduler , so that in each vertex group, we “reward” instructors for submitting their course preference requests early, and course vertices are colored on a “first come, first served” basis, or
- sort courses by (CLASSMAXSIZE) , so that in each vertex group we color vertices correspond- ing to larger-sized courses first, followed by those corresponding to smaller-sized courses, or
- sort courses in random order , so as not to in- tentionally “favor” any particular course over an- other when coloring.
In addition, we could choose to “precolor” par- ticular vertices in our course conflict graph, based on some priority criteria. Such vertices or courses would be preassigned a specific color and/or preassigned a specific time slot prior to the actual coloring and timetabling procedure, in such a way as to satisfy an essential timetabling condition that any courses desig- nated as “prescheduled” should be scheduled to their respective specified time slots. Of course, we must be careful to properly precolor vertices corresponding to such courses, so as not to induce any immediate con- sequential scheduling conflicts! One of the preferential timetabling conditions described earlier in this paper calls for an attempt to maintain an even distribution of courses among time slots, which should ultimately aid in room as- signment and also allow for maximum utilization of university resources. Such a condition is of- ten strongly preferred by both small-sized and large- sized universities. Therefore, for purposes of uni- versity course timetabling, it appears that one par- ticular “color searching procedure”, namely that in the SMALLEST-FIRST-SEARCH GREEDY algo- rithm variation, will be the most preferable to use in coloring our conflict graph. During the coloring pro- cedure, SFSG ranks the color classes by the num- ber of vertices currently in them, and searches this ranked list of color classes in order by ascending size. Based on this searching heuristic, SFSG attempts to balance the size of the color classes. If color classes correspond to time slots in our timetabling-by-graph- coloring model, then the SFSG color searching pro- cedure should greatly aid in satisfying the above pref- erential timetabling condition of even distribution of courses among time slots as much as possible.
5 Computational Results
To test the effects of a variety of different color search- ing procedures as well as the effects of a variety of dif- ferent initial vertex orderings on graph coloring per- formance, we conducted computational experiments involving each of the above 16 greedy algorithm vari- ations and the coloring of different conflict graphs G arising from data obtained from Rice University and the University of St. Thomas in Houston, TX. De- tailed results of such experiments, along with an in- depth analysis of said results, appear in [6] and are summarized briefly below.
- Rice University, Fall 2000: G has 749 vertices, 147,440 edges; chromatic number χ(G) = 11 (verified by OPLStudio), with computing time for all colorings between 0.03 and 0.09 seconds
