Vous êtes sur la page 1sur 60

AlbaNova Condensation Models

Master Thesis
Modeling of Direct Contact Condensation With OpenFOAM
Roman Thiele
Supervisors:
Henryk Anglart
Eric Lillberg
Division of Nuclear Reactor Technology
Royal Institute of Technology
Stockholm, Sweden, June 2010
TRITA-FYS 2010:43 ISSN 0280-316X ISRN KTH/FYS/10:43SE
ii
ABSTRACT
Within the course of the master thesis project, two thermal phase change models for direct contact conden-
sation were developed with dierent modeling approaches, namely inter-facial heat transfer and combustion
analysis approach.
After understanding the OpenFOAM framework for two phase ow solvers with phase change capabilities,
a new solver, including the two developed models for phase change, was implemented under the name of
interPhaseChangeCondenseTempFoam and analyzed in a series of 18 tests in order to determine the physical
behavior and robustness of the developed models. The solvers use a volume-of-uid (VOF) approach with
mixed uid properties.
It has been shown that the approach with inter-facial heat transfer shows physical behavior, a strong time
step robustness and good grid convergence properties. The solver can be used as a basis for more advanced
solvers within the phase change class.
iii
iv
ACKNOWLEDGEMENTS
I would like to extend my gratitude all my supervisors and listeners during the course of this work. Most
notably to Henryk Anglart for this guidance and the support as a supervisor and Carsten t Mannetje for
listening and letting me bounce of ideas. Also the rest of the reactor technology department for giving
valuable input during the bi-weekly meetings.
As well I would like to thank Westinghouse Electric Sweden AB and most notably Eric Lillberg for nancial
support and guidance in understanding the OpenFOAM source code.
v
vi
CONTENTS
1 Introduction 1
2 Theory Behind the Solvers 3
2.1 Fluid Dynamics Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Interface Tracking with VOF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Two Phase Change Models for One Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 The Combustion-like Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 The Inter-Facial Heat Transfer Approach . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Thermophysical Model for Temperature Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Program Code and Usage of the Solver 9
3.1 The Solver Code Explained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Phase Continuity Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Velocity Equation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 Pressure Equation Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 The Energy Equation Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 The Phase Change Model Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Functions of AlbaNovaInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Usage of interPhaseChangeCondenseTempFoam . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Sensitivity Analysis 19
4.1 The Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Grid Convergence Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Velocity and Time Step Dependency Test . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3 The Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Results 23
5.1 GCI Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Velocity Dependence Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Time Step Dependence Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
vii
viii CONTENTS
6 Conclusion and Recommendations 27
6.1 Conclusions on the Phase Change Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A Main Program Source Code 31
Appendix B Source Code Combustion Model (AlbaNovaCombustion) 35
Appendix C Source Code Interface Model (AlbaNovaInterface) 39
Appendix D High Velocity Test 43
LIST OF SYMBOLS
The list of symbols include bold face symbols, which indicate a vector property.
Symbol Dimensions Description
Latin Symbols
a variable Discretization coecients
A m
2
Inter-facial area
c
p
J/kg/K = m
2
/s
2
/K Specic heat
e variable Relative error
E
vl
J/m
3
/s Heat transfer between phases
f
c
Hz = s
1
Combustion frequency
g m/s
2
Gravity
GCI - Grid convergence index
h W/m
2
/K = kg/s
3
/K Heat transfer coecient
i J/kg Specic enthalpy
i
fg
J/kg = m
2
/s
2
Latent heat
l m Representative grid size
L m Characteristic length
m kg Mass
m kg/s Mass ow
N - Total number of cells
Nu - Nusselt number
p Pa Pressure
p - Apparent order of the solver for GCI
q W = kg m
2
/s
3
Heat
q

W/m
2
= kg/s
3
Heat ux
Q J/m
3
/s General heat source
r - Ratio of representative grid sizes
S variable Generic source term
T K or

C Temperature
u m/s Velocity
V
cell
m
3
Volume of a cell
x m Length
Greek Symbols
- Phase fraction of water
kg/m
3
/s Mass transfer per unit volume

b.l.
m Boundary layer thickness
variable Absolute error of global variable
m
2
/s Thermal diusivity
W/m/K = kg m/s
3
/K Thermal conductivity
Continued on next page
ix
x CONTENTS
Continued from previous page
Symbol Dimensions Description
Pa s = kg/m/s Dynamic viscosity
m
2
/s Kinematic viscosity
kg/m
3
Density
s Pseudo time
m
2
s
1
Flux
Subscripts
inf
Bulk
l
Liquid
m
Mixture
v
Vapor
LIST OF FIGURES
2.1 Volume-of-Fluid method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Energy transfer schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Cell layout with interface boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Graphical representation of the interface area model. . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Runtime command structure interPhaseChangeCondenseTempFoam . . . . . . . . . . . . . . 9
3.2 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Sketch of the simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 GCI comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Velocity dependency time development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Interface distribution velocity test of the interface model . . . . . . . . . . . . . . . . . . . . . 25
5.4 Interface distribution velocity test of the combustion model . . . . . . . . . . . . . . . . . . . 26
5.5 Time step dependency over time development . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
D.1 Condensation rate vs. time for inlet velocity 10m/s . . . . . . . . . . . . . . . . . . . . . . . . 43
D.2 Time step behavior high velocity test 0.15s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
D.3 Time step behavior high velocity test 0.30s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
D.4 Time step behavior high velocity test 0.80s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
D.5 Time step behavior high velocity test 1.35s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
xi
xii List of Figures
LIST OF TABLES
3.1 AlbaNovaInterfaceCoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 AlbaNovaCombustionCoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Transport properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Grid sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Test matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 GCI test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Velocity dependency test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Time step dependency results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
xiii
xiv List of Tables
CHAPTER 1
INTRODUCTION
Energy is a huge topic in todays society and with it comes nuclear energy. Nuclear power plants need to
be ecient and above all safe in all conditions. One of the more severe conditions is a large loss of coolant
accident (LOCA), which occurs if one of the main water and steam supplying pipes breaks. When this
happens, large amounts of steam are released into the containment (the so called dry well) of the power
plant. In order to keep the power plant safe, because the containment is not created for the high pressures as
they are present in pipes, the steam must be removed from the containment. The steam is guided through
pipes into so-called suppression pools (wet well), which contain large amounts of water to condensate the
steam and therefore relieve the containment from high pressures.
Experimenting with large setups and going through as many possible situations as possible is expensive and
time consuming. However, with modern computer tools, it is possible to simulate these conditions without
experimenting. The specialization in engineering that deals with this is called computational uid dynamics
(CFD). There are many companies and software tools available for more or less complete simulations of
dierent phenomena. One of these software packages is OpenFOAM R (OF). OF is an open source software
package that comes with a number of predened solvers for dierent tasks. However, since the package is
open source, new solvers can easily be created or existing solvers be modied. The remaining question is,
why should OF perform those tasks, which other software packages maybe already perform.
OF is, due to its open source nature, scalable and completely transparent when it comes to the development
of new solvers. The transfer of knowledge from academic use to industrial use works without hurdles and
the software can run on small and large machines (multi-core clusters) without license restrictions.
This report describes the development of a solver for direct contact condensation within the OpenFOAM
framework. Two dierent models are developed and a sensitivity analysis is performed on both solvers. The
development is meant as a basis for more sophisticated solvers and is by far not yet a complete solver. The
solvers are based on the assumption of saturated steam owing onto a sub-cooled water surface. In order to
fully enjoy this report, the reader should have a basic understanding of numerical simulation, thermodynamics
and uid dynamics.
Concerning the structure of this report, chapter 2 will give an overview of the uid dynamical and thermo
dynamical theory that is used to develop the solvers. In chapter 3 the program code will be explained.
Chapter 4 deals with setting up and explaining the sensitivity analysis, followed by a chapter with the
results. The last chapter concludes the report and gives recommendations for further development.
1
2 Introduction
CHAPTER 2
THEORY BEHIND THE SOLVERS
In this chapter the theory, which makes up the solvers and the models used in the solvers is explained. It
starts with the overall uid dynamics model, which gives the framework for the phase change models, which
are subsequently explained.
2.1 Fluid Dynamics Framework
The uid dynamics are based on the solver interPhaseChangeFoam which is provided by the OpenFOAM
1.6 software. It is a solver for two immiscible and incompressible uids with phase change features using
a volume-of-uid approach for interface tracking. The phase change models are interchangeable, and two
phase change models were developed within the scope of this work (see section 2.2). The solver is based
on the original work on cavitation models by Kunz [8], without the inuence of non-condensible gases. The
governing equations are not based on mass continuity equations but on volume continuity as can easily be
seen by the division by the density, , of the present phases as shown below.
_
1

m
_
p

+ u =
_
m
+
+ m

_
_
1

l
+
1

v
_
, (2.1)
where one can see a derivative with respect to , which is a pseudo-time derivative and is used for the time
iterative solution employed by Kunz. Equation 2.1 represents the volume continuity equation, where p is the
pressure, the density, u the velocity and m
+
and m

represent the mass ow between the phases. The


positive contribution is condensation and negative contribution comes from evaporation. Within the scope
of this paper, only the condensation is modeled and evaporation is set to 0.
The accompanying momentum equation is given by equation 2.2 as

m
u
t
+

m
u

+
m
u u = p +
m

2
u +
m
g , (2.2)
where
m
is the mixture dynamic viscosity and g is the gravitational acceleration. In order to track the
interface, a phase continuity equation is introduced.

t
+
_

m
_
p

+ u =
_
m
+
+ m

_
_
1

l
_
(2.3)
Equation 2.3 represents the phase continuity equation and introduces the phase fraction , which is bounded
by 0 and 1, representing gaseous and liquid phase, respectively. The importance and function of this function
is discussed in section 2.1.1, where the volume-of-uid approach is discussed in more depth.
The mixture density,
m
, of the governing equations is given by

