[rules-users] [planner] The presumed score is corrupted

[Geoffrey De Smet]

In your doMove you're doing:

crew.addActivity(activity);
remainingActivities.remove(activity);

If crew and/or remainingActivities are used by your score rules, the 
working memory should be notified of their changes.
That's causing the corruption


Extra advice:
I think you're making your moves too complex and your domain model too 
complex.
If you upgrade to 5.3, it will be hard to identify the planning 
entities. There will be many (and I doubt you need more than 1).
Read
   
http://docs.jboss.org/drools/release/5.3.0.CR1/drools-planner-docs/html_single/index.html#d0e1411
and specificly this note in that chapter:
>
> /Do not create unnecessary planning entity classes./This leads to 
> difficult |Move| implementations and slower score calculation.
>
> For example, do not create a planning entity class to hold the total 
> free time of a teacher, which needs to be kept up to date as the 
> |Lecture| planning entities change. Instead, calculate the free time 
> in the score constraints and put the result per teacher into a 
> logically inserted score object.
>
> If historic data needs to be considered too, then create problem fact 
> to hold the historic data up to, but /not including/, the planning 
> window (so it doesn't change when a planning entity changes) and let 
> the score constraints take it into account.
>



Op 14-10-11 15:48, Guilherme Kunigami schreef:
>
>
> 2011/10/14 Geoffrey De Smet <ge0ffrey.spam at gmail.com 
> <mailto:ge0ffrey.spam at gmail.com>>
>
>     Probably you forgot to notify the workingMemory.update in the
>     doMove method:
>
>         public void doMove(WorkingMemory workingMemory) {
>             FactHandle factHandle = workingMemory.getFactHandle(activity);
>             activity.setAssignee(...);
>             workingMemory.update(factHandle, activity);
>         }
>
>     Op 14-10-11 09:21, Geoffrey De Smet schreef:
>>     A corrupted score normally indicates a problem with the Move
>>     implementation (or sometimes the score drl).
>>
>>     Basically this happened: for a number of moves, it did the move,
>>     calculated the score and undo the move.
>>     One of those move was associated with a score -10hard/0soft, that
>>     was the best one.
>>     Now, it does that move (which is now called the "step") and when
>>     it calculates the score it's a different score 0hard/0soft.
>>
>>     Try TRACE environment and see if it crashes sooner. Copy paste
>>     your Move implementation here.
>
>
> Using the TRACE environment gave the same results of DEBUG.
>
> Here's my move implementation, as well as the snipet of drools rule 
> file that calculates the score based on remaining activities:
> http://pastebin.mozilla.org/1355014
>
>>     In Planner 5.4 there will be 2 out-of-the-box Move
>>     implementations to use, so writing Move's become optional.
>
> Cool!
>
> By the way, I'm using Drools 5.2.0 final.
>
> Thanks,
>
>>
>>     Op 13-10-11 16 <tel:13-10-11%2016>:37, Guilherme Kunigami schreef:
>>>     Hi,
>>>
>>>     I've implemented a very simple application using drools planner
>>>     consisting of a bunch of activities. My rule file is very simple
>>>     too and just counts the number of activities not assigned. When
>>>     I run Solver.solve(), I get the following error message:
>>>
>>>     Exception in thread "AWT-EventQueue-0"
>>>     java.lang.IllegalStateException: The presumedScore
>>>     (-10hard/0soft) is corrupted because it is not the realScore
>>>      (0hard/0soft).
>>>
>>>     Presumed workingMemory:
>>>       Score rule (remainingActivitiesCount) has count (1) and weight
>>>     total (11).
>>>     Real workingMemory:
>>>       Score rule (remainingActivitiesCount) has count (1) and weight
>>>     total (0).
>>>
>>>     I've tracked down this message and found this piece of code
>>>     @DefaultLocalSearchSolver.solveImplementation():
>>>
>>>     // there is no need to recalculate the score, but we still need
>>>     to set it
>>>     localSearchSolverScope.getWorkingSolution().setScore(localSearchStepScope.getScore());
>>>     if (assertStepScoreIsUncorrupted) {
>>>        
>>>     localSearchSolverScope.assertWorkingScore(localSearchStepScope.getScore());
>>>     }
>>>
>>>     It seems that the working score is never updated along the
>>>     algorithm, but the score in the working memory changes. Thus,
>>>     when we use the DEBUG environment, assertStepScoreIsUncorrupted
>>>     is turned on and the assertion fails.
>>>
>>>     Should the score be updated or am I using the library incorrectly?
>>>
>>>     Thanks,
>>>
>>>
>>>     _______________________________________________
>>>     rules-users mailing list
>>>     rules-users at lists.jboss.org  <mailto:rules-users at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>     -- 
>>     With kind regards,
>>     Geoffrey De Smet
>>
>>
>>     _______________________________________________
>>     rules-users mailing list
>>     rules-users at lists.jboss.org  <mailto:rules-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>     -- 
>     With kind regards,
>     Geoffrey De Smet
>
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111014/91032fdb/attachment.html