Hierarchy of stream connectors.

[qlambert-pro]

According to my interpretation of section 15.1, the following is invalid.

model Model1
  connector C
    flow Real n_flow;
    stream Real h_outflow;
    Real p;
  end C;

  connector D
    flow Real n_flow;
    stream Real h_outflow;
    Real p;
  end D;

  connector E
    C c;
    D d;
  end E;

  
  E e(c(p = 1, h_outflow = 2), d(p = 4, h_outflow = 3));

equation

end Model1;

e is a stream connector since it has variables with stream prefix, but it also has two flow variables with flow prefix.

What is the consensus?

[qlambert-pro]

Here is a model somewhat dual to the one above, which I would consider valid.

model Model2
  connector C
    flow Real n_flow;
    Real p;
  end C;

  connector D
    stream Real h_outflow;
    C c;
  end D;


  D d( c.p = 1, h_outflow = 2);

equation

end Model2;

[casella]

@qlambert-pro I'll give you my user's perspective, having participated in the definition of the stream connectors 15 years ago.

The rationale of stream connector is to model advection between different connected components. The idea is describe a fluid that flows carrying some specific conveyed quantities, e.g. specific enthalpy or mass fractions, which are governed by balance equations in connection sets that involve the products of the conveyed quantities with the flows.

From a modeller's point of view Model1 makes perfect sense: you have a component that has two physical flanges d and e, each one describing a fluid flow. The two fluids can be different and have different flow rates; as such, they should be handled separately, they are only grouped as sub-connectors into the same connector e for convenience. For example, if you have a system where multiple components must handle a fuel flow and an oxidizer flow, which are always carried in twin pipes, you can bundle them together in a connector of type E, so you only need one connect statement instead of two when connecting two components.

Another possible application is two-phase inhomogeneous flow: in this case there would be only one physical flange represented by connector e, but there will be two flows through it, a liquid flow through sub-connector c and a gas flow through connector d. The two flows can be different (they could even have opposite sign), and the balance equations of the inStream() and actualStream() operators will have to be handled separately.

On the contrary, Model2 doesn't make much sense to me.

@hubertus65, @rfranke, @Harisankar-Allimangalath, @dzimmer, @thorade can comment on that, but I guess what I wrote above should be the established consensus among the users.

I re-read the specification carefully, and I agree it is not clear from this point of view. Section 15 was written having a simple ,flat connector in mind, not a hierarchically structured one, and it was already complicated enough 😅. Section 9 instead allows to build connectors containing other connectors. Unfortunately, Section 9 does not introduce any terminology for that, e.g. defining "hierarchically structured connectors" or "sub-connectors", so the link between the two sections is ambiguous.

Maybe the issue can be resolved by indicating in Section 15 that the flow variable and the corresponding stream variables are located "at the same level", but I am not sure what is the right terminology for that. @qlambert-pro you can propose an amendment and I can comment on that. @HansOlsson can also help with that for sure.

[HansOlsson]

I agree, and to me the "at the same level" would be kind of redundant - the idea is that C and D are stream connectors, since they contain a declaration with stream, but E and Model1 are not stream connectors (Model1 is not even a connector), even if there is a stream connector inside them.

It may still be possible to add it, but we have to be careful.

The risk is that by adding "at the same level" at one place we will then have to consider other constructs, since either they also need the restriction "at the same level" or they should consider sub-components.

[casella]

I agree, and to me the "at the same level" would be kind of redundant

Possibly, but @qlambert-pro's initial remark in the ticket seems to imply otherwise.

From a modelling point of view, the requirement of the flow variable and stream variable(s) to be "at the same level" is what we meant. We never meant to be looking for the flow variable one level up or down, in case of structured connectors. Stating this in Section 15 would limit the scope of this restriction to stream variables, so it shouldn't impact other construct.