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

Geoffrey De Smet ge0ffrey.spam at gmail.com
Fri Apr 6 07:50:15 EDT 2012


I just realized that the graph only prints out values (the soft score) 
of the hard score = 0.
Since you don't reach feasibility early on, the graph will be zero.
Try to tmp hack it to get the graph by disabling soft constraints and 
putting the hard constraints values in the soft score.

With kind regards,
Geoffrey De Smet


Op 06-04-12 13:46, Geoffrey De Smet schreef:
> 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





More information about the rules-users mailing list