Is DynamicSelect allowed in sub-expressions?

[maltelenz]

Section 18.9.6 says:

Any value (coordinates, color, text, etc.) in graphical annotations can be dependent on class variables using DynamicSelect.

And has the example:

 annotation(Icon(graphics = {
  Rectangle(
    extent =
      DynamicSelect({{0, 0}, {20, 20}},
                    {{0, 0}, {20, level}}),
    fillColor =
      DynamicSelect({0, 0, 255},
                    if overflow then {255, 0, 0} else {0, 0, 255})
  )})); 

My question is if it is allowed to use DynamicSelect on values further down in a hierarchy as well.

For example, would it be legal to rewrite the extent in the example above as:

    extent =
      {{0, 0}, {20, DynamicSelect(20, level)}}

For the record, this currently doesn't work in System Modeler. From what I can tell it doesn't work in OpenModelica either.

[HansOlsson]

It does work in Dymola, and I don't see any special reason to exclude it.

model Unnamed
  model M
    parameter Boolean overflow=true;
    parameter Integer level=20;
   annotation(Icon(graphics = {
  Rectangle(
    extent=
      {{0, 0}, {100, DynamicSelect(100,level)}},
      fillPattern=FillPattern.Solid,
    fillColor=
      DynamicSelect({0, 0, 255},
                    if overflow then {255, 0, 0} else {0, 0, 255}))}));
  end M;
  M m(overflow=false, level=40)
    annotation (Placement(transformation(extent={{-50,-8},{-30,12}})));
  M m1 annotation (Placement(transformation(extent={{-2,-58},{18,-38}})));
end Unnamed;

[maltelenz]

I guess a reason to exclude it would be that it adds further complexity in implementing a Modelica tool. A question is if the user functionality gained is worth the cost in complexity.

[HansOlsson]

I guess a reason to exclude it would be that it adds further complexity in implementing a Modelica tool. A question is if the user functionality gained is worth the cost in complexity.

The complexity depends on how it is implemented.

Clearly it is more complicated to see if it contains DynamicSelect if it can be buried as above. However, another option is to try to get the value of appropriate type (dynamic or not) and set a flag if it contains DynamicSelect; in that case checking for nested DynamicSelect isn't really a concern, but allows more re-use.

To me there is an additional benefit as in one of the examples above: avoiding duplicate code: extent ={{0, 0}, {20, DynamicSelect(20, level)}} vs. extent =DynamicSelect({{0, 0}, {20, 20}}, {{0, 0}, {20, level}}) I can see even more complicated scenarios where the commonality might be harder to find.

[maltelenz]

The complexity depends on how it is implemented.

Well clearly, but also being more allowing clearly adds complexity, since more cases need to be handled.

For example, providing a usable graphical editing UI seems really hard to me if the deeper DynamicSelect were allowed. How does Dymola deal with editing such an element?

[HansOlsson]

The complexity depends on how it is implemented.

Well clearly, but also being more allowing clearly adds complexity, since more cases need to be handled.

I realize that my 'depends' should have been stronger:

In some cases the extra cases just follow naturally from how it is implemented and it would actually add complexity to describe and detect the issue to not handle it. (As far as I understand that is the case in Dymola.)

For example, providing a usable graphical editing UI seems really hard to me if the deeper DynamicSelect were allowed. How does Dymola deal with editing such an element?

Personally, I have always edited such annotations in the text-layer. But Dymola have a widget allowing structured editing of the annotations of graphical objects and it supports any expression (including DynamicSelect), so there isn't any extra cost for editing such expressions in that way. (As far as I know, I think we are working on improving it as well.)

However, as far as I know the graphical editing (color selector, dragging extent, etc) in Dymola only work with literals, and I don't know if such editing makes sense in combination with DynamicSelect.

Consider: DynamicSelect({{0, 0}, {20, 20}}, {{0, 0}, {20, level}}) - if you drag the 20x20 rectangle to move it what should we generate? DynamicSelect({{10, 20}, {30, 40}}, {{0, 0}, {20, level}}) seems problematic, and the obvious DynamicSelect({{10, 20}, {30, 40}}, {{10, 20}, {40, 20+level}}) seems too magic. It's even worse if its size is changed - it could be to allow a larger range of level - or just to make the component larger.

In this specific case one could argue that if the DynamicSelect was on a sub-expression and that sub-expression was unchanged we should keep the DynamicSelect call, but I'm not sure if that works in general.

[maltelenz]

I agree that interactive editing of parts with non-literal expressions is hard. As you say, it's hard to even decide what would be the sensible behavior.

This is why I think it would be better if DynamicSelect was restricted to the "top" expressions. Then interactive and other helpful graphical editing would still be possible for the static part (the first argument to DynamicSelect), unless that also has expressions of course.

[HansOlsson]

I agree that interactive editing of parts with non-literal expressions is hard. As you say, it's hard to even decide what would be the sensible behavior.

This is why I think it would be better if DynamicSelect was restricted to the "top" expressions. Then interactive and other helpful graphical editing would still be possible for the static part (the first argument to DynamicSelect), unless that also has expressions of course.

Yes, but one concern is that it isn't clear whether such a "partial" update corresponds to what users want at all. Added: That's why I think Dymola's current mode of just generating literal values for graphical editing (overwriting whatever was there previously) works well enough; and I don't see that as an argument in favor of either variant of DynamicSelect.

[HansOlsson]

Language group: Check again how easy to support (possibly excluding updating of DynamicSelect further down). @casella to forward to OpenModelica UX-expert

[maltelenz]

After discussing this again internally, I am still convinced that the complexity of allowing this is not worth it.

In particular the complexity we have a problem with, is the editing support (in a GUI). We are very happy with our current implementation, which makes things easy for the user, and provides very nice help with editing with things like color pickers and similar.

If DynamicSelect would be allowed deeper down, one could no longer reasonably separate the editing into the static and dynamic parts. Extracting the static parts would be possible, but as soon as editing happens, I don't see how that could be incorporated without losing the dynamic part. The fact that the only tool that supports these deeper DynamicSelect (Dymola) also loses this on edit (as mentioned during the meeting), shows that it is a hard problem to solve.

We should clarify that deeper DynamicSelect are not allowed. Everything that would be possible with a deeper DynamicSelect is still possible, but in a more straightforward and simpler to edit way.

[adeas31]

Language group: Check again how easy to support (possibly excluding updating of DynamicSelect further down). @casella to forward to OpenModelica UX-expert

OpenModelica also doesn't support DynamicSelect further down in the hierarchy.

[HansOlsson]

Language group: Check again how easy to support (possibly excluding updating of DynamicSelect further down). @casella to forward to OpenModelica UX-expert

OpenModelica also doesn't support DynamicSelect further down in the hierarchy.

Have you investigated how difficult it would be to support?

[gkurzbach]

OpenModelica also doesn't support DynamicSelect further down in the hierarchy.

SimulationX doesnt' support it either.

Have you investigated how difficult it would be to support?

The effort results from the removal of the built-in special treatments and the implementation of DynamicSelect as a normal operator. The effort of the first is probably higher then the second.