DAE index reduction in clocked partitions

[Rüdiger Franke]

Clocked partitions may contain high index DAEs, for instance when basing a discrete-time controller on an inverse continuous-time model, see:

Modelica_Synchronous.Examples.Systems.ControlledMixingUnit
Modelica_Synchronous.Examples.Systems.EngineThrottleControl

OpenModelica produces wrong results for such models.

OpenModelica currently discretizes differential equations by replacing der(x) with (x - previous(x))/interval() during clock partitioning (Euler).

OpenModelica should reduce the DAE index inside a clocked partition prior to the discretization.

See the failing test synch.mos (ControlledMixingUnit)
​https://github.com/OpenModelica/OpenModelica-testsuite/commit/ee09ab4b8551ce22514b4315cb04b88fdf2843ed

[Lennart Ochel]

I think inline integration should be applied after index-reduction, because currently there are no differential equations anymore when clocked partitions enter index-reduction.
So one option would be to move the inline integration from the partitioning module to a separate optimization module, which is called between index-reduction and post-optimization. What do you think?

Later on, we could merge that module together with the inline integration module that is developed by one of Bernhard Bachmann's students.

[Rüdiger Franke]

The Synchronous module identifies all previous variables, i.e. clocked states. This can only be done after index reduction. It might be needed to split the Synchronous module into clock partitioning before and discrete state detection after index reduction. The current index reduction would surely need to be extended to loop over all clocked partitions.

Alternatively: would it be thinkable to let the Synchronous module call a function for index reduction for a clocked partition?

[Lennart Ochel]

The current index-reduction implementation depends on the pre-optimization, e.g. module findStateOrder, which is currently called after the Synchronous module. It would be possible to call index-reduction for clocked partitions within pre-optimization, but I don’t think that is a good idea to change the transformation process in that way.

I would prefer to split the Synchronous module into a pre- and a post-index-reduction procedure.

[Rüdiger Franke]

​PR1391 along with ​commit d32ecb make ControlledMixingUnit work.

Some more issues show up when replacing ExplicitEuler with ImplicitEuler. See the following example:

model ControlledMixingUnit2
  extends Modelica_Synchronous.Examples.Systems.ControlledMixingUnit(
    periodicClock1(solverMethod="ImplicitEuler"));
end ControlledMixingUnit2;

ImplicitEuler leads to the introduction of algebraic loops. No Jacobians and no ModelStructure are generated though!

Moreover, there is a linear torn system of dimension 1 -- shouldn't this be solved analytically?

Last but not least, the C runtime does not generate code for algebraic loops in clocked partitions.

[Rüdiger Franke]

With ​PR1391 the ControllecMixingUnit example of Modelica-Synchronous validates now!

Unfortunately some other validations failed tonight. Is this related to the change or did possibly something change with the interpretation of results at the same time -- ramps for discrete variables?

See e.g. Modelica_Synchronous.Examples.Elementary.IntegerSignals.Hold: ​https://test.openmodelica.org/libraries/Modelica_Synchronous_cpp/files/Modelica_Synchronous.Examples.Elementary.IntegerSignals.Hold.diff.shiftSample.y.html

[Lennart Ochel]

Replying to rfranke:

Unfortunately some other validations failed tonight. Is this related to the change or did possibly something change with the interpretation of results at the same time -- ramps for discrete variables?

I am afraid that this is due to my changes. I will check …

[Francesco Casella]

Milestone moved to 1.13.0 due to 1.12.0 already being released.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed