Load
The real amount of work to place: which teacher teaches which lesson to which class and for how many weekly hours.
Help Center · Timetable Generation
Do not just tell the solver to place lessons; build the right solution space.
Timetable quality is largely determined before the solver starts. When lesson loads, real capacity, mandatory rules and quality preferences are separated correctly, Dersiva can produce more consistent trials and explain unplaced lessons more clearly.
Core model
Separate three things: load, mandatory rules and preferences.
Hard constraint
A rule the solver must never violate, such as a truly unavailable day or a strict daily maximum.
Soft objective
A quality target to improve where possible, such as reducing gaps or balancing teaching days.
01
Pre-check the data model
Before generation, review teacher, class, lesson and assignment totals. Planned weekly teacher load should match assignments, while each class must have enough usable weekly periods for its total lesson demand.
- ✓Any missing teacher/lesson assignment?
- ✓Are weekly-hour totals correct?
- ✓Does class weekly slot capacity cover the required load?
02
Check lesson assignments and remaining load
Every assignment should carry the correct teacher, class/section, lesson and weekly-hour value. Planned and remaining load make it easier to see which teacher or lesson group still requires capacity during placement.
- ✓Any lesson assigned twice by mistake?
- ✓Does total teacher load match the real workload?
- ✓Are grouped/shared lessons modeled correctly?
03
Separate hard constraints from quality objectives
Only rules that truly cannot be violated should be hard constraints. Turning every preference into a hard rule unnecessarily shrinks the solution space. Lock mandatory conditions first and leave quality preferences as objectives where possible.
- ✓Is “I prefer not to” being treated as “impossible”?
- ✓Does one teacher have conflicting mandatory rules?
- ✓Was a quality preference accidentally made hard?
04
Define unavailable days and working availability
Enter days a teacher truly cannot work as unavailable. If only certain periods are available, model the real time availability. Make sure enough total open slots remain to carry the teacher’s weekly load.
- ✓Are enough slots left after unavailable days?
- ✓Any protected day or regulation-driven condition?
- ✓Do teacher and class availability actually overlap?
05
Set realistic teacher-specific daily maxima
Dersiva can use different daily maximum lesson limits for different teachers. When a limit is strict, the solver must distribute the weekly load across the remaining days. A very low daily maximum can make a timetable difficult even when enough days appear to be open.
- ✓Weekly load ÷ open days compatible with daily maximum?
- ✓Do different teachers need different limits?
- ✓Does the daily maximum conflict with unavailable days?
06
Model blocks and weekly distribution patterns
Block requirements and patterns such as 2+2+1 define the operational structure of a lesson. They must be evaluated together with the real daily capacity of the class and teacher availability.
- ✓Does the block length fit the day?
- ✓Are enough different days available for the pattern?
- ✓Do the teacher’s other lessons consume the required block space?
07
Think of capacity as teacher + class + day intersection
Having enough hours somewhere in the week is not enough. A lesson needs the teacher, class and lesson pattern to be available at the same time. Day-specific class capacity and teacher daily capacity together create the real solution space.
- ✓Is the class’s actual number of periods for that day correct?
- ✓Do teacher and class open slots really overlap?
- ✓Does one day have a different time structure?
08
Choose the generation mode for the current goal
Fast mode is useful for short feasibility and data trials; Balanced mode targets a general speed/quality compromise; Quality mode can spend more optimization time searching for a better result. Do not start with the longest solve when you are still validating data.
- ✓Is this a first trial or final-quality search?
- ✓Is the problem feasibility or quality?
- ✓Will more time actually help optimization?
09
Generate and keep the result as a trial
After pre-checks, the solver builds the model, searches the feasible space under mandatory rules and optimizes quality objectives. Treat the result as a trial first; the first successful solve should not automatically become the applied timetable.
- ✓Did all lessons place?
- ✓Was solve status/time as expected?
- ✓Was the trial stored in timetable history?
10
Read unplaced lessons as bottlenecks, not symptoms
If a few hours remain unplaced, identify which teacher, class, day and constraints meet at the bottleneck. Instead of randomly removing rules, check capacity, daily maxima, block patterns and conflicting assignments in a controlled order.
- ✓Do unplaced hours cluster around one teacher?
- ✓Does the same class/day repeat?
- ✓Was real capacity calculated before relaxing a hard rule?
11
Compare trials and select only one applied timetable
You can produce different trials with Fast, Balanced or Quality modes. Even with the same completion rate, gaps, dense days, short days and distribution quality may differ. Compare them in history and select only the reviewed timetable as applied.
- ✓Were trials produced from the same data/constraint state?
- ✓Does the quality improvement help the school as a whole?
- ✓Was the correct trial selected as applied?
12
Use safe diagnostics for native solver crashes
If the application closes at the start of solving, do not treat it as an infeasible timetable by default. Retry with Safe Diagnostic Mode — 1 Worker; verify OR-Tools native components, Microsoft Visual C++ runtime and logs. If 1 Worker succeeds while normal solving closes, investigate the runtime/native/multi-worker layer separately.
- ✓Was 1 Worker safe diagnostic mode tested?
- ✓Are VC++ and native prerequisites present?
- ✓Were log.txt / Windows event logs reviewed?
Choosing a solve mode
The same data can be solved with different objectives.
Fast
Short trials for data and feasibility checks.
Balanced
General compromise between speed and quality.
Quality
More optimization time to search for a stronger quality result.
Unplaced lesson analysis
Look for the bottleneck in four layers.
Assignment
Are weekly load and teacher totals correct?
Availability
Are there enough teacher/class overlapping open slots?
Capacity
Do daily maximum, class slots and block length fit together?
Constraints
Are multiple hard rules eliminating the same solution space?
Technical diagnostics
Separate feasibility problems from runtime problems.
A solver reporting no feasible placement and an application closing inside the native solver call are different failure classes. Safe Diagnostic Mode, logs and runtime prerequisites help distinguish them.
Next guide
v3.19 — Timetable Quality Guide
The next guide will explain why two complete timetables can have very different quality, using gaps, density, short days, lesson weight, student load and school-wide fairness.
Help Center