-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read HFVRP instances #550
base: main
Are you sure you want to change the base?
Read HFVRP instances #550
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #550 +/- ##
==========================================
+ Coverage 95.68% 95.70% +0.02%
==========================================
Files 73 73
Lines 3243 3260 +17
Branches 888 888
==========================================
+ Hits 3103 3120 +17
Misses 48 48
Partials 92 92 ☔ View full report in Codecov by Sentry. |
@N-Wouda Also check out https://github.com/PyVRP/Sandbox/pull/6 for the new instances and README. I'll bump that to PyVRP/Instances and update the submodule after review. |
I need to do a bit more testing on this, probably tomorrow. I have tried to solve all HFVRP instances with 10 second runtime, but there are some instances that don't result in feasible solutions, even for longer runtimes. This instance is pretty annoying: even though we have an unlimited fleet, the initialization procedure uses vehicle type 0 by default. But some clients have demand that exceeds this vehicle type capacity.
Details
|
OK, it turns out that there is at least one instance ( There may be more, but I don't want to do that manually. It should be very easy to check with an exact bin packing program. I have messaged the original author of the paper Pessoa et al. (2018). Until then, this PR is on-hold. Details about X115-HVRPInstance: X115-HVRP.txt These are the vehicle capacities:
These are the client demands:
The presented 12 clients must be assigned to these vehicles with large capacities. There are more vehicles, but the capacity is too small. Summing up these values:
This can't even feasibly fit! |
OK, I manually checked all other instances and turns out X115-HVRP is the only infeasible instance. That's good news; I'll just run a benchmark without this instance. There were still some issues with the weights. I have fixed this now and am running a new benchmark. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to think about the scaling issue a bit more. The increase in e.g. penalty term value and overall ballooning size of all values scares me a bit.
This PR is ready to be reviewed again. The open issue with HFVRP instances was how to deal with the scaling. The current solution is not to scale unit distance costs, instead we assume that the instance data is integral. Accordingly, the original HFVRP instances are modified to match this assumption. |
Oh, sorry, I still need to look at this. I'll try to do so later today! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me, I only have one question about the rounding (and the earlier concern about the huge penalty terms up to 1 million, but that might be OK now that we have 64-bit integers).
# Unit distance costs are not rounded: we assume here that the instance | ||
# presents the costs in the desired precision! | ||
unit_distance_costs = instance["vehicles_unit_distance_cost"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems a bit odd. Why would we not round these? What goes wrong if we do?
This PR adds support for reading HFVRP instances and is part of #543.
Notes:
This keeps the code coverage level up, and helps ensure the changes work as intended.