Question about osqp_update_data_mat behavior when supplying matrix indices in CSC form

[maniok098]

Dear OSQP developers,

We are implementing our MPC on an embedded system and using osqp_update_data_mat to update the problem matrices. We observed that when supplying CSC-form indices along with the updated values, the solver fails to solve the MPC problem (control input jumps to bound values), even if we use the same data and indices as before. Specifically:

• The following call succeeds:

osqp_update_data_mat(solver, P_x_old, OSQP_NULL, P_nnz_old, A_x_old, OSQP_NULL, A_nnz_old)

• While this call fails:

osqp_update_data_mat(solver, P_x_old, P_i_old, P_nnz_old, A_x_old, A_i_old, A_nnz_old);

Notably, we also used P_i_old and A_i_old during the initial setup, and the solver worked fine in that case. This suggests that even if we intend to update only the matrix values, supplying the same indices as in the setup might be affecting the behavior.

We noticed that the supplied indices are used by OSQPMatrix_update_values after unscaling the solver in osqp/src/osqp_api.c:1138 Could you provide any insights into why this might be happening? Are there any specific constraints or considerations when updating matrices with indices?

[goulart-paul]

It is hard to say without seeing an example, but the first things I would check are:

1. Check that there is not some confusion about whether you are supplying a complete P matrix or the upper triangle. The update functions are expecting to only get the upper triangular part of P. Note that I don't think the anything other than an upper triangular matrix will be accepted at solver creation.

2. Make sure that the sparse matrices you are passing are arranged such that entries within any column or arranged in increasing order of row number.

3. See if the problem persists with data equilibration enabled/disabled. Set scaling = 0 to disable.

Does specification of a complete index vector cause failures when done for just one of P or A? If so, which one?

[maniok098]

Thank you for replying so quickly! We will investigate further and follow up here.

[maniok098]

Dear @goulart-paul and all potentially interested developers and users, I conducted further investigation and found that updating P is causing the issue, whereas updating A works fine. I hope this provides more evidence of the behavior.

• Code for reproducing test_osqp_update_data_mat.cpp
• Tested OSQP version: The latest GitHub version, commit 2747c45
• Operating system: Arch Linux (No in embedded mode)

Summary of findings

1. Yes we are aware that P should be suplied in CSC form, containing only the upper triangular part. To ensure this, our Python wrapper processes P using np.triu(P) before converting it to scipy.sparse.csc_matrix, as shown below

import numpy as np
import scipy.sparse as sp

# Some dense symmetric matrices
# P = ....

# Convert to CSC form
P_csc = sp.csc_matrix(np.triu(P))

# Write header files for C++
cpp_data =  "// Custom member variables for QSQP solver\n\n"
cpp_data += f"OSQPFloat m_P_x[{P_sp.nnz}] = {{{', '.join(map(str, P_sp.data.tolist()))}}};\n"
cpp_data += f"OSQPInt m_P_nnz = {P_sp.nnz};\n"
cpp_data += f"OSQPInt m_P_i[{P_sp.nnz}] = {{{', '.join(map(str, P_sp.indices.tolist()))}}};\n"
cpp_data += f"OSQPInt m_P_p[{P_sp.indptr.size}] = {{{', '.join(map(str, P_sp.indptr.tolist()))}}};\n\n"

with open(filename, 'w') as f:
    f.write(cpp_data)

2. As scipy.sparse.csc_matrix handles the CSC format, we assume that P is properly strutured. This has worked well for our other MPC problems, where we only updated setpoints etc. using osqp_update_data_vec, without updating P or A.

3. The issue persists even when setting scaling=0, leading to the following error:

Segmentation fault (core dumped)

4. The failure occurs only when updating P, whereas updating A works fine. The results from our test code are as follows:

• Expected output

iter   objective    prim res   dual res   gap        rel kkt    rho         time
   1   0.0000e+00   0.00e+00   0.00e+00   0.00e+00   0.00e+00   1.00e-01    1.54e-05s
  25   0.0000e+00   0.00e+00   0.00e+00   0.00e+00   0.00e+00   1.00e-01    1.38e-04s

status:               solved
solution polishing:   unsuccessful
number of iterations: 25
optimal objective:    0.0000
dual objective:       -0.0000
duality gap:          0.0000e+00
primal-dual integral: 0.0000e+00
run time:             3.05e-04s
optimal rho estimate: 1.00e-06

MPC solution: 0

• Failure

Segmentation fault (core dumped)

• This fails

// Case 1 :  Update both P and A matrix → Fails
  m_exitflag = osqp_update_data_mat(m_solver, m_P_x, m_P_i, m_P_nnz, m_A_x,
                                    m_A_i, m_A_nnz);

• This fail

// Case 2: Updating only P → Still fails
  m_exitflag = osqp_update_data_mat(m_solver, m_P_x, m_P_i, m_P_nnz,
  OSQP_NULL,
                                    OSQP_NULL, OSQP_NULL);

• This succeeds

// Case 3: Updating only A → Succeeds
m_exitflag = osqp_update_data_mat(m_solver, OSQP_NULL, OSQP_NULL,
OSQP_NULL,
                                m_A_x, m_A_i, m_A_nnz);

• This succeed

// Case 4: Using OSQP_NULL to force full update → Succeeds
m_exitflag = osqp_update_data_mat(m_solver, m_P_x, OSQP_NULL, m_P_nnz, m_A_x,
                                OSQP_NULL, m_A_nnz);

• This succeeds

// Case 5: Setting m_P_i[i] = i to force a full update of P → Succeeds
for (int i = 0; i < m_P_nnz; i++) {
m_P_i[i] = i;
}
m_exitflag = osqp_update_data_mat(m_solver, m_P_x, m_P_i, m_P_nnz, m_A_x,
                                m_A_i, m_A_nnz);

I hope these tests could help identify the cause of this behavior. Please let me know if further testing is needed—I’d be happy to assist.