Greetings!
*TLDR:
- Given a problem instance with 46 jobs and 10 vehicles, time windows and skills.
- latest build of VROOM (alias. "1.12.0-dev" from 2nd of february) is not capable to assign all jobs to vehicles - compared to v1.8.
- but even leaves some vehicles unused.
- However, an acceptable solution is found by including an additional job, which might contradict VROOM's mantra.*
- Both "latest" and v1.8 build were not capable to reproduce the acceptable solution, if vehcle order gets flipped.
Description
Given the following problem instance from the zip-folder:
4_instances_on_v8_and_latest.zip
- "46_jobs.json", a problem instance with 46 jobs and 10 vehicles, time windows and skills.
And its alterations:
- "47_jobs.json", an additional job is added.
And the same instaces as above, but order of vehicles inside the array is flipped:
- 46_jobs_flipped.json
- 47_jobs_flipped.json
For all given 4 instances, there are VROOM outputs from version 1.8 and "latest".
- 46_jobs_result_v8.json
- 46_jobs_result_latest.json
- etc.
In the scenario of those problem instances, a solution is considered "good",
if all jobs are getting assigned - observeable by the "unassigned" key inside the result JSON.
The overall cost optimization is not relevant.
The three phenomena occurring:
A) Worse solution with latest build.
On instance "46_jobs.json"
we find a good solution with VROOM v1.8 - using 9 from 10 available vehicles -
while the "latest" build is only capable to assign all jobs but one.
B) Adding one more jobs results in a good solution
On instance "47_jobs.json"
both vroom versions are capable to find a good solution - both using only 9 from 10 available vehicles.
It shall be mentioned, that the added job (id:0) could be served by the unused vehicle.
Considering the "bad" solution from "46_jobs.json", this is quite troubling as logically it's hard to explain to anyone that a more complicated instance achieves a good result but a less complicated instance doesn't.
C) Changing the vehicle order
If changing the vehicle order - as in "46_jobs_flipped.json" and "47_jobs_flipped.json" respectively -
none VROOM version is capable to reproduce the "good" solution.
Thoughts
While problem C is problematic for consistency and reproduction purposes/debugging,
it is to some degree explainable: Input different - output different.
Problem A and B however are troubling.
Questions
Would you consider these behaviours as acceptable or can this already be considered as bug?
I get that I could use an existing solution as input for a following optimization, but that is hard to decide in advance when gradually adding more jobs as you don't know in advance when you should use an existing solution or rather leave VROOM more freedom.
Greetings!
*TLDR:
Description
Given the following problem instance from the zip-folder:
4_instances_on_v8_and_latest.zip
And its alterations:
And the same instaces as above, but order of vehicles inside the array is flipped:
For all given 4 instances, there are VROOM outputs from version 1.8 and "latest".
In the scenario of those problem instances, a solution is considered "good",
if all jobs are getting assigned - observeable by the "unassigned" key inside the result JSON.
The overall cost optimization is not relevant.
The three phenomena occurring:
A) Worse solution with latest build.
On instance "46_jobs.json"
we find a good solution with VROOM v1.8 - using 9 from 10 available vehicles -
while the "latest" build is only capable to assign all jobs but one.
B) Adding one more jobs results in a good solution
On instance "47_jobs.json"
both vroom versions are capable to find a good solution - both using only 9 from 10 available vehicles.
It shall be mentioned, that the added job (id:0) could be served by the unused vehicle.
Considering the "bad" solution from "46_jobs.json", this is quite troubling as logically it's hard to explain to anyone that a more complicated instance achieves a good result but a less complicated instance doesn't.
C) Changing the vehicle order
If changing the vehicle order - as in "46_jobs_flipped.json" and "47_jobs_flipped.json" respectively -
none VROOM version is capable to reproduce the "good" solution.
Thoughts
While problem C is problematic for consistency and reproduction purposes/debugging,
it is to some degree explainable: Input different - output different.
Problem A and B however are troubling.
Questions
Would you consider these behaviours as acceptable or can this already be considered as bug?
I get that I could use an existing solution as input for a following optimization, but that is hard to decide in advance when gradually adding more jobs as you don't know in advance when you should use an existing solution or rather leave VROOM more freedom.