Prize-collecting instances

[N-Wouda]

@leonlan @wouterkool I suggest we take the GH1000 and X instances as a basis, and simply add a new prize section to them. Unsure what reasonable prizes would be.

My thinking now is maybe sample these uniformly from [min distance, max distance]? What do you think 'reasonable' prizes would be? I'll have a look for some relevant literature before committing to any one thing, but that'll have to wait until tomorrow.

[leonlan]

I don't know what prizes will lead to "good" PCVRP instances. But here's one instance property that you could aim to achieve with some additional thoughts:

• Percentage of served customers: Good solutions should not serve too few but also not too many customers.
  • Maybe two categories, something like 30-50%, and 60-80%.
  • Prizes shouldn't be too low, because then nothing will be served.
  • If there's an unlimited or very large fleet, then prizes shouldn't be too high, otherwise all customers may be served.
  • Prizes of geographical outliers in the instance should be normalized, otherwise, they are trivially included/excluded from the solution. [I only know that EURO-NeurIPS instances have geographical outliers, not sure if they are in GH or X]

[N-Wouda]

I think the current instances make sense. They are:

• The small instances of Bulhões et al. (2018). I call these "PC-CVRP" in this repository. The instances have 50-200 customers, and optimal solutions are known (see the paper linked below for details).
• The GH1000 instances, with an added prize section. I call these "PC-VRPTW" in this repository. The prizes are generated in a fashion similar to that of Bulhões et al. (2018) and Stenger et al. (2013), as $p_i = h_i \times q_i$, where $h_i$ is sampled iid from $U[0.75, 2.25]$ for each client $i$ (and $q_i$ is its demand).

Bulhões, T. et al. (2018). The vehicle routing problem with service level constraints. European Journal of Operational Research, 265(2): 544–558. https://doi.org/10.1016/j.ejor.2017.08.027.

Stenger, A. et al. (2013). The prize-collecting vehicle routing problem with single and multiple depots and non-linear cost. EURO Journal on Transportation and Logistics, 2(1–2): 57-87. https://doi.org/10.1007/s13676-013-0022-4.

[N-Wouda]

I toyed a bit with scaling the prizes, but roughly 1.5 times demand seems to work well enough (and is something we can back up with literature). Such prizes work out to 20-40% of all customers on the C and RC instances, and 10-20% on the R instances. I think that's reasonable.

[N-Wouda]

We might not need the small PC-CVRP instances if we can benchmark against another, good prize-collecting algorithm on the larger PC-VRPTW instances.

[N-Wouda]

I have an initial set of BKS for the PC-VRPTW instances that I'll inspect and commit tomorrow.

[N-Wouda]

With these BKS, we have the following for the PC-VRPTW instances averaged by instance group:

So the whole range of "how many clients are selected" appears to be covered by these instances.

Although most solutions are 'small', we also have quite a few mid-size to large solutions:

On the whole, I think these instances are balanced enough to serve as our (initial) prize-collecting benchmarks.

[N-Wouda]

I'm going to remove the PC-CVRP instances. They're so small that benchmarking on them is basically useless since the solutions are optimal most of the time, and the PC-VRPTW instances already appear to be good enough for evaluating our prize-collecting work.

[N-Wouda]

This took a bit of work, but on my end I'm happy with these instances and the initial BKS. @leonlan @wouterkool can you have a look at this thread and let me know what you think?

[leonlan]

I just realized that DIMACS is not “round to 1 decimal” but “truncate on 1st decimal”.

I think the DIMACS objective is really confusing because of this detail (which I forget about every time). My suggestion is to change the convention to round the distances to the nearest integer.

[N-Wouda]

That's a good catch. I've updated the text. Our DIMACS rounding function is OK though, so the BKS presented here are fine (the error is only in the text).

[N-Wouda]

I've updated this several times with new BKS. Now that PyVRP/PyVRP#213 is merged, I will also merge this since it's already become the default benchmark instance set.