My model is a QCP. The quadratic constraint involved is coded in GAMS very simply as follows
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 GAMSMOSEK 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:
First I thought perhaps CPLEX does not recognize the =c= constraints. So, I replaced the equation with
Then, I get this error:
This doesn't make sense to me  the secondorder 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 secondorder cone constraints in GAMS using CPLEX as the solver? My backup plan is to use MATLABMOSEK 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 
I think this might be relevant here, apologies if not. answered 21 Feb '14, 15:06 Iain Dunning 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

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, answered 21 Feb '14, 14:32 fbahr ♦ 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",
(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
Oh boy, my bad – I meant to write:
My point, though, was [or was supposed to be] that
aren't equivalent. [ And
(22 Feb '14, 11:14)
fbahr ♦
PS, on second thought [or, more precisely, after rereading 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 sqring. 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:
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,
(22 Feb '14, 18:17)
fbahr ♦
showing 5 of 8
show 3 more comments
