You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The bug results from #1782 which introduced some constants to parameterize the placement of outside connectors in interface classes within Fluid.
Dymola (2023x Refresh1 on Linux and Windows)
does not properly handle these constants when extending such interface classes, as illustrated in the example below,
(even worse!) modifies existing annotations when opening models that derive from these classes: for instance, open IBPSA.Fluid.Chillers.BaseClasses.Carnot and notice how these lines
does not properly handle these constants when extending such interface classes, as illustrated in the example below,
but does not modify existing models like Dymola does.
I have opened a ticket at Dassault Systemes: SRF01088076 (status: wait for correction delivery).
However, I see no immediate workaround (changing these constants to parameters and/or making them public has no effect), and I suggest that we readily revert the changes from #1782 as Dymola's behavior is likely to have severe consequences.
Example illustrating the issue: Connecting Component.port_a to Component.sub.port_a from the diagram view of Dymola yields an incorrect graphical annotation.
package Testmodel BaseModelica.Fluid.Interfaces.FluidPort_a port_a
"Fluid connector a (positive design flow direction is from port_a to port_b)"annotation (Placement(transformation(extent={{port_a_x-10,port_a_y-10},{port_a_x+10,port_a_y+10}})));Modelica.Fluid.Interfaces.FluidPort_b port_b
"Fluid connector b (positive design flow direction is from port_a to port_b)"annotation (Placement(transformation(extent={{port_b_x-10,port_b_y-10},{port_b_x+10,port_b_y+10}})));protectedconstantInteger port_a_x =-100"x-coordinate of port_a center";
constantInteger port_a_y =0"y-coordinate of port_a center";
constantInteger port_b_x =100"x-coordinate of port_b center";
constantInteger port_b_y =0"y-coordinate of port_b center";
end Base;
model SubComponentextends Base;
end SubComponent;
model Componentextends Base;
SubComponent sub
annotation (Placement(transformation(extent={{-10,-10},{10,10}})));equationconnect(port_a, sub.port_a)
annotation (Line(points={{0,0},{-6,0},{-6,0},{-10,0}}, color={0,127,255}));end Component;
end Test;
The text was updated successfully, but these errors were encountered:
Yes, I can reproduce this. Good example of how even two reviewers can miss something with such an impact.
I still like some of the changes of #1782. Maybe just revert the examples and the constants?
Ouch! I can reproduce it too and missed this in the review. I already integrated the updates in Buildings, and rerouted various connections to the new connector placements. At this point, I think it would actually be faster, and more importantly add more value to users, to make new additional base classes that have the connectors on the top and bottom, and use them for the tank. I can work on these changes and add them to PR #1795. As they are only needed by the tank, I plan to make them subclasses of the tank, and once the bugs are fixed in the tools, we can restore what we merged.
@mwetter@FWuellhorst FYI, I just got this feedback from Dassault Systemes after submitting this issue to them.
It looks like the issue has already been solved for the coming Dymola 2024x. I invite you to test if the correction is working as soon as this new release of Dymola is available.
The bug results from #1782 which introduced some constants to parameterize the placement of outside connectors in interface classes within
Fluid
.Dymola (2023x Refresh1 on Linux and Windows)
IBPSA.Fluid.Chillers.BaseClasses.Carnot
and notice how these linesmodelica-ibpsa/IBPSA/Fluid/Chillers/BaseClasses/Carnot.mo
Lines 237 to 238 in 386a90a
OMEdit (OpenModelica 1.21.0 on Linux)
I have opened a ticket at Dassault Systemes: SRF01088076 (status: wait for correction delivery).
However, I see no immediate workaround (changing these constants to parameters and/or making them public has no effect), and I suggest that we readily revert the changes from #1782 as Dymola's behavior is likely to have severe consequences.
@mwetter or @FWuellhorst Can you reproduce what I noticed on your system?
Example illustrating the issue: Connecting
Component.port_a
toComponent.sub.port_a
from the diagram view of Dymola yields an incorrect graphical annotation.The text was updated successfully, but these errors were encountered: