Removed conditional components cause type mismatches

[casella]

Please check ​Modelica.Fluid.Examples.TraceSubstances.RoomCO2. The NF fails with

[Modelica trunk/Fluid/Vessels.mo:279:9-280:89:writable]
Error: Type mismatch in binding portsData_diameter_internal = 
volume.portsData.diameter, 
expected subtype of Real[2], got type Real[0].

[perost]

The error is actually correct, since the component is defined as:

RealInput[nPorts] portsData_diameter_internal =
  portsData.diameter if use_portsData and nPorts > 0;

and portsData.diameter is defined as:

parameter VesselPortsData[if use_portsData then nPorts else 0] portsData

I.e. the component only has a valid binding if it actually exists, and the specification is a bit fuzzy on the subject of how valid a removed conditional components must be.

But since this is used in the MSL we should probably handle this in the same way as if-equations. I.e. save any errors that occur during the typing of conditional component bindings, and only display them if they're not removed during the flattening.

[casella]

Replying to perost:

The error is actually correct, since the component is defined as:

RealInput[nPorts] portsData_diameter_internal =
  portsData.diameter if use_portsData and nPorts > 0;

and portsData.diameter is defined as:

parameter VesselPortsData[if use_portsData then nPorts else 0] portsData

I.e. the component only has a valid binding if it actually exists, and the specification is a bit fuzzy on the subject of how valid a removed conditional components must be.

But since this is used in the MSL we should probably handle this in the same way as if-equations. I.e. save any errors that occur during the typing of conditional component bindings, and only display them if they're not removed during the flattening.

If the specification is fuzzy I would tend to consider this as valid, and maybe open a ticket for a further clarification in version 3.5.

The construct used in that model is actually very convenient and natural: if the conditional component exists, the binding is considered, otherwise it is just ignored. If supporting this is not too complicated and not clearly against the current specification, I would go for it.

[perost]

Fixed in cd5427b by allowing conditional components that are removed to have invalid bindings. Also improved a bit in 5047996 by simplifying trivial expressions such as {e[i] for i in 1:1} into e[1] (i.e. array constructors that result in a single element), which the RoomCO2 models contained a lot of.

The model still doesn't pass the backend though, it complains that an independent subset of the model is imbalanced now.

[casella]

Replying to perost:

The model still doesn't pass the backend though, it complains that an independent subset of the model is imbalanced now.

There are several Modelica.Fluid models that fail with the NF because of imbalanced systems. In fact, the system is balanced after flattening, so it looks like the back-end doesn't like something in the NF output and messes up with the optimization of the system of equations. I'll look that up asap.