Propagate parameters via expandable connector?

[modelica-trac-importer]

Reported by ahaumer on 20 Nov 2015 18:29 UTC I wonder whether it could be possible to propagate parameters via the bus (expandable connector); simple rule: one participant may set the parameter, all participants can get it. Would be a smart feature.

expandable connector Bus
  parameter Real p;
end Bus;

model A
  parameter Real p;
  Bus bus(p=p);
end A;

model B
  parameter Real p=bus.p;
  Bus bus;
end B;

model C
  A a(p=1);
  B b;
equation 
  connect(a.bus, b.bus);
end C;

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1841

[modelica-trac-importer]

Comment by filip.jorissen on 26 Aug 2016 07:35 UTC I'd like to also ask for this feature.

Right now it is possible to pass parameters through a bus by using fixed=false:

expandable connector Bus
  Real p;
end Bus;

model A
  parameter Real p;
  Bus bus;
equation
  bus.p=p;
end A;

model B
  parameter Real p(fixed=false);
  Bus bus;
initial equation
  p=bus.p
end B;

model C
  A a;
  B b;
equation 
  connect(a.bus, b.bus);
end C;

this however implies that a parameter value is only known at initialisation, which removes the possibility for simplifying code during translation for equations that depend on this parameter (e.g. using Evaluate=true in if/then/else statements). This is causing problems in the IDEAS library since we are forced to put certain equations in a different place than preferred, to be able to evaluate them efficiently.

The solution proposed by ahaumer seems good to me. I think this can be backwards compatible since it's a less strict implementation than what now exists.

[modelica-trac-importer]

Comment by filip.jorissen on 26 Aug 2016 07:39 UTC The relevant IDEAS ticket for the concrete problem we are facing: https://github.com/open-ideas/IDEAS/issues/552

[modelica-trac-importer]

Comment by hansolsson on 6 Sep 2016 12:37 UTC Modelica specification tickets.

[modelica-trac-importer]

Comment by hansolsson on 6 Sep 2016 12:48 UTC Duplicate of #111 - which also includes discussion about e.g. using overconstrained connectors for this.

[modelica-trac-importer]

Comment by hansolsson on 6 Sep 2016 13:56 UTC Replying to [comment:4 hansolsson]:

Duplicate of #111 - which also includes discussion about e.g. using overconstrained connectors for this.

Reopen and close other.

The most important information from that hidden ticket is the comment about overconstrained connectors.

[modelica-trac-importer]

Comment by Filip Jorissen on 13 Oct 2016 07:07 UTC Is there a timeline for this issue? We (and I imagine other people as well) could really use this!

[modelica-trac-importer]

Comment by filip.jorissen on 20 Jan 2018 09:15 UTC Still need this :)

[Mathadon]

@HansOlsson this issue stays a limitation for our model development in the IDEAS library and it seems a logical issue to have in other research fields too. Any chance this will be included in the Modelica specification?

[HansOlsson]

@HansOlsson this issue stays a limitation for our model development in the IDEAS library and it seems a logical issue to have in other research fields too. Any chance this will be included in the Modelica specification?

@Mathadon Can you provide some more information about this, in particular links to the library and indications where it is used?

[Mathadon]

@HansOlsson the library is available at https://github.com/open-ideas/IDEAS

To illustrate, see example IDEAS.Buildings.Examples.ZoneExample, which contains a building consisting of two zones, 5 walls and a window. The surface areas of the walls and window are communicated to the zone through the expandable connector indicated in yellow. I.e. the parameter Modelica.SIunits.Area A in IDEAS.Buildings.Components.Interfaces.PartialSurface is output onto the connector using connect(layMul.area, propsBusInt.area);.

In the model IDEAS.Buildings.Components.Interfaces.PartialZone we pass it to IDEAS.Buildings.Components.BaseClasses.RadiativeHeatTransfer.ZoneLwGainDistribution where it is converted back into a parameter using

  Modelica.Blocks.Interfaces.RealInput[nSurf] area;
  final parameter Modelica.SIunits.Area AfloorTot(fixed=false) "Total floor surface area";
initial equation
  AfloorTot = max(Modelica.Constants.small,sum({if IDEAS.Utilities.Math.Functions.isAngle(inc[i], IDEAS.Types.Tilt.Floor) then area[i] else 0 for i in 1:nSurf}));

This approach works, but does not allow symbolic processing during translation using the value of AfloorTot since its value is only known at initialization. In this particular case it does not matter, but there are cases where it limits the functionality or efficiency of our models. E.g. when you want to pass a parameter a where exp = if a then <linear expression> else <non-linear expression>. If the if-then-else cannot be simplified during translation then a non-linear algebraic loop is generated that could otherwise be linear (if a=true, and assuming an algebraic loop is generated that depends on exp).

