Local balance

[HansOlsson]

I believe this handles all of the case, but there might be some remaining issue.

[qlambert-pro]

An alternative to the count here is:

• For over-determined variables and equations, where the cardinality of the type is c and the size of the residual is n:
  • Over-determined connector variables are counted as n variables.
  • Declaration and equality equation of over-determined type are counted as c.
  • Connections.root and Connections.branch are counted as adding n - c equations.
  • Connections.potentialRoot is counted as adding n - c if the root is selected and 0 otherwise.
  • Generated potential equations are counted as adding n equations.

[qlambert-pro]

Which would mean that we can keep the intuition about the flow variables being solved in the outside scope.

[HansOlsson]

To me changing to non-causal non-flow as currently proposed works, and that solves the main issue - without changing too much else.

I'm sure there are alternatives that work equally well, but I'm not sure about the proposed change above - in particular:

• Currently Connections.root and selected Connections.potentialRoot don't contribute themselves, instead the model has other equations for the roots (using Connections.isRoot for potential ones). That's why root-less trees need special care - and I find it easier to explain that specific exception than the other cases.
• Similarly Connections.branch don't need to contribute themselves.
• If we were to improve it the main issue is to consider that the non-flow variables might not necessarily be Real, so we should ideally handle that as well, and in that case subtraction becomes messier. (The equalityConstraint and thus the flow must be Real as I recall).

[qlambert-pro]

To me changing to non-causal non-flow as currently proposed works, and that solves the main issue - without changing too much else.

The changes only touch part of the specs that were introduced 2 years ago though.

• Currently Connections.root and selected Connections.potentialRoot don't contribute themselves, instead the model has other equations for the roots (using Connections.isRoot for potential ones). That's why root-less trees need special care - and I find it easier to explain that specific exception than the other cases.

Right, I want to point out though that when @casella wrote the following comment, in particular:

In the case of System2, there are no rootless spanning trees, so there is no equation to add besides the component equations and the usual connection equations.

you didn't catch that in fact System2 has a rootless spanning tree. Also both @casella and my interpretation of your text was that the spanning tree should be a global one (up to the current instance) rather than a local one.
And arguably Connections.root, Connections.potentialRoot and Connections.branch do need to be considered to build the spanning tree so they do contribute for the purpose of balance checking.

If we were to improve it the main issue is to consider that the non-flow variables might not necessarily be Real, so we should ideally handle that as well, and in that case subtraction becomes messier. (The equalityConstraint and thus the flow must be Real as I recall).

I don't understand what is messy about subtracting integers, as I am talking about the cardinality of a type.

At the end of the day, we should go for an explanation that people understand, so it would be nice to have opinions from others.

For the record, the intuition in my proposal is that overdetermined connector variables and the equations where they appear should be counted according the size of the residual rather than the cardinality of their type. This is why potential equations are counted according to the size of the residual. Similarly, the presence, of branch and root in a model indicates that certain equations in that model will be counted as having a rank higher than they have, hence the subtraction to bring it to the size of the residual. potentialRoot is handled as root would be if the variable is selected as root.

[HansOlsson]

To me changing to non-causal non-flow as currently proposed works, and that solves the main issue - without changing too much else.

The changes only touch part of the specs that were introduced 2 years ago though.

• Currently Connections.root and selected Connections.potentialRoot don't contribute themselves, instead the model has other equations for the roots (using Connections.isRoot for potential ones). That's why root-less trees need special care - and I find it easier to explain that specific exception than the other cases.

Right, I want to point out though that when @casella wrote the following comment, in particular:

In the case of System2, there are no rootless spanning trees, so there is no equation to add besides the component equations and the usual connection equations.

you didn't catch that in fact System2 has a rootless spanning tree.

Because I made the usual mistake of considering the "global" balancing (where gen1, load, line1, and line2 are all included - and the root is in gen1.) (Or "global" in the sense of including the sub-components, but not fully "global").

Also both @casella and my interpretation of your text was that the spanning tree should be a global one (up to the current instance) rather than a local one.

Ideally both should work, as long as it is done consistently.

However, since that time, I've worked further on checking local balancing really locally, i.e., checking whether it is balanced without considering the contents of the sub-components (and not even instantiating them).

[HansOlsson]

I think it may help if we have clear names, so I propose something like:

• Global
• Inclusive (i.e., local including everything in sub-components)
• Local (i.e., local excluding sub-components)

When we first implemented the check to find the problematic component in Dymola it was checking the inclusive balance not the local one, and many of the subtler issues were missed - and it was missed for the specification as well. However, that is insufficient for template-models where the sub-components are of partial classes.

I also find the global one the most intuitive, and the local one the least intuitive; so I find it preferable if we don't modify the global count (at least not for simulation models), and try to minimize the change for the inclusive variant.

For the inclusive and local variants one can consider either the global spanning tree, or the spanning tree built only built from the considered information. In order to have a truly local handling only the latter makes sense.

I don't think we need the inclusive variant in the specification (but I think it may help the discussion if we avoid mixing it up with the other), but we need the global and local ones.

[henrikt-ma]

We kind of get the global count for free from the perfect matching rule:

There must exist a perfect matching of variables to equations after flattening, where a variable can only be matched to equations that can contribute to solving for the variable.

Hence, it is actually the local balance which becomes the more important balance for the specification to define.

[HansOlsson]

Regarding overdetermined connectors I believe I found a different more intuitive way of handling it, but will need to verify that it work first.

[HansOlsson]

A bit busy, but the basic idea is as follows (after a first iteration):

Revert the flow->non-flow change above, but add that each overdetermined connector in a sub-components are assumed to have a separate root.

The consequences are:

• It is simple, consistent, and fairly intuitive, we assume we have a root internally and flow-variables are determined externally, both for the model we check, and for its sub-components.
• It doesn't require examining the sub-components in detail for the local balance.
• It adds the correct number of equations, as connecting two connectors from sub-components generate a breakable branch that adds a residual equation, which has the exact same size as the number of flow-variables - and similarly in other cases.
• It relies on the non-poking restriction for Connections.branch (so no need for potential roots); which ensures that all edges for them will be breakable.
• It does require a separate handling of overdetermined connectors for the local balance compared to the global balance (the inclusive check can re-use the global one).

Suggested change

	For each declared component of specialized class \lstinline!block! or \lstinline!model!, it is the sum of the number of inputs and non-causal non-flow variables in the (top level) public connector components of these components (and counting the elements after expanding all records and arrays to a set of scalars of primitive types).
	For each declared component of specialized class \lstinline!block! or \lstinline!model!, it is the sum of the number of inputs and flow variables in the (top level) public connector components of these components (and counting the elements after expanding all records and arrays to a set of scalars of primitive types).
	If these public connector components contain overdetermined connectors they are assumed to have a separate root for each overdetermined connector.

[HansOlsson]

Suggested change

	\begin{nonnormative}
	For normal physical connector the number of flow variables matches the non-causal non-flow variables, but for overdetermined connectors there is a difference.
	\end{nonnormative}

Remove.