# QCP modeling question

 1 My model is a QCP. The quadratic constraint involved is coded in GAMS very simply as follows eq8(j).. w(j) =c= u(j) + v(j);  This solves without errors using MOSEK. What I understand from reading GAMS documentation, this represents $$\sqrt{u_j^2 + v_j^2} <= w_j$$ However, I would like to use CPLEX, because my institution does not have the MOSEK license (and in order to use GAMS with MOSEK, I need a GAMS-MOSEK link license, which we don't have either). When I use this =c= notation and solve this model using CPLEX, I get the following error message: Unknown row type (5). *** Problems when setting up Cplex model.  First I thought perhaps CPLEX does not recognize the =c= constraints. So, I replaced the equation with eq8(j).. sqr(u(j)) + sqr(v(j)) =l= sqr(w(j));  Then, I get this error: QCP status(0): Cplex Time: 0.00sec (det. 0.00 ticks) *** CPLEX Error 5002: Q in %s is not positive semi-definite.  This doesn't make sense to me - the second-order cones are certainly PSD. Perhaps squaring both sides is the error, however modeling it directly with a square root gives me an error as well. hmm. My question is: can GAMS/CPLEX handle =c= constraints? Otherwise, do you have a recommendation for how I model second-order cone constraints in GAMS using CPLEX as the solver? My backup plan is to use MATLAB-MOSEK Fusion, which works fine, but in my opinion it would be oh so much easier just to use GAMS, my "comfort IDE". (I have previously posted a version of this question here, where I also show the full GAMS model) asked 21 Feb '14, 11:41 Andreas 180●2●8 accept rate: 12%

 2 I think this might be relevant here, apologies if not. answered 21 Feb '14, 15:06 Iain Dunning 917●1●4●18 accept rate: 33% This is definitely related, thank you. The RHS of the 'implemented' constraint is still convex, so I am surprised that this works. I suspect GAMS and CPLEX do not speak to each other in =c= terms... I may have a nice weekend with CVX in my basement. Thanks. (21 Feb '14, 16:12) Andreas Yes, its a bit of a trick - a special structure the solver knows about. (21 Feb '14, 16:17) Iain Dunning My replaced constraint (without =c=) is in fact in the format that your 'implemented' constraint is in. The only difference is that my w(j) term is unconstrained. Of course, the original constraint implies that w(j) is nonnegative. When I declare w(j) nonnegative in GAMS, it works beautifully with GUROBI. (CPLEX still gives an error.) Thanks. (21 Feb '14, 16:58) Andreas
 0 IINM, conic constraints require a conic programming (e. g., MOSEK) or NLP solver (e. g., KNITRO). You can read up on GAMS' conic programming support here: CPLEX [on the other hand] generally requires constraints to define convex regions and, – again – IINM, sqrt is a concave function. answered 21 Feb '14, 14:32 fbahr ♦ 4.6k●7●16 accept rate: 13% Thanks for this. The LHS is a Euclidean norm which is convex. (21 Feb '14, 16:20) Andreas Well, while I've to admit that I've actually forgot that "every norm is convex", sqr(u(j)) + sqr(v(j)) most certainly isn't the Euclidean norm. [You probably meant to write: sqrt(u(j)**2 + v(j)**2) =l= w(j); – I'm still not 100% sure, though, that this formulation matches CPLEX's SOCP definition ...but this shouldn't keep you from trying it out.] (21 Feb '14, 17:04) fbahr ♦ I'm afraid I am not communicating well, sorry. First of all, in GAMS language, sqr(x) is square (same as x**2), and sqrt is squareroot... And when I mentioned that the LHS was the L2 norm, I was referring to the first constraint I wrote. I tried using this directly (i.e., sqrt( sqr(u(j)) + sqr(v(j)) ) =l= w(j); ) When this didn't work for me, I squared both sides, which appears to match the CPLEX definition you linked. However, since it gives me an error, I must be wrong somewhere. Works in GUROBI though, per Iain's answer. (22 Feb '14, 09:51) Andreas > In GAMS language, sqr(x) is square (same as x**2), and sqrt is squareroot... Oh boy, my bad – I meant to write: sqrt(u(j)**2 + v(j)**2) =l= w(j); My point, though, was [or was supposed to be] that (1) eq8(j).. w(j) =c= u(j) + v(j); (2) eq8(j).. sqr(u(j)) + sqr(v(j)) =l= sqr(w(j)); aren't equivalent. [Sqr-ing (1) yields u(j)**2 + v(j)**2 - 2*sqrt(u(j)**2 + v(j)**2)*w(j) + w(j)**2 =l= 0; And (2), as given, has a non-PSD Hessian matrix – assuming that w(j)s are variables, otherwise I don't see how CPLEX could possibly complain about that constraint.] (22 Feb '14, 11:14) fbahr ♦ PS, on second thought [or, more precisely, after re-reading the CPLEX doc]: Key for making CPLEX accept your SOCP constraint could be: switching to barrier optimizer. (22 Feb '14, 12:10) fbahr ♦ Yes, I see what you mean by sqr-ing. I just quickly "squared both sides" of the constraint, which clearly was an error. Oops! I'll try to this squaring "correctly" this weekend and see what CPLEX does. I suspect it won't help since it doesn't get rid of all square roots. I will also try forcing the barrier method. Thanks for your comments! (22 Feb '14, 13:17) Andreas 1 I seem to think that (2) implies (1). For CPLEX, the example file "socpex1.m" mentions: The constraint "xi in SOC" for xi=(xi[1], ..., xi[ni]) is xi[1] >= |(xi[2],...,xi[ni])| where |.| denotes the Euclidean norm. In CPLEX such a constraint is formulated as -xi[1]^2 + xi[2]^2 + ... + xi[ni]^2 <= 0 xi[1] >= 0 This is precisely (2). As a summary, the "=c=" notation works for SOCPs when using GAMS/MOSEK. The "square both sides of the constraint" approach works for GAMS/GUROBI. Unsure about GAMS/CPLEX. (22 Feb '14, 17:03) Andreas Oh, you are actually absolutely right. From this post, (2) [for w non-neg., u, v free] is supposed to work (using the barrier optimizer) – http://pic.dhe.ibm.com/infocenter/cosinfoc/v12r6/.../topics/cont_optim/qcp/06_SOCPasLagrangian.html (22 Feb '14, 18:17) fbahr ♦ showing 5 of 8 show 3 more comments
 toggle preview community wiki

By Email:

Markdown Basics

• *italic* or _italic_
• **bold** or __bold__
• image?![alt text](/path/img.jpg "Title")
• numbered list: 1. Foo 2. Bar
• to add a line break simply add two spaces to where you would like the new line to be.
• basic HTML tags are also supported

Tags:

×191
×51
×2
×2