【问题标题】:Repeated planning without ProblemFactChange没有 ProblemFactChange 的重复计划
【发布时间】:2015-04-02 09:54:44
【问题描述】:

我有点想知道如何实施重复计划。

文档分为3种情况。 “备份计划”、“持续计划”和“实时计划”。

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

如果我没有遗漏任何内容,所有 optaplanner 示例(例如护士烘焙)都使用“实时计划”下描述的“ProblemFactChange”实施重复计划。没关系。 Solver.addProblemFactChange() 将优雅地处理 ProblemFactChange。

但这听起来像是一种“实时规划”的方法。我们应该如何以更简单的方式实施“备份计划”/“持续计划”?

为了实现“15.2.备份计划”中的内容,

然后,当出现问题时(其中一名员工请病假), 更改原始解决方案的计划事实(删除病人 员工离开他/她的班次未分配),然后重新启动 计划,从具有不同分数的解决方案开始 现在。构建启发式将填补新创建的空白 (可能与备用员工)和元启发式甚至会 进一步改进。

我只是:

  • 终止求解器
  • 从求解器获取最佳解决方案
  • 直接在 BestSolution 中编辑问题事实/计划实体(不关心 ScoreDirector)
  • 使用编辑后的 ​​BestSolution 再次运行求解器

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

这是一种有效的方法吗?

【问题讨论】:

    标签: optaplanner


    【解决方案1】:

    关于上面的伪代码:这种方法也可以,它是一种手动形式的实时规划。 ProblemFactChange 的优点是它是从另一个线程(异步)提交的。一旦这样的 PFC 进入,求解器线程会注意到 PFC 队列不为空,停止求解,处理 PFC 队列,然后再次开始求解。和你上面描述的差不多。通过打开日志记录,我在 CloudBalancing 中看到,从异步线程提交 PFC 之前到求解器线程处理它并再次找到初始化的可行解决方案之间的时间是 12ms 左右(取决于 PFC当然,就我而言,它正在删除分配了 10 个左右进程的计算机。

    关于一般的重复计划:重复计划只是一个分类名称。 重复计划的三种形式(备份计划、连续计划、实时计划)是相辅相成的(=相互正交),它们不是相互替代的。

    示例nurse rostering(员工排班)实现:

    • 实时规划:使用红色 X 按钮删除护士
    • 持续计划:按下“提前 1 天进入未来”按钮,计划窗口将向右移动。

    所有 3 种形式都满足不同的需求,可以一起应用于同一个用例。

    【讨论】:

    • PS:手动(并且没有 PFC)的优点确实是您不必担心调用 before/after 方法,因此编写起来更容易:)跨度>
    • 谢谢你,杰弗里。这是一个完美的答案!
    猜你喜欢
    • 2015-07-01
    • 1970-01-01
    • 1970-01-01
    • 2020-04-09
    • 2011-07-18
    • 1970-01-01
    • 1970-01-01
    • 2019-06-02
    • 2014-11-18
    相关资源
    最近更新 更多