Skip to content

How to factor out a thermodynamic state record outside of a function? #3879

@henrikt-ma

Description

@henrikt-ma

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

Metadata

Metadata

Labels

discussionIndicates that there's a discussion; not clear if bug, enhancement, or working as intended

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions