MOSEK "both conic and nonlinear" error

[4er4er4er]

MOSEK rejects models that contain a quadratic objective and a quadratic constraint:

var x {1..7} >= 0;
minimize qobj: sum {j in 1..7} x[j]^2;
subj to qconstr: sum {j in 1..7} x[j]^2 <= 1000;

The error message is:

MOSEK 10.0.43:  Error type 3, MSK_RES_ERR_MIXED_CONIC_AND_NL(1501): 
The problem contains both conic and nonlinear constraints.

A user ran into this problem when trying out MOSEK as an alternative to Gurobi (which does not reject such models). Is this an unavoidable limitation in MOSEK? If so, we would have to advise a different formulation, perhaps minimizing z subject to z >= the objective expression.

[glebbelov]

Running with cvt:socp=0 sends the model as-is and Mosek converts it to conic internally:

ampl: option mosek_options 'cvt:socp=0';         
ampl: solve;
MOSEK 10.0.43:   cvt:socp = 0
MOSEK 10.0.43: optimal; objective 7.084598309e-26
0 simplex iterations
7 barrier iterations

But in general, yes this is a documented limitation. We could add an oputomatic transformation.

Or, we can hope that Mosek improves the automatic conversion, because currently it only works for 'standard conic forms' of quadratic constraints, while Gurobi also accepts xy >= 1 for example. In this model, all they would need to do is run the conversions despite receiving conic constraints.

[4er4er4er]

It appears that MOSEK can handle this example as it is originally stated, but that MP's default is to transform it to a different form, which MOSEK can't handle. Is that right?

If yes, then ideally MP would detect when this case occurs, and would suppress the transformation in this case. But is that possible? There might be complications that I don't appreciate.

[glebbelov]

Done for this example. But:

This example is a convex QCP, not a SOCP. That's pretty much all that Mosek can handle; it seems unable to recognize SOCP from quadratics even in standard form.

Thus, to enable proper SOCP models with quadratic objective, we need to extract the objective's QP terms into a cone.

[4er4er4er]

A different user sent another example, which failed with both cvt:socp=1 and cvt:socp=0. I think you have fixed this now, but here's a simplified version in case it is useful for testing:

var x {1..7} >= 0;
var y >= 0;

minimize obj: sum {j in 1..7} x[j]^2;

subj to conQ: sum {j in 1..7} x[j]^2 <= y^2;
subj to conL: sum {j in 1..7} x[j] + y = 75;

Using the MOSEK 20231117 driver, cvt:socp=1 gave the "both conic and nonlinear" error:

MOSEK 10.0.43:   cvt:socp = 1
MOSEK error 1501: The problem contains both conic and nonlinear constraints.
MOSEK 10.0.43:  Error type 3, MSK_RES_ERR_MIXED_CONIC_AND_NL(1501): The problem contains both conic and nonlinear constraints.

With cvt:socp=0, MOSEK instead rejected the problem with a "not convex" message:

MOSEK 10.0.43:   cvt:socp = 0
MOSEK error 1293: Constraint ''(1) is not convex. Q should be positive semidefinite in a constraint with finite upper bound.
MOSEK 10.0.43:  Error type 3, MSK_RES_ERR_CON_Q_NOT_PSD(1293): The quadratic constraint matrix is not PSD.

[4er4er4er]

Also I noticed that MOSEK 20231117 rejected this model:

var x {1..7} >= 0;
var z >= 0;

minimize obj: z^2;
subject to conQ: sum {j in 1..7} x[j]^2 <= 1000 + z^2;

subj to conL: sum {j in 1..7} x[j] = 75;

Gurobi accepts this model, but MOSEK 20231117 reports a "not convex" error with either cvt:socp=1 or cvt:socp=0. MP might be missing this case as something that can be converted to a conic.

[glebbelov]

The last example is non-convex.

The previous new example is SOCP and not a convex QC. So it still did not work, until I added objective function presolve (extract QP terms into an aux SOC).

However this is done only in simple cases as above. For cases such as minimize x^2 + y^2 - 0.1*x*y it does not, and then, with any proper SOC constraints, Mosek fails. However now whenever Mosek reports failure due to non-convex QC, we warn the user as follows:

WARNING:  "Nonconvex QC"
  Mosek reported the problem as nonconvex QCP.
If the constraints are in fact Second-Order Cones,
make sure they have standard SOCP forms, and
the objective is linear by moving the
quadratic terms into auxiliary SOC constraints.
See mp.ampl.com/model-guide.html.
MOSEK 10.0.43:  Error type 3, MSK_RES_ERR_CON_Q_NOT_PSD(1293): The quadratic constraint matrix is not PSD.

This all goes towards user convenience: actually, SOCP assumes a linear objective. However, general conic optimization assumes any convex objective. Full convenience would be achieved with log/exp expression presolve into exp cones. Then our logistic regression Colab/Streamlit example could use a single model for IPOPT and Mosek.