Clarification on fixed point iterations for pre()

[PeterMeisrimelModelon]

Consider the following model:

model min_ex
    Real x(start = 3);
    Real z(start = 0);
    Real t;
    Boolean b;
    discrete Real output_state(start = 0);
equation
    b = x < 2;
    x + t + z = 3;
    if b then
        t = 2*time;
    else
        t = time;
    end if;
    if x < 1.9 then
        z = 1;
    else
        z = 0;
    end if;
    when b then
        output_state = x;
    end when;
end min_ex;

• Initial solution for x is 3, and decreases as time increases as per t = time.
• At time = 1 (x = 2), there will be an event:
  • first: b becomes true => t becomes 2, new solution: x = 1
  • second: x < 1.9 becomes false => z becomes 1, new solution: x = 0
  • Note: This example can be expanded to make this an N step process.
• The when construct is to capture the value of x with the change in b (which was also the intention of the modeller), but what is the expected value?
  • 1 as the value of the iteration when b first becomes true?
  • 0 as the final value after the value for x has been fully resolved? (which was what the modeller expected)
  • Something else?
  • The modeler expected this value to be 0 in this reproducer
• The example can simplified by replacing the use of b with x < 2. This gives fewer dependencies, while effectively being the same model.

What should be the correct solution here and more importantly: why?

Disclaimer: OCT currently yields output_state = 1 for this model. We suspect this is not the correct result, but it is not evident to us from the specification.

Specification for pre()
Chapter 3 Operators and Expressions ‣ Modelica® Language Specification version 3.7 states a lot of things, but it is still not quite clear:

• What does “mask event iteration“ mean to begin with?
• Is this type of example the non-normative text refers to with “global fix point iteration scheme, similarly to the event iteration“?
  • I.e., a fixed point iteration that resolves the chain of “if” evaluations required to compute “x“, before evaluating the when block for the first time.

Edit: fixed mistake pointed out in comment.

[HansOlsson]

To me the value is 0 (or close to it), but there's more to it.
The

    b = x < 2;
    x + t + z = 3;
    if b then
        t = 2*time;
    else
        t = time;
    end if;
    if x < 1.9 then
        z = 1;
    else
        z = 0;
    end if;

involves solving a mixed system of equations (which is normally done using iterations) - but not event iterations.
Thus 0 is the final value for x during the event iteration where b changes.

Appendix B states that the mixed system of equations are solved for given values of pre(), which is consistent with this. However, it just says that "specialized algorithms" are needed, and doesn't repeat the statement about event iteration if v<>pre(v) so it could be clearer.

Note that the description above has an error, b becomes true, not false at time 2.

Compare it with the following model:

model min_ex2
    Real x(start = 3);
    Integer z(start = 0);
    Real t;
    Boolean b;
    discrete Real output_state(start = 0);
equation 
    b = x < 2;
    x + t + pre(z) = 3;
    if b then
        t = 2*time;
    else
        t = time;
    end if;
    if x < 1.9 then
        z = 1;
    else
        z = 0;
    end if;
    when b then
        output_state = x;
    end when;
end min_ex2;

Here b changes means x=1 so output_state=1, but then you do an additional event iteration to get x=0.

[HansOlsson]

And, yes, this is what is referred to as “global fix point iteration scheme, similarly to the event iteration“?

The "mask event iteration" is unrelated and more refer to skipping (or "masking") event iterations even if x<>pre(x) when pre(x) only occurs inside bodies of when-clauses:

when b then
      output_state = pre(x);
  end when;

[PeterMeisrimelModelon]

Thanks for the clarifications and the additional example!

Trying to map your explanation to the current language used for pre() for potential clarifications:

• The unknowns in the example are b, pre(b), t, x, z and output_state.
• Due to containing a mixed algebraic system, one likely uses an iterative scheme (global fix point iteration scheme) to determine primarily x. Here the distinction that this is similar to but not event iteration, since this iteration does not include the pre() updates.

I think this part is sufficiently clear by just

The language allows mixed algebraic systems of equations where the unknown variables are of type Real, Integer, Boolean, or an enumeration. These systems of equations can be solved by a global fix point iteration scheme, similarly to the event iteration.

I suppose one could spell-out the difference to the event-iteration more explicitly and/or that these may be requiring within event-iterations.

To me, the by fixing the Boolean, Integer, and/or enumeration unknowns during one iteration. adds more confusion.

1. Having a stray iteration when the same paragraph talks about event iteration and (global) fix point iterations.
2. Is fixing the [...] unknowns trying to refer to not-updating the pre() values? I.e., a clarification of the difference global fix point iteration vs. event iteration? Or should it be considered part of the quality of implementation part, if one had e.g., multiple constructs from the example within the same model? Or something else?
3. It does not mention Real unknowns here? Is this simply an oversight?

For the appendix B; maybe add a reference/pointer to the pre-operator? I might be missing some intricacies about the exact examples that are references there though.

[henrikt-ma]

What is the meaning global when talking about fix point iteration?

[henrikt-ma]

Anyway, this was a tricky question, but I believe @HansOlsson explained it well.

Maybe it goes without saying, but the reason one shouldn't expect output_state to end up being exactly 0 is that the accuracy is dependent on how good the tool is at making x < 2 change when x is infinitesimally less than 2. I'd say that the limit is the ideal and most correct behavior, making output_state exactly zero in the end, but I don't have that sort of expectation on Modelica tools today.

[HansOlsson]

What is the meaning global when talking about fix point iteration?

I believe the explanation is as follows:

The fix point iteration could be done over all equations and variables (globally) - or for a sub-set (locally).

For pre(b) I don't know exactly how to do it for a sub-set (in a safe way), but the global variant iterate until b=pre(b) makes perfect sense.
For a mixed system of equations where we have equations b=boolEq(x); implictEq(b, x)=0; (solving implictEq and then computing boolEq) I guess both may be possible, but the local variant makes more sense (but there are complications).

Should be explained in a better way.

[henrikt-ma]

Alright, globally only ended up within parentheses in your answer, so I suppose it isn't that important after all.

Then I'd prefer speaking of these two fixed point iterations:

• Mixed system iteration: The ad-hoc, more or less de-facto standard, way of solving blocks of equations in both Real and non-Real variables. Since I believe that the technique is so widely used in Modelica tools, I find it a bit unfortunate that we can't give it an official name due to not being a standardized procedure. Perhaps, the specification could non-normatively mention the idea of iterating between solving for the discrete-valued and the continuous-valued variables in the block, and that this is commonly known as performing a mixed system iteration?
• Event iteration: The standardized procedure of solving the equations over and over until b == pre(b) (for all b such that…). Yes, global iteration is how the semantics are defined in the specification, but of course tools may do it more efficiently if they know they will obtain the same results.

We don't break down the event iteration in System Modeler, but if I'd give it a try, I would have tried building a dependency graph of "the equation blocks" we have today, where the dependencies between the blocks would be augmented with edges for pulling b and pre(b) into the same strong component of equation blocks (plus something for reinit). I then believe it should be possible to perform the event iteration for one of these strong components at a time, with no iteration at all for many of the strong components.