Von: "Geoffrey De Smet" <ge0ffrey.spam(a)gmail.com&gt; An: rules-users(a)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

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(a)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&quot;&lt;ge0ffrey.spam(a)gmail.com&gt; >> An: rules-users(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users

Thank you for all the tips. In the mean time I was able to locate the source of serious performance "killer". These 3 rules: http://nopaste.info/3f89c43eee_nl.html

I tried to reorganize and re-optimize them at least 10 times to no avail. I'd appreciate, if anyone could suggest me how to change them to get the performance up. Until now I have tried: - reducing variable bindings (e.g. resource == $resource to resource == $maxLoad.resource) - moving accumulate from constraint rules to "insert momentary load" - joining sum for TUs and Picks in one accumulate - and number of other less useful changes still, if I add these rules the calculate count goes down from approx 5300 to 2000 per second which is more than a half.

Thanks and kind regards, Reinis On 04/06/2012 01:50 PM, Geoffrey De Smet wrote: > 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(a)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&quot;&lt;ge0ffrey.spam(a)gmail.com&gt; >>>> An: rules-users(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users