m
=
l
+ (1 )
v
, (2.4)
where the subscripts l and v denote liquid and vapor, respectively.
3
4 Theory Behind the Solvers
2.1.1 Interface Tracking with VOF
As mentioned before, the solver uses a volume-of-uid (VOF) approach to track the interface and with this
information derive the momentum exchange between the phases. A volume-of-uid method was rst devised
by Hirt [6] as a method to track the interface of a uid dispersed in another continuous uid.
The VOF uses a scheme that tracks the interface of the dispersed phase by utilizing the phase fraction within
the cell. Every cell stores a value between zero and one, which denote empty and full of the continuous
phase, respectively. This function depends on time and position, meaning = (t, x), can be partially
dierentiated and moves with the uid, as can be seen in equation 2.3, the average phase continuity equation.
A visual representation is found in gure 2.1.
=0
=1
n
Figure 2.1: Graphical representation of the VOF method, depicting the normal vector of the interface and the cells
containing phase 1 (blue, = 1) and cells containing phase 2 (no color, = 0). The cells containing the interface
have 0 < < 1.
Due to the fact that the function follows the region of uid and not the interface it is a simple and economic
way to track the interface [6], since only one extra variable must be stored and can be handled as any other
transport equation. With the dierentiability of the function comes the convenience that the curvature and
the normal vector of the interface can be computed. Those values can then be used to calculate the interface
forces.
2.2 Two Phase Change Models for One Task
In this section the dierent models which are used for further development of the solver are introduced. There
are two of them, which are based on dierent approaches. The rst one being a combustion like approach,
treating the mass transfer between the phases in analogy to chemical combustion. The second model takes
an approach, which is closer to real physical behavior, using inter-facial heat transfer to calculate the mass
exchange between the phases.
For both models the energy and mass upon transfer must be conserved. This means, the energy that is
transfered (with the mass) away from the saturated steam must be equal to the energy being received by the
liquid.
Also, both models assume that the steam that enters the computational domain is at saturation conditions.
Therefore, cooling down of the steam is not necessary before the phase change occurs.
Two Phase Change Models for One Task 5
2.2.1 The Combustion-like Approach
The idea behind this approach is, that the neither heat transfer coecient nor the heat transfer area must
be known. This results in a simplied way of describing condensation.
As a starting point the energy per mass of the two sides of the interface can be expressed as
m
l
c
p
(T
sat
T
inf
) = m
v
i
fg
, (2.5)
where m
l
and m
v
are the mass of water and steam, respectively. T
sat
and T
inf
represent the saturation
temperature and the temperature of the water, whereas c
p
is the specic heat of water at saturation conditions
and i
fg
is the latent heat of water. This can be rewritten for the mass of steam transferred
m
v
=
m
l
c
p
(T
sat
T
inf
)
i
fg
. (2.6)
Equation 2.6 presents how much steam is condensed given a certain amount of water.
In order to describe the mass ow across the interface a so-called combustion frequency, f
c
, is introduced.
This frequency determines how much steam can condense within a certain amount of time. The resulting
equation for the mass ow is then
m
+
=
m
l
c
p
(T
sat
T
inf
)
i
fg
f
c
. (2.7)
The obtained mass ow rate must be considered the maximum of course. There must never be more steam
condensed than the cell contains. Therefore upon programming this into the solver, one must consider this.
As can be seen in equation 2.7 for the mass ow between, m
+
, the phases, all but one value, f
c
, are easily
obtainable from the IF97 databases [14].
2.2.2 The Inter-Facial Heat Transfer Approach
The starting point for this approach is again a balanced energy equation. The balance must be at the
interface between the two uids, as shown in gure 2.2. The energy balance is given by
q = h (T
sat
T
inf
) A
l
= m
+
i
fg
, (2.8)
where h is the heat transfer coecient, as determined within the next subsection, A
l
is the inter-facial area
between water and steam, m
+
is the mass condensation rate and i
fg
is the latent heat. From equation 2.8 it
can be seen that two parameters, namely the inter-facial area and the heat transfer coecient are unknowns.
They have to be determined or estimated within the simulation or beforehand. As the inter-facial area mainly
depends on the computational cell size, the volume ratio of steam and water and the direction of the interface
within the cell, this variable must be estimated during the simulation.
As for the heat transfer coecient, h, this can be determined before hand, knowing what the approximate
conditions during the simulation are, or it can be determined at runtime, based on some heat transfer
coecient model as described in the following part of this section.
Determining the Heat Transfer Coecient
In order to complete the inter-facial heat transfer model, the heat transfer coecient is needed. Two dierent
approaches are taken. Both assume a very low velocity and laminar ow.
Pure Conduction In order to determine the heat transfer coecient, h, some kind of model must be
devised. There are many models already available, which are more or less complicated. For this approach an
easy model based on the way the condensation is supposed to take place is devised. Taking a look at gure
2.2, one can see that the condensation takes places on a mostly at water surface at very slow laminar ow.
The assumptions for the heat transfer is that the heat ux across the interface between the two uids works
as in conduction. The Fourier law of conduction in one direction for the water side of the interface is given
by [7]
q

=
f
dT
dn
, (2.9)
6 Theory Behind the Solvers
Interface (Tsat)
}
dn
Steam (Tsat)
Water (Tinf)
q
Figure 2.2: Schematic of the energy transfer at the interface of steam and water as described by equation 2.8.
where q

is the heat ux,


f
is the thermal conductivity of the material (in this case water).
dT
dn
is the
temperature gradient. Assuming that most of the water is at bulk temperature, T
inf
, and that there is a
thin boundary region close to the interface equation 2.9 can be rewritten to
q

=
f
T
sat
T
inf

b.l.
, (2.10)
where
b.l.
represents the boundary thickness. As one can notice, the minus sign has disappeared. This is
due to the fact that the temperatures have been switched as well.
The heat ux due to convection is given by [7]
q

= h (T
sat
T
inf
) . (2.11)
Equating equations 2.10 and 2.11 and solving for h gives the following expression for the heat transfer
coecient
h =

f

b.l.
. (2.12)
Therefore, the total mass transfer from vapor to liquid is given by inserting 2.12 into the energy balance from
equation 2.8 and solving for m
+
, which results in
m
+
=

f
A
l
(T
sat
T
inf
)

b.l.
i
fg
. (2.13)
Nusselt Number for Flat Rectangular Plate Condensation Bejan [3] gives the following relation for
condensation of steam on a at horizontally placed plate, which is a similar conguration to the one found
within the inlet channel of the condensation tank.
Nu =
h
l
L

l
= 1.079
_
L
3
i
fg
g (
l

v
)

l

l
(T
sat
T
inf
)
_
1
5
, (2.14)
where Nu is the Nusselt number, h
l
the heat transfer coecient,
l
the thermal conductivity of the liquid,
L the characteristic length of the plate, g is gravity and
l
and
v
are the densities of the water and steam,
respectively.
The only unknown in this relation is the characteristic length L. However, in this case it is set to the diameter
of the inlet channel. Rewriting it gives the heat transfer coecient h
l
as
h
l
=

L
L
1.079
_
L
3
i
fg
g (
l

v
)

l

l
(T
sat
T
inf
)
_
1
5
. (2.15)
Thermophysical Model for Temperature Analysis 7
Inserting equation 2.15 into 2.8 the mass transfer rate across the inter-facial boundary is given as
m
+
=
h
l
A
l
(T
sat
T
inf
)
i
fg
, (2.16)
where h
l
is given by equation 2.15.
Both models should give approximately the same results, but in order to keep the model as close as possible
to physical behavior, the Bejan relation will be implemented into the solver.
Interface Area Model
For this model to work, the last thing left to do is to specify the heat transfer area, A
l
, from equation 2.16.
In order to avoid complex geometric modeling a simple model is developed. It is assumed that most cells
are regular in size. Meaning that the hexahedral cells have approximately the same length dimension in all
direction. It is further assumed, that the size of the inter-facial area depends on the liquid volume fraction
, which ranges between 0 and 1, as can be seen in gure 2.3. This means that at = 0.5, the area is largest
and that at 0 and at 1 no inter-facial area is present. For a good estimate of the largest inter-facial area, the
largest area within a regular cube is assumed.

1-
Interface
Cell boundary
Figure 2.3: Description of a regular cell with internal inter-facial boundary between the uid () and the gaseous
phase (1 ).
The maximum area A
max
is therefore given as
A
max
=

3 V
2
3
cell
, (2.17)
where V
cell
is the cell volume. And the linear function for the increase and decrease of the area is given by
A
l
=
_
2 0 < 0.5
2 (1 ) 0.5 1
. (2.18)
A graphical representation is given in gure 2.4.
2.3 Thermophysical Model for Temperature Analysis
The last part that will be added to the solver is a thermo-physical model for the water. In order to achieve
this, the energy equation for the water side must be solved. The general governing energy equation for the
liquid phase is given by [1]

t
(
l
i
l
) + (
l
ui
l

l
T
l
) = Q
l
+
c
i
fg
+ E
vl
, (2.19)
where i
l
is the enthalpy of the water, T is the temperature, is the phase fraction of water,
l
is the density
of water, u is the velocity of the water,
l
is the thermal conductivity of water, Q
l
is a general heat source
8 Theory Behind the Solvers
A
max
A
=0.5
Figure 2.4: Graphical representation of the interface area model.
to the water,
c
is the condensation rate from steam to water per unit volume, i
fg
is the latent heat and E
vl
is the energy transfer from vapor to liquid phase from conduction.
In order to have an easily solvable expression to implement, simplications can be performed. The rst
simplication is that there is no general internal heat source, meaning Q
L
= 0. Since only the water side
should be solved for, the added factor of may be dropped. Dividing both sides by c
p
in order to have only
temperature leaves the following expression.
T
t
+ uT
2
T =

c
i
fg
c
p
+ E
vl
, (2.20)
where is the thermal diusivity resulting from =
f
//c
p
. Equation 2.20 leaves two terms that need to be
modeled, namely E
vl
and
c
. The mass condensation rate per unit volume is modeled as described in section
2.2. For the conduction, which is also the boundary condition for the water side of the equation, a model
has to be devised. The temperature on the steam side should always be kept at saturation temperature T
sat
.
When discretizing equation 2.20 around the point of interest (subscript p), the result is
a
p
T
p
+

all
T
n
a
n
=

