INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

INTERFACESVol. 47, No. 6, November–December 2017, pp. 537–554

http://pubsonline.informs.org/journal/inte/ ISSN 0092-2102 (print), ISSN 1526-551X (online)

Near-Optimal Course Scheduling at the TechnionOfer Strichmana

a Information Systems Engineering, Faculty of Industrial Engineering and Management, Technion–Israel Institute of Technology,Haifa 3200003, IsraelContact: ofers@ie.technion.ac.il (OS)

Received: May 8, 2016Revised: August 31, 2016; January 25, 2017;February 22, 2017Accepted: February 25, 2017

https://doi.org/10.1287/inte.2017.0920

Copyright: © 2017 INFORMS

Abstract. The focus of this article is the automation of course, classroom, and examscheduling for the faculty of Industrial Engineering (IE) at the Technion in Haifa, Israel.The system, called the Technion Industrial Engineering Scheduler (TieSched), has beenoperational since 2012. It is based on a distributed collection of constraints and multipleengines running in parallel, including SAT, pseudo-Boolean, CSP, and weighted-Max-SATsolvers. A sophisticated decision support subsystem accommodates manual edits to theschedule. This article describes the manual process used previously and the TieSched sys-tem architecture, and it provides details about themodel formulation and solving engines.It also presents the new process that TieSched enables and the path to stakeholder accep-tance. The benefits of TieSched include improved efficiency of the scheduling process (i.e.,a reduction from 9–10 to 3–4 weeks), better schedules, and enhanced levels of service toteachers, assistants, and students.

History: This paper was refereed.

Keywords: education systems: planning • integer programming: applications • decision analysis: applications

IntroductionEach of the 18 faculties (departments) in the Technionin Haifa, Israel, has a dedicated administrative assis-tant (the “assistant” in the remainder of this paper) tohandle administrative tasks that are related to teach-ing issues. Most of an assistant’s time is dedicated toscheduling courses, classrooms, and exams. The assis-tant is the only person within a faculty who has anoverall view of the goals and their relative importance;however, if a conflict that the assistant cannot solvearises, the dean or vice dean might intervene. Thescheduling process involves a significant number ofhidden priorities. In practice, the assistant determinesthese priorities in an ad hoc manner. For example, anassistant must determine if granting a teacher’s requestto teach in a specific slot (i.e., a specific day and hour)outweighs scheduling that class such that it overlapswith an elective course; or the assistant might have todecide if preventing a gap in the schedule outweighsallowing a teaching assistant (TA) to take a graduate-student course. Similar problems exist with schedulingexams; for example, how should the days allocated toexams be split among the various courses? These are

important decisions thatmust bemade at a higher levelthan the administrative assistant and applied as uni-formly and as transparently as possible. Furthermore,even if the priorities are explicit, the number of con-siderations and possible combinations is so large, thatusing a manual process to find a near-optimum sched-ule is virtually impossible.

The industrial engineering (IE) faulty in the Tech-nion is relatively large in that it comprises four under-graduate tracks and nine graduate tracks and has com-plex teaching requirements. The programs in eachtrack change every few years; as a result, the schedul-ing requirements are determined not only by the track,but also by the year and semester in which the stu-dents were admitted. The complexity of the schedul-ing process led the Technion to attempt to automateit five times between the late 1970s and the 1990s.All these attempts, which were focused solely on anautomated scheduling engine, failed. The schedulesgenerated were inadequate because many constraintswere not considered, and the constraints of the teachersand TAs were never entered completely. The assis-tant apparently found that asking a teacher when to

537

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion538 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

schedule his (her) course was easier than entering his(her) constraints.Our automated scheduler TieSched and its periph-

eral subsystems became operational in 2012 and havesince evolved. TieSched’s automated schedulermoduleattempts to cope with the computational complexityof the problem by running multiple engines in par-allel, most of which are based on SAT (propositionalsatisfiability solvers) and CSP (constraints solvers)technologies.

The Manual Process Prior to TieSchedThe manual course-scheduling process has fourphases. The first phase—scheduling the lectures—isdone synchronously among all faculties. One week ofthe scheduling process is dedicated to each of the sixsemesters of studies. Although most programs com-prise eight semesters, the last two semesters includeonly electives, which do not require coordination andare relatively easy to schedule. For example, in the firstweek of the scheduling period, all assistants schedulethe first-semester-level courses taught in their facul-ties; in the second week, they schedule the second-semester-level courses. This synchronous approachensures the cross-faculty coordination that is requiredfor scheduling joint courses. Generally an assistantattempts to start with the previous year’s schedule anduses it as a basis for making changes. The schedulingis based on an estimation of the demand; for exam-ple, the assistant estimates howmany recitation groupswill be needed based on the default upper bound of35 students per class (the number of students per lec-ture group is more flexible). Estimating enrollment toelective courses is typically easy; because the numberof students in these classes is always small, one recita-tion group is usually sufficient. Demand formandatorycourses is also typically easy to estimate. In most cases,the studentswho can be expected to take a given courseare currently registered in another mandatory course.Therefore, the numbers are expected to be similar. Forsome courses, however, the enrollment is difficult topredict because the courses are open to multiple fac-ulties as electives. The number of students who willrepeat a course is also difficult to predict.The second phase—scheduling the recitation groups

—takes two weeks. This phase requires cross-faculty

coordination. Phase 2 is much more difficult to sched-ule than Phase 1 because (1) the schedule is alreadyconstrained by Phase 1, and (2) the TAs take courses asgraduate students. The combination of these two fac-tors can cause a situation in which a TA cannot take anelective or amandatory course;worse, the TAmayneedto confirm a slot before the recitations of that course arefixed.Theautomated scheduler, discussed in thispaper,solves these problems.

During Phase 1 and Phase 2, which comprise eightto nine weeks, the assistant must personally contactall teachers and TAs to coordinate their slots. As ofthis writing (spring 2016), the IE department has 133such teachers and TAs. During this period (i.e., Phase 1and 2), the assistant also schedules the exams for theTechnion’s two exam periods, which correspond tofirst- and second-chance exams (in the Technion eachstudent can take one or two exams, and the last one he(she) takes is the one that counts). The process includesmany hard and soft constraints that must be satisfied;these are described in detail below.

In Phase 3, the schedule of courses and exams is sentto the students’ representatives, who check the sched-ule and may request changes. The most common rea-son is that occasionally they have information that theassistant does not have, such as that a large number ofstudents intend to retake a course and therefore not fol-low the program. The assistant attempts to accommo-date these requests, while coordinating changes withthe relevant teachers and TAs.

In Phase 4, the schedule is entered into the Technioncentral computer, the students are informed about theschedule, and are allowed to register for courses. Theregistration software includes the maximum capac-ity of each class and closes it for registration oncethat capacity is reached. If the number of studentswho want to register for a course exceeds the num-ber allowed, given the groups that were opened forregistration, then the assistant is notified and mustmake a decision, in conjunction with the vice dean forteaching, whether to open a new group, enlarge anexisting one, or block additional students from regis-tering. Based on the number of registrants, the assis-tant assigns classrooms, while considering the specialrequirements of courses; for example, a course mightrequire a specific laboratory.

In the next section we describe the new system.

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 539

Table 1. TieSched Uses 17 Constraints for Scheduling Courses; the Two Columns on the Right Indicate if the Constraints AreControlled by the Teachers and TAs, Respectively, Using the Web Interface

Constraint Hard/Soft Lec. TA

1 Desired hours S 3 3

2 Undesired hours S 3 3

3 Time availability (impossible hours) H 3 3

4 Split lecture (same day or different days) H 3

5 Recitation should follow the lecture H 3

6 No overlap with a list of up to three courses, which TAs wish to take as students H 3

7 Max and min number of hours of teaching H8 Force desired hoursa H9 Curriculum clashes (mandatory courses): no overlap of class periods taken by the same populationb H

10 Teacher clashes: no overlap of class periods of the same teacher or TA H11 External scheduling constraints (dictated by other departments) H12 General constraints (e.g., no classes on Thursday afternoon) H13 Distribution of class periods (i.e., in some courses, we specify that not more than half of a course’s recitation

groups will overlap)H

14 Curriculum clashes (mandatory and/or electives) S15 Curriculum clashes (electives) S16 Late hours S17 Minimize gaps in the schedule and balance the teaching load throughout the week S

aThe assistant can mark the teacher’s desired hours as hard constraints. This is applicable for several external teachers who have noflexibility. bExceptions to this rule are supported. Specifically, this is not enforced for class periods of the same course or type (e.g., tworecitations of the same course), general university-wide courses, and if the catalogue specifies a set of alternative courses.

TieSched: The System ArchitectureTieSched has three main components: A web-basedsystem for collecting constraints, a control system, andan automated scheduler.1. Web-based system for collecting constraints. Tables 1

and 2 show the constraints that the teachers andTAs control. The assistant can control all the con-straints through the control component, which we de-scribe in Item 2. A large subset of the constraintscan be mapped to constraints in the curriculum-basedcourse timetabling problem. Its complete descriptioncan be found in Gaspero et al. (2007) and in Achá andNieuwenhuis (2014). In the Related Work section, wepoint out the main differences between our model andthe model in Gaspero et al. (2007). Wherever possible,the terminology in our tables is consistent with thatin Achá and Nieuwenhuis (2014). Constraints 1–3 inTable 1 are the desired, undesired, and impossible (i.e.,the hours in which the teacher cannot teach) teach-ing hours. In the web interface, they are marked usingcolors—green, orange, and red, respectively. Everyteacher and TA has a “budget” of labels of each color(e.g., they can mark no more than x slots with red).The administrative assistant is not restricted by thosebudgets. Figure 1 shows a sample web page.

Although it takes a few minutes to fill in the con-straints the first time, in subsequent scheduling, theteachers and TAs have to change the constraints only

Table 2. TieSched Uses 11 Constraints for SchedulingClassrooms (Constraints 1–7) and Exams (Constraints 8–11)

Constraint Hard/Soft

1 Teacher or TA’s desired classroom S2 Room clashes: class periods scheduled at the same

hour are scheduled in different classesH

3 Room capacity H4 Designated rooms (e.g., labs) H5 Adjustment to class sizea S6 Room stability: class periods of the same course stay

in the same classS

7 Preference for teaching in the IE building S8 No exams on Saturdays and holidays H9 Number of preparation days ≥ recommended

numberS

10 Requested dates for the examb H11 Distance between the first- and second-chance

exams ≥ recommended number, based onclass size

S

aA set of soft constraints enforcing the constraint that the bestscore is given when the number of students is in the range of 60–85percent of the class capacity.

bPrincipally used for forcing the exam schedule of externalcourses, as dictated by other departments; can also be applied as asoft constraint.

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion540 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

Figure 1. The TieSched Web Interface Shows the Constraints and Preferences Collected from Teachers

Notes. The numbers near the various colors (smiley faces) indicate the remaining “budget”; for example, only five additional slots can bemarked as “cannot teach” (red). The web page that the TAs use allows them to also mark courses that they want to take as graduate students.

if their personal constraints change between semesters.In the previous semester, for example, 53 of 89 activeteachers updated their constraints.2. Control system. The control system is a client,

which is installed on an assistant’s computer, for help-ing with the editing of the raw data and the sched-ule. This module (a) is a decision support system forhigh-quality manual scheduling, (b) provides informa-tion management, and (c) enables the user to invokethe automatic scheduler.

(a) As a decision support system, it(i) indicates which slots cannot be used for

scheduling a course because of schedule conflicts withother populations (we call “population” a group of stu-dents in the same track that were admitted in the samesemester) who are taking the same course;

(ii) indicates whether the correct number oflectures, recitations, and (or) labs were scheduled;

(iii) shows teacher’s and TA’s constraints;(iv) generates a report listing the results of var-

ious checks, such as unscheduled class periods, or aschedule that violates a constraint.

(b) As an information management system, itprovides

(i) access to the relevant tables for updating(e.g., tables of teachers, courses, semesters, tracks,classroom information, exam information, parameter-scheduling tuning, and general options);

(ii) access to semester-specific information, suchas the courses to be taught, the teachers who will teachthese courses, the number of groups, and class capacity;

(iii) an export facility that supports exportingthe schedule to the Technion central computer and toExcel files;

(iv) a communication module that supportssending the schedule to the teachers and TAs by emailin a calendar format (e.g., Google Calendar).

(c) As an automatic scheduler, it enables the userto tune and invoke the automatic scheduler module,which we discuss next.

3. Automatic scheduler. The automatic scheduler sup-ports scheduling courses, classrooms, and exams. It isbased on solving a minimization problem with hardand soft constraints (Tables 1 and 2). Appendix A

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 541

includes the mathematical formulation of these con-straints. Appendix C shows data that are characteristicof the scheduling problem (e.g., the number of slots).

Design Decisions. The literature, for example the cur-riculum-based course timetabling problem (Gasperoet al. 2007), is typically concerned with solving thecourse- and class-scheduling problem as one; in con-trast, we solve these problems separately. Classroomscan be a contested resource (e.g., a single lab mightneed to serve several courses); hence, solving classroomscheduling in conjunction with course scheduling ismandatory ifwewant to find anoptimal solution.How-ever, for several reasons, we decided to separate thesetwo problems. (1) Solving them together implies thatthe classrooms are scheduled before precise registra-tion information is available; therefore,manual changeswould have to be made and the solution would likelynot be optimal. (2) It is computationally harder. (3) Forour department, we consider it largely unnecessarybecause we do not have a scenario in which a singlelab serves several courses; without such contention, weconsider class scheduling to be significantly less impor-tant than course scheduling, perhaps to the point thateven if solved together it should be solved with a lexi-cographic objective where the classroom scheduling issecondary. (4) We do not need this information for theregistration process, because students generally do notchoose their courses based on the classroom. Even if wedid publish it, it would necessarily lead to changes fol-lowing the student registrationsbecauseof the incorrectpredictions of class size.

Modeling and SolvingThe SolversThe system is based on translating the constraints intoone of several formats, and using multiple tools, as weshow in Table 3. These tools are in the public domainand free for academic use. TieSched supports run-ning multiple engines in parallel. When executed on apersonal computer, it distributes them evenly amongthe computer’s cores. The engines collaborate in thesense that the first to find a solution notifies the centralthread, which then stops all other engines and restartsthem with a new constraint on the value of the objec-tive, forcing it to be smaller than the one found.

Table 3. Users of TieSched Can Choose Which of theEngines Listed to Operate in Parallel

Engine type Tool Reference

Pseudo-Boolean minisatp Eén and Sörensson (2006)Glucose Audemard and Simon (2009)HSAT Gershman and Strichman (2009)

Lingelin Biere (2014)Treengelin Biere (2014)

CSP HCSP Veksler and Strichman (2016)mZinc Nethercote et al. (2007)

SMT MS-Z3 de Moura and Bjørner (2008)Weighted Max-SAT MsUncore Morgado et al. (2012)ILP OPL IBM (2014)

The set of activated engines can be controlled via thecontrol system’s graphical user interface (GUI); how-ever, in practice, the assistant activates a default combi-nation of three tools that we chose based on results ofbenchmarking tests that we conducted. Figure 2 showsthe overall architecture of the system.

In the past semester, the pseudo-Boolean formula wegenerated for scheduling courses had 467,000 variablesand 1.78 million clauses (the corresponding file size isabout 50 MB). The formulas for scheduling the class-rooms and exams are ≈20 percent and ≈30 percent ofthis size, respectively. The constraints files are publiclyavailable in Strichman (2016).

ModelingFor each combination of course type (i.e., lecture,recitation, lab), teaching group, and class period (recallthat multiple-hours lectures can be split to two classperiods at the request of the teacher), we define twotypes of variables: h ∈ [8..19] (hour), and d ∈ [1..5](day). Based on these variables, all the constraints canbe cast as a Boolean combination of difference con-straints (Kroening and Strichman 2008, Section 5.7) overfinite-domain variables, that is, linear constraints withonly two variables, and the coefficients are equal to 1.For example, suppose two class periods have lengthlen1 and len2, respectively, and we wish to prevent theiroverlap. Let d1, d2, h1, h2 be the day and hour variablesassociated with these two class periods. Then the con-straint is (d1 , d2) ∨ (h1 − h2 ≥ len2) ∨ (h2 − h1 ≥ len1);that is, either these two class periods are scheduled ondifferent days, the first class period begins after the sec-ond one ends, or the second class period begins afterthe first one ends. Appendix B shows the conversion

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion542 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

