Visual representation of conditional components

[modelica-trac-importer]

Reported by massimo.ceraolo on 19 Oct 2018 06:50 UTC Consider Modelica.Fluid.Examples.DrumBoiler.DrumBoiler diagram.

The user is shown a diagram seeming faulty: q_F and q_F_Tab output are signal outputs that seem to converge into the same point.

In reality the model is correct because both q_F and q_F_Tab are conditional components and only one of them can be present at a time.

I wonder whether this should be somehow visible. One idea could be requiring (in sect. 4.4.5 of specification), or , at least recommending, that tools show disabled conditional components greyed. Obviously if this is decided it must also be decided how they should be greyed.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/2275

[modelica-trac-importer]

Comment by beutlich on 19 Oct 2018 06:57 UTC Should be "inputs" rather than "outputs" in your description. Which makes it even more confusing that multiple signals are used as input signal source.

[modelica-trac-importer]

Comment by hansolsson on 19 Oct 2018 08:09 UTC Replying to [ticket:2275 massimo.ceraolo@…]:

Consider Modelica.Fluid.Examples.DrumBoiler.DrumBoiler diagram.

The user is shown a diagram seeming faulty: q_F and q_F_Tab output are signal outputs that seem to converge into the same point.

In reality the model is correct because both q_F and q_F_Tab are conditional components and only one of them can be present at a time.

I wonder whether this should be somehow visible. One idea could be requiring (in sect. 4.4.5 of specification), or , at least recommending, that tools show disabled conditional components greyed. Obviously if this is decided it must also be decided how they should be greyed.

To me the critical point is more when than how, and I don't think it should be standardized too much.

If you drag in the example as a sub-component in Dymola (at least since Dymola 2015 FD01 and also in 3D Experience Platform) q_F is dimmed out, by having a dotted outline instead. Dymola also has a different way of visually dimming components and corresponding connections, indicating that that the how isn't settled.

There is a reason for this.

If DrumBoiler weren't protected from editing the explanation would be straightforward: even if q_F is disabled as default you still want to be able to edit the diagram of the model you are working with - including modifying the condition of q_F, connecting it, removing it, moving it - all of which is difficult if it is dimmed out.

