Use blank pixels around lines to enhance readability

[massimo ceraolo]

In MA ticket 2162 there have been a discussion on the diode symbol. The IEC has the disadvantage that an erroneous connection between anode and cathode is hardly visible. Dropping that line solves this, but is against the effort of making Modelica symbols as IEC compliant as possible.
The decision was to keep the IEC symbol.

However it may occur to newbies that a line is inadvertently drawn between anode and cathode. This is crazy but happens. It produces an issue which is difficult to spot.

Dymola solves this using a graphical representation which does some difference between a correct diode and a short circuit diode (Dymola.png)
OMEdit does not make any difference (OM.png).

I think that Dymla simply uses some blank pixels at the sides of connecting lines: in this way the lines are "detached" from any underlying other drawing element.

Is it possible to consider something also for OMEdit?
Not only would this enhance readability of diodes and GTOs, but, more in general, readability of all diagrams in which connecting lines are drawn over other elements.
Important is the case of connecting lines intersections: compare the way intersections are viewed in Dynmola and OM for the file "crossingLines.mo"

[Adeel Asghar]

I think the MA ticket number is wrong.

[anonymous]

​https://github.com/modelica/Modelica/issues/2162

[Martin Sjölund]

What's the Modelica code used for the screenshots?

[massimo ceraolo]

Replying to sjoelund.se:

What's the Modelica code used for the screenshots?

model DIODES
  Modelica.Electrical.Analog.Ideal.IdealDiode diode annotation (Placement(
        transformation(
        extent={{-10,-10},{10,10}},
        rotation=90,
        origin={-12,0})));
  Modelica.Electrical.Analog.Ideal.IdealDiode diode_SHORTED annotation (
      Placement(transformation(
        extent={{-10,-10},{10,10}},
        rotation=90,
        origin={12,0})));
equation 
  connect(diode_SHORTED.n, diode_SHORTED.p)
    annotation (Line(points={{12,10},{12,-10}}, color={0,0,255}));
end DIODES;

[massimo ceraolo]

Probably what dymola does is just writing at the sides of connecting lines two rows of blank pixels. In this way the lines are "detached" from any underlying other drawing element.

[Martin Sjölund]

Added blank pixels sounds like a good idea; I just don't know if you can draw transparent pixels over non-transparent ones in Qt.

[massimo ceraolo]

Maybe every connection line can be drawn twice: the first time with slightly thicker lines and white colour, the second time with the right size and color.
The first one will blank the underlying drawing before the second one will actually write the needed connection line.

[Martin Sjölund]

@ceraolo: the problem is you now assume the canvas is white. It's transparent, and this is especially important when we for example export to SVGs to create nice figures in papers.

[massimo ceraolo]

A lot of programs use white backgrounds (including mine). I don't see drawbacks for this in the ability to write nice papers.

In fact, looking at the attachments of this ticket it is clear that OM pictures do not have opaque (white) background, while Dymola's have one.

[Francesco Casella]

While in principle one may want to superimpose a Modelica diagram on a background with a colour different from white, I don't think this is a really a strong requirement - in fact, all Modelica diagrams I ever saw put on paper had a white background.

On the other hand, the issue raised by @ceraolo is critical for the correctness of models, which ia IMHO a lot more important than the background colour of diagrams in papers. It is also relevant in other contexts than diodes.

[massimo ceraolo]

Since SVG is vectorised, the background can be still be removed at a later time, in case of need.
Actually we probably don't need to have a white background.
In case of transparent background the SVG can be used on white documents smoothly.
In case we want to put it over coloured backgrounds I'm not sure that the result will be so bad: just having connecting lines with white margins.
And still, in case of need, one could add white background as posprocessing.

[Adeel Asghar]

I tried to add the white outline around the connection line, .
Looks pretty fine. However, the original problem reported in the ticket is bit tricky. The problem is that the connection is drawn under component. So with the current OMEdit structure we have the following options,

1. Draw the connection on top. Looks like this,

The connection line is even on top of the ports and doesn't look nice.

2. (Current behavior) Draw the connection under the component. Looks like this,

3. (Required behavior) Draw the component without ports, draw the connection and then draw the ports. Tricky to implement since we need to set the stacking order. The stacking order is among the sibling items. The connection line and component are sibling items but the ports are children of component. So either I can say put connection on top or put component on top but I can't say put component then put connection and then out ports. I guess dymola is handling it by not making the ports children of component. We can also do that but this requires huge change in the structure of OMEdit e.g., adding/removing ports from the scene, managing transformations etc.

[Francesco Casella]

Replying to adeas31:

I tried to add the white outline around the connection line

I have some trouble seeing the "air gap". I also tried with reading glasses, since my eyesight is no longer as good as it used to be, but even then I think the white strip is too thin (about three pixels, counting anti-aliasing), and for some reason it also appears to be asymmetric, so that the air gap on one side is almost non-existent, which doesn't look good. Dymola uses a slightly wider and symmetric strip, about five pixels, which I find a lot clearer, even without reading glasses.

I would also go for 5 pixels width, and try to make it well-centered.

