Messages

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.

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

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.

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