This is also relevant when trying to understand a component model such as Modelica.Mechanics.MultiBody.Sensors.AbsoluteSensor which has a conditional connector at the top (which aren't shown disabled - the icon just looks similar).

The DrumBoiler is a bit of an exception, since it is intended to be run as an example - but still has conditional connectors that are only useful when modified (e.g. as a component model).

It might be that multiple ways of disabling are needed.

[modelica-trac-importer]

Comment by anonymous on 22 Oct 2018 06:41 UTC

If DrumBoiler weren't protected from editing the explanation would be straightforward: even if q_F is disabled as default you still want to be able to edit the diagram of the model you are working with - including modifying the condition of q_F, connecting it, removing it, moving it - all of which is difficult if it is dimmed out.

It it is just shown differently, e.g. greyed, it can be connected, removed, moved, resized easily, I think, given that the grey is not too light.

Note that the diagram of this example, as it appears now, can well be interpreted as a wrong diagram, since it gives no clue that parts of it are indeed inactive. I.e., the user can understand the reason that makes the diagram correct only looking at the attributes of individual components.

I understand that there are many ways of making disabled components visually different, which creates some difficulty in defining a standard choice. But, on the other hand, if this is done, the usage of disabled components such as in Modelica.Fluid.Examples.DrumBoiler.DrumBoiler can be more frequent. Indeed, it brilliantly allows creating very flexible models, but today its usage is somewhat jeopardised by this visual weakeness.

[modelica-trac-importer]

Comment by massimo.ceraolo on 22 Oct 2018 06:44 UTC Last comment was mine. It was intended to start with the word "If" instead of "It".

[modelica-trac-importer]

Comment by anonymous on 22 Oct 2018 06:44 UTC

If DrumBoiler weren't protected from editing

This is only the case for the MSL that comes with Dymola. But it looks different if you load another MSL or use a different Modelica environment.

[modelica-trac-importer]

Comment by hansolsson on 22 Oct 2018 10:35 UTC Replying to [comment:5 anonymous]:

If DrumBoiler weren't protected from editing

This is only the case for the MSL that comes with Dymola. But it looks different if you load another MSL or use a different Modelica environment.

Yes, but that only strengthens my point.

My point was that if it weren't read-only it would make some sense - since DrumBoiler is also intended to be used as a component model (or as base-class?) you want to be able to change its conditional components (which you obviously cannot do if it is read-only).

This is somewhat unusual for an experiment.

It might be that we need different visual highlighting of this case.

[modelica-trac-importer]

Comment by massimo.ceraolo on 23 Oct 2018 17:20 UTC I consider the DrumBoiler once it is duplicated. So it is made writable. My belief is that also in this case having visual feedback of the state of a component being disabled would be very useful. In the specific case changing the value of use_inputs would toggle the "greyed state" of the four conditional components involved. If it were just a matter of the special case of DrumBoiler as a MSL example I would not have created this ticket.

[modelica-trac-importer]

Comment by henrikt on 24 Oct 2018 08:04 UTC I am also against standardizing on the exact visual representation. For example, I can imagine that it could be really helpful to visually indicate how different conditional components are related to the same Boolean constant, but things are getting so complex at this point that I find it better to leave the visualization aspects to the tool makers. Similarly, if we were to standardize on something that didn't include how to show the relation between conditional components controlled by the same constant, then a tool vendor would need to go against the specification in order to provide such a helpful feature.

[modelica-trac-importer]

Comment by massimo.ceraolo on 24 Oct 2018 19:21 UTC Replying to [comment:8 Henrik Tidefelt]:

I am also against standardizing on the exact visual representation. For example, I can imagine that it could be really helpful to visually indicate how different conditional components are related to the same Boolean constant, but things are getting so complex at this point that I find it better to leave the visualization aspects to the tool makers. Similarly, if we were to standardize on something that didn't include how to show the relation between conditional components controlled by the same constant, then a tool vendor would need to go against the specification in order to provide such a helpful feature.

Ok, I get the point: this could be a helpful feature, maybe it is better to leave this to tools vendors. I don't have a precise idea on this and on the ticket description I myself wrote "at least recommend" because had doubts of this kind.

On the other hand, consider that one of the best characteristic of Modelica is that you can change from one tool to another and still "get the same", even from the visual point of view. I use Modelica for teaching. In the first semester use a commercial tool (Dymola) and in the second one free (OpenModelica). I surprise my students on how they are immediately at ease with the new tool. The fact that the very graphical appearance is (nearly exactly) the same is a real boon. This makes modelica unique, AFAIK. So, every time we leave choices to tool vendors, we weaken this point of strength of the Modelica system (=language, libraries, tools).

A possibility is to issue a recommendation that leaves room for further customisation by the tool vendors. Let me try a draft.

"Conditional components for which the condition is false are displayed greyed; in case a model contains conditional components depending on more than one Boolean variable, tool vendors are free to choose other visual techniques to differentiate disabled components from enabled ones, e.g. with the purpose of differentiate from each other disabled components depending on different Boolean variables"

But I still would prefer just recommending to display greyed disabled components, without any addition. Being disabled it a so basic feature that deserves a rule. Inter-relationship of disabling with disabling variables is something different some way to visually analyse our model, which can added by tool vendors to standard display.

[modelica-trac-importer]

Comment by henrikt on 25 Oct 2018 08:22 UTC I think I get your point, but I see it slightly different. To somehow indicate that a component is disabled is such a basic thing to expect from a tool that I think that we can safely consider it a quality of implementation how and if it is done.

By the way, if a recommended behavior was given for disabled components, it could be considered a nice symmetry to also specify a recommended behavior for enabled components. While I would certainly find it informative to see what components that can be disabled in a diagram, it seems like a rather tricky question to decide what that behavior should be. For example, such a recommendation would should take into consideration how it might interact with useful ways of representing that a component is replaceable.

When switching from one tool to another, I think that differences in the visualization of conditional and replaceable components account for a relatively small learning cost compared to differences in window layout, menus, context menus, use of dialogs vs direct editing, simulation setup, plotting utilities, and so on. Not saying that I think that these tool aspects should be standardized too. :)

[modelica-trac-importer]

Comment by massimo.ceraolo on 27 Oct 2018 07:05 UTC Well, I understand that there is no support for the idea, so I'm going to close the ticket soon. Before doing this, I just summarize the reasons for which I opened and supported it:

1) Any valid Modelica model should also have a valid appearance; this is not true, at least with Dymola and Openmodelica, with models such as Modelica.Fluid.Examples.DrumBoiler.DrumBoiler from MSL; 2) this appearance should be as closely as possible the same across simulation tools, and my proposal pursued this criterion.

[modelica-trac-importer]

Comment by massimo.ceraolo on 27 Oct 2018 07:08 UTC OOPS, it looks like that I'm not allowed to close the ticket. please someone having the powers for this, close it.

[modelica-trac-importer]

Comment by fcasella on 27 Oct 2018 13:14 UTC I used conditional connectors in diagrams in some cases. They are very convenient, but I agree with @ceraolo that they can make understanding the diagram a bit tricky if there is no visual clue at all that some components are conditional. Of course if one sees something fishy, one can always check the component attributes and find that out.

I'm not sure this should be standardized, but I guess some form of (non-intrusive) visual clue would be nice. Greying out disabled components is questionable, because that depends on the default value of the boolean parameter, and would seem to imply some preference on that configuration when browsing the diagram in the library. I think both components should have some visual clue (e.g. a thin dotted line or whatever) that invites the user to check the attributes and find out what is the condition for their instantiation.

From my side, when I use this kind of tricks I always add some text to the diagram that explains its rationale (e.g. specifically on which boolean parameter the conditional components depend upon), which is best done manually rather than relying on automatic visual clues.

My 2 cts.

[modelica-trac-importer]

Modified by fcasella on 27 Oct 2018 13:15 UTC