Conditional connectors not handled by OMEdit

[Francesco 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.

[Francesco 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.

[Martin Sjölund]

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

[Adeel Asghar]

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.

[Martin Sjölund]

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.

[Adrian Pop]

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!

[Adrian Pop]

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.

[Martin Sjölund]

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).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Francesco Casella]

What is the current status with this ticket?

[Dietmar Winkler]

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

[Per Östlund]

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

[Francesco Casella]

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

[Adrian Pop]

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

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Francesco Casella]

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

[Francesco Casella]

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

[Francesco Casella]

See #2132

[massimo 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.

[Francesco 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.

[Francesco 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?

[Adeel Asghar]

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.

[Francesco 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?

[massimo 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)

[Francesco 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)

[Francesco 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

[Francesco 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

[Francesco Casella]

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

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Rescheduled to 1.18.0

[Francesco Casella]

Ticket retargeted after milestone closed

[Francesco Casella]

1.18.0 blocker tickets moved to 1.19.0

[Adeel Asghar]

Fixed with instance api.