Hi Geoffrey,
I managed to implement the solution with the relative end Times. (I haven't
yet used the incremental score calculation because I haven't quite
understood how I implement it)
However I am facing one problem with our approach:
Lets say we have 3 tasks A, B, and C, each of duration 1 just for
simplicity, with these constraints:
a) B can only start between A.endTime + 10 and A.endTime + 100
b) C can only start between A.endTime + 50 and A.endTime + 100
c) C can only start between B.endTime + 10 and B.endTime + 20
With our approach of B.startTime = max(prev.endTime, A.endTime + 10) B
will always be scheduled to start at time 11 (and end at time 12) given the
hard constraints above.
On the other hand C cannot start before time 51, thus violating constaint
C.
The only solution to this would be to move B forward to start at time 30.
Is there any technique to detect these situations and make such adjustments?
thanks again,
Josef
On 20 August 2012 09:46, Geoffrey De Smet ge0ffrey.s...@gmail.com wrote:
You 'll want incremental score calculation (with delta's) for your end
times.
http://docs.jboss.org/drools/release/5.4.0.Final/drools-planner-docs/html_single/index.html#incrementalScoreCalculation
So that naturally puts the calculation of those end times in the scoreDRL
(or IncrementalJavaCalculator if you're not using drools).
Whether or not that endTime should be a property on the model (at least
the model that Planner works with), is an open design question.
If it isn't, you can use insertLogicals in DRL, like I did in
nurserostering to calculate the number of sequential weekends being worked
etc.
If it is a property on your model, either the DRL must first correct it
(with higher salience rules for example),
or custom moves must correct it as they are being done (which is very
hard as it entails constraints functionality).
As for the cloning: it's quite simple:
Either the model's entity contains the endTime property, then clone it.
If it doesn't, then there's nothing to clone.
I don't see any problems related to the cloning.
Op 18-08-12 01:53, Josef Bajada schreef:
Hi Geoffrey,
Following your advice and after gaining some more understanding of
planner, I think approaching the problem as a chain of tasks one of the
other makes sense. It would have some 'wait' time between tasks where the
end time of the previous task is smaller than the minimum time the task has
to wait after its dependency (which could be different from the previous
task).
I've noticed that in most examples (TSP and VRP), there is some
separation between the model and the planning entity that is being moved
around in the chain, which also makes sense. (For instance in TSP, Visit is
the planning entity while City is the data entity). When the planning
entity gets cloned, the data entity gets assigned to the clone.
I am concerned however, that with my dependency between tasks and their
end times (which are as such a property of the planning entity not the data
entity) I won't be able to model them in this way. (For a task to know
whether it has violated its hard constraint it needs to get access to the
end time of its dependency, which is in the planning entity). My concern is
that I might end up with a whole mess when it comes to the cloning of
tasks. I am also concerned about the performance of computing the end time
of each node recursively based on its previous task and dependent tasks.
What is the best approach in this case?
thanks,
Josef
On 25 July 2012 08:30, Geoffrey De Smet ge0ffrey.s...@gmail.com wrote:
Op 24-07-12 23:14, Josef Bajada schreef:
Hi Geoffrey,
Thanks for your reply.
Does it make sense to wait longer than 7 mins after task A (presuming
no other task forces occupies the user at that time)?
Put differently: Can we say that the starting time of B =
Math.max((endTime of task before B), (endTime of task A + 7 minutes))?
If we can say that, it's pointless to investigate the solutions where
task B starts 8 minutes after task A and the user doing no task that last
minute.
Yes, the starting time of B = Math.max((endTime of task before B),
(endTime of task A + 7mins)) as long as it is smaller than (endTime of task
A + 8mins).
Yes, it is pointless to investigate the solutions where task B starts 8
minutes after task A and the user doing no task that last minute.
The 8 minute is just a constraint that the task in between tasks A and B
cannot take longer than 7:59s.
I am thinking that maybe instead of using time itself as the planning
variable, we would use time just to determine the Hard and Soft scores.
So if Task B is scheduled after Task A + 8mins by the solver, then it
inflicts on the hard score. Similarly if Task B is scheduled before Task A
+ 7 mins.
Does my reasoning make sense in any way?
Yes, but personally, I 'd design it differently (although I have no proof
that my way would be better), like this:
