Background
Many models extend from base classes such as Fluid.Interfaces.PartialTwoPort in which the connector location in the diagram view is defined with literal values — e.g. port_a is always located at coordinates {{-110,-10},{-90,10}}.
This restricts the layout of components derived from these base classes. As an example, the internal components of the pump/fan models are crammed inside a square, 200 by 200 point canvas, whereas a more "horizontally stretched" model would have been preferred since most Modelica IDEs have a "widescreen" model view.
Another example is the model Fluid.Storage.BaseClasses.PartialTwoPortInterface which is a duplicate Fluid.Interfaces.PartialTwoPortInterface (plus Fluid.Interfaces.PartialTwoPort) with the exception of the fluid port placement.
Feature request
A more flexible connector layout is suggested in which the extent annotation of the connectors is stored in a constant or a protected parameter rather than being hard coded. In either case, the constant/parameter should be hidden from the regular user to limit cluttering of the parameter dialog and simulation results, but at the same time giving model developers better flexibility when using the base classes.
Flexible placement in diagram view
A flexible placement of the connectors in the diagram view should be implemented with a constant for each connector. The connector location can only be changed when extending from the base class to leave enough drawing space for the components in the derived model. This is the highest priority of the feature request.
Flexible placement in icon view
A flexible connector placement in the icon view can be used to change the connectors to a "vertical layout" (like the case with the thermal energy storage models).
The connector location should be specified with a parameter to allow modification port location on the icon after instatiation of the component. A specific use case is the implementation of a heat exchanger base class (not in the IBPSA library), in which the icon and location of the four fluid ports depends on the heat exchanger type and flow configuration, specified with parameter (see graphical example below).
This feature has a lower priority.
Suggested implementation
Below is a simplified code example for the implementation of flexible port locations for Fluid.Interfaces.PartialTwoPort
partial model PartialTwoPort "Partial component with two ports"
constant Integer[2,2] port_a_diagramExtent={{-110,-10},{-90,10}}
"Diagram extent of 'port_a'" annotation (HideResult=true);
constant Integer[2,2] port_b_diagramExtent={{90,-10},{110,10}}
"Diagram extent of 'port_b'" annotation (HideResult=true);
protected
parameter Integer[2,2] port_a_iconExtent=port_a_diagramExtent
"Icon extent of 'port_a'" annotation (HideResult=true);
parameter Integer[2,2] port_b_iconExtent=port_b_diagramExtent
"Icon extent of 'port_a'" annotation (HideResult=true);
public
Modelica.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_diagramExtent),
iconTransformation(extent=port_a_iconExtent)));
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_diagramExtent),
iconTransformation(extent=port_b_iconExtent)));
end PartialTwoPort;
Final thoughts
With default the coordinates suggeste above, the new feature are completely invisible to the users. However, I have not investigated if there is a slight model translation penalty by introducing constants/parameters instead of hard-coded, literal values.
Background
Many models extend from base classes such as
Fluid.Interfaces.PartialTwoPortin which the connector location in the diagram view is defined with literal values — e.g.port_ais always located at coordinates{{-110,-10},{-90,10}}.This restricts the layout of components derived from these base classes. As an example, the internal components of the pump/fan models are crammed inside a square, 200 by 200 point canvas, whereas a more "horizontally stretched" model would have been preferred since most Modelica IDEs have a "widescreen" model view.
Another example is the model
Fluid.Storage.BaseClasses.PartialTwoPortInterfacewhich is a duplicateFluid.Interfaces.PartialTwoPortInterface(plusFluid.Interfaces.PartialTwoPort) with the exception of the fluid port placement.Feature request
A more flexible connector layout is suggested in which the
extentannotation of the connectors is stored in aconstantor a protectedparameterrather than being hard coded. In either case, the constant/parameter should be hidden from the regular user to limit cluttering of the parameter dialog and simulation results, but at the same time giving model developers better flexibility when using the base classes.Flexible placement in diagram view
A flexible placement of the connectors in the diagram view should be implemented with a
constantfor each connector. The connector location can only be changed when extending from the base class to leave enough drawing space for the components in the derived model. This is the highest priority of the feature request.Flexible placement in icon view
A flexible connector placement in the icon view can be used to change the connectors to a "vertical layout" (like the case with the thermal energy storage models).
The connector location should be specified with a
parameterto allow modification port location on the icon after instatiation of the component. A specific use case is the implementation of a heat exchanger base class (not in the IBPSA library), in which the icon and location of the four fluid ports depends on the heat exchanger type and flow configuration, specified with parameter (see graphical example below).This feature has a lower priority.
Suggested implementation
Below is a simplified code example for the implementation of flexible port locations for
Fluid.Interfaces.PartialTwoPortFinal thoughts
With default the coordinates suggeste above, the new feature are completely invisible to the users. However, I have not investigated if there is a slight model translation penalty by introducing constants/parameters instead of hard-coded, literal values.