Step 7 — Automatic generation

Once the lessons are created, you position them on the grid. Building a timetable is in practice a cycle, not a one-off action:

1. you place a few lessons by hand — to anchor immovables or lock strong constraints (dated interventions, exams, manual anchors);
2. you generate (everything or a subset) so the algorithm places the rest under constraints;
3. you adjust at the margins — fix a special case, move a lesson, change your mind;
4. and it can loop back: you regenerate as you go (added lessons, or — in calendar mode — by date ranges, by batches of classes or campuses).

You can also do everything 100% by hand, without the solver. Manual placement (placing, moving, locking, one by one or in batches) has its own dedicated page: Manual placement. For the overall flow, see Module overview.

This page covers automatic generation.

Availability

Available on weekly, cyclic and calendar timetables. In calendar mode, lessons are placed on real dates and the options can limit the date range to generate.

Preparation

Before clicking Generate timetable:

• expand the Generation tab (labeled Checking on a calendar timetable) to check the global statistics,
• fix the critical alerts (red) — they block generation,
• review the warnings (orange) — they do not block but signal a risk (overly restrictive availability, borderline capacity, etc.).

The screen also shows:

• the number of lessons created vs lessons positioned,
• the hour volumes entered vs the teachers' service hours,
• the groups assigned to at least one course (to spot forgotten or unused groups).

Launching

Click Generate timetable. Omniscol spins up a dedicated, parallelized computing environment. The duration depends on the size of the timetable, the number of constraints and the chosen options. There is no queue to manage on the school side; initialization often takes around ten seconds before the computation actually starts.

The computation is capped at twenty minutes, but in practice this is far beyond what is needed: a timetable of about 200 courses often responds in about twenty seconds — the algorithm is nearly instantaneous, most of the time goes into starting the machine — and ~600 courses in about one minute. For a very large institution approaching this cap, the Omniscol team can increase the power of the computing machine, on request.

Generation options

By default, generation places all the created lessons that are not yet positioned. It can also move already positioned lessons if that improves the timetable. Locked lessons keep their position.

The options menu notably lets you:

• manage rooms with three choices: optimized assignment by default, verification only, or ignoring rooms entirely;
• select only certain classes or certain subjects;
• restrict a calendar timetable to a target date window;
• ignore already assigned rooms or the current placements;
• assign only the rooms without recomputing the whole placement;
• run a fast generation without optimization;
• allow flexible placement on the sub-slots of the time grid when the timetable uses sub-slots.

The advanced optimization settings also let you reduce gaps, avoid two lessons of the same subject on the same day, spread lessons out, set hour minima or maxima, or choose the number of attendance days for teachers. Practices vary across countries: in France, some institutions aim to reduce the number of attendance days for teachers; in other contexts, you may instead prefer to spread those days out, for example to organize other on-site duties.

Calendar-mode-specific options

In calendar mode, the advanced options can limit generation to a target date window shorter than the total range of the timetable. This is useful to generate only part of the year: a one-month test, progressive construction of a semester, or reworking a period already prepared.

The other important option is day compacting for classes. By default, the solver tends to seek a balance across the available days; if you generate only part of the year's lessons, this behavior can artificially spread out the courses. Compacting lets you request a grouping:

• at the start of the window;
• at the end of the window;
• with no start or end preference, but keeping the days as compact as possible.

How generation works

Understanding the solver's logic helps you anticipate what it will place, what it will sacrifice, and how to steer it. It pursues two goals, in this order:

1. Fit everything in — the absolute priority: position all the lessons while respecting the hard constraints.
2. Optimize quality — once everything fits, reduce gaps, smooth out the days, honor the preferences.

It starts from a clean state (locked lessons keep their place, the others are replayed) and places from the hardest lesson to the easiest. Difficulty mostly comes from the tightness of the constraints: a course whose teacher is only available one afternoon per week, or a four-hour block to fit in one piece, goes to the front. At equal difficulty, it alternates subjects and handles the rarest before the most common, to distribute each one's chances fairly.

When not everything fits: the sacrifice

If the timetable is too constrained to fit everything, the solver does not give up: it picks the smallest set of lessons to set aside so that the rest fits, then optimizes this partial timetable. The sacrificed lessons stay in the sticky notes bar, waiting to be placed. Since the ordering prioritized the hardest and the rarest, it is mostly easy and numerous lessons that yield: the 5th hour of a high-volume subject before the single hour of a rare subject.

You stay in control of these trade-offs: lock the lessons that must never move — placed first, they are not sacrificed — and relax the over-constraint (open time slots, availability) where possible, so that everything fits.

Hard constraints and soft constraints

Not all constraints are equal:

• Hard — never violated: occupancy (a teacher, a class, a group, a room or a resource cannot be used twice at the same time), the ranges marked Unavailable (in black) on a teacher, a class, a room, a subject or a group, the lack of a free room or resource on the time slot, the closed days, the locked positions and the alignments.
• Soft — everything else, which the solver can break at the cost of a penalty in order to fit everything: the ranges marked Undesired (in red — to avoid, not forbidden) and the optimization preferences (compactness, spreading, grouping by day…). A high-priority constraint weighs more than a low-priority one, but none is blocking. The solver also tries targeted relaxations (placement on the sub-slots of the grid…) when that is the price to pay to sacrifice no lesson.

Checking without optimizing

The fast generation option (without optimization) runs a lightweight pass that mostly answers one question: does everything fit? Useful to test the feasibility of a configuration before investing the time in a full optimization.

Result

• Green banner: generation succeeded. The lessons in the requested scope could be positioned and the result can be inspected.
• Red banner: no complete solution was found. The best computed timetable remains viewable and the unpositioned lessons appear in the sticky notes bar for diagnosis.

See Diagnosing a failed generation.

Consolidate or copy

After a successful generation, Omniscol offers two options:

• Consolidate into the current timetable (the placement replaces the existing one).
• Create a copy (the current timetable stays intact, the optimized result becomes a new timetable).

If you plan to regenerate later (because you are building incrementally, for example), do not consolidate: otherwise the already positioned lessons would be starting points for the new generation.

Locking a lesson before running another generation

On an already positioned lesson, use the position padlock to lock it. The next generation will not move it but will adjust the other lessons around it. Handy for anchoring "immovable" lessons (fixed external interventions, dated exams, manual adjustments…). Full details in Locking a lesson: mass locking, effects on the diagnostic (red → orange), behavior of the algorithm.

Exporting a timetable as JSON

The button exports the current timetable only in JSON format. This is not the full account export documented in Import and export.

Typical cases:

• keeping a record of a draft or a scenario before deletion;
• archiving an intermediate state before a major reorganization;
• sending this specific timetable to the Omniscol team as part of support.

As with the full JSON export of the school account, re-importing is not a standard use freely available on the school side.

What next

Final step: Publishing (activating) a timetable.