[Bug report] The optimizer object produces NaN

[Dan Pan]

Dear Johan,

I recently met a NaN problem with "optimizer" object when playing with MPC.

I followed the tutorial of "implicit MPC" to make a controller with "optimizer" and "gurobi"

However, when I call some input values, it gives out NaN. I successfully circumvent the problem by rounding the input into 14(1 less than MATLAB 'double') significant digits[i.e. controller(round(x_in, 14, 'significant'))]. I'm wondering if you have met this problem before, and if there's other ways to solve the problem.

I hereby attach the controller and the input

• call "controller(x_estimated)" will result in NaN.
• call "controller(round(x_estimated,14,'significant'))" will give good result.

Thanks for your reading.

Best regards,

Dan

[Johan Löfberg]

No bug, the problem is infeasible

>> [~,errorcode] = controller(x_estimated)

errorcode =

     1

[Johan Löfberg]

and I note that that the solver isn't even called but YALMIP detects infeasibility already during problem compilation.

If you believe that is incorrect, you would have to supply the complete model for analysis

[Dan Pan]

Dear Johan,

Thanks for the rapid reply.

I got the reason why it turns out to be infeasible: 

When playing MPC, a common case is that we are playing along the state limit. The system dynamics(in the no-noise deterministic case) would guide the state beyond the limit (state limit+epsilon) which is due to the imprecise calculation between the floating-point values. This will result in infeasible initial conditions for the next MPC cycle. It's a typical but not obvious artifact when playing with MPC. I think it's worth mentioning in the tutorial of MPC for the readers if you have time. :)

Thank you very much.

Best regards,

Dan

[Johan Löfberg]

Yes, I assumed that was your case. (a common mistake is to include a constraint on initial state x(k), which makes no sense as x(k) already is given: I see I have that in the example, should be -5<=x{k+1}<=5)

[Dan Pan]

Dear Johan,

Very glad to communicate with you! 

All the best to you and YALMIP!

Best regards,

Dan 

[Dan Pan]

Dear Johan,

I found another artifact with similar problem. See the attachment.

Here's how to trigger the problem:

• % This will give errorcode 12:
  [u,errorcode] = controllerMPC(x_estimated)
  
• % This will run without error:
  [u,errorcode] = controllerMPC(x_estimated+(0.000001)*ones(4,1)) %generate a neighbor of x_estimated
• % This will also run without error:
  [u,errorcode] = controllerMPC(x_estimated-(0.000001)*ones(4,1)) %generate a neighbor of x_estimated at different direction
• % This will again also run without error:
  [u,errorcode] = controllerMPC(round(x_estimated,10,'significant')) %round x_estimated

The problem is a MPC problem with one additional convex quadratically constraint on the states(that controls the range of the vehicle from the depot). That is really a singular point that doesn't violate any constraint.

Best,

Dan

[Johan Löfberg]

and this is incorrect? you generate problems in the vicinity of infeasibility. if you perturb in a certain direction, it might become more feasible, same thing might happen if it rounds towards the same direction, it might fall into the region where cplex find a feasible enough solution

[Dan Pan]

Dear Johan,

Thanks for your rapid reply.

I think that is incorrect, for the reason that as the problem is convex, the feasible region should be convex as well. The above-mentioned example shows that the infeasible region is a singular point, which makes the feasible region non-convex.

The uploaded controller used "gurobi" as the QP solver. Just now I changed the solver to "cplex" as you suggested, and the error was gone... 

Anyway thank you very much. All the best to you and YALMIP.

Best,

Dan

[Johan Löfberg]

this has nothing to do with convexity or anything. This is a tolerance and numerical precision issue. You have a problem instance which infeasible, or very close to infeasible, and for points around that point, you will have different behavior due to tolerance issues

however, I cannot reproduce your results. To begin with, there is no optimizer in the file called controllerMPC, it is called controller

The first two case returns infeasible (1), and this is detected already by yalmip (and no solver is called so error code 12(which only cplex and maybe gurobi returns is weird), hence absolutely trivially infeasible in the sense that you have a bound constraint x >= positive. third and fourth case are solved to optimality, 

[Dan Pan]

Dear Johan,

Thanks for your reply.

Did you use the data from the very begging named "[Bug Report]controller_and_artifactInput_DanPan.mat", or use the data named "[Bug_report]0501.mat" which I uploaded today? In today's upload, there is an object called "controllerMPC".

Thanks.

Best,

Dan

[Johan Löfberg]

Used the wrong file

with the new file, all cases leads to a solution with objective  4.37054202e+06 (although I terminated the first case, gurobi runs forever but it has the correct solution if you look at the display)

[Johan Löfberg]

correction, gurobi actually returns code 12 if I let it run, and says unbounded in display, which makes no sense as both primal and dual are 4.37e6 in the last iteration

[Dan Pan]

Dear Johan, 

Thanks for your reply. So in this case, you suggest to neglect the error code[unbounded], right? So according to your past experience, do you have any idea in which cases we could dismiss the error code? 

Btw, I found another artifact which I spent the whole night to solve, I would explain in anther thread. That is something concerning the nonlinear solver with the [default] second order cone simplification.

Best regards.

Dan

[Johan Löfberg]

Well, you should recognize that you've managed to stumble upon a bug in gurobi. How you proceed after that is up to you

It might be that the solver is fooled by the relatively large value on the objective (although it is reasonable, and it works in the other cases). Try to scale the objective with a factor /1000 and see if anything changes

[Dan Pan]

Dear Johan,

Thank you for the reply. I'll follow your advice.

I just posted another thread. I wish you could have a look if you have time.

Best,

Dan