Inflow generation methods¶

Using the generators¶

Each generation method provided by the library has an executable Python script associated with it. Running the appropriate script executes the generation procedure. All inflow generation methods depend on a certain amount of parameters. These parameters are communicated to the script via a configuration file, which is passed as a command-line argument.

nameOfTheScript --config=configurationFileName

The configuration file is a simple text file, with the following layout

# This is a comment, it can describe the parameter below
parameterOne    valueOfParameter1

# Another comment
parameterTwo    valueOfParameter2

Which parameters should be present depends on the method that is being used. They are therefore described for each method individually below.

Random fluctuations with specified \(U_i\) and \(\langle u'_i u'_j\rangle\)¶

Theory¶

This method is presented in the appendix of [LWS98]. For each point of the inflow patch, for each time-step, three random values, \(\tilde u, \tilde v, \tilde w\), are drawn from the normal distribution with 0 mean and standard deviation 1. The following transformation is then applied to obtain the values of the velocity components:

\[\begin{split}& u = U + a_{11} \tilde u, \\ & v = V + a_{21} \tilde u + a_{22} \tilde v, \\ & w = W + a_{31} \tilde u + a_{32} \tilde v + a_{33} \tilde w. \\\end{split}\]

Here, \(a_{ij}\) is the Cholesky decomposition of the Reynolds stress tensor. Both the mean velocity components and the Reynolds stress tensor components should be provided by the user at each point of the inflow patch. It is easy to prove that the generated signal will adher to the prescribed values.

The critical flaw of this method is that the generated velocity signals are not correlated in neither space or time, meaning that no coherent structures are introduced at the inlet. The accuracy of the method can therefore be expected to be poor, and it is therefore recommended to not use for practical flow simulations. The method can be useful for academic studies wishing to compare the performance of a more advanced techniques to a baseline synthetic generation method.

Usage and practical information¶

The runRandomFluctuations script should be used to generate the fields. The script is parallelized using MPI, so it is possible to take advantage of all the available cores present on the machine.

As described above, the method requires the value of the mean velocity and the Reynolds stress tensor for each inflow patch point. These are expected to be provided in a simple text format:

For the mean velocity, each row should contain 3 space-delimited numbers, corresponding to \(U\), \(V\), and \(W\), respectively.

For the Reynolds stress tensor, each row should contain 6 space-delimited numbers, corresponding to \(\langle u'u' \rangle\), \(\langle u'v' \rangle\), \(\langle u'w' \rangle\), \(\langle v'v' \rangle\), \(\langle v'w' \rangle\), and \(\langle w'w' \rangle\).

The ordering of the rows should correspond to the order of points, as read by the inflow geometry reader. It is the user’s responsibility to ensure this.

The configuration file should define the following parameters.

All parameters associated with the chosen input and output formats. Refer to the associated parts of the User guide for information.

uMeanFile — the path to the file containing the mean velocity values.

reynoldsStressFile — the path to the file containing the Reynolds stresses.

dt— the time-step in the main simulation.

t0 — the start-time of the main simulation.

tEnd — the end-time of the simulation.

tPrecision — write precision for time values. Should be chosen according to dt.

Lund’s rescaling¶

Theory¶

This method was presented in a paper by Lund, Wu and Squires [LWS98]. The method is suitable for generating an accurate inflow field for a simulation which involves a turbulent boundary layer approaching from upstream. For example, it can be used in a simulation of flow around a smooth ramp or a backward-facing step.

In order to introduce the method, let us consider a zero-pressure flat plate turbulent boundary layer (TBL). At the inlet of the domain the desired characteristics of the boundary layer, such as \(\text{Re}_\tau\) and \(\text{Re}_{\delta_{99}}\), are known.

The central idea of the method is to obtain the values at the inlet by rescaling the velocity field from a plane located some place downstream, see Fig. 1. The rescaling procedure involved insures that the target characteristics of the boundary layer at the inlet are met. The plane located downstream is referred to as the recycling plane.

../_images/lund_rescaling.svg — Fig. 1 Schematic of the rescaling from a plane located downstream proposed by Lund et al [LWS98].¶

Since eddylicious does not interact directly with an ongoing simulation, the method has to be reformulated. Instead of using a recycling plane located downstream of the inlet in the main simulation, the proposed approach is to have a separate, precursor simulation dedicated to generating a database of two-dimensional velocity distributions. This database then serves as input for eddylicious, which applies the rescaling procedure as defined in [LWS98]. The rescaled velocity fields are then saved to the hard-drive and serve as inflow fields in the main simulation. The whole processes is schematicaly illustrated in Fig. 2

