CPLEX Error 3003: Not a mixed-integer problem when calling relative_gap on a pure LP model

[MAJegham]

This is similar to #355. If all the variables of the JuMP model are continuous the model solves correctly but some post-solve methods might fail. Here, relative_gap() errors with CPLEX Error 3003: Not a mixed-integer problem.

Used versions :

CPLEX.jl v0.9.3 cplex 12.10 JuMP v1.0.0 Julia v1.7.2

 What I launched :

called : relative_gap(model) after successfully solving the model (optimize!())

 What I expected :

Getting the relative gap of the solved model

What happened :

CPLEX Error 3003: Not a mixed-integer problem

Reproducible example :

relative_gap_NotMIPError.jl.txt

[odow]

CPLEX only supports relative_gap if the problem is a MIP.

[odow]

I guess we could do something like

function MOI.get(model::Optimizer, attr::MOI.RelativeGap)
    _throw_if_optimize_in_progress(model, attr)
    p = Ref{Cdouble}()
    ret = CPXgetmiprelgap(model.env, model.lp, p)
    if ret == CPXERR_NOT_MIP
        return NaN
    end
    _check_ret(model, ret)
    return p[]
end

[MAJegham]

Thanks for the answer! In fact, that might be a convenient solution.

Not ideal though, as it does not differentiate situations where an erroneous NaN is returned from situations where the NaN is due to the CPXERR_NOT_MIP. Anyway, if the solution is retained, behavior needs to be documented not to have people wonder why they're getting NaN gaps.

P.S. Is there a function like is_mip(model) ? can this be done by checking the types of the problem's variables ?

[mlubin]

The error seems more appropriate than returning NaN. In this case the error had the intended effect of forcing the caller to understand the contexts in which relative_gap is computed by the solver.

[odow]

Actually, the correct solution is to throw the new MOI. GetAttributeNotAllowed error (to be released in MOI v1.5.0), with the message that the problem is not a mixed-integer problem.

x-ref: https://github.com/jump-dev/MathOptInterface.jl/pull/1892