degradation of initial solution

[Gorniker]

We are trying to use vrp-cli (v. 1.22) to improve some vrp solutions, but the resulting solutions are often incorrect in capacity constraints. The problem can be described with this example: the first run

vrp-cli solve pragmatic problem.json -m matrix.json -o solution_1.json

gives correct solution in solution_1.json (max load in tour is equal to the capacity of the vehicle), but the second run

vrp-cli solve pragmatic problem.json -m matrix.json -i solution_1.json -o solution_2.json

gives incorrect solution in solution_2.json (max load in tour is bigger the the capacity of the vehicle). We have already tried different init-size values, but it didn't help. The files from example: example.zip

[reinterpretcat]

Hi, thanks for reporting!

So far sounds like an issue in init solution logic related to reload functionality. Anyway, I'll check it.

[reinterpretcat]

I think I found the reason of the problem: when initial solution is constructed from user provided, inserted jobs are not analyzed whether they should be promoted to locked as normally solver does for specific types (e.g. reload/break). If the job is not locked, it can be removed from the solution which might cause such issues.

Looking how I can fix it in nice way..

[reinterpretcat]

I've added a fix in the master branch, will be available in the next release

[Gorniker]

Thanks a lot

[Gorniker]

Hi. I've tested the last release and the solver gets correct solution on the represented example. But it still gets incorrect solutions on problems with more than two points. The file with the minimal failing example (with the same sequence of runs): example_2.zip

[reinterpretcat]

Actually, there is no really issue (well, maybe some missing validation rule), just a bit misuse of a tag: try to specify different values for each reload and use the corresponding ones in the init solution (should be added automatically).

Root cause: as the same tag is used on each reload, the solver assigns the same reload job multiple times and removes them together incorrectly later when processing initial solution. This can be fixed by throwing some validation error in init reader or make it smarter.