MOSEK IIS hard to interpret

[Paulnkk]

Hey :)

Is your feature request related to a problem? Please describe. From my point of view, the MOSEK IIS in cvxpy is hard to interpret since it is not clear which particular constraints and variables are causing infeasibility.

Describe the solution you'd like Mapping constraints to the IIS generated by MOSEK in order to see which constraints may cause infeasibility. I think gurobipy provides an IIS which is very nice and easy to interpret.

Describe alternatives you've considered I am using the following code to generate an IIS: prob.solver_stats.extra_stats["IIS"] and get the output:

{9: array([ 0.00000000e+00, -0.00000000e+00,  0.00000000e+00,  0.00000000e+00,
        0.00000000e+00,  0.00000000e+00,  4.12227004e-08,  0.00000000e+00,
        0.00000000e+00]), 16: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 30: array([ 0.00000000e+00,  0.00000000e+00,  0.00000000e+00,  0.00000000e+00,
        0.00000000e+00,  0.00000000e+00,  0.00000000e+00, -0.00000000e+00,
        0.00000000e+00, -0.00000000e+00, -0.00000000e+00,  0.00000000e+00,
        5.60445911e-07,  0.00000000e+00, -0.00000000e+00, -0.00000000e+00,
       -0.00000000e+00, -0.00000000e+00, -0.00000000e+00, -0.00000000e+00,
       -0.00000000e+00, -0.00000000e+00, -3.23255633e-08,  3.24847773e-08,
       -0.00000000e+00]), 34: array([-0.00000000e+00, -0.00000000e+00, -0.00000000e+00, -0.00000000e+00,
       -0.00000000e+00, -0.00000000e+00,  4.12227004e-08, -0.00000000e+00,
       -0.00000000e+00]), 38: array([-0., -0., -0., -0., -0., -0., -0., -0., -0.]), 43: 0.0, 48: 0.0, 53: 0.0, 58: 0.0, 63: 0.0, 68: 0.0, 73: 0.0, 78: 0.0, 83: 0.0, 88: 0.0, 93: 0.0, 98: 0.0, 21: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 26: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 238: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 242: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 246: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 250: array([0., 0., 0., 0., 0., 0., 0., 0., 0.]), 114: array([0., 0., 0., 0.]), 131: array([0., 0., 0., 0.]), 148: array([0., 0., 0., 0.]), 165: array([0., 0., 0., 0.]), 182: array([ 3.34106847e-08, -3.33310776e-08, -2.11087866e-09,  9.25907323e-10]), 199: array([0., 0., 0., 0.]), 216: array([0., 0., 0., 0.]), 233: array([0., 0., 0., 0.])}

I think this IIS is not optimal since it is not clear what the keys and values in the dict are referring to. Here is a tiny example of a gurobipy IIS (which is referring to another problem). Please assume here that the decision variable with gurobipy is initialized as follows:

plus_r_t = {t: m.addVar(vtype=GRB.CONTINUOUS, name=f"plus_r_{t}") for t in range(T)}

and the tiny IIS is:

The following constraint(s) cannot be satisfied:
R0: plus_r_0 < -1.0
Variable bounds causing issue: plus_r_0

In the gurobipy IIS, we can see the variable and referred constraint which is causing problems here. I have to say that I am not sure if this could be even resolved within cvxpy since I am not sure what cvxpy receives from MOSEK and if it is even possible to map constraints (which is great to see while debugging which algebraic constraints are actually implemented) to this IIS to generate an output which is similar to gurobipy IIS

Thanks and best regards

Additional context

[aszekMosek]

MOSEK does not return an IIS but "only" a Farkas infeasibility certificate. So yes, it may not be optimal in the sense of not being irreducible. But in the first place you should filter it for small values and only take those positions which are sufficiently well bounded away from zero.

I don't know what the dict is that you receive but I presume it should be some duals forming the certificate.

More about it from Mosek point of view in:

https://docs.mosek.com/latest/pythonapi/prob-def-linear.html#primal-infeasible-problems

https://docs.mosek.com/latest/pythonapi/debugging-infeas.html#locating-primal-infeasibility

https://docs.mosek.com/modeling-cookbook/linear.html#infeasibility-in-linear-optimization

https://themosekblog.blogspot.com/search?q=farkas

The procedure employed by MOSEK to report the cause of primal infeasibility, for example in the MOSEK infeasibility report, is to go through the dual values, see which ones are sufficiently nonzero, and report their corresponding constraints/bounds.

[SteveDiamond]

@aszekMosek thanks for clarifying. @Paulnkk the dictionary keys are constraint ids (constraint.id)