Figure 2. (Color online) The Architecture of TieSched

CentralDB

Schedules

Control

Client Web

Server

PC

HPC

DB

CSPengine

SAT-basedengine#1

A m

inim

al c

orre

ctin

gse

t of c

onst

rain

ts

A m

inim

al li

stof

con

flict

ing

cons

trai

nts

SAT-basedengine#2

Core-basedengine

Solution

SatisfiableUnsatisfiable

Correctionminimizer

Coreminimizer

Constraintscollection

Automaticscheduling

Registration info.

Roommng.

Notes. Table 3 shows the list of engines. The “Central DB” at the top left is the university’s central database. The “Room mng.” database,also at the top left, is a separate system for managing the rooms in the building. The bottom elements are discussed in section When the HardConstraints Cannot Be Satisfied.

of such constraints to propositional logic, which mostof our solvers require. Using separate variables for theday and hour has an advantage inmodeling constraintsthat refer to the day (e.g., “two class periods shouldbe scheduled on the same day with a window of twohours between them”). This is in contrast to model-ing with a single variable, as Abdennadher and Marte(2000) discuss, with a domain equal to the number ofhours in a week.The constraints to enforce minimum gaps (time win-

dows) in the schedule and balancing the days are par-ticularly challenging, because defining a gap in theschedule is difficult in the presence of many electivesand multiple recitation and lecture groups. To explainthis, we provide two examples. In Example 1, supposewe schedule, for a given population, three consecutivehours, respectively, of mandatory, elective, andmanda-tory courses. Whether this schedule has a gap depends

on each student’s decision whether to take the electivecourse. In Example 2, the middle hour is a recitation;however, this recitation is one of several possible recita-tions for each student.

Our solution to this problem is to define a centralhour (1 pm in our case) and then increase the fine as theclass period is scheduled further from that hour (the“fine” is simply the weight of the corresponding softconstraint, which is added to the value of the objectivefunction if it is violated); for example, starting at 3 pmor ending at 11 am incurs the same fine, but starting at4 pm incurs a higher fine. Furthermore, elective coursesand recitations with multiple groups incur lower fines,hence encouraging a schedule in which the manda-tory courses are concentrated near the central hour andthe electives and recitations with multiple groups arescheduled in the early and late hours. This statisticallyreduces gaps in the students’ schedules and balances

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 543

the schedule throughout the week. This solution isnovel. To the best of our knowledge, previous attemptsto solve this problem, such as in Gaspero et al. (2007),used a fine for nonadjacent lectures, regardless of thesize of the gap between them. In contrast, in ourmodel,the fine is proportional to that gap. Our modeling alsobalances the schedule throughout the week, because itassigns a higher fine to courses that are further fromthe central hour.The objective function in our model has the sole pur-

pose of minimizing the overall weight of the violatedsoft constraints, which are discussed next.

Soft ConstraintsAs is evident in Tables 1 and 2, we have many soft con-straints, and determining their relative weight reflectsa policy. However, prior to the implementation ofTieSched, no such policy existed, let alone a formalizedand written policy. The manual schedule was based onad hoc considerations of the assistant. Although theauthor, as vice dean of teaching at the time, had theauthority to determine this policy, in practice it wasbased on a feedback loop in which, together with theassistant, the results of TieSched were studied and theweights were adapted until the results were satisfac-tory. That the department was forced to formalize apolicy is one of the benefits of such a system, becauseit ensures that the process is uniform and objective,rather than ad hoc and personal. The weights can beviewed and changed via the user interface; however,in each of the three modules (courses, classes, exams),they stabilized quickly and have not been modified inthe last few years.On the technical side, for each soft constraint con

withweight wcon (wcon should be interpreted as a “fine,”that is, the cost of not satisfying it), we introduce anauxiliary Boolean variable acon. We then add the dis-junctive constraint (acon ∨ con) to the set of constraints,and the term wconacon to the minimization objective.This means that the solver aspires to satisfy con; oth-erwise, acon must be assigned 1, and consequently theobjective is increased by wcon.

Some of the soft constraints, such as the distancefrom the central hour that we discuss in the Modelingsection, are not subject only to the extremes of beingsatisfied or not satisfied; rather, there are levels of sat-isfaction (e.g., the later the course begins after 1 pm, the

higher the fine). The following example demonstrateshow such constraints aremodeled for a simple case of aone-hour course. Suppose that the starting hour of thiscourse is h. Then we add a sequence of soft constraintsh < t for t ∈ [14..20] and h > t for t ∈ [8..12] (8 and 20are the earliest and latest hours in the system), eachwith aweight 1. If, for example, the course is scheduledto begin at hour 17, then the constraints h < t for t ∈[14..16] are violated; accordingly, the accumulated fineis 3. In practice, these constraints are more complicatedbecause class periods can be longer than one hour.Hence, if a two-hour course begins at 3 pm, we penal-ize the first hour with 2 and the second hour with 3.Appendix A includes details about these constraints.

When Solving Times OutDespite the large amount of input, some tools (e.g.,minisatp, glucosep, and lingeling) give an initialnonoptimal solution after a few minutes. These toolssolve the optimization problem indirectly. They are pri-marily satisfaction (feasibility) engines: they solve theoptimization problem in several iterations, by itera-tively adding a constraint that forces the value of theobjective to be smaller than in the best solution thusfar. When given an input formula with an objective,minisatp and glucosep bias the search toward valuesthat improve the objective. Hence, the initial solutionis not an arbitrary one; rather, it corresponds to a rela-tively low value of the objective if it is a minimizationproblem. In our experience with these tools and theirparallel composition, when solving the course schedul-ing problem, they typically reach the best solution thatthey are ever going to reach (that is, within the 24-hourtime-limit) within approximately 90 minutes.Interestingly, we can calculate an upper bound on

the distance of this solution from the optimum, and itis remarkably small: typically our solution is no morethan five percent larger than the optimum value. Thecalculation is based on the observation that all thevariables are of finite domain (i.e., they are Boolean);hence, we can calculate the theoretical lower and upperbounds of the objective. Furthermore, in parallel tosolving the optimization problem, we run anothersolver that runs “from the other side” (i.e., it attemptsto prove that no solution exists that is x percent fromthe lower bound, for an increasing value of x). Figure 3illustrates this. Hence, after approximately 90 min-utes, we typically have a solution that is, for example,

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion544 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

Figure 3. (Color online) In Parallel to Attempting toMinimize the Objective (from Right to Left), We Also Try toProve That There Is No Solution with Low Values of theObjective (from Left to Right)

Reversesearch

Normalsearch

MaxMin

Note. Typically after approximately 90 minutes, the gap betweenthese two engines is about five percent.

14 percent from the lower bound; however, we alreadyproved that there is no solution within nine percent ofthe lower bound. Thus, the optimal solution is some-where within this range. We can only guess that thesolution we find is optimal or very close to it, based onanalyzing the solution manually: indeed, we can neverimprove it with respect to the constraints.

Using a lower bound as a reference is not a newconcept: some commercial integer linear programming(ILP) solvers (e.g., the solver in MATLAB) that arebased on branch and bound calculate as output theratio between the best solution found so far and thesolution to the relaxed problem (i.e., without integral-ity constraints), which is much easier to find. However,to the best of our knowledge, none solves the problemfrom the other side in parallel in an attempt to improvethe estimation of the distance of the current solutionfrom the optimal one.

When the Hard Constraints Cannot Be SatisfiedWhen the constraints cannot be satisfied, assistancein solving the problem is imperative, given the largenumber of constraints. Next, we describe two featuresof TieSched that we developed to address this prob-lem: minimal unsatisfiable cores and minimal correct-ing sets.A minimal unsatisfiable core is a subset of the original

constraints that cannot be satisfied and from which noconstraint can be removedwithout making the remain-ing set satisfiable. This is a well-known problem inthe Σ2 complexity class (it is harder than problemsin NP). In linear programming, it is better known bythe name irreducible inconsistent set; for example, IBM’sCPLEX has a utility for finding such sets. Our solu-tion differs in that we attempt to minimize the setof original high-level constraints (e.g., “the class peri-ods of course A and course B cannot overlap”) rather

