Local balance per type

[henrikt-ma]

Fixing #3763. Opening as draft to make clear that this is not ready for merging, and so that a discussion about how to do this can be started already.

In particular, I am looking for input on which type concepts to use when defining scalar type class, that is the formal categorization used to break down the local balance counting based on type.

Note that this PR contains some language fixing commits which have also been isolated in the PR #3817, so the changes of the present PR will look much cleaner once #3817 has been merged.

[HansOlsson]

I guess that should be cleaned up, right?

[henrikt-ma]

Yes, I wanted to have a discussion about the approach before proceeding with this detail.

[HansOlsson]

Check if it exists, otherwise make separate later PR for it.
Current rules state mixes integer and real in some odd way, instead of having type coercion integer->real.

[HansOlsson]

Looking at "6.7 Type Compatible Expressions" as far as I understand the current text is working, but I see the following issues:

• That section doesn't explicitly state that it applies to equations (it is instead stated in "8.3.1 Simple Equality Equations")
• It is complicated to find the specific rules for equations, as it also handles comparison operators, division and power.
• Thus the type coercion integer->real is stated twice.
• It is less clear for algorithms and multi-returning functions.

I can see the following minor improvements of that section:

1. State that it applies to equations as well and that the type compatible expression for the equation is the type of the equation; and if necessary add non-normative text giving the exact rules.
2. At the start state the rules use "Real or Integer expression" to explicitly handle the integer->real type coercion.

If we wanted to state that it applies after that coercion we would replace:

• If A is a Real expression then B must be a Real or Integer expression. The type of the full expression is Real, compare section 10.6.13, unless the operator is a relational operator (section 3.5) where the type of the full expression is Boolean.
• If A is an Integer expression then B must be a Real or Integer expression. For exponentiation and division the type of the full expression is Real (even if both A and B are Integer) see section 10.6.7 and section 10.6.5, for relational operators the type of the full expression is Boolean. In other cases the type of the full expression is Real or Integer (same as B), compare section 10.6.13.

by:

• If A is a Real expression then B must be a Real expression. The type of the full expression is Real, compare section 10.6.13, unless the operator is a relational operator (section 3.5) where the type of the full expression is Boolean.
• If A is an Integer expression then B must be a Integer expression. For exponentiation and division the type of the full expression is Real (even if both A and B are Integer) see section 10.6.7 and section 10.6.5, for relational operators the type of the full expression is Boolean. In other cases the type of the full expression is Integer, compare section 10.6.13.

I don't think that would be a significant enough improvement, and in particular I see issues when combining it with the next item.

3. Add that for binding equations, algorithms, and multi-returning function calls (?), if the left-hand-side is an Integer variable then the right-hand-side must be an Integer expression, something like:

• If A is an Integer expression (which must be a component reference) as the left-hand-side of an algorithm etc then B must be an Integer expression, and the type of the expression is Integer.
• Otherwise if A ...

I think it is best to discuss that in a separate PR.

[HansOlsson]

I find the use of "in" as part "locally balanced in Real" a bit confusing.
I would prefer some other word, but don't know exactly which ones, "locally balanced for Real", or "locally balanced in terms of Real"

[henrikt-ma]

We can give for a try…

[henrikt-ma]

I must say I still would prefer in over for, so maybe we should keep looking for the right word. Candidates:

• concerning
• considering

[HansOlsson]

"Considering" seems the best of them for me too, but looking at a thesaurus I also found "with regard to", "with respect to".

[HansOlsson]

I assume it was intended to be "Ready for Review", after merging the other one, right?

Looks good overall.
However, there are some minor comments.

[HansOlsson]

Language group: Will be a clear separation integer/enumeration; so cannot write an equation with inverse for that (example to be given).
In the worst case we would need to merge these types, but hopefully not needed.

[MarkusOlssonModelon]

Here is an example where separating integers/enumerations would break a currently working model:

model IntEnumExample
    type E = enumeration(A, B);
    function intToE
        input Integer i;
        output E e /*= E(i)*/;
    protected
        E values[:] = {E.A, E.B};
    algorithm
        e := values[i];
        annotation(Inline=false, inverse(i = eToInt(e)));
    end intToE;
    function eToInt
        input E e;
        output Integer i = Integer(e);
    algorithm
        annotation(Inline=false, inverse(e = intToE(i)));
    end eToInt;

    input Integer i(min=1, max=2, start=1);
    E e;
equation
    i = eToInt(e);
end IntEnumExample;

This model currently compiles and simulates in Modelon Impact. But it would not be valid with the proposed type separation, the only unknown variable has type E and the only equation has type Integer.

[henrikt-ma]

This model currently compiles and simulates in Modelon Impact. But it would not be valid with the proposed type separation, the only unknown variable has type E and the only equation has type Integer.

SystemModeler does not accept the model based on the following rule in https://specification.modelica.org/master/modelica-dae-representation.html:

The key difference between the two groups of discrete-time variables $z$ and $m$ here is how they are determined.
The interpretation of the solved form of \eqref{eq:dae-discrete-valued} is that given values for everything else, there is a closed-form solution for $m$ in the form of a sequence of assignments to each of the variables of $m$ in turn – there must be no cyclic dependencies between the equations used to solve for $m$.
Further, each of the original model equations behind \eqref{eq:dae-discrete-valued} must be given in almost solved form:

• Non-Integer equations at most requiring flipping sides of the equation to obtain the used assignment form.
  …

[HansOlsson]

Dymola doesn't accept it either.

[MarkusOlssonModelon]

This model currently compiles and simulates in Modelon Impact. But it would not be valid with the proposed type separation, the only unknown variable has type E and the only equation has type Integer.

SystemModeler does not accept the model based on the following rule in https://specification.modelica.org/master/modelica-dae-representation.html:

The key difference between the two groups of discrete-time variables
z
and
m
here is how they are determined.
The interpretation of the solved form of \eqref{eq:dae-discrete-valued} is that given values for everything else, there is a closed-form solution for
m
in the form of a sequence of assignments to each of the variables of
m
in turn – there must be no cyclic dependencies between the equations used to solve for
m
.
Further, each of the original model equations behind \eqref{eq:dae-discrete-valued} must be given in almost solved form:

• Non-Integer equations at most requiring flipping sides of the equation to obtain the used assignment form.
  …

You are right. In that case I have no concerns, should be fine to separate integers/enumerations.

[HansOlsson]

So, for now add something like:

Suggested change

	\textbf{TODO: Define equation-compatible, or use one of the existing compatibility definitions!}
	The type of the equation is defined by the type compatible expression for the equation in \cref{type-compatible-expressions}.