Determination of the Precursor Parameters

A procedure in four steps to determine the parameters (l

, b

, δ, U , ν

) for the precursor simulation, from the parameters (b

, h

, U

, θ

, ν) of the main simulation, is now proposed.

Step 1 The width of the channel, the kinematic viscosity, and the mo-mentum thickness are taken to be the same as for the main simulation, i.e. b

= b

, ν

= ν, and θ

= θ

.

Step 2 The bulk velocity for the precursor simulation is determined as fol-lows. The centreline velocity of the precursor is matched to the free-stream velocity of the main simulation, i.e. U

= U

. The bulk velocity is then determined by the relation,

U

U = f

(Re

), (4.10)

for channel flow. To obtain a computable semi-empirical expression, the ansatz, f

(Re

) ≈ 1 + α

Re

, is fitted to the DNS data of [23], which includes channel flow simulations at five different Re-numbers.

The resulting coefficient values are given in table 4.1, and the fit to data is illustrated in figure 4.3.

Step 3 The length-scale of the precursor simulation is defined by δ, which is determined from the relation,

δ

θ = f

(Re

), (4.11)

4.2. Strong Recycling of Channel Flow for TBL Simulations 29

Figure 4.3: Illustration of the functions f

and f

. The full lines are given by the semi-empirical expressions, with coefficients from table 4.1. The DNS values are taken from [23].

for channel flow. To obtain a computable semi-empirical expression, the ansatz f

≈ γ

+ α

Re

, is fitted to the DNS-data of [23]. The resulting coefficient values are given in table 4.1, and the fit to data is illustrated in figure 4.3.

Table 4.1: Coefficients in the semi-empirical expression for f

and f

. The coefficient values are obtained by a least-squares fit of the two ansatzes to the DNS-data from [23].

i α

β

γ

1 0.3427 0.1287 1.000 2 2.603 · 10

0.9834 11.28

Step 4 The length of the channel flow domain is determined to be propor-tional to the channel’s height. In Paper I, the analysis of two-point correlations shows that the value, l

= 8δ, can be considered suffi-ciently large.

Since the precursor simulation is set up based on the requirements of the

main simulation, it is natural to also do this with the grid generation. It

is thus recommended that the grid on the inflow patch matches the grid on

the sampling plane of the precursor simulation, and that the same time-step

is used in the two simulations.

Chapter 5

Eddylicious: A Python Package for Inflow

Generation

This chapter is dedicated to the description of a Python package for turbu-lent inflow generation developed by the author. The presented material is based on Paper III. In the first section the purpose of the package is dis-cussed. This is followed by a section presenting the architecture of the code and then a section outlining the currently implemented functionality.

5.1 Motivation and Purpose

In the previous chapter an overview of the existing approaches towards inflow generation was presented. Naturally, it is important to assess which methods perform best. Several papers [19, 47, 32, 6, 18] investigate this, but each study typically considers a relatively small number of methods. One reason for this is that the inflow generation methods are usually implemented within a framework of a specific CFD solver. This makes the task of testing a large set of methods tedious, since it involves a large amount of programming.

It is, however, possible to bypass this issue in the following way. Most modern CFD solvers support reading boundary data from files stored on the hard-drive. Therefore, it is possible to create a solver-independent inflow generation library, which would save the inflow fields to one or multiple files. The task of making all the implemented methods available to a certain solver would then boil down to implementing the ability to save the fields in a file-format that the solver supports.

The success of this approach relies on a collaborative effort to fill up the developed code with various inflow generation techniques. A research

31

group with sufficient experience with a given method should thus be able to contribute the source code implementing this method to the library. It is therefore imperative that the code of the library is open-source and that third-party contributions are welcome.

With these ideas in mind, the Python package eddylicious was cre-ated

. It is free software, provided under the GNU General Public Licence.

The currently implemented functionality of the package, as well as its prin-ciple components, are discussed further in this chapter.

One downside of the proposed framework is that it is impossible to im-plement methods that somehow interact with the flow-field inside the com-putational domain. This includes weak recycling methods, such as the LWS method [26]. Another example is the method developed in [45] which relies on introducing extra body-forces to the momentum equations.

Also, the size of the produced database of inflow velocities can potentially take up to several hundreds of gigabytes on the hard-drive. The size is directly proportional to the density of the computational mesh at the inlet and the number of time-steps for which the velocities are being generated.

Nevertheless, eddylicious has the potential to grow into a

compre-hensive library of inflow generation methods, compatible with several CFD

solvers. Since eddylicious is written in Python, developers have access to

a plethora of excellent libraries for scientific computing. This allows rapid

implementation of existing methods or prototyping new ones. Furthermore,

the programming is simplified because of the fact that such issues as

geo-metry decomposition and similar solver-related difficulties do not have to be

considered.