students or tracking admission criteria for final exams become challenging. .... classes, such that room- and teaching-staff capacities are respected and the ...
Optimized Allocation of Exercise Classes and Study Management at TU Berlin Abstract At TU Berlin the number of students in major classes for students in their first semesters easily exceeds 2.000 in a single course (Analysis I for engineering students, for example). Due to this large number of students, simple organizational duties such as assigning exercise courses to students or tracking admission criteria for final exams become challenging. In this paper, we present an environment – the “MosesKonto” – that helps finding an optimal (in respect to student wishes) assignment into exercise groups and provides means for tracking and managing exam registration. Based on the data acquired in the summer term 2005, already 50% of all bachelor exams were managed through the MosesKonto at TU Berlin. 1. Introduction A common problem for big universities, that do not provide fixed timetables for their students, is the distribution of students into small exercise groups (so-called “tutorials”) accompanying the lectures. That is, many students with individual time constraints have to be matched to one or more tutorials on different time slots. Since the individual constraints are not known a priori, letting the students make ratings (often called “wishes” here) and finding a matching in that manner that as much as possible students are mapped on their highest ratings seems to be an appropriate procedure.
Figure 1: Number of students attending math-service lectures
2. Organization of Classes at TU Berlin One of the major challenges facing universities is the organization of the study supporting processes, especially in freshmen courses1. With about 30.000 students, TU Berlin is among the largest (counting students) technical universities in Germany. As a service for other faculties, the institute of mathematics is in charge of the mathematical education of most students, independent of their actual course of studies, making it the biggest “service provider” of the university. Since a major reorganization of the math-service five years ago, every year, 9.000 to 10.000 (cf. Fig. 1) students from 18 different courses of studies are taught courses in one of the six “math-service” engineering modules (Analysis I–III, Differential Equations, Integral Transformations & Partial Differential Equations, Linear Algebra). The largest module is the freshmen course in Analysis with a total count of more than 2.200 students per semester.
The modules are organized as follows: In order to guarantee lecture class sizes of less than 250 attendees, multiple lectures are held in parallel. The lecturers of the individual lecture classes take care of presenting the same mathematical material to all attendees. In addition to lecture classes, all students have to solve the same exercises as homework and, in the case of sufficiently good homework score are admitted to take the written examination at the end of the semester. Students also are eligible to attend a small-sized exercise class where the material of the lectures is manifested. The following list summarizes the administrational duties for performing math-service: • • • • •
Assign all math-service students to exercise classes Manage homework scores for admission to final examinations and course credits Management of student registration for examinations Inform students about examination scores Collect and submit examination scores to the central office of examination.
Although all of the above tasks are typical administrational duties for student management at universities, the large course sizes make them very time-consuming and labor-intensive. This is especially true for the assignment into exercise groups for every module: All students have to be assigned to small (meaning total sizes of 15 to 30 students each) groups such that assignments do neither conflict with each other nor conflict with the individual schedules of the students while respecting certain capacity restrictions. But, the large course sizes not only present difficulties; they imply a great opportunity of rationalization in the student-administration. Against this background the development of MosesKonto2,3 (Moses as acronym for Mobile Services for Students and Konto as the German word for account; cf. the left side of Fig. 2 for a screenshot) began in 2002 and was initially deployed and used since 2003 for all courses within the math-service modules described above. Since the winter term 2005/6, the assignment into exercise classes and management of exams has been extended to cover further courses, even
across different departments. More courses are expected to follow in the upcoming winter term 2007/8. 3. Assignment into exercise classes Every student who attends a course in one of the math-service modules is eligible to attend an exercise class. The number of attendees for a particular course is not known until the semester starts, as the enrollment process does not end until then. The students do not know their complete schedule until this time either, and the variety (with respect to course of study) of students that attend math-service courses imply a great variety in individual schedules. These two facts make it impossible to fix a set of dates for exercise classes in advance. Instead, one is forced to find dates for these classes in the first week of a new semester, by taking into account all students’ timetables. Until the winter term of 2002/3, the assignment of students into exercise classes was performed independently for every math-service module. The procedure required all students of a particular module (up to 1.000 people at that time) to gather in the main lecture hall to receive their exercise class dates. The students were numbered and subsequently drawn by lot to choose their most preferred date from the remaining dates in the global pool of exercise classes. Of course, this procedure did not guarantee that every student received his most preferred date, but it did ensure that the assignment of a whole course is feasible within 90 min. The integration of additional courses (and thus increasing the number of students to be administrated by math-service) invalidated the above assumption about the feasibility of the assignment method. In fact, the last time the above method was applied, it took several hours and forced more than 2.000 students to be physically present in a completely overcrowded main lecture hall construed for 1.200 students (cf. Fig. 2 on the left).
Figure 2: Main lecture hall during the assignment of exercise classes at the beginning of Winter Term 2001 (left), Web-interface of the Moseskonto (right)
Since this development in the number of attendees was foreseeable, the development of a webbased registration procedure (cf. the right-hand side of Fig. 2) began in the spring of 2002; the new method has been used since the summer term of 2003. The major goals of the new procedure were: • • • •
Gather early information on the expected number of students for every module Take into account the student’s individual schedules by collecting their “wishes” for dates Distribute students as even as possible among all exercise classes of every module Assign students such that no date conflict arises for students that attend courses in more than one module.
It was not possible (for various reasons) to access the personal data of the students from the central office of enrollment. Thus, to realize a procedure that respects the requirements above, students would need to register at MosesKonto and create a personal account. But, as a side effect, the same personal data can be used to manage the final exams. The latter is a great improvement over the established way of registering for an exam: students had to register at the central office of examination with a paper form, from which a press copy of their registration form is sent to the department of mathematics, where these copies are entered in an excel sheet. Of course, numerous transcription errors are produced that way. All of the above requirements could be easily met by means of an assignment procedure operating on a first-come-first-served basis. But it would favor those students over others, who receive their certificate of enrollment earlier. And from a technical point of view, it would concentrate the registration traffic on a very short time span, which means that the system probably would not scale well for increasing numbers of students. This motivated our decision for a global optimization method: Over a given time span, say, two weeks, students have the opportunity to chose their personal priorities from a range of possible dates for every mathservice module they would like to attend courses in. All students will choose their favorite dates using their MosesKonto account, and can revise their choices at any time. After the registration time span, the collected data is used to compute an assignment that is optimal in respect to all student’s priorized dates (“wishes”; see chapters 4 and 5 for a detailed description). 3.1 Student Groups Often, students have organized themselves into groups of two or three to work collaboratively on their homework, for example. It is desirable, although not essential, to let all group members attend the same exercise class. MosesKonto offers the opportunity to register for an exercise class as a group, which implies that all group members have to choose the same priorities for the available exercise class dates. The functionality to mange groups (change groups, step back, etc.) is provided through MosesKonto as well. These groups are not formulated as constraints in the global optimization problem, but some care is taken to respect these wishes for groups if possible.
4. The Global Optimization Step in Detail The optimization step involves the computation of all assignments of students into exercise classes, such that room- and teaching-staff capacities are respected and the computed solution is optimal in respect to the given priorization of dates. The problem admits a formulation as a constrained minimum-cost-flow network problem3-8. An example of this network for a sole course is depicted in Fig. 3. The resulting integer linear program finds a solution in acceptable time, that is, less than one minute for the largest instances seen so far on a recent machine. The data from MosesKonto is accessed and preprocessed by the software TUTOP10, which also formulates the integer program that is then to be solved by the commercial software CPLEX11. For the last part, any solver with the capability of solving integer linear programs could be used instead of CPLEX. In addition, TUTOP has built-in primal heuristics which can be used to generate “good” feasible solutions to the integer linear program as well10. The remainder of this chapter is dedicated to sketch a typical work flow using TUTOP. Altogether, it takes less than a day to produce the assignments for all students and exercise classes and to publish the results online with MosesKonto. The exercise class dates, from which the students define their priorities, are dates on which courses are principally able to offer exercise classes (for large courses, the whole week can usually be covered). Simply monitoring the (first) priorities during the registration time span, provides a way to know ahead of time when teaching staff and rooms are likely to run short, so that adjustments to either of these cases can be made in time. 0123 3 7654 s1
(0,1,0)
(0,1,0)
s PQRS WVUT
+W
0123 2/ 7654 t1 > >> >> >> >> (0,1,cp (p(s2 ,k),t1 )) >> >> (0,capup .. 0123 1 7654 s2 k (t1 ),0) >> . >> >> (0,1,cp (p(s2 ,k),tj )) >> >> > up (0,capk (tj ),0) t ,7654 .. 0123 PQRS / WVUT tj . −W @ (0,1,cp (p(s1 ,k),tz ))
(0,1,0)
.. . + 7654 0123 sn
()*+ /.-, vi
(0,1,cp (p(s1 ,k),t1 ))
(min,max,cost)
.. .
(0,1,cp (p(sn ,k),tz ))
(0,capup k (tz ),0)
7654 /% 0123 tz
7654 / 0123 vj
Figure 3: Network for a sole course. (Knots & Edges labeled according to Dimacs-Min9)
After the end of the registration time span, it has to be defined how many parallel exercise classes have to be realized at a certain date for each module. Of course, room- and teaching staff restrictions must be adhered to by the choices made. It should be noted that TUTOP does not explicitly optimize the use of room- and teaching staff resources; both are set by the responsible person for the exercise class assignment (the “planner”). TUTOP provides guidance for the decisions about rooms and teaching staff to be made, and returns an optimal set of assignments subject to the maximum number of students that can be covered by exercise classes for a certain module at a certain date. Put differently, TUTOP expects a capacity for every date/exercise class combination defining the maximal number of students that can be assigned to that combination as input. The established procedure for defining these capacities operates in a per-module fashion. In the first step the optimization is performed with infinite capacities. The solution of this problem yields information that the planner can use to allocate rooms and teaching staff for the exercise class dates of the first module; he tries to allocate resources as close as possible to the optimum with infinite capacities. Once the two resources (rooms and staff) are set by the planner, they define the finite capacity for all dates for which the module in question offers exercise classes. Using these capacities as input for TUTOP, a new solution (with infinite capacities for the remaining modules) is computed in CPLEX and the process is iterated for each module. Convenient LATEX lists and csv files are generated providing the individual responsible for the modules with the exercise class dates that are the result of the assignment. Of course, one could just as well define all capacities for every module in advance and let TUTOP compute the solution accordingly. But with the methodology described above, the planner has more detailed information at every stage, usable to revise the resource allocations. For this task, TUTOP has been equipped with a convenient graphical user interface providing the planner with views of all important information. Moreover, if all capacities are set without the feedback from the individual optimization stages, it is more likely that cases arise in which students cannot be assigned to any exercise class at all. Once the optimization is completed, that is, every module has been set to finite capacities, the solution from TUTOP is provided as input for MosesKonto. The post-processing step not only involves correctness tests of the assignment, it also takes some care to incorporate the student’s wishes for groups (see subsection 3.1) into the optimal solution. By means of their personal MosesKonto account, all students can find out about the exercise class dates they have been assigned to. Authorized staff members can also use their MosesKonto accounts to generate lists (csv, LATEX) of participants in exercise classes, both globally for all and locally for individual exercise classes. They are also authorized to move students from one exercise class date to another (or to delete them or to include other students). Some care has to be taken that such manual post-processing operations do not create conflicting dates for students; the number of such post-processing is generally small so that in practice this problem does not account for a lot of work.
5. Algorithm Describing this procedure in terms of a network flow problem is very easy: let si 0 S be a student. We link nodes tj 0 TS representing distinct timeslots to him, and regard a link of each such node to another tj 0 TC as a rating. Since each tj 0 TC represents a tutorial then, we describe the capacity of this tutorial cap(tj,cl) as the upper bound of the arc linking the tutorial with the sink. Defining the flow at the (artificial) source s to be the total demand of tutorials, only one problem persists to be resolved: every student shall get exactly one tutorial for each course he wishes to attend. In order to guarantee this, we define some cuts w to be bundle-capacities that force this property. The problem formulation as an integer linear programming problem follows here:
Here W is regarded as the set of arcs representing wishes and cp(w) the associated cost (here the priority that a timeslot was rated with). Clearly, relaxing (4) the problem becomes a simple minflow problem which can be solved very fast; this fact can be used for a lot of special tailored dual strategies to get a primal solution [12]. However, it turned out that this problem is a “wellsuited” one: Even on large instances (5.500 tutorial seats, i.e. more than 105 variables) solutions can be acquired pretty fast using standard linear programming techniques and tools. An example network for several courses is diagrammed in Fig. 4. 6. Evaluation of the Computed Assignments The quality of the solutions achieved by the method described above is generally very good, even under rather tight capacity restrictions. As an example the results from the assignments in the summer term 2005 are discussed. In total, 4.198 “seats” have been assigned, where 4.392 had been available.
source
students
s-timeslots 0123 UJ 7654 oo7 t1 H
σw
c-timeslots 0123 i 2 7654 v t1 9
sink
99 ooo 0123 4 ; 7 99 0123 1 7654 ooo hhhh37654 t t 2 2 o A , ; o AA 99 o hhhhh o o H h 9 ohohhh U Σ≤1 i v + .. .. AAAA999 0123 7654 9 s1 VVVVVV s . . AA99 s VVVVV ss , AA99 VVV+ ss 1 ) 0123 7654 0123 7654 A s U t t s U z z U s UUUU A9A9A9 4 ss U s U UUUA9* s J .. .. '&%$ !"# 4 > !"# Σ≤1 Y R s KsKK i'&%$ t .cl . iiii}} H i KK i i } i KK i R } i Y 0123 KK } 0123 Z 7654 t1 i KK k e -1 7654 }} hhhh3 t1 R H h KK h } h h u } K% hhhhhh RZ k .. .. }}}} 0123 7654 sn VVVVV Σ≤1 e . . }} VVVVV VVVV+ } -&. 7654 0123 7654 0123 tz tz
s
(0,n(si ),0)
/
S
(0,1,0)
/ TS
(0,1,cp (si ,tj ,cl ))
/ TC / (0,cap(cl ,tj ),0)
t
Figure 4: Network for several courses (The boundaries and costs for all edges are denoted symbolically in the lower row). Fig. 5 breaks down the above numbers into the six modules mentioned in chapter 2.
Figure 5: Quality for each module (left), overall quality (right) It is worth noting that the good fill rates could not have been achieved without a preliminary analysis and allocation of available resources during the registration time span. By doing so, teaching staff can be moved from one module to another and additional room resources can be acquired ahead of time. During the registration time span, students had to prioritize five dates for every module they would like to attend exercise classes in. The mean priority of the assigned exercise class dates was 1.27 and every student received a date among his prioritized dates. An additional measure of quality can be derived from the “mean of assigned priorities. For every module, it shows the theoretically possible best mean (between 1 and 1.05) of assigned priorities
and the achieved mean (between 1.05 and 1.35). The first is defined by the mean of an optimal set of assignments when an infinite number of rooms and teaching staff members would be available. Even in that case, the mean is greater than 1, since students may choose the same date as first priorities for different modules.
Figure 6: Numbers of places for different modules vs. numbers of required seats. 7. Administration of Examinations As a rule, each student participating in the service courses “mathematics for engineers” has to pass a written final exam (consisting of up to three separate written tests) for each module. As a result, up to 8.000 written exams have to be handled, creating a substantial administrative overhead. The efficient organization of such large exams requires punctual registration on the part of the participating students. The results have to be published and forwarded to the central office of examinations of the corresponding departments, possibly followed by final corrections based on students’ searching of the exam. Finally, the results have to be processed statistically to provide the responsible deans with information concerning the success of the courses. To satisfy the regulations imposed by the different courses of studies it is necessary to hold up to three different (though identical in content) exams. As a result, the students feel insecure which exam they have to register for. To alleviate this problem, the students are only presented with the appropriate exam for their particular course of studies when registering for the final exam for a given module. Registration for final exams for compulsory optional subjects and exams governed by older or more “exotic” examination regulations has to be done in person at the service center, which also has access to the examination administration of the system. When “creating” an exam in the database, the registration and deregistration periods have to be specified. Students have to (de-)register during that specified period only, deregistering for (officially certified) medical reasons being the only exception being handled exclusively by the central office of examinations.
Information for each exam is available for download by the service center or other authorized staff in the form of a zip-file containing the following: • •
• •
•
A list of all students registered for this exam, including their personal data and the results of the exam (in csv-format) Separate lists for each course of studies, containing the names and personal data of each student registered for the exam to be forwarded to the central office of examinations (LATEX -Format) A complete list of all registered students including personal data for proof of identity during the exam (LATEX -Format) Separate lists for each course of studies, containing the names, personal data and exam score of each student registered for the exam to be forwarded to the central office of examinations (LATEX -Format) A complete statistic including a graphical representation of the results (LATEX -Format)
The lists of registered students forwarded to the central office of examinations replace the more traditional registration forms handed in by the students in person. Similarly, the lists containing the result, once signed by the professor, replace the minutes of the examination previously required for each student separately. The complete csv-format list of participating student is used as the basis for assigning the students to the rooms available for the examination and to determine the needed capacity and thus required rooms in the first place. 8. Administration of Homework Most courses of study require mandatory homework as a prerequisite for admission to the exams. However, some few courses, that have a large number of students though, form an exemption from this rule. As a result, homework is a prerequisite for approximately fifty percent of all students. The homework-related criteria that are to be met for admission to the exams are currently dependent on both the module and the professor teaching it. In consequence, it is necessary to store the criteria (as a boolean) for each module and each semester separately. Authorized staff can access the list of course participants at the end of the semester to add if the student met the homework-related criteria or not. The system does not check if the homework-related criteria are met during the online registration for the exam as the last homework assignments are regularly neither handed in nor graded by the time the registration period has expired. The registration lists, however, contain the information about which students met the criteria, enabling the service center to deregister students if appropriate.
9. Access Rights Management Typically, the users of the system fall into one of the following groups of people requiring fundamentally differing access right that can even vary between departments: •
• • • •
Students, as a rule, are granted access to their own personal data and nothing else (exception: courses allowing team work, see section 3.1). They are given write-access for their own data and for registering for exams or exercise classes, otherwise read-access only. The Administrator is given access to all information; he is provided with additional, special rights, such as the creation of new modules. Employees of the Service Center are usually responsible for all communication with the central office of examinations and is the central contact for all students. Teaching Assistants are often responsible for entering the results of exams and similar tasks. Tutors will input if the homework-related criteria are met and have access to the personal data of their students.
The growing interest of other departments to use the MosesKonto for the registration for their own exercise classes, examination and student administration outside the mathematical service modules requires an expansion of the access right management to facilitate the independent administration of their students. These changes have to account for different access right requirements for the above mentioned user groups. As a solution, we have implemented a hierarchical access rights management system mirroring that of UNIX. All reading or writing rights for the different types of information (e.g. access to the students’ personal data or to their examination results) are treated as a single, independent resource. Passing these resources (reading or writing) is treated as a third type of resource. User groups (e.g. teaching assistants) can be created and are defined by their associated access rights. The owner of a group (either because he created it or it was associated with him by default) has the right to add or remove members of the group or grant access rights to group members within the limits of his own rights. Students are outside this access rights management, as their rights do not have to be defined on a per-module basis. The right to register for an exam for example can be managed through the use of a registration time period. 10. Experiences with the System The MosesKonto has been deployed successfully at the TU Berlin for three years. The registration for exercise classes for the mathematical service modules would be impossible without the online registration given the steadily increasing numbers of participating students each semester. The online registration spares both the students and the teachers from timeconsuming in-situ registration while better addressing the needs of students. The approach of a global optimization implemented in the system requires a significant amount of effort in the mathematical modeling of the problem but provides the following, significant advantages:
• • • • •
conflict-free assignment of exercise classes across several, different modules optimal adaptation to the wishes of the students optimal use of existing room resources optimal use of existing staff resources instantaneous information concerning number of participating students
The deployment of the MosesKonto to administrate exams has been equally successful. Without the use of online registration it would have been impossible to keep up with the vastly increasing number of students in the mathematics service courses for engineers (almost doubled in the last few years). The online registration has saved students hours of waiting commonly associated with the registration for an exam. Starting with the winter semester 2005/6 the use of the MosesKonto has been extended to cover modules beyond mathematical service courses. New modules administrated through the system include electrical engineering, modules in the computer sciences, mechanics and the material sciences. For the summer semester 2006 standard mathematics courses and the service module in physics for engineers courses will be added to the list of modules included in the MosesKonto. In consequence, the MosesKonto will administer the exercise class administration for the largest and most important service courses for engineers. The conflict-free assignment of exercise courses for these important exercise classes represents a significant improvement in the course administration. Next to the mathematical service courses, “physics for engineers” and “mechanics” are the largest single modules offered at the TU Berlin. Starting with the summer semester 2006 the MosesKonto will be extended to include the examination registration and administration of these courses as well, following the coordination of the transition with the central office of examinations. 11. Outlook One desirable future feature of the system would be a direct, automatic exchange of data, in particular, of the registrations for and results of examinations with the central office of examinations. This exchange could be realized in the form of the transfer of data in an XMLformat, replacing the current, error-prone, manual transfer of data. Preliminary efforts of coordination have shown the general willingness of the central office of examinations to participate. However, certain adaptations to their software are required and are not yet implemented. On the technical side we are working on our own solver in order to be independent of proprietary software and thus allow for the employment of the MosesKonto at other universities at no charge (cf. Fig. 7 for some preliminary results of our own implementation. In addition to the inclusion of minor, new features, such as the ability to store the results of weekly assignments separately, that have resulted from the requirements of other departments, the MosesKonto is currently undergoing a redesign of the optimal allocation of exercise courses. The aim of the optimization lies in a single-pass allocation including the corresponding room
assignment. This has to include additional constraints such as preferences for certain specific rooms expressed for a given module that are hard to quantify within the mathematical model.
LinAl Ana1 Ana2 ITPDE ODE
All
Figure 7: Comparison of the results currently achieved using CPLEX and our own solver
Bibliography [1] Malave, C.; Imbrie, P. & Watson, K., “Intervention programs for a freshman integrated curriculum”, Frontiers in Education Conference, 1999. FIE '99. 29th Annual, 1999, 3, 13D7/3-13D7/8vol.3. [2] Grottke, S., Jeschke, S., Lach, G., Luce, R., Pfeiffer, O., Sablatnig, J., and Zorn, E., “ MosesKonto: Student Management and optimized exercise class assignment at TU Berlin”, Proceedings of the E-Learn 2006 ,Vol. 5, pp. 2839 2840. [3] Grottke, S., Jeschke, S., Lach, G., Luce, R., Pfeiffer, O., Sablatnig, J., and Zorn, E., “MosesKonto: Optimiertes Verteilungsverfahren für Tutorien und Studierendenverwaltung an der TU Berlin”, DeLFI 2006: 4. e-Learning Fachtagung Informatik der Gesellschaft für Informatik e.V. (GI), pp. 385 386, 2006. [4] Ahuja, Ravindra K., Magnati, Thomas L., Orlin, James B. (1993), „Network Flows: Theory, Algorithms, and Applications“, Prentice Hall, New Jersey, USA. [5] Corman, Thomas H., Leiserson, Charles E., Rivest Ronald L., Stein, Clifford (2001), “Introduction to Algorithms”, 2nd edition, MIT Press and McGraw-Hill, New York, USA [6] Löbel, A. (2000) MCF - A network simplex Implementation (v1.2). www.zib.de/Optimization/Software/Mcf [7] Nguyen, V. & Tan, Y., „Minimum convex cost flow problem“, Proceedings of the 2003 Joint Conference of the Fourth International Conference on Information, Communications and Signal Processing, 2003 and the Fourth Pacific Rim Conference on Multimedia., 2003, 2, 1248-1252vol.2 [8] Salehi Fathabadi H., and Shridel, G.H., “A O(mn) Time Algorithm for Solving Minimal Cost Network Flow Problems”, Asia-Pacific Journal of Operational Research (20), pp. 161-175, 2003. [9] The first DIMACS international algorithm implementation challenge: Problem definitions and specifications. ftp://dimacs.rutgers.edu/pub/netflow/general-info .
[10] Luce, R., „TUTOP – Tutorienplätze optimal verteilen“, Seminar Paper, TU Berlin, Germany, 2003. [11] ILOG CPLEX, www.ilog.com/products/cplex/ [12] Schrijver, Alexander (2003). “Combinatorial Optimization, Polyhedra and Efficiency”, Volume A. Springer Verlag, Berlin, Germany.
