Skip to content

Reduce chance of wrong warning for non-affine DAE

Tjerk Vreeken requested to merge reduce-incorrect-dae-affinity-warnings into master

If some DAE expressions contain e.g. if-else blocks on now-inlined parameters, they should no longer influence the check on affinity. However, MXFunctions are not as good as SXFunctions at giving sparsity information for complex functions with e.g. pending substitute calls. So in the affinity check we try to expand to SXFunction for sparsity information, and fall back to MXFunction if this fails for some reason.

Note that it is still possible to get incorrect warnings about the DAE not being affine, especially if one uses a compiled/codegen'd model. In that case, expansion to SXFunction is not possible. And even in the case where expansion is possible, we could still get the wrong sparsity information with SXFunctions as well.

Merge request reports