than the low-level mathematical constraints that modelthem. Furthermore, we associate with each such high-level constraint a description in natural language, thusmaking the problem easier to address. Indeed, in thefew times that the unsatisfiability condition occurred,our assistant was able to solve the problem based onthe output of these descriptions. The solution typicallyinvolves one TA or teacher whose request was not sat-isfied. In one situation, the constraints were satisfiedonly after three iterations (i.e., there were three sepa-rate unsatisfiable cores).

When the constraints are inconsistent, we automat-ically invoke a tool called Haifa’s high-level minimalunsatisfiable core (HHLMUC) (Ryvchin and Strichman2011), which finds a minimal high-level core; based onits output, we print the text associated with the con-straints in that core. Despite the theoretical complex-ity, in practice, this process never takes more than aminute. One reason is that when the formula is unsat-isfiable, it is typically because of a combination ofa very small number of high-level constraints (typi-cally not more than three or four), and the underlyingsolvers tend to prove unsatisfiability with little redun-dancy. Hence, the initial core entered into HHLMUC isalready small.

Briefly, HHLMUC works as follows: in each itera-tion, it attempts to remove the entire set of constraintsthat emanate from a single high-level constraint. If theformula is still unsatisfiable, it discards this set of con-straints and repeats the process. Otherwise, it marksthe high-level constraint as necessary for the minimalcore and reintroduces the associated set of mathemati-cal constraints into the formula.

In case of unsatisfiability, TieSched also finds theweighted high-levelminimum correcting set (WH-MCS). Tothe best of our knowledge, this problem has not beenpreviously covered in the literature. First, we associatewith each high-level hard constraint, a secondaryweightindicating its importance relative to the other hard con-straints. If all hard constraints cannot be satisfied simul-taneously, this number helps us to determine whichconstraint to remove or relax. Based on these numbers,given an unsatisfiable set of constraints, the WH-MCSproblem is to find a set of hard constraints with a min-imal total weight, such that removing them makes therest of the constraints satisfiable. For example, supposethere are a hundred high-level constraints c1 , . . . , c100

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 545

that cannot be mutually satisfied and, to simplify theexample, that we gave them all the same secondaryweight. Suppose further that there are three high-levelminimal unsatisfiable cores: {c1 , c2 , c3 , c4}, {c3 , c8 , c9},and {c20 , c21}. Then aWH-MCS is, for example, {c3 , c20}.We emphasize that the unsatisfiable cores are not giventous (enumeratingunsatisfiable cores is ahardproblemin its own right, as shown inLiffiton andSakallah 2008),and that nonuniformweights can change the answer.We solve this problem by reducing it to a weighted

high-level Max-SAT problem. Let us first recall the stan-dardMax-SAT problem. Given a propositional formulain conjunctive normal form (CNF), the goal of Max-SAT is to find the maximum number of clauses thatcan be satisfied simultaneously. The weighted high-levelversion of Max-SAT requires the set of clauses to bepartitioned to groups, and each group must be asso-ciated with a weight. It then finds a set of groupswith the largest total weight that can still be simulta-neously satisfied. The connection of this problem toWH-MCS is evident: the constraints emanating froma high-level constraint form a group, which we asso-ciate with the secondary weight. Solving the groupMax-SAT problem with this input gives us a set ofhigh-level constraints that can be satisfied: the com-plement of this set is our desired outcome. Continu-ing the previous example, each of c1 , . . . , c100 is rep-resented by a group of clauses, and each such groupis associated with a weight representing the relativeimportance of that constraint. Then solving the groupMax-SAT problem may result in all constraints otherthan {c3 , c20}.Although we are not aware of a tool that solves

the weighted-high-levelMax-SAT problem, Heras et al.(2015) illustrate how to reduce this problem to aweighted Max-SAT problem. TieSched uses the encod-ing in Heras et al. (2015), and invokes the MsUncoretool (Morgado et al. 2012) to solve it. The assistantreceives a list of high-level constraints, with a mini-mum total secondary weight, whose removal solves allthe inconsistencies in the constraints.We note that the problem of relaxing hard con-

straints when the formula is unsatisfiable has beenpreviously addressed in the literature in the con-text of course scheduling (Guéret et al. 1996): theauthors remove one of the constraints that is caus-ing the inconsistency; they then reiterate until they

achieve consistency. In contrast to our method, thisprocess does not guarantee that the weight of theremoved constraints is minimal. Another alternativeis the approach used in Miranda et al. (2012). Theauthors model hard constraints as soft with a largeweight; hence, an optimal solution satisfies as manyof those constraints as possible. In the realm of arestricted time budget for solving the problem, ourapproach is likely to be more useful, because whereasin their solution the result does not necessarily satisfythe originally hard constraints, all of the intermedi-ate solutions in our approach do satisfy the hard con-straints, andwe are typically able to find such solutionsrelatively fast.

The New Process and theLimits of AutomationWhereas the manual scheduling process, which theother departments still use, takes 9–10 weeks, the newprocess takes 3–4weeks. Furthermore, themanual pro-cess requires almost 100 percent of the assistant’s time,because he (she) must personally coordinate the sched-ule with nearly 150 people (all the teachers and TAs); inthe new process, the assistant has relatively little workto do. Next, we describe the reasons that the process isnot 100 percent automated and hence requires manualchanges:

• Teachers and (or) TAs request changes to theirschedules to address constraints they did not key-in through the web interface in response to the firstrequest.

• The system does not support some constraints.A teacher or TA might enter a special request that thesystem cannot currently model. (For example, “Tues-day afternoon is good only if I teach three hours con-secutively; however, if I teach on Wednesday, I wantto split it into two sessions with a gap of two hours.”)The assistant reviews these comments and attempts tosatisfy them by making manual changes.

• Student representatives make requests, typicallybecause they have information that was unknown tothe assistant a priori, as we discuss in section The Man-ual Process Prior to TieSched. For example, a large num-ber of students may wish to repeat a course; hence,the schedule and the recommended program are notsynchronized.

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion546 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

In addition, nine courses are scheduled manuallybefore running the automated scheduler for two rea-sons, as follows:

• Our faculty has a joint program with another fac-ulty (CS), which still uses manual scheduling. Thismeans that CS must coordinate with us the scheduleof several courses about five weeks before we run ourscheduler (which in itself is not aware of the constraintsin CS).

• Our faculty offers a graduate program for work-ing students that is concentrated in a single day of theweek. We realized that manually selecting the threecourses from that program and manually schedulingthem with the proper breaks is easier than trying toautomate their scheduling.For these reasons, we achieved 89.5 percent automa-

tion in the previous semester. This number is basedon comparing three figures: s—the total number ofslots, m—the number of manual changes that weremade to the automated schedule, and p—the numberof slots that were prescheduled as hard constraints. The89.5 percent figure is the result of (s − p − m)/s. Forcomparison, in the first year, this number was approxi-mately 70percent. It reached its current level of 89.5 per-cent in the second year when we determined the miss-ing constraints thatwere creatingmost of the problems.Having the necessity to combine automation with

manual work in mind, we now describe the new pro-cess. This description is based on a day-by-day actionlist that we wrote in a web-based spreadsheet. Theassistantmarks off the completed items on that list eachsemester.

1. Prepare data. This step takes two to three daysto complete.

(a) Copy all data from the previous year to thenew semester;

(b) Make the necessary changes to the list ofcourses, the course teachers and TAs, and the numberof groups to be scheduled;

(c) Adapt, if necessary, the hard constraints fromthe previous year; these constraints are typicallyrelated to courses given by other faculties, or coursesgiven by external teachers who can teach only in oneparticular slot;

(d) Review the textual comments of the teachersto determine if any can be translated to a constraint;typically, some can be translated;

(e) Update, if necessary, the academic programs;this is done by changing the list of populations that isassociated with each course;

(f) Generate a report of inconsistent and (or)incomplete data and correct the problems specified inthe report.

2. Update mailing lists to reflect changes to theteachers and TAs in the next semester.

3. Send a message through the mailing lists to allteachers and TAs to request that they update their con-straints within the next three days.

4. Activate the automatic scheduling of courses.5. (Manually) check and edit the schedule in accor-

dance with the textual requests entered by the teachersand TAs.

6. Share the schedule with teachers, and solicitrequests for changes within the next three days.

7. Activate the automated scheduling of exams.8. Share the schedule with the TAs, and solicit

requests for changes to be received within the nexttwo days.

