Closed RaulRomani closed 4 years ago
I have 20 deliveries located at the same coordinates
In that case, it would be much more convenient to submit just one job covering the 20 deliveries (just add up delivery amounts), especially if you know the overall service time and want to set it to 30 minutes.
Benefits of this approach are:
Thank you for your prompt reply.
You are right. The problem is that I only use Shipments (pickup and delivery) and I don't know for sure how many repeated pickups locations or delivery locations I will have each day.
service_time_pickup_location = function1(#pickups_repeated_location) service_time_delivery_location = function2(#deliveries_repeated_location)
I kind of solved that problem by processing the routes given by vroom (updating the step times according to the above-shown formulas). But that solution produces shorter route times and do not optime all the time that vehicles have. For example, A vehicle work time is 6 hours and a route given by vroom has a duration of 5.5 hours and after doing that post-processing that route has a duration of 3 hours.
I believe that I could add some code inside the lambda function called run_solve that is located in the class VRPTW. Is it possible to edit the route times before the time window validation?
Yes, adjusting the service times after optimization has an impact on the rate of available hours actually used in the solution.
How much do you care about time windows? I mean do you have timing constraints for shipments steps at all, beside vehicle time windows?
Yes, I have vehicle time windows and delivery time windows. I don't use pickup time windows. Why?
Just asking because if you don't have many timing constraints, a quick hack could be to artificially overestimate the vehicles work time.
Yes, that could work. But, there could be cases in which it exceeds the vehicle time window.
There is no easy way to use a simple formula such as service_time_pickup_location = function1(#pickups_repeated_location)
. The reason is that during the search we do simple moves without having a global view of the route (e.g. insert a new job at a given rank in an existing route). Knowing the number of repeated locations at that step would require looking around through the route, which we currently avoid for efficiency reasons.
What you could try though would be to adjust the way job service times are evaluated during validity checks and route updates. You could default to using the "usual" job.service
value for the first occurrence of a location, then reduce the service time for any additional location that is the same as the previous existing step.
I think you'd only have to adjust the service time evaluation used in https://github.com/VROOM-Project/vroom/blob/master/src/structures/vroom/tw_route.cpp ; would probably require quite a dive into the route validation and update logic though.
That is quite a challenge. At least for now, I'm just going to overestimate the vehicle time windows. Thanks for your help, much appreciated.
OK, so closing now. Feel free to re-open if required later.
Currently, the service duration of jobs that happens to be in the same location is calculated with the formula:
service_duration_of_jobs = #jobs * step.service
For example, The service time of a job of type delivery is set it to 10 minutes and I have 20 deliveries located at the same coordinates. The service time for all those 20 deliveries that are located in the same coordinates will be 200 minutes; however, I want it to be 30 minutes.
I believe I can do this modification in the vroom code. I would have to update the arrival and duration of every route in each iteration. But I don't know exactly where to put this code. Maybe that problem could be solved with a simpler approach. Can someone help me with this problem?