[rules-users] Best model for planning? technicians, airplanes and shifts

[Geoffrey De Smet]

Without going through the code with a fine comb (which we don't 
generally do on this level of free support), it's a bit hard to tell.

Some suggestions to take a look at:

1) Verify that the exception message now is still _exactly_ the same. 
You could be looking at another score corruption exception.
If it differs the slightest bit, can you paste it again?

2) Switch from UnweightedConstraintOccurrence to 
IntConstraintOccurrence, because none of the examples use the former and 
most examples use the latter. If that fixes it, let me know so I can 
verify and fix the bug, although on first sight I don't see a bug in the 
code of UnweightedConstraintOccurrence.


Op 03-09-12 09:00, Michiel Vermandel schreef:
> Indeed, it did not help.
>
> Any other ideas?
> Please...
>
> Thanks,
>
> Michiel
> *From:* Geoffrey De Smet <ge0ffrey.spam at gmail.com>
> *To:* Rules Users List <rules-users at lists.jboss.org>
> *Sent:* Monday, September 3, 2012 8:37 AM
> *Subject:* Re: [rules-users] Best model for planning? technicians,
> airplanes and shifts
>
> Op 02-09-12 16:11, Michiel Vermandel schreef:
>  > Hi,
>  >
>  > I have set the environment option to DEBUG and now the solver reports
>  > this exception:
>  > Exception in thread "main" java.lang.IllegalStateException: Score
>  > corruption: the workingScore (-2) is not the uncorruptedScore (0):
>  >    The workingMemory has 2 ConstraintOccurrence(s) in excess:
>  > tasksInSameJobMustBeInSamePeriod/NEGATIVE_HARD:[Maintenance of Boeing
>  > 737 - PJ23.I#1]
>  >      tasksInSameJobMustBeInSamePeriod/NEGATIVE_HARD:[Maintenance of
>  > Boeing 737 - PJ23.I#2]
>  >    Check the score rules who created those ConstraintOccurrences. Verify
>  > that each ConstraintOccurrence's causes and weight is correct.
>  >      at
>  >
> org.drools.planner.core.score.director.AbstractScoreDirector.assertWorkingScore(AbstractScoreDirector.java:101)
>  >      at
>  >
> org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.doMove(DefaultGreedyDecider.java:110)
>  >      at
>  >
> org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:78)
>  >      at
>  >
> org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:63)
>  >      at
>  >
> org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:183)
>  >      at
>  >
> org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:151)
>  >      at
>  >
> be.axi.planner.domain.MaintenancePlanning.main(MaintenancePlanning.java:27)
>  >
>  > It is caused by this rule:
>  >
>  > rule "tasksInSameJobMustBeInSamePeriod"
>  >      when
>  >       $t1 : MaintenanceTask($id : id, $periodId : periodId, $jobId :
>  > jobId )
>  >          $t2 : MaintenanceTask(id != $id,  periodId != $periodId, jobId
>  > == $jobId)
>  >      then
>  >          insertLogical(new
>  > UnweightedConstraintOccurrence("tasksInSameJobMustBeInSamePeriod", $t1));
> I expect you would add $t2 to the causes too:
>            insertLogical(new
>    UnweightedConstraintOccurrence("tasksInSameJobMustBeInSamePeriod",
> $t1, $t2));
>
> It's unlikely that that's causing the score corruption though.