9. Share the schedule with the student representa-tives, and solicit requests for changes to be receivedwithin the next seven days.

10. Send the final schedule to each teacher and TA;send a calendar entry (for a Google or Outlook calen-dar) to those who indicated that they want it.

11. Export the schedule to the Technion centralcomputer.

12. After the students have completed registering,activate the automated scheduling of the classrooms.

13. Export the classroom schedule to the Technioncentral computer.

With the exception of steps 1(b)–1(f) and step 5, allthese steps are done by pressing a button in the controlsystem. Overall the assistant has less than 30 percent ofthework that her peers have. As a result of this extremereduction in work, the faculty has transferred work toher; thisworkhas traditionallybeenallocated toanotherassistantwhowasoverloadedandsometimespaidover-time.Unfortunately, the facultycannotshowareductionin manpower; however, it can show that various tasksthat were done late or not completed, or completed onovertime pay, are now fulfilled as part of the routine.

Problems and AcceptanceAn initial version of the system was presented to thefaculty council, and the initial question asked was

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 547

“how do we benefit from this”? This reflects the mainorganizational problemwith the manual approach: theprofessors, who control the department, mostly careabout the schedules for their own courses rather thanthe overall schedule, and they usually get the sched-ules they want; hence, they were not highly motivatedto cooperate. The convenience and because they canrequest things they never knew they could (e.g., afavorite classroom, or splitting a course on the sameday), and other advantages related to classrooms andexams scheduling that were only developed later, con-vinced them rather quickly. Initially, some did not entertheir constraints; however, a single round in which theschedule was automated made them realize that theywere hurting themselves by not cooperating. We notehere that the amount of cooperation needed from theteachers is minuscule; they must enter their constraintsinto the web-based page. These constraints are consid-ered by TieSched until they are changed. After usingthe system for a year, teachers and TAs came to like it.

TieSched’s acceptance by the assistant, who is itsoperator, was crucial. The system has a fairly sim-ple Windows-based graphical user interface that pro-vides access to all the necessary tables and param-eters. Although the automated scheduler is invokedby a key stroke (assuming that the default enginesare used), our biggest challenge in reaching a state inwhich the assistant is almost autonomous was incom-plete or inconsistent data, which can abort the auto-matic scheduler module or make its results meaning-less. We now prevent most potential inconsistencies byperforming checks at the time of data entry. In addi-tion, TieSched produces a report in plain language,based on dozens of SQL queries that search for suchinconsistencies. Observe that step 1(f) in the detailedprocedure that we describe above requires the assis-tant to invoke this feature and address the problemsin the report. The assistant now is proficient enough tohandle such problems without requiring help.

BenefitsOur new process offers several advantages, as wedescribe here.

• All hard constraints are satisfied (if the hard con-straints do not conflict), and the solution is near opti-mal relative to the soft constraints. A review of the lists

of constraints in Tables 1 and 2 suggests the implica-tions of this. For example, a teacher’s course is split, ifrequested, is never scheduled on hours that are blockedby the teacher, and the recitation is scheduled to beadjacent to the lecture, if requested. In addition, eachTA can now take the courses that he (she) wants with-out conflicting with his (her) own recitation. This isa hard constraint (Table 1), which implies that pre-venting TAs from taking their desired courses, a situ-ation that occurred commonly over many years, wasavoidable.

• The control system supports manual and semi-automatic scheduling, by visually showing some of theconstraints (e.g., conflicting schedules of other popu-lations), and performs dozens of checks upon request.As we discuss above, we do not believe that sucha complex system can provide a 100 percent auto-mated solution. Hence, the decision support that thismodule offers is necessary for achieving high-qualityschedules.

• It automates the creation of a per-semester mail-ing list. This allows the assistant and others (such asthe dean) to communicate directly with everyone whoactively teaches, rather than to all staff by using thegeneral staff mailing list; teachers and TAs have theoption of having their schedules entered directly intotheir calendars.

• The classroom scheduling module attempts toadhere to the requests of each teacher and (or) TA,guarantees the correct class size, and minimizes thenumber of times a class is given outside our facultybuilding.

• Automated exam scheduling solves major prob-lems that exist with the manual schedule. First, whenthe assistant manually schedules exams, he (she) isnot fully aware of the time required to prepare foreach exam, relative to other exams that the studentsmust take in the same semester. Our system solves thisproblem. The student representatives gave question-naires to students from all tracks and years, request-ing them to split a given number of days between thevarious exams. These numbers are now the basis forthe optimization problem that TieSched solves. Sec-ond, TieSched attempts to assign a greater number ofdays between the first- and second-chance exams oflarge classes. For a large class, the teacher and (or) TArequires more time to check and return the exams. By

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion548 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

lengthening the time between these exams, studentshave sufficient time before the second-chance exam todecide whether to take it.

Related WorkThe amount of literature on automated course schedul-ing is immense. A biennial conference on the prac-tice and theory of automated timetabling (PATAT) islargely dedicated to this field; see Özcan et al. (2016).The constraints in our model have a great deal in

common with the curriculum-based course timetablingproblem (Gaspero et al. 2007); however, as we discuss,we model and solve the course- and class-schedulingproblems separately. Themajor differences in ourmod-eling (Tables 1 and 2) are the hard constraints 4–6, and13, and the soft constraints 1, 2, 14, 15, and 17.We differin how we treat the minimization of gaps in the sched-ule and the balancing of the days, as we explain in theModeling section.

To the best of our knowledge, the first article ded-icated to this subject is Harwood and Lawless (1975).De-Werra (1985) includes a survey of early works(up to 1985) with an emphasis on graph-theoreticalmodels, and the work in Thompson and Dowsland(1996) is dedicated to scheduling exams using sim-ulated annealing. TieSched is not the first schedulerto rely on constraints over discrete finite-domain vari-ables (in contrast to ILP solutions). Abdennadher andMarte (2000) is the earliest work of which we are awarethat considers the course-scheduling problem as a CSPproblem with both soft and hard constraints; however,their work includes no discussion of the case in whichthe system times out or the constraints are unsat-isfiable. This is also true for the course-schedulingand class-scheduling solutions in Rudová and Murray(2002). We are not aware of solutions in the literatureto the problems discussed in the When Solving TimesOut section (i.e., previous solutions focused on heuris-tics and approximations, without guarantees of prox-imity to the optimal solution), and the When the HardConstraints Cannot Be Satisfied section. Regarding theformer, making all constraints soft does not solve theproblem because in the case of a time-out, the solutiondoes not necessarily respect the hard constraints, evenif such a solution exists.Chin-A-Fat (2004) reports on SAT-based school

scheduling. A recent article by Achá and Nieuwenhuis

(2014) describes SAT and Max-SAT algorithms for uni-versity scheduling, based on hard and soft constraints;hence, it is the closest to our solution relative to theunderlying solving engines. It solves existing schedul-ing benchmarks; it is not concerned with modeling.

Scheduling-software packages that were developedby commercial companies are also relevant to ourdiscussion. The commercial system that most closelyresembles ours is best-timetabling. It supports numer-ous types of constraints; however, its solution is heuris-tic in nature and gives no guarantee of near optimality.Its constraints-collectionweb interface collects informa-tion only on preferred teaching hours, in contrast toour more elaborate interface, as we describe in Tables 1and 2. The tool unitime has no distributed constraints-collection facility and is basedon stochastic local search;that is, it is logically incomplete:when there isno solutionowing to conflicting constraints, it cannot detect thissituation and iterates forever. The Mimosa tool, whichis principally used in schools rather than universities,is the most widespread scheduling-software package;however, its optimization features are weak. For exam-ple, after generating an initial manual schedule, it canmove classes in the same day to attempt to close gaps.Hence, itsmain focus is onassistingmanual scheduling.

Kassa (2015) describes an effort to implement coursescheduling in the College of Business and Economics ofBahir Dar University in Ethiopia. It covers room assign-ments, timetable scheduling, and scheduling teachersto classes.

