Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VariablePrimalStart should use PStart #591

Open
odow opened this issue Nov 28, 2024 · 5 comments
Open

VariablePrimalStart should use PStart #591

odow opened this issue Nov 28, 2024 · 5 comments

Comments

@odow
Copy link
Member

odow commented Nov 28, 2024

In

ret = GRBsetdblattrelement(model, "Start", Cint(info.column - 1), grb_value)

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

@odow
Copy link
Member Author

odow commented Nov 28, 2024

It isn't sufficient to set this here because of:

image

we'd need to do it in optimize!

@odow
Copy link
Member Author

odow commented Nov 28, 2024

@simonbowly:

image

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?

@simonbowly
Copy link
Collaborator

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.

@odow
Copy link
Member Author

odow commented Nov 28, 2024

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.

@simonbowly
Copy link
Collaborator

simonbowly commented Dec 1, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants