Provide correct and efficient event handling in --daeMode

[Francesco Casella]

AnHeuermann reports in ticket:5843#comment:1:

Let's start with a first class of problems:

Verification failed
See e.g. Modelica.Blocks.Examples.BooleanNetwork1.

This model has integer and boolean variables, which are not treated correctly. The values are not updated after events and remain constant.
Enabling tearing (minimal, cellier, omc) and looking at the tearing dumps shows that no discrete variables are moved to inner variables. That makes sense for ode case, since there are no loops. But for the dae mode we want to causalize the discrete variables.

And how should the dae mode handle discrete state variables?

Actually when looking at the discrete states we have for ode

* Number of discrete states: 12 (falling.not_u,rising.u,set1.y,changing.u,triggeredAdd.y,booleanTable.combiTimeTable.nextTimeEventScaled,onDelay.t_next,onDelay.delaySignal,$whenCondition3,$whenCondition2,booleanTable.combiTimeTable.nextTimeEvent,rSFlipFlop.pre.u)

and for dae the dump is not working(?):

 * Number of states: 0 ()
 * Number of discrete states: 0 ()

And why is $whenCondition3 a state in the first case at all?

[Francesco Casella]

As I understand it, the starting point is the synchronous data flow principle, see ​Section 8.4 of the Modelica Specification.

When using daeMode, I understand you go through index reduction, state selection causalization and tearing anyway, the only difference being that implicit equations (corresponding to strong components of the E-V graph) are not solved by a nested solver but are passed as residuals to the DAE solver. So, the DAE solver gets a DAE problem where the unknowns are the state derivatives and the tearing variables of the nonlinear system, while it doesn't explicitly see all the causalized and torn equations and variables.

Is this correct?

Now, when events are triggerd, the synchronous data flow mandates to solve the continuous equations and the active discrete equations simultaneously (in principle). In practice, if the discrete equations are segregated in strong components having only discrete variables as unknowns, this is easy, because you just go through all the ordered assigments of the BLT, including those matched to discrete variables that show up in active discrete equations. If discrete and continuous equations are not segregated in separate strong components, then you can issue an error and suggest to add some suitable pre operator to decouple the mixed continuous-discrete algebraic loops, possibly causing some event iteration.

I guess if -daeMode did this properly, most MSL models with events should work just fine. Do I miss something?

In fact, there is another potentially interesting case, which may be worth further investigation. In the case of power system models (such as those in the PowerGrids library), the DAEs include one very large strong component (possibly with 10.000s or 100.000 of equations), corresponding to the equations describing the grid, the loads, and the trasformers. These equations are phasor-based, so they neglect the electromagnetic dyamics and assume an instantaneous relationship among each and every voltage and current in the grid.

One potential problem in this case is that one should avoid this large system of equations to also include some discrete variables (e.g. positions of tap changers in transformers), otherwise the huge mixed continuous-discrete system could be really difficult to solve. However, I guess that proper discipline in including the right pre operators on logic variables should avoid this kind of occurence, turning it into event iteration.

One thing which is probably missing in this case is the use of sparse algebraic solvers to handle this phase, e.g. solving the continuous and active discrete system equations by means of a sparse solvers, see #4034. Unfortunately @wbraun left before this thing was tackled. We'll soon publish the ScalablePowerGrids testsuite that should contain several test cases which are appropriate to test this feature.