How to implement this formulation symbolically (eg. in CasADi) about towr HOT 3 OPEN

Hi! That's a good question that I unfortunately don't have a direct answer to. You're right, the polynomial that's affecting the constraint changes as the duration get optimized. Therefore, you can't really know in advance which optimization variables affect this constraint, anyone of the polynomials might. See here the discrete id being calculated:

(Side note: only for the dynamic and range-of-motion constraint that are equally spaced in time. Many other constraints are directly enforced at the polynomial junctions, and move together as the durations change, so those should be easier to formulate symbolically).

So I'm not sure how you could implement this symbolically, but the function above that calculates this discrete ID would be the one to focus on. Maybe there's a way to say: All node values might affect the specific constraint at time t, just the affect of those nodes far away from the constraint are zero?

from towr.

Hi,
On the same subject, I think this problem already exists with IPOPT. According to my tests and the IPOPT documentation, the structure of the Jacobian needs to be constant [1] and IPOPT starts to give weird results when a constraint switches from one spline to the other.
@awinkler Do you initialize IPOPT with a specific structure somewhere? If not, I'd suggest to add non-zero values in the Jacobian for the n next/previous splines w.r.t the active one at least during the IPOPT initialization.

[1] "Once defined, this nonzero structure MUST remain constant for the entire optimization procedure. This means that the structure needs to include entries for any element that could ever be nonzero,
not only those that are nonzero at the starting point." https://projects.coin-or.org/Ipopt/browser/stable/3.2/Ipopt/doc/documentation.pdf?format=raw

from towr.

Yes, you're right, I just checked the code to find where I'm tackling this issue already. This is because IPOPT requires the sparsity structure beforehand, see this discussion. They way it's currently solved is very generously initializing all elements to be non-zero; so similar to what you suggested @Mathieu-Geisert. I'm assuming this makes it less performant, but at least won't mess up the algorithmic structure.

On a more general note, optimizing over the durations remains tricky. Convergence is slower from my experience and not as robust, so there's definitely room for investigation and discussion on how to set up this structure correctly.

from towr.