c
i
fg
c
p
+ E
vl
, (2.21)
where the a gives the coecients of all cells and the subscript n gives the nodes around node p. At the
boundary, the cell temperature should be at saturation temperature, giving T
p
T
sat
. This can be achieved
by modeling E
vl
with large numbers in a way that
E
vl
= S
large
T
sat
T
p
S
large
, (2.22)
where S
large
is a large number, much larger than the reciprocal of the precision of the computational system
(for double precision, the precision is 10
8
). Inserting equation 2.22 into equation 2.21 and solving for T
p
results in
T
p
=
S
large
T
sat
a
p
+ S
large

all
T
n
a
n
a
p
+ S
large
T
sat
(2.23)
This source E
vl
is conditionally applied for = 0.
CHAPTER 3
PROGRAM CODE AND USAGE OF THE SOLVER
This chapter treats the program code and gives an explanation of which parts have been edited and/or newly
written to accomplish the goal of the new solver interPhaseChangeCondenseTempFoam. The programming
was done in C++ with help of the libraries that are included in the OpenFOAM 1.6.x (OF) package and
compiled with a gcc version higher than 4.3.3.
interPhaseChangeCondenseTempFoam runtime commands
Reading: PISO
Time
Output: Courant number
delta t (calculated depending on CFL-condition)
alphaSubCycle.H
Performs analysis of
Creates (from weighted average of mixture)
Creates (flux)
Runs alphaEqn.H
C
o
r
r
e
c
t
i
o
n

l
o
o
p
AlphaEqn.H
transport equations with source terms from phase change models
Solves bounded equation
UEqn.H
Create tensor for solution of U with source from phase change model
If momentum predictor is set, solves the velocity equation
P
I
S
O

l
o
o
p
pEqn.H
Uses U tensor variable to create U
Sets up with U and volume flux from phase change model
Sets up pressure equation with and volume flux
Solves pressure equation
Updates velocity field accordingly
continuityErrs.H
Corrects the introduced continuity errors
TEqn.H (if energy equation is switched on)
Sets up energy equation with mass flux and
energy source term from phase change model for water side
Solves the energy equation
r
u
n
t
i
m
e

l
o
o
p
Figure 3.1: A graphical representation of the runtime command structure of interPhaseChangeCondenseTempFoam.
9
10 Program Code and Usage of the Solver
The solver is an enhanced version of the solver interPhaseChangeFoam, which is delivered with OF. The orig-
inal solver includes three dierent phase change models that are used to simulate cavitation. The new solver
omits these phase change models and only includes the two new phase change models that were developed in
chapter 2. In order to comply with the programming grammar, the solvers are called AlbaNovaCombustion
and AlbaNovaInterface, representing the combustion analysis approach (see section 2.2.1) and the inter-
facial heat transfer approach (see section 2.2.2), respectively. A graphical representation of the code can be
seen in gure 3.1. The gure omits the phase change models and only states at which part the phase change
models give data back to the main code, since the phase change models are a class on their own.
The newly added features compared to the original code include a preparation the solving of the energy
equation for the water side for the main class interPhaseChangeCondenseTempFoam and two new classes
called AlbaNovaCombustion and AlbaNovaInterface. The energy equation is not completely implemented,
see section 3.2 for more information.
3.1 The Solver Code Explained
Within the following section, the line numbers correspond to the line numbers in the solver source les, as
they can be found in the solver and the appendix.
All equations that can be solved separately, e.g. pressure, velocity and phase continuity, are treated in
separate .H les containing the setup of the necessary variables and the equation, as well as solving of
the equation. OF handles dierential equations and the solving of such, such as transport equations, in a
template class called fv<type>Matrix. This class allows an easy set up and solving of the equation with
dierent solution schemes which can be set on runtime. The code to solve a dierential equation in OF is
similar to the mathematical representation as it is given in the theory chapter.
3.1.1 Phase Continuity Code
As one can see in gure 3.1, the solver starts by solving the continuity equation for the liquid volume fraction.
This is done in two steps. At rst the alpha sub cycle is started. It rst creates a eld for the mass ux and
sets it to zero. This is done with every start of the time loop. Meaning that a new mass ux is written at
every start.
01: surfaceScalarField rhoPhi
02: (
03: IOobject
04: (
05: "rhoPhi",
06: runTime.timeName(),
07: mesh
08: ),
09: mesh,
10: dimensionedScalar("0", dimensionSet(1, 0, -1, 0, 0), 0)
11: );
12:
The next elds it creates is the ux due to interface compression phic in
38:
39: surfaceScalarField phic = mag(phi/mesh.magSf());
40: phic = min(interface.cAlpha()*phic, max(phic));
41:
After creating all those necessary elds for the phase continuity equation, the phase continuity equation is
set up and solved in alphaEqn.H. The rst step is to set up the relative ux. Since the solver relies on
mixed properties and one equation models. This is achieved by multiplying the compression ux with the
normalized normal vector of the interface.
04:
05: surfaceScalarField phir("phir", phic*interface.nHatf());
The Solver Code Explained 11
06:
The solver enters a loop, in which rst the actual explicit ux due to phase fraction , phiAlpha, and then
the sources which result from the phase change are set up and inserted into the bounded multiphase solver
that is supplied by OpenFOAM. The loop runs a predened number of correction iterations, which is set on
run time by the user.
The explicit ux of is set up via
09: surfaceScalarField phiAlpha =
10: fvc::ux
11: (
12: phi,
13: alpha1,
14: alphaScheme
15: )
16: + fvc::ux
17: (
18: -fvc::ux(-phir, scalar(1) - alpha1, alpharScheme),
19: alpha1,
20: alpharScheme
21: );
22:
where the rst term is due to the water phase and the second term is due to the gas phase. The schemes
determine how to discretize the eld.
During the next step, the source terms for evaporation and condensation are retrieved from the class that
handles the phase change. This can be one of the models handling phase change (AlbaNovaCombustion or
AlbaNovaInterface) and will explained at a later stage. The template data type Pair stands for two values,
which can be in any form of a eld or a scalar, depending on the denition given after tmp. The values can
be read as from an array as shown below in line 25 and 26.
23: Pair<tmp<volScalarField> > vDotAlphal =
24: twoPhaseProperties->vDotAlphal();
25: const volScalarField& vDotcAlphal = vDotAlphal[0]();
26: const volScalarField& vDotvAlphal = vDotAlphal[1]();
27:
28: volScalarField Sp
29: (
30: IOobject
31: (
32: "Sp",
33: runTime.timeName(),
34: mesh
35: ),
36: vDotvAlphal - vDotcAlphal
37: );
38:
39: volScalarField Su
40: (
41: IOobject
42: (
43: "Su",
44: runTime.timeName(),
45: mesh
46: ),
47: // Divergence term is handled explicitly to be
48: // consistent with the explicit transport solution
49: divU*alpha1
50: + vDotcAlphal
12 Program Code and Usage of the Solver
51: );
The two source terms volScalarField Su and volScalarField Sp represent the sources due to the dier-
ence between condensation and vaporisation and due to convective transport of the water phase, respectively.
After forming and establishing all elds necessary for the MULES solver that is supplied with OpenFOAM
[9, MULES], it is run. The MULES code is described as a Multidimensional universal limiter with explicit
solution, which solves convective-only transport equations with upper and lower limits, as required by the
-transport equation. The call for the MULES solver is given by
55: MULES::implicitSolve(geometricOneField(), alpha1, phi, phiAlpha, Sp, Su, 1, 0);
The next step is to correct the mass ux for the new found -values. Which is done in line 57:
57: rhoPhi +=
58: (runTime.deltaT()/totalDeltaT)
59: *(phiAlpha*(rho1 - rho2) + phi*rho2);
After the correction loop, the condensation rate is written into the condensation rate eld, which can be used
at a later stage, for example within the source term of the temperature equation.
63:
64:
65: Pair<tmp<volScalarField> > mDotAlphal =
66: twoPhaseProperties->mDotAlphal();
67: const volScalarField& mDotcAlphal = mDotAlphal[0]();
68: mDotCondense = mDotcAlphal*(1-alpha1); // multiply by (1-alpha1) because given back that way
After leaving the alphaEqn.H le the mixture density is updated with the appropriate values, as line 52
in the alphaEqnSubCycle.H shows.
53: rho == alpha1*rho1 + (scalar(1) - alpha1)*rho2;
3.1.2 Velocity Equation Code
After solving the phase continuity the equation for solving the velocity distribution is set up in UEqn.H. Due
to the coupling of the velocity and pressure equation, the velocity equation is only set up, but not solved
instantly, as can be seen below.
01: surfaceScalarField muE
02: (
03: "muEff",
04: twoPhaseProperties->muf()
05: + fvc::interpolate(rho*turbulence->nut())
06: );
07:
08: fvVectorMatrix UEqn
09: (
10: fvm::ddt(rho, U)
11: + fvm::div(rhoPhi, U)
12: - fvm::Sp(fvc::ddt(rho) + fvc::div(rhoPhi), U)
13: - fvm::laplacian(muE, U)
14: - (fvc::grad(U) & fvc::grad(muE))
15: //- fvc::div(muE*(fvc::interpolate(dev2(fvc::grad(U))) & mesh.Sf()))
16: );
The muEff scalarField, represents the mixture dynamic viscosity of the uid. The velocity equation is set up
so that all sources end up on the LHS and the whole equation is set to zero. The rst, the second and the
fourth term in the equation correspond to the full partial derivatives that involve u that are present in the
momentum equation 2.2. The third and fth, lines 12 and 14, respectively, are the negative of part of the
The Solver Code Explained 13
product rule of dierentiation in order to obtain only the derivative with respect to u.
Consider the following derivative as it is given in line 10,
d( u)
dt
= u
d
dt
+
du
dt
. (3.1)
In line 12, however, the time derivative of rho is multiplied with U and subtracted. Leaving only

