VariablePrimalStart should use PStart
In
https://github.com/jump-dev/Gurobi.jl/blob/9720c804e8f52ff316652ca5d1818e7f198a59a6/src/MOI_wrapper/MOI_wrapper.jl#L3435
we use Start, which is for feasible MIP solutions:
https://docs.gurobi.com/projects/optimizer/en/current/reference/attributes/variable.html#attrstart
See instead PStart:
https://docs.gurobi.com/projects/optimizer/en/current/reference/attributes/variable.html#attrpstart
It isn't sufficient to set this here because of:
we'd need to do it in optimize!
@simonbowly:
This isn't clear. Do you mean "either as a primal-dual starting point through both PStart and DStart, or as a primal-dual basis through both VBasis and CBasis, then"? If I set only PStart (and not DStart), will LP presolve be disabled?
Yes it refers to setting all PStart+DStart values, i.e. a valid LP warm start per the first paragraph:
If you set PStart values for every variable in the model and DStart values for every constraint ...".
But just so I'm clear: you opened this issue following our discussion of start points for NLP models (though that's not mentioned above). Are we on the same page there? If so, the relevant paragraph is the one discussing that:
For non-convex (MI)QCP and (MI)NLP models, this defines the starting point for certain primal heuristics. If you set PStart values for every variable in the model, then these heuristics will be more likely to converge to feasible points in the vicinity of the given starting point.
I guess my question is:
JuMP doesn't have a way to distinguish MIP starts from PStarts, and we may or may not have complete primal solutions.
So we'll probably set both Start (just the variables that have VariablePrimalStart set) and PStart (all variables, either VariablePrimalStart, or 0 projected onto the bounds). But I don't want to set PStart for every solve if it is going to disable resolve.
As above, this won't disable presolve (that happens only if DStart is set as well, and Gurobi.jl doesn't set this). But you will get warnings from the solver "Warning, invalid warm-start solution discarded" for MILPs and LPs to indicate that simplex cannot use the incomplete start.
Since JuMP doesn't distinguish, one option would be to only set PStart values before optimize! if the model has nonlinear or quadratic constraints and a start value is given for every variable in the model. We'd also need to fill in starts for the resultant variables we introduce for nonlinear constraints.
This is tricky when it's not clear what the user intended to do. I guess there's a risk that a start intended as a feasible MIP start might actually be a negative for performance of the NLP heuristics. Similarly, a partial infeasible point intended as an NLP start might cause the solver to spend a lot of time trying to complete/repair it (as a MIP start).