Make first release and upload to pypi

[bstellato]

It would be nice to release the first (minor ?) version and upload it to pypi so that people can try it out. What do you think @bamos ?

[bamos]

Yes! Sounds good -- there are a few things I'd like to debug and get fixed and in before then. I've been connecting this in with some experiments over the past week and comparing the performance to qpth. While the derivatives between qpth and osqpth match on some simple QPs, I've been having some issues getting osqpth to converge on the optnet sudoku experiment that qpth converges on. Here's a run I just did with qpth:

And here's what osqpth does:

---

As we worried about before, this is likely happening from selecting the wrong active set in the backward pass for some problems. One solution would be to switch to using the full KKT system in the backward pass for now and try to debug the active set one/re-use the OSQP pre-factorizations later, what do you think of this?

I'll also push in an osqp option to the optnet experiment repo soon once I clean up the code a bit, and can also send an example problem from one of the later phases of training where the gradients are off so we could concretely debug that.

---

Here's a quick/informal performance comparison of the iteration time for the optnet 4x4 sudoku experiment. I think most of the computation is bottlenecked by the internal operations on osqpth rather than other operations I'm doing (also I am now computing the sparse index map once and am not using the fully dense one like I was talking about in the other issue). I think this is also bottlenecked by the backward pass computations too. Also for these smaller systems, a batched dense backwards pass on CUDA could be competitive over a multi-processing sparse one:

	Batch Size	Time (s)
qpth (GPU)	1	0.12s
	300	~1.5s
osqpth	1	0.01s
	300	2.39s

---

I've got a stream of some other more minor changes to the layer code to that better handles some error cases and catches some nasty issues when used improperly and will send them over in a PR soon. Let me know if you, @sbarratt, or others have any uncommitted changes (like for multiprocessing) that you want me to wait for and put my changes on top of.

[bstellato]

Thank you @bamos for running these tests! Indeed, the active set selection can be problematic when the precision is lower. Probably with some acceleration methods or higher precision there will be fewer issues.

One solution would be to switch to using the full KKT system in the backward pass for now and try to debug the active set one/re-use the OSQP pre-factorizations later, what do you think of this?

What if we set it as an option to switch? it would help debugging.

There are no changes I would like to push at the moment. I added an utility function to disable multi-threading to the python osqp interface before releasing 0.6.0. This is independent from osqpth though.

Here's a quick/informal performance comparison of the iteration time for the optnet 4x4 sudoku experiment....

Warm-starting the solver from the previous solution would already be beneficial. We should try it. Also, I suspect that initializing the OSQP object during the layer initialization by performing an initial setup and reusing it throughout the forward-backward passes would help a lot saving time. What do you think?

[bamos]

What if we set it as an option to switch? it would help debugging.

Sure, a switch here sounds good. I'll add this in and try it on the Sudoku experiment.

Warm-starting the solver from the previous solution would already be beneficial. We should try it.

Yes, this is something really cool that osqpth enables and it should be relatively easy to add in a warm-start buffer for every example. I thought about doing this with the qpth PDIPM but was worried I'd have a hard time warm-starting it.

If finding the right active set/re-using the OSQP factorization for the backward pass doesn't work out for some reason, it may be useful to use an iterative method for the backward pass and warm-start it too.

Also, I suspect that initializing the OSQP object during the layer initialization by performing an initial setup and reusing it throughout the forward-backward passes would help a lot saving time. What do you think?

Yes, this would be especially useful in testing mode when the data isn't changing. For this we should switch to using a Module wrapper around a Function, which may be useful even if we don't do this: https://pytorch.org/docs/stable/notes/extending.html