du
dt
(3.2)
within the equation. The same is true for all the other derivatives that include rho (muEff contains a
multiplication with rho in line 5). This avoids a problem that would arise due to the interface within the
eld. At the interface, the density changes abruptly, in real life this is a discontinuity. Due to this abrupt
change, the gradients become very steep, and would introduce velocity sources that are not actually present
across the interface, because the uid in front of the interface moves with the same velocity as the uid
behind the interface.
3.1.3 Pressure Equation Code
With the velocity equation fully set up (note: velocity is not yet solved for), the solver enters the pressure
solution step within pEqn.H. The rst step is to predict the velocity, since it is needed to set up the ux for
the pressure equation. This is achieved in lines 1 to 5.
01: {
02: volScalarField rUA = 1.0/UEqn.A();
03: surfaceScalarField rUAf = fvc::interpolate(rUA);
04:
05: U = rUA*UEqn.H();
At rst the central coecient of the velocity equation matrix are retrieved and inverted (line 2), where
UEqn.A() give the central coecients [9, fvMatrix]. Line 5 then predicts the velocity by multiplying the
reciprocal of the central coecients with the operation source from the same matrix.
With the predicted velocity the ux that depends solely on the velocity is created.
07: surfaceScalarField phiU
08: (
09: "phiU",
10: (fvc::interpolate(U) & mesh.Sf())
11: + fvc::ddtPhiCorr(rUA, rho, U, phi)
12: );
The term ddtPhiCorr() introduces a correction for the divergence of the face velocity eld (the velocity
eld was interpolated from cell central stored to cell face stored) by taking out the dierence between the
interpolated velocity and the real ux [9].
Within the next step, the complete ux is constructed, by taking into account not only the ux due to
velocity, but also due to other forces.
16: phi = phiU +
17: (
18: fvc::interpolate(interface.sigmaK())*fvc::snGrad(alpha1)*mesh.magSf()
19: + fvc::interpolate(rho)*(g & mesh.Sf())
20: )*rUAf;
where the rst term accounts for the ux due to velocity, the second term accounts for the interfacial forces
(sigmaK) and the third term account for buoyancy forces ( g).
After setting up the ux, the sources due to the phase change are set up. This is done in lines 22 to 25.
14 Program Code and Usage of the Solver
22: Pair<tmp<volScalarField> > vDotP = twoPhaseProperties->vDotP();
23: const volScalarField& vDotcP = vDotP[0]();
24: const volScalarField& vDotvP = vDotP[1]();
Following getting the necessary values for the source, the pressure equation is set up. This is done in a
for-loop, which calls dierent steps depending on the number of iterations and how far the for-loop has
progressed. The steps in line 38 and 47 are always performed, and are necessary to solve the problem as they
represent the nal solving and the correction of the ux, respectively.
26: for(int nonOrth=0; nonOrth<=nNonOrthCorr; nonOrth++)
27: {
28: fvScalarMatrix pEqn
29: (
30: fvc::div(phi) - fvm::laplacian(rUAf, p)
31: - (vDotvP - vDotcP)*pSat + fvm::Sp(vDotvP - vDotcP, p)
32: );
33:
34: pEqn.setReference(pRefCell, pRefValue);
35:
36: if (corr == nCorr-1 && nonOrth == nNonOrthCorr)
37: {
38: pEqn.solve(mesh.solver(p.name() + "Final"));
39: }
40: else
41: {
42: pEqn.solve(mesh.solver(p.name()));
43: }
44:
45: if (nonOrth == nNonOrthCorr)
46: {
47: phi += pEqn.ux();
48: }
49: }
Finally, an updated velocity eld is calculated by only adding/removing the change that was made to phi,
without the contribution to phi due to the velocity eld (phiU).
3.2 The Energy Equation Problem
For the energy equation, no solution could be found to implement it for one side only. The theory behind
the equation assumes that a discrete interface is available within the code. This, however, is not the case
with the framework provided. The solver is prepared to be compiled with an energy equation added to the
source code and has the necessary switches built-in on the user side. Nevertheless, at this point the energy
equation it not functional and it might be necessary to provide a two equation model in order to implement
the energy equation.
If an implementation can be found, it only needs to be programmed into the TEqn.H le and the code
recompiled.
3.3 The Phase Change Model Classes
The phase change model classes, AlbaNovaCombustion and AlbaNovaInterface directly inherit from the
base class phaseChangeTwoPhaseMixture, which is delivered with the OF package. The class provides virtual
functions for the functions mDotAlphal() and mDotP(), which give the mass ows between the phases as a
pair. A virtual function is a function that can be overwritten on inheritance [13]. Within the scope of this
solver development, only the mass ow from the vapor to the liquid side is modeled, whereas the ow in
opposite direction is set to 0. The pairing of those mass ows was not completely removed in order to further
The Phase Change Model Classes 15
develop the model to include evaporation due to boiling or alternative mechanisms.
Both functions return mass ow rates as a coecient to be multiplied with a pressure term (mDotP()) or an -
term (mDotAlphal()). mDotP() is used to calculate the pressure changes that occur due to this condensation
mass ow, whereas mDotAlphal() serves its purpose in the bounded -phase transport equation. The
functions were overwritten to include the temperature based phase change models described in chapter
2. These mass ow function have a non-virtual counterpart, which gives back the volume ow rates as
coecients, instead of the mass ow rates. This is necessary since, as described in the theory section, the
uid dynamical framework is based on volume continuity.
In gure 3.2 the class diagram for the two new classes AlbaNovaInterface and AlbaNovaCombustion are
shown. As one can see, the models directly inherit most of their functions from the base class. There are no
extra public functions implemented, but the virtual functions were overwritten, as described before. For the
interface model, two new private functions have been added, which calculate the heat transfer coecient,
hCoeff(), and the heat transfer area, interfaceArea(). The decision to run separate functions for these
two parameters is based on the fact, that with this method, the underlying models are easily exchangeable.
The full source code of the two models can be found in appendix B and appendix C, respectively.
AlbaNovaCombustion
- combFrequency_ : dimensionedScalar
- Tsat_ : dimensionedScalar
- Tinf_ : dimensionedScalar
- ifg_ : dimensionedScalar
- cp_ : dimensionedScalar
- mcCoe_ : dimensionedScalar
AlbaNovaInterface
- lambdaF_ : dimensionedScalar
- Tsat_ : dimensionedScalar
- Tinf_ : dimensionedScalar
- ifg_ : dimensionedScalar
- charLength_ : dimensionedScalar
- g_ : dimensionedScalar
- mcCoe_ : dimensionedScalar
- interfaceArea() : tmp<volScalarField>
- hCoe() : tmp<volScalarField>
phaseChangeTwoPhaseMixture
# phaseChangeTwoPhaseMixtureCoes_ : dictionary
# pSat_ : dimensionedScalar
+ phaseChangeTwoPhaseMixture()
+ ~phaseChangeTwoPhaseMixture()
+ pSat() : dimensionedScalar
+ virtual mDotAlphal() : Pair<tmp<volScalarField> >
+ virtual mDotP() : Pair<tmp<volScalarField> >
+ vDotAlphal() : Pair<tmp<volScalarField> >
+ vDotP() : Pair<tmp<volScalarField> >
+ correct()
+ virtual read() : bool
Figure 3.2: Class diagram of the AlbaNova phase change models with inheritance from the base class
phaseChangeTwoPhaseMixture. - denotes private attribute/operation, # denotes protected attribute/operation
and + denotes public attribute/operation.
3.3.1 Functions of AlbaNovaInterface
The rst function that was newly written for AlbaNovaInterface is for the heat transfer area A, as outlined
below.
069: Foam::tmp<Foam::volScalarField>
070: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::interfaceArea() const
071: {
072: // return the interfacial area based on model for interfacial area
073: // returns dimensions Area
074:
075: // model based on regular volume cells, taking the largest cut area
076: // as maximum for area, linear increase and decrease with alpha
077: const volScalarField& cellVolume =
078: alpha1 .db().lookupObject<volScalarField>("cellVolu");
079: volScalarField limitedAlpha1 = min(max(alpha1 , scalar(0)), scalar(1));
080:
081: const dimensionedScalar
16 Program Code and Usage of the Solver
082: areaFactor("areaFactor",dimensionSet(0,2,0,0,0,0,0), 0.0);
083:
084: volScalarField interfaceArea = alpha1 * areaFactor;
085: volScalarField maxArea = alpha1 * areaFactor;
086:
087: maxArea = sqrt(3.0)*pow(cellVolume,(2.0/3.0));
088: return tmp<volScalarField>
089: (
090: (neg(limitedAlpha1-0.5)*maxArea*2.0*limitedAlpha1) +
091: (pos(limitedAlpha1-0.5)*maxArea*(-2.0*( limitedAlpha1 - 1.0)))
092: );
093:
094: }
Since this class is not part of the runtime environment, it can only gain access to variables via input or via
input variables, or they need to be created somewhere along the programming code. This means that the
cell volume cellVolu, needs to be accessed via the passed variable alpha1. The variable contains a data
base that can give access to the run time variables. The access to those is created in lines 77 and 78. After
this, two new volume scalar elds are created to store the interface and maximum area of the each cell, they
are initialized with 0.
The other newly introduced function is the function to calculate the heat transfer coecient. The heat
transfer coecient is based on equation 2.15. The function is given by the following.
096: Foam::tmp<Foam::volScalarField>
097: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::hCoe() const
098: {
099: // from [Bejan, Convection heat transfer, 1995]
100:
101: return
102: (
103: 1.079 * lambdaF / charLength * pow(
104: (pow3(charLength ) * ifg * g * (rho1()-rho2()) ) /
105: (lambdaF * nuModel1().nu() * (Tsat - Tinf ) ) , 0.2 )
106: );
107: }
3.4 Usage of interPhaseChangeCondenseTempFoam
For the following section it is assumed the reader has a basic understanding of how to set up simulation cases
in OF, as only the most important steps for setting up a case for the new solver are explained. For more
information on how to set up cases, the reader is also referred to the user guide of OF [10, ch. 1 and ch. 2]
and the test cases on the CD.
Each of the models has its own set of parameters that are to be adjusted depending on the case that is run.
Three les need to be checked for consistency. The rst one if the transportDict le, which contains all pa-
rameters concerning water and steam properties, as well as general uid properties and switches. Both models
use the general switches and overall uid properties. The phases need their respective density and kinematic
viscosity set, where phase one is the continuous phase. The switch for phaseChangeTwoPhaseMixture can
be set to either AlbaNovaInterface or to AlbaNovaCombustion, as those are the only models that are
available with the solver. For the coecient for each model tables 3.1 and 3.2 are to be consulted for the
AlbaNovaInterface and AlbaNovaCombustion model, respectively. The switch for the temperature equation,
temperatureEquation needs to be set to off, since the equation has not been implemented yet.
In order to have the solver work properly, the solvers for the following variables need to be specied within
the fvSolution dictionary: alpha1, U, p, T (only in case the solver needs to run the temperature equation,
meaning temperature is switched on), pCorr, pFinal and PISO. Also, relaxation factors may be specied for
alpha1, U, p and T, but these are optional.
With each solver, certain schemes need to be specied. The specication for the schemes can be found within
Usage of interPhaseChangeCondenseTempFoam 17
Table 3.1: Input coecient for AlbaNovaInterface with sample values for ambient conditions. The dimensions
correspond to the dimensions that need to be given to OF.
Label Dimensions Value Name
lambdaF [1 1 -3 -1 0 0 0] 0.6 Thermal conductivity of water
Tsat [0 0 0 1 0 0 0] 373 Saturation temperature
Tinf [0 0 0 1 0 0 0] 293 Bulk temperature water
ifg [0 2 -2 0 0 0 0] 2256.4e3 Latent heat
charLength [0 1 0 0 0 0 0] 0.18 Characteristic length
gravity [0 1 -2 0 0 0 0] 9.81 Gravitational acceleration
nuL [0 2 -1 0 0 0 0] 1.004e-6 Kinematic viscosity water
cp [0 2 -2 -1 0 0 0] 4.1813e3 Heat capacity water
Pr [0 0 0 0 0 0 0] 5.5 Laminar Prandtl number
Table 3.2: Input coecient for AlbaNovaCombustion with sample values for ambient conditions. The dimensions
correspond to the dimensions that need to be given to OF.
Label Dimensions Value Name
combFrequency [0 0 -1 0 0 0 0] 0.8 Combustion frequency
cp [0 2 -2 -1 0 0 0] 4.1813e3 Heat capacity water
Tsat [0 0 0 1 0 0 0] 100 Saturation temperature
Tinf [0 0 0 1 0 0 0] 20 Bulk temperature water
ifg [0 2 -2 0 0 0 0] 2256.4e3 Latent heat
lambdaF [1 1 -3 -1 0 0 0] 0.5 Thermal conduction water
the provided test case within system/fvSchemes.
18 Program Code and Usage of the Solver
CHAPTER 4
SENSITIVITY ANALYSIS
The following chapter describes the sensitivity analysis conducted on the code that is described in chapter
3. The main input parameter that are believed to change the behavior of the code are the velocity, the cell
size and the time step. The OF framework handles automatic time step adjustment on runtime, but this can
also be switched o.
4.1 The Test Cases
Both models are tested and compared. As for the combustion model, the combustion frequency needs to
be tuned to a value, so that the condensation rate is approximately the same as it is for the interface area
model. This is done only once for the base case and kept at this value for all following cases. After the base
cases have been set up, the input parameters concerning the condensation and transport behavior will not
be altered. The observed quantity is the integrated condensation rate over all cells, m
+
.
The sensitivity analysis consists of 18 test cases. All tests are carried out on the same model with dierent
grid sizes, dierent inlet velocities and dierent time step setups. Each of the tests is run with three dierent
parameter values, except for the velocity. There three dierent velocities are chosen and a fourth velocity
from the grid convergence test is added.
Except for the time step dependency tests, the so called Courant number is kept at 0.25. The Courant
number gives the ratio of the time step, t, to the characteristic convection time u/x [5]. The ratio is used
to automatically determine the time step on runtime without input by the user.
In gure 4.1 the model that is used throughout the tests is shown. The model is based on the POOLEX
facility set up with a reduced main tank diameter from 2.4m to 1.33m and a reduced height of the wet well
compartment from 3.61 to 3.11m [11]. This was done in order to decrease the number of cells needed to
describe the model, since the steam is not expected to leave the pipe which reduces the impact on the mesh
surrounding the pipe.
4.1.1 Grid Convergence Index
For the grid test a parameter called the grid convergence index (GCI) is calculated based on the method
given by Celik [4] as outlined below. The rst step is to specify a representative grid size, l, by
l =
_
1
N
N

n=1
V
n
_
1/3
, (4.1)
where N is the total number of cells, and V
n
is the volume of the nth cell. A sum is used to describe the total
volume, because with dierent mesh sizes the total volume of the domain changes slightly, due to better or
worse representation of the edges. The dierent mesh sizes will be considered, where the l
3
> l
2
> l
1
and the
ratios between to grid sizes is above 1.3. The ratios are given by r
21
= l
2
/l
1
and r
32
= l
3
/l
2
. The apparent
19
20 Sensitivity Analysis
1.33m
3
.
1
1
m
2
.
5
5
m
0.22m
0.2m
Water Atmosphere
Inlet
Pipe
Steam
Figure 4.1: Simulation model used for all simulation, based on the POOLEX facility set up with reduced volume.
order, p, of the of the code can be calculated by the following three equation using a xed point iteration.
p =
1
ln(r
21
)
|ln |
32
/
21
| + q(p)| , (4.2)
where q(p) is given by
q(p) = ln
_
r
p
21
s
r
p
32
s
_
(4.3)
and s being given as
s = 1 sign(
32
/
21
) , (4.4)
where the absolute errors between the global variables of dierent grids are
32
= m
+
3
m
+
2
and
21
=
m
+
2
m
+
1
. The condensation rates are obtained on the dierent grid size test runs. The next step is to
calculate the extrapolated values by
m
+,21
ext
=
r
p
21
m
+
1
m
+
2
r
p
21
1
. (4.5)
In order to now nd the GCI, the approximate relative error between the nest and second nest grid are
calculated, by
e
21
a
=

m
+
1
m
+
2
m
+
1

(4.6)
and inserted into the equation giving the grid convergence index,
GCI
21
fine
=
1.25e
21
a
r
p
21
1
. (4.7)
The GCI
21
fine
gives the error band for the calculated global variable on the nest grid [12], in this case the
condensation rate, m
+
.
The Test Cases 21
4.1.2 Velocity and Time Step Dependency Test
In case of the velocity dependency test, the inuence of the velocity on the condensation rate is examined.
This is done by changing the inlet velocity. It is expected that due to higher velocities a break up of the
interface can occur, which might change the condensation behavior. One lower and two higher velocity are
selected. The lower velocity is set to 0.05 m/s, which simulates falling steam. The higher velocities are 0.2
m/s and 0.5 m/s, which simulate a slowly pumped insertion of steam into the water basin.
In the time step dependency test, the time step behavior is changed from automatic to xed time steps.
The inuence of this change on the condensation rate is also examined. From the aforementioned tests with
automatic time step control, it is known that in order to fulll a Courant number of 0.25 on the nest grid,
a time step of 0.001s is sucient. The chosen time steps are 0.001, 0.005 and 0.01.
4.1.3 The Test Cases
All test cases run with a predetermined set of parameters for it transport properties. The transport properties
were acquired from the IF97 database for water properties [14]. The pressure was chosen close to ambient
and a sub-cooling of 80K was chosen. The transport properties are listed in table 4.1.
Table 4.1: Transport properties of the test cases, from the IF97 data base [14].
Property Value
p
sat
1.1 bar
T
sat
375.29 K

l
997.71 kg/m
3

v
0.65 kg/m
3
i
fg
2250.410
3
J/kg
T
l
295.29 K

l
0.603 W/m/K
c
p
4183.3 J/kg/K

l
9.510
7
m
2
/s

v
1.910
5
m
2
/s
As mentioned before, the combustion model was tuned and the combustion frequency was set to 0.8 Hz. The
characteristic length for the heat transfer coecient, L, was set to the pipe diameter, 0.22m.
The chosen grids are given in table 4.2 and the test matrix is given in table 4.3. The ratios between the grids
are given as r
21
= 1.3089 and r
32
= 1.6348. Where the indices represent the grid numbers which are given
in table 4.2.
Table 4.2: Grid sizes for obtaining the GCI, including the representative grid size in m.
Grid name Cell count Representative grid size [m]
Grid 1 626914 1.981 10
2
Grid 2 279808 2.593 10
2
Grid 3 63964 4.239 10
2
22 Sensitivity Analysis
Table 4.3: Test matrix, where auto means that the time step is regulated automatically corresponding to a Courant
number of 0.25
Case # Model Grid Inlet velocity Time step
1 Interface 3 0.1m/s auto
2 Interface 2 0.1m/s auto
3 Interface 1 0.1m/s auto
4 Combustion 3 0.1m/s auto
5 Combustion 2 0.1m/s auto
6 Combustion 1 0.1m/s auto
7 Interface 1 0.05m/s auto
8 Interface 1 0.2m/s auto
9 Interface 1 0.5m/s auto
10 Interface 1 0.1m/s 0.001
11 Interface 1 0.1m/s 0.005
12 Interface 1 0.1m/s 0.01
13 Combustion 1 0.05m/s auto
14 Combustion 1 0.2m/s auto
15 Combustion 1 0.5m/s auto
16 Combustion 1 0.1m/s 0.001
17 Combustion 1 0.1m/s 0.005
18 Combustion 1 0.1m/s 0.01
CHAPTER 5
RESULTS
This chapter treats the results of the sensitivity analysis. It treats all tests separately. Firstly, the GCI test
is presented, followed by the tests for velocity and time step size dependency.
5.1 GCI Test Results
The grid convergence test runs each ran for 5 seconds real time over which the global mass condensation
rate, m
+
, was recorded and averaged over time. The average is used, because as one can see from the graphs
of the condensation rate against time in gure 5.1, the condensation rate changes with passing through the
cells in a sinusoidal fashion. This makes it hard to compare the various time steps and therefore an averaged
approach is considered.
From the graph it becomes apparent that with increasing grid density, the global condensation rate of the
interface model varies about a constant value. This value is reached shortly after initiating the simulation,
with a respective shorter time for a ner grid. For the combustion model however, no stable value is reached.
The condensation rate rises steadily over the 5 seconds of the simulation with spikes which are similar to the
sinusoidal variations seen in interface model graph in gure 5.1a.
The calculated apparent order of the interface model and the combustion model are 5.7 and 3.58, respectively.
The calculated GCI for the combustion model results in 82.35% and for the interface model in 2.02%, meaning
that for the nest grid with the combustion model, the acquired value is accurate to 82.35% and for the
interface model to 2.02%, neglecting the computer rounding errors. The full test results can be viewed in
table 5.1.
Table 5.1: Test results of the grid convergence index test.
Case # Avg. m
+
[kg/s]
Interface model
1 1.933 10
3
2 2.3897 10
3
3 2.2574 10
3
Combustion model
4 1.5137 10
3
5 1.774 10
3
6 0.8576 10
3
23
24 Results
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
0
0.5
1
1.5
2
2.5
3
x 10
3
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]


