Package ttsolver

Purdue University Timetabling.

See:
Description

Class Summary

Test	A main class for running of the solver from command line.
TimetableLoader	Abstract timetable loader class.
TimetableModel	Timetable model.
TimetableSaver	Abstract timetable saver class.
TimetableXMLLoader	This class loads the input model from XML file.
TimetableXMLSaver	This class saves the resultant solution in the XML format.

Package ttsolver Description

Purdue University Timetabling.

In timetabling problem at Purdue University a timetable for large lecture classes is constructed by a central scheduling office in order to balance the requirements of many departments offering large classes that serve students from across the university. Smaller classes, usually focused on students in a single discipline, are timetabled by “schedule deputies” in the individual departments. Such a complex timetabling process, including subsequent student registration, takes a rather long time. Initial timetables are generated about half a year before the semester starts. The importance of creating a solver for a dynamic problem increases with the length of this time period and the need to incorporate the various changes that arise.

As for Fall 2004 semester, this problem consists of about 830 classes (forming almost 1800 meetings) having a high density of interaction that must fit within 50 lecture rooms with capacities up to 474 students. Room availability is a major constraint for Purdue. Overall utilization of the time available in rooms exceeds 78%; moreover, it is around 94% for the four largest rooms. About 90,000 course requests by almost 30,000 students must also be considered. 8.4% of class pairs have at least one student enrolment in common.

The timetable maps classes (students, instructors) to meeting locations and times. A major objective in developing an automated system is to minimize the number of potential student course conflicts which occur during this process. This requirement substantially influences the automated timetable generation process since there are many specific course requirements in most programs of study offered by the University.

To minimize potential time conflicts, Purdue has historically subscribed to a set of standard meeting patterns. With few exceptions, 1 hour x 3 day per week classes meet on Monday, Wednesday, and Friday at the half hour (7:30, 8:30, 9:30, ...). 1.5 hour x 2 day per week classes meet on Tuesday and Thursday during set time blocks. 2 or 3 hours x 1day per week classes must also fit within specific blocks, etc. Generally, all meetings of a class should be taught in the same location. Such meeting patterns are of interest to the problem solution as they allow easier changes between classes having the same or similar meeting patterns.

Student Sectioning

Many courses at Purdue University consist of several sections, with students enrolled in the course divided among them. Sections are often associated together by some constraints. For example, sections of the same course should not overlap. Each such section forms one class which has its own preferences. Therefore each is treated separately - there is a variable for each section.

An initial sectioning of students into course sections is processed. This student sectioning is based on Carter's homogeneous sectioning and it is intended to minimize future student conflicts. However, there is still a possibility of improving the solution with respect to the number of student conflicts. This can be achieved via section changes during the search.

In the current implementation, sectioning is altered only by switching student enrolments between two different sections of the same course. Each student enrolment in a course with more than one section is processed. An attempt is made to switch it with a student enrolment from a different section. If this switch decreases the total number of student conflicts, it is applied.

Current implementation the students are switched in the current solution, before it is stored as the best solution. All classes are processed and attempted switches are made between students in the same course. Note that a switch of a student enrolment can be followed with subsequent switches, so that classes can be processed more than once.