我正在使用OptaPlanner为VRPTW问题开发解算器,当需要维修大量客户时,我遇到了问题。大量的我意味着多达10,000个客户。我试过运行求解器大约48小时但是没有达到可行的解决方案。
我使用高度自定义的VRPTW域模型,引入了额外的计划实体,即所谓的" Workbreak"。工作突破就像客户,但他们可以拥有一个实际上另一个计划价值的位置 - 因为工人每天都可以回家或去酒店。工作时间具有固定的出发时间(通常是第二天早上),以及可变的到达时间(因为它取决于链中的先前实体)。一个硬约束关心不允许"到达"在某段时间后进入Workbreak。还有其他硬约束,例如:
......还有更多 - 必须应用总共19个硬约束。还有3个软约束。
所有上述约束最初都写成Drools规则,但由于许多基于累积的约束(每天最多工作,每天最多工作时间,每周加班时间),求解器的总体速度(基准)大约为400步骤/秒。
起初我认为解算器的速度太慢而无法在合理的时间内达到可行的解决方案,因此我将所有规则重写为简易计分计算器,并且它具有相当快的速度 - 大约4600步/秒。我知道这对于极少数客户来说只会表现最好,但我想知道Drools是否是导致性能不佳的原因。然后我将所有这些规则重写为增量分数计算器(并且在损坏的分数错误的痛苦中幸存下来,直到所有这些规则成功修复)。令人惊讶的是,与简易分数计算器相比,少数客户的增量分数计算有点慢,但这不是问题,因为总体速度大约是4000步/秒 - 无论我有多少实体。
最让我烦恼的是,超过一定数量的客户(问题始于1000个客户),解算器无法达到可行的解决方案。目前我使用延迟验收和步数计算算法,因为它们对这类问题表现非常好(至少对于较少数量的客户而言)。我也使用了模拟退火,但没有成功,主要是因为我找不到算法特定参数的好值。
我也实施了一些自定义动作:
现在我挠挠脑袋,想知道我应该怎么做来诊断问题的根源。我怀疑它可能是一个得分陷阱,但我修改了解算器,所以它每分钟保存最佳得分的快照。阅读完这些快照后,我意识到分数仍在下降。硬约束的数量可以发挥作用吗?我怀疑需要执行许多动作来找出提高分数的举措。事实是,对于这类问题,48小时可能不是那么多,它应该进行一周的计算?不幸的是,我没有什么可比的。
我想知道如何找出它只是一个性能问题,还是解算器(算法,自定义移动,硬/软分数)配置问题。
我真的为我糟糕的英语道歉。
答案 0 :(得分:1)
TL; DR但FWIW: