第15章 反復計画

プランニングエンティティーを動かせないようにするには、SelectionFilter エンティティーを追加します。これは、エンティティーを動かせる場合は true を、動かせない場合は false を返します。

public class MovableShiftAssignmentSelectionFilter implements SelectionFilter<ShiftAssignment> {

    public boolean accept(ScoreDirector scoreDirector, ShiftAssignment shiftAssignment) {
        ShiftDate shiftDate = shiftAssignment.getShift().getShiftDate();
        NurseRoster nurseRoster = (NurseRoster) scoreDirector.getWorkingSolution();
        return nurseRoster.getNurseRosterInfo().isInPlanningWindow(shiftDate);
    }

}

設定は以下のようになります。

@PlanningEntity(movableEntitySelectionFilter = MovableShiftAssignmentSelectionFilter.class)
public class ShiftAssignment {
    ...
}

既存の計画を置き換えると、その計画が大きく中断する可能性があります。その計画が人 (従業員、ドライバーなど​) に影響する場合、大抵は中断は望ましくありません。このような場合は、長期的な再計画が役に立ちます。計画を変更する利点が、それによって中断が発生するよりも大きくなります。

たとえば、マシンの再割当て例では、エンティティーにプランニング変数 machine と、その元の値 originalMachine があります。

@PlanningEntity(...)
public class ProcessAssignment {

    private MrProcess process;
    private Machine originalMachine;
    private Machine machine;

    public Machine getOriginalMachine() {...}

    @PlanningVariable(...)
    public Machine getMachine() {...}

    public boolean isMoved() {
        return originalMachine != null && originalMachine != machine;
    }

    ...
}

計画時、プランニング変数 machine が変更します。それを originalMachine と比較することで、計画における変更にペナルティーが追加されます。

rule "processMoved"
    when
        ProcessAssignment(moved == true)
    then
        scoreHolder.addSoftConstraintMatch(kcontext, -1000);
end

ソフトペナルティー -1000 は、変更した各変数で、ソフトスコアが 1000 ポイント以上改善する場合 (またはハードスコアが改善する場合) は、最適解だけが許可されることを示しています。

Solver が解決中に、外部イベントにより問題ファクトを変更する場合があります。たとえば、飛行機が遅れたために、滑走路の使用を遅らせる必要がある場合です。(別のスレッドから、もしくは同じスレッドでも) Solver を使用して解決中に問題ファクトのインスタンスを変更しないでください。変更すると壊れます。代わりに、ProblemFactChange を Solver に追加して、Solver スレッドをできるだけ早く実行します。

public interface Solver {

    ...

    boolean addProblemFactChange(ProblemFactChange problemFactChange);

    boolean isEveryProblemFactChangeProcessed();

    ...

}

public interface ProblemFactChange {

    void doChange(ScoreDirector scoreDirector);

}

以下は例になります。

    public void deleteComputer(final CloudComputer computer) {
        solver.addProblemFactChange(new ProblemFactChange() {
            public void doChange(ScoreDirector scoreDirector) {
                CloudBalance cloudBalance = (CloudBalance) scoreDirector.getWorkingSolution();
                // First remove the problem fact from all planning entities that use it
                for (CloudProcess process : cloudBalance.getProcessList()) {
                    if (ObjectUtils.equals(process.getComputer(), computer)) {
                        scoreDirector.beforeVariableChanged(process, "computer");
                        process.setComputer(null);
                        scoreDirector.afterVariableChanged(process, "computer");
                    }
                }
                // A SolutionCloner does not clone problem fact lists (such as computerList)
                // Shallow clone the computerList so only workingSolution is affected, not bestSolution or guiSolution
                cloudBalance.setComputerList(new ArrayList<CloudComputer>(cloudBalance.getComputerList()));
                // Next remove it the problem fact itself
                for (Iterator<CloudComputer> it = cloudBalance.getComputerList().iterator(); it.hasNext(); ) {
                    CloudComputer workingComputer = it.next();
                    if (ObjectUtils.equals(workingComputer, computer)) {
                        scoreDirector.beforeProblemFactRemoved(workingComputer);
                        it.remove(); // remove from list
                        scoreDirector.afterProblemFactRemoved(workingComputer);
                        break;
                    }
                }
            }
        });
    }

基本的に、Solver が停止したら、ProblemFactChange を実行して再起動します。これは、その初期解は 1 つ前の実行で調整した最適解になるため、ウォームスタート です。これは、構築ヒューリスティックが再度実行したことを示しますが、プランニング変数がほとんどもしくは全く初期化されないため (null 許容型のプランニング変数 がある場合を除きます)、それは、コールドスタートよりもはるかに速くなります。

(Solver およびフェーズ設定の両方に) 設定した各 終了 はリセットされ、terminateEarly() への以前の呼び出しは未完成ではありません。ただし、通常、(デーモンモード以外で) 終了 を設定せず、結果が必要な場合のみ Solver.terminateEarly() を呼び出します。代わりに、以下に示すように、終了 を設定し、BestSolutionChangedEvent と組み合わせてデーモンモードを使用します。

リアルタイム計画では、作業がなくなったときに Solverスレッドが待機し、問題ファクトが新たに変更すると問題解決がすぐに再開するのが便利なことが多いです。デーモンモードに Solver を追加すると以下の効果があります。

デーモンモードを設定するには、以下のように設定します。

<solver>
  <daemon>true</daemon>
  ...
</solver>

BestSolutionChangedEvent をサブスクライブして、Solver スレッドが見つけた新しい最適解を処理します。BestSolutionChangedEvent は、すべての ProblemFactChange がすでに処理されていることを保証できず、その解が初期化され実行できる状態でもありません。そのような無効な解を持つ BestSolutionChangedEvents を無視するには、以下を行います。

    public void bestSolutionChanged(BestSolutionChangedEvent<CloudBalance> event) {
        // Ignore invalid solutions
        if (event.isEveryProblemFactChangeProcessed()
                && event.isNewBestSolutionInitialized()
                && event.getNewBestSolution().getScore().isFeasible()) {
            ...
        }
    }