Conditional connectors not handled by OMEdit

[casella]

Since cardinality was deprecated a few years ago, conditional connectors have been used extensively, in particular in the MSL.

Currently OMEdit always display conditional connectors even when they are switched off, which might be a bit confusing for the user. It would be nice (and probably not too hard to implement in MetaModelica) if we only drew conditional connectors when they are active.

[casella]

I'm told by Adeel that OMEdit can now handle this, but that OMC always returns visible. Can you please have a look and check why? Any example from the Modelica.Electrical library can be used for this purpose.

[sjoelund.se]

I have no clue what API commands are used for this... I need to know the command and expected output.

[adeas31]

Replying to sjoelund.se:

I have no clue what API commands are used for this... I need to know the command and expected output.

For example, heatPort is the 3rd component of Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort see the output below,

getComponents(Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort)
{{Boolean,useHeatPort,"=true, if HeatPort is enabled", "public", false, false, false, false, "parameter", "none", "unspecified",{}},{Modelica.SIunits.Temperature,T,"Fixed device temperature if useHeatPort = false", "public", false, false, false, false, "parameter", "none", "unspecified",{}},{Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_a,heatPort,"", "public", false, false, false, false, "unspecified", "none", "unspecified",{}},{Modelica.SIunits.Power,LossPower,"Loss power leaving component via HeatPort", "public", false, false, false, false, "unspecified", "none", "unspecified",{}},{Modelica.SIunits.Temperature,T_heatPort,"Temperature of HeatPort", "public", false, false, false, false, "unspecified", "none", "unspecified",{}}}

Following command gives the placement annotation values for Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort components,

getComponentAnnotations(Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort)
{{},{Dialog("General","Parameters",true,false,false,"","","","","",false)},{Placement(true,0.0,0.0,-10.0,-110.0,10.0,-90.0,0.0,0.0,0.0,-10.0,-110.0,10.0,-90.0,0.0)},{},{}}

Note that we get Placement(true which means heatPort should be visible. However, the code in the model says,

Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_a heatPort(T(start=T)=T_heatPort, Q_flow=-LossPower) if useHeatPort annotation (Placement(transformation(extent={{-10,-110},{10,-90}}), iconTransformation(extent={{-10,-110},{10,-90}})));

which means if useHeatPort parameter is true only then use the placement annotation.

For a running example take a look at resistor component in Dymola.

[sjoelund.se]

I still don't know what any of those things in the output mean... That API really should output a record.

And yes, you're doing it wrong if you query the class if it is enabled or not. This is a property of the component. If you have a class SomeClass(visible=true) component if someCondition, you need to look for both class being visible and the component actually being active given the parameters.

[adrpo]

Yes. The Placement is visible = true by default (See Constants.mo, the Placement record) if is not specifically given Placement(visible = false).
OMEdit should query the value of the conditional parameter useHeatPort in the class where is used and if is false the component annotation *and* its connections should be ignored!

[adrpo]

The problem is a bit more complicated by the fact that the condition in conditional components
is an expression and currently there is no way for OMEdit to ask OMC the value of an expression. A workaround could be made by instantiating the model and seeing if the component is present or not in the DAE but that would slow things down even more.

[sjoelund.se]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[sjoelund.se]

Milestone changed to 1.9.3 since 1.9.2 was released.

[sjoelund.se]

Moved to new milestone 1.9.4

[casella]

What is the current status with this ticket?

[dietmarw]

Good question. The status says assigned but no one in the "Owned by" field ;-)

[perost]

I guess I should take a look at it. Might be hard to implement though, but we'll see.

[casella]

Even a partial implementation that does not cover all the cases but just the basic one in the MSL would be very good.

[adrpo]

For this a new front-end is needed. I'm still working on it :)

[sjoelund.se]

Milestone pushed to 1.9.5

[sjoelund.se]

Milestone renamed

[casella]

I made this a blocker for 2.0, unless there are really compelling technical reasons why this cannot be solved by that milestone.

[casella]

Moved to 1.14.0, once the new API is in place this shouldn't be too hard.

[casella]

See #2132

[ceraolo]

Not only conditional connectors are displayed, but they can even be connected!

Even more surprisingly it can be connected to a non compatibile connector: for instance the heatport of a resistor can currently be connected by mouse action to one of its pins.

[casella]

Replying to ceraolo:

Not only conditional connectors are displayed, but they can even be connected!

Of course they can, as OMEdit is unaware of their actual activation status, because of the limitations discussed in 2132. Once those are resolved, this should no longer be an issue.

Even more surprisingly it can be connected to a non compatibile connector: for instance the heatport of a resistor can currently be connected by mouse action to one of its pins.

This is another story, I was not aware of it, thanks for pointing this out! I opened #5542 and #5543 on this topic.

[casella]

@adeas31, I understand this requires changes both to OMEdit and to the API. Are the former already done, and what is missing from the API?

[adeas31]

I can't do much in OMEdit about it yet until we handle this in the API. The problem is that we need a instance on which the modifiers are set.

[casella]

I mean, could we define the API interface precisely, so you can work on it and then we don't have to wait once @adrpo manages to take care of his part?

[ceraolo]

Of course they can, as OMEdit is unaware of their actual activation status, because of the limitations discussed in 2132. Once those are resolved, this should no longer be an issue.

Sure. I mentitled this because changes the relevance of the issue.
If a newbie (a student) can see a port that should not be visible but cannot connect it, is a relatively minor glitch. Totally different is the situation when he can. especially in cases where the conditional port is near a real one.
(It has happened and was not easy to spot)

[casella]

@ceraolo, in any case this is expected to get fixed in 1.14.0 (or possibly 1.14.1 if we run out of time)

[casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

[casella]

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

[casella]

@perost, could you possibly take care of this? Otherwise, please reassign it to @adrpo

[casella]

Retargeted to 1.17.0 after 1.16.0 release

[casella]

Rescheduled to 1.18.0

[casella]

Ticket retargeted after milestone closed

[casella]

1.18.0 blocker tickets moved to 1.19.0

[adeas31]

Fixed with instance api.