Do not count extra equations for public non-connector top level inputs with binding equations

[Francesco Casella]

Please check the Modelica.Mechanics.MultiBody.World model in OMEdit. The model is reported to be unbalanced.

The reason is that the model contain several declarations such as

input Real[3] x = {1, 2, 3};

The NF counts three binding equations and then three more equations for the top-level input. This is wrong; according to Section 4.7

The local equation size of a model or block class is the sum of the following numbers:

• ...
• ...
• The number of (top level) public input variables that neither are connectors nor have binding equations [i.e., top-level inputs are treated as known variables. This represents the number of binding equations that will be provided when the class is used.].

These public inputs have a binding equation, so they should not be counted again.

[Per Östlund]

This isn't really an NF issue as such, both the OF and the NF will flatten such a declaration to:

  input Real x[1];
  input Real x[2];
  input Real x[3];
equation
  x = {1.0, 2.0, 3.0};

I assume we do this to avoid having to split the binding and potentially cause performance issues. In this particular issue it might be better to split it, but we have to consider the general case.

The issue then is that CheckModel and the backend counting (which are two different implementations unfortunately) has no way of knowing that the equation was moved from a binding equation. I'm really not sure what the preferred solution here would be.

Cc:ing Karim in case he can give some backend perspective on the issue.

[Francesco Casella]

The easiest solution is probably to remove the top-level input qualifiers when moving the boundary to initial equations. When such a binding exists, there is no way to optionally override it from the outside (e.g. in an FMU).

[Per Östlund]

Fixed in a6556d32. checkModel(Modelica.Mechanics.MultiBody.World) now reports that the model is balanced.