heuristic/warm-start solutions may be infeasible

[chriscoey]

if a solver tells us that a warm-start or heuristic solution is infeasible, we should fix that.

there could be a bug in the feasible solution construction code. or if the issue is that conic solutions are epsilon infeasible, we could use primal cone projections to recover a feasible solution (using some of the same code as dual cone projections)

[mlubin]

Something's broken with the MIP warmstarts:

WARNING: Ignoring partial starting solution. Cbc requires a feasible value to be specified for all variables.

That means Pajarito isn't giving Cbc a complete vector.

[chriscoey]

Is it possible to get that message if you give a full vector that's infeasible? Or are the dimensions necessarily wrong?

On Aug 26, 2016 12:37 PM, "Miles Lubin" notifications@github.com wrote:

Something's broken with the MIP warmstarts:

WARNING: Ignoring partial starting solution. Cbc requires a feasible value to be specified for all variables.

That means Pajarito isn't giving Cbc a complete vector.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mlubin/Pajarito.jl/issues/95#issuecomment-242785628, or mute the thread https://github.com/notifications/unsubscribe-auth/AJq0k-KaKb6LnCTxc25H4cUDUQR7ZJ1yks5qjxYsgaJpZM4I-myz .

[mlubin]

@chriscoey, means there are NaNs in the starting point: https://github.com/JuliaOpt/Cbc.jl/blob/456175aa56d087e975805ef0eed82569f6659e8a/src/CbcSolverInterface.jl#L176

[chriscoey]

ah ok. i expected there to be bugs in the warm starts. will work on it soon

On Fri, Aug 26, 2016 at 2:31 PM, Miles Lubin notifications@github.com wrote:

@chriscoey https://github.com/chriscoey, means there are NaNs in the starting point: https://github.com/JuliaOpt/Cbc.jl/blob/ 456175aa56d087e975805ef0eed82569f6659e8a/src/CbcSolverInterface.jl#L176

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mlubin/Pajarito.jl/issues/95#issuecomment-242815030, or mute the thread https://github.com/notifications/unsubscribe-auth/AJq0k3lxFbKrBySVcr_VpvvY8JkL0tdsks5qjzDrgaJpZM4I-myz .

[mlubin]

Could be worth adding an option on whether to pass a solution to the MIP solver. This way we can run an experiment and measure how much it actually helps.

[chriscoey]

ok for this remember we need to be looking at the output of the solvers on larger problems to make sure the heuristic solutions work

[chriscoey]

ok often we are getting MIP solver readouts like MIP start violates constraint R67010 by 0.00 in one case I saw the violation was 0.08

so there must be a bug in the solution construction

[chriscoey]

OK so now I'm printing MIP solver output on the tests. On "solver test 2": MIP start violates constraint R8 by 1.00 Hopefully that will help me diagnose the issue.

[mlubin]

That's a big violation

[chriscoey]

Yup, should have been looking at MIP printout earlier

[chriscoey]

actually, my mistake, that was simply because I was setting start = 0 so i could calculate initial cut infeas the easy way. I no longer set start on variables initially, and don't try calculating cut infeas the first time.

that means I no longer get any mip start violations from the test set

[mlubin]

Did that also resolve the 0.00 violations?

[chriscoey]

but that's not good. I'm still getting it on the large problems. mostly 0.00, but I just found one with MIP start violates constraint R42002 by 0.02

[chriscoey]

so I don't have an easy way to figure out what the bug is

[mlubin]

figure out which constraint is R42002

[chriscoey]

can I get gurobi to tell me?

[mlubin]

no, find out which constraint in JuMP has index 42002

[mlubin]

or 42003 if gurobi is zero-based

[chriscoey]

@mlubin so the only constraints that are violated by mip starts are cuts that were added at the end of the previous iteration.

could gurobi be referring to an old MIP start? or is it necessarily referring to the one that I passed in with JuMP most recently?

[chriscoey]

why would it say both of the following:

MIP start did not produce a new incumbent solution
MIP start violates constraint R882 by 0.02

If there is one MIP start, it wouldn't check to see if it is incumbent if it is infeasible, right?

Could that suggest that there are multiple MIP starts and it's not talking about the one passed in by JuMP?

[mlubin]

Does gurobi start out with a solution that matches the objective value of the MIP start we're giving it?

[chriscoey]

the original code wasn't handling heuristics/warm-starts properly. glad we caught this. see PR #125

[chriscoey]

haven't seen any issue here on the examples i've been running. so I'm going to close. reopen if solver says mip start is infeasible