5. The ThermoFluid Library
5.4 Object-Orientation in ThermoFluid
Control Volume Flow Model Lumped Models
Lumped Composite Model
Discretized Model
Figure 5.3 Lumped, composite and discretized model objects. Lumped compos-ite models are composed from an alternating sequence of control volume and flow models in a container model. The equations in a discretized model are interleaved control volume and flow model equations. Identical boundary conditions are needed for lumped composite and distributed models: flows at the outlined and potentials at the filled connectors.
umes algebraically from the conditions dM
dt = 0, dU dt = 0.
5.4 Object-Orientation in ThermoFluid
The basic concepts of object-oriented modeling languages have been treated in Chapter 3. In this section we will give examples of how these concepts are applied in practice in theThermoFluidlibrary.
The main idea of the ThermoFluid library is to provide an extensi-ble basis for a robust thermo-hydraulic component library. The library is divided into five main parts:
Interfaces define the types of connectors used in the library. The flow connectors are of two different types; either with a static or dynamic flow description. For easy accessibility and inter-operability between different Modelica base libraries, the Interfaces package is always directly beneath the top level package.
Chapter 5. The ThermoFluid Library
Icons define the graphical appearance and the positioning of connectors for the classes in the Components package.
BaseClasses are the central part of models, the basic physical equations for a control volume: balance equations, state transformations and medium models. This is by far the largest package inThermoFluid.
All base classes are abstract and only the functions are usable “as is”, without further programming.
PartialComponents contain common code for component models, they allows code sharing and simplifies maintenance. Partial components are composed from base classes. While base classes are building blocks, partial components are almost complete models where few building blocks are missing.
Components are the user part of the library, models that can be used to build a system for simulation by graphical composition. Some com-ponents are composed of simpler comcom-ponents, they form a hierarchy of models and subsystems by themselves.
ThermoFluid
PartialComponents Components Icons
Interfaces BaseClasses
Figure 5.4 Top level package structure of theThermoFluidlibrary. The graphical symbols are explained in Appendix A.
These parts are illustrated in Figure 5.4. The ThermoFluid library makes systematic use of object-oriented structuring concepts in order to achieve reuse on the level of basic physical phenomena. This can be com-pared with traditional flow-sheet simulation packages that provide reuse on the level of engineering components like pumps and heat exchangers.
Partial components and base classes offer two additional levels of model reuse on a more fine-grained level. The structuring mechanisms that are used inThermoFluid are the same as in object-oriented programming:
Generalization is a strategy to handle complexity by classification of models and code sharing. Modelica offers
• inheritance and
• parameterization of generic class
5.4 Object-Orientation in ThermoFluid as important concepts for code reuse.
Decomposition is a divide-and-conquer strategy to deal with complexity.
In Modelica, decomposition can be achieved in two ways, either using
• multiple inheritance or
• component aggregation.
The language tools are not completely orthogonal to the concepts, multi-ple inheritance can also be classified as partial generalization and class parameterization is also applicable to components. In the following sub-sections we will give examples of how these features are applied in the ThermoFluid library. A critical discussion of the experiences with object-oriented modeling in Modelica and an attempt to deduce general guide-lines is found in Chapter 6.
Generalization
Inheritance A simple example of generalization is to identify common sets of variables and interfaces. Also some aspects of behavior are com-mon for a large class of quite different models. A general feature for flow equipment is the bi-directional convective heat transport, which can be expressed as
partial model FlowModelBase extends FlowVariables;
Boolean a_upstream"flow direction: true if positive at port a";
extends TwoPort;
equation
//for static flow , a_upstream depends on p2− p1
//for dynamic flow, a_upstream depends on sign( ˙m) //the equation for a_upstream is deferred to a derived class.
a.q_conv= if a_upstream then mdot∗a.h else mdot∗b.h;
end FlowModelBase;
Notice that the specification of the flow direction, a_upstream , and the mass flow, mdot , is postponed until later. For quasi steady state flow, the value of the Boolean variable a_upstream should not be based on the sign of the mass flow because a_upstream and mdot would end up in a mixed Boolean-Real equation system. Since the calculation of the mass flow depends on the type of flow equipment used, this additional informa-tion has to be provided in a derived class. For example, a quasi steady state flow resistance with a linear expression for pressure losses can be derived as:
Chapter 5. The ThermoFluid Library
model LinearOrifice"linear pressure loss − mass flow correlation"
extends FlowModelBase;
equation
a_upstream= a.p > b.p; //steady state flow mdot= mdot0/dp0∗(a.p−b.p);
end LinearOrifice;
The mass flow depends on the parameters mdot0, dp0 and the pres-sure difference over the valve.
The selection of equations that are included in a base class has to be done very carefully because equations can not be replaced or altered. The only way to change equations is when the equation is to encapsulate it in a replaceable component and replace the component.
Class Parameterization Class parameterization is a form of general-ization due to the restrictions on replacement classes, compare Chapter 3.
Type compatibility enforces the constraining class to be a generalization of all classes that can be supplied as a replacement class.
As an example for class parameterization inThermoFluidwe take the FlowModel from Section 5.6. Any flow model needs a loss model for the frictional pressure drop. In order to make the class FlowModel as gen-eral as possible, only a generic flow model is specified during base class implementation.
partial model FlowModel"flow model with generic pressure loss"
replaceable model
PressureLoss= GenericPressureLossModel;
extends PressureLoss;
. . .
end FlowModel;
The GenericPressureLossModel does not have to contain any equa-tions, but for practical reasons (and as a base class for inheritance in specialized pressure loss models) it contains the variables that are com-mon to all pressure loss models.
In specialized classes, the generic pressure loss model is then replaced by a more adequate model, which contains the equation(s) for computing the actual pressure loss.
model BlasiusPipe"Pipe using Blasius’ pressure loss correlation"
extends TwoPort;
extends Balances;
extends FlowModel(redeclare PressureLoss = BlasiusPlossModel);
end BlasiusPipe;
5.4 Object-Orientation in ThermoFluid Strictly speaking it is not necessary to use a replaceable base class for the pressure loss as above, it would be equally possible to use a replace-able component. In Modelica, this looks as follows:
partial model AlternateFlowModel"replaceable component flow model"
replaceable BlasiusPloss ploss extends GenericPressureLossModel;
end AlternateFlowModel;
In the alternative form of AlternateFlowModel a component ploss of type BlasiusPloss is declared. Possible replacements are constrained to be subtypes of GenericPressureLossModel . The functionality is the similar as in FlowModel , with two differences:
• The AlternateFlowModel has a default class BlasiusPLoss and replacement objects are constrained to be type compatible to Generic PressureLossModel , the constraining class. The GenericPressure -LossModel is a partial model , therefore classes using FlowModel can not be instantiated without redeclaring the pressure loss model.
AlternateFlowModel can be used directly because of an instantiable default class.
• Variables inside the ploss-component in AlternateFlowModel have to be accessed by dot-notation, e. g., as in:
ploss.dp= ploss.k*ploss.mdotˆ 2
This makes equations more difficult to read.
The last point, enhanced readability of equations, is one reason to use replaceable base classes similar to the FlowModel example above. This example also illustrates that the language means for decomposition and generalization have some overlap.
Decomposition
Decomposition can be achieved by declaring instances of models in a com-pound model or through multiple inheritance. Both types of decomposition are used in the central elements ofThermoFluid, control volumes and flow models. Composition of compound models from submodels is also called aggregation. InThermoFluid this is mainly used as assembly of physical phenomena into a complete model. In order to demonstrate decomposition with a larger example, the models for assembling a distributed pipe are presented.
Model Structure of a pipe A control volume formulation of a pipe uses all code structuring means described above. It can be decomposed into the following individual parts:
Chapter 5. The ThermoFluid Library
Balance equations take care of all mass- and energy interaction of the volume.
Thermal state equations use the mass and energy balances to define dynamic state equations and include a replaceable property model.
A flow model formulates the momentum balance and includes a friction pressure loss correlation.
Initialization code that defines typical initial conditions.
An heat transfer law. Heat transfer is optional because a simple pipe is often modeled as adiabatic.
A geometry record. The pipe models in system level models are often abstractions from more complex flow geometries. The geometry has to be parameterized in such a way that the simplified model param-eters can be approximated.
Decomposition makes use of multiple inheritance and composition from parts. For a pipe model this is illustrated in Figure 5.5. The base class for all types of pipes is a vectorized sequence of control volume and flow mod-els which inherits from four base classes. Components are symbolized by smaller blocks inside the puzzle bits. The darker top level class inherits from one partial component and adds a geometry parameterization and a heat transfer law as components. The heat transfer law connects to the
HeatAndMass object via a HeatFlow connector.
These parts are modeled individually using the following classes:
partial model TwoPort"base class for models with two flow interfaces"
parameter Integer nspecies(min=1) "number of chemical components";
Interfaces.FlowA a(nspecies=nspecies) "design−inflow";
Interfaces.FlowB b(nspecies=nspecies) "design−outflow";
end Balances;
partial model TwoPortLumped"mass− and energy balances"
extends TwoPort;
extends ThermoBaseVars(n=1) "variable definitions";
replaceable HeatObject heat(n=1) "heat transfer object";
equation
//contributions to mass− and energy balances dM_x[1, :] = a.mdot_x + b.mdot_x;
dU[1] = a.q_conv + b.q_conv − p[1]∗der(V[1]) + heat.Q_s[1];
dM[1] = sum(dM_x[1,:]);
. . .//further code omitted end Balances;
5.4 Object-Orientation in ThermoFluid
Initialize
balance
geo
flow
vectorized in variables thermal
medium
base classes
generalized pipe model
composed by
finalized pipe model geometry
multiple inheritance Single inheritance
Add & replace components
Figure 5.5 Composition of a generalized pipe model inThermoFluid. The three bottom levels are composed via multiple inheritance in a control volume class. This is specialized in a next step to a concrete pipe model, specifying the type of fluid, geometry and heat transfer mechanism. Initialization can be seen as a mixin class, defining a part of the behavior more precisely. Initialization of the flow model is only needed for a dynamic momentum balance.
partial model ThermalModel_xy"state equations for example states x and y"
replaceable model Medium= CommonRecords.StateVariables_xy;
equation
der(x) = A∗dM+ B∗dU+ C∗der(V); //real coefficients depend on states der(y) = D∗dM+ E∗dU+ F∗der(V);
. . .//further code omitted end ThermalModel_xy;
The state variables x and y are for illustration, the pairs which are actu-ally implemented are presented in Section 4.5, where also the coefficients A–F of the state transformation are given.
partial model Initialization_xy"initialization"
parameter Integer n(min=1) "number of cv’s";
SIunits.Pressure[n] p(start=init.p0, fixed=false) "pressure";
initial equation der(p) = zeros(n);
Chapter 5. The ThermoFluid Library . . .//further code omitted
end Initialization_xy;
The variables that are chosen as states are often known at initial time and they tend to give well-behaved equation systems. It is convenient to relate the initialization to the states, but this is not a requirement.
partial model FlowModel extends TwoPort;
dz∗der(mdot) = dG + (a.p − b.p)∗A− dp∗A;
. . .//the momentum balance end FlowModel;
and aggregation of these base classes leads to a general description of a control volume, e. g., a pipe
partial model Pipe_xy"base class of pipe models with states x,y"
extends Balances; //heat transfer connector etc.
extends ThermalModel_xy; //the dynamic states
extends Initialization_xy; //covers typical initial conditions extends FlowModel; //contains a replaceable pressure loss model end Pipe;
By the Modelica keyword extends the new model Pipe_xy inherits the attributes of all base classes. Common parts of the base classes are only inherited once. The parts which are inherited multiple times have to be identical, which is important due to the possibility of modifications of base classes along the inheritance paths. This may lead to the unpractical consequence that identical modifications have to be applied to several of the inherited classes in order to render them identical.
Some examples have shown how object-oriented constructs of the Mod-elica language are applied inThermoFluid. The constructs are used through-out the library structure to facilitate code sharing and make the library more flexible. In Chapter 6 it is investigated in more detail how to apply Modelica’s language features to the design of model libraries.