6. Course Combinations
Course Combinations are the primary way for the Engine to respond to the needs of
students. The Engine needs information to schedule sections so that students can
register in the courses they need to progress through their chosen programs in a timely
manner. The Engine accepts this information in what we call Course Combinations.
Course combinations are lists of courses that a student or group of students take in the
same term. Therefore, enough seats to accommodate those students must be
scheduled at different times. Course combinations are usually determined by the
structure of the program as determined by the academic unit, but sometimes they reflect
an informal organization of courses that reflects the best advice of local academic
advisors and student preferences.
In the simplest case, suppose the fall term of the first year of a program in Pataphysics
(PTPH) is completely determined as follows: ENGL 100, PTPH 130, PHIL 100, HIST
100, and PSYC 100. And let us suppose we expect 35 students to take this program in
fall of year one. Our course combination for the fall term of year-one of PTPH would
look like this:
PTPH-1 (YR=1, Term=F, #=35): ENGL 100 + PTPH 130 + PHIL 100 +
HIST 100 + PSYC 100
The timetable engine will ensure that 35 seats in sections of each of these courses are
scheduled at different non-conflicting times.
But things quickly get more complicated: For example, let us imagine that the second
term of the first year of our Pataphysics (PTPH) program can be described as follows:
Students take ENGL 110, PTPH 100, PHIL 110, one of either FR 110 or GER 100, and
any other course as an elective. We would represent this in two course combinations:
PTPH-2 (YR=1, Term=W, #=?): ENGL 110 + PTPH 100 + PHIL 110 + FR 110
PTPH-3 (YR=1, Term=W, #=?): ENGL 110 + PTPH 100 + PHIL 110 + GER 100
Notice that we do not include both FR 110 and GER 100 in a single course combination
because, for this program, these two courses do not have to be scheduled at different
times.
An estimate of the number of students who will be in each of these variants of the
program is also essential. This allows us to ensure that only the needed number of
seats are free of conflict. The students who take the courses described in course
combination PTPH-2 do not need to be in an ENGL 110 section that is scheduled at a
different time from GER 100. Similarly, the students who take the courses described in
course combination PTPH-3 do not need to be in an ENGL 110 section that is
scheduled at a different time than FR 110. Seats for the students in this program may
end up in different sections of ENGL 110. Let us suppose 10 students are expected to
follow PTPH-2 and 25 students are expected to follow PTPH-3. Our course
combinations record this:
1
PTPH-2 (YR=1, Term=W, #=10): ENGL 110 + PTPH 100 + PHIL 110 + FR 110
PTPH-3 (YR=1, Term=W, #=25): ENGL 110 + PTPH 100 + PHIL 110 + GER
100
Given this information, the engine will make sure there are 10 conflict-free seats in
sections of ENGL 110, PTPH 100, PHIL 110, and FR 110. It will also make sure 25
conflict-free seats are available in sections of ENGL 110, PTPH 100, PHIL 110, and
GER 100.
As the number of variants of a program increase, the number of course combinations
associated with the program, year and term increases. For, example a program
described as follows would require eight separate course combinations: Students must
take MATH 110, PHYS 100, either CS 100 or BIOL 100, and one of CHEM 140, 105,
104, or 100. Can you create them?
Now suppose we have a program that allows an open elective in a term. We do not
attempt to create a separate course combination for each possible combination of the
required courses and every open elective offered at the university. There are simply too
many to deal with. For this kind of free choice, we rely on the natural distribution of
courses to give students a choice. However, if an advisor in a unit knows from
experience that 90% of the students in the unit’s program take a particular course as
their elective, then creating a course combination that includes this specific course is a
worthwhile.
Some programs have so little structure that course combinations cannot easily be
created. But it may still be of vital importance to students that core courses are
scheduled conflict free. Department planners can ensure this by building representative
course combinations that present two or more of the department’s core courses, even
though these courses are not required to be taken together. Enrolments for these “fake”
course combinations can be set at one, merely to ensure that the timetable engine
places at least one section of each course at different times. Department and faculty
advisors may also have experience about course combinations that are often taken by
students, although they are not required. These too should be represented as course
combinations with estimated enrolments. We also expect that many programs will
generate course combinations that are not specific to either term. These combinations
will be placed in every term regardless of whether courses mentioned are offered or not.
That is, they will act only when the courses mentioned are on offer.
The whole point of the exercise is to give the timetabling engine as much information as
possible in order to have it create a timetable that satisfies the greatest number of
student-needs, while using the least possible amount of classroom space.
When you first see the Engine’s data base, you will find more than a thousand course
combinations already entered. Staff in the Registrar’s Office have spend many hours
creating course combinations based on the Calendar and on registration patterns from
2
previous terms, in order to give you a starting point. We have created more than a
thousand of these. But these cannot replace the experience advisors and schedulers
can bring to this process.
And this brings out a point that should be noted: The academic unit that offers the
program is the unit that creates the course combinations for its program, regardless of
which units offers the courses mentioned in the course combinations. (The academic
unit that offers the sections, however, retains complete control over which and how
many sections of each course they will offer.)
7. Academic Blocks
Academic blocks are a more precise version of course combinations. They allow the
Engine to respond to student needs at the section level, rather than course level. The
Engine does not place every course listed in a course combination at a different time.
Rather it places the requested number of seats needed, at different times. So it groups
together demands from across the university, for a given course, to fill the sections on
offer and then places those sections in a conflict-free timetable. The Engine does this
by turning course combinations into what we call academic blocks and working with the
latter at the level of available sections.
But this also allows us to intercede manually in special cases where conflict-free
scheduling is required at the section level. We can, for example, ensure that a specific
number of seats in a specific section are offered at a different time than the same
number of seats in another section. This allows us to place one specific section
targeted at a particular cohort of students at a different time from the other targeted
sections they must take. For example, we can be sure that the specific section of PTPH
100 especially designed for students in, say, Petroleum Engineering is offered at a time
when these students do not have other courses scheduled. (The registration
restrictions used in Self Serve that control access to a section are entirely independent
of the information in the Engine, and must be maintained independently.)
8. Student Restrictions
Students need to have reasonable daily course loads, so there are another set of
restrictions that the Engine uses to restrict how it schedules sections. We can set the
maximum number of hours that students can have in a day, so too many sections to
satisfy one course combination cannot be placed on the same day. We can limit the
number of hours in a row that a student should have. We can allow or not allow a
student’s sections to be scheduled back-to-back. And we can restrict the number of
maximum number of hours over which a single day’s classes can be spread, so the
student is not forced to stay on campus all day for, say, two hours of class.
Again, the course combination is a proxy for the students in a program. The Engine
cannot force students to register so that they do not have more than the maximum
allowed hours in a day. It can only ensure that the student has an opportunity to
register in a way that avoids unreasonable daily course loads.
3
9. Instructor Restrictions
Just as with students, instructors must have reasonable daily schedules. Most
basically, the Engine ensures that no instructor must teach in two different places at the
same time. But it can also restrict daily scheduling in the same was as it does for
students. We can set the maximum number of hours that instructors can teach in a day.
We can limit the number of hours in a row that an instructor can teach. We can allow or
not allow instructors to be scheduled to teach back-to-back sections. And we can
restrict the maximum number of hours over which a single day’s teaching can be
spread, so an instructor is not forced to stay on campus all day to deliver, say, a onehour early-morning lecture and a one-hour late-afternoon lecture. We can even insert a
minimum break between the end of an evening course and the beginning of any course
scheduled for that instructor on the following day.
Department meetings can also be accommodated. Instructors are associated with
departments. And using this association, the Engine allows us to block off a single
period of time for all instructors associated with a given department.
10. Timing Patterns
When we create a course section, we need to pick a pattern of delivery for it. The
beginning and end of the daytime class period and the beginning and end of the
evening class period are set globally. Within one or other of these periods there are a
number of “classical” delivery patterns available. Most courses will fit into one of the
following patterns:
 D3X1: Three one-hour meetings spread over three days, with each meeting
occurring in the day
 E3X1: Three one-hour meetings spread over three days, with each meeting
occurring in the evening
 D2X1.5: Two one-and-one-half-hour daytime meetings spread over two days
 E2X1.5: Two one-and-one-half-hour evening meetings spread over two days
 D1X3: One daytime meeting of three hours
 E1X3: One evening meeting of three hours
There are some other more unusual patterns for non-classical meeting patterns. For
example, we have allowed for single one-hour and single four-hour classes. We have
also allowed classes that run for one hour each on Tuesday, Thursday and Friday (in
order to offset the inefficiencies created by Monday and Wednesday 1.5 hour classes).
11. Relating the Timing of Meetings
In some cases the manner in which meetings of a section are organized needs to be
more subtle. For example, it is possible to link labs and tutorials and lectures so that
they are ordered in particular ways. We can tie tutorials together so they occur one
after the other in a row. We can tie labs or tutorials so they occur after within a given
period of time after a lecture or, alternatively, so there must be a given period of time
between them and the lecture.
4
12. Rooms Requests
In what we have called the location area of information for a section, we record the kind
of room that is needed for a given section. The Engine recognizes the university as
having various types of rooms. These include lecture theatres, smart classrooms,
classrooms, special rooms, and computer laboratories. The unit can request one of
these for each section. Unfortunately, we do not have enough of some of each of these
types to satisfy every request. So the if the Engine cannot place a section in the
requested room type, it will look for the next best solution.
The Engine also recognizes our rooms as having characteristics such as having tables,
having tablets, having a lot of white board area, being wheelchair accessible, and so on.
When a request for some of these characteristics is attached to a section, the Engine
will attempt to build a timetable in which these requests are satisfied.
Finally we can tell the Engine which part of the campus would be preferable for a given
section. So, units can direct the Engine to schedule a given section in the same
building as the offering department or instructor’s office, if possible. Again, while every
request cannot be filled, the Engine will build a master timetable that maximizes the
satisfaction of all requests.
13. Forcing Times
What can it hurt if just one small class of say 50 students is forced to be at 1:00 pm on
Tuesday? This turns out to create a huge impediment to making a master timetable
that satisfies the needs of students and instructors. Let us look at only one thread in a
very simple case: Assume that just 20 of these 50 students each need just one course
that is different from the other 49 students. This means there are now 20 sections that
cannot be offered at 1:00 p.m. on Tuesday. But in each of these 20 classes, suppose
there are 10 students who need a class that the others do not need. Now there are 200
more sections that cannot be offered at 1:00 p.m. on Tuesday. And each of those
sections has students with different needs. But we must also add in the complications
of instructor schedules for the teachers of these 220 sections, the room-types needed
for them, and timing patterns they each require. The ripple keeps expanding outwards!
It turns out that allowing even a single section to “pick a time,” creates significant
constraints on the creation of a master time table that will satisfy the needs and
preferences of students and instructors. Forcing times is deadly to the optimizing
process.
But we must force some times. For example, we have are video-linked courses that are
offered simultaneously at two or more institutions or locations. We have courses that
require outdoor daylight meetings. We have course that require outdoor evening
meetings. There are instructors with severe medical challenges that make teaching at
certain times all but impossible. We have contract instructors who have day jobs that
make teaching in the evening a requirement. All this impedes the creation of an optimal
5
master timetable, but we must accommodate these needs. However, accommodating
these essential needs may leave little possibility of satisfying less pressing preferences
for specific teaching times.
6