Is it possible to identify the presence of conditions that prevent results? We can happily say that we have an engine capable of finding efficiently the most challenging timetables. However, as you know, in order to optimise the timetables, it is essential to find complete results in advance. Unfortunately, when working with the planner, you will have experienced that impossible conditions are introduced. Perhaps the most controversial issue in using the software is how to determine, before using the engine, whether there are impossible conditions. What conditions prevent full timetables?
The engine is the component that finally has to find the solution, so it is not always possible to know in advance whether there are conditions that cannot be fulfilled. Indeed, this is strictly true; there are impossible conditions that are very difficult to analyse. However, it is possible to identify many of the impossible conditions; most of them are introduced accidentally, preventing the full results.
The GHC engine fits results very quickly. This is a fact. If the engine cannot find results quickly and fails to fit any class unit in repeated attempts, most of the time it is because there are some conditions that prevent it and they must be debugged. Otherwise, the engine takes a little more time and effort to find a complete solution if they are more unusual. Should we wait? And if we suspect that there is some impossible condition, what is it?
We have two processes that can help us to check if there are conditions that are impossible to fulfil before using the engine: the validation of the planner’s configuration and the analysis of minimum sets that are impossible to fit.
The validation process looks at some of the most common causes that may prevent full results. For example, that a group of students have been assigned more class units than the ones that fit into their time frame or that different class units have been set up at the same time with the same teacher.
On the other hand, the analyser tries to solve separately the timetables of each teacher, of each group of students, etc. Thus, if it cannot solve any of these subsets, it will reduce it to a minimum of class units that are impossible to fit in. If the analyser finds a minimum set of class units that do not fit, it will be easier to see what is happening, that is, what conditions overlap with each other within this reduced number of class units.
Even though it is not the most common, as we have already said, there may be timetables for which the engine does not find a solution that apparently does not involve conflicts. Indeed, there are timetables without validation errors and for which the analyser does not find conflicts, which nevertheless contain conditions that prevent solutions. In these cases we have a third tool that can help us considerably: the debugger. The debugger allows to launch the engine and also the analyser, without any of the strict conditions initially configured. The debugger is very useful to launch tests by relaxing the strict conditions and thus know which ones prevent the solutions.
There are other debugging strategies, such as trying to assign directly from the editor the class units that have not been able to fit in to see which messages appear or to check in the incomplete result where there are gaps in the group timetable, just in case the problem is a meeting or the presence of an excess of positions forbidden to teachers, coinciding at the same time.
We do not want to forget that the task of making academic timetables is complex enough so that, in addition to having the best tools, the expertise of those who use them is necessary. Be sure to ask us for all the help you need. In any case, the merit of making the best timetables will always be yours.