OCP_QP_SET_ALL required after updating ocp problem data?

[markusgft]

Dear @giaf, I checked out the recent release 0.1.1 and ran into the following issue:

• With previous versions, i.e. the ct-v2 tag, I had to set the pointers to the problem data once (e.g. set pointers to the linearized system matrices A,B) afterwards I could arbitrarily mutate the problem matrices and hpipm would of course use the updated problem matrices without requiring further calls.
• In 0.1.1, simply updating problem matrices after initialization won't result in the solver "seeing" the new values. Everytime I change entries in the problem matrices, I have to call
• "OCP_QP_SET_ALL(...)" on the problem data, before executing a solve.

Is this a known behaviour? If the expected behaviour is different, I will try to devise a minimal example upon request!

Thanks, and keep up the great work!

[giaf]

Hi, I'm not sure of what you mean. And honestly I don't remember much about how the solver was 2 years ago :p

So, the HPIPM structures are supposed to be used as "black box", and only accessed though setters and getters. This is because e.g. some data is store into BLASFEO matrix format (as opposite to column-major), or transposed, or packed and so on. So, if you operate though the setter/getter interface, if you change your array of doubles somewhere, then surely you need to call a setter (either the set_all, or the individual setter like set_A) to update the memory in the actual HPIPM structure (which is the data "seen" by the solver).

Since we are in C and structures do not have private members, it is obviously also possible (at your own risk) to directly change yourself the structure members (and not though the setters/getters), if you know the format in which they are stored (e.g. blasfeo, packed, transposed, ...), and if you take the risk that a future solver version may change this format. I don't know if this was what you were doing with the ct-v2 version.

Hope this helps to clarify, otherwise if I didn't get what the issue is, some code snippet can help.

[markusgft]

Thank you for the answer, this is what I suspected. Essentially, it means that I need to call the "set_all" routine within the control loop, I will try to make some timings regarding this and see how things go!