osqp / osqp-python

Python interface for OSQP

Python interface for OSQP

Python wrapper for OSQP: the Operator Splitting QP Solver.

The OSQP (Operator Splitting Quadratic Program) solver is a numerical optimization package for solving problems in the form

minimize        0.5 x' P x + q' x

subject to      l <= A x <= u

where x in R^n is the optimization variable. The objective function is defined by a positive semidefinite matrix P in S^n_+ and vector q in R^n. The linear constraints are defined by matrix A in R^{m x n} and vectors l in R^m U {-inf}^m, u in R^m U {+inf}^m.

Installation

To install osqp for python, make sure that you're using a recent version of pip (pip install --upgrade pip) and then use pip install osqp.

To install osqp from source, clone the repository (git clone --recurse-submodules https://github.com/osqp/osqp-python) and run pip install . from inside the cloned folder.

Documentation

The interface is documented here.

Packaging

This repository performs the tests and builds the pypi wheels. Conda packages are on conda-forge.

osqp-python's Issues

Obtaining preconditioner matrix from the solver

Is there a way to access the preconditioner matrix S after the Quadratic program has been setup and solved using the python interface for the OSQP solver? I am referring to the D and E matrices mentioned as a part of matrix S in the Modified Ruiz Equilibriation (Algorithm 2, p.649) in the paper here.

https://link.springer.com/article/10.1007/s12532-020-00179-2

Add support to release aarch64 wheels

Problem

On aarch64, pip install osqp-python builds the wheels from source code and then install it. It requires user to have development environment installed on his system. also, it take some time to build the wheels than downloading and extracting the wheels from pypi.

Resolution

On aarch64, pip install osqp-python should download the wheels from pypi

@bstellato , please let me know your interest on releasing aarch64 wheels. I can help in this.

symbol not found in flat namespace '_csc_matrix'

Error importing osqp

System:
MacBook Pro with Apple M2 Max
MaOS Ventura 13.0

python version:
Python 3.9.6

osqp version:
0.6.2.post8

Details
I cloned the osqp/osqp-python repo with tag v0.6.2.post8 and built by running pip3 install .. Installation runs fine.
When I try importing osqp in python3 I get the following error:

>>> import osqp Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Python/3.9/site-packages/osqp/__init__.py", line 5, in <module> from osqp.interface import OSQP File "/Library/Python/3.9/site-packages/osqp/interface.py", line 6, in <module> import osqp._osqp as _osqp # Internal low level module ImportError: dlopen(/Library/Python/3.9/site-packages/osqp/_osqp.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace '_csc_matrix'

Hard to install on Python 3.10 due to missing qdldl wheels

Even though osqp has wheels for Python 3.10 it depends on qdldl which does not.

Apparent non-determinism when using OSQP via CVXPY

Hi,

We are noticing that for some specific Quadratic Programming Problem in CVXPY we are getting two different solutions seemingly randomly.

I have included more context in https://github.com/timothy-nunn/cvxpy-non-determinism which also includes a reproduction of the issue.

We have only observed this issue for this fairly specific set of inputs but have observed the behaviour over multiple operating systems and versions of OSQP.

I will also note that we observe two different logs when running in verbose mode which shows where these two solutions are coming from. One solution is found after 50 iterations and cannot be polished, whilst the other is found after 75 and can be polished:
log.txt

The main questions are:

1. Is this non-determinism expected? Ie are stochastic numerical methods employed in OSQP that would explain these observations.
2. If it is expected, is there a way to eliminate non-determinism in a testing environment?

Cannot install osqp on MacOSX

I am trying to install osqp on MacOSX (v12.5.1).

1 - Trying pip install osqp==0.6.2.post5, fails, here are a few relevant lines from all the output:

Building wheels for collected packages: osqp
Building wheel for osqp (pyproject.toml) ... error
error: subprocess-exited-with-error

running build_ext
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.10/bin/cmake", line 5, in
from cmake import cmake
ModuleNotFoundError: No module named 'cmake'

However cmake is installed with cmake --version of 3.24.3

2 - Following the installation procedure (python3 setup.py install), manages running build_ext but fails later; steps from: https://osqp.org/docs/get_started/python.html

Installed /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/osqp-0.0.0-py3.10-macosx-10.9-universal2.egg
Processing dependencies for osqp==0.0.0
Searching for osqp==0.0.0
Reading https://pypi.org/simple/osqp/
Download error on https://pypi.org/simple/osqp/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997) -- Some packages may not be found!
Couldn't find index page for 'osqp' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.org/simple/
Download error on https://pypi.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997) -- Some packages may not be found!
No local packages or working download links found for osqp==0.0.0

What should I do?

Additional infos:
python3 -V -> 3.10.4

Install fails because of metadata version on Mac OS

I am running Mac OS 13.0.1 and homebrew installed python 3.10.8 on Apple M1.

pip3 install -U osqp
Requirement already satisfied: osqp in /usr/local/lib/python3.10/site-packages (0.6.2.post5)
Collecting osqp
  Using cached osqp-0.6.2.post7.tar.gz (227 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Discarding https://files.pythonhosted.org/packages/06/d8/8119b64ac3d2d27141859c9ed1206de07d259fa0d2147d219786f12f5ae5/osqp-0.6.2.post7.tar.gz (from https://pypi.org/simple/osqp/): Requested osqp from https://files.pythonhosted.org/packages/06/d8/8119b64ac3d2d27141859c9ed1206de07d259fa0d2147d219786f12f5ae5/osqp-0.6.2.post7.tar.gz has inconsistent version: expected '0.6.2.post7', but metadata has '0.0.0'
Requirement already satisfied: numpy>=1.7 in /usr/local/lib/python3.10/site-packages (from osqp) (1.23.5)
Requirement already satisfied: qdldl in /usr/local/lib/python3.10/site-packages (from osqp) (0.1.5.post2)
Requirement already satisfied: scipy>=0.13.2 in /usr/local/lib/python3.10/site-packages (from osqp) (1.9.3)

This problem occurs both under Rosetta2 and for native arm64 codes.

MKL Pardiso error during symbolic factorization -3. (reordering_phase) error_num= -180

Hi, I'm trying to use pardiso but there is a coredump. The demo is simple:

P = sparse.csc_matrix([[ 3.,  2.],
     [ 2.,  3.]]
     )

q = np.array([1.0, 1.0])
A = sparse.csc_matrix([[1.0, 0.0], [0.0, 1.0]])

l = np.array([0.0, 0.0])
u = np.array([100.0,100.0])

qp = osqp.OSQP()
qp.setup(P,q,A,l,u,linsys_solver="mkl pardiso")
qp.solve()

The error message is

ERROR in init_linsys_solver_pardiso: Error during symbolic factorization: -3

Actually when input data is changed, there can be different error messages, the error code can be -2,-3.

I'm trying to figure out what happened but failed. What I find is:

• the default solver is OK

• c interface with the same data is OK

• this function https://github.com/oxfordcontrol/osqp/blob/2846ab19e3ecb2b61eee19559c85761ffaf31eb6/lin_sys/direct/pardiso/pardiso_interface.c#L51 generate a core dump

• input to the function seems good

Publish conda recipe to conda-forge?

Hey, I was wondering if you have considered publishing the conda recipes to conda-forge? That way, people could install osqp directly from conda-forge, and there would be automated infrastructure to keep the recipe up to date (e.g. it is currently at 0.4 while there have been releases 0.4.1 and 0.5).

Adding other channels is sometimes very hard (imagine a firewall that only allows main and conda-forge), and can also complicate package resolution (especially with --strict-channel-priority, which will become the default soon-ish).

OSQP Solver fails on a simple problem while ECOS works

I am linking to a minimal reproducible example I have posted to the cvxpy site.
OSQP runs out of iterations.

Multiple calls to `setup` leak memory

If we call setup multiple times, we get a memory leak. Example:

import osqp, scipy, numpy

solver = osqp.OSQP()

n = 1000

N = 100

for i in range(N):
	A = scipy.sparse.random(n,n,density=0.04,format="csc")
	Q = scipy.sparse.random(n,n,density=0.04,format="csc")

	d = numpy.random.rand(n)

	solver.setup(Q, d, A, l=d, verbose=False)

I would expect that either

• multiple calls to setup are not allowed (raise an error)
• or that no memory leak occurs.

Module 'osqp' has no attribute 'solve'.

I installed version 0.6.2.post0 via pip under Python 3.6 and noticed that there is no stateless solve function in the osqp namespace as claimed in the documentation:

>>> import osqp
>>> osqp.solve
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'osqp' has no attribute 'solve'

Add development package building and deployment

From what discussed in #6 with @mcg1969 it would be very useful to build conda packages for every master build and deploy them to a subchannel. Then, when a tag is applied, we should build and deploy the final version (still automatically) to the standard oxfordcontrol channel.

This would allow us to:

• Deploy automatically up to date releases
• Have users test our code before the final release
• Remove the dependency on the osqp-recipes repository.

Numpy 1.24 breaks builtin type aliases

The numpy people marked aliases of builtin types like np.int as deprecated in version 1.20.0. They are effectively deprecated with version 1.24.0 which was just released.

This leads to a bunch of AttributeErrors, like

AttributeError: module 'numpy' has no attribute 'int'

Your requirements.txt states compatability for numpy >=1.7 and thus causes CI to crash on this (but that's on the numpy folks).

The corresponding pull request is #105 .

This issue is related to cobra issue 1305

pypi's 0.6.1 is actually 0.6.0 (probably?)

I was recently trying the codegen interface and was getting the cmake issue from #41

I verified that my installed version was the tagged 0.6.1 release, e.g. ../my/venv/lib/python3.9/site-packages/osqp-0.6.1.dist-info and was confused, since investigating the source code pertaining to the codegen, the fix from the 0.6.1 release was not present.

Independently, I've also encountered the same issue here: #43
That is, the warning module fix that was also part of the 0.6.0 to 0.6.1 bump is also not present. It seems reasonable to conclude that the source for 0.6.0 was uploaded to pypi instead of 0.6.1.

Here is some source code that triggers both these errors, confirmed from a fresh virtual environment in Python 3.9.0 installing only pip install osqp

import osqp
import numpy as np
import scipy.sparse as sparse

P = sparse.diags([1, 1]) # add .tocsc() if you want to trigger the codegen error instead of the warn error
q = np.zeros(2)

A = sparse.csc_matrix([[1, 1], [1, 0], [0, 1]])
l = np.array([1, 0, 0])
u = np.array([1, np.inf, np.inf])

model = osqp.OSQP()
model.setup(P=P, q=q, A=A, l=l, u=u)

# Solve the program
results = model.solve()
print(results.x)

# Let's instead codegen it
# https://osqp.org/docs/codegen/python.html
model.codegen("simple_qp")
print("Success!")

Support nonzero scaling for C derivatives

Unless we set scaling=0 in the derivative unit tests, we observe different results in derivatives w.r.t. the Python implementation. Some helpful comments from Bart:

It makes sense that scaling has a special effect on the C side since data is rescaled there. However, the C side should unscale the results before returning them. Otherwise the differentiation will not work.

For the backward (adjoint) derivative, the results have the shape of the data. I suspect you just need to unscale them using the unscale_data function. (and use (dP, dq, dA, dl, du) instead of (P, q, A, l, u).

For the forward derivative, I believe you should use unscale_solution over (dx, dy) instead of (x, y).

Integrate new codegen with cvxpygen

Integrate code generation functionalities with cvxpygen @maxschaller would you have time to help with this?

• Adjust function call (no longer needs cmake) https://github.com/cvxgrp/cvxpygen/blob/5aaacdb894354288e2f12a16ca738248c69181c4/cvxpygen/cpg.py#L451
• Edit API to pass codegen parameters https://github.com/osqp/osqp/blob/3c0ffa8de757ec84ecdd3ccf93bee0195557efc7/include/public/osqp_api_types.h#L128-L138

FLOAT and LONG flags in code_generator.py/ codegen()

Original post: OSQP Forum

It was recommended by @goulart-paul that I open an issue in GitHub.

---

Hello,

I am trying to generate C source code with the Python3 tool m.codegen(dir_name, **opts). I would like the resulting code to use float instead of double and to use int instead of long long. However, I believe I am not achieving these settings. The following is a description of the behavior I am experiencing.

Following the documentation, I tried running the following Python3 script:

import osqp

# Allocate problem data and src variable
... 

m = osqp.OSQP();
m.setup(P, q, A, l, u)
m.codegen(src, force_rewrite=True, parameters='matrices', FLOAT=True, LONG=False)

The result is a directory with the correct source code. In fact, I can compile the source code with the rest of my project and correctly solve the QP. However, I believe the type of c_int is long long and the type of c_float is double. I have tested this by printing, for example, as follows
printf( "Test c_int workspace->data->A->i[4] = %d, workspace->data->A->i[4]);
>> Test c_int workspace->data->A->i[4] = 467912
printf( "Test c_int workspace->data->A->i[4] = %lld, workspace->data->A->i[4]);
>> Test c_int workspace->data->A->i[4] = 1

The expected value of workspace->data->A->i[4] is 1. I can cast (int)workspace->data->A->i[4] and then I also get 1 as expected. But I believe this shows me the type of c_int is long long.

Furthermore, here are some lines in the file src/include/osqp_configure.h that seem to have auto-generated with unexpected content. I would expect #define DFLOAT for example.

/* EMBEDDED */
#define EMBEDDED (2)

/* PRINTING */
/* #undef PRINTING */

/* PROFILING */
/* #undef PROFILING */

/* CTRLC */
/* #undef CTRLC */

/* DFLOAT */
/* #undef DFLOAT */

/* DLONG */
#define DLONG

If I try to manually change this osqp_configure.h file, I get some compilation errors from the qdldl library with type mismatches.

I apologize for the long explanation. Any advice on how to correctly use the m.codegen(dir_name, **opts) Python3 method to generate code with the correct float and int typing would be appreciated.

Thank you for your time,

-Victor

TestError on AArch64 :test_issue14 (module.tests.mkl_pardiso_test.mkl_pardiso_tests

When I execute python setup.py test on aarch64, the error is as follows，Does osqp-python support aarch64?
test_issue14 (module.tests.mkl_pardiso_test.mkl_pardiso_tests) ... ERROR in lh_load_lib: Error while loading dynamic library libmkl_rt.so: libmkl_rt.so: cannot open shaect file: No such file or directory
ERROR in osqp_setup: Linear system solver not available.
Tried to obtain it from shared library.
ERROR
test_multithread (module.tests.multithread_test.multithread_tests) ... /home/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/python-3.8.8-l73kggq3ezxridinxkfckv4ddztul6python3.8/multiprocessing/pool.py:265: ResourceWarning: unclosed running multiprocessing pool <multiprocessing.pool.ThreadPool state=RUN pool_size=2>
_warn(f"unclosed running multiprocessing pool {self!r}",
ResourceWarning: Enable tracemalloc to get the object allocation traceback
ok
test_nan (module.tests.non_convex_test.non_convex_tests) ... ok
test_non_convex_big_sigma (module.tests.non_convex_test.non_convex_tests) ... ok
test_non_convex_small_sigma (module.tests.non_convex_test.non_convex_tests) ... ERROR in LDL_factor: Error in KKT matrix LDL factorization when computing the nonzero el The problem seems to be non-convex
ERROR in osqp_setup: KKT matrix factorization.
The problem seems to be non-convex.
ok
test_polish_random (module.tests.polishing_test.polish_tests) ... ok
test_polish_simple (module.tests.polishing_test.polish_tests) ... ok
test_polish_unconstrained (module.tests.polishing_test.polish_tests) ... ok
test_primal_and_dual_infeasible_problem (module.tests.primal_infeasibility_test.primal_infeasibility_tests) ... ok
test_primal_infeasible_problem (module.tests.primal_infeasibility_test.primal_infeasibility_tests) ... ok
test_unconstrained_problem (module.tests.unconstrained_test.unconstrained_tests) ... ok
test_solve (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_A (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_A_allind (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_P (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_P_A_allind (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_P_A_indA (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_P_A_indP (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_P_A_indP_indA (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_update_P_allind (module.tests.update_matrices_test.update_matrices_tests) ... ok
test_warm_start (module.tests.warm_start_test.warm_start_tests) ... ok

======================================================================
ERROR: test_issue14 (module.tests.mkl_pardiso_test.mkl_pardiso_tests)

Traceback (most recent call last):
File "/tmp/root/spack-stage/spack-stage-py-osqp-0.6.2-xecbyow6iiudqrypuq75vqgye7jzruch/spack-src/module/tests/mkl_pardiso_test.py", line 25, in test_issue14
m.setup(self.P, self.q, self.A, self.l, self.u,
File "/home/spack/opt/spack/linux-centos8-aarch64/gcc-8.3.1/py-osqp-0.6.2-xecbyow6iiudqrypuq75vqgye7jzruch/lib/python3.8/site-packages/osqp/interface.py", line 37, in
self._model.setup(*unpacked_data, **settings)
ValueError: Workspace allocation error!

---

Ran 53 tests in 24.555s

FAILED (errors=1)
Test failed: <unittest.runner.TextTestResult run=53 errors=1 failures=0>
error: Test failed: <unittest.runner.TextTestResult run=53 errors=1 failures=0>

error checking in update method

When making an update to the cost data 'Px' in the 'update' method, the python OSQP interface does not check whether the array that has been passed is the correct size. If not index set is provided, OSQP should enforce a condition that the Px array provided by the user is the same length as the number of marked non-zeros in the upper triangle of P.

Export OSQP_info and OSQP_results in src/extension/src/osqpmodule.c

Export these two types can make osqp pickleable, otherwise python cannot recognize these classes.

mkl_set_interface workaround

The mkl_set_interface call in init_linsys_solver_pardiso, pardiso_interface.c, is still crashing with a segfault, no matter whether it uses long ints or not. I recompiled by commenting out the mkl_set_interface_layer call and now the module works really well. It seems the MKL library just uses the environment variable instead : https://scc.ustc.edu.cn/zlsc/tc4600/intel/2017.0.098/mkl/common/mklman_c/GUID-CF00130A-092E-4B3F-85C1-BACA3EB500C1.htm for possible combinations

Since only MKL_INTERFACE_LP64 and MKL_INTERFACE_ILP64 are supported in the pardiso_interface.c (and I use the GNU option), and since the program works well without any call to mkl_set_interface , but crashes when a call is performed, I suggest to just remove that call. If that is not possible (for example, because it is necessary in some other contexts, OS, etc), then a workaround would be to check whether an environment variable for MKL_THREADING_LAYER or MKL_INTERFACE_LAYER exists. If so, then MKL will use these anyway, so the call can be avoided.

In any case, thanks for the nice work :-)

Remove dependency on future for Python 3

As I understand it, the future package has no effect when installed on Python 3, and exists only to allow Python 2 to run Python 3 code. Insofar as OSQP-Python actually relies on any of future's features, it does so only when running on Python 2. Thus, it should be possible to reduce the installation load for Python 3 users by not installing future when hosted on Python 3. To do this, all you would need to do is to change
https://github.com/oxfordcontrol/osqp-python/blob/8e009e7dd41c44d1d2c31f92a5a0a035de6fb9f0/requirements.txt#L3
to

future;python_version<="2.7"

(See PEP 508.)

cmake as a build time requirement

I'm not seeing a cmake entry in either pyproject.toml or setup.py for the develop-1.0 branch. The min. required version in CmakeLists.txt is 3.18 so this will have to go in at the appropriate place.

Print issue

I am using osqp in conda environment but I don't want to get the output below, please how do I need to set?
"
OSQP v0.6.2 - Operator Splitting QP Solver
(c) Bartolomeo Stellato, Goran Banjac
University of Oxford - Stanford University 2021

problem: variables n = 148, constraints m = 196
nnz(P) + nnz(A) = 778
settings: linear system solver = qdldl,
eps_abs = 1.0e-03, eps_rel = 1.0e-03,
eps_prim_inf = 1.0e-04, eps_dual_inf = 1.0e-04,
rho = 1.00e-01 (adaptive),
sigma = 1.00e-06, alpha = 1.00, max_iter = 100
check_termination: on (interval 25),
time_limit: 1.00e-03 sec,
scaling: on, scaled_termination: off
warm start: on, polish: off, time_limit: 1.00e-03 sec

iter objective pri res dua res rho time
1 -5.4415e+04 5.60e+01 8.63e+08 1.00e-01 3.14e-04s
50 -3.9434e+06 1.15e-02 9.12e+01 1.82e-02 6.46e-04s

status: solved
number of iterations: 50
optimal objective: -3943371.5010
run time: 6.81e-04s
optimal rho estimate: 7.48e-03"

Support codegen in editable install

Right now python setup.py develop or pip install -e . do not pull in the codegen_src folder (generated during extension build time, which should be theoretically be identical in editable/normal install modes). This won't matter to 99% of the users, but it would be nice to investigate why this is not working and fix it, or document clearly that codegen is not supported when installing osqp-python in editable mode.

macos build wheels fail for 10.15 (catalina)

I install osqp via pip: pip install osqp, and then run a small LP problem:

import cvxpy as cp
import numpy as np
x = cp.Variable(4)

objective = cp.Minimize(4 * x[1] + 3 * x[2] + x[3])
constraints = [
    x[0] == 0,
    x >= 0,
    x[1] - x[2] + x[3] >= 1,
    x[1] + 2 * x[2] - 3 * x[3] >= 2,
]
prob = cp.Problem(objective, constraints)

# The optimal objective value is returned by `prob.solve()`.
result = prob.solve()
# The optimal value for x is stored in `x.value`.
print(x.value)
print(objective.value)

It fails on the osqp side.
The error message looks like:

TypeError                                 Traceback (most recent call last)
<ipython-input-2-8997b7dfd83e> in <module>()
----> 1 result = prob.solve()

/Users/youkaichao/anaconda3/envs/py3/lib/python3.6/site-packages/cvxpy/problems/problem.py in solve(self, *args, **kwargs)
    287         else:
    288             solve_func = Problem._solve
--> 289         return solve_func(self, *args, **kwargs)
    290
    291     @classmethod

/Users/youkaichao/anaconda3/envs/py3/lib/python3.6/site-packages/cvxpy/problems/problem.py in _solve(self, solver, warm_start, verbose, parallel, gp, qcp, **kwargs)
    569             self._intermediate_problem)
    570         solution = self._solving_chain.solve_via_data(
--> 571             self, data, warm_start, verbose, kwargs)
    572         full_chain = self._solving_chain.prepend(self._intermediate_chain)
    573         inverse_data = self._intermediate_inverse_data + solving_inverse_data

/Users/youkaichao/anaconda3/envs/py3/lib/python3.6/site-packages/cvxpy/reductions/solvers/solving_chain.py in solve_via_data(self, problem, data, warm_start, verbose, solver_opts)
    192         """
    193         return self.solver.solve_via_data(data, warm_start, verbose,
--> 194                                           solver_opts, problem._solver_cache)

/Users/youkaichao/anaconda3/envs/py3/lib/python3.6/site-packages/cvxpy/reductions/solvers/qp_solvers/osqp_qpif.py in solve_via_data(self, data, warm_start, verbose, solver_opts, solver_cache)
    111             solver_opts['polish'] = solver_opts.get('polish', True)
    112             solver = osqp.OSQP()
--> 113             solver.setup(P, q, A, lA, uA, verbose=verbose, **solver_opts)
    114
    115         results = solver.solve()

/Users/youkaichao/anaconda3/envs/py3/lib/python3.6/site-packages/osqp/interface.py in setup(self, P, q, A, l, u, **settings)
     30
     31         unpacked_data, settings = utils.prepare_data(P, q, A, l, u, **settings)
---> 32         self._model.setup(*unpacked_data, **settings)
     33
     34     def update(self, q=None, l=None, u=None,

TypeError: argument 2 must be numpy.ndarray, not numpy.ndarray

But it works if I build the package myself.

I'm using macos 10.15 (catalina).

codegen error

I used the codegen like this

but it er error at CMakeLists.txt:120 (add_subdirectory):
The source directory
/home/lyj/code1/include
does not contain a CMakeLists.txt file.
and I found that the CMakeLists.txt not copy to the target_include folder. I think you have some mistake in codegen.py file

Python solve is faster than C code-generated one

Hi,

I ran the quadrotor example in Python and generated C code in the standard way. I noticed that it intentionally generated code with an EMBEDDED flag then I have to use time.h to measure the solve time of the osqp_solve(&workspace) function.

Both Python and C gave me the same results but the solve times are unexpected. Python one is like 1ms and C one is like 3ms. I don't really get why this happened. Did anyone see this problem before?

Thanks.

Installation fails if numpy is not already installed with python 3.8

Installation in a fresh python3.8 environment where numpy is not present fails because of the numpy import at the beginning of setup.py.

$ python --version
Python 3.8.0
$ pip --version
pip 19.3.1 from /tmp/venv/lib/python3.8/site-packages/pip (python 3.8)
$ pip install osqp
Collecting osqp
  Using cached https://files.pythonhosted.org/packages/ba/17/49790ce2ce7a6b95cd250642ebc68bd723ddefdd052ee8dcc1e0dcf4ffca/osqp-0.6.1.tar.gz
    ERROR: Command errored out with exit status 1:
     command: /tmp/venv/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-a1pzoqca/osqp/setup.py'"'"'; __file__='"'"'/tmp/pip-install-a1pzoqca/osqp/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-install-a1pzoqca/osqp/pip-egg-info
         cwd: /tmp/pip-install-a1pzoqca/osqp/
    Complete output (5 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-install-a1pzoqca/osqp/setup.py", line 11, in <module>
        import numpy
    ModuleNotFoundError: No module named 'numpy'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

It seems that this issue had be addressed in PR #2 but that import numpy is now back in setup.py. Strangely I didn't observe this behavior under python 3.6 and 3.7 so it may be related to python 3.8.

Installing numpy before osqp avoids the problem.

Add macOS arm64 wheel

Currently, no wheel for macOS arm64 is available on PyPI. Since you are already using cibuildwheel, you can upgrade to version 2.10.0 or above, which provides support for building macOS arm64 wheels natively on Cirrus CI.

Add Python binary wheels for Linux on Pypi (manylinux)

Add binary wheels for Linux on pypi. It seems that pypi does not allow uploading binary wheels with C extensions using the standard procedure.

Having only a source linux distribution could give issues when installing OSQP on linux platforms with multiple python installations and virtual environments. https://github.com/cvxgrp/cvxpy/issues/503

A workaround is to use binary wheels based on https://github.com/pypa/manylinux.

Wrap generated C code with tiny python functionalities

Main idea:

• Generate setup.py similarly to pre-1.0 versions
• Wrap these functionalities with new pybind11-based code

  osqp-python/src/osqp/codegen/files_to_generate/emosqpmodule.c

  Lines 666 to 679 in f486931

  	static PyMethodDef PYTHON_EXT_NAME_methods[] = {
  	{"solve", (PyCFunction)OSQP_solve, METH_NOARGS, "Solve QP"},
  	{"update_lin_cost", (PyCFunction)OSQP_update_lin_cost, METH_VARARGS, "Update linear cost"},
  	{"update_lower_bound", (PyCFunction)OSQP_update_lower_bound, METH_VARARGS, "Update lower bound"},
  	{"update_upper_bound", (PyCFunction)OSQP_update_upper_bound, METH_VARARGS, "Update upper bound"},
  	{"update_bounds", (PyCFunction)OSQP_update_bounds, METH_VARARGS, "Update bounds"},
  	#if EMBEDDED != 1
  	{"update_P", (PyCFunction)OSQP_update_P, METH_VARARGS, "Update matrix P"},
  	{"update_A", (PyCFunction)OSQP_update_A, METH_VARARGS, "Update matrix A"},
  	{"update_P_A", (PyCFunction)OSQP_update_P_A, METH_VARARGS, "Update matrices P and A"},
  	#endif
  	{NULL, NULL, 0, NULL}
  	};

  The update ones are combined now.
• Simplify solution structure as in

  osqp-python/src/osqp/codegen/files_to_generate/emosqpmodule.c

  Lines 262 to 264 in f486931

  	return Py_BuildValue("OOiid", x, y, (&workspace)->info->status_val,
  	(&workspace)->info->iter, solve_time);

• Compile python wrapper as in the pre-1.0 version

Add CONTRIBUTING.md

Add instructions to:

• Create a release
• Install required dev dependencies, e.g., pre-commit.

No wheels for Python 3.11

Hi,

Python 3.11 has been released as the current stable version, and it would be great to get wheels for this version.

Thanks!

CMake must be installed to build OSQP

It seems this package needs CMake during a pip install.

RuntimeError: CMake must be installed to build OSQP

If I do pip install cmake it works after.

Can't cmake be added to the setup_requires field in setup.py?
This would make the installation process smoother for many libraries that depend on this one.
I'll make a PR if this can be done?

FLOAT codegen argument doesn't work as expected

Issue

Using the following code in Python, I'm expecting the resulting generated code to use floats because of FLOAT='True'. Instead, it looks like the generated code is still using doubles.

prob.codegen('osqp_gen',parameters='vectors', FLOAT='True')

Outputs the following to the console along with the generated files.

-----------------------------------------------------------------
           OSQP v0.6.3  -  Operator Splitting QP Solver
              (c) Bartolomeo Stellato,  Goran Banjac
        University of Oxford  -  Stanford University 2021
-----------------------------------------------------------------
problem:  variables n = 172, constraints m = 304
          nnz(P) + nnz(A) = 1161
settings: linear system solver = qdldl,
          eps_abs = 1.0e-03, eps_rel = 1.0e-03,
          eps_prim_inf = 1.0e-04, eps_dual_inf = 1.0e-04,
          rho = 1.00e-01 (adaptive),
          sigma = 1.00e-06, alpha = 1.60, max_iter = 4000
          check_termination: on (interval 25),
          scaling: on, scaled_termination: off
          warm start: on, polish: off, time_limit: off

Getting workspace from OSQP object...                           [done]
Creating target directories...                                  [done]
Copying OSQP sources...                                         [done]
Generating customized code...                                   [done]
Compiling Python wrapper...                                     [done]
Copying code-generated Python solver to current directory...    [done]

In osqp_gen > include > osqp_configure.h I see:

/* DFLOAT */
/* #undef DFLOAT */

/* DLONG */
#define DLONG

In osqp_gen > include > qdldl_types.h I see:

// QDLDL integer and float types
typedef long long    QDLDL_int;   /* for indices */
typedef double  QDLDL_float; /* for numerical values  */
typedef unsigned char   QDLDL_bool;  /* for boolean values  */

Compiling

Running the CMakeLists.txt file, it also shows Floats are still disabled.

-- We are on a Generic system
-- Embedded is 1
-- Passing EMBEDDED flag to compiler
-- Disabling printing for embedded
-- Printing is OFF
-- Disabling profiling for embedded
-- Profiling is OFF
-- Floats are OFF
-- Disabling long integers (64bit) on 32bit machine
-- Long integers (64bit) are OFF

Move Python-specific interface code from main library to Python interface repo

The merging of osqp/osqp#396 in the main OSQP library repo will allow us to move the Python-specific printing functions to the Python repo, removing the need to include the Python headers and code in the main library.

This is also possible to do with the memory allocation functions currently, and hopefully the timing/interrupt functions will move to this as well, so we can then move all Python-interface specific code to the interface and remove it from the main library repo.

Installation fails if numpy is not already installed with python 3.9

Thank you for great OSS!!.
I think a similar issue of #40 exists on Python 3.9.

Collecting osqp>=0.4.1
Downloading osqp-0.6.1.tar.gz (211 kB)
ERROR: Command errored out with exit status 1:
command: /opt/hostedtoolcache/Python/3.9.0/x64/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-zg0bvhs2/osqp/setup.py'"'"'; file='"'"'/tmp/pip-install-zg0bvhs2/osqp/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-t6j45zjf
cwd: /tmp/pip-install-zg0bvhs2/osqp/
Complete output (5 lines):
Traceback (most recent call last):
File "", line 1, in
File "/tmp/pip-install-zg0bvhs2/osqp/setup.py", line 11, in
import numpy
ModuleNotFoundError: No module named 'numpy'

I think many people are waiting pip wheels for python 3.9!!

Add derivatives parallelization

Parallelize derivatives with multi-threading, similarly, to diffcp https://github.com/cvxgrp/diffcp/blob/a122f966bad40eb4eb24df38fe511ed2d12fcbff/diffcp/cone_program.py#L89

Note. We need to disable GIL before computing the adjoint derivatives

Remove legacy code

Remove legacy code to support old interface, e.g., files new_interface.py.

Release GIL

Would it be possible to release the GIL before calling into osqp, with the macro Py_BEGIN_ALLOW_THREADS, or are there possible complications?

Similar to how this is done in scs.

Need a pip release

aba0a5f fixes a bug where the warn package isn't imported.

Without this, users get unhappy errors like:

NameError: name 'warn' is not defined

The current pip version, 0.6.1, does not incorporate this fix. A new bugfix version should be released, if possible.

Move codegen workspace into c files

Split the code-generated worksapce in workspace.c and workspace.h.

This is consistent with the matlab interface: osqp/osqp-matlab#10

Licensing question with OSQP regarding CVXOPT imports

Hi,
First, I am looking for a good QP solver that is free of GPL license, and the OSQP became one of the most prominent candidate for our project.
I am planning to include the solver into our software, which is also licensed under Apache license, and GPL is incompatible with the Apache license. Our project legal team advised that GPL cannot be included into our project due to license incompatibility.
However, when I saw commit messages of OSQP, it seems that CVXOPT is tested within the OSQP.
I hope to know if OSQP code includes any part of CVXOPT code directly or imports that from the code of OSQP.
Thank you.

Error in building wheel for osqp because "No module named cmake' "

I'm trying to install the cvxpy package in my virtual environment of PyCharm. I typed C:\Users\<Username>\PycharmProjects\<projectName>\venv\Scripts>pip install cvxpy, and got:

Collecting cvxpy
  Using cached cvxpy-1.2.1-cp311-cp311-win_amd64.whl
Collecting ecos>=2
  Using cached ecos-2.0.10-cp311-cp311-win_amd64.whl
Collecting osqp>=0.4.1
  Using cached osqp-0.6.2.post5.tar.gz (226 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy>=1.15 in c:\users\<Username>\PycharmProjects\<projectName>\venv\lib\site-packages (from cvxpy) (1.23.4)
Collecting scs>=1.1.6
  Using cached scs-3.2.0-cp311-cp311-win_amd64.whl
Requirement already satisfied: scipy>=1.1.0 in c:\users\<Username>\PycharmProjects\<projectName>\venv\lib\site-packages (from cvxpy) (1.9.3)
Collecting qdldl
  Using cached qdldl-0.1.5.post2-cp311-cp311-win_amd64.whl
Building wheels for collected packages: osqp
  Building wheel for osqp (pyproject.toml) ... error
  ERROR: Command errored out with exit status 1:
   command: 'C:\Users\<Username>\PycharmProjects\<projectName>\venv\Scripts\python.exe' 'C:\Users\<Username>\PycharmProjects\<projectName>\venv\Lib\site-packages\pip\_vendor\pep517\in_process\_in_process.py' build_wheel 'C:\Users\<Username>\AppD
ata\Local\Temp\tmptb8bjomi'
       cwd: C:\Users\<Username>\AppData\Local\Temp\pip-install-6glakjuq\osqp_f4f485f728cb41eb9bd04d39cf2e5c81
  Complete output (82 lines):
  Disabling LONG
  Remove long integers for numpy compatibility. See:
   - https://github.com/numpy/numpy/issues/5906
   - https://github.com/ContinuumIO/anaconda-issues/issues/3823
  You can reenable long integers by passing: --osqp --long argument.

  running bdist_wheel
  running build
  running build_py
  running egg_info
  writing src\osqp.egg-info\PKG-INFO
  writing dependency_links to src\osqp.egg-info\dependency_links.txt
  writing requirements to src\osqp.egg-info\requires.txt
  writing top-level names to src\osqp.egg-info\top_level.txt
  listing git files failed - pretending there aren't any
  reading manifest file 'src\osqp.egg-info\SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  adding license file 'LICENSE'
  running build_ext
  Traceback (most recent call last):
    File "<frozen runpy>", line 198, in _run_module_as_main
    File "<frozen runpy>", line 88, in _run_code
    File "C:\Users\<Username>\PycharmProjects\<projectName>\venv\Scripts\cmake.exe\__main__.py", line 4, in <module>     
  ModuleNotFoundError: No module named 'cmake'
.
.
.
  subprocess.CalledProcessError: Command '['cmake', '--version']' returned non-zero exit status 1.
  ----------------------------------------

  ERROR: Failed building wheel for osqp

Trying C:\Users\<Username>>pip install cvxpy does successfuly install cvxpy, but then cvxpy isn't in my virtual environment. I tried uninstalling cmake and then installing cvxpy - didn't work. I uninstalled and reinstalled cmake and didn’t work.
cmake version is the latest, ver 3.24.1, obtained from running pip install cmake
python version is 3.11.0, pip version is 21.3.1.

osqp fails on scipy 1.5.0

Summary

Testing this package fails when scipy is upgraded to 1.5.0. All the "update_matrices_test.py" tests fail.

Extra Notes

Scipy 1.5.0 release notes: https://docs.scipy.org/doc/scipy/reference/release.1.5.0.html. I don't see major deprecations that would cause this.

Replication

# Install Nix
$ curl -L https://nixos.org/nix/install | sh
$ git clone https://github.com/nixos/nixpkgs.git
$ cd nixpkgs
# checkout failing commit
$ git checkout a3179602e47c918ea40b32f8f2a3c638d4484083
$ nix-build -A python3Packages.osqp

Test Logs

Test log from Nix-build

============================= test session starts ==============================
platform linux -- Python 3.8.3, pytest-5.4.3, py-1.8.1, pluggy-0.13.1
rootdir: /build/osqp-0.6.1
collected 49 items / 1 deselected / 48 selected                                

module/tests/basic_test.py ...........                                   [ 22%]
module/tests/codegen_matrices_test.py .........                          [ 41%]
module/tests/codegen_vectors_test.py .....                               [ 52%]
module/tests/dual_infeasibility_test.py ...                              [ 58%]
module/tests/feasibility_test.py .                                       [ 60%]
module/tests/non_convex_test.py ...                                      [ 66%]
module/tests/polishing_test.py ...                                       [ 72%]
module/tests/primal_infeasibility_test.py ..                             [ 77%]
module/tests/unconstrained_test.py .                                     [ 79%]
module/tests/update_matrices_test.py FFFFFFFFF                           [ 97%]
module/tests/warm_start_test.py .                                        [100%]

=================================== FAILURES ===================================
_______________________ update_matrices_tests.test_solve _______________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_solve>

    def test_solve(self):
        # Solve problem
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.85459329, 0.73472366, 0.06156, -0.06095794, -0.96167612]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 1.99022911
E       Max relative difference: 22.44656972
E        x: array([-1.135636, -0.471212,  0.214947,  1.307339,  0.176622])
E        y: array([ 0.854593,  0.734724,  0.06156 , -0.060958, -0.961676])

module/tests/update_matrices_test.py:46: AssertionError
_____________________ update_matrices_tests.test_update_A ______________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_A>

    def test_update_A(self):
        # Update matrix A
        Ax = self.A_new.data
        Ax_idx = np.arange(self.A_new.nnz)
        self.model.update(Ax=Ax, Ax_idx=Ax_idx)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.44557958, 0.11209195, 0.22051994, -0.78051077, -0.01697192]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 0.90386561
E       Max relative difference: 4.83483723
E        x: array([-0.128437,  0.200391,  0.01928 ,  0.123355,  0.065085])
E        y: array([ 0.44558 ,  0.112092,  0.22052 , -0.780511, -0.016972])

module/tests/update_matrices_test.py:87: AssertionError
__________________ update_matrices_tests.test_update_A_allind __________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_A_allind>

    def test_update_A_allind(self):
        # Update matrix A
        Ax = self.A_new.data
        self.model.update(Ax=Ax)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.44557958, 0.11209195, 0.22051994, -0.78051077, -0.01697192]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 0.90386561
E       Max relative difference: 4.83483723
E        x: array([-0.128437,  0.200391,  0.01928 ,  0.123355,  0.065085])
E        y: array([ 0.44558 ,  0.112092,  0.22052 , -0.780511, -0.016972])

module/tests/update_matrices_test.py:100: AssertionError
_____________________ update_matrices_tests.test_update_P ______________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_P>

    def test_update_P(self):
        # Update matrix P
        Px = self.P_new.data
        Px_idx = np.arange(self.P_new.nnz)
        self.model.update(Px=Px, Px_idx=Px_idx)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.79105808, 0.68008954, -0.00974931, -0.00569589, -0.92142316]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 2.03442876
E       Max relative difference: 251.98743999
E        x: array([-1.243371, -0.525746,  0.247115,  1.429597,  0.191722])
E        y: array([ 0.791058,  0.68009 , -0.009749, -0.005696, -0.921423])

module/tests/update_matrices_test.py:60: AssertionError
_________________ update_matrices_tests.test_update_P_A_allind _________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_P_A_allind>

    def test_update_P_A_allind(self):
        # Update matrices P and A
        Px = self.P_new.data
        Ax = self.A_new.data
        self.model.update(Px=Px, Ax=Ax)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.45599336, 0.11471169, 0.22567378, -0.80654725, -0.01778191]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 0.95140325
E       Max relative difference: 5.29813175
E        x: array([-0.150824,  0.23532 ,  0.02264 ,  0.144856,  0.076429])
E        y: array([ 0.455993,  0.114712,  0.225674, -0.806547, -0.017782])

module/tests/update_matrices_test.py:160: AssertionError
__________________ update_matrices_tests.test_update_P_A_indA __________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_P_A_indA>

    def test_update_P_A_indA(self):
        # Update matrices P and A
        Px = self.P_new.data
        Ax = self.A_new.data
        Ax_idx = np.arange(self.A_new.nnz)
        self.model.update(Px=Px, Ax=Ax, Ax_idx=Ax_idx)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.45599336, 0.11471169, 0.22567378, -0.80654725, -0.01778191]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 0.95140325
E       Max relative difference: 5.29813175
E        x: array([-0.150824,  0.23532 ,  0.02264 ,  0.144856,  0.076429])
E        y: array([ 0.455993,  0.114712,  0.225674, -0.806547, -0.017782])

module/tests/update_matrices_test.py:146: AssertionError
__________________ update_matrices_tests.test_update_P_A_indP __________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_P_A_indP>

    def test_update_P_A_indP(self):
        # Update matrices P and A
        Px = self.P_new.data
        Px_idx = np.arange(self.P_new.nnz)
        Ax = self.A_new.data
        self.model.update(Px=Px, Px_idx=Px_idx, Ax=Ax)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.45599336, 0.11471169, 0.22567378, -0.80654725, -0.01778191]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 0.95140325
E       Max relative difference: 5.29813175
E        x: array([-0.150824,  0.23532 ,  0.02264 ,  0.144856,  0.076429])
E        y: array([ 0.455993,  0.114712,  0.225674, -0.806547, -0.017782])

module/tests/update_matrices_test.py:131: AssertionError
_______________ update_matrices_tests.test_update_P_A_indP_indA ________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_P_A_indP_indA>

    def test_update_P_A_indP_indA(self):
        # Update matrices P and A
        Px = self.P_new.data
        Px_idx = np.arange(self.P_new.nnz)
        Ax = self.A_new.data
        Ax_idx = np.arange(self.A_new.nnz)
        self.model.update(Px=Px, Px_idx=Px_idx, Ax=Ax, Ax_idx=Ax_idx)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.45599336, 0.11471169, 0.22567378, -0.80654725, -0.01778191]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 0.95140325
E       Max relative difference: 5.29813175
E        x: array([-0.150824,  0.23532 ,  0.02264 ,  0.144856,  0.076429])
E        y: array([ 0.455993,  0.114712,  0.225674, -0.806547, -0.017782])

module/tests/update_matrices_test.py:116: AssertionError
__________________ update_matrices_tests.test_update_P_allind __________________

self = <module.tests.update_matrices_test.update_matrices_tests testMethod=test_update_P_allind>

    def test_update_P_allind(self):
        # Update matrix P
        Px = self.P_new.data
        self.model.update(Px=Px)
        res = self.model.solve()
    
        # Assert close
>       nptest.assert_array_almost_equal(res.x,
            np.array([0.79105808, 0.68008954, -0.00974931, -0.00569589, -0.92142316]))
E       AssertionError: 
E       Arrays are not almost equal to 6 decimals
E       
E       Mismatched elements: 5 / 5 (100%)
E       Max absolute difference: 2.03442876
E       Max relative difference: 251.98743999
E        x: array([-1.243371, -0.525746,  0.247115,  1.429597,  0.191722])
E        y: array([ 0.791058,  0.68009 , -0.009749, -0.005696, -0.921423])

module/tests/update_matrices_test.py:73: AssertionError
=============================== warnings summary ===============================
module/tests/polishing_test.py::polish_tests::test_polish_random
  /build/osqp-0.6.1/module/tests/polishing_test.py:91: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    Pt = sp.randn(self.n, self.n)

module/tests/polishing_test.py::polish_tests::test_polish_random
  /build/osqp-0.6.1/module/tests/polishing_test.py:93: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.q = sp.randn(self.n)

module/tests/polishing_test.py::polish_tests::test_polish_random
  /build/osqp-0.6.1/module/tests/polishing_test.py:94: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.A = sparse.csc_matrix(sp.randn(self.m, self.n))

module/tests/polishing_test.py::polish_tests::test_polish_random
  /build/osqp-0.6.1/module/tests/polishing_test.py:95: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.l = -3 + sp.randn(self.m)

module/tests/polishing_test.py::polish_tests::test_polish_random
  /build/osqp-0.6.1/module/tests/polishing_test.py:96: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.u = 3 + sp.randn(self.m)

module/tests/primal_infeasibility_test.py::primal_infeasibility_tests::test_primal_infeasible_problem
  /build/osqp-0.6.1/module/tests/primal_infeasibility_test.py:38: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.q = sp.randn(self.n)

module/tests/primal_infeasibility_test.py::primal_infeasibility_tests::test_primal_infeasible_problem
  /build/osqp-0.6.1/module/tests/primal_infeasibility_test.py:40: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.u = 3 + sp.randn(self.m)

module/tests/primal_infeasibility_test.py::primal_infeasibility_tests::test_primal_infeasible_problem
  /build/osqp-0.6.1/module/tests/primal_infeasibility_test.py:41: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.l = -3 + sp.randn(self.m)

module/tests/primal_infeasibility_test.py::primal_infeasibility_tests::test_primal_infeasible_problem
  /build/osqp-0.6.1/module/tests/primal_infeasibility_test.py:45: DeprecationWarning: scipy.rand is deprecated and will be removed in SciPy 2.0.0, use numpy.random.rand instead
    self.l[int(self.n/2)] = self.u[int(self.n/2)+1] + 10 * sp.rand()

module/tests/warm_start_test.py::warm_start_tests::test_warm_start
  /build/osqp-0.6.1/module/tests/warm_start_test.py:32: DeprecationWarning: scipy.rand is deprecated and will be removed in SciPy 2.0.0, use numpy.random.rand instead
    self.l = -sp.rand(self.m) * 2.

module/tests/warm_start_test.py::warm_start_tests::test_warm_start
  /build/osqp-0.6.1/module/tests/warm_start_test.py:33: DeprecationWarning: scipy.rand is deprecated and will be removed in SciPy 2.0.0, use numpy.random.rand instead
    self.u = sp.rand(self.m) * 2.

module/tests/warm_start_test.py::warm_start_tests::test_warm_start
  /build/osqp-0.6.1/module/tests/warm_start_test.py:37: DeprecationWarning: scipy.randn is deprecated and will be removed in SciPy 2.0.0, use numpy.random.randn instead
    self.q = sp.randn(self.n)

-- Docs: https://docs.pytest.org/en/latest/warnings.html
=========================== short test summary info ============================
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_solve
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_A
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_A_allind
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_P
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_P_A_allind
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_P_A_indA
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_P_A_indP
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_P_A_indP_indA
FAILED module/tests/update_matrices_test.py::update_matrices_tests::test_update_P_allind
=========== 9 failed, 39 passed, 1 deselected, 12 warnings in 5.75s ============

Segmentation fault: 11

I am running the following simple script:

import osqp
import numpy as np
from scipy.sparse import csc_matrix

P = np.array([[1,0], [0,1]])
q = np.array([-1,-1])
A = np.array([[1,0], [0,1]])
l = np.array([0,0])
u = np.array([1,1])

P = csc_matrix(P)
A = csc_matrix(A)

settings = {
    'verbose': True,
}

# This works
m = osqp.OSQP()
m.setup(P=P, q=q, A=A, l=l, u=u, **settings)
results = m.solve()
print(results.x)  # [0.99895712 0.99895712]

# This fails with Segmentation fault: 11
results = osqp.solve(P=P, q=q, A=A, l=l, u=u, **settings)
print(results.x)

Creating OSQP object and calling a solve method on it works fine.
The value of x is [0.99895712 0.99895712].

Direct invocation of osqp.solve terminates with Segmentation fault: 11.

Setup:
MacBook Pro, MacOS Mojave 10.14.6
Python 3.7.2
OSQP 0.6.1
numpy 1.16.2
scipy 1.2.2

Migrate or join conda-recipe efforts in conda-forge?

Hey everyone

I've been working with cvxpy and osqp for a while, and it's always been a pain to install (especially on windows). Things have progressed a lot over the last two years, but only recently did I become hopeful to have a centralised install of everything necessary through conda-forge.

The reason a single channel is important for several reasons:

• conda-forge is the "gold standard" of curated packages in the conda-universe, and even anaconda uses this as their "upstream" for most packages
• in turn, it is strongly discouraged to add other channels, which might have packages compiled with incompatible compilers etc.
• consequently, it is often hard to get any channel other than conda-forge (and main) past a sys-admin / firewall / proxy.
• finally, it gives much more exposure. Although the current osqp-feedstock has seen no action since more than half a year (and didn't have a windows build), the downloads outnumber the oxfordcontrol-channel by more than four to one.

After I discovered that conda-forge/osqp-feedstock#8 had been dormant for a while, I managed to build for 0.5.0 a couple of days ago, and consequently also for windows. Note that this involved cutting some corners (e.g. I really don't care about investing any time in python 2.7), and some tiny patches to get stuff to build on azure.

Now I've run into problems with 0.6.0 and 0.6.1, and was trying to figure out where the specification of the debug-build came from, I saw that there was a conda-recipe in this repo as well.

Long story short: I wanted to suggest merging forces and to (for the above reasons and more) concentrate the conda-related efforts on the conda-forge feedstock. I'm happy to add you to the maintainers right away, and don't care whether we revert/adapt any and all changes I made. All I want is a working conda installation across all platforms and with minimal maintenance effort for everyone involved.

Circular test dependency on cvxpy

Anything that uses module/tests/utils.py depends on cvxpy. However, cvxpy requires osqp to build, causing a circular dependency: https://github.com/cvxgrp/cvxpy/blob/b5b0f8b15b1f10106301d2b921ccfc6cbbbaf044/setup.py#L72.

I can work around this by disabling tests that use cvxpy for now, but this is still not ideal.