Grid 3, case 1
Grid 2, case 2
Grid 1, case 3
Time smoothed case 2
Time smoothed case 3
(a) Interface Model
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
0
0.5
1
1.5
2
2.5
x 10
3
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]


Grid 3, case 4
Grid 2, case 5
Grid 1, case 6
(b) Combustion Model
Figure 5.1: Graphs showing the condensation rate vs. time on dierent grids used for GCI calculations. In gure
(a) the time smoothed combustion rates have been added for comparison.
5.2 Velocity Dependence Test Results
As for the other test runs, the velocity test ran for 5 second, over which the average condensation rate
is calculated, these results are listed in table 5.2. The three dierent velocities chosen are complimented
by a fourth, which is taken from the GCI tests (cases 3 and 6). Figure 5.2 shows the development of the
condensation rate over time.
One can see that with higher velocities, the condensation rate is larger as well. This can be explained by
looking at the distribution of the interface in gures 5.3 and 5.4. Both models base their condensation on the
property of 0 < < 0, meaning with more cells being occupied by unequal to unity or zero, condensation
occurs at a larger rate.
For the interface model, a theoretical maximum condensation rate can be calculated. This maximum is
4.42910
4
kg/s. This mass ow corresponds to an inlet velocity of 1.7910
2
m/s. As one can see, the
theoretical maximum is lower than than the maximum that is obtained during the lowest velocity of 0.05m/s,
which results in a steady condensation.
Table 5.2: Test results of the velocity dependency test.
Case # Avg. m
+
[kg/s]
Interface model
3 2.2574 10
3
7 1.8246 10
3
8 2.8212 10
3
9 3.8715 10
3
Combustion model
6 0.8576 10
3
13 0.6746 10
3
14 1.105 10
3
15 1.6147 10
3
5.3 Time Step Dependence Test Results
For the analysis of the time step dependency, four dierent cases are compiled for each model; three dierent
time steps and the auto time step run from the GCI tests. The results of the average condensation rate is
shown in table 5.3.
Time Step Dependence Test Results 25
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
x 10
3
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]
Interface


