FAQ — Generation algorithm behavior

Frequently asked questions about the behavior of the automatic generation engine. For a description of the solver itself, see Solver; for the operational details, see Automatic generation.

Which timetable types does the solver work on?

On weekly, cyclic and calendar timetables. In calendar mode, lessons are placed on real dates and the generation options include date bounds.

How does the algorithm work?

Omniscol runs a solving process in the background. The solver evaluates the lessons to place, the declared constraints and the generation preferences. The result depends above all on data quality: hour volumes, teachers, rooms, groups, availability, incompatibilities and inter-site constraints.

Each generation starts a dedicated, parallelized computing environment. There is no queue to manage on the school side; initialization often takes around ten seconds before the actual computation begins. In the Timetable management module, the Generate timetable button starts the computation, tracks its status and lets you inspect the result.

The engine is a neuro-symbolic Monte-Carlo metaheuristic optimization AI: stochastic search, symbolic constraints and progressive score optimization. It does not promise success on an impossible set of constraints; in that case, Omniscol returns a diagnostic.

How long does a generation take?

The duration depends on the size of the timetable, the number of lessons, the number of constraints and the chosen options. As an order of magnitude, a middle school with around 550 students, 45 teachers and 16 classes, with plenty of availability, can obtain a complete timetable in under a minute, with very few or no gaps, when the data is consistent. A denser, highly constrained case, or one with costly optimizations, can take significantly longer.

Does the solver respect all constraints?

Hard constraints are strictly respected:

• a teacher in only one place at a time;
• a class without double placement, except for groups in a division;
• availability and time slots marked Unavailable;
• a standard room occupied by only one lesson at a time;
• a large room used only within its capacity and class-count limits;
• compatible specialized rooms, capacities, material resources and inter-site travel;
• locked lessons kept in place.

Soft constraints (undesirable availability, preferences, pedagogical weighting, day balance, number of attendance days, gaps in timetables) are optimized as well as possible. They create penalties: the solver looks for the solution that accumulates the fewest, but may keep some if that is the best compromise compatible with the hard constraints.

What if the generation fails?

When no complete solution is found, Omniscol returns the best computed timetable and leaves the unplaced lessons in the sticky notes bar. The partial timetable remains available to understand what was placed, then fix the constraints or reposition some lessons manually. The most frequent causes are described on the page Diagnosing a failed generation.

Can the position of a lesson be forced manually?

Yes, by locking a lesson after manual placement. The solver does not move a locked lesson during a new generation, but adjusts the others around it. Useful for anchoring immovable lessons (external speakers on fixed dates, dated exams).

Why doesn't the solver offer several solutions?

The solver optimizes according to the declared constraints and preferences and returns the best solution found. To obtain several solutions to compare, duplicate the timetable before each generation and slightly adjust the constraints or weightings between runs.

Does the solver take declared absences into account?

The solver works on the structural timetable, independently of absences. Absences are handled afterwards in the Absence management module (see Overview of the Absences module), affecting the display of the published timetable and the statistics of the Dashboard (not the underlying structure).

Deliberate conflicts and blocking conflicts

Not all conflicts are equivalent:

• Non-blocking conflicts — can be left as they are if this is a deliberate choice (for example, a room whose displayed headcount exceeds its capacity because you know that not all enrolled students will attend). The alert stays visible but does not block.
• Blocking conflicts — prevent the automatic generation from succeeding (no compatible room, inconsistent alignment, etc.). The Generate timetable button stays disabled as long as these conflicts remain.

See Conflict.