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