Event iteration convergence and reinit

[henrikt-ma]

There was some discussion about event iteration in #578, but I don't see that the current specification text makes the relation between reinit and event iteration clear. What we have is this:

\lstinline!reinit! does not break the single assignment rule, because \lstinline!reinit(x, expr)! in equations evaluates \lstinline!expr! to a value, then at the end of the current event iteration step it assigns this value to \lstinline!x! (this copying from values to reinitialized state(s) is done after all other evaluations of the model and before copying \lstinline!x! to \lstinline!pre(x)!).

and the criterion for convergence of the event iteration:

Before the start of the integration, it must be guaranteed that for all variables \lstinline!v!, \lstinline!v = pre(v)!.

However, this doesn't mention that the reinit essentially invalidates the "current event iteration step", meaning that the event iteration convergence test is not meaningful right away.

Here is a model which illustrates the need:

model ReinitLadder
  Real x(start = 1, fixed = true);
equation
  der(x) = -1;
  when x < 0 then
    reinit(x, 0.2);
  elsewhen x > 0.1 then
    reinit(x, 0.4);
  elsewhen x > 0.3 then
    reinit(x, 0.6);
  elsewhen x > 0.5 then
    reinit(x, 0.8);
  elsewhen x > 0.7 then
    reinit(x, 1.0);
  end when;
  annotation(
    experiment(
      StopTime = 3.0
    )
  );
end ReinitLadder;

[henrikt-ma]

In case it helps the discussion, here is a variant with explicit Boolean variables:

model ReinitLadderExpanded
  Real x(start = 1, fixed = true);
  Boolean b0 = x < 0;
  Boolean b1 = x > 0.1;
  Boolean b3 = x > 0.3;
  Boolean b5 = x > 0.5;
  Boolean b7 = x > 0.7;
equation
  der(x) = -1;
  when b0 then
    reinit(x, 0.2);
  elsewhen b1 then
    reinit(x, 0.4);
  elsewhen b3 then
    reinit(x, 0.6);
  elsewhen b5 then
    reinit(x, 0.8);
  elsewhen b7 then
    reinit(x, 1.0);
  end when;
  annotation(
    experiment(
      StopTime = 3.0
    )
  );
end ReinitLadderExpanded;

[HansOlsson]

It could be made clearer, but as far I can see it is already guaranteed.

Reason:

• reinit must be inside a when-statement https://specification.modelica.org/master/equations.html#reinit
• when-statements are activated when some boolean b triggers, i.e., satisfies b and not pre(b) https://specification.modelica.org/master/equations.html#defining-when-equations-by-if-expressions-in-equality-equations

Thus it is impossible that a reinit is activated and all b==pre(b).

[henrikt-ma]

Aren't you mixing up two different rounds of the event iteration? The b != pre(p) triggers one round of event iteration, but the one it triggers is the one where the reinit runs, not the next round, right?

[HansOlsson]

Aren't you mixing up two different rounds of the event iteration? The b != pre(p) triggers one round of event iteration, but the one it triggers is the one where the reinit runs, not the next round, right?

Not as far as I can see:

1. Iteration 1, we compute a new b
2. Iteration 1, b and not pre(b) so reinit will be triggered
3. Iteration 1, other stuff
4. Iteration 1 (end of), reinit is executed
5. Since b != pre(b) (as b=true and pre(b)=false) we will start another event iteration:
6. Iteration 1 end or 2 start, pre(b):=b
7. Iteration 2, we compute a new b
8. ...

[henrikt-ma]

You are right. My reasoning was based on a misconception about the reason behind the condition to check for any b != pre(b). My understanding was based on the special role of variables appearing inside pre(…), where the underlying reason for b != pre(b) to trigger another round of event iteration was that the value of pre(b) used in the current iteration would turn out to be outdated after the update pre(b) := b. Thus, a possible way to describe my mistake is that I only thought about outdated values of discrete-time states, while forgetting about the possibility that also continuous-time states could be outdated.

While seeking for an explanation for my why of thinking in the explanatory parts of the specification, I encountered this non-normative observation:

If \lstinline!v! and \lstinline!pre(v)! are only used in \lstinline!when!-clauses, the translator might mask event iteration for variable \lstinline!v! since \lstinline!v! cannot change during event iteration.

What is the cannot change during event iteration supposed to mean here?