connect subconnectors of hierarchical connectors directly, without extra node

thorade commented 4 years ago

I have a customer who defined two hierarchical connectors:

connector Hier_control
  Modelica.Blocks.Interfaces.RealOutput y;
  Modelica.Blocks.Interfaces.BooleanInput setOff_component;
  Modelica.Blocks.Interfaces.BooleanOutput setOff_control;
end Hier_control;

connector Hier_component
  Modelica.Blocks.Interfaces.RealInput y;
  Modelica.Blocks.Interfaces.BooleanInput setOff_control;
  Modelica.Blocks.Interfaces.BooleanOutput setOff_component;
end Hier_component;

When connecting these two connectors to each other, everything works as expected. Sometimes the customer would like to connect MSL source blocks instead, e.g. a Sine source and a Boolean constant source. This is also possible, but Dymola forces me to introduce a "Node", and then connect to the node.

OCT seems to also accept connections directly to the subconnectors, using dot notation, like this:

connect(booleanStep.y, valveHie.hier.setOff_control);
connect(sine.y, valveHie.hier.y) ;

When checking this code in Dymola, I get a warning message:

Connect argument was not one of the valid forms, since valveHie is not a connector.

To me, this message does not make sense, because the first part (booleanStep, or valveHie) never is a connector, but a component instance. The model still compiles and simulates without further errors, but the result is not as expected (connected variables are not equal).

From the specification (chapter 9, especially 9.3 and 9.1), I cannot directly see whether this is illegal, and if it is illegal, I do not understand the motivation. What is wrong or dangerous or ambigous with directly using dot notation?

For exandable connectors, a similar discussion is in ticket #428. But I would say expandable and hierarchical are a bt different, because in a hierarchical connector I know in advance what signals are present.

thorade commented 4 years ago

Full test model is here:

package HierarchicalConnector

  connector Hier_control
    Modelica.Blocks.Interfaces.RealOutput y;
    Modelica.Blocks.Interfaces.BooleanInput setOff_component;
    Modelica.Blocks.Interfaces.BooleanOutput setOff_control;
  end Hier_control;

  connector Hier_component
    Modelica.Blocks.Interfaces.RealInput y;
    Modelica.Blocks.Interfaces.BooleanInput setOff_control;
    Modelica.Blocks.Interfaces.BooleanOutput setOff_component;
  end Hier_component;

  model ValveHie
    Hier_component hier
    annotation (Placement(transformation(extent={{-108,-14},{-88,6}})));
    Modelica.Blocks.Sources.BooleanConstant booleanConstant
    annotation (Placement(transformation(extent={{2,-2},{-18,18}})));

  equation 
    connect(booleanConstant.y, hier.setOff_component)
      annotation (Line(points={{-19,8},{-56,8},{-56,-3.95},{-97.95,-3.95}}, color={255,0,255}));
  end ValveHie;

  model ControlHie
    Hier_control hier annotation (Placement(transformation(extent={{76,-4},{96,16}})));
    Modelica.Blocks.Sources.BooleanConstant booleanConstant
    annotation (Placement(transformation(extent={{-48,10},{-28,30}})));
    Modelica.Blocks.Sources.Constant const
    annotation (Placement(transformation(extent={{-62,-36},{-42,-16}})));

  equation 
    connect(booleanConstant.y, hier.setOff_control)
      annotation (Line(points={{-27,20},{30,20},{30,6.05},{86.05,6.05}},
      color={255,0,255}));
    connect(const.y, hier.y)
    annotation (Line(points={{-41,-26},{22,-26},{22,6.05},{86.05,6.05}},
    color={0,0,127}));
  end ControlHie;

  model System_with_Hierarchical
    Modelica.Blocks.Sources.Sine sine(
      freqHz=1,
      offset=0.2,
      startTime=0.1,
      phase=0.00174532925199432778)
      annotation (Placement(transformation(extent={{-80,0},{-60,20}})));

    Modelica.Blocks.Sources.BooleanStep booleanStep
      annotation (Placement(transformation(extent={{-80,40},{-60,60}})));

    ValveHie valveHie annotation (Placement(transformation(
          extent={{58.0,2.0},{78.0,22.0}},
          rotation=0.0,
          origin={0.0,0.0})));

    ControlHie controlHie
      annotation (Placement(transformation(extent={{-82,-42},{-62,-22}})));

    ValveHie valveHie1
      annotation (Placement(transformation(
          extent={{52.0,-42.0},{72.0,-22.0}},
          rotation=0.0,
          origin={0.0,0.0})));

  equation 
    connect(booleanStep.y, valveHie.hier.setOff_control)
      annotation (Line(points={{-59,50},{-11.4,50},{-11.4,11.6},{58.2,11.6}}, color={255,0,255}));
    connect(controlHie.hier, valveHie1.hier)
      annotation (Line(points={{-63.4,-31.4},{-22.6,-31.4},{-22.6,-32.4},{52.2,-32.4}}, color={0,0,0}));
    connect(sine.y, valveHie.hier.y)
      annotation (Line(points={{-59,10},{-0.4,10},{-0.4,11.6},{58.2,11.6}}, color={0,0,127}));
  end System_with_Hierarchical;
