I would like to discuss a modeling challenge encountered in the AixLib library. I am not sure whether it also exists in the MSL or other libraries dealing with multi-phase thermodynamics.
Problem
The problem boils down to the desire to factor out a computation of a ThermodynamicState record, for example, a non-trivial setState_phX call, store the result in a component of a model, and then use the component in one or more places where a continuous-time property (density, pressure, etc) is computed based on the state. Unfortunately, the ThermodynamicState record tends to include an Integer phase member, so the record cannot be equated to a function call with non-discrete-time argument expressions, and of course the arguments to setState_phX are not discrete-time.
In some cases, by sacrificing code readability and paying the price of code duplication, one can eliminate the ThermodynamicState record components and thereby comply with the variability rules. In other cases, such as PartialFlowCoefficient (https://github.com/RWTH-EBC/AixLib/blob/main/AixLib/Fluid/Actuators/Valves/ExpansionValves/BaseClasses/PartialFlowCoefficient.mo) I don't know what to do. There we have:
input Medium.ThermodynamicState staInl
"Thermodynamic state at valve's inlet conditions";
input Medium.ThermodynamicState staOut
"Thermodynamic state at valve's outlet conditions";
and if I understand the design correctly, the idea is that these are set in one place of the code, and then used in other places. Eliminating the staInl and staOut would completely ruin this design.
Ultimately, it feels to me as if the root of the problem is that an Integer component cannot be continuous-time. If it could, having a continuous-time ThermodynamicState would not be a problem either.
Possible solution: Declared non-discrete-time component variability
As a starting point for the discussion, say we would explicitly declare that the components are non-discrete-time like so:
input continuous Medium.ThermodynamicState staInl
"Thermodynamic state at valve's inlet conditions";
input continuous Medium.ThermodynamicState staOut
"Thermodynamic state at valve's outlet conditions";
or for the specific member of the state record:
continuous Integer phase;
The rules for using something declared continuous in expressions would be similar to using expressions wrapped in noEvent(…). To avoid difficult questions about how to interpret simulation results stored to file, one could simply avoid storing the non-discrete-time variables of discrete-valued type.
Of course, there would probably be more details to sort out and the design would require effort, but what are the alternatives?
Relation to new GenerateEvents semantics?
Since we haven't implemented the new #3610 semantics for GenerateEvents = true in System Modeler, I'd also appreciate if someone with an up-to-date implementation (I am thinking of you, @HansOlsson), could shed some light on to what extent the new semantics come to the rescue here. Could it be the case that all constructions of these ThermodynamicState components already fulfill the rules of being discrete-time expressions?!
Note that this GenerateEvents = true in getPhase_ph wasn't there in 4.0.0:
https://github.com/modelica/ModelicaStandardLibrary/blob/8ae3d35c24e519cb2996cab20f3b13daf2b0c50a/Modelica/Media/R134a.mo#L2233
and that AixLib is still using MSL 4.0.0:
https://github.com/RWTH-EBC/AixLib/blob/2a0329b5899274e8d470e4e3e0e7e8a428918e49/AixLib/package.mo#L8
I would like to discuss a modeling challenge encountered in the AixLib library. I am not sure whether it also exists in the MSL or other libraries dealing with multi-phase thermodynamics.
Problem
The problem boils down to the desire to factor out a computation of a
ThermodynamicStaterecord, for example, a non-trivialsetState_phXcall, store the result in a component of a model, and then use the component in one or more places where a continuous-time property (density, pressure, etc) is computed based on the state. Unfortunately, theThermodynamicStaterecord tends to include anInteger phasemember, so the record cannot be equated to a function call with non-discrete-time argument expressions, and of course the arguments tosetState_phXare not discrete-time.In some cases, by sacrificing code readability and paying the price of code duplication, one can eliminate the
ThermodynamicStaterecord components and thereby comply with the variability rules. In other cases, such asPartialFlowCoefficient(https://github.com/RWTH-EBC/AixLib/blob/main/AixLib/Fluid/Actuators/Valves/ExpansionValves/BaseClasses/PartialFlowCoefficient.mo) I don't know what to do. There we have:and if I understand the design correctly, the idea is that these are set in one place of the code, and then used in other places. Eliminating the
staInlandstaOutwould completely ruin this design.Ultimately, it feels to me as if the root of the problem is that an
Integercomponent cannot be continuous-time. If it could, having a continuous-timeThermodynamicStatewould not be a problem either.Possible solution: Declared non-discrete-time component variability
As a starting point for the discussion, say we would explicitly declare that the components are non-discrete-time like so:
or for the specific member of the state record:
The rules for using something declared
continuousin expressions would be similar to using expressions wrapped innoEvent(…). To avoid difficult questions about how to interpret simulation results stored to file, one could simply avoid storing the non-discrete-time variables of discrete-valued type.Of course, there would probably be more details to sort out and the design would require effort, but what are the alternatives?
Relation to new GenerateEvents semantics?
Since we haven't implemented the new #3610 semantics for
GenerateEvents = truein System Modeler, I'd also appreciate if someone with an up-to-date implementation (I am thinking of you, @HansOlsson), could shed some light on to what extent the new semantics come to the rescue here. Could it be the case that all constructions of theseThermodynamicStatecomponents already fulfill the rules of being discrete-time expressions?!Note that this
GenerateEvents = trueingetPhase_phwasn't there in 4.0.0:https://github.com/modelica/ModelicaStandardLibrary/blob/8ae3d35c24e519cb2996cab20f3b13daf2b0c50a/Modelica/Media/R134a.mo#L2233
and that AixLib is still using MSL 4.0.0:
https://github.com/RWTH-EBC/AixLib/blob/2a0329b5899274e8d470e4e3e0e7e8a428918e49/AixLib/package.mo#L8