[Mathadon]

@HansOlsson any feedback on this or do you need more input? I hope this can make it into the 3.5 spec.

[sjoelund]

I think one problem would be that this is different from how connections of parameters work in general: they don't generate any equations but essentially only assertions.

[Mathadon]

Instantiating an (expandable) connector declares variables and making connections to that connector generates equations through the connection sets, I don't see why this could not also work for parameters? It's just a matter of having a field for the variability of the variable? A parameter can be treated in the same way as a 'potential variable' as far as I can tell.

[HansOlsson]

Instantiating an (expandable) connector declares variables and making connections to that connector generates equations through the connection sets, I don't see why this could not also work for parameters?

There are several significant differences:

• Parameter-equations in connectors currently only generate assertions, not equations as non-parameters (as @sjoelund writes).
• Treating parameters as a 'potential variable' of a physical connector seems a bad fit; as a physical connector should have matching flow and potential, and parameters are excluded.
• It seems better to treat it as a non-physical connector, but in Modelica they are causal, i.e. input or output. For expandable connectors there are rules for determining the causality and the idea is that (at most) one connector in the system generates the signal and the rest use it. That seems better - except that we don't have causal parameters.

Looking at IDEAS.Buildings.Examples.ZoneExample it honestly doesn't seem like expandable connectors are an ideal solution as there does not seem to be multiple components communicating through a bus, instead each component is using a unique array element in the bus. To me it seems as if one of the following would be better:

• Having all parameters in an array at the top and propagating downwards instead (will be less readable models).
• Giving each component a unique number and use an inner component for collecting the data in some way.
• Component iterator proposal: https://github.com/modelica/ModelicaSpecification/blob/MCP/0021/RationaleMCP/0021/MCP-0021_ComponentIterators.pdf
• Or possibly some other solution to the original problem

[Mathadon]

I see now, I misinterpreted @sjoelund 's post.

I have indeed thought about using alternate approaches but they usually require much more user intervention (e.g. setting some unique index, as by your example), which is (very) prone to errors.

I can see from your explanation that there currently exists no functionality that can easily be used to implement this feature but that's life I guess.. =) I did some thinking too:

• Indeed, having causal parameters (using connections/connectors, right?) would help but that seems like a pretty big thing to introduce. It would allow parameter connections in the GUI, where you'd want to distinguish between parameter connections and continuous connections and this opens a whole range of possible problems I guess.
• Actually, the way we use work around the problem now works pretty well, where we send the parameter value as a causal signal through the expandable connector and then fetch the variable value on the other side of that connector. The only problem is that using a connector forces the variability to become 'continuous', due to which we have to use an initial equation to reduce the variability back to 'parameter'. Perhaps the solution is to no longer assume that a (causal) connector variable itself has continuous variability (I'm assuming here that this is indeed the case), but rather think of it as a pointer to another variable, and to fetch the variability of that variable. In our models, the translator would then see that the variability of the input of the connector is the same as the parameter that it is assigned to. I guess that this could work for physical connectors too, but there a variable value can depend on multiple variables in the connection set (instead of just 1), making it a bit harder for the translator to figure out what the highest variability of the connection set is.

Would that second option make sense? I.e. to no longer check variability against causal connector variables, but to check against the variable that assigns a value to that causal connector variable.

[mwetter]

I think the component iterator proposal would streamline a lot of model constructs that we are facing with the Buildings library when construction models of buildings with multiple rooms, district heating systems for multiple buildings, or air conditioning systems that serve multiple rooms.

@Mathadon : Would that also address your use case?

[Mathadon]

While the iterator proposal would facilitate solving some other problems that we are facing, I do not think that it would solve this particular use case where we want to grab the parameter value of one specific wall from one specific zone. The zone would be able to access the required parameter value from the wall, but it would not know what walls to consider; it should only consider walls that have a connection to the zone, and I see no way to deduce that information from the model.

One possible solution/addition to the proposal would be to allow iterating like:

parameter Real A[:] = {c.A for c in class port.connectedInstances()}

[Mathadon]

@HansOlsson this is still an open issue within the IDEAS development. In a broader context I also see other use cases where components could exchange parameters in a similar way as they can exchange physical properties. Are there any plans for integrating this in the Modelica spec?

[HansOlsson]

@HansOlsson this is still an open issue within the IDEAS development. In a broader context I also see other use cases where components could exchange parameters in a similar way as they can exchange physical properties. Are there any plans for integrating this in the Modelica spec?

Sorry, I have missed this - I will have to investigate it more.

[Mathadon]

Thanks for considering it! Let me know in case you need further input from our side :)