[RFC] New abstraction for LPQP/Conic/NLP solvers

[mlubin]

New interface is as follows:
For LP/QP/QCQP:

m = LinearQuadraticModel(GurobiSolver(...))
loadproblem!(m, A, l, u, c, lb, ub, sense)
optimize!(m)
stat = status(m)
x = getsolution(m)

For conic:

m = ConicModel(MosekSolver(...))
loadproblem!(m, c, A, b, constr_cones, var_cones)
optimize!(m)
stat = status(m)
x = getsolution(m)

For NLP:

m = NonlinearModel(IpoptSolver(...))
loadproblem!(m, numVar, numConstr, l, u, lb, ub, sense, evaluator)
optimize!(m)
stat = status(m)
x = getsolution(m)

The purpose of this change is to address the confusion of interfaces described in #73. Existing methods are categorized in the new docs as to which interface they belong to. loadconicproblem! and loadnonlinearproblem! are renamed to loadproblem!, and getconicdual is renamed to getdual. I'd like to minimize any other changes we make to the interface at this point (#87, #84, #79, loadquadraticproblem! from #73). Just implementing the proposed breaking change will be enough work and will make those changes easier to do in the future.

CC @tkelman @madeleineudell @IainNZ @joehuchette @dpo @ulfworsoe @carlobaldassi @JackDunnNZ @yeesian

[joehuchette]

How does the quadratic part of LinearQuadraticModel work?

[mlubin]

Same as now, no changes. You use loadproblem! to provide the linear part.

[mlubin]

Adding a quadratic objective/constraint part to loadproblem! won't be a breaking change, I think, so I'd rather put that off.

[ulfworsoe]

From my end of things it looks good. It will be a bit more work to implement, but it will make underlying mappings simpler and the interface clearer.

Question for the AbstractConicModel: getunboundedray() and getinfeasibilityray() seems to only be defined for AbstractLinearQuadraticModel. Do getsolution()/getduals() for AbstractConicModel return rays or certificates?

[mlubin]

@ulfworsoe, getdual on a conic model is already documented to return a dual ray in the case of infeasibility. My intention would be for getsolution to do the same for primal rays, though it's not documented at this point (nobody has needed this functionality yet).

[mlubin]

I've updated a few solvers (ECOS, SCS, Cplex, Gurobi, GLPK) and have JuMP passing tests locally. I'm going to plan on merging and doing the massive version bumps early next week. Thanks to @carlobaldassi, many packages using MPB set 0.4 as an upper bound in REQUIRE, which means they won't immediately break when MPB 0.4 is tagged. The ones that don't have this will immediately break. The fixes should be very easy (< 5 lines diff) though.

@ulfworsoe, will you have a chance to look at the corresponding updates to Mosek.jl? That one might be a bit more complex since it's the only solver which implements all three interfaces.

[ulfworsoe]

Already on it.

[ulfworsoe]

I think there is a file "LinearQuadratic.jl" missing in the mpb0.4 branch.

[mlubin]

Oops, pushed.

[mlubin]

@ulfworsoe, you can take a look at the PRs referenced above to see the changes involved.

[mlubin]

Given that the current changes are mostly implemented and seem manageable, I'm open to suggestions/votes for other breaking changes as long as we're at it. We don't do this very often.

[ulfworsoe]

Edit: Never mind. Stupid question.

I am splitting the three models into separate structures and sets of functions. I would like to drop conic quadratic constraints from the LinearQuadraticModel, but that means that some quadprog tests fail. Are support for conic quadratic constraint mandatory? And if not, how should I disable the test for that case?

[mlubin]

@ulfworsoe, it's not mandatory, but we'll have to do some extra work in JuMP to handle this case in order to avoid breaking existing models. Won't be too difficult to do though.

[ulfworsoe]

Ok. That means that I can actually implement the nonlinear and the model in the same object.

[ulfworsoe]

@mlubin, I have updated the Mosek interface. Changes are in the mpb0.4-impl branch of Mosek.jl. It should pass at least the tests I threw at it (MathProgBase tests plus a few more).