../_images/lund_rescaling_eddylicious.svg — Fig. 2 Schematic showing how the rescaling proposed in [LWS98] is implemented in eddylicious.¶

From now on the subscript prec will be used to refer to the values obtained in the precursor simulation. The subscript infl will be used to refer to values at the inlet of the main simulation

The rescaling procedure is based on the assumption of existence of similarity solutions for the mean stream-wise velocity profile in the inner and outer layers of a TBL. The following relationships stem from this assumption.

\[\begin{split}& U^{\text{inner}}(y^+) = u_\tau f_1(y^+),\\ & U_0 - U^{\text{outer}}(\eta) = u_\tau f_2(\eta).\end{split}\]

Another assumption, that is fulfilled automatically in the setting proposed by Lund et al [LWS98], but not within the framework of eddylicious, is that the relationships above are valid for both the precursor simulation and the main simulation. Strictly speaking, this requires the precursor simulation to be a TBL itself. However, a flow sufficiently similar to a TBL, like channel flow, can also be used with success.

Let \(\gamma = u_{\tau, \text{infl}}/u_{\tau, \text{prec}}\). Then, if the assumption above is fulfilled, the rescaling procedure for the mean streamwise velocity is

\[\begin{split}& U^\text{inner}_\text{infl}(y^+_\text{infl}) = \gamma U^\text{inner}_\text{prec}(y^+_\text{infl}),\\ & U^\text{outer}_\text{infl}(\eta_\text{infl}) = \gamma U^\text{outer}_\text{prec}(\eta_\text{infl}) + U_{0, \text{infl}} - \gamma U_{0, \text{prec}}.\end{split}\]

The rescaling for the mean wall-normal velocity is defined simpler, and is not as rigorously based on any physical assumption.

\[\begin{split}& V^\text{inner}_\text{infl}(y^+_\text{infl}) = V^\text{inner}_\text{prec}(y^+_\text{infl}),\\ & V^\text{outer}_\text{infl}(\eta_\text{infl}) = V^\text{outer}_\text{prec}(\eta_\text{infl}).\end{split}\]

The rescaling for the fluctuations is defined as

\[\begin{split}& (u'_i)^\text{inner}_\text{infl}(y^+_\text{infl}) = \gamma (u'_i)^\text{inner}(y^+_\text{infl}),\\ & (u'_i)^\text{outer}_\text{infl}(\eta_\text{infl}) = \gamma (u'_i)^\text{outer}(\eta_\text{infl}).\end{split}\]

The inner and outer components are blended together using a weighted average:

\[u_{i, \text{infl}} = u_{i, \text{infl}}^\text{inner}[1-W(\eta_\text{infl})] + u_{i, \text{infl}}^\text{outer}W(\eta_\text{infl}).\]

The weight function \(W(\eta)\) is defined as

\[W(\eta) = \frac{1}{2} \left\{ 1+ \dfrac{\tanh \left( \frac{\alpha(\eta - b)}{(1-2b)\eta +b}\right)}{\tan(\alpha)} \right\},\]

where \(\alpha=4\) and \(b=0.2\).

Usage and practical information¶

The runLundRescaling script should be used to generate the fields. The script is parallelized using MPI, so it is possible to take advantage of all the available cores present on the machine.

Depending on what data is available for the TBL desired at the inlet it may be convinient to either use \(\delta_{99}\) or \(\theta\) as the outer scale (that is the length used to normalize \(y\) to obtain \(\eta\)). Eddylicous can work with both and will use the scale which is provided in the config file, i.e. one of the two should be present:

delta99 — desired \(\delta_{99}\) at the inlet of the main simulation.

theta — desired momentum thickness at the inlet of the main simulation.

Note that using \(\theta\) requires to scale \(\eta\) before it can be plugged into function \(W(\eta)\). The value of 8 is used, based on the fact that \(\theta\) is around 8 times less than \(\delta_{99}\) for a wide range of Reynolds numbers.

As evident from the equations, defining the rescaling procedure, the value of the friction velocity at the inlet, \(u_{\tau, \text{infl}}\), is needed for the procedure. To this end, two options are available to the user. One is to simply provide the value of the friction velocity directly. The other is to let eddylicious compute it using the skin friction coefficient, \(c_f\), and an empirical estimate connecting it to either \(\text{Re}_{\delta_{99}}\) or \(\text{Re}_\theta\).

