Re: Digest for osqp@googlegroups.com - 5 updates in 1 topic
39 views
Skip to first unread message
Matt Baumgart
Feb 12, 2019, 9:32:24 AM2/12/19
to OSQP
Sending via PM
On Tue, Feb 12, 2019 at 12:07 AM <os...@googlegroups.com> wrote:
Matt Baumgart <matthew....@gmail.com>: Feb 11 07:03AM -0800
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 <goular...@gmail.com>: Feb 11 04:53PM
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.
Goran Banjac <goranba...@gmail.com>: Feb 11 09:18AM -0800
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
<https://github.com/oxfordcontrol/osqp/blob/master/include/constants.h#L59>),
then we update the corresponding \rho parameter
<https://github.com/oxfordcontrol/osqp/blob/master/src/osqp.c#L821-L824>.
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
On Monday, February 11, 2019 at 5:53:29 PM UTC+1, Paul Goulart wrote:
Matt Baumgart <matthew....@gmail.com>: Feb 11 10:27AM -0700
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
On Mon, Feb 11, 2019 at 10:18 AM Goran Banjac <goranba...@gmail.com>
wrote:
Goran Banjac <goranba...@gmail.com>: Feb 11 10:42AM -0800
Could you please post a MWE in which the described behavior occurs?
Thanks,
Goran
On Monday, February 11, 2019 at 6:28:08 PM UTC+1, Matt Baumgart wrote:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to osqp+uns...@googlegroups.com.
Matt Baumgart
Feb 12, 2019, 2:01:59 PM2/12/19
to OSQP
I am finding that the NaN issue I saw on 0.3.1 is not repeatable on OSQP 0.5.0.
Best,
Matt
Reply all
Reply to author
Forward
0 new messages