NaNs returned on poorly-posed problem

[danielpmorton]

I had accidentally made my problem poorly-posed by introducing a constraint that added a row of all zeros to my A matrix (So, one constraint was basically l <= 0x <= u)

But, this led to a confusing return where this produced NaNs instantly, even though the problem was instantaneously feasible (l <= 0 <= u)

This stems from scale_problem, where a term in data.E explodes to infinity after a few iterations of the while loop, and then in update_problem_data this line new_data.A = jnp.diag(data.E) @ A @ jnp.diag(data.D) leads to A containing NaNs due to E containing infs

I don't know what the best way to handle this poorly-posed case is, but figured I would mention this edge case.

This is the data which caused this problem:

[pculbertson-bdai]

Thanks Dan! One thought is there could be an unsafe divide lurking in the problem scaling -- i.e., here.

If you care / have a chance, maybe try adding a 1e-8 the the denominator here and see if it helps? OSQP in general should be quite robust to poor problem scaling (nice side-effect of ADMM), but the Ruiz stuff might not be.

If it's a persistent / important issue, we can always dig into Bartolomeo's problem scaling code in the "real" OSQP and see if we spot any differences.

[danielpmorton]

I'll give it a try!