CODEWITHSUNDEEP
optaplanner
Toshiya Kobayashi
Toshiya Kobayashi

Reputation: 705

Repeated planning without ProblemFactChange

I'm a bit wondering about how to implement repeated planning.

The document classifies into 3 situations. 'Backup planning', 'Continuous planning' and 'Real-time planning'.

http://docs.jboss.org/optaplanner/release/latest/optaplanner-docs/html_single/index.html#repeatedPlanning

If I'm not missing something, all optaplanner-examples (e.g. Nurse roastering) implement repeated planning using 'ProblemFactChange' which is described under 'Real-time planning'. That's fine. Solver.addProblemFactChange() will take care of the ProblemFactChange gracefully.

But it sounds like an approach for 'Real-time planning'. How should we implement 'Backup planning' / 'Continuous planning' in a simpler way?

To implement what is written in "15.2. Backup planning",

Then, when things go wrong (one of the employees calls in sick), change the planning facts on the original solution (delete the sick employee leave his/her shifts unassigned) and just restart the planning, starting from that solution, which has a different score now. The construction heuristics will fill in the newly created gaps (probably with the spare employee) and the metaheuristics will even improve it further.

I just:

https://github.com/tkobayas/optaplanner/blob/repeatedPlanning/optaplanner-examples/src/main/java/org/optaplanner/examples/cloudbalancing/app/CloudBalancingHelloWorldRepeat.java#L52-L73

Is this a valid approach?

Upvotes: 3

Views: 523

Answers (1)

Geoffrey De Smet
Geoffrey De Smet

Reputation: 27312

About the pseudo code above: That approach will work too, and it's a manual form of real-time planning. The advantage of ProblemFactChange is that it's submitted from another thread (asynchronously). Once such a PFC comes in, the solver threads notices that the PFC queue isn't empty, stops solving, processes the PFC queue and then starts solving again. Pretty much the same thing as what you described above. By turning on logging, I've seen in CloudBalancing that the time between before the async thread submitted the PFC and until after the solver thread processed it and found an initialized, feasible solution again, is 12ms or so (depends on the PFC of course, in my case it was deleting a Computer with a 10 Processes or so assigned).

About repeated planning in general: Repeated planning is just a classification name. The 3 forms of repeated planning (backup planning, continuous planning, real-time planning) are complementary to each other (= orthogonal to each other), they are not alternatives to each other.

The example nurse rostering (employee rostering) implements:

  • real-time planning: delete a nurse with the red X buttons
  • continuous planning: press the button "advance 1 day into the future", as a result the planning window shifts to the right.

All 3 forms serve different needs and can be applied on the same use case together.

Upvotes: 2

Related Questions