Open modelica-trac-importer opened 5 years ago
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.
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
Comment by hansolsson on 6 Sep 2016 12:37 UTC Modelica specification tickets.
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.
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.
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!
Comment by filip.jorissen on 20 Jan 2018 09:15 UTC Still need this :)
@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 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?
@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).
@HansOlsson any feedback on this or do you need more input? I hope this can make it into the 3.5 spec.
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.
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.
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:
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:
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:
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.
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?
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()}
@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 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.
Thanks for considering it! Let me know in case you need further input from our side :)
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.
Migrated-From: https://trac.modelica.org/Modelica/ticket/1841