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]

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.