The ScheduleExpert system from Cornell Univer-sity’s School of Hotel Administration (Hinkin andThompson 2002), which was later developed as a com-mercial product focusing on hospitality staffing agen-cies, does course and class scheduling and also assignsteachers to subjects. The constraints are all soft, and theobjective is to minimize their violation. The modelingdiffers from ours; for example, it does not have con-straints for minimizing the gaps in the schedule; how-ever, it has constraints to minimize the time betweenthe first and last lecture of each faculty member in agiven day. It is based on a heuristic search, with noguarantee of the closeness of the result to an opti-mum. The user examines the schedules generated bythe system at run time and determines if they aregood enough or if the system should run for moretime to improve the solution. A similar approach can

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 549

be found in udpSkeduler (Miranda et al. 2012), a toolthat is based on IBM’s Cplex and was developed forscheduling courses in the Faculty of Engineering of theUniversidad Diego Portales (UDP) in Santiago. Theysolve the course and classroom scheduling as part ofa single model. This difference emanates from a dif-ferent scheduling process: they publish an initial draftof the schedule based on estimating the course regis-tration; after the students register, they determine thefinal schedule. Another difference between udpSked-uler and TieSched is that in the latter, teachers andTAs mark desired, undesired, and impossible hours; inthe former, each teacher is obliged to mark a minimumnumber of patterns, where a pattern is a precise sched-ule of the course and the classroom in which it will begiven. Therefore, if two teachers mark their courses atthe same hour and at the same class, one of these pat-terns will not be satisfied, and the system will not offerthe alternative of scheduling during the same hoursbut in a different room.It is also significantly less flexible than the input

model of TieSched (e.g., because it fixes the connectionbetween the class periods of the course, and the class-room), and is less stable between semesters because ifa teacher’s course changes, then those patterns mustalso change.Unlike TieSched, it does not consider the objective of

minimizing gaps in the schedule or balancing the days.Finally, we note that its solution is not necessarily opti-mal, even with respect to those restrictions, becauseof capacity restrictions. Once the number of patterncombinations becomes too large, udpSkeduler manu-ally adds filters, which exclude many patterns to makeit solvable.

ConclusionWe presented TieSched, a system that was developedanddeployed at the Industrial Engineering departmentin the Technion, Haifa, Israel. This system has sev-eral components: a web-based interface to collect con-straints, an optimization engine to solve the schedulingproblem for courses, classes, and exams, and a man-agement system with which the assistant can edit theschedule and perform many other tasks. The systemwas used first in 2012, and numerous improvementsand extensions have since been incorporated. It is cur-rentlyused routinely by the assistantwithminimal sup-port. It eliminated most of her work, allowing her to

assumenewduties. Aswediscuss in this paper, the sys-temprovidesmany benefits to the faculty; these includebetter schedules for all stakeholders, auniformschedul-ing policy, academic benefits such as better allocation ofthe days needed to prepare for exams, and avoidanceby TAs of having their recitations overlap with coursestheywant to take.

Each year we incorporate themost current engines—the engines that win the various competitions; this iseasy to do given the standard constraints language thatthese competitions impose. Various constraint files arenow available for benchmarking purposes (Strichman2016), and in several formats: CNF (conjunctive normalform for SAT solvers, solving the feasibility problemfor a given value of the objective), WCNF (weightedCNF, for Max-SAT solvers), SMT2 (for SMT solverssuch as MS-Z3), OPB (optimization pseudo-Boolean),MiniZinc (a constraints satisfaction standard format),and OPL (for IBM’s CPLEX tool). Hopefully, this willlead to improved engines that will solve them to com-pletion in a reasonable amount of time.

AcknowledgmentsMany students helped the author develop TieSched, mostlyas part of annual undergraduate projects. In particular, theauthor thanks three students: Boris Milner for developingthe web-based component for collecting constraints; OlaRosenfeld, PhD student, for developing the initial automatedscheduler, including the translation of the CSP model to SAT;without her work, this system probably would not exist; and finally,Michael Veksler for coming up with the idea of how to solvethe problem of gaps in the schedule and balancing it.

Appendix A. Constraints FormulationThe objective in all three problems is

min∑con∈S

wcon · acon , (A.1)

where S denotes the set of soft constraints, con ∈ S, wcon de-notes the weight of the constraint, and acon denotes the aux-iliary Boolean variable that controls this constraint: it is setto true if and only if the constraint is violated (see the SoftConstraints section).

In the description of the constraints, we will denote con-stants with c and a subscript. For example, cd and ch are con-stants representing a day and an hour, respectively. A timeinterval is defined by three constants: a day cd , and timebounds chmin

and chmax. Other symbols represent decision

variables. Specifically, for each class period u (henceforth, ateaching unit), we define decision variables du , hu , which arethe day and starting hour of that unit, and a constant clenu

,

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion550 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

which is the number of hours associated with that unit. Thecourse-scheduling problem is defined in Table B.1. It relieson several types of auxiliary constraints that we show inTable B.2. For two elements u1, u2 in a list of units, we writeu1 < u2 to show that u1 appears before u2 in the list.

For the class-scheduling problem, for each unit u, we havea single decision variable ru that holds the classroom inwhichthis unit will be taught. (Recall that the class-scheduling

Table B.1. The Course-Scheduling Problem Is Defined via the Following Constraints

Name Parameters Constraint

Desired hours for teacher G—The set of desired intervals〈cd , chmin , chmax 〉.

U—Units of the teacher.

∧u∈U

∨G timeBetween(du , hu , clenu

, cd , chmin , chmax )

Undesired hours for teacher G—The set of undesired intervals〈cd , chmin , chmax 〉.

U—Units of the teacher.

∧u∈U

∧G noOverlap(du , hu , clenu

, cd , chmin , chmax −chmin )

Time availability (impossible hours) Same as undesired hours, as a hardconstraint.

Split lecture: Same day du1 , hu1 , clenu1, du2 , hu2 , clenu2

. The gap isconfigured to be 2 or 3 hours.

du1 � du2 ∧ (hu1 ≥ hu2 + clenu2+ 2∨ hu2 ≥

hu1 + clenu1+ 2) ∧ (hu1 ≤

hu2 + clenu2+ 3∧ hu2 ≤ hu1 + clenu1

+ 3)Split lecture: Different days du1 , du2 du1 , du2

Recitation should follow the lecture Lecture: du1 , hu1 , clenu1. Recitation:

du2 , hu2 . Applied only to the first unitof first lecture group, and firstrecitation group.

du1 � du2 ∧ hu2 � hu1 + clenu1

No overlap of a TA’s course with thecourses he (she) takes as a student

U1—Units taught by the TA, U2—Unitsof courses that the TA takes.

noOverlapUnitSets(U1 ,U2).

Max and min teaching hours (Hard constraints implicitly constrainedby setting the domain of the hvariables to the range [8..20].)

Force desired hours (Same as desired hours, only marked ashard constraints.)

Curriculum clashes (mandatorycourses): No overlap of units taken bythe same population

U—List of units taken by the population. ∧u , v∈U, u<v noOverlapUnits(u , v)

Teacher clashes: No overlap of units ofthe same teacher

U—List of units taught by the teacher. ∧u , v∈U, u<v noOverlapUnits(u , v)

External scheduling constraints Day and time dictated from outside. timeBetween constraintsDistribution of units Two lists of units U1 ,U2 of equal size. For i ∈

|U1 |:∧

ui∈U1 , vi∈U2 noOverlapUnits(ui , vi)Curriculum clashes (mandatory,

electives)U1 ,U2—List of elective and mandatory

units taken by the population.

∧u∈U1 , v∈U2 noOverlapUnits(u , v)

Curriculum clashes (electives) U—List of elective units taken by thepopulation.

∧u , v∈U, u<v noOverlapUnits(u , v)

Late hours Not teaching later than 6 pm. For each unit u: hu ≤ 18− clenu

Minimize gaps Center� 13 (central hour). For each unit u: (for each hourCenter ≤ c ≤ 20− lenu : hu ≤ c, and foreach hour 8+ lenu ≤ c ≤ Center:hu ≥ c − len+ 1)

problem is solved only after the schedule has been deter-mined; hence, that schedule is part of the input to the class-scheduling problem.) The constraints for this problem arelisted in Table B.3.

For the exam-scheduling problem, each course s has twodecision variables, as and bs , which correspond to first-and second-chance exams. Their domains correspond to thelength of the respective examperiods. This domain is a range;

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 551

Table B.2. The Modeling of the Course-Scheduling Problem in Table B.1 Relies on the Following AuxiliaryConstraints

Name Parameters Constraint