Case 7, 0.05m/s
Case 3, 0.1m/s
Case 8, 0.2m/s
Case 9, 0.5m/s
Time smoothed rate
Theoretical Max
(a) Interface Model
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
x 10
3
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]


Case 13, 0.05m/s
Case 6, 0.1m/s
Case 14, 0.2m/s
Case 15, 0.5m/s
(b) Combustion Model
Figure 5.2: Graphs showing the global condensation rate development over time depending on dierent inlet veloc-
ities. In gure (a) the time smoothed condensation rates as well as the theoretical maximum condensation rate have
been added for comparison.
Figure 5.3: The interface distribution during the velocity dependency tests at time 2.5 s after initiation for all four
cases for the interface model.
In case of the interface model, it is easily recognized, that a change of the time step in this case, does not
have such a big impact. In fact, the change in condensation rate between case 10 and 11 is only 0.49% and
between case 10 and 12 only 0.54%, whereas the time step is multiplied by 5 and 10, respectively. This small
change is also veried by looking at the graph of the condensation rate versus time as depicted in gure 5.5a.
For the combustion model, the behavior is slightly dierent. With increasing time step size, the condensation
rate increases as well. After some time into the simulation, the condensation rate starts to divert from the
original value that is obtained with an auto adjusted time step behavior, as can be seen in gure 5.5b.
26 Results
Figure 5.4: The interface distribution during the velocity dependency tests at time 2.5 s after initiation for all four
cases for the combustion model.
Table 5.3: Overview of the average condensation rates for the time step dependency test including one auto adjusted
time step run.
Case # Avg. m
+
[kg/s]
Interface model
3 2.2574 10
3
10 2.2593 10
3
11 2.2482 10
3
12 2.2471 10
3
Combustion model
6 0.8576 10
3
16 0.8541 10
3
17 0.8732 10
3
18 0.8809 10
3
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
0
0.5
1
1.5
2
2.5
3
x 10
3
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]


Case 10, t = 0.001s
Case 11, t = 0.005s
Case 12, t = 0.01s
Case 3, auto
(a) Interface Model
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
0
0.2
0.4
0.6
0.8
1
1.2
x 10
3
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]


