Key takeaways
- Specialist-room needs are hard: the wrong room type makes the slot no solution.
- Room availability is a primary infeasibility driver; model it before the first run.
- Stations, benches, and machines cap how many groups share a space.
- Most room failures are data failures: types, availability, and capacity recorded wrong.
The room facts to capture
Room failures are usually data failures. Capture these before judging any run.
- Room type: which lessons can this space host at all
- Availability: when the room can be scheduled
- Capacity: how many students the space takes
- Equipment: stations, benches, machines, and what they limit
- Sharing rules: which groups or subjects compete for the space
- Which lessons genuinely require the specialist space
Hard where the lesson cannot run
The hard-soft line for rooms is a single question: can the lesson run in this space at all? A lab class in a standard room is not a worse timetable, it is not a timetable. Those requirements are hard constraints and belong in the model as such.
Everything above that line is preference: nicer rooms, shorter walks, a department staying on one corridor. Those carry weights, not vetoes, for the reasons covered in hard constraints.
How to do this in Smootables: rooms, equipment, and allowed rooms
Rooms and Equipment are resource types in Resources, with the same rule surface as teachers where it applies: room unavailability is entered under Availability as full-day blocks or repeating in-day rules.
The type rule is enforced per study unit: Study Unit Settings carry the allowed rooms for that subject, and the solver treats them as hard. On an individual placement, the room can be Any room, specific rooms, Remote (no room), or To be decided later. When a solve fails on rooms, the report says so in typed causes (a room pool too small, a room not allowed, room capacity too small) with suggested actions such as changing allowed rooms or adding rooms.
Preparing room constraints
The aim is that the first infeasibility report points at real scarcity, not at missing data.
- Audit the rooms: types, capacities, and the equipment in each.
- Record availability for every shared or specialist space.
- Attach room requirements to the subjects that genuinely have them.
- Leave general lessons free to take any suitable room.
- Check demand against supply per room type before generating.
- Treat repeated clashes over one space as a scarcity signal, not a scheduling bug.
When the room model meets the others
Room constraints interact: a specialist room narrows options, the teacher who can take the class narrows them again, and the group's other lessons narrow them a third time. Infeasibility usually arrives from the intersection, which is why single-constraint reasoning misleads.
The repair work is data-first: data preparation covers the audit, and the recipes for the two sharpest cases are restricting rooms by subject and workshop room capacity.
Questions planners ask about room constraints
Why is the timetable infeasible when rooms are visibly free?
Free is not the test; suitable is. If the lessons that remain all need the same specialist rooms at the same times, the free general rooms are irrelevant. That is why room availability drives infeasibility so often.
Should room preferences be hard constraints?
Only room requirements. A science class that cannot run outside a lab is hard. A teacher who likes room 12 is soft, and hardening that wish is a classic way to make a timetable impossible.
How does equipment differ from rooms in the model?
Equipment is a countable resource inside or across rooms: stations, benches, machines. It constrains how many groups can work at once, which is a capacity rule rather than a location rule.