Upper and lower bound values at codegen initialization

[Matt Baumgart]

Hi,

I'm using the MATLAB codegen interface to generate a custom solver in OSQP 3.1.  At codegen time I initialize the upper and lower bounds to 1 and -1 (uniformly for all elements). 

Before calling the resulting custom solver via emosqp('solve'), I typically need to update the upper and lower bounds to new values via emosqp('update_bounds',l_new,u_new).

This has been working well and I've had similar performance from the codegen and non-codegen implementation.

However, I am now finding that when some elements of l_new and u_new are zero, the codegen solver performs very poorly compared to non-codegen.  For instance emosqp('solve') runs 1000000 iterations without much progress, while QP.solve() completes in 3000 iterations.

If I redo the codegen process with upper and lower bounds initialized to l_new and u_new at codegen time, performance is restored: emosqp('solve') performs about as well as QP.solve().

If I redo the codegen process with upper and lower bounds initialized to l_new-(1e-6) and u_new+(1e-6), performance is still restored.

If I redo the codegen process with upper and lower bounds initialized to l_new-(1e-3) and u_new+(1e-3), performance of the codegen version becomes very poor again.

I theorized that scaling might be to blame--but disabling scaling in the QP.setup call (prior to QP.codegen) does not help.  

Are some other settings necessary to ensure performance of the codegen solver after changing upper/lower bound values?

Thanks,

Matt

[Paul Goulart]

I believe the problem may be related to the automated choice of the parameter \rho that OSQP uses.   If the solver detects that a certain element of the lower/upper bounds coincides, then we use a larger value of \rho for that constraint since we assume you intend it as an equality constraint, and it will always be binding.   Otherwise we treat it as an inequality in the normal way.

If possible, I would suggest setting all of your inequalities to (-1,1) pairs and all of your equalities with (0,0) pairs during codegen. 

--
You received this message because you are subscribed to the Google Groups "OSQP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osqp+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osqp/5ee0fe9d-e980-42fe-a2a3-34be3c17755d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Goran Banjac]

A follow-up to Paul's comment:

It turns out that setting \rho parameter to a high value for an equality constraint works well. If a constraint was treated as an inequality constraint (because lower and upper bounds do not coincide), then \rho is set to a lower value. If the bounds are updated so that an inequality constraint becomes equality (we check that u-l < RHO_TOL), then we update the corresponding \rho parameter. Updating parameters requires re-factorization of the KKT matrix.

However, in codegen (to be precise, when EMBEDDED=1) we avoid performing numerical re-factorization and we do not update \rho.

As Paul suggested, if you expect that some constraints are always equality constraints, then you should make sure that the corresponding lower and upper bounds coincide before calling the codegen method.

If this is not the case, then you can generate the code with EMBEDDED=2. This mode will allow you to re-factor the KKT matrix when updating the bounds.

Finally, you might consider switching to the latest OSQP release; we had 3 new releases since 0.3.1.

Hope it helps.

Goran

[Matt Baumgart]

Thanks Paul and Goran.  The suggestion worked: when I initialize upper and lower bounds to zero for equality constraints, performance is restored.  Thank you very much for the fast response!

As an aside, I intend to migrate to v5.0 very soon, but wanted to get this issue figured out first.

I did also notice that when I initialize upper and lower bounds to zero for one or more *inequality* constraints, I get solved status = 1 but NaNs in the primal and dual solution.

Cheers,

Matt

You received this message because you are subscribed to a topic in the Google Groups "OSQP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osqp/ywEBIrjseD4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osqp+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osqp/1c1d1396-10a2-404c-b3a2-6ba8b10b0157%40googlegroups.com.

[Goran Banjac]

Could you please post a MWE in which the described behavior occurs?

Thanks,

Goran