Could there be support for "stacked" connectors?

[gwr69]

Motivation

Regarding the support for connecting components with a multitude of connector classes my understanding as modeler and library developer of a system dynamics library (i.e., BusinessSimulation) is the following:

1. Composite connectors are hierarchical connectors intended for conveniently connecting many sub-connectors at once. Sometimes the need for making individual connections for elements within a composite connector arise (see #2543)
2. Expandable connectors are typically flexible connectors with elements being dynamically added during the modeling process, which make building large models much more convenient. While they are excellent for building larger models, I am a bit hesitant in using them for pre-built components, e.g., library classes.

The restrictions and caveats associated with the above mentioned mechanisms and the way connections are typically established in dedicated SD tools (with naturally more simple use cases) has me wonder about a simpler possibility, which I would like to describe below.

Stacked Connectors (while block connectors are not implemented yet)

Let's look at a very simple structure in Modelica (System Modeler was used in this case):

model ModelConnections
  model component1
    Modelica.Blocks.Interfaces.RealOutput y1;
    Modelica.Blocks.Interfaces.RealOutput y2;
  end component1;

  component1 c1;

  model component2
    Modelica.Blocks.Interfaces.RealInput u1;
    Modelica.Blocks.Interfaces.RealInput u2;
  end component2;

  component2 c2;
equation
  connect(c1.y2, c2.u2);
end ModelConnections;

It is perfectly legal and thus simply a matter of (likely improper) style to "stack" connectors atop of each other in diagrams and icons. In the given example, Wolfram SystemModeler's GUI (I have not checked this for other environments) will not know which connector is selected in DiagramView and so it is probably just the order of the connectors being instantiated in the model, which determines the actual instances being connected in the connection equation (e.g., c1.y2 is connected c2.u2 with the GUI's Connect Line Tool when the stacked connectors are selected).

Wouldn't it be possible to allow tools to recognize the proximity of graphical representations as to provide a choice dialog for selecting the appropriate connector?

This would not have any other implications as the model's code will not be affected at all—it is merely a convenient and flexible way to prevent diagram clutter and "porcupine-like" icons. In inductive modeling approaches like system dynamics such multiplicity of connectors arises quickly (mainly, but not exclusively causal ones) and most often these connectors will not be used "en bloc".

Maybe this could be specified more formally by something like an annotation, e.g., To maybe make this more formal, one may discuss an annotation like representativeConnector (or even more general representativeInstance ?) which tells a tool to not show a separate graphical representation in the icon or diagram, but to instead use the graphical representation of the declared representative instance as proxy for establishing a selection in the tool's front end.

Essentially, this would make the use of many individual connectors (not meant to be treated as a single block) more convenient.

[gwr69]

This issue is not receiving a lot of attention, so let me ask a couple of questions to either stimulate discussion or come to closure more quickly:

1. Is there anything that makes this proposal less preferable than the connector block (working title according to #2543 )?

2. Having a less restrictive connector block as an alternative to a composite connector has been discussed last in 2020. Is there a reason for something in this vein not being followed up on?

3. If the answer to 2 is "no", what may be a realistic timeline for one of these solutions being added in the specs?

[HansOlsson]

Some comments:

• I'm currently working on ensuring that current MCPs go through and other issues are resolved, and thus haven't had time to consider new enhancements. In general having a 'composite connector' (or 'connector block') seems like a good future extension - but after them.
• Tools already have various forms of support for stacked (or otherwise overlapping) connectors. So the answer to that question is 'yes'. I don't see that as requiring something special in the specification.

Consider a full model:

model ModelConnections
  model component1
    Modelica.Blocks.Interfaces.RealOutput y1
      annotation (Placement(transformation(extent={{98,-10},{118,10}})));
    Modelica.Blocks.Interfaces.RealOutput y2
      annotation (Placement(transformation(extent={{98,-10},{118,10}})));
  end component1;

  model component2
    Modelica.Blocks.Interfaces.RealInput u1
      annotation (Placement(transformation(extent={{-124,-18},{-84,22}})));
    Modelica.Blocks.Interfaces.RealInput u2
      annotation (Placement(transformation(extent={{-124,-18},{-84,22}})));
  end component2;

  component1 c1
    annotation (Placement(transformation(extent={{-60,0},{-40,20}})));
  component2 c2 annotation (Placement(transformation(extent={{60,0},{80,20}})));
  annotation (uses(Modelica(version="4.0.0")));
end ModelConnections;

Attempting to connect them in Dymola 2023 gives

(I can't recall when this added - but Dymola 2018 FD01 also had it.) Note that you also get the same dialog if the connectors are close "enough" even if not fully overlapping. I guess we could add other possibilities as well @DagBruck

[gwr69]

Thank you for the reply and I can quite see the lower priority for making more elaborate changes in the vein of connector block. But you have rather nicely confirmed my hunch, that tools may already support "stacked/overlapping" connectors in establishing connections as this is totally within specification. There has been "hesitance" out of fear that this may break compatibility between tools, which can now be alleviated by reference to Dymola. ;-)

[DagBruck]

(I can't recall when this added - but Dymola 2018 FD01 also had it.) Note that you also get the same dialog if the connectors are close "enough" even if not fully overlapping. I guess we could add other possibilities as well @DagBruck

Yes, Dymola has a "hot zone" around the cursor to make picking easier, so you may get several close objects in one operation. The special case which is filtered away is that a hit on a component's connector obviously creates a a hit on the component itself, but in that case we assume the user wants to start drawing a connection.

[HansOlsson]

As for "block connector" I would see the following:

• They can directly only contain connectors - not flow (or across) variables.
• You can connect to the whole or parts (since it is intentional we don't have the usual problem of breaking encapsulation). Note that we might also have a similar easing of the restriction for expandable connectors.

In this way "connector block" would be similar to "expandable connector" but with fixed contents.

[gwr69]

As for "block connector" I would see the following:

• They can directly only contain connectors - not flow (or across) variables.
• You can connect to the whole or parts (since it is intentional we don't have the usual problem of breaking encapsulation). Note that we might also have a similar easing of the restriction for expandable connectors.

In this way "connector block" would be similar to "expandable connector" but with fixed contents.

Weren‘t acausal connectors allowed within expandable connector ? (d‘accord otherwise)

[HansOlsson]

As for "block connector" I would see the following:

• They can directly only contain connectors - not flow (or across) variables.
• You can connect to the whole or parts (since it is intentional we don't have the usual problem of breaking encapsulation). Note that we might also have a similar easing of the restriction for expandable connectors.

In this way "connector block" would be similar to "expandable connector" but with fixed contents.

Weren‘t acausal connectors allowed within expandable connector ? (d‘accord otherwise)

Yes, they are allowed but as sub-connectors - so I don't see whether that would be different.

[gwr69]

Ok, there are a couple of thinks to ponder for clarity (at least for my head):

• Would the prefix connector be needed inside a block connector and accordingly then input or output prefixes? (similarity to expandable connector suggests that this were not the case)
• Could the internal connectors (e.g., variables) be potentially present only? (as with expandable ones)
• Would the block connector just be a mere notional “collector”, i.e., so connections to m.bc.c are legal, which would then be dissimilar; my understanding is that m.bc.c would really be m.c so bc can be completely eliminated from a parsed model)