Make sure daeMode works in a reliable way

[Francesco Casella]

--daeMode was introduced several years ago, particularly to handle models with large algebraic loops and/or models where the DAE description is sparse while the ODE one is not.

The current status of --daeMode is that it works well in a number of cases, but still fails rather frequently. For example, compare the success ratio of simulations of MSL 3.2.3 ​with odeMode and with ​daeMode.

We should

• investigate why these failures happen
• fix them if possible
• in case some cases cannot be reliable handled by --daeMode we should issue a proper error message during compilation, instead of generating a failing simulation code

[Andreas Heuermann]

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]

Replying to AnHeuermann:

You correctly pointed out a basic issue of daeMode, i.e., event handling. I think this deserves a ticket on its own, see #5860. Let's continue this discussion there and keep this as a container ticket.

[Karim Adbdelhak]

Replying to AnHeuermann:

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.

Yes and no. We want to causalize them for the event iteration during which we compute their values (for that we still use the ode system). For the regular simulation we consider them constant since they cannot change at any other point than during event iteration. For the actual DAE mode we don't have to causalize them. From the matching we get the equations that are matched to the discrete variables and call those only during event iteration.

At least this is the plan, there for sure might be bugs in this.

And how should the dae mode handle discrete state variables?

Well... i don't know if i get this discussion right, but from my understanding all discrete variables that have a pre value (appear inside a pre() call) are discrete states (Specification 3.4 section 16.4). They are not sates in the sense of differential equations since they don't have a derivative. The rule that they only change during event iteration still holds here i think so no special treatment necessary.

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 ()

Yea this has to be fixed....

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

I guess this is an alias of another condition that has appeared inside a pre() call or something like that. This would be something minimal i could think of:

when {c1, c2} then
  b1 = pre(c1);
  b2 = pre(c2);
end

c1 would be an alias of $whencondition1.

[Francesco Casella]

@Karim, can we please continue the discussion on #5860? Otherwise this ticket is soon going to become a mess, as soon as other daeMode issues pop up.

Thanks!