Case 16, t = 0.001s
Case 17, t = 0.005s
Case 18, t = 0.01s
Case 6, auto
(b) Combustion Model
Figure 5.5: Graphs showing the global condensation rate development over time depending on dierent time steps,
where auto means that the time step is adjusted with a given Courant number (0.25).
CHAPTER 6
CONCLUSION AND RECOMMENDATIONS
This chapter presents the conclusions that have been drawn from the results with respect to the theory
chapter. The latter part of this chapter presents the recommendations and how further research can be
conducted using the results of this work.
6.1 Conclusions on the Phase Change Models
The rst conclusion that can be drawn is that the one equation model that is implemented with the VOF
method employed by OF is unsuitable for implementing the energy equation. The interface spread that has
been observed in the velocity dependency tests (see section 5.2) of both models, makes the method that was
supposed to be employed invalid. For this to work, a sharper interface must be present.
The results of the GCI, the velocity dependency and the time step dependency test give an indication of the
physical validity of the proposed models. The range of condensation rates is close to what is expected from
previous experiments, like TransAT at LUT, Finland [2]. However, due to the absence of extensive test data,
the validity of the models cannot be completely conrmed.
The interface model shows great time step stability, because even with a time step increase by one magnitude,
the results only dier by 0.54% from the smallest time step used, which gives a Courant number of approxi-
mately 0.25. The grid convergence index shows that convergence for ner grids exists, with a GCI of 2.02%
for the nest grid used within the tests carried out. However, with higher velocities, the condensation rate
increases with higher velocities. This is a valid physical behavior (higher velocities give rise to turbulence,
which increases the heat transfer coecient), but should have not occurred with the developed model. The
behavior stems from the fact, that with higher velocity, there is a higher numerical diusion from the original
VOF framework employed by OF. Overall, including visual inspection, it can be said that the developed
interface model behaves in a physical sense and can be used for further development.
The combustion model on the other hand does not show a physical behavior. It was not possible to show a
grid convergence. The GCI remained at 82.35% for the nest grid. In addition, there is no stable condensation
rate present, as should be expected. This means that the current implementation of the combustion model
is not capable of predicting direct contact condensation behavior.
6.2 Recommendations
There are several aspects that need to be addressed in further work on this topic. The rst one being the
validation of the interface model with data from experiments. This is crucial, since otherwise the model can
not be used for condensation prediction. After validation or even during validation of the interface model
with data from experiments reecting the conditions it is implemented for now (low velocity steam injection),
improved models for the heat transfer and the interface model should be devised.
It is envisioned that an improved interface model includes information about the angle at which the interface
27
28 Conclusion and Recommendations
advanced through the cell in order to have a better estimate of the interface area within a cell. The next step
would be to write a new class for the heat transfer coecient in order to chose the coecient modeling before
the simulation starts. This however, can also lead to an automatic selection of the heat transfer coecient
model based on velocity consideration by the phase change model itself.
The combustion model approach should not be completely disregarded at this point. With a model for
the so-called combustion frequency, based on velocity, pressure, temperature and/or additional information,
which can be retrieved from within the simulation, this approach might lead to a valid model, that does
neither need to include a complicated heat transfer coecient model, nor a model for the interface area.
Further work also includes the implementation of the energy equation, which is crucial, since the prediction
of the temperature within the water is of great importance for safety systems. As stated before, this might
only be possible by implementing the devised phase change model into a two-equation model, in which every
uid is treated separately.
BIBLIOGRAPHY
[1] Henryk Anglart. Thermal Hydraulics in Nuclear Systems (KTH, Stockholm, 2008).
[2] Henryk Anglart, Djamel Lakehal, Vesa Tanskanen, and Mikko Ilvonen. BWR thermal-hydraulic issues:
dryout, core transients and steam injection to pressure-suppression pool, Dec. 2009. NURISP presenta-
tion, retrieved from personal conversation with Henryk Anglart.
[3] Adrian Bejan. Convection heat transfer (Wiley, New York, 1995), 2nd ed. edn. ISBN 9780471579724.
[4] Ismail B. Celik. Procedure for estimation and reporting of discretization error in CFD applications.
Journal of Fluids Engineering, 130, Jul. 2008. Editorial of JFE, Retrieved March 12, 2010.
[5] Joel Ferziger. Computational methods for uid dynamics (Springer, Berlin ;;New York, 2002), 3rd, rev.
ed. edn. ISBN 9783540420743.
[6] C Hirt and B Nichols. Volume of uid (VOF) method for the dynamics of free boundaries1. Journal of
Computational Physics, 39(1):pp. 201225, 1981. ISSN 00219991. doi:10.1016/0021-9991(81)90145-5.
[7] M Kaviany. Principles of heat transfer (Wiley, New York, 2002). ISBN 9780471434634.
[8] R Kunz. A preconditioned NavierStokes method for two-phase ows with application to cavitation predic-
tion. Computers & Fluids, 29(8):pp. 849875, 2000. ISSN 00457930. doi:10.1016/S0045-7930(99)00039-0.
[9] OpenCFD Limited. OpenFOAM programmers c++ documentation.
http://foam.sourceforge.net/doc/Doxygen/html/, 2010. Retrieved May 10, 2010.
[10] OpenCFD Limited. OpenFOAM user guide. http://www.openfoam.com/docs/user/, 2010. Retrieved
May 05, 2010.
[11] Eija Puska. Sar2010 : the Finnish research programme on nuclear power plant safety 2007-2010 :
interim report (VTT, [Espoo], 2009). ISBN 9789513872663.
[12] John W. Slater. Examining spatial (Grid) convergence. http://www.grc.nasa.gov/WWW/wind/valid/
tutorial/spatconv.html, Jul. 2008. Retrieved May 25, 2010.
[13] Bjarne Stroustrup. Programming : principles and practice using C++ (Addison-Wesley, Upper Saddle
River NJ, 2009). ISBN 9780321543721.
[14] Milton Venetos. Excel engineering. http://www.x-eng.com/, 2007. Downloadable database.
29
30 Bibliography
APPENDIX A
MAIN PROGRAM SOURCE CODE
001: /*---------------------------*\
002: ========= |
003: \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
004: \\ / O peration |
005: \\ / A nd | Copyright (C) 1991-2009 OpenCFD Ltd.
006: \\/ M anipulation |
007: ---------------------------
008: License
009: This le is part of OpenFOAM.
010:
011: OpenFOAM is free software; you can redistribute it and/or modify it
012: under the terms of the GNU General Public License as published by the
013: Free Software Foundation; either version 2 of the License, or (at your
014: option) any later version.
015:
016: OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
017: ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
018: FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
019: for more details.
020:
021: You should have received a copy of the GNU General Public License
022: along with OpenFOAM; if not, write to the Free Software Foundation,
023: Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
024:
025: Application
026: interPhaseChangeCondenseTempFoam
027:
028: Description
029: Solver for 2 incompressible, immiscible uids with condensation
030: phase-change. Uses a VOF (volume of uid) phase-fraction based interface
031: capturing approach. It also incorporates the solution of the energy
032: equation.
033:
034: Based on interPhaseChangeCondenseFoam and the phase change models associated
035: with this solver.
036:
037: The momentum and other uid properties are of the mixture and a
038: single momentum equation is solved. The energy equation is only solved for
039: the water phase.
040:
041: Turbulence modelling is generic, i.e. laminar, RAS or LES may be selected.
31
32 Main Program Source Code
042:
043: \*---------------------------*/
044:
045: #include "fvCFD.H"
046: #include "MULES.H"
047: #include "subCycle.H"
048: #include "interfaceProperties.H"
049: #include "phaseChangeTwoPhaseMixture.H"
050: #include "turbulenceModel.H"
051:
052: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
053:
054: int main(int argc, char *argv[])
055: {
056: #include "setRootCase.H"
057: #include "createTime.H"
058: #include "createMesh.H"
059: #include "readGravitationalAcceleration.H"
060: #include "readPISOControls.H"
061: #include "initContinuityErrs.H"
062: #include "createFields.H"
063: #include "readTimeControls.H"
064: #include "correctPhi.H"
065: #include "CourantNo.H"
066: #include "setInitialDeltaT.H"
067:
068: // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
069:
070: Info<< "\nStarting time loop\n" << endl;
071:
072: while (runTime.run())
073: {
074: #include "readPISOControls.H"
075: #include "readTimeControls.H"
076: #include "CourantNo.H"
077: #include "setDeltaT.H"
078:
079: runTime++;
080:
081: Info<< "Time = " << runTime.timeName() << nl << endl;
082:
083: #include "alphaEqnSubCycle.H"
084:
085: turbulence->correct();
086:
087: // --- Outer-corrector loop
088: for (int oCorr=0; oCorr<nOuterCorr; oCorr++)
089: {
090: #include "UEqn.H"
091:
092: // --- PISO loop
093: for (int corr=0; corr<nCorr; corr++)
094: {
095: #include "pEqn.H"
096: }
097:
098: #include "continuityErrs.H"
099: }
100:
101: if(temperatureEquation == "on")
33
102: {
103: #include "TEqn.H"
104: };
105:
106: twoPhaseProperties->correct();
107:
108: runTime.write();
109:
110: Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
111: << " ClockTime = " << runTime.elapsedClockTime() << " s"
112: << nl << endl;
113: }
114:
115: Info<< "End\n" << endl;
116:
117: return 0;
118: }
119:
120:
121: // ************************************************************************* //
122:
34 Main Program Source Code
APPENDIX B
SOURCE CODE COMBUSTION MODEL (ALBANOVACOMBUSTION)
001: /*---------------------------*\
002: ========= |
003: \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
004: \\ / O peration |
005: \\ / A nd | Copyright (C) 1991-2009 OpenCFD Ltd.
006: \\/ M anipulation |
007: ---------------------------
008: License
009: This le is part of OpenFOAM.
010:
011: OpenFOAM is free software; you can redistribute it and/or modify it
012: under the terms of the GNU General Public License as published by the
013: Free Software Foundation; either version 2 of the License, or (at your
014: option) any later version.
015:
016: OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
017: ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
018: FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
019: for more details.
020:
021: You should have received a copy of the GNU General Public License
022: along with OpenFOAM; if not, write to the Free Software Foundation,
023: Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
024:
025: \*---------------------------*/
026:
027: #include "AlbaNovaCombustion.H"
028: #include "addToRunTimeSelectionTable.H"
029:
030: // * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //
031:
032: namespace Foam
033: {
034: namespace phaseChangeTwoPhaseMixtures
035: {
036: deneTypeNameAndDebug(AlbaNovaCombustion, 0);
037: addToRunTimeSelectionTable(phaseChangeTwoPhaseMixture, AlbaNovaCombustion,
038: components);
039: }
040: }
041:
35
36 Source Code Combustion Model (AlbaNovaCombustion)
042: // * * * * * * * * * * * * * * * * Constructors * * * * * * * * * * * * * * //
043:
044: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaCombustion::AlbaNovaCombustion
045: (
046: const volVectorField& U,
047: const surfaceScalarField& phi,
048: const word& alpha1Name
049: )
050: :
051: phaseChangeTwoPhaseMixture(typeName, U, phi, alpha1Name),
052:
053: combFrequency (phaseChangeTwoPhaseMixtureCoes .lookup("combFrequency")),
054: Tsat (phaseChangeTwoPhaseMixtureCoes .lookup("Tsat")),
055: Tinf (phaseChangeTwoPhaseMixtureCoes .lookup("Tinf")),
056: ifg (phaseChangeTwoPhaseMixtureCoes .lookup("ifg")),
057: cp (phaseChangeTwoPhaseMixtureCoes .lookup("cp")),
058: mcCoe (rho1() * cp * (Tsat - Tinf ) / ifg )
059:
060: {
061: correct();
062: }
063:
064:
065: // * * * * * * * * * * * * * * Member Functions * * * * * * * * * * * * * * //
066:
067: Foam::Pair<Foam::tmp<Foam::volScalarField> >
068: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaCombustion::mDotAlphal() const
069: {
070: volScalarField limitedAlpha1 = min(max(alpha1 , scalar(0)), scalar(1));
071:
072: // create value for the second return, that it is zero but right dimensions
073: const dimensionedScalar
074: secondValue("2ndValue",dimensionSet(1,-3,-1,0,0,0,0),0.0);
075:
076: const scalar smallValue = scalar(1e-10); // can be used to remove division by zero
077:
078: return Pair<tmp<volScalarField> >
079: (
080:
081: // must be written in a way that (1-alpha) is missing to be multiplied
082: // with (1 - alpha), might have to be a max(1-limitedAlpha1,smallValue)
083: // but does not matter because it will be multiplied with (1-alpha) anyway
084:
085: min(rho2()*(1-limitedAlpha1), mcCoe *limitedAlpha1) * combFrequency
086: / max(1-limitedAlpha1,smallValue),
087:
088: limitedAlpha1 * secondValue * 0.0 //return value with 0 and right dimensions
089:
090: );
091: }
092:
093: Foam::Pair<Foam::tmp<Foam::volScalarField> >
094: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaCombustion::mDotP() const
095: {
096: const volScalarField& p = alpha1 .db().lookupObject<volScalarField>("p");
097: volScalarField limitedAlpha1 = min(max(alpha1 , scalar(0)), scalar(1));
098: // create 2nd value for return to be 0 but right dimensions
099: const dimensionedScalar
100: secondValue("2ndValue",dimensionSet(0,-2,1,0,0,0,0),0.0);
101: const dimensionedScalar
37
102: smallPressure("smallPressure",dimensionSet(1,-1,-2,0,0,0,0),10.0); // small value for
comparison against dividing by 0
103:
104: // return dimensions [s/m2]
105: // return mass ow divided by pressure
106: return Pair<tmp<volScalarField> >
107: (
108:
109: min(rho2()*(1-limitedAlpha1), mcCoe *limitedAlpha1) * combFrequency
110: / max(p, smallPressure ),
111:
112: limitedAlpha1 * secondValue * 0.0 // return value with appropriate dimensions and value 0
113:
114: );
115: }
116:
117:
118: void Foam::phaseChangeTwoPhaseMixtures::AlbaNovaCombustion::correct()
119: {}
120:
121:
122: bool Foam::phaseChangeTwoPhaseMixtures::AlbaNovaCombustion::read()
123: {
124: if (phaseChangeTwoPhaseMixture::read())
125: {
126: phaseChangeTwoPhaseMixtureCoes = subDict(type() + "Coeffs");
127:
128: phaseChangeTwoPhaseMixtureCoes .lookup("combFrequency") >> combFrequency ; // [1/s]
129: phaseChangeTwoPhaseMixtureCoes .lookup("Tsat") >> Tsat ;
130: phaseChangeTwoPhaseMixtureCoes .lookup("Tinf") >> Tinf ;
131: phaseChangeTwoPhaseMixtureCoes .lookup("ifg") >> ifg ;
132: phaseChangeTwoPhaseMixtureCoes .lookup("cp") >> cp ;
133: mcCoe = rho1() * cp * (Tsat - Tinf ) /ifg ;
134: return true;
135: }
136: else
137: {
138: return false;
139: }
140: }
141:
142:
143: // ************************************************************************* //
144:
38 Source Code Combustion Model (AlbaNovaCombustion)
APPENDIX C
SOURCE CODE INTERFACE MODEL (ALBANOVAINTERFACE)
001: /*---------------------------*\
002: ========= |
003: \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
004: \\ / O peration |
005: \\ / A nd | Copyright (C) 1991-2009 OpenCFD Ltd.
006: \\/ M anipulation |
007: ---------------------------
008: License
009: This le is part of OpenFOAM.
010:
011: OpenFOAM is free software; you can redistribute it and/or modify it
012: under the terms of the GNU General Public License as published by the
013: Free Software Foundation; either version 2 of the License, or (at your
014: option) any later version.
015:
016: OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
017: ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
018: FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
019: for more details.
020:
021: You should have received a copy of the GNU General Public License
022: along with OpenFOAM; if not, write to the Free Software Foundation,
023: Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
024:
025: \*---------------------------*/
026:
027: #include "AlbaNovaInterface.H"
028: #include "addToRunTimeSelectionTable.H"
029:
030: // * * * * * * * * * * * * * * Static Data Members * * * * * * * * * * * * * //
031:
032: namespace Foam
033: {
034: namespace phaseChangeTwoPhaseMixtures
035: {
036: deneTypeNameAndDebug(AlbaNovaInterface, 0);
037: addToRunTimeSelectionTable(phaseChangeTwoPhaseMixture, AlbaNovaInterface,
038: components);
039: }
040: }
041:
39
40 Source Code Interface Model (AlbaNovaInterface)
042: // * * * * * * * * * * * * * * * * Constructors * * * * * * * * * * * * * * //
043:
044: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::AlbaNovaInterface
045: (
046: const volVectorField& U,
047: const surfaceScalarField& phi,
048: const word& alpha1Name
049: )
050: :
051: phaseChangeTwoPhaseMixture(typeName, U, phi, alpha1Name),
052:
053: lambdaF (phaseChangeTwoPhaseMixtureCoes .lookup("lambdaF")),
054: Tsat (phaseChangeTwoPhaseMixtureCoes .lookup("Tsat")),
055: Tinf (phaseChangeTwoPhaseMixtureCoes .lookup("Tinf")),
056: ifg (phaseChangeTwoPhaseMixtureCoes .lookup("ifg")),
057: charLength (phaseChangeTwoPhaseMixtureCoes .lookup("charLength")),
058: g (phaseChangeTwoPhaseMixtureCoes .lookup("gravity")),
059: mcCoe ( (Tsat -Tinf ) / ifg )
060: {
061: correct();
062: }
063:
064: // * * * * * * * * * * * * * * Member Functions * * * * * * * * * * * * * * //
065:
066: // function to calculate the interface area when needed
067: Foam::tmp<Foam::volScalarField>
068: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::interfaceArea() const
069: {
070: // return the interfacial area based on model for interfacial area
071: // returns dimensions Area
072:
073: // model based on regular volume cells, taking the largest cut area
074: // as maximum for area, linear increase and decrease with alpha
075: const volScalarField& cellVolume =
076: alpha1 .db().lookupObject<volScalarField>("cellVolu");
077: volScalarField limitedAlpha1 = min(max(alpha1 , scalar(0)), scalar(1));
078:
079: const dimensionedScalar
080: areaFactor("areaFactor",dimensionSet(0,2,0,0,0,0,0), 0.0);
081:
082: volScalarField interfaceArea = alpha1 * areaFactor;
083: volScalarField maxArea = alpha1 * areaFactor;
084:
085: maxArea = sqrt(3.0)*pow(cellVolume,(2.0/3.0));
086: return tmp<volScalarField>
087: (
088: (neg(limitedAlpha1-0.5)*maxArea*2.0*limitedAlpha1) +
089: (pos(limitedAlpha1-0.5)*maxArea*(-2.0*( limitedAlpha1 - 1.0)))
090: );
091:
092: }
093:
094: // function to calculate the heat transfer coecient
095: Foam::tmp<Foam::volScalarField>
096: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::hCoe() const
097: {
098: // from [Bejan, Convection heat transfer, 1995]
099:
100: return
101: (
41
102: 1.079 * lambdaF / charLength * pow(
103: (pow3(charLength ) * ifg * g * (rho1()-rho2()) ) /
104: (lambdaF * nuModel1().nu() * (Tsat - Tinf ) ) , 0.2 )
105: );
106: }
107:
108:
109: Foam::Pair<Foam::tmp<Foam::volScalarField> >
110: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::mDotAlphal() const
111: {
112: // return dimensions [kg/m3/s]
113: // return condensation divided by (1-alpha)
114: const volScalarField& cellVolume =
115: alpha1 .db().lookupObject<volScalarField>("cellVolu");
116: volScalarField limitedAlpha1 = min(max(alpha1 , scalar(0)), scalar(1));
117:
118: const scalar smallValue(1e-5); //small value to avoid division by 0
119:
120: // create scalar for second value
121: const dimensionedScalar
122: secondValue("secondValue",dimensionSet(1,-3,-1,0,0,0,0),0.0 );
123: const dimensionedScalar
124: volFactor("volFactor",dimVol,1.0);
125:
126: volScalarField interfaceArea = this->interfaceArea();
127: volScalarField hCoe = this->hCoe();
128:
129: Info << "Max interFaceArea: "
130: << max(interfaceArea).value() << " m2" <<endl;
131: Info << "Max Heat transfer coefficient: "
132: << max(hCoe).value() << " W/m2/K" << endl;
133:
134: return Pair<tmp<volScalarField> >
135: (
136: // has to be divided by (1-limitedAlpha1) due to function denition
137: // division (pos(-cellVolume)*volFactor + cellVolume) saves from dividing by
138: // zero, because at boundary eld, cellVolume = 0, division by volume is
139: // to ensure that the mass transfer rate is given by kg/m3/s
140:
141: (hCoe * mcCoe * interfaceArea)/ (
142: max(1.0-limitedAlpha1, smallValue)
143: * (pos(-cellVolume)*volFactor + cellVolume)),
144:
145: limitedAlpha1 * 0.0 * secondValue
146:
147: );
148: }
149:
150: Foam::Pair<Foam::tmp<Foam::volScalarField> >
151: Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::mDotP() const
152: {
153: const volScalarField& p = alpha1 .db().lookupObject<volScalarField>("p");
154: const volScalarField& cellVolume =
155: alpha1 .db().lookupObject<volScalarField>("cellVolu");
156:
157:
158: volScalarField limitedAlpha1 = min(max(alpha1 , scalar(0)), scalar(1));
159: //small value for comparison in case of division by 0
160: const dimensionedScalar
161: smallValue("smallPressure",dimensionSet(1,-1,-2,0,0,0,0),10.0);
42 Source Code Interface Model (AlbaNovaInterface)
162:
163: const dimensionedScalar
164: volFactor("volFactor",dimVol,1.0);
165: // create scalar for second value
166: const dimensionedScalar
167: secondValue("secondValue",dimensionSet(0,-2,1,0,0,0,0),0.0 );
168:
169: volScalarField interfaceArea = this->interfaceArea();
170: volScalarField hCoe = this->hCoe();
171:
172: return Pair<tmp<volScalarField> >
173: (
174: // return dimensions [s/m2]
175: // return mass ow divided by pressure
176: // division (pos(-cellVolume)*volFactor + cellVolume) saves from dividing by
177: // zero, because at boundary eld, cellVolume = 0
178: (hCoe * mcCoe * interfaceArea)/
179: (max(p, smallValue ) * (pos(-cellVolume) * volFactor + cellVolume)),
180:
181: limitedAlpha1 * 0.0 * secondValue
182:
183:
184: );
185: }
186:
187:
188: void Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::correct()
189: {}
190:
191: bool Foam::phaseChangeTwoPhaseMixtures::AlbaNovaInterface::read()
192: {
193: if (phaseChangeTwoPhaseMixture::read())
194: {
195: phaseChangeTwoPhaseMixtureCoes = subDict(type() + "Coeffs");
196:
197: phaseChangeTwoPhaseMixtureCoes .lookup("lambdaF") >> lambdaF ;
198: phaseChangeTwoPhaseMixtureCoes .lookup("Tsat") >> Tsat ;
199: phaseChangeTwoPhaseMixtureCoes .lookup("Tinf") >> Tinf ;
200: phaseChangeTwoPhaseMixtureCoes .lookup("ifg") >> ifg ;
201: phaseChangeTwoPhaseMixtureCoes .lookup("charLength") >> charLength ;
202: phaseChangeTwoPhaseMixtureCoes .lookup("gravity") >> g ;
203: mcCoe = (Tsat -Tinf ) / ifg ;
204:
205: return true;
206: }
207: else
208: {
209: return false;
210: }
211: }
212:
213:
214: // ************************************************************************* //
215:
APPENDIX D
HIGH VELOCITY TEST
This appendix chapter describes a high velocity test, where the inlet velocity is increased to 10m/s from the
up to 0.5m/s in previous tests. The velocity corresponds to a mass ow of 0.988kg/s. All other parameters
correspond to the ones mentioned before. The test was only carried out with one of the two models, namely
the interface area model. This is due to the conclusions drawn, that this model has the better physical
behavior of the two developed models. The test has been stopped after 166 hours of simulation, which
resulted in 2.2s real time data.
In gure D.1 one can see the total condensation rate developing over time. It is to note that the typical
behavior of a sinusoidal increase or decrease is not present, as the interface passes through the cells. This
can be due to the high velocity. It has been shown before that with higher velocities the frequency of
increase/decrease increases, therefore, the increase decrease is probably still there, but not visible due to the
rapid change. Another reason can be that the interface is spread even more, due to the higher velocity and
that the sinusoidal phenomena is smoothed.
0 0.5 1 1.5 2 2.5
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
Total Time [s]
T
o
t
a
l

C
o
n
d
e
n
s
a
t
i
o
n

R
a
t
e
,

[
k
g
/
s
]


u
in
= 10m/s
Figure D.1: Graph of the total condensation rate over time for an inlet velocity of 10m/s.
The time at which the steam exists the lower end of the pipe can be clearly made out in the graph, as it
corresponds to a sharp increase of the condensation rate. When the bubble starts forming, the interface area
increases and more steam is allowed to condense.
43
44 High Velocity Test
Figures D.2 through D.5 show extraction of the behavior at dierent time steps. It is clearly visible that the
behavior is rather violent and for a better simulation, a turbulence model should have been selected.
Figure D.2: Figure showing the pressure, the velocity, alpha and the condensation rate per volume at time step
0.15s.
45
Figure D.3: Figure showing the pressure, the velocity, alpha and the condensation rate per volume at time step
0.30s.
Figure D.4: Figure showing the pressure, the velocity, alpha and the condensation rate per volume at time step
0.80s.
46 High Velocity Test
Figure D.5: Figure showing the pressure, the velocity, alpha and the condensation rate per volume at time step
1.35s.

Vous aimerez peut-être aussi