Warehouse access time

[boooch]

In case of using pickup and delivery, part or all pickups can be in one point (warehouse). If I set service time fop pickup for example 10 minutes in case of 5 shipments - full service time will be 50 minutes. But this is not real situation. Best solution IMHO is to add additional variable to job - access time. In this case I can set access time for warehouse - 10 minutes and service time for each shipment - 1 minute, so we will get 11 minutes in case of 1 shipment and 15 minutes in case of 5 shipments. What are you thinking about it? This is real use case

[jcoupey]

This sounds really similar to #353 where a couple options/hacks have been discussed.

[jcoupey]

It's probably possible to achieve the expected behaviour without a huge change of the current implementation. The idea would be to keep the service value as a small unit of time that is actually required with an extra step, but add a setup time value that would account for the cost that should not be duplicated (e.g. arriving, parking etc.).

For a task at a new location, we would apply setup + service time, but then for any additional task at the same location, only the service time would be applied.

For example, 5 pickups done in a row with each a setup of 10 minutes and service of 2 minutes, then the overall time would be 10 + 5 * 2 = 20 minutes.

Provided it's always possible to access previous location for all checks/route changes without changing the current implemenation (I think so), then it would be a matter of spotting all places where a service time is applied to decide whether the setup time should be added.

[leobudima]

Just to add anecdotally that this does prove to be an inconvenience in different situations - e.g.:

• regular delivery of multiple tasks at the same location, when because of accumulated service time at location other possibly doable tasks are unassigned

• modeling tasks as shipments for the purpose of reloading at depot, and then having a huge accumulated service time at depot if not specifically managing pickup service duration differently

and the setup + service sounds like a great feature!

I'm sure people will end up asking about different setup times for different types of tasks etc, but realistically, a simple, "optimization-wide" setup value is more than great for majority of cases.

[jcoupey]

@leobudima thanks for your input. I agree this is significantly important and we need to have it at some point.

I know I won't have time to commit to this feature any time soon, so for the time being I'd welcome any contribution. This is why I described a possible implementation above and can provide more pointers for those interested. I'd gladly merge a PR that implements this idea without increasing solving complexity.

[leobudima]

@jcoupey thanks for your reply!

While this is firmly outside of my technical comfort zone for now, I would be really glad to start contributing and might give it a try soon - do you potentially have any high-level guidance on the implementation?

[jcoupey]

Running a simple grep -rn service from the src folder provides an overview of the files/places you'd potentially want to touch.

Technical stuff

1. Parse the setup value in input (utils/input_parser.cpp)
2. Adjust the Job object and ctor to store it (structures/vroom/job.h and structures/vroom/job.cpp)
3. Store setup value in relevant objects used to describe a solution (structures/vroom/solution/*)
4. Report cumulated setup values at step, route and summary level in output (utils/output_json.cpp)

Core work

Spotting all situations where a task service value is used in order to potentially also add the setup value. This happens in structures/vroom/tw_route.cpp when checking for route validity or updating a route while solving and in utils/helpers.h when we actually build final routes and compute all arrival times.

Locations (and jobs) have an index member function that allow accessing the rank of the location in the matrix. It can be safely used to find out if a location is the same as the previous one. The trickiest part here is probably to fetch the previous job/location index involved depending on the context.

[boooch]

this feature still not implemented?

[jcoupey]

Nope, looks like no-one had time to work on this so far.

[jcoupey]

The setup time for tasks is now a thing in master after merging #547.