setVarUB! in MPB interface broken about mosek.jl

[mlubin]

I don't think these model modification routines have ever worked, see #17

[IainNZ]

Ahh, ok. They are just going to keep using Gurobi in mean time.

[IainNZ]

The error confuses me because it says m.varmap[i] on that line, so not sure where the comparison is coming from

[ulfworsoe]

set(constr|var)(UB|LB) should work now (in head revision).

[mlubin]

Mosek is still failing JuMP's tests here:

[probmod] Testing problem modification basics
     - With solver GurobiSolver
     - With solver CplexSolver
     - With solver MosekSolver
putconboundlist: [1],Int32[1]
    Int32[1]
    [-1.0e30]
    [3.0]
0 1 3 4
  Failure   :: (line:-1) :: With solver MosekSolver :: Expected: 2.0 ≅ 0.0
    getValue(x) --> roughly(0.0,TOL)
  Failure   :: (line:-1) :: With solver MosekSolver :: Expected: 5.0 ≅ 2.0
    getValue(z) --> roughly(2.0,TOL)
  Failure   :: (line:-1) :: With solver MosekSolver :: Expected: 503.2 ≅ 201.0
    getObjectiveValue(m) --> roughly(201.0,TOL)
putconboundlist: [1],Int32[1]
    Int32[1]
    [-1.0e30]
    [3.0]
0 1 3 4
  Failure   :: (line:-1) :: With solver MosekSolver :: Expected: 3.0 ≅ 1.0
    getValue(x) --> roughly(1.0,TOL)
     - With solver ClpSolver
     - With solver GLPKSolverLP
     - With solver IpoptSolver
WARNING: Solver does not appear to support adding variables to an existing model. Hot-start is disabled.
WARNING: Solver does not appear to support hot-starts. Model will be built from scratch.
     - With solver ECOSSolver
     - With solver SCSSolver
Out of 104 total facts:
  Verified: 100
  Failed:   4

[ulfworsoe]

I'll take a look.

[ulfworsoe]

All MathProgBase tests should pass now. There are still failing JuMP tests; one that looked like a sign problem, one that was a precision problem, some GECO problems that was probably the solver failing to find a solution/certificate and some I couldn't determine.

[mlubin]

Thanks for taking a look. We can address the issues one by one, but I'm still getting a failure on the problem modification test (same as above).

[ulfworsoe]

That should be fixed now. 11 Fails remaining in Jump tests.

[ulfworsoe]

Remaining Fails in JuMP:

• [model] Test solving an LP (Min): sign problem. I am not sure if the test is wrong or the interface is wrong, but all mathprogbase tests on this subject should pass now.
• [model] Test vectorized model creation: Precision problem, probably due to MIP solutions having feasibility/optimality tolerances in the order of 1e-2. Also, not that testing on solution values (especially) for MIP can be unreliable.

[mlubin]

The dual tests should be correct; the mathprogbase tests aren't as comprehensive as the JuMP tests (and all of the other solvers pass both mathprogbase and JuMP).
CC @joehuchette for the tolerance issue

[ulfworsoe]

I think all sign errors have been fixed in Mosek.

I am not entirely certain about signs on infeasibility rays.

[joehuchette]

The tolerance issue should be an easy fix

[mlubin]

Is there a Mosek parameter we can set to tighten tolerances and get the test passing?

[ulfworsoe]

In general, look for any double parameter containing _TOL_.
For the integer problem, I suggest you try to look at MSK_DPAR_MIO_TOL_ABS_RELAX_INT, MSK_DPAR_MIO_TOL_REL_GAP and MSK_DPAR_MIO_TOL_ABS_GAP.

Tolerances may not fix the problem: The solution of different solvers may all be within tolerances,but still differ substantially. If you know the analytical optimal solution, you can test that each constraint is within tolerance, that each integer variable is within tolerance and that the objective less than the analytical objective+eps.

[mlubin]

Hopefully we're not testing a problem with multiple optimal solutions

[mlubin]

This should be fixed by 5ddc4f8