Optaplanner 无法解决一项硬约束

Question

我目前正在尝试使用 optaplanner 优化作业车间调度算法。然而，有一个限制被卡住了。我应该采取哪些可能的步骤来尝试解决这个问题。 我的配置文件如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<solver xmlns="https://www.optaplanner.org/xsd/solver"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://www.optaplanner.org/xsd/solver https://www.optaplanner.org/xsd/solver/solver.xsd">
  <!--  <environmentMode>FULL_ASSERT</environmentMode>-->
  <environmentMode>NON_REPRODUCIBLE</environmentMode>
  <moveThreadCount>AUTO</moveThreadCount>
  <solutionClass>com.greyorange.taskscheduler.domain.CandidateSolution</solutionClass>
  <entityClass>com.greyorange.taskscheduler.domain.CandidateAssignment</entityClass>

  <scoreDirectorFactory>
    <constraintProviderClass>com.greyorange.taskscheduler.costs.ObjectiveFunction</constraintProviderClass>
    <constraintStreamImplType>BAVET</constraintStreamImplType>
  </scoreDirectorFactory>

  <localSearch>
    <termination>
      <secondsSpentLimit>15</secondsSpentLimit>
    </termination>
    <acceptor>
      <entityTabuSize>7</entityTabuSize>
    </acceptor>
    <forager>
      <acceptedCountLimit>1000</acceptedCountLimit>
      <finalistPodiumType>STRATEGIC_OSCILLATION</finalistPodiumType>
    </forager>
  </localSearch>
  <localSearch>
    <termination>
      <secondsSpentLimit>10</secondsSpentLimit>
    </termination>
    <acceptor>
      <greatDelugeWaterLevelIncrementRatio>0.000001</greatDelugeWaterLevelIncrementRatio>
    </acceptor>
    <forager>
      <acceptedCountLimit>4</acceptedCountLimit>
    </forager>
  </localSearch>
  <localSearch>
    <termination>
      <secondsSpentLimit>2</secondsSpentLimit>
    </termination>
    <localSearchType>HILL_CLIMBING</localSearchType>
    <moveListFactory>
      <moveListFactoryClass>com.greyorange.taskscheduler.neighborhood.SlideTimeWindowMoveFactory
      </moveListFactoryClass>
    </moveListFactory>
  </localSearch>
</solver>

我目前很想知道我可以采取哪些步骤。我尝试更改接受的计数限制，它解决了我的问题，但我的技术主管对该解决方案并不信服。

请帮忙

Answer 1

您的解算器配置看起来经过大量微调，我想知道这是否真的有益。除非您已经对该特定数据集进行了一些广泛的基准测试，否则这种对求解器业务的参与程度可能会适得其反。

我注意到的另一件事是，您并没有真正给任何本地搜索太多时间来真正完成一些实际工作。这可能完全没问题，但随着数据集大小的增长，几秒钟已经不足以获得不错的结果。

最后，由于您使用的是 Bavet，您可能有兴趣了解 OptaPlanner 中提供的 BAVET 版本实际上存在一些严重的错误，这些错误在 fork 之后被 Timefold Solver 解决了。 （举个例子，这要求我们几乎从头开始重写 Bavet。）

这些提示对您有帮助吗？我无从得知；弄清楚为什么求解器没有找到任何特定的解决方案需要对当前的问题有深入的了解，而我没有也不可能拥有这一点。