Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rileyjmurray opened this issue Apr 3, 2022 · 7 comments

Comments

@rileyjmurray
Copy link

rileyjmurray commented Apr 3, 2022

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!

@BrannonKing
Copy link

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

@rileyjmurray
Copy link
Author

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

@svigerske
Copy link
Member

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.

@SteveDiamond
Copy link

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

@rileyjmurray
Copy link
Author

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.

@svigerske
Copy link
Member

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
Copy link
Member

The comment scipopt/scip#22 (comment) sounds like this has been fixed on the CVXPY side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants