PySCIPOpt 4.2 (SCIP 8) incorrectly reports a second-order cone program is infeasible
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!
Surely this is a bug in the C code, not the python wrapper, true?
@BrannonKing yes, almost certainly. I posted here since I can only provide the MWE in Python (and even then, using CVXPY as a wrapper).
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.
I've uploaded the .cip file for the above CVXPY formulation. (Renamed to .txt so github allows the attachment.) cvxpy_socp_3.txt
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.
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.
The comment https://github.com/scipopt/scip/issues/22#issuecomment-1256707910 sounds like this has been fixed on the CVXPY side.