I'm new to ORTools and I need some guidance on which algorithm to choose for this problem:
(I think it is an assignment problem, but also a mix with route optimization and VRP..)
A salesman has N shops to visit
Every shop has a service time T (ex: 30 minutes)
Shops are categorized this way:
a) Category 1 = must be visited twice a week
b) Category 2 = must be visited once a week
c) Category 3 = must be visited biweekly (every two weeks)
d) Category 4 = must be visited once a month
A shop cant be visited 2 days in a row
The salesman should work up to 9 hours (1 hour for lunch)
The salesman should visit 8 to 12 shops a day (soft constraint)
The salesman should work up to 176 hours a month
Some shops can be discarded from the solution. (prefer to keep the ones with lower category)
We have the geolocation and a time distance matrix for the shops
The objectives are:
Maximize the number of shop visited
Minimize the KMs for the salesman
This is an example of shops distribution
First of all, it seems like you're trying to solve the problem globally, i.e. to find an optimal monthly or yearly schedule for the entire problem. I suspect that might be difficult, and suggest to try relaxing the problem, say: to a daily one.
For instance, maybe for a given day, it's possible to compile a list of stores which should be visited, perhaps by order of scores. So maybe a store that was visited yesterday will not be in the list; and one that has to be visited once a week, and was visited 6 days ago would be on the top of the list.
Then, you might be able to solve using a variant of the VRP solver on that list; you can use simulation (maybe with some random element) to generate a weekly or monthly schedule based on that. It's not guaranteed to be optimal, but might be good enough.
If your problem is more complex then what the OR-Tools VRP solver can handle, you can try using the more general CP-SAT solver, which is very generic, and can handle VRP-like problems with additional constraints, e.g. Scheduling problems or other constraints.
You can also consider using other approaches here, e.g. Tabu search.
Related
Please note that this is not the usual question about generating a fixture list for a league.
This problem is really doing my head in as I can't come up with a solution that wouldn't involve generating stupidly large results tables that couldn't be processed in my lifetime.
There are 19 teams in a league, 9 matches each week (1 team gets a rest each week). Over the season they play each other home and away. Now the meaty bit. 6 of the 9 matches are selected for a predictions competition. At the end of the season all of the teams in the league must have been selected for the prediction comp and all must have played the same number of home games in the predictions. The problem I have is how can I use SQL to generate each week's 6 fixtures to use in the predictions comp?
The numbers get silly because the are C(9,6)=84 possible combinations of matches that can be selected each week, so over just a few weeks the numbers get impossibly large. I'm sure there must be a solution for this but I'm well and truly stumped. Many thanks in advance.
PS: I don't need all possible combinations of prediction fixtures as that too would be impossibly large, just one result that satisfies the criteria.
So I'm developing a database for an agency that manages many relief staff.
Relief workers set their availability for each day in one of three categories (day, evening, night).
We also need to be able to set some part-time relief workers as busy on weekly, biweekly, and in one instance, on a 9-week rotation. Since we're already developing recurring patterns of availability here, we might as well also give the relief workers the option of setting recurring availability days.
We also need to be able to query the database, and determine if an employee is available for a given day.
But here's the gotcha - we need to be able to use change data capture. So I'm not sure if calculating availability is the best option.
My SQL prototype table looks like this:
TABLE Availability Day
employee_id_fk | workday (DATETIME) | day | eve | night (all booleans)| worksite_code_fk (can be null)
I'm really struggling how to wrap my head around recurring events. I could create say, a years worth, of availability days following a pattern in 'x' day cycle. But how far ahead of time do we store information? I can see running into problems when we reach the end of the data set.
I was thinking of storing say, 6 months of information, then adding a server side task that runs monthly to keep the tables updated with 6 months of data, but my intuition is telling me this is a bad fix.
For absolutely flexibility in the future and keeping data from bloating my first thought would be something like
Calendar Dimension Table - Make it for like 100 years or Whatever you Want make it include day of week information etc.
Time Dimension Table - Hour, Minutes, every 15 what ever but only for 24 hour period
Shifts Table - 1 record per shift e.g. Day, Evening, and Night
Specific Availability Table - Relationship to Calendar & Time with Start & Stops recommend 1 record per day so even if they choose a range of 7 days split that to 1 record perday and 1 record per shift.
Recurring Availability Table - for day of week (1-7),Month,WeekOfYear, whatever you can think of. But again I am thinking 1 record per value so if they are available Mondays and Tuesday's that would be 2 rows. and if multiple shifts then it would be multiple rows.
Now and here is the perhaps the weird part, I would put a Available Column on the Specific and Recurring Availability Tables, maybe make it a tiny int and store something like 0 not available, 1 available, 2 maybe available, 3 available with notice.
If you want to take into account Availability with Notice you could add columns for that too such as x # of days. If you want full flexibility maybe that becomes a related table too.
The queries would be complex but you could use a stored procedure or a table valued function to handle it fairly routinely.
Hi and happy new year to all Optaplanner users,
we have a requirement to plan tours. These tours contain chained and time-windowed activities (deliveries) executed by a weekly changing number of trucks.
The start time of a single tour can vary and is dependent on several conditions (i.e. the goods to be delivered must be produced, before the tour can start; only a limited number of trucks can be served at the plants gates at the same time; truck must be back before starting a new tour). Means: also the order of tours can vary and time gaps between the tours of a truck can occur.
My design plan is, to annotate TourStartTime as a second planning variable in Optaplanners VRPTW-example and to assign TourStartTime to 2-hours time grains (planning horizon is 1 week and tours normally do not start during night times; so the mentioned time grains reflect a simplified calendar for possible tour starts).
The number of available trucks (from external logistic companies) can vary from week to week. Regarding this I wanted to plan with a 'unlimited' number of trucks. But the number of trucks per logistic company, that can be actually assigned with deliveries, should be controlled by a constraint (i.e. 'trucks_to_be_used_in_parallel').
Can anybody tell me, if this is a feasable design approach, or where do I have to avoid traps (ca. 1000 deliveries/week, 40-80 trucks per day) ?
Thank you
Michael
A second planning variable is possible (and might be even the best design depending on your requirements), but it will blow up the search space and maybe even custom course grained moves might become needed to get great results.
Instead, I 'd first investigate if the Truck's TourStartTime can be made a shadow variable. For example, give all trucks a unique priority number. Then make a Truck's TourStartTime a shadow variable: the soonest time a truck can leave. If there are only 3 lanes and 4 trucks want to leave, the 3 trucks with the highest priority number leave first (so get the original TourStartTime, the 4th truck gets a later one).
I'm new to OptaPlanner, and seen how some problems can be solved fairly easily by modifying from the very useful sets of example. I'm trying to figure out what is the best way to model my problem.
I have a group of deliverymen, and their job is to deliver supplies from multiple suppliers to multiple customers. The tricky part is that the customers requirements and suppliers supplies are range values that varies from month to month. And I also have the option to hire temp deliverymen if the supplies and demands of the month is too high. End result is to maximize profit for each month.
What category of optimization problem am I facing, and I'm struggling to find the best way to model this problem. Any suggestions?
Put in a number of temp deliverymen as normal deliverymen with a boolean temp=true, and have your score constraints penalize those more (I presume a higher soft weight as the soft score will be your profit).
This is basically the pickup and delivery variation of the VRP example. Some of our users have adjusted the VRP example to this already (see some of the other questions here on stackoverflow tagged with optaplanner). Basically the trick is to write a score constraint that understands that the "load" of a vehicle changes through its route (but it should always be less than its "capacity").
You can schedule 1 month (or 1 week or less or 2 months or more) at a time, but you can also do "continuous planning" (if months affect each other like in nurse rostering, but I doubt that's the case here) (if so, see the optaplanner video on youtube) to plan a window.
Lets say I have a website that sells widgets. I would like to do something similar to a tag cloud tracking best sellers. However, due to constantly aquiring and selling new widgets, I would like the sales to decay on a weekly time scale.
I'm having problems puzzling out how store and manipulate this data and have it decay properly over time so that something that was an ultra hot item 2 months ago but has since tapered off doesn't show on top of the list over the current best sellers. What would be the logic and database design for this?
Part 1: You have to have tables storing the data that you want to report on. Date/time sold is obviously key. If you need to work in decay factors, that raises the question: for how long is the data good and/or relevant? At what point in time as the "value" of the data decayed so much that you no longer care about it? When this point is reached for any given entry in the database, what do you do--keep it there but ensure it gets factored out of all subsequent computations? Or do you archive it--copy it to a "history" table and delete it from your main "sales" table? This is relevant, as it has to be factored into your decay formula (as well as your capacity planning, annual reporting requirements, and who knows what all else.)
Part 2: How much thought has been given to the decay formula that you want to use? There's no end of detail you can work into this. Options and factors to wade through include but are not limited to:
Simple age-based. Everything before the cutoff date counts as 1; everything after counts as 0. Sum and you're done.
What's the cutoff date? Precisly 14 days ago, to the minute? Midnight as of two Saturdays ago from (now)?
Does the cutoff date depend on the item that was sold? If some items are hot but some are not, does that affect things? What if you want to emphasize some things (the expensive/hard to sell ones) over others (the fluff you'd sell anyway)?
Simple age-based decays are trivial, but can be insufficient. Time to go nuclear.
Perhaps you want some kind of half-life, Dr. Freeman?
Everything sold is "worth" X, where the value of X is either always the same or varies on the item sold. And the value of X can decay over time.
Perhaps the value of X decreased by one-half every week. Or ever day. Or every month. Or (again) it may vary depending on the item.
If you do half-lifes, the value of X may never reach zero, and you're stuck tracking it forever (which is why I wrote "part 1" first). At some point, you probably need some kind of cut-off, some point after which you just don't care. X has decreased to one-tenth the intial value? Three months have passed? Either/or but the "range" depends on the inherent valud of the item?
My real point here is that how you calculate your decay rate is far more important than how you store it in the database. So long as the data's there that the formalu needs to do it's calculations, you should be good. And if you only need the last month's data to do this, you should perhaps move everything older to some kind of archive table.
you could just count the sales for the last month/week/whatever, and sort your items according to that.
if you want you can always add the total amonut of sold items into your formula.
You might have a table which contains the definitions of the pointing criterion (most sales, most this, most that, etc.), then for a given period, store in another table the attribution of points for each of the criterion defined in the criterion table. Obviously, a historical table will be used to store the score for each sellers for a given period or promotion, call it whatever you want.
Does it help a little?