Starting solutions are passed to Gurobi for vars that have no value set

[4er4er4er]

Even though no values have been assigned to the variables, Gurobi 10 reports that it received a MIP start:

ampl: model multmip3.mod; data multmip3.dat;
ampl: option solver gurobi;
ampl: option gurobi_options 'outlev 1';
ampl: solve;

Gurobi 10.0.1: Set parameter LogToConsole to value 1
...
User MIP start did not produce a new incumbent solution
User MIP start violates constraint R24 by 400.000000000
...
Root relaxation: objective 2.247650e+05, 36 iterations, 0.00 seconds (0.00 work units)
Another try with MIP start

Only values that appear in the nl file's x section should be sent as starting values to Gurobi. If there is no x section, then no starting values should be sent. A few tests suggest that the ASL interface to Gurobi 10 works this way, but that the MP interface sends a starting value of 0 to Gurobi for each variable that does not appear in the x section.

Sending only the starting values that the user actually set (and that were included in the nl file) is necessary for the proper operation of Gurobi's partial MIP start feature. Also, in the case where no starting values are set by the user, Gurobi needs to know that, so it can skip MIP start processing, and so that the user is not confused by "MIP start" messages.

[mapgccv]

Fixed in b25593ebbdab521c0f06ed7b783d7673a2185651

[glebbelov]

Added partial MIP start in Gurobi. TODO also in other solvers.

[mapgccv]

@glebbelov, should we amend backend-mip.h to avoid calling AddPrimalDualStart for MIP problems? Gurobi silently ignores the values (https://www.gurobi.com/documentation/10.0/refman/pstart.html#attr:PStart) , but other solvers might have a problem with them.

[glebbelov]

@mapgccv this sounds reasonable

[glebbelov]

Partial MIP start in Gurobi released in 20230426