【问题标题】:My optaplanner solution doesn't improve shortly after the solve started. How do I debug this?我的 optaplanner 解决方案在解决方案开始后不久就没有改善。我该如何调试?
【发布时间】:2020-12-29 19:27:20
【问题描述】:

在我的解决方案开始解决后不久,我得到了一个初始分数的更新(从 -54init/0hard/0medium/-33275soft 到 0hard/0medium/-34035soft),之后没有其他任何变化(示例UI 仍然显示“正在解决...”和右上角的橙色波浪)

所以我寻找更多的调试输出(由于未知原因没有成功),试图确定是否没有执行进一步的步骤,或者这些步骤是否没有产生更好的结果(到目前为止我认为,分数应该有所提高)。更令人费解的是,如果我正确地深度克隆了一个问题事实的一类,不确定性——也许我所看到的是没有正确完成它的迹象?

所以现在我比较纠结于自己的选择,主要是缺乏使用 Optaplanner 的经验(我肯定想更好地了解它)。我知道这是一个相当基本的 Optaplanner 问题,但是对 Optaplanner 有更多工作经验的人可以给我一个关于我进一步调试可能性的线索吗?如果我能有更多类似于示例中发生的调试输出(例如,我的 logback.xml 应该放在哪里),我已经很高兴了?

【问题讨论】:

  • 如果您打开 enviromnentMode FULL_ASSERT(这会减慢一切)会发生什么?失败了吗?
  • 它不会失败:行为保持原样,没有该环境模式。那就是:求解器总是不断地通过其他选择,只有分数没有提高。我可以从中扣除什么?现在,我不得不说(“承认”?)这(仍然)是一个简单的问题。可能没有更好的解决方案。注释掉一个约束会导致相同的行为,只有约束结果卡在另一个值上(并且像现在一样保持该值)
  • 我发现分数没有损坏。不幸的是(?!),这不是因为我没有破坏它:这是因为影子变量没有被更新(并且保持在 0 的值,因此在相关约束的 penalize()- 计算中没有被正确计算)。仍在寻找原因:/
  • 您在本地搜索阶段使用哪种算法?我在模拟退火方面遇到了类似的问题,但在禁忌搜索方面却没有。同样在大约 15 分钟后,通过模拟退火,溶液又开始发生变化。那么你运行算法多长时间了?
  • 此处使用了 TABU_SEARCH。然而,我的发现被证明是错误的(如果你通读了这里的所有内容):我希望看到这些动作,但我没有看到任何动作。但是这个发现是错误的,因为它没有正确设置日志记录。所以我确实选择了动作,只是没有在日志输出中看到它们。 OTOH,根据您的情况,一种本地搜索选择的性能比另一种要好得多,这并非不可能。也许您应该看看用不同的本地搜索阶段对您的解决方案进行基准测试。

标签: debugging logging output optaplanner


【解决方案1】:

关于调试信息:我发现缺少与示例类似的调试日志输出的 maven 配方如下:

    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.2.3</version>
        <scope>runtime</scope>
    </dependency>

所以在添加了该配方后,我得到了正确的调试日志,就像示例中一样(从示例中复制的 logback.xml 文件已正确放置在资源文件夹中)

调试输出进一步表明求解器正在正确地逐步完成各种可能性。所以我得开始调试约束了……

【讨论】:

  • 是的,打开 TRACEDEBUG 日志记录以查看 optaplanner 所做的选择。
  • 是的,我一直在寻找这个有用的信息(正如你所注意到的,在一些最初的问题之后现在已经成功了)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2023-01-03
  • 1970-01-01
  • 2021-05-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-08-17
相关资源
最近更新 更多