either infeasible or unbounded message+equality constraints

[dicaranx]

Dear Johan, 

I am having some troubles with a dmpc optimization problem. I am getting a message of "Either infeasible or unbounded". Suppose I have different agents which give feasible solutions to a problem with inequality and equality constraints, then a convex combination of these solutions should be also feasible if sets and costs are convex (a known result in cooperative dmpc). 

I solved the problem with cost function 0 to discard infeasibility and had no problem. So I suppose it has to be with unbounded issues, nevertheless I don't see why should my cost function had that problem, I only have linear and quadratic terms.

I try gurobi and cplex optimizers, both with the same result.

I send you the example.

Thanks.

[Johan Löfberg]

Looks infeasible to me (when you generate solutions using an objective, you end up in a state where it is infeasible). Putting a break in the call to gurob i when inf or unbounded occurs

[sol{1},err{1}] = controller{1}{{[P.x_k(:,k);P.u_k(:,k)],c(k:k+P.Hp-1,:),S.d(k:k+P.Hp-1,:)',Xr(:,mod(k+P.Hp-1,P.Hp)+1),Us}};
15  result = gurobi(model,model.params);
K>>
K>> result = gurobi(model,model.params)

result =

          status: 'INF_OR_UNBD'
     versioninfo: [1x1 struct]
       itercount: 0
    baritercount: 0
       nodecount: 0

K>> model.obj=model.obj*0;
K>> model.Q=model.Q*0;
K>> result = gurobi(model,model.params)

result =

          status: 'INFEASIBLE'
     versioninfo: [1x1 struct]
       itercount: 0
    baritercount: 0
       nodecount: 0

[dicaranx]

Hello Johan, 

thanks for your reply. Nevertheless, if it is infeasible, why I get successful results if I multiply the objective function by 0 (in line 100 when defining controller{j}) ?. 

[Johan Löfberg]

Bacuase your MPC controller isn't recurisively feasible I guess. When you simulate using the MPC controller with no objective, you appen to move along a trajectory where feasibility is retained, but when you simulate with the real controller, you lose feasibnility

Easily checked, create both controllers, and then when you run into problems with the real controller, make a call to the controller without objective, and it should then say infeasibility

[dicaranx]

I did what you suggested and get that infeasible result. I still don't know why, theoretically it has been proved that this algorithm is recursively feasible if starting from a feasible solution and if you have a feasible control action to append at the end of the next warm start. If you see the for the first p iteration, the three subproblems are feasible, then a convex combination of their solutions should be also feasible for the same time instant k but in p+1. 

If you noticed in line 67, I have equality constraints (besides the terminal equality constraint), if I check the following sum given a feasible solution it should be equal to 0 due to the constraint. For the controller with the zero objective I get

K>> S.E*Cu*sol{2}{1}(:,k)+S.Ed*S.d(k,:)'

ans =

  -1.0595e-14

   1.7764e-15

   6.3665e-12

   5.6843e-14

            0

            0

            0

  -3.4106e-13

            0

  -2.8422e-14

            0

and for the same constraint but with the real controller (the feasible solution in the round before the error) I get 

K>> S.E*Cu*sol{2}{1}(:,k)+S.Ed*S.d(k,:)'

ans =

  -1.0595e-14

   1.7764e-15

            0

  -3.6794e-07

            0

            0

   1.6266e-05

  -3.4106e-13

            0

  -2.8422e-14

  -7.7511e-07

then, when I do the combination of all the solutions of the real controller, the same equality constraint that should sum 0, gives

ans =

  -3.4401e-15

            0

   1.1369e-13

  -1.2142e-07

   7.9012e-12

   2.0373e-10

   5.3679e-06

   7.5666e-08

   1.2733e-11

   1.5153e-07

  -6.3459e-07

Given the order of the results, I don't know if this satisfy the exact equality constraints at p=2, even when theory says that the signal Us (line 167) should remain feasible. 

Other thing I checked was the terminal constraint. If I take the difference between the terminal state given by the solution and the target state it is 0. But if I compute the terminal state by applying manually the sequence of inputs of the solution, then the difference is not 0 but an approximate value. 

Could be a numerical issue due to the equality constraints?.

[Johan Löfberg]

crank up the verbose flag and look at the solver display to see if it displays anything that could indicate numerical issues

[dicaranx]

Dear Johan, 

I have checked the model and all the parameters are correct. The problem is feasible in a centralized fashion. Regarding feasibility, I have two questions: 

i) How can I check in yalmip which constraint is being violated?

ii) I notice that for some states the target value in the terminal equality constraint is always the upper bound (i.e., xt = xmax). In addition, I have equality constraints for some inputs (e.g., F*u = z). Can the aforesaid lead to infeasibility?.  

Thanks for your help.

[Johan Löfberg]

Introduce slack variables and see which slacks have to be non-zero for the solution to be feasible

In models with tight conbstraints solved iteratively, it is easy to run into problems. The solver returns a solution which is marginally infeasible, and then that solution is used, creating a marginally infeasible problem, and things go bad