Importance of updating rho for new constraint bounds

Hi, I have encountered a situation where updating the lower and upper bounds of the constraints for a problem takes ‘a very long time’. For example with ~1000 variables solving and re-solving take ~0.1s but an update takes ~0.5s.

The issue seems to arise because my bounds update sets the upper limit for a single variable to its lower limit, which from looking at the code and reading the paper is triggering the solver to change the entry in rho as the constraint changes from an ‘inequality’ to an ‘equality’ constraint, and the update in rho causes a refactorization - hence the 0.5s (I assume).

My question is - is this rho update really needed? I appreciate that in general having 1000x larger values in rho for equality constraints reduces the number of solver iterations required, but in my use-case its resulting in large numbers of costly refactorizations, to save perhaps only a few much cheaper iterations.

It looks like when producing embedded code this update_rho_vec step is actually omitted?

Would there be value in allowing the user to forbid updates to rho when updating constraint bounds ? Or perhaps only updating rho if > x% of constraints have changed type?

Many thanks for any advice on the above,

1 Like

We have the exact same problem, turning a > into = is very expensive when updating constraints.

A solution to that would be very useful