Interfaces

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.

5.5 Interfaces is a potential or an “across” variable and one flow or “through” variable whose product gives the power flow at the interface. This solution is the simplest possible interface which fulfills the requirement that energy is conserved in the component. Domains which deal with more than one type of energy or flows based on interacting potentials and with mass transport have more choices, but the following guidelines can be useful:

• It must be possible to express correct boundary conditions for the model. This requirement is clear for PDE models but it is equivalent for ODEs derived from PDEs describing conservation laws.

• Interfaces should in general be as small as possible. They should not carry more information than necessary. Sometimes this may conflict with minimizing numerical effort when variables have to be calcu-lated in two components instead of one.

• interface variables should have good physical interpretations that are familiar to the user. They can be measured variables and are often related to boundary conditions.

The guideline to use the across variable with potential character and the corresponding through variable breaks down for heat conduction when the last guideline is used. The correct solution according to the principle of conjugate effort and flow variables, see[Cellier, 1991], for heat conduction in solids is to use temperature and entropy flow, but engineers are not familiar with entropy flow and it is not measurable.

For thermo-fluid systems the design of connectors is not as straightfor-ward as is e. g., for electrical systems. One connector has to carry several flows and transmit several potentials. A further complication is that the true physical potentials that are the driving force for a phenomenon, e. g., the chemical potential, are often replaced by other, approximative quan-tities for practical reasons. It is often convenient to use extra variables in connectors to avoid redundant property calculations. A boundary layer for mass- or heat transfer can be implemented as a separate submodel and certain fluid properties are needed within the boundary layer submodel, but for both coding and computational efficiency it is a disadvantage to have two identical or overlapping property calculation functions in the boundary layer and the control volume representing the free stream.

In summary, for thermo-fluid models there are several possible defini-tions of connectors. The choice in ThermoFluid has proven practical and in case that more variables need to be communicated between submodels, this can be handled via definition equations in modifications, see Chap-ter 3.

The connector for quasi-steady state single- or multi component flows contains the variables:

Chapter 5. The ThermoFluid Library

connector BaseFlow"connector for quasi steady−state flow"

parameter Integer nspecies(min=1);

parameter String MediumType= "unspecified" ; SIunits.MassFraction mass_x[nspecies];

SIunits.Pressure p;

SIunits.SpecificEnthalpy h;

flow SIunits.MassFlowRate mdot_x[nspecies];

flow SIunits.Power q_conv;

SIunits.Density d;

SIunits.Temperature T;

SIunits.SpecificEntropy s;

SIunits.RatioOfSpecificHeatCapacities kappa;

end BaseFlow;

The quantities are number of components, a string for the fluid type and the further types are self-explaining and taken from the Model-ica.SIunits library. The variable set in the Static.BaseFlow connector is not minimal but it has been chosen in the above way for efficiency rea-sons. Fluid property calculations are expensive and via including density, entropy and ratio of specific heats in the connector, fluid property calcu-lations can be omitted in simple flow models.

In the case of a dynamic momentum balance, the standard flow con-nector is extended with

connector BaseFlow"connector for dynamic flow"

. . .//up to here identical with the static connector flow SIunits.MomentumFlux G_norm;

SIunits.MomentumFlux dG;

end BaseFlow;

The momentum flux G_norm is originally a three dimensional vector which has been reduced to a scalar due to the one dimensional character of the library. The variable dG is an approximation of the spatial derivative of the momentum flux which allows to connect submodels with dynamic momentum flow without loss of accuracy at the connectors.

The definition of the HeatFlow connector is connector HeatFlow"discretized heat flow connector"

parameter Integer n;

SIunits.Temperature[n] T;

flow SIunits.Power[n] q;

end HeatFlow;

where n stands for the spatial discretization, T[n] for the temperature and q[n] for the heat flow.

5.5 Interfaces In theThermoFluidlibrary it is possible to model chemical reactions in a reaction subcomponent. The reaction subcomponent uses Modelica flow semantics for the molar net flows of reactants and products. The reaction components use the following connector definition:

connector ChemFlow"connector for reaction submodels"

parameter Integer n, nspecies;

parameter String MediumType="unspecified" ; SIunits.Temperature[n] T"temperature";

SIunits.Pressure[n] p"pressure";

SIunits.Concentration[n,nspecies] conc"concentration";

flow SIunits.Power[n] q"heat of reaction";

flow SIunits.MolarFlowRate[n,nspecies] rZ "product + reactant flows";

end ChemFlow

The variables in the ChemFlow connector are discretization number n, number of components nspecies, the fluid type, temperature, pressure, concentrations of the components, component specific enthalpies, molar flow rates and heat generation from the heat of reaction. In the standard ThermoFluidimplementation, the heat of formation of the reaction is taken care of by including it in the specific enthalpy so that the heat flow q= 0.

Under some circumstances, e. g., when reactions take place in a porous catalytic layer, it may be better to treat the heat of reaction separately.

For those cases, q is included in the ChemFlow connector.

A connector for mass diffusion for semi-permeable membranes is de-fined similarly, here the partial pressures of the components are the po-tential variables causing the diffusion mass flow.

connector DiffusionFlow"connector for membrane diffusion"

parameter Integer n, nspecies;

parameter String MediumType="unspecified" ; SIunits.Temperature[n] T"temperature";

SIunits.SpecificEnthalpy[n] dHMx"change of enthalpy";

SIunits.Pressure[n,nspecies] pp"partial pressures" ; flow SIunits.MassFlowRate[n,nspecies] rM "diffusion mass flow";

flow SIunits.Power[n] q"heat flow through membrane";

end DiffusionFlow

Apart from the basic connectors it is useful to provide shell models for typical configurations of connectors, e. g., two BaseFlow connectors and a HeatFlow connector for a control volume with heat transfer. All standard connectors configurations composed from the basic connectors above for control volumes, pipes, junctions, heat exchangers and reservoirs are predefined in the Interfaces package.

There is a particular shortcoming in the Dymola user interface that influences the class structure ofThermoFluid. When multiple inheritance

Chapter 5. The ThermoFluid Library

is used, only the graphics contained in the first inherited class are used in the user interface. This means that care has to be taken to make sure that all connectors and the model icon are defined in the first class in declaration order.