end HierarchicalConnector;

HansOlsson commented 4 years ago

For exandable connectors, a similar discussion is in ticket #428. But I would say expandable and hierarchical are a bt different, because in a hierarchical connector I know in advance what signals are present.

It is true that they differ, but the reason the original issue in #428 is illegal still applies even if it is a normal connector and not a hierarchical one.

See section 9.1 in Modelica 3.3: "The connect-equation construct takes two references to connectors [a connector is an instance of a connector class], each of which is either of the following forms:

c1. c2 … cn, where c1 is a connector of the class, n>=1 and ci+1 is a connector element of ci for i=1:(n-1).
m.c, where m is a non-connector element in the class and c is a connector element of m."

The ... is in neither of those forms.

Originally posted by @modelica-trac-importer in https://github.com/modelica/ModelicaSpecification/issues/428#issuecomment-435601113

thorade commented 4 years ago

Thank you Hans for the quick answer. I still fail to see why it would be problematic to use dot notation for predefined hierarchical connector.

HansOlsson commented 4 years ago

As I see it there are two reasons for this restriction:

One is the conceptual in terms of breaking encapsulation. Literally "putting a screwdriver in an electrical socket"; as the hierarchical connector is designed as one object that you should connect to as a whole. Using a "node" allows circumventing this in special cases, without making it too easy.
The other is that the original design had operations on connectors based on whether they are connected or not (e.g. cardinality), and connecting to parts cause problems for that. Even if we are deprecating cardinality we still have connectorSizing with similar issues.

I'm not saying that these argument are super-strong, but on the other hand I don't really see why a hierarchical connector is used in this example; to me it more seems like a number of weakly related connectors than a hierarchical connector.

thorade commented 4 years ago

Thanks. For the conceptual part, I thought of it more like the GPIOs on a board like a Raspberry, where you can connect each GPIO on its own, or you can use an extension board or shield that connects to all pins simultaneously (hope I got the terms right). In the example, the different connectors are not strictly related, it is just for convenience, so that one single connection between two components is sufficient instead of multiple connections.

qlambert-pro commented 4 years ago

@HansOlsson On the one hand, I understand that this use of hierarchical connector may not have been the intended use case. On the other hand wanting to simplify the interface of a model that has a lot of connectors by grouping them seems like a valid request. On a certain level, there is also some precedent for that in the sense that it is possible to have subscripts, in the reference to the connector.

HansOlsson commented 4 years ago

I realized one thing.

The arguments for not connecting to parts of a connector wouldn't apply if we introduced a new variant of connector. To avoid introducing a new keyword let's call it 'connector block' (as it is a block of connectors). The rules would be:

Extend the allowed connections for 'connector block' as above.
All non-parameter components of a 'connector block' must be of restricted type 'connector', 'connector block', or 'expandable connector'. (At first I though about forbidding flow, stream, overdetermined - but them I realized that this was simpler.)
A component of a 'connector block' may not be used as input to cardinality.
An array component of a 'connector block' may not have a connectorSizing annotation.

It seems as if this would be fairly straightforward to implement, and the one making the model would make it really clear whether "poking" inside the connector is allowed.

Added: However, we have many other issues to consider.

HansOlsson commented 4 years ago

I realized one thing.

The arguments for not connecting to parts of a connector wouldn't apply if we introduced a new variant of connector. To avoid introducing a new keyword let's call it 'connector block' (as it is a block of connectors). The rules would be:

Extend the allowed connections for 'connector block' as above.

All non-parameter components of a 'connector block' must be of restricted type 'connector', 'connector block', or 'expandable connector'. (At first I though about forbidding flow, stream, overdetermined - but them I realized that this was simpler.)

A component of a 'connector block' may not be used as input to cardinality.

An array component of a 'connector block' may not have a connectorSizing annotation.

It seems as if this would be fairly straightforward to implement, and the one making the model would make it really clear whether "poking" inside the connector is allowed.

Added: However, we have many other issues to consider.

Phone meeting agree on general direction.

modelica / ModelicaSpecification

connect subconnectors of hierarchical connectors directly, without extra node #2543