PySCIPOpt icon indicating copy to clipboard operation
PySCIPOpt copied to clipboard

PySCIPOpt 4.2 (SCIP 8) incorrectly reports a second-order cone program is infeasible

Open rileyjmurray opened this issue 3 years ago • 6 comments

I'm a project maintainer of CVXPY. We've found that PySCIPOpt version 4 or higher results in failing tests. The current plan for us to fix this is to only allow PySCIPOpt version 3.X. Here's the most up-to-date snapshot of the CVXPY repository before we implement that fix: https://github.com/cvxpy/cvxpy/tree/dc92bad111c7f1304c6d4a1bd02f64c5e888a581.

The data for the failing test case is here (with axis=0): https://github.com/cvxpy/cvxpy/blob/dc92bad111c7f1304c6d4a1bd02f64c5e888a581/cvxpy/tests/solver_test_helpers.py#L319-L350 SCIP claims the problem is infeasible, but that is not actually the case. The optimal objective is about -1.9321.

The code above looks messy compared to normal CVXPY code. Here's a cleaned up-version

import cvxpy as cp
import numpy as np

x = cp.Variable(shape=(2,))
c = np.array([-1, 2])
root2 = np.sqrt(2)
u = np.array([[1 / root2, -1 / root2], [1 / root2, 1 / root2]])
mat1 = np.diag([root2, 1 / root2]) @ u.T
mat2 = np.diag([1, 1])
mat3 = np.diag([0.2, 1.8])

expr = cp.vstack([mat1 @ x, mat2 @ x, mat3 @ x])  # stack these as rows
t = cp.Constant(np.ones(3, ))
objective = cp.Minimize(c @ x)
con = cp.constraints.SOC(t, expr.T, axis=0)

prob = cp.Problem(objective, [con])

The canonicalized problem expresses constraints as A @ x + b \in K where K is a product of three 3D second-order cones. The augmented matrix [A | b] is as follows:

array([[ 0. ,  0. ,  1. ],
       [-1. , -1. ,  0. ],
       [ 0.5, -0.5,  0. ],
       [ 0. ,  0. ,  1. ],
       [-1. ,  0. ,  0. ],
       [ 0. , -1. ,  0. ],
       [ 0. ,  0. ,  1. ],
       [-0.2,  0. ,  0. ],
       [ 0. , -1.8,  0. ]])

We also define the 3D second-order cone as { (t1, t2, t3) : t1 >= sqrt(t2 ** 2 + t3 ** 2) }.

Let me know if there's anything I can do to help diagnose this problem on the SCIP / PySCIPOpt side!

rileyjmurray avatar Apr 03 '22 23:04 rileyjmurray

Surely this is a bug in the C code, not the python wrapper, true?

BrannonKing avatar Aug 24 '22 17:08 BrannonKing

@BrannonKing yes, almost certainly. I posted here since I can only provide the MWE in Python (and even then, using CVXPY as a wrapper).

rileyjmurray avatar Aug 24 '22 18:08 rileyjmurray

It would be good if you can let SCIP print the problem and see if it arrives there correctly. If it does, post the CIP file here. That may make it easier for us to reproduce the problem.

svigerske avatar Aug 24 '22 18:08 svigerske

I've uploaded the .cip file for the above CVXPY formulation. (Renamed to .txt so github allows the attachment.) cvxpy_socp_3.txt

SteveDiamond avatar Sep 22 '22 21:09 SteveDiamond

Hi @svigerske, @matbesancon ran the file Steven posted and found no problem in SCIP. Help investigating this on pyscipopt's side would be much appreciated.

rileyjmurray avatar Sep 23 '22 12:09 rileyjmurray

Can we see the log you get from running SCIP/PySCIPOpt? That should include all the info on what dependencies of SCIP you have linked in.

svigerske avatar Sep 23 '22 19:09 svigerske

The comment https://github.com/scipopt/scip/issues/22#issuecomment-1256707910 sounds like this has been fixed on the CVXPY side.

svigerske avatar Oct 18 '22 07:10 svigerske