OMEdit does not render thermal connections in MSL models correctly

[dietmarw]

Description

Looking at Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.* models there are thermal connectors missing in the rendering but present in code and annotation.

It looks lilke only the thermal connectors of the base class Modelica.Magnetic.QuasiStatic.FundamentalWave.BaseClasses.Machine are shown.

Steps to Reproduce

Open Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.SM_ElectricalExcited in the diagram view of OMEdit.

Expected Behaviour

Here a screenshot from Dymola how the diagram should get rendered including all thermal connections:

Actual Behaviour

Here a screenshot from OMEdit (Connected to OpenModelica 1.19.0~dev-401-gaef8258)

Version and OS

• OpenModelica Version: 1.19.0~dev-401-gaef8258
• OS: Ubuntu Linux 20.04
• MSL 4.0.0

[dietmarw]

Also confirmed to not work correctly on the Windows version of OMEdit.

[casella]

Probably same as #8172, some conditional connectors are never show, instead of being always shown, while #2081 gets solved.

[dietmarw]

Yes I was aware of #2081 but not #8172. But it does look to be the same or related issue.

[casella]

For #8172 we'll find a fix for 1.19.0. #2081 requires rewriting the API and the way OMEdit uses it, it's planned for 1.20.0 in July. This time we have funding to get that done, so done it will get.

[perost]

I get error messages that I guess might be causing the issue:

[5] 15:24:52 Scripting Error
Unable to find component internalThermalPort.heatPortExcitation while parsing connection {excitation.heatPortWinding,internalThermalPort.heatPortExcitation,}.

[6] 15:24:52 Scripting Error
Unable to find component internalThermalPort.heatPortRotorWinding while parsing connection {rotorCage.heatPortWinding,internalThermalPort.heatPortRotorWinding,}.

[7] 15:24:52 Scripting Error
Unable to find component internalThermalPort.heatPortBrush while parsing connection {brush.heatPort,internalThermalPort.heatPortBrush,}.

These errors comes from OMEdit and not OMC though, but it might be that the issue is in the API. I think @adeas31 will need to look into why OMEdit can't find the connections, and then I can try to help with the API if needed.

[casella]

LGTM. @adeas31, please have a look at your earliest convenience.

[casella]

Should be fixed by #8237. @dietmarw, please check with the latest nightly build and reopen if this doesn't work for you.

[dietmarw]

I have no rights to reopen the ticket but can tell that the hack in #8237 did not fix it:

[3] 08:49:46 Scripting Error
Unable to find component internalThermalPort.heatPortBrush while parsing connection {brush.heatPort,internalThermalPort.heatPortBrush,}.

[4] 08:49:46 Scripting Error
Unable to find component internalThermalPort.heatPortExcitation while parsing connection {excitation.heatPortWinding,internalThermalPort.heatPortExcitation,}.

[5] 08:49:46 Scripting Error
Unable to find component internalThermalPort.heatPortRotorWinding while parsing connection {rotorCage.heatPortWinding,internalThermalPort.heatPortRotorWinding,}.

[adeas31]

This is same as #8086. There are connections to internalThermalPort but its not there in the diagram so OMEdit outputs the error while trying to fetch the component.

[casella]

As I understand, the latest issue reported by @dietmarw has nothing to do with the visibility of conditional connector. @perost, the problem here is the replaceable internalThermalPort hierarchical connector, which is redeclared to be of type Interfaces.InductionMachines.ThermalPortSMEE in the machine model. Apparently the redeclaration is lost by the API function used by OMEdit, which only knows about the nested connectors defined in the base class Interfaces.InductionMachines.PartialThermalPortInductionMachines.

I checked the omedicommunication.log file for internalThermalPort.heatPortExcitation and I found

getNthConnection(Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.SM_ElectricalExcited,4) 23:42:31:785
{"excitation.heatPortWinding","internalThermalPort.heatPortExcitation",""} 23:42:31:785
#s#; 0.000000; 7.566000; 'getNthConnection(Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.SM_ElectricalExcited,4)'

getNthConnectionAnnotation(Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.SM_ElectricalExcited, 4) 23:42:31:785
{Line(true, {0.0, 0.0}, 0, {{-20, -50}, {-20, -80}, {-40, -80}, {-40, -90}}, {191, 0, 0}, LinePattern.Solid, 0.25, {Arrow.None, Arrow.None}, 3, Smooth.None)} 23:42:31:790
#s#; 0.004000; 7.570000; 'getNthConnectionAnnotation(Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.SM_ElectricalExcited, 4)'

so apparently OMedit is getting the required information. There are no other instances of the string internalThermalPort.heatPortExcitation in the log file, so I'm not sure exactly what goes wrong here and why.

@adeas31, can you please have a look at what happens when rendering the diagram of Modelica.Magnetic.QuasiStatic.FundamentalWave.BasicMachines.SynchronousMachines.SM_ElectricalExcited and give indications to @perost which API function he should fix?

Thanks!

[casella]

This is same as #8086. There are connections to internalThermalPort but its not there in the diagram so OMEdit outputs the error while trying to fetch the component.

I don't think so. The only connects that fail are the ones to sub-connectors that are defined in the redeclared connector. The other ones work fine. Really looks like a front-end issue. Probably the OF is still used for some API call, and the NF should be used instead.

[adeas31]

I think getElements doesn't return internalThermalPort so OMEdit doesn't have the component and as a result unable to draw the connections.

[perost]

I think getElements doesn't return internalThermalPort so OMEdit doesn't have the component and as a result unable to draw the connections.

getElements just returns the elements in the class definition, so it doesn't return internalThermalPort since that element isn't declared in SM_ElectricalExcited but inherited from BaseClasses.Machine. I assume that OMEdit looks up the inherited elements separately, but that means that the redeclares are not taken into account.

For that to work we'd have to change getElements (or add a new function) to instantiate the class and return all the elements, both local and inherited. And then I think we're starting to approach #2081 territory.

[casella]

For that to work we'd have to change getElements (or add a new function) to instantiate the class and return all the elements, both local and inherited. And then I think we're starting to approach #2081 territory.

I agree, there's no point spending time on a hack that will be very short-lived.

@dietmarw, we will overhaul this mechanism completely next year, within a cooperation with LBL. Please follow #2081 for more details and to see the progress.

[mwetter]

This also occurs when opening in OMEdit (from OpenModelica 1.20.0~dev-336-g8a791ee) the model IBPSA.Fluid.Humidifiers.Humidifier_u from commit d96b7899655c05f1ed5cb08a0b399270d2258ae8 of the IBPSA library.

The error message of OMEdit is

[3] 10:49:24 Scripting Error
Unable to find component vol.mWat_flow while parsing connection {gai.y,vol.mWat_flow,}.

and it looks like the underlying reason is that OMEdit does not resolve the replaced instance vol in

within IBPSA.Fluid.Humidifiers;
model Humidifier_u
  "Ideal humidifier or dehumidifier with prescribed water mass flow rate addition or subtraction"
  extends IBPSA.Fluid.Interfaces.TwoPortHeatMassExchanger(
    redeclare replaceable package Medium =
        Modelica.Media.Interfaces.PartialCondensingGases,
    redeclare final IBPSA.Fluid.MixingVolumes.MixingVolumeMoistAir vol(
    final prescribedHeatFlowRate=true));
...