Heterogeneous vehicle type

[wouterkool]

This PR:

• Implements heterogeneous vehicle types and uses it to support heterogeneous vehicle capacities
• This PR supersedes Heterogeneous capacity #203

• Partially implements Heterogeneous fleet #188 (does not support heterogeneous cost).
• Adds and passes relevant tests.
• Has well-formatted code and documentation.

Benchmark

On VRPTW.

This PR (c25917c; job ID 2670926; 10x seeds/1h runtime with configs/vrptw.toml):

 Avg. objective: 333197.6 (min: 333086, max: 333324)
Avg. iterations: 123194.3 (min: 107088, max: 130939)

Notes:

• It is essential that you add a test when making code changes.
  This keeps the code coverage level up, and helps ensure the changes work as intended.
• When fixing a bug, you must add a test that would produce the bug in the master branch, and then show that it is fixed with the new code.
• New code additions must be well formatted. Changes should pass the pre-commit workflow, which you can set up locally using pre-commit.
• Docstring additions must render correctly, including escapes and LaTeX.

[wouterkool]

Summarizing, I think there are a few leftover issues which I think should be non-blocking. Can we finish this PR and put this in a seperate issue?

These I think we should definitely address:

• How to read heterogeneous instances and solutions
• How to print heterogeneous solutions

These I am happy with the current situation but we could change if you feel strongly

• Whether or not to check all vehicle types for empty after an improving move (now yes, unlikely to make a difference)
• Whether using VehicleType = int vs std::optional<size_t> (now int with -1 unassigned)
• Whether to keep assignedVehicleTypes as attribute (now yes)
• Whether to allow empty routes in the solution (now no)
• Which argument order to use for VehicleType (now capacity, num_available)
• Whether we can do transformRoutes as a separate function or in the constructor (now seperate function, suggestions welcome)
• Whether we can remove make_heterogeneous helper (not necessary I think)

[N-Wouda]

• How to read heterogeneous instances and solutions
• How to print heterogeneous solutions
• Whether we can remove make_heterogeneous helper (not necessary I think)

Agree, the first two are most important. I proposed above that we revert our printing to current main. I also want to get rid of make_heterogeneous because it seems unnecessary once we can read heterogeneous instances. We similarly do not modify ProblemData instances for other things; we just create a new instance and read() that.

• Whether or not to check all vehicle types for empty after an improving move (now yes, unlikely to make a difference)

I think the current implementation is fine and much simpler than the initial one.

• Whether to keep assignedVehicleTypes as attribute (now yes)

I want to get rid of this. A client has neighbours, sure, but how is a client assigned a vehicle type? A client is part of a Route, which has a vehicle (type). Something like client2route makes more sense to me than assignedVehicleTypes. Those assignments could then, hypothetically, be used to determine the vehicle types 'of' each client.

• Whether to allow empty routes in the solution (now no)

No is OK, but I'm really not sure why this was in the scope of this PR in the first place.

• Which argument order to use for VehicleType (now capacity, num_available)

I'd like to go back to the original, but this isn't worth the discussion to me.

• Whether we can do transformRoutes as a separate function or in the constructor (now seperate function, suggestions welcome)

Removed this in the other PR.

[wouterkool]

@N-Wouda thanks for the contributions, feel free to propose an alternative for the assignedVehicleTypes and can you then do a benchmark run? Please merge it when you think it's ready.

[N-Wouda]

I'm going to commit a few more changes after reading this again, but I'm OK with this. Let's copy the reading stuff over to a new issue and merge this after the benchmark completes OK.

Benchmark should be in tomorrow morning.

[N-Wouda]

Avg. objective: 333197.6 (min: 333086, max: 333324)
Avg. iterations: 123194.3 (min: 107088, max: 130939)

Slightly better than #240, which was the last benchmark I could find. Good!