[rules-users] Planner 5.3.0 Final - Issue with Local Search / Move
Geoffrey De Smet
ge0ffrey.spam at gmail.com
Sun Apr 22 10:10:55 EDT 2012
Op 20-04-12 07:45, duggal schreef:
>>> 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?
See your jira: https://issues.jboss.org/browse/JBRULES-3471
"The last solution is not necessarily the best solution.
Planner reminders the best solution it encounters, but when it hits a
local optima, it will need to do a few steps that have worse solution to
get out of it and find a better local optima.
The log clearly says ", best score", not ", new best score", so that's
normal that that step move isn't in the best solution (unless later a
new best solution is found and no other step move has undone that step
move)."
>>> 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.
It's probably because of this change:
[MAJOR] An uninitialized planning entity should be allowed to be put
into the working memory
without causing a NullPointerException because a planning variable is
still null.
Before in *.java:
@PlanningEntity(...)
public class Lecture ... {
@PlanningVariable(...)
public Period getPeriod() {
return period;
}
...
public Day getDay() {
return period.getDay();
}
public int getTimeslotIndex() {
return period.getTimeslot().getTimeslotIndex();
}
...
}
After in *.java:
@PlanningEntity(...)
public class Lecture ... {
@PlanningVariable(...)
public Period getPeriod() {
return period;
}
...
public Day getDay() {
if (period == null) {
return null;
}
return period.getDay();
}
public int getTimeslotIndex() {
if (period == null) {
return Integer.MIN_VALUE;
}
return period.getTimeslot().getTimeslotIndex();
}
...
}
> 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.
Call scoreDirector.calcluateScore() first.
> --
> 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.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
With kind regards,
Geoffrey De Smet
More information about the rules-users
mailing list