optaplanner - 停止并重新启动求解过程有助于找到更好的解决方案

Question

我和我的同事成功实现了基于 OptaPlanner 的考试安排程序作为我们的 bachelor thesis 。 然而，我们注意到求解器在本地搜索阶段卡住了几个小时，停止/重新启动求解过程有助于找到新的解决方案。 我认为这种行为是由于我们处理新的最佳解决方案的方式造成的。 事实上，我们只保存更好的解决方案，如下图所示。 在本地搜索阶段，我们使用“计步爬山”，其中 stepCountingHillClimbingSize = 400 和 stepCountingHillClimbingSize = 1。

虚线箭头表示新解决方案与哪个解决方案进行比较。 当求解过程在步骤 7 停止并重新启动时，将加载步骤 5 的解。而如果求解过程不被中断，则步骤 7 中的解将成为引用解。 我认为这个过程增加了一些随机性。 如何使用 OptaPlanner 添加此行为？ 这是否与中描述的问题相同 OptaPlanner immediately produces better solution after terminating and restarting the solver ？

solverConfig.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<solver xmlns="https://www.optaplanner.org/xsd/solver">
    <!--TODO: enable for real production use - gives a small performance boost. See: https://docs.optaplanner.org/latest/optaplanner-docs/html_single/index.html#environmentModeProduction-->
    <!--<environmentMode>NON_REPRODUCIBLE</environmentMode>-->
    <moveThreadCount>AUTO</moveThreadCount>
    <solutionClass>ch.ost.examscheduler.solvers.opta.domain.ExamTimetable</solutionClass>
    <entityClass>ch.ost.examscheduler.solvers.opta.domain.Exam</entityClass>
    <scoreDirectorFactory>
        <constraintProviderClass>ch.ost.examscheduler.solvers.opta.solver.constraints.TimeTableConstraintProvider
        </constraintProviderClass>
        <constraintStreamImplType>DROOLS</constraintStreamImplType>
        <initializingScoreTrend>ONLY_DOWN/ONLY_DOWN</initializingScoreTrend>
    </scoreDirectorFactory>
    <constructionHeuristic>
        <constructionHeuristicType>FIRST_FIT_DECREASING</constructionHeuristicType>
    </constructionHeuristic>
    <localSearch>
        <unionMoveSelector>
            <cacheType>PHASE</cacheType>
            <changeMoveSelector>
                <filterClass>ch.ost.examscheduler.solvers.opta.solver.filters.AllRoomsUnassignedChangeMoveFilter
                </filterClass>
            </changeMoveSelector>
        </unionMoveSelector>
        <acceptor>
            <stepCountingHillClimbingSize>400</stepCountingHillClimbingSize>
        </acceptor>
        <forager>
            <acceptedCountLimit>1</acceptedCountLimit>
        </forager>
    </localSearch>
</solver>

Answer 1

是的，我们也在其他一些用例中看到了这一点。默认本地搜索类型延迟接受可以从某些用例中的重新启动中受益。这种重新启动称为重新加热。我们有一个实现重新加热的问题。

它看起来很糟糕 - 但通常再加热的增益是一个舍入误差 - 而且结果仍然比你在其他地方得到的结果要好得多。但尤其是在小型数据集上，其他求解器可能会做得更好，这是一种痛苦。

同时，解决方法(手动重新加热)是配置 localSearch 阶段两次，并在第一个 localSearch 阶段设置未改进的 30 秒左右的时间终止。但如果卡住两次怎么办？