Second-order cone constraints

[Josh Taylor]

Greetings,
I have some second-order cone optimization I'd like to do (mixed
integer). Mosek can solve SOCPs, and I think CPLEX does as well (or at
least uses a SOCP solver for QCPs). Is there a particular way to
format SOCP constraints in AMPL so that the solver does not produce
nonconvex quadratic errors? It seems that although these solvers can
solve SOCP's, AMPL may not be able to communicate that the constraints
are in fact SOCP. Thanks ahead for any help.

Josh

[Robert Fourer]

Currently there are some AMPL-solver interfaces that scan the objective and
constraint expression trees to see if all nonlinear terms are quadratic. If
so, they save up the coefficients of the quadratic terms and pass them to
the solver along with the coefficients of the linear terms. But still it is
up to the solver to detect quadratic problems that are SOCPs and to apply
appropriate methods to solve them. Thus AMPL's support for SOCPs is
solver-dependent.

With CPLEX, a problem having constraints in the form "sum {j in 1..n} x[j]^2
<= y^2, y >= 0" is recognized as an SOCP. Some examples of forms that are
and aren't recognized is given in
www.ampl.com/MEETINGS/TALKS/2010_11_Austin_SD48.pdf, beginning at slide 32.
(Also I am attaching the relevant files.) Also, simple rotated cones in the
form "sum {j in 1..n} x[j]^2 <= y * z, y >= 0, z >= 0" are recognized. With
MOSEK, I am not sure what the current situation is, but MOSEK might also
recognize certain AMPL quadratic problems as SOCPs.

I am working with a research student on a project to automatically recognize
and transform a variety of problem types that are equivalent to SOCPs. This
gets to be quite difficult once you go beyond the simplest examples, though.

Bob Fourer
4...@ampl.com