规划实体总是违反规则会导致undoMove损坏吗?

时间:2018-04-24 00:48:03

标签: drools optaplanner

当我通过Optaplanner计划任务计划并使用Chained Through Time模式时,我收到了一个undoMove损坏异常。我发现一旦规则被违反,undoMove腐败就会引发。我调查计划实体,有一个实体总是违反规则,因为它的到达时间晚于交付时间。     在规则"任务开始时间必须晚于其到达时间",它限制任务的开始时间必须晚于其到达时间,并且在规则"赶上交付日期& #34;,如果任务的开始时间晚于其交付时间,则会有惩罚分数。因此,如果某个任务的开始时间晚于交付时间,则会出现UndoMove损坏。

rule "Task start time must later than its arrival time"
when 
    Task(
        $planStartTime : planStartTime != null,     // start time not null
        $arrivalTime : arrivalTime != null ,        // arrival time not null
        $planStartTime < $arrivalTime)              // start time earlier than arrival time
then
    scoreHolder.addHardConstraintMatch(kcontext,$planStartTime - $arrivalTime);
end

    rule "Catch up delivery date"
    when
        Task(
            $delTime : deliveryTime != null,        // the delivery time not null
            $endTime : getPlanEndTime() != null,    // task's end time not null, endTime = startTime + duration, and the startTime is the shadown variable. 
            $endTime > $delTime)                    // the taks's end time is later than its delivery time.
    then
           // once this constraint match, undoMove corruption exception throws.
        scoreHolder.addSoftConstraintMatch(kcontext,  $delTime - $endTime );
    end

跟踪堆栈:

08:42:37.140 [main] TRACE     Model annotations parsed for Solution TaskAssignmentSolution:
08:42:37.145 [main] TRACE         Entity Step:
08:42:37.146 [main] TRACE             Variable nextTask (shadow)
08:42:37.146 [main] TRACE         Entity Task:
08:42:37.146 [main] TRACE             Variable previousStep (genuine)
08:42:37.146 [main] TRACE             Variable machine (shadow)
08:42:37.146 [main] TRACE             Variable planStartTime (shadow)
08:42:39.086 [main] INFO  Solving started: time spent (128), best score (-1init/0hard/0medium/0soft), environment mode (FULL_ASSERT), random (JDK with seed 0).
08:42:39.191 [main] TRACE         Corruption detected. Diagnosing...
java.lang.IllegalStateException: UndoMove corruption: the beforeMoveScore (-1init/0hard/0medium/0soft) is not the undoScore (-1init/0hard/0medium/-1soft) which is the uncorruptedScore (-1init/0hard/0medium/-1soft) of the workingSolution.
  1) Enable EnvironmentMode FULL_ASSERT (if you haven't already) to fail-faster in case there's a score corruption.
  2) Check the Move.createUndoMove(...) method of the moveClass (class org.optaplanner.core.impl.heuristic.selector.move.generic.chained.ChainedChangeMove). The move (Task [103-016] {null -> MachinePlan [1/FG-SG01/023]}) might have a corrupted undoMove (Undo(Task [103-016] {null -> MachinePlan [1/FG-SG01/023]})).
  3) Check your custom VariableListeners (if you have any) for shadow variables that are used by the score constraints with a different score weight between the beforeMoveScore (-1init/0hard/0medium/0soft) and the undoScore (-1init/0hard/0medium/-1soft).
    at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertExpectedUndoMoveScore(AbstractPhaseScope.java:191)
    at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:130)
    at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99)
    at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74)
    at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
    at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167)
    at com.esquel.APS.GEW_FN.solver.SolverManager.startSolve(SolverManager.java:359)
    at com.esquel.APS.GEW_FN.solver.SolveMain.planTasks(SolveMain.java:209)
    at com.esquel.APS.GEW_FN.solver.SolveMain.StartSolve(SolveMain.java:81)
    at com.esquel.APS.GEW_FN.main.App.main(App.java:84)

有谁知道为什么?谢谢你。

0 个答案:

没有答案