[rules-users] Planner 5.3.0 Final - Issue with Local Search / Move

[duggal]

>> 1. While looking at the solution created at the end of the local search 
>> phase AND comparing to the moves output in the log file. I see that there 
>> are several instances where the log file shows a move BUT the output 
>> solution has the entity still on the previous planning variable. 
>> This is happening only towards the end of the phase (about last 8 steps)
>> of 
>> the time terminated phase. 
>This sounds like a genuine bug. 
>Could you copy paste some logging output to show the issue more clearly? 
>Can you check if 5.4.0.CR1 still has the issue and create a jira: 
>   https://issues.jboss.org/browse/JBRULES
I have upgraded to 5.4.0CR1 (both planner and drools) and tried both the
generic change move and my custom implementation.
I still have instances where the log (DEBUG) shows tasks moved to new
resources, but the final (best) solution shows the task still on a previous
resource.
Before I create a JIRA for this, I want to show you a sample log output
describing the issue -
To read the planning entity string below: [<entity id> <resource string>
<task string> <start time> <end time>]
where <resource string>:
    [<resource id> <resource name>]
and <task string>:
    [<task id> <task name>]

2012-04-20 08:28:05,411 [main] DEBUG DefaultGreedyFitSolverPhase  -     Step
index (816), time spend (36875), score (-110hard/32200soft), initialized
planning entity ([817 [49 W502] [19664 TASK817] 19Mar12.03:00 19Mar12.05:00
]).
...
2012-04-20 08:28:12,005 [main] INFO  DefaultGreedyFitSolverPhase  - Phase
constructionHeuristic ended: step total (974), time spend (43469), best
score (-183hard/38700soft)
2012-04-20 08:28:12,536 [main] DEBUG DefaultLocalSearchSolverPhase  -    
Step index (0), time spend (44000), score (-183hard/38700soft),     best
score (-183hard/38700soft), accepted move size (800) for picked step ([817
[49 W502] [19664 TASK817] 19Mar12.03:00 19Mar12.05:00 ] => [102 W140]).
...
2012-04-20 08:30:01,974 [main] DEBUG DefaultLocalSearchSolverPhase  -    
Step index (566), time spend (153438), score (-175hard/39900soft),     best
score (-175hard/39900soft), accepted move size (800) for picked step ([817
[102 W140] [19664 TASK817] 19Mar12.03:00 19Mar12.05:00 ] => [94 W132])
...
2012-04-20 08:30:15,880 [main] DEBUG DefaultLocalSearchSolverPhase  -    
Step index (637), time spend (167344), score (-175hard/39900soft),     best
score (-175hard/39900soft), accepted move size (800) for picked step ([817
[94 W132] [19664 TASK817] 19Mar12.03:00 19Mar12.05:00 ] => [481 608]).
...

You can see that task817 was assigned to resource W502 by the construction
heuristic. Local search (Tabu) then moved this to resource W140, next to
W132 and finally to 608.
When I read the best solution obtained at the end of the local search (time
terminated), then TASK817 is showing as assigned to W140. 
What is strange is that the log file shows a successful move W140-->W132 and
ALSO W132-->608. Why did W132-->608 succeed if the task was still left on
W140?

>> However the final output 
>> shows the constraint still EXISTS between the two entities (even though
>> the 
>> overlap is no longer present). As a result even though the constraints
>> are 
>> actually removed, the score is NOT going down as the planner constraints 
>> still exist. 
>> The rule used by me is as follows (Allocation is the planning entity and
>> ...
>Smells like a memory corruption in drools-core. There is one fixed for 
>5.4.0.CR1, so 
>First turn on <environmentMode>TRACE</...> and see what it outputs.   
>Then upgrade to knowledge-api, drools-core and drools-compiler 5.4.0.CR1. 
On upgrading to 5.4.0CR1, I am facing a new issue in determining which
constraints are broken and hence unable to verify if my original issue is
fixed.
I am using the Drools Score Director and use the GUI hack to determine the
list of constraints met during solving. However the iterator returned is
empty even though I know that a lot of rules are met -
(Iterator<ConstraintOccurrence>) workingMemory.iterateObjects(new
ClassObjectFilter(ConstraintOccurrence.class));
Note that the workingMemory instance is not null, just the iterator returned
has no entries.

--
View this message in context: http://drools.46999.n3.nabble.com/Planner-5-3-0-Final-Issue-with-Local-Search-Move-tp3913541p3925199.html
Sent from the Drools: User forum mailing list archive at Nabble.com.