\[\begin{split}& c_f = 0.02 \text{Re}^{-1/6}_{\delta_{99}}, \\ & c_f = 0.013435(\text{Re}_\theta - 373.83)^{-2/11}.\end{split}\]

The friction velocity is then obtained as \(U_0 \sqrt{c_f/2}\). The related parameter in the configuration file is

uTauInflow — the friction velocity at the inlet of the main simulation. Either the value of the velocity or compute, which tells eddylicious to use one of the correlations above.

Another important feature is that eddylicious will always use only half of the datapoints in the wall-normal direction available from the precursor simulation. This is natural if the precursor is channel flow, but is in fact unnecessary when it comes to rescaling from another TBL simulation. Basically, this demands that the boundary layer used as a precusor does not occupy more than half of the computational domain in the wall-normal direction.

It is possible to choose which half of the precursor plane to consider, the bottom or the top. The following parameter in the configuration file controls this choice.

half — which half of the precursor plane to grab the data from. Either bottom or top.

Note, that this means that a single channel flow precursor actually contains two independent precursor datasets.

The rescaling formulas involve the velocity from the precursor simulation evaluated for the values of \(y^+\) and \(\eta\) defined by the TBL at the inflow of the main simulation. These values are obtained using linear interpolation. This means that the values of \(\text{Re}_\tau\) and \(\text{Re}_\theta\) for the precursor simulation must be higher than that at the inflow of the main simulation. Applied to rescaling from a precursor TBL this means that one can only rescale from “downstream”.

In the current implementation, eddylicious will compute the highest value of \(\eta\) available for the precursor simulation. Then it will pick the points in the main simulation for which \(\eta\) is lower than this computed value. This ensures that interpolation is possible for the outer part of the profile. These chosen points will be considered as containing the inflow TBL. In all points above, the freestream velocity will be prescribed. If the range of \(\eta\) in the precusor is not sufficient to cover the whole inflow TBL, a jump in the mean streamwise velocity will be observed.

Note, that no similar procedure is performed for \(y^+\). Therefore, if the range of \(y^+\) in the precursor does not cover that in the inflow TBL, eddylicious will simply crash.

Besides for the parameters mentioned above, the configuration file should also define the following parameters.

All parameters associated with the chosen input and output formats. Refer to the associated parts of the User guide for information.

yOrigin — the wall-normal coordinate of wall which the boundary layer is attached to in the main simulation. This is used when evaluating non-dimensional coordinates like \(y^+\). Also this is used to determine the “orientation” of the TBL with respect to the wall-normal coordinate.

nuInflow — the kinematic viscosity value in the main simulation.

nuPrecursor — the kinematic viscosity value in the precursor simulation.

U0 — desired freestream velocity at the inlet of the main simulation.

dt— the time-step in the main simulation.

t0 — the start-time of the main simulation.

tEnd — the end-time of the simulation.

tPrecision — write precision for time values. Should be chosen according to dt.

Example configuration files can be found in the tutorial Channel flow in OpenFOAM using Lund’s rescaling.

Interpolation¶

Theory¶

This is a simple generator that just interpolates data from one two-dimensional point set to another. This may be useful when some inflow data already generated and it should be applied for different inflow patches, discretized by a different mesh. A particular example can be applying the method proposed in [ML17], where a channel flow precursor is used to generate inflow for a turbulent boundary layer simulation. Given precursor data, it only remains to interpolate it onto the mesh of the inflow boundary patch.

../_images/interpolation.svg — Fig. 3 Schematic showing how the interpolation is performed. Thick solid lines represent the geometry of the patches, Blue circles represent the grid points. The dashed rectangles represent the user-defined bounding boxes, thus filtering out some of the points.¶

The interpolation type used is currently nearest-neighbour. A bounding box for the points has to be prescribed explicitly by the user, both for the source and target points. This allows to filter out a part of the points, see Fig. 3. The points are then scaled to lie in unit square prior to interpolation.

Usage and practical information¶

The runInterpolation script should be used to generate the fields. The script is parallelized using MPI, so it is possible to take advantage of all the available cores present on the machine.

As usual, all parameters associated with the chosen input and output formats should be included in the config file. Refer to the associated parts of the User guide for information. The following parameters should be included as well.

xOrigin — the streamwise location of the inflow patch.

minYPrec, maxYPrec — wall-normal bounds for the source points.

minZPrec, maxZPrec — spanwise bounds for the source points.

minYInfl, maxYInfl — wall-normal bounds for the target points.

minZInfl, maxZInfl — spanwise bounds for the target points.