noOverlap d1 , h1 , clen1 d2 , h2 , clen2 (d1 , d2) ∨ (h1 − h2 ≥ clen2) ∨ (h2 − h1 ≥ clen1)noOverlapUnits Units u1 , u2 noOverlap(du1 , hu1 , clenu1

, du2 , hu2 , clenu2)

noOverlapUnitSets Sets of units U1 ,U2∧

u1∈U1 , u2∈U2 noOverlapUnits(u1 , u2)timeBetween d , h , clen, required interval: cd , chmin , chmax d � cd ∧ chmin ≤ h ∧ h + clen ≤ chmax

Table B.3. The Class-Scheduling Problem Is Defined via the Following Constraints

Name Parameters Constraint

Room clashesa List of units U taught at a particular houra ∧u , v∈U, u<v ru , rv

Unit in classb All units U, all classrooms C∧

u∈U, c∈C ru , cDesignated rooms (Via the domains, for example, normal units do not have the

lab rooms in their domain)Room stability List of units U

∧u , v∈U, u<v ru � rv

aNote that this includes units that were scheduled in previous hours but have length larger than 1.bThis constraint encapsulates three type of constraints via its weight: the teacher’s preferred classroom, the preference to

teaching in the IE building, and the relative capacity (the fine is 0 if the number of registrants is 60–85 percent of the class’scapacity, and higher if it is higher or lower). For example, if a teacher prefers class c for his/her unit u, then a fine will beassociated with the constraint ru , c′ for each c′ , c.

hence, it includes Saturdays and holidays (if they are withinthe scheduling period). Table B.4 shows the constraints forthe first-chance exams; the constraints for the second-chanceexam are similar; therefore, we do not show them in thisappendix. The constraints refer to minDiff, which is a con-stant that represents the global minimum distance betweenthe two exams, and cABDiff, which is a constant representing

Table B.4. The Exam-Scheduling Problem Is Defined via the Following Constraints; the Constraints ShownRefer to the First-Chance Exam Only, and the Gap Between Them Refers to the Second-Chance Exam

Name Parameters Constraint

No exams on Saturdaysor holidays

All coursesa S, forbidden dates in the exam periods D∧

s∈S, d∈D as , d

Min no. of preparationdays

A mandatory course s1 and its requested prep. days cs1 ; a setS of mandatory courses taken by the same population

For s ∈ S: For minDays < i ≤cs−1: (as−1− as ≥ i∨ as > as−1)(soft)

For i �minDays: the same,but as a hard constraint

Requested date Course s, requested date db as � dFirst dayc All courses S, and for each s ∈ S, its requested prep days cs as ≥ cs − 4Distance between the

first- and second-chance exams

All courses S, and for each s ∈ S, its recommendedminimum distance in days csd , based on class size; minDiffis a global minimum distance between the two exams; andcABDiff is the difference between the starting dates of thetwo exam periods

For minDiff < i ≤ csd : bs − as ≥i − cABDiff (soft)

For i �minDiff: the same, butas a hard constraint

aThis is the set of all courses for which the department is responsible.bMostly used for forcing the exam schedule of external courses, as dictated by other departments.cThe days before the first day of the examination period also count for preparation. (We count them as four days; hence,

if an exam requires five days, scheduling it on the first day incurs a fine.)

the difference between the starting dates of the two examperiods.

Appendix B. Translating Difference Constraints toPropositional Logic

To translate each of the difference constraints, which areover finite domains, to constraints over Boolean variables, we

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion552 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

use order encoding (Petke and Jeavons 2011). For each vari-able v ∈ [min,max], we introduce max–min Boolean vari-ables bmin , bmin+1 , . . . such that bi represents the fact that v ≤ i.We then add max–min−1 transitivity constraints to enforceorder: bi⇒ bi+1, for each of i ∈ [min,max−1]. Finally, we addconstraints to enforce the original difference constraint. Thisis best illustrated with examples. Next, we use the standardBoolean connectives: “∧” for conjunction, “�⇒ ” for implica-tion, and “¬” for negation.

Given the constraint x ≤ y, where x , y ∈ [1..3], we introducethe Boolean variables bx

1 , bx2 for x and b y

1 , by2 for y (we do not

need bx3 and b y

3 because they are always true; that is, theyrepresent tautologies), and add the transitivity constraints

bx1 �⇒ bx

2 ∧ b y1 �⇒ b y

2 (B.1)

(that is, if x ≤ 1 then x ≤ 2, and the same for y), and constraintsenforcing x ≤ y:

b y2 �⇒ bx

2 ∧ b y1 �⇒ bx

1 . (B.2)

(That is, if y ≤ 2 then x ≤ 2, and if y ≤ 1 then x ≤ 1.)As another example, consider the constraint x − y � 2 for

x , y ∈ [1..5]. The Boolean variables are bxi , b

yi for i ∈ [1..4], the

transitivity constraints are

bxi �⇒ bx

i+1 ∧ b yi �⇒ b y

i+1 for i ∈ [1..3], (B.3)

and the constraints enforcing the equivalence x − y � 2 are

bx3 ⇐⇒ b y

1 ∧ bx4 ⇐⇒ b y

2¬bx

2 ∧ b y3 ,

(B.4)

which is perhaps easier to understand when written as theinequalities that it represents: x ≤ 3 ⇐⇒ y ≤ 1, x ≤ 4 ⇐⇒y ≤ 2, x ≥ 3, y ≤ 3.

Appendix C. TieSched Parameter Data for 2016During the 2016 spring semester, scheduling for the IEDepartment involved the following: 133 faculty and teach-ing assistants; 127 courses, of which 30 have a fixed scheduledetermined by other faculties; 722 scheduled slots, of which265 have a fixed schedule determined by other faculties. (Thegap between this number and the number of courses occursbecause each course can have multiple teaching and recita-tion groups. In addition, lectures longer than two hours canbe split into two class periods at the request of a teacher.)The timetable has five days, from 8:30 am to 8:30 pm. Thereare 15 classrooms in the building, and many classroomsare outside the building and therefore less preferable. Theschedule of all first-chance exams must fit within threeweeks, and the schedule of all the second-chance exam mustfit within two-and-a-half weeks, with a one-week break inbetween.

ReferencesAbdennadher S, Marte M (2000) University course timetabling

using constraint handling rules. Appl. Artificial Intelligence 14(4):311–325.

Achá RJA, Nieuwenhuis R (2014) Curriculum-based coursetimetabling with SAT andMaxSAT. Ann. Oper. Res. 218(1):71–91.

Audemard G, Simon L (2009) Predicting learnt clauses quality inmodern SAT solvers. Boutilier C, ed. Proc. 21st Internat. JointConf. Artificial Intelligence, Pasadena, CA, 399–404.

Biere A (2014) Yet another local search solver and lingeling andfriends entering the SAT competition 2014. Accessed May 10,2017, http://fmv.jku.at/papers/Biere-SAT-Competition-2014.pdf.

Chin-A-Fat KK (2004) School timetabling using satisfiabilitysolvers. Master’s thesis, Delft University of Technology, Delft,Netherlands.

de Moura LM, Bjørner N (2008) Z3: An efficient SMT solver. Ramakr-ishnan CR, Rehof J, eds. Tools and Algorithms for the Constructionand Analysis of Systems (TACAS), Lecture Notes in Computer Sci-ence, Vol. 4963 (Springer-Verlag, Berlin), 337–340.

De-Werra D (1985) An introduction to timetabling. Eur. J. Oper. Res.19(2):151–162.

Eén N, Sörensson N (2006) Translating pseudo-Boolean constraintsinto SAT. JSAT 2(1–4):1–26.

Gaspero L, McCollum B, Schaerf A (2007) The Second Inter-national Timetabling Competition (ITC): Curriculum-basedcourse timetabling. Accessed May 10, 2017, http://citeseerx.ist.psu.edu/viewdoc/download?doi�10.1.1.211.3344&rep�rep1&type�pdf.

Gershman R, Strichman O (2009) HaifaSat: A SAT solver based onan abstraction/refinement model. J. Satisfiability Boolean Model.Comput. 6(1–3):33–51.

Guéret C, JussienN, Boizumault P, Prins C (1996) Building universitytimetables using constraint logic programming. Burke E, Ross P,eds. Practice and Theory of Automated Timetabling. PATAT 1995,Lecture Notes in Computer Science, Vol. 1153 (Springer, Berlin),130–145.

