6

In the documentation it is indicated, that cardinality() function is deprecated and should no longer be used. However, it is still used in the libraries such as ThermoSysPro.

e.g.

if (cardinality(C) == 0) then
 some code
end if;

where C is FluidInlet or FluidOutlet

Could anyone give a simple example of how it could be replaced?

marco
  • 5,944
  • 10
  • 22
Tomillo
  • 157
  • 7

3 Answers3

6

The usual solution is to make the connector conditional, and if enabled you require that it is connected.

For physical connectors you can see how heatports and support is handled in: Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort Modelica.Mechanics.Rotational.Interfaces.PartialElementaryOneFlangeAndSupport2

For control signals you can see how p_in, h_in etc are handled in Modelica.Fluid.Sources.Boundary_pT Modelica.Fluid.Sources.Boundary_ph

However, the connectors of ThermoSysPro belong in neither of those categories and that should ideally also be cleaned up.

Hans Olsson
  • 11,123
  • 15
  • 38
3

The only thing I know, that could be used in this regard, is the connectorSizing annotation. It is described in the MLS chapter 18.7.

It is used a number of times in the Modelica Standard Library, e.g. in Modelica.Blocks.Math.MinMax via the parameter nu. When using it, the tool automatically sets the modifier for nu according to the number of connections to it.

  parameter Integer nu(min=0) = 0 "Number of input connections"
    annotation (Dialog(connectorSizing=true));
  Modelica.Blocks.Interfaces.RealVectorInput u[nu];

In the example below, nu=2 is generated by Dymola automatically when creating a connection in the graphical layer. I have removed the graphical annotations, to make the code more readable.

model ExCS
  Modelica.Blocks.Math.MinMax minMax(nu=2);
  Modelica.Blocks.Sources.Sine sine(freqHz=6.28);
  Modelica.Blocks.Sources.Constant const(k=0.5);

equation 
  connect(sine.y, minMax.u[1]);
  connect(const.y, minMax.u[2]);
end ExCS;
Markus A.
  • 6,300
  • 10
  • 26
3

The cardinality() operator is used in Modelica.Fluid.Sources.BaseClasses.PartialSource, and in a similar way in other fluid libraries (IBSPA, AixLib, Buildings, BuildingSystems and IDEAS), in the form

  // Only one connection allowed to a port to avoid unwanted ideal mixing
  for i in 1:nPorts loop
    assert(cardinality(ports[i]) <= 1,"
      each ports[i] of boundary shall at most be connected to one component.
      If two or more connections are present, ideal mixing takes
      place with these connections, which is usually not the intention
      of the modeller. Increase nPorts to add an additional port.
     ");
   end for;

I occasionally had models from users who somehow ended up with more than one connection to a ports[i]. How this happened was not clear, but I find the use of cardinality() useful to catch such situations, which otherwise can yield to mixing in the fluid port which the user did not intent and which are hard to detect.

Michael Wetter
  • 76
  • 1
  • 1
    I also think that this function is rather useful, but it is depreciated and it will be removed in the future for my understanding. There must be some genuine reasoning behind if the developers decided to remove it. Though it would be interesting to hear it. – Tomillo Jan 24 '20 at 11:27
  • ..and on the back of that question: what will you be using for that purpose in the future, when cardinality has been removed? It's strange to have a feature deprecated, but no clear successor/alternative named. – Christoph Apr 21 '22 at 12:39