[rules-users] [Drools Planner] Proof-of-Concept Stock-planning System

[Geoffrey De Smet]

32 hours, that is very long, especially if you're talking about feasibility.
Feasibility much be attained within seconds or maybe 2 minutes.

So either your problem is very, very constrained (unlikely)
or there is much room for optimization.

Run the Benchmarker and enable the statistic BEST_SOLUTION_CHANGED.
Verify that you have a good graph, and not a bad graph. See this issue 
to see the difference:
   https://issues.jboss.org/browse/JBRULES-3451


Op 06-04-12 13:33, drools at orbit-x.de schreef:
> Thank you, Geoffrey!
>   
> This is the answer I was hoping for and it confirms my understanding of this problem.
>   
> Indeed it looks like it will be a standard implementation (since it is (A) and (C)).
>   
> The reason I was willing to ask the community is that current (non-optimizied prototype solution) takes approx. 32 hours to complete. But I am pretty sure that optimized move factory, rule definitions and engine configuration will move the completion time down to expected 6 hours.
>   -----Original-Nachricht-----
>> Von: "Geoffrey De Smet"<ge0ffrey.spam at gmail.com>
>> An: rules-users at lists.jboss.org
>> Datum: 05-04-2012 11:34
>> Betreff: Re: [rules-users] [Drools Planner] Proof-of-Concept Stock-planning System
>>
>> Op 03-04-12 23:10, Reinis schreef:
>>> Hello,
>>>
>>> I want to ask you, guys, if you could guess if it is possible or
>>> probable to build such a System with Drools Planner:
>>>
>>> The system shall plan the best time where the transport unit (TU) has to
>>> be input into stock system to reach set delivery deadlines, utilization
>>> of resources and load balancing of bottle necks (all expressed as rules).
>>>
>>> Most of things (resource capacity, route within the stock system, etc.)
>>> are given and constant facts. Actually there is only one planning
>>> variable - time interval of a transport unit characterizing retention
>>> period within a given Resource. Like this:
>>>
>>> TU#1 is in Resource #A from 11:00 till 11:30<- the optimal interval has
>>> to be planned
>> Is the value range something like this:
>> (A)
>> - 10:00 till 10:30
>> - 10:30 till 11:00
>> - 11:00 till 11:30
>> - 11:30 till 12:00
>> Or like this?
>> (B)
>> - 11:00 till 11:15
>> - 11:01 till 11:16
>> - 11:02 till 11:17
>> - 11:03 till 11:18
>> ...
>>  From reading further, I presume (A).
>>
>>> TU#1 is in Resource #B from 11:45 till 12:00<- the optimal interval has
>>> to be planned
>>>
>>> TU#1 is in Resource #C from 12:30 till 13:00<- the optimal interval has
>>> to be planned
>>>
>>> I have following problem size and constraints:
>>> - TUs per day: 160'000
>>> - Amount of resources a TU travel through: 3
>> Do the TU need to go through it's 3 resources in a specific order?
>> (C) No
>> (D) Yes
>> I presume it can not go through 2 resources at the same time.
>>> - Average smallest time interval: 15 Min
>>> - Planning period: 09:00 - 16:00 = 8 hours = 32 intervals
>>> - Initial planning window: 4-6 hours
>>> - continuous planning multiple batch execution time during the day after
>>> addition and/or retraction of number of TUs: 20 minutes
>> (E) This is repeated planning (see documentation manual if you haven't
>> already).
>>> So the problem size would be(?):
>>> (TUs * resources) ^ intervals = (160'000 * 3) ^ 32 = 6.305500958×10¹⁸¹
>> That's not a big search space. In some examples I 've seen 10^6800.
>> Of course, the search space isn't the only metric to take into account
>> (but I haven't found a good way to measure the other metrics,
>> such as how-constrained-is-the-problem, how-big-is-the-snowball-effect,
>> ...).
>>> I know there is no one answer to this question. I would like only to get
>>> your feeling on this problem. Would you take on solving this sort of
>>> problem with drools planner?
>> Definitely :)
>> If it's (A) and (C), it should be an easy, standard implementation.
>> If it's (B) and (D), then it becomes interesting :)
>>
>> The only part I expect some rough edges is (E).
>> I suspect you'll be asking for build-in support for "planning entity
>> locking" to do your continuous planning easily.
>>    https://issues.jboss.org/browse/JBRULES-3359
>> It's a PITA to do that yourself for now.
>>> thanks and br
>>> Reinis
>> -- 
>> With kind regards,
>> Geoffrey De Smet
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-- 
With kind regards,
Geoffrey De Smet