Basic Cost Components $($Hard Constraints$)$:

Lectures:

Representation: Binary decision variables indicating whether a lecture is scheduled at a specific time and in a specific room.

Constraint: All lectures of a course must be scheduled, and each lecture must be assigned to a distinct period.

Conflicts:

Representation: Pairs of lectures from courses in the same curriculum or taught by the same teacher.

Constraint: Lectures with conflicts must be scheduled in different periods. Violations occur if conflicting lectures are scheduled together.

RoomOccupancy:

Representation: Pairs of lectures that cannot take place in the same room at the same period.

Constraint: Two lectures in the same room at the same period represent one violation. Extra lectures in the same period and room count as additional violations.

Availability:

Representation: Teacher availability for a specific course at a given period.

Constraint: If the teacher of a course is not available at a given period, no lecture of the course can be scheduled during that period.

RoomCapacity:

Representation: Binary decision variables representing whether a room is selected for a lecture.

Constraint: The number of students attending a course must be less than or equal to the number of seats available in all rooms hosting its lectures. This constraint is soft, with penalties for exceeding room capacity.

Optional Cost Components $($Soft Constraints$)$:

MinWorkingDays:

Representation: Binary decision variables indicating whether a lecture is scheduled on a specific day for a specific course.

Constraint: Lectures for each course must be spread over a minimum number of days.

IsolatedLectures $($Compactness v$.1)$:

Representation: Binary decision variables indicating whether a lecture is isolated from others in the same curriculum on the same day.

Constraint: Lectures belonging to a curriculum should be adjacent to each other $($in consecutive periods$).$

Windows $($Compactness v$.2)$:

Representation: Binary decision variables indicating whether there is a time window between lectures of a curriculum on the same day.

Constraint: Lectures belonging to a curriculum should not have time windows between them.

RoomStability:

Representation: Binary decision variables i$1.$ Project Overview:

The project centers around solving the Curriculum$-$Based Course Timetabling $($CB$-$CTT$)$ problem, which involves scheduling university course lectures. The objective is to establish a set of standardized formulations for CB$-$CTT$,$ allowing researchers to compare and evaluate their results consistently. Real$-$world data from various universities forms the basis for creating instances in the project.

$2.$ Problem Definition:

CB$-$CTT requires the scheduling of university course lectures within a specified number of rooms and time periods. Various constraints, such as conflicts, teacher availability, and room capacity, must be taken into account to generate a feasible timetable.

$3.$ Motivation:

Many research papers tend to create unique formulations tailored to their specific institutions, making it challenging to compare results. The project aims to provide standard formulations $($UD$1$ to UD$5)$ to facilitate comparisons and bridge the gap between theoretical research and practical implementation.

$4.$ Formulations:

The project introduces multiple formulations $($UD$1$ to UD$5),$ each with specific cost components and weights. Basic cost components include aspects like lectures, conflicts, room occupancy, availability, and room capacity. Optional cost components include considerations for working days, lecture isolation, window constraints, room stability, and more.

$5.$ Instances and Data:

Instances in the project are derived from real data at various universities, including instances from the ITC$2007$ competition. Additional instances $($DDS$1$ to DDS$7)$ from different Italian universities are also included. Data features cover information such as the number of courses, lectures, rooms, periods per day, days, and curricula.

$6.$ Data Formats:

To represent the problem instances, the project introduces an extended data format called $.$ectt. This format extends the existing $.$ctt format used in the ITC$2007$ competition. An XML format is also provided for flexibility.

$7.$ Problem Management System:

A web application, known as the Problem Management System $($PMS$),$ serves as the project's central hub. The PMS includes tools like validators, instance generators, and an online solver to facilitate benchmarking. Users can submit their solutions, lower bounds, and new instances through the PMS$.$

$8.$ Google Colab and Python:

The project code is intended to be implemented in Python and run on Google Colab. The optimization model will be solved using IBM CPLEX and docplex.

$9.$ Request for Code:

You've requested a Python implementation of the CB$-$CTT problem using Google Colab, IBM CPLEX, and docplex. The code should cover decision variables, constraints, and the overall formulation of the CB$-$CTT problem.