solver capabilities table

[mlubin]

We need a table (either here or in MathProgBase docs) with the capabilities of each of the different solver objects and the names of their corresponding packages.

[mlubin]

It would actually be nice to make this programmatic as well. Choosing default solvers is getting a little hairy... we should be able to request a default solver from MathProgBase given a list of the required capabilities.

[IainNZ]

I wonder what does AMPL do without a solver specified...

Baking in a capability matrix seems fine to me though.
Would it get as specific as user cuts support, lazy constraint support, etc?

[mlubin]

The default solver for AMPL is MINOS (??): http://www.ampl.com/DOWNLOADS/ "The default solver will be MINOS"

I think the easiest way to build the capability matrix programmatically is by checking which MathProgBase tests pass. This might be a bit of an overhead, so we could cache or hardcode the result. We don't have any MathProgBase tests for callbacks, but we could.

[mlubin]

Oops, haven't addressed choosing default solvers.

[joehuchette]

Looks like you meant to close this already.

[IainNZ]

Nope, still need the programmatic part of it I think

[joehuchette]

Lol whoops. Is there a better way to do this than try/catch the MathProgBase tests? That seems really brittle.

[mlubin]

This doesn't need to block the release, untagging.

[mlubin]

With the recent changes in MPB, we can now do this programmatically using method_exists.

[joehuchette]

This would be a nice addition.

[joehuchette]

How would you update this table programmatically? Could we hook into Pkg.update or Pkg.build to recompute and recache this?

[mlubin]

I was thinking that this could just be computed at runtime given an instance of an AbstractMathProgModel object.

[joehuchette]

That's true, if it's just method_exists calls it should be pretty cheap.

[mlubin]

The only issue I see with method_exists is that some feature might be poorly implemented by a solver and we don't yet want people to try using it.

[joehuchette]

Well then it probably shouldn't be in a release for a JuliaOpt package :)

[joehuchette]

We could also require solvers support a classes_supported method at the MPB level, and then it would just be a table lookup and completely unambiguous. We could even have a fallback that does the method_exists test.

[mlubin]

That introduces an extra level of complexity in that we have to separately define what the problem "classes" are, which could be a bit hairy. Let's just go with method_exists, and if there's a feature that is poorly supported (like, QP in Clp/Cbc would be), then the solver can print a warning.

[joehuchette]

I think the problem classes are pretty well-defined, at least at this point. We can probably wait until this actually is an issue in practice before we worry about it, though.

[karanveerm]

As Miles said at jump-dev/Convex.jl#32, for the conic interfaces it makes sense to implement 2 functions

# returns an array of cones supported by the solver
get_supported_cones(...)

# input is either a single cone such as :Free or an array like [:Free, :ExpPrimal]
# output is a boolean
supports_cones(...)

We are already checking if we support the cone in each solver:
https://github.com/JuliaOpt/ECOS.jl/blob/master/src/ECOSSolverInterface.jl#L190
https://github.com/karanveerm/SCS.jl/blob/master/src/SCSSolverInterface.jl#L333
https://github.com/JuliaOpt/Mosek.jl/blob/master/src/MosekConicInterface.jl#L2

We might as well expose this nicely.

As of now, Convex.jl has an ugly check here:
https://github.com/cvxgrp/Convex.jl/blob/master/src/solver_info.jl

As for default solver, as of now Convex checks for ECOS, SCS, Gurobi and Mosek in that order and throw an error if none are found.
I was planning to write a function for Convex that takes in the array of cones and returns some solver that

1. the user has installed
2. can support those cones

Perhaps, it would make sense to have that functionality in MPB?

[joehuchette]

I agree that this would be nice to have at the MPB level. We've been toying around with a way to construct the lookup table programmatically, but the easy thing to do would just be to hardcode everything in MPB (i.e. not require solvers to implement anything new, at least at this point).

[mlubin]

For the conic interface it makes a lot of sense just to ask solvers to implement supported_cones().

[mlubin]

I think this can be largely addressed with traits at the MPB level.

[mlubin]

This discussion is completely stale after the transition to MOI. It could still be interesting to be able to identify which solvers are able to solve a given model (especially with bridges in the mix), but if someone is interested in this, it should be brought up in a new issue.