reinterpretcat
commented
1 year ago Hi, thanks for feedback! Yes, some checks are run only if matrices are specified. Also checker itself can have some issues (there is one already: https://github.com/reinterpretcat/vrp/issues/31), but I think the issue is in the break logic. I need to find time to work on it, at the moment, I'm working hard to finish a big internal change. It will take some time.
Hello, I am a colleague of @roganjoshp who started the discussion around the handling of required driver breaks earlier in the year. Many thanks for your work in adding this functionality and apologies for the delay in getting back to you (there were a number of delays in implementing the API bindings to connect your solver to the rest of our vehicle routing stack).
I am running into the following error when attempting to solve the problem located here :
thread 'actix-rt|system:0|arbiter:0' panicked at 'unfeasible solution in 'abcd-1234-56780efgh': 'arrival time mismatch for 5 stop in the tour: car_0, expected: '2021-01-01T09:54:00Z', got: '2021-01-01T09:30:00Z''', vrp-api/src/main.rs:84:13 note: run withRUST_BACKTRACE=1environment variable to display a backtracevrp-api/src/main.rs is a separate component implemented by us as part of the API bindings, but the error itself is raised by the module which checks the routing information is used properly. If I run the same problem without a custom matrix, it returns the solution located here without any errors. Correct me if I’m wrong, but here, it looks like the check which raised the error above is skipped whenever a custom matrix is not supplied (and the haversine approximation is used instead internally), and that is the reason why a solution is returned successfully in this case.
Also, the break in the solution above seems to be one of the activities within the same stop as a pickup job and the start and end times seem to be overlapping which may be why the routing check is failing. I am aware of this issue which sounds similar to this, so happy to move the discussion there as well.
Lastly it’s worth noting that when the break is returned as a separate stop in the tour rather than one of the activities in the same stop as another, the error above is never present from what I’ve seen (an example of such a solution is here). Please let me know if my understanding of the checker behaviour is correct and more than happy to send any additional examples if that would be helpful.