任务计划卡住了

Question

我目前正在尝试掌握OptaPlanner，因为它似乎是解决我遇到的问题的完美解决方案。

基本上，我打算使用Project作业调度示例，但是据我所知，这是从复杂到复杂的方式。 因此，我尝试从一个非常有限的示例开始，然后从那里继续前进：

我的任务有一个持续时间和一个已定义的前任。 计划实体是每个任务开始的时间。

我有一个很难的分数，可以惩罚在其前身的启动时间和持续时间之前开始的任务。 我还有一个软评分，试图缩小差距，使整个过程尽可能短。

public HardSoftScore calculateScore(Schedule schedule) {
    int hardScore = 0;
    int softScore = 0;

    for (Task task : schedule.getTaskList()) {
        int endTime = task.getAllocation().getStartTime() + task.getDuration();
        softScore = -endTime;

        for (Task task2 : schedule.getTaskList()) {
            if(task.getId()!=task2.getId()){
                if( task2.getPredecessorId()==task.getId()) {
                    if (endTime > task2.getAllocation().getStartTime()) {
                        hardScore += task2.getAllocation().getStartTime() - endTime;
                    }
                }
            }
        }
    }

    return HardSoftScore.valueOf(hardScore, softScore);

}

这是求解器配置：

<?xml version="1.0" encoding="UTF-8"?>
<solver>
    <!--<environmentMode>FAST_ASSERT</environmentMode>-->

    <!-- Domain model configuration -->
    <solutionClass>com.foo.scheduler.domain.Schedule</solutionClass>
    <planningEntityClass>com.foo.scheduler.domain.Task</planningEntityClass>

    <!-- Score configuration -->
    <scoreDirectorFactory>
        <scoreDefinitionType>HARD_SOFT</scoreDefinitionType>
        <simpleScoreCalculatorClass>com.foo.scheduler.solver.score.SchedulingSimpleScoreCalculator</simpleScoreCalculatorClass>
    </scoreDirectorFactory>

    <!-- Optimization algorithms configuration -->
    <termination>
        <maximumSecondsSpend>100</maximumSecondsSpend>
    </termination>
    <constructionHeuristic>
        <constructionHeuristicType>FIRST_FIT</constructionHeuristicType>
    </constructionHeuristic>
    <localSearch>
        <acceptor>
            <entityTabuSize>7</entityTabuSize>
        </acceptor>
        <forager>
            <acceptedCountLimit>1000</acceptedCountLimit>
        </forager>
    </localSearch>
</solver>

问题是，只要我只有硬分就可以了。 但是，当然有差距。 一旦添加软评分，大约10步后一切都会卡住。 为什么？

[...]
2014-05-03 20:01:31,966 [main] DEBUG     Step index (10), time spend (495), score (-35hard/-66soft),     best score (-34hard/-68soft), accepted/selected move count (1000/19884) for picked step (com.foo.scheduler.domain.Task@35480096 => com.foo.scheduler.domain.Allocation@f9a4520).
2014-05-03 20:03:11,471 [main] DEBUG     Step index (11), time spend (100000), score (-35hard/-65soft),     best score (-34hard/-68soft), accepted/selected move count (0/105934687) for picked step (com.foo.scheduler.domain.Task@7050c91f => com.foo.scheduler.domain.Allocation@47c44bd4).

Answer 1

在步骤11中选择的移动计数为105934687清楚地表明没有移动被接受。 我不知道软分怎么会触发它。 只有1种解释：

• EntityTabuAcceptor不接受任何移动，因为它们都是禁忌，这意味着每个动作的计划实体都在禁忌列表中。 如果您的数据集非常小（ 14或更少的计划实体），则可以这样做。 打开TRACE日志记录，日志将确认这一点。

这些解决方法均应解决以下问题：

• 使用后期验收

   <acceptor> <lateAcceptanceSize>400</lateAcceptanceSize> </acceptor> <forager> <acceptedCountLimit>1</acceptedCountLimit> </forager> 

• 使用<entityTabuRatio>代替<entityTabuSize>

• 根据SolverFactory.getSolverConfig()的数据集大小，使用<entityTabuSize>混乱。 不建议！

为什么计划实体少于14个？

因为默认情况下，您会得到<changeMoveSelector>和<swapMoveSelector> 。 <swapMoveSelector>交换2个实体，如果赢得了步骤，则两个都禁忌。 禁忌列表的大小是步骤数，因此，如果连续有7个交换步骤获胜，则禁忌列表中可能有14个实体。