Conditional placement of connector's instance

[tobolar]

Is it common to Modelica Specification to define the placement of connector's instance (rotation and origin in the example below) conditional in the icon layer?

Example:

model ReplaceConnector
  parameter Boolean inputBottom = false
    "= true, if connector is placed on the lower edge of icon";

  Modelica.Blocks.Interfaces.RealInput u
    annotation (
      Placement(
        transformation(extent={{-110,-10},{-90,10}}),
        iconTransformation(
          extent={{-20,-20},{20,20}},
          rotation=if inputBottom then 90 else 0,
          origin=if inputBottom then {0,-100} else {-100,0})));
end ReplaceConnector;

[maltelenz]

See also:

3375

1672

3133

and some cases where there was actually a decision:

2642

2334

2225

I can tell that at least one tool (Wolfram System Modeler) currently has no support for the example model above.

[HansOlsson]

To me the more standard way of handling this would be:

Modelica.Blocks.Interfaces.RealInput u
    annotation (
      Placement(
        transformation(extent={{-110,-10},{-90,10}}),
        iconTransformation(
          extent={{-20,-20},{20,20}},
          rotation=DynamicSelect(0,if inputBottom then 90 else 0),
          origin=DynamicSelect({-100,0},if inputBottom then {0,-100} else {-100,0}))));

I can understand that using DynamicSelectfor a parameter-expression is not really "dynamic" and a might be seen as bit of overkill - but at least it has a similar intention and it is used in the GUI for items where DynamicSelect should already be supported. We could add this case to the specification, and I guess Dymola could have better checks for when it is missing.

Does Wolfram System Modeler handle this model in some way?

The first argument also has a use: if there is no default for inputButtom, or its expression is too complicated we at least have some graphical annotation (well - in this case it is overkill, but in general it could be useful).

This is also different from some of the other linked cases where we really need to use the correct value or things break.

[maltelenz]

Does Wolfram System Modeler handle this model in some way?

No, there is no way to get this behavior in System Modeler currently.

[HansOlsson]

Does Wolfram System Modeler handle this model in some way?

No, there is no way to get this behavior in System Modeler currently.

Just to be clear - does System Modeler support DynamicSelect for non-parameters in some situation? E.g.,

model ReplaceConnector
  parameter Boolean inputBottom = false
    "= true, if connector is placed on the lower edge of icon";
  Boolean dummy=inputBottom;

Modelica.Blocks.Interfaces.RealInput u
    annotation (
      Placement(
        transformation(extent={{-110,-10},{-90,10}}),
        iconTransformation(
          extent={{-20,-20},{20,20}},
          rotation=DynamicSelect(0,if dummy then 90 else 0),
          origin=DynamicSelect({-100,0},if dummy then {0,-100} else {-100,0}))));
end ReplaceConnector;

[tobolar]

@HansOlsson and @maltelenz Thanks for your response.

In particular, I refer to changes in https://github.com/DLR-SR/ThermofluidStream/blob/main/ThermofluidStream/HeatExchangers/Internal/PartialDiscretizedHEX.mo where connector's instance

Interfaces.Inlet inletB(redeclare package Medium = MediumB)
  annotation (
    Placement(
      transformation(extent={{-110,70},{-90,90}}), 
      iconTransformation(
        extent=if crossFlow then {{110,-90},{90,-70}} else {{-110,70},{-90,90}})));

was introduced.

I'm curious whether this is common or not, or whether there is an alternative solution (as e.g. using DynamicSelect) since this would be applicable on some more models in ThermofluidStream (e.g. JunctionT1.mo and JunctionT2.mo which are of the same functionality but differ in connector instances placement).

[maltelenz]

Just to be clear - does System Modeler support DynamicSelect for non-parameters in some situation?

System Modeler has two different views/states of diagrams, as mentioned in 18.6.6:

