You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When submitting an instance that has no time_window key for vehicles and time_windows key for any of the tasks, then it's treated as a CVRP which removes the need for all time validity checks. So far so good. But this behavior remains if a vehicle has a non-empty breaks array. Then the result of the problem being treated as a CVRP is that the breaks are not assigned at all.
One may argue that providing breaks without an actual working hour restriction is somehow an edge case (and probably the reason why this went unnoticed so far). But from the API point of view this is totally valid: not providing a vehicle time_window means "no constraints" on overall working hours but then requesting breaks can still make sense.
A current work-around is to apply a huge non-constraining time window somewhere to switch to VRPTW-based solving.
A straightforward fix would be to simply update the Input::_has_TW flag properly upon adding a new vehicle in order to consider not only its time window but the existence of potential breaks.
When submitting an instance that has no
time_window
key for vehicles andtime_windows
key for any of the tasks, then it's treated as a CVRP which removes the need for all time validity checks. So far so good. But this behavior remains if a vehicle has a non-emptybreaks
array. Then the result of the problem being treated as a CVRP is that the breaks are not assigned at all.One may argue that providing breaks without an actual working hour restriction is somehow an edge case (and probably the reason why this went unnoticed so far). But from the API point of view this is totally valid: not providing a vehicle
time_window
means "no constraints" on overall working hours but then requesting breaks can still make sense.A current work-around is to apply a huge non-constraining time window somewhere to switch to VRPTW-based solving.
A straightforward fix would be to simply update the
Input::_has_TW
flag properly upon adding a new vehicle in order to consider not only its time window but the existence of potential breaks.vroom/src/structures/vroom/input/input.cpp
Line 241 in e1fd844
The text was updated successfully, but these errors were encountered: