Unsupported constraint only in infeasibility analysis

I have a JuMP.jl model that I solve using Gurobi. For some cases (data) it is infeasible.

I am using MathOptAnalyzer.jl to generate an infeasibility report:

MathOptAnalyzer.analyze(MathOptAnalyzer.Infeasibility.Analyzer(), model; optimizer=optimizer)

However, it fails with

MathOptInterface.UnsupportedConstraint{MathOptInterface.ScalarAffineFunction{Float64}, MathOptInterface.Interval{Float64}}("")

How can this happen?

It’s easy in real life to figure out why the model is infeasible, just by constructing the constraints one-by-one.

For example, if the only element in the model is JuMP.@variable(m, x >= 0), then it cannot be INFEASIBLE.

And the infeasibility is closed related to the nature of the problem. If the modeler knows what the physical constraints are about, then eliminating infeasibility should be easy.

I do not agree with the statement that this is easy.

But nevertheless, my question was why is there suddenly an unsupported constraint during the IIS computation?

Hi @ohmsweetohm1,

If you’re using Gurobi, you don’t need MathOptAnalyzer to compute the conflict.

Just follow: Solutions · JuMP

It should be enough for something like:

compute_conflict!(model)
if get_attribute(model, MOI.ConflictStatus()) == MOI.CONFLICT_FOUND
    iis_model, _ = copy_conflict(model)
    print(iis_model)
end

Do you have a reproducible example for your error? It’s probably because Gurobi doesn’t support interval constraints natively, so they’re bridged, and we’re not bridging them correctly in the analyser (this is a bug).

I’ve opened an issue: Inner Optimizer does not use bridges · Issue #32 · jump-dev/MathOptIIS.jl · GitHub

1 Like

So MathOptAnalyzer is not dispatching to compute_conflict! if the solver supports it?

Nope. I’ll open a feature request: Use solver's IIS if supported · Issue #63 · jump-dev/MathOptAnalyzer.jl · GitHub

MathOptAnalyzer (and MathOptIIS) are still somewhat experimental. They still need a bunch of work before a v1.0 release

1 Like