Of course the width of the white strip must be further increased for double- and quad-wide connection lines

[Francesco Casella]

Replying to adeas31:

3. (Required behavior) Draw the component without ports, draw the connection and then draw the ports. Tricky to implement since we need to set the stacking order. The stacking order is among the sibling items. The connection line and component are sibling items but the ports are children of component. So either I can say put connection on top or put component on top but I can't say put component then put connection and then out ports. I guess dymola is handling it by not making the ports children of component. We can also do that but this requires huge change in the structure of OMEdit e.g., adding/removing ports from the scene, managing transformations etc.

A simple solution is to first draw the component (including the connectors), then the connections on top of them, but have the white strips around them start not at the end points of the connection line but a few pixels inside the connection line, that is, make the white strip a bit shorter than the connection line itself. In this way the connector is not affected, but on the other hand if the connection overlaps a component this is clearly seen and intersections are handled properly in most cases.

If you want to really do it right, the amount of "retraction" of the white strip should correspond to the extent of the connector, but maybe a few pixels would just do.

[Francesco Casella]

Please also make sure that connection sets with more than two connectors, where some lines often partially overlap and rightly so, are rendered correctly.

Dymola takes the connection set in consideration and puts strategically placed "connection dots" where overlapping connections belonging to the same connection set depart from each other. This is nice but not necessary; however, it is necessary that due to the application of the white strips, the connection lines in this case do not show up as broken. I guess this requires to first draw all the white strips and then all the connection lines, maybe you're already doing that.

[massimo ceraolo]

1. Draw the connection on top. Looks like this,

The connection line is even on top of the ports and doesn't look nice.

For me it is OK that it doesn't look nice!
This connection is wrong and it is good that it does not look nice, so the mistake is easier to spot.

[massimo ceraolo]

I would also go for 5 pixels width, and try to make it well-centered.

The connecting line width was discussed and implemented in #4196.
The white strip, for me, should have a width defined in terms of the connecting line width. For instance three times that width.

[Francesco Casella]

See also #4839

[massimo ceraolo]

I must say that the situation is worse than what the ticket description and contents say.

Connecting to the wrong connector is something that in real life happens, rather frequently.

One way to check connections I use frequently is to move objects around to see how connections move. However, there are several cases in which this technique does not help at all.
Consider the two controllers in the enclosed FB.mo. They seem identical but give totally different results.
This is due to the PI1 input being wrongly connected to feedback1 input u1 instead of output.

Unfortunately, this wrong connection can not be singled out by graphical actions: moving feedback1 around does not give any clue that the wire going towards the right is connected to u1 instead of y!
Opening this model in Dymola immediately shows the issue.

May this three-year old ticket be sheduled earlier than for 2.0.0?

[Francesco Casella]

@adeas31, what do you think? How long would it take to implement this feature?

[Francesco Casella]

Ticket retargeted after milestone closed

[Francesco Casella]

1.18.0 blocker tickets moved to 1.19.0

[massimo ceraolo]

Anytime I propose Openmodelica to my students, I come across this issue.
The mistakes caused by this OM weakness are very difficult to find.
Consider the enclosed model TesctConn.QSensor.
It looks good, and checks good in OM.
However, when inserted into a circuit that uses it, RL_PQ I get:

[2] 14:26:50 Translation Error
Internal error IndexReduction.pantelidesIndexReduction failed! System is structurally singular and cannot be handled because the number of unassigned equations is larger than the number of states. Use -d=bltdump to get more information.

[3] 14:26:50 Translation Error
Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed!

this is very difficult for a young user to spot, and was very difficult also for me.

To find where the issue comes from I had to use Dymola, just to have a better error message and better visualization of QSensor.
In Dymola it became immediately apparent that the fixedDelay component is badly connected: the correct connections are in QSensorGood.

QSensor diagrams in OM and Dymola are shown in QSensorOM.png and QSensorDym.png.

I conclude that the need for this ticket to be solved is VERY STRONG, to avoid herds of potential users abandoning OM.

[massimo ceraolo]

1. Draw the connection on top. Looks like this,

The connection line is even on top of the ports and doesn't look nice.

Does only the shorted one have the wire above the pins?
In this case, I confirm what I said three years ago: this is very good since it makes it even easier to spot the issue.

So if just this stopped the ticket to be fixed is really a pity: there is a strong need for this improvement.

[Francesco Casella]

@adeas31, I think @ceraolo is right, we should really make sure that connections between ports of the same component are always drawn on top of the component icon, and never get covered by it. I also had the same issue in other contexts, and I confirm that this usually causes severe structural issues, which are reported by errors that do not help at all understanding what the problem is.

Can you please fix this?

Thanks!

[Adeel Asghar]

Does only the shorted one have the wire above the pins?

What do mean by shorted one?

[massimo ceraolo]

Replying to adeas31:

Does only the shorted one have the wire above the pins?

What do mean by shorted one?

the dioded named diode_SHORTED in the picture

[Adeel Asghar]

​https://github.com/OpenModelica/OpenModelica/pull/11175