add test for cvrp demo

[guimarqu]

No description provided.

[codecov]

Codecov Report

Merging #358 into master will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #358      +/-   ##
==========================================
+ Coverage   75.87%   75.89%   +0.02%     
==========================================
  Files          51       51              
  Lines        3751     3755       +4     
==========================================
+ Hits         2846     2850       +4     
  Misses        905      905              

Impacted Files	Coverage Δ
src/Algorithm/colgen.jl	81.45% <100.00%> (+0.24%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2fb8b7e...a3e46a4. Read the comment docs.

[rrsadykov]

Actually, the demo is not correct, the lower bound becomes larger after cut separation than the optimal solution (784.0)

[guimarqu]

Actually, the demo is not correct, the lower bound becomes larger after cut separation than the optimal solution (784.0)

At the root node or deeper in the branching tree ?

[rrsadykov]

Sorry, I messed up 748 and 784. The lower bound seems to be ok. However, it would be good to test a smaller instance and solve it to optimality. The root lower bound depends on the solver used. Also, if I put 785 as initial upper bound, optimal solution 784 is missed.

[rrsadykov]

I made a smaller instances with 15 clients :
A-n16-k3.vrp.zip

Here is the optimal solution for it:

Best found solution of value 504 : 
Vehicle 1 of type 1 : depot -> 12 -> depot, demand = 21, time = 58
Vehicle 2 of type 1 : depot -> 6 -> 3 -> 2 -> 13 -> 7 -> 1 -> depot, demand = 90, time = 180
Vehicle 3 of type 1 : depot -> 5 -> 10 -> 15 -> 9 -> 11 -> 4 -> 8 -> 14 -> depot, demand = 95, time = 266

For this smaller instance, the optimal solution is also missed

[rrsadykov]

See the message above

[guimarqu]

See the message above

It looks like we don't check if the solution returned by the LP restricted master is integer.
cvrp.pdf

[guimarqu]

Coluna finds the optimal solution but we never test if the RM solution projected on original variables is integer.

  <it= 15> <et=36.63> <mst= 0.00> <sp= 0.01> <cols= 1> <DB=  494.0000> <mlp=  504.0000> <PB=504.0000>
  <it= 16> <et=36.65> <mst= 0.00> <sp= 0.01> <cols= 0> <DB=  504.0000> <mlp=  504.0000> <PB=504.0000>
[ Info: Dual bound reached primal bound.
	MC_2000059= 0.5
	MC_2000072= 1.0
	MC_2000118= 0.5
	MC_2000123= 0.5
	MC_2000148= 0.5
*******
	x[1,(1, 2)]= 1.0
	PricingSetupVar_sp_2= 3.0
	x[1,(1, 6)]= 1.0
	x[1,(1, 7)]= 1.0
	x[1,(1, 13)]= 2.0
	x[1,(1, 15)]= 1.0
	x[1,(2, 8)]= 1.0
	x[1,(3, 4)]= 1.0
	x[1,(3, 14)]= 1.0
	x[1,(4, 7)]= 1.0
	x[1,(5, 9)]= 1.0
	x[1,(5, 12)]= 1.0
	x[1,(6, 11)]= 1.0
	x[1,(8, 14)]= 1.0
	x[1,(9, 15)]= 1.0
	x[1,(10, 12)]= 1.0
	x[1,(10, 16)]= 1.0
	x[1,(11, 16)]= 1.0
Node is already conquered. No children will be generated

[rrsadykov]

I did not see any change to check the projected solution for integrality

[guimarqu]

@rrsadykov It was a trash commit. Should we check integrality of the projected solution at each iteration ?

[rrsadykov]

yes, in Bapcod we check on every iteration.

[guimarqu]

Subproblem infeasibility is broken in column generation. I'll fix it in another PR.

[guimarqu]

It was broken before the merge of cut callback into master