Harwood GB, Lawless RW (1975) Optimizing organizational goals inassigning faculty teaching schedules. Decision Sci. 6(3):513–524.

Heras F, Morgado A, Marques-Silva J (2015) MaxSAT-based encod-ings for group MaxSAT. J. AI Commun. 28(2):195–214.

Hinkin TR, Thompson GM (2002) SchedulExpert: Schedulingcourses in the Cornell University School of Hotel Administra-tion. Interfaces 32(6):45–57.

IBM (2014) CPLEX optimizer. Accessed August 14, 2017, https://www-01.ibm.com/software/commerce/optimization/cplex-optimizer/.

Kassa BA (2015) Implementing a class-scheduling system at theCollege of Business and Economics of Bahir Dar University,Ethiopia. Interfaces 45(3):203–215.

Kroening D, Strichman O (2008) Decision Procedures—An AlgorithmicPoint of View (Springer-Verlag, Berlin).

Liffiton MH, Sakallah KA (2008) Algorithms for computing mini-mal unsatisfiable subsets of constraints. J. Automated Reasoning40(1):1–33.

Miranda J, Rey PA, Robles JM (2012) Udpskeduler: A Web architec-ture based decision support system for course and classroomscheduling. Decision Support Systems 52(2):505–513.

Morgado A, Heras F, Marques-Silva J (2012) Improvements to core-guided binary search for MaxSAT. Cimatti A, Sebastiani R,eds. Theory and Applications of Satisfiability Testing—SAT, LectureNotes in Computer Science, Vol. 7317 (Springer-Verlag, Berlin),284–297.

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the TechnionInterfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS 553

Nethercote N, Stuckey PJ, Becket R, Brand S, Duck GJ, Tack G(2007) MiniZinc: Towards a standard CP modelling language.Accessed August 14, 2017, https://www.comp.nus.edu.sg/~gregory/papers/cp07.pdf.

Özcan E, Burke EK, McCollum B, Kjenstad D, Riise A (2016) Thepractice and theory of automated timetabling (2012). Ann. Oper.Res. 218(1):1–2.

Petke J, Jeavons P (2011) The order encoding: From tractable CSP totractable SAT. Sakallah KA, Simon L, eds. Theory and Applicationsof Satisfiability Testing—SAT 2011 (Springer, Berlin), 371–372.

Rudová H, Murray KS (2002) University course timetabling with softconstraints. Burke EK, Causmaecker PD, eds. Practice and Theoryof Automated Timetabling IV, Selected Revised Papers, Lecture Notesin Computer Science, Vol. 2740 (Springer, Berlin), 310–328.

Ryvchin V, Strichman O (2011) Faster extraction of high-level mini-mal unsatisfiable cores. Sakallah KA, Simon L, eds. Theory andApplications of Satisfiability Testing—SAT, Lecture Notes in Com-puter Science, Vol. 6695 (Springer, Berlin), 174–187.

Strichman O (2016) Scheduling benchmarks page. Accessed May 10,2017, http://ie.technion.ac.il/~ofers/TieSched/.

Thompson JM, Dowsland KA (1996) Variants of simulated anneal-ing for the examination timetabling problem. Ann. Oper. Res.63(1–4):105–128.

Veksler M, Strichman O (2016) Learning general constraints in CSP.Artificial Intelligence 238(September):135–153.

Verification LetterProfessor AvishaiMandelbaum, Dean, and Professor AharonBen-Tal, former Dean, Faculty of Industrial Engineering andManagement, Technion Israel Institute of Technology, Haifa,Israel, write:

“It is our honor and pleasure to comply with the require-ment of Interfaces, and testify on the application and greatvalue of the Automatic Scheduling System, developed byProfessor Ofer Strichman. Indeed, the system has been usedroutinely, since 2012, in our Faculty of Industrial Engineeringand Management (IEM) at the Technion.

“There are two signatories below: the present dean of IEM,Avishai Mandelbaum, and the former dean Aharon Ben-Tal,who was the dean when the system was implemented.

“In way of background, scheduling of academic activi-ties is a notoriously difficult problem: It must satisfy systemneeds (create a schedule) while accommodating constraintsof capacity (e.g., rooms), and preferences of individuals (fac-ulty, students). This difficulty challenged us until 2012, asour faculty used a manual scheduling process that requiredthe skills of a highly experienced secretary. Our experiencedsecretary was due to retire a few months after Prof. Ben-Tal became the dean, which provided the perfect timing forimplementing Prof. Strichman’s system.

“During the first year of its use, there were faculty mem-bers who were skeptical and expressed concerns that thesystemmight not work. This was mainly due to the acknowl-edgement that academic scheduling is an inherently difficultproblem. It might have also to do with the fact that, in paral-lel to adopting a new system, the secretary was new as well,without any prior experience with the manual system. Weare happy to report that these initial hurdles were overcome

within two years. Then both our faculty and students becamevery satisfied with the system, which is now running welland saving a great amount of time and effort for all partiesinvolved in its application.

“The scheduling system enables faculty to specify theirteaching constraints explicitly (which are generally met),their favorite classroom, how to split their teaching hours, etc.Teaching assistants now enjoy the fact that their recitationsdo not overlap with the courses that they take as students.The students themselves enjoy a better schedule, which bal-ances the load along the week, minimizes gaps in the sched-ule, etc.

“The above benefits are consequences of a state-of-the-artscheduling system, which is based on the following scientificand practical principles. First, the teachers and their assis-tants are given a web-based friendly interface with whichthey can enter and edit their constraints (these remain fromthe previous semester, and hence practically teachers use itonly if their constraints have changed). Second, the automaticscheduler combines a multitude of optimization engines thatcooperate, and those are able to find optimal or close tooptimal solutions despite the theoretical complexity of theproblem. Third, the process does not end there: The systemsupports an easy-to-use client for the secretary, with whichshe can edit the schedule in a supported manner (the sys-tem marks impossible slots and then gives a detailed reportabout possible problems and violations of constraints). Theoverall scheduling process for a semester takes a few weeks,and includes time for teachers and their assistants to requestmanual changes after the automatic scheduler has emittedthe schedule.

“Professor Strichman’s system is dynamically evolving.For example, this year we have added a module for auto-matic exam scheduling, which is solving a major problem forus. Specifically, it used to be the case that the secretary aloneprepared the schedule, effectively deciding on the number ofdays that are available to study for each of the exams. Thishas now changed with the help of the automated schedulerand input from our students. To this end, we asked three stu-dents from each semester to hypothetically allocate the daysin the exam period, between the courses that they took in theprevious year and based on the relative load of these courses.This information is of course known to no one but the stu-dents, and it provides the required input for the automaticexam scheduler.

“It is hard to put a price-tag on all of the above benefits, butthe value of Prof. Strichman’s Automatic Scheduling Systemis clear and very significant. Indeed, faculty and students arehappy that their needs are well catered to. Next, we estimatethat the system reduces scheduling efforts by no less than70%. Also, as a last testimony for its success, the system isnow in the process of being adopted by additional facultiesat the Technion, as well by additional universities in Israel.

“In summary, our scheduling system is an excellent testi-mony for the success in themarriage of a long-existing impor-tant challenging need with first-rate cutting-edge research.”

INFORMS

holdsco

pyrightto

this

artic

lean

ddistrib

uted

this

copy

asaco

urtesy

totheau

thor(s).

Add

ition

alinform

ation,

includ

ingrig

htsan

dpe

rmission

policies,

isav

ailableat

https://p

ubso

nline.inform

s.org/.

Strichman: Near-Optimal Course Scheduling at the Technion554 Interfaces, 2017, vol. 47, no. 6, pp. 537–554, ©2017 INFORMS

Ofer Strichman is a computer scientist at the Technion inHaifa, Israel. He has been active in the formal verificationand computational logic communities since 1999. He haspublished two books: Decision Procedures—An AlgorithmicPoint of View with Daniel Kroening and Efficient DecisionProcedures for Validation, edited a third one, and coauthored

more than 90 peer-reviewed articles in these fields. He isalso active in the SAT (Boolean satisfiability) community andcochaired the main conference for SAT in 2010. He is bestknown for his contributions to SAT (e.g., incremental satis-fiability, phase saving), linear-time proof manipulation, andbounded model-checking.