Derivative of homotopy

[Martin Sjölund]

What is the derivative of homotopy? We have the following code commented out:

    // differentiate homotopy
    /* case( e as DAE.CALL(
                path = p as Absyn.IDENT(name="homotopy"),
                expLst = {actual,simplified},
                attr = attr), _, _, _, _)
      equation
        (res, functionTree) = differentiateExp(actual, inDiffwrtCref, inInputData, inDiffType, inFunctionTree);
        // (e2, functionTree) = differentiateExp(simplified, inDiffwrtCref, inInputData, inDiffType, functionTree);
        // res = DAE.CALL(p, {e1, e2}, attr);
      then
        (res, functionTree); */

For Buildings.Electrical.AC.ThreePhasesUnbalanced.Lines.Examples.ACSimpleGrid_N, replacing the expression with the actual expression works well. So does using the --replaceHomotopy=actual flag.

[Lennart Ochel]

This depends on the context. For ordinary simulation it is just the derivative of the actual expression. I am already working on removing homotopy for simulation context.

[Lennart Ochel]

I'd expect that just the actual expression need to be differentiated.
I run the entire test suite with that differentiation rule and there is one problem with the symbolic Jacobian for state sets in Modelica.Fluid.Examples.HeatingSystem. Willi, can you explain why it fails?

[Willi Braun]

For some reason the symbolic jacobian for dynamic state selection has 18 equations and 19 variables. So that's the reason it fails, but that needs some further investigation.

[Adrian Pop]

For example some models in Buildings fail with differentiation of homotopy issues:
​https://test.openmodelica.org/libraries/Buildings/files/Buildings.Electrical.AC.OnePhase.Conversion.Examples.ACACTransformer.err

Lennart added a case for handling homotopy in the Differentiate module but is commented out due to Jacobian issues.

Willi can you have a quick look?

[Willi Braun]

The actual reason for commenting it out was and is somehow the index reduction. In the past we had also issues with this rule in index reduction with avm models.
BTW: Adrian, are they still checked from time to time?
Okay I'll have a other look into it.
However, perhaps we should activated it anyway, even if there are models that fails, but is most likely for other reasons and the rule is correct.

[Adrian Pop]

@wbraun. They were checked on each commit but unfortunately we haven't updated them in a while. I disabled the AVM test just yesterday until I get some time to update them.

[anonymous]

how about:
if init() then homotopy(diff(),diff()) else diff(actual)

[Francesco Casella]

I am not sure I understand what the problem is, also with reference to #3716.

For simulation code generation, the actual expression should be used.

For initialization code generation when lambda = 0, the simplified expression should be used.

For initialization code generation when lambda > 0, lambda*actual + (1-lambda)*simplified should be used.

Any problem with this?

Also the proposal in comment:8 seems just fine to me.

Please close #3716 when this is fixed.

[Lennart Ochel]

I've already implemented proper handling of homotopy for different stages (i.e. simulation and initialization). That means that we always generate just the actual expression for simulation, simplified expression for initialization with lambda=0 and homotopy expression for initialization with lambda <> 0.

The problem is index-reduction which is performed before splitting up initialization/simulation. The equations that are generated during index reduction will later be optimized for simulation/initialization and need therefore to have all the information.

I just reassign this to me.

[Lennart Ochel]

I've created ​PR453 for this.

[Francesco Casella]

For the index reduction analysis, you should just use the actual expression. The index is related to the simulation equations, not to the initialization ones.

[Lennart Ochel]

This is fixed with bd443007596444f06b1af5b0b4f58e4123964e8d/OMCompiler.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed