I'm creating a schedule generator for a school and I am facing two challenges:
During the construction heuristic phase I'm not getting any callbacks to the bestSolutionConsumer passed in to the SolverManager.solveAndListen which means that I'm not able to give any feedback to the user during this phase. (It's only about 10 seconds or so as of today, but still annoying.)
I suspect that this is by design (judging from this question), but please correct me if I'm wrong.
(I suspect that the idea is that the construction heuristic phase should be quick anyway, and that 99% of a long running solve will be spent in the local search phase, and thus that's the only phase that actually matters. Correct?)
This scheduling program will only be semi-automatic. I'd like the user to be able to pin lectures, move lectures around manually, and even remove lectures from the schedule by putting them in a pile on the side for later placement (where the later placement could perhaps be done by OptaPlanner).
This lead me to rethink what I consider an initialized solution. If I...
...then maybe I should make the timeslot nullable or have a sentinel timeslot value for unscheduled lectures, and simply penalize such solutions.
In this scenario, I'm imagining that a solution is immediately and trivially initialized (all lectures initially in the unscheduled state, but formally speaking the solution is still initialized) and that the construction phase is basically skipped.
Is this stupid for some reason?! It feels like I'm throwing out a large part of OptaPlanner capabilities.
Am I overlooking any downsides of this approach?
Is it even possible to skip construction phase by doing this?
Also, repeated planning is of importance to me, and the docs say:
Repeated planning (especially real-time planning) does not mix well with a nullable planning variable.
Does the same apply also to the approach of using an unscheduled sentinel value?
1/ No, this is not stupid. It is, in fact, an example of over-constrained planning.
2/ Well, now that variables are nullable, you need to write your constraints such that nulls are acceptable. And you may run into situations where the solver will find it easier to just leave some variables null, unless there is a pretty substantial penalty for that. You may have to design special constraints to work around that, or in the worst case even custom moves.
3/ Construction heuristics are not mandatory, but they can still be useful. Even if they leave some variables null, they can still give you a decent initial solution. You may also want to try a custom phase.
4/ If you worry about some of the things above, indeed introducing a dummy value instead of making a variable nullable could solve some of those worries. (And introduce others, as every constraint now has to deal with this dummy value.)
My advice is to do a quick proof of concept. See how each of the approaches behaves. Pick the one that you prefer to deal with. There are no silver bullets.