Hello Mr. Liviu,
Thank you again for all the improvements in FET.
I would like to suggest adding a new type of constraint:
Constraint: "Maximum number of students in specific time slots"
This constraint would allow us to define a maximum limit of students that can be scheduled during certain selected time slots.
It could be very useful in both exam and lesson timetabling cases — for example, to ensure that the total number of students in simultaneous activities does not exceed a given capacity during specific hours.
For example:
Suppose we select Day 1, Hour 1 and Day 2, Hour 1 in the time selection screen, and set the maximum number of students to 200.
When generating the timetable, FET would then ensure that the total number of students scheduled in those selected time slots does not exceed 200.
This would help control room usage, exam session capacities, or student distribution across time, even without defining individual rooms.
Thank you very much for considering this suggestion.
Best regards,
Furkan Kızılaslan
Hello, Mr. Furkan,
Thank you for your kind words!
I will think of this. But, as a first impression, trying to avoid adding a new constraint type, please tell me if you are certain you cannot use an already present constraint type: activities max simultaneous in selected time slots. In this constraint, you could select all the activities of the timetable, select Day 1, Hour 1, and Day 2, Hour 2, and specify say max activities to be 10. How about this possibility?
Hello Mr. Liviu,
Thank you for your reply!
Yes, I am aware of the "activities max simultaneous in selected time slots" constraint — it is indeed useful.
However, my idea focuses on controlling the total number of students, not just the number of activities.
For example, imagine we have 10 small groups of 10 students each, and 2 large groups of 100 students each.
Even if both types of activities happen in the same time slot, the total student count can differ drastically.
The current constraint limits how many activities can happen simultaneously, but not how many students are involved in those activities.
That's why a constraint like "maximum number of students in selected time slots" could help ensure balanced student distribution or capacity control (for exams, shared resources, etc.), independently of how many activities exist.
You are welcome, Mr. Furkan! Thank you as well for the suggestion!
So, as a final doubt of mine, isn't it possible to use rooms and rooms' capacities?
@Volker Dirr ,
@Vangelis Karafillidis , and other users, what do you think? We could add a constraint
activities max total number of students in selected time slots, or something like that, and even use it for something more, like having A1 (2 students), A2 (1 student), and A3 (1 student), and saying, with max = 2, that a slot can have either A1 or (A2 and A3).
I will think of the feasibility of this potential new constraint.
And, important for the FET project: could we gather some donations/sponsorships for this, if it is possible to implement in the FET algorithm?
I think in normal case it is fine to use the existing room constraints for this problem.
if you have a very low number of rooms, then there might be 2 cases we might need to think about:
a) for writing exams you might want to place several groups into a single room
b) for writing exams you might in worst case (if you are very low on room capacity) need to split a group on 2 or more rooms. But in fact this is not easy, since you also need to tell it the students and you also need to tell it teachers (so they have enough papers for the writing exams.
But on the other hand I don't think that in real live variant b) makes much sense, since 1) telling the student the exact room is still not solved by that and 2) in normal case you are teaching the students also in that building the weeks/months before, so there should be enough room. I am not sure about online universities without teaching activities in the building, only exams in the building.
And for variant a) I think the best practice will be to manually choose the groups that can be together in a single room and just put that groups into a single activity and use room constraints.
But maybe furkankzlsn can tell us why variant a) doesn't work in his institution and if variant b) (in fact he suggested something that will end into splitting groups into (in worst case) a lot of different rooms) is useful. I fear if you do it, it will end up into a small nightmare, since then you need to tell each single student where to go and you need to care about the right papers in the right room.
Hello
@furkankzlsn,
@Liviu Lalescu and
@Volker Dirr.
For preparing the exams schedule, I preferred to work on a spreadsheet. The reason is that adding all the necessary data to FET is time consuming. For Greek schools, most of the time the exams schedule is quite easy. So, although FET lacks this type of constraint, I am not sure if the implementation of this new constraint is really going to benefit a significant number of users. I think that most FET users would prefer to work on a spreadsheet for preparing the exams schedule.
Vangelis.
Hello
@Liviu Lalescu,
@Volker Dirr,
@Vangelis Karafillidis, and everyone,
Thank you for the thoughtful feedback.
Let me clarify the underlying need in a general, room-independent way:
In many high-capacity exam timetables, room assignment is a post-processing step.
Data import is easy, but institutions often have complex room policies (multiple buildings/floors, heterogeneous capacities, distribution per floor, invigilator balancing, late room changes).
Because of that, we frequently generate the time layout first, and only afterwards split/assign rooms according to local rules.
In such contexts, controlling capacity through rooms is not practical at the time-generation stage. For example, a single slot (e.g., Day 1 – Hour 1) may reach up to ~2000 students across many activities. Using room constraints would force premature room commitment and entangle scheduling with local post-allocation rules.
What would help broadly is a time-based capacity constraint, independent of rooms:
Proposed constraint (room-independent):
"Maximum total number of students in selected time slots."
Semantics: For a selected set of time slots, sum the student counts of all activities placed there and require Total ≤ Max.
Scope: Works regardless of the number of activities or eventual room splits; it operates purely on the time axis, not the space axis.
Example: Select Day 1–Hour 1 (and others if needed), set Max = 2000 → the solver ensures the total students scheduled in that/these slot(s) never exceed 2000.
This complements (not replaces) room constraints and addresses the stage before rooms are fixed. It also generalizes nicely to other use cases:
Campus- or building-wide density limits per hour for safety/logistics.
Balancing large vs. many small exams across the day.
Managing invigilation/entry flows when rooms are assigned later.
On Volker's points (a/b):
(a) Manually grouping several cohorts into a single activity to share a room loses granularity early and doesn't prevent global slot overload across many parallel activities.
(b) Splitting one cohort into multiple rooms is indeed an operational necessity sometimes, but that split typically occurs after time placement. A time-based cap prevents overload before we reach that stage, without forcing room choices.
On simplicity and adoption:
Small schools may continue to use spreadsheets effectively. This feature would be optional and primarily benefit medium/large institutions or centralized exam centers. Even a minimal first version (just "sum ≤ max" on selected slots) would already be very valuable. A future iteration could optionally allow filters (e.g., by year/department/tag), but that is not required for the initial step.
Feasibility notes (to help design):
Counting should be based on each activity's known student count (or the size of its student set).
If two activities share some students, either:
count by declared activity sizes (simpler, may double-count overlaps), or
count unique students if that information is available (more precise).
A simple v1 could choose (1), with (2) as a potential enhancement.
Interaction with existing "max simultaneous activities in selected time slots" is orthogonal: that limits activity count, while this one limits student count.
Thanks again for considering a time-axis capacity constraint. I believe it would provide broad, real-world value without forcing room commitments too early.
Best regards,
Furkan Kızılaslan
I appreciate this as a potentially useful constraint. I think the best would be activities max total number of students in selected time slots, so that we can apply, as Mr. Furkan said, to separate groups of activities.
Note, Mr. Furkan, that in a certain slot the activities cannot have common students.
I'll consider Volker's and Vangelis' opinions, but I hope they will consider implementing this constraint as something useful.
As I said, I need to consider also the financial matter for FET. The only way to monetize this project is through donations or sponsorships. So, please consider this aspect. My request for implementing this constraint would be 2000 (two thousand) euros, only if the work is 100% successful. Maybe we'll find sponsors. But, as usual (there were no such big donations until now, but we continued adding features to FET), I might consider implementing the new constraint even for free. I'll think about it.
Thank you, Mr. Liviu!
That's wonderful to hear — I'm very glad that the idea is considered useful.
Yes, the version you mentioned, "activities max total number of students in selected time slots," perfectly describes the intended logic.
I truly appreciate your openness and the time you dedicate to improving FET.
Many institutions, including ours, will surely benefit from this kind of flexibility.
Thank you again for your attention and for considering this idea so thoughtfully.
Quote from: furkankzlsn on October 16, 2025, 07:08:47 AM(a) Manually grouping several cohorts into a single activity to share a room loses granularity early and doesn't prevent global slot overload across many parallel activities.
First part of the sentence: Yes, maybe, if you have got very difficult room problems. But I guess in "normal" case there won't be such high problems. The advantage of this variant is, that it will simplify the second step very much.
The second part of the sentence is wrong. Of course it prevent the global slot overload, since the global slot overload is set by the room capacities and the room constraints. So you can set a global limit by that of course (yes, it is more difficult to get the exact limit, but it is 100% sure, that you will be below the limit.)
In my opinion doing 2 steps is always critical, since 2 steps also always mean that you need to share in worst case on multiple rooms many times. So might be much work in the second step. Yes, the first step is easier, but the second step will be much more complicated.
But if many institutions need this and if that is a highly useful real world feature, as furkankzlsn said, it should be easy for a few institutions to donate a bit and support your work, Liviu.