WIP: MOI

[odow]

My guess is that this will change a lot by the final form, and once we play around with implementing more wrappers.

This is now in fairly robust form. It passes virtually every MOI test (with the exception of some conic ones that aren't supported i.e. SOC, EXP etc).

• Warm starts are dealt with by storing a warm start vector in the Model object and calling immediately prior to mipopt solves (as suggested here). Closes Warm start solution silently discarded when has_int=false #117
• Adds a logfile keyword to redirect log. Closes How to do "cplex.setout(ofstream)"? #42
• Supports interval sets (with a test for solving twice gives different objective values #76). Closes range constraint (two-sided) support  #52
• Re quad interface. Now wrap only the low-level functions and push everything through MOI which should clarify Inconsistent quad interface compared to Gurobi.jl #37
• Status codes follow MOI convention which clears up Document solver status codes #16

Still to do:

• callbacks

[odow]

@joaquimg what are your thoughts on this approach (and shouldn't you be asleep)?

[joaquimg]

I like it, as you saw, I was brainstorming with myself yesterday. My only problem with the Dictis that after deleting a variable one would have to loop the entire Dict. But the Array has the problem of possibly growing a lot. And a linked list might be slow to access a single element.
You could keep going with dicts and I got for arrays and then we compare, the interface are similar anyways...

[joaquimg]

[solved] do you have a better name for: getconstraintlist(map::ConstraintMapping, ::MOI.ScalarAffineFunction{Float64}, ::MOI.EqualsTo{Float64}) = map.equal_to ?
You already had constraint_storage better indeed.

[joaquimg]

I have a second question, I think adding constraints and variables, one by one might be slow, but I haven´t benchmarked yet... Planning to do that soon.

[joaquimg]

I did the comparison for Xpress:
https://gist.github.com/joaquimg/5dbaf83e7555b94d79f4d01f8ed53119

It is a 10x difference!

can you do it for CPLEX and/or Gurobi?

[odow]

That's still only half a milisecond to add 1000 variables though...

[mlubin]

I was thinking that solvers could skip these mappings by matching up the constraint reference number with the variable reference number, since multiple bounds per variable are not allowed.

[odow]

But can't I add a lower bound and a separate upper bound? Just not two upper bounds?

[mlubin]

You can add a separate lower bound and upper bound. You can't add two upper bounds. The wrapper could store a variable attribute vector with the possible bound statuses per variable:

• No bounds
• Lower bound only
• Upper bound only
• Lower and upper bound, separately
• Lower and upper bound via EqualTo
• Lower and upper bound via Interval

You can check if a ConstraintReference{SingleVariable,GreaterThan} is valid by checking the bound flag of the corresponding variable (only if lower bound only, or lower and upper separately).

[joaquimg]

Do you think it is useful to have "No bounds" and "Lower and upper bound, separately"? I think they are just consequence of the others.

[mlubin]

I meant for this list to be mutually exclusive so you can have a single vector that identifies the status of the bounds.

[joaquimg]

Why do we need variable_mapping and variable_references, cant we just use keys(variable_mapping)?

[joaquimg]

What about people that use CPLEX.jl directly? Should this be a new package since there are so many changes? I was thinking about first implementing a simple MOI and then update the solver low level API. Whats in you mind?

[odow]

I just moved everything out of the way for now. The new ccall methods I'm prepending cpx_. I'll probably keep all the old methods as they were.

[odow]

Okay this is in fairly robust form. @joehuchette did you have any ideas about callbacks?

[joehuchette]

I don't think we've settled on how callbacks fit into MOI yet. Are they broken on this branch?

[odow]

Okay I just reenabled the old code. For now the old MPB compatible CplexSolver has been renamed to CplexMPBSolver. It really makes sense to split these out into separate packages though. A CPLEX.jl that contains the low-level wrapper. A MathOptInterfaceCPLEX.jl with CplexMOISolver(), and MathProgBaseCPLEX.jl with CplexMPBSolver()

[odow]

Closing in favor of #181