CVX can not Solve the Convex Problem for Specific Constant Values


#1

Hello,

I am trying to solve the following problem, however for specific combination of constant values, CVX can’t find the solution (output is NaN).

function [zm,xp] = Schedule (x,z,xID,xID2,xL,xU,zL,zU,Pevbar,Pabar,lam,price,N_SH,T_H,mu,alpha)

cvx_begin quiet

variables xp(N_SH)   zm(N_SH) 
minimize( (alpha) * (price) * zm  +  (mu/2) * square_pos(norm(zm-z+Pevbar-Pabar+lam,2)) )

subject to
xp(1) == x(1); 
for scont = 2:N_SH
    xp(scont)== zm(scont-1) * T_H + xp(scont-1)* xID(scont-1) + x(scont)* xID2(scont);
end
xp(2:N_SH) <= xU(2:N_SH);
xL(2:N_SH) <= xp(2:N_SH);
zm <= zU;
zL <= zm;

cvx_end

I really appreciate if you tell me how to deal with this.


(Mark L. Stone) #2

Depending on the inputs, your program could be infeasible, which would produce NaN,for the CVX variables, but no error message. You should not use the quiet option when you are having difficulties, because that prevents the solver output and CVX status from being shown. Please re-run without quiet and see what it shows.

If mu < 0 (which I am guessing it is not), you would get a Disciplined convex programming error, and the solver would never be called.

If re-running without quiet is not sufficient to clarify for you what the difficulty is, then feel free to post a complete (with all input data) , reproducible (preferably small, if possible) problem, along with the output from running it.


#3

Thank you Mark for your response.
Depending on \mu and \alpha values, the result is NaN or feasible. \mu>0. This is actually the x-update step of ADMM. \mu is the penalty factor and alpha is the cost function weighting factor. When I increase \mu or decrease \alpha, it converges.
I will re-run it without quiet, and let you know.


#4

Mark,

It says: “Status: infeasible”.
I am not sure where this infeasibility is coming from, as when I change \alpha a bit, it converges (it is infeasible for alpha \in [50,65], but feasible for other values! ). In my code, \alpha and \mu are scalar values, and all the others are vector.


(Mark L. Stone) #5

You haven’t provided a reproducible problem, so I can only speculate. If indeed you have one problem which is declared feasible, and another problem declared infeasible, with the only difference between them being the values of alpha and mu, neither of which enter the constraints, then at least one of the following must be true.

  1. You made a mistake on problem entry
  2. You have a numerically bad problem, such as very large magnitude coefficient, or a very wide-magnitude span of coefficients, or other numerically bad things which are causing the solver to make mistaken conclusions. It is possible for large coefficients in the objective function to couple into the constraints when pre-solve or other manipulations are performed by the solver. That can cause even a trivially obvious to the human eye feasible problem to be declared infeasisble by a solver, and the converse.
  3. There is a bug in CVX and/or the solver

Look to see whether the solver says it encountered numerical difficulties.
Try a different solver and see what the results are.
If you used CVX 3.0beta, then try CXV 2.1, because CVX 3.0beta is known to have bugs

What is the range of magnitudes of non-zero coefficients in your model, for both the reported feasible and infeasible cases?


#6

Mark,

I just realize that depending on the computer I run my code on, the result is way different. As I said, I am using ADMM to solve a multi-gent based optimization problem. If I run the code on my laptop, CVX fails to solve that problem for all the the agents, however on my desktop, it fails only for some of the agents. Please notice that the agent’s objective function, constraints, and input data are homogeneous.


#7

Mark,

Is here there any way I can send you the input data and the code?


(Mark L. Stone) #8

Whatever you can post on the forum.


#9

Mark,

Please find the MATLAB file and input data on the following google drive link
https://drive.google.com/drive/folders/15JrWVhg3maCThygHBQxNWNmXhu0nIlOv?usp=sharing


(Mark L. Stone) #10

You have a very large span of magnitudes for input data. That may cause numerical difficulties for solvers, and lead to different behaviors in even slightly different computing environments. So you should try to improve scaling, so that most input data is within a small number of orders of magnitude of 1. And don’t use quiet option of CVX, then you will be able to see the solver output, including warning messages. Also try different solvers if you can.


#11

Thank you Mark for your prompt response. I will try to improve scaling.
By “different solvers”, do you mean SeDuMi and SDPT3? or another solver package like YALMIP?


(Mark L. Stone) #12

I was referring to SeDuMi and SDPT3. If you have access to MOSEK or Gurobi, and a CVX version which can use them, they are likely to be better able to deal with precarious numerics.

As for scaling, you also don’t want the optimal objective value ti be too big (e.g, magnitude 1e5 or greater), as they may cause difficulties. You may not be able to do it because it substantively changes the objective function and resulting argmin, but if your objective function winds up still being too big, not squaring (all) the norms might make the problem easier to solve reliably.


#13

Mark,
Thank you so much for your help. I scaled the inputs, and the code works.