• An "editing state", which is what you see when browsing and editing models. It completely ignores DynamicSelect, except it allows you to edit the dynamic parts in a special dialog.
• A "non-editing" state, for simulated results. This uses the second argument to DynamicSelect, and of course works for non-parameters.

An additional restriction is that it looks like we don't support DynamicSelect in component placement annotations, as used in the examples brought forth in this issue. I guess this makes our support incomplete, assuming the Any value (coordinates, color, text, etc.) in graphical annotations in 18.6.6 also includes placement annotations for components.

I don't like using DynamicSelect for "static" things, as suggested here, since I view that annotation as something that applies to a special dynamic view that is attached to a simulation result, and not when normally browsing and viewing models.

[HansOlsson]

An additional restriction is that it looks like we don't support DynamicSelect in component placement annotations, as used in the examples brought forth in this issue. I guess this makes our support incomplete, assuming the Any value (coordinates, color, text, etc.) in graphical annotations in 18.6.6 also includes placement annotations for components.

I don't like using DynamicSelect for "static" things, as suggested here, since I view that annotation as something that applies to a special dynamic view that is attached to a simulation result, and not when normally browsing and viewing models.

I can understand that but/and:

• When browsing for models it to make makes sense to ignore any "dynamic" value (in icons); and therefore DynamicSelect provides a benefit over just giving a parameter value, but it would also be possible to say that it works without DynamicSelect.
• When viewing/editing models there are already other parameter-dynamic parts (strings using %p, conditional components, etc).
• To me it seems a lot cleaner than the last option:

model ReplaceConnector
  parameter Boolean inputBottom = false
    "= true, if connector is placed on the lower edge of icon";

  Modelica.Blocks.Interfaces.RealInput u1  if inputBottom
    annotation (
      Placement(
        transformation(extent={{-110,-10},{-90,10}}),
        iconTransformation(
          extent={{-20,-20},{20,20}},
          rotation=90,
          origin={0,-100})));
 Modelica.Blocks.Interfaces.RealInput u2 if not inputBottom
    annotation (
      Placement(
        transformation(extent={{-110,-10},{-90,10}}),
        iconTransformation(
          extent={{-20,-20},{20,20}},
          rotation=0,
          origin={-100,0})));
protected 
    Modelica.Blocks.Interfaces.RealInput u;
equation 
   connect(u1, u);
   connect(u2, u);
end ReplaceConnector;

[d-hedberg]

My interpretation is that the second argument of DynamicSelect is a dynamic expression that should be considered and evaluated during simulation (as a visualization) as it depends on simulation data. System Modeler supports this.

Static expressions, either as a direct binding to an annotation attribute, or as the first argument of a DynamicSelect, is used and evaluated when viewing the model in a modeling environment, hence it cannot depend on simulation data. System Modeler supports this, but in some cases only literal values are supported.

This (sensible) approach has been common practice for quite some time. Have a look at Modelica.Electrical.Analog.Basic.Resistor. It has a graphic item in its icon annotation that depends on a parameter: Line(visible = useHeatPort, ...). It is not part of a DynamicSelect. I think this makes sense and allows modeling environments to properly visualize the Resistor configuration.

Please do not change this! Let us keep differentiating between expressions needing/not needing simulation data when evaluated. The initial example by @tobolar looks perfectly fine to me. It's a static configuration of a component and should not use the dynamic part of DynamicSelect.

[casella]

Based on what I understood for #3464, let me add that the scope of this ticket is completely different from that of DynamicSelect.

The point here is to make base classes flexible enough. When you define a base class, you define an abstract interface (e.g. connectors) that are found in all derived classes. However, it is often the case that it is too early to define their concrete placement in the icon. That should be changeable when you inherit from the base class to define a concrete model. This is completely static and not at all dynamic, the new location is defined once and for all in the class and never changes when instantiating or simulating.

[tobolar]

The point here is to make base classes flexible enough. ...

This is exactly the idea behnid!