没有 ProblemFactChange 的重复计划
Repeated planning without ProblemFactChange
我有点想知道如何实施重复计划。
文件分为3种情况。 'Backup planning'、'Continuous planning' 和 'Real-time planning'。
如果我没有遗漏任何东西，所有 optaplanner-examples（例如 Nurse roastering）都使用 'ProblemFactChange' 实施重复规划，这在 'Real-time planning' 中有描述。没关系。 Solver.addProblemFactChange() 将优雅地处理 ProblemFactChange。
但这听起来像是 'Real-time planning' 的一种方法。我们应该如何以更简单的方式实现'Backup planning' / 'Continuous planning'？
执行“15.2.备份计划”中的内容，
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.
我只是：
- 终止求解器
- 从求解器中获取最佳解决方案
- 直接在 BestSolution 中编辑问题事实/规划实体（不关心 ScoreDirector）
- 运行 求解器再次使用编辑后的 BestSolution
这是一种有效的方法吗？
关于上面的伪代码：这种方法也行得通，它是实时计划的手动形式。 ProblemFactChange 的优点是它是从另一个线程（异步）提交的。一旦出现这样的 PFC，求解器线程就会注意到 PFC 队列不为空，停止求解，处理 PFC 队列，然后再次开始求解。和你上面描述的差不多。通过打开日志记录，我在 CloudBalancing 中看到，从异步线程提交 PFC 到求解器线程处理它并再次找到初始化的可行解决方案之间的时间是 12ms 左右（取决于PFC 当然，在我的例子中，它正在删除一台分配了 10 个左右进程的计算机）。
关于一般的重复计划：重复计划只是一个分类名称。 重复计划的3种形式（备份计划、连续计划、实时计划）是相互补充的（=相互正交），它们不是相互替代的。
示例nurse rostering（员工排班）实现：
- 实时规划：使用红色 X 按钮删除护士
- 连续规划：按下按钮 "advance 1 day into the future"，结果规划 window 向右移动。
所有 3 种形式都满足不同的需求，可以一起应用于同一用例。
我有点想知道如何实施重复计划。
文件分为3种情况。 'Backup planning'、'Continuous planning' 和 'Real-time planning'。
如果我没有遗漏任何东西，所有 optaplanner-examples（例如 Nurse roastering）都使用 'ProblemFactChange' 实施重复规划，这在 'Real-time planning' 中有描述。没关系。 Solver.addProblemFactChange() 将优雅地处理 ProblemFactChange。
但这听起来像是 'Real-time planning' 的一种方法。我们应该如何以更简单的方式实现'Backup planning' / 'Continuous planning'？
执行“15.2.备份计划”中的内容，
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.
我只是：
- 终止求解器
- 从求解器中获取最佳解决方案
- 直接在 BestSolution 中编辑问题事实/规划实体（不关心 ScoreDirector）
- 运行 求解器再次使用编辑后的 BestSolution
这是一种有效的方法吗？
关于上面的伪代码：这种方法也行得通，它是实时计划的手动形式。 ProblemFactChange 的优点是它是从另一个线程（异步）提交的。一旦出现这样的 PFC，求解器线程就会注意到 PFC 队列不为空，停止求解，处理 PFC 队列，然后再次开始求解。和你上面描述的差不多。通过打开日志记录，我在 CloudBalancing 中看到，从异步线程提交 PFC 到求解器线程处理它并再次找到初始化的可行解决方案之间的时间是 12ms 左右（取决于PFC 当然，在我的例子中，它正在删除一台分配了 10 个左右进程的计算机）。
关于一般的重复计划：重复计划只是一个分类名称。 重复计划的3种形式（备份计划、连续计划、实时计划）是相互补充的（=相互正交），它们不是相互替代的。
示例nurse rostering（员工排班）实现：
- 实时规划：使用红色 X 按钮删除护士
- 连续规划：按下按钮 "advance 1 day into the future"，结果规划 window 向右移动。
所有 3 种形式都满足不同的需求，可以一起应用于同一用例。