Capstone Project: Final Report

Capstone Project
Department of Mechanical Engineering
Final Report
OpenFOAM validation for high Reynolds number flows
Project Title: OpenFOAM validation for high Reynolds number flows
Date: 1st October, 2012
Identifier: CP-AOO-123
Student Workers: Benjamin Hillier, 329147

Mitchell Schram, 328346
Tim Maltby, 328722
Academic Supervisor: Professor Andrew Ooi
Academic Examiner: Dr. Jason Monty
Client Organisation: Defence Science and Technology Organisation
External Mentors: Dr. Ronny Widjaja

Dr. David Jones
Version: v5.3.11 Final, 1st October, 2012

Acknowledgements
The authors would like to acknowledge the helpful contributions of Dr. Daniel Chung, Dr. Jason
Monty, Dr. Nicholas Hutchins and Prof. Andrew Ooi. Special thanks to the industry partners Dr.
David Jones and Dr. Ronny Widjaja for their guidance, suggestions and time.
Terminology & Nomenclature

Re - Reynolds number
ui - velocity
u0i - turbulent fluctuation velocity
Ui - time averaged velocity
U - mean freestream velocity
D - characteristic length scale
ν - kinematic viscosity
ντ - eddy viscosity
p - pressure
p0 - turbulent fluctuation in pressure
ρ - density
xi - position vector
τij - Reynolds stress
k - turbulent kinetic energy
µτ - dynamic eddy viscosity, ρντ
∗
Sij - traceless mean strain rate tensor
δij - Kronecker’s delta (identity matrix)
- turbulent dissipation
ω - specific turbulent dissipation, k
u∗ - friction velocity
u∗ y
y+ - a measure of first cell centre distance, ν
I - initial turbulent intensity (0-1)
l - turbulent length scale
CP-AOO-123 i
Executive Summary
Computational Fluid Dynamics (CFD) has become an increasingly popular tool in the age of comput-
ing for studying the complex flows inherent in many real world engineering applications. The Defence
Science and Technology Organisation (DSTO) uses CFD extensively to evaluate and design systems for
both aviation and maritime uses. One of the major limiting factors facing the uptake of CFD today is
the cost of commercial CFD packages. One solution to this is the use of freely available, open source
software packages such as OpenFOAM. Before any such package can be utilised with confidence, it must
be shown to produce accurate solutions to a wide range of flow problems under a variety of conditions.
This report attempts to validate part of the OpenFOAM suite for high Reynolds number flows.
A significant difficulty in the simulation of fluids at high Reynolds numbers is the problem of turbulence.
Turbulence is characterised by the presence of random time dependent fluctuating velocities and pressures
in a highly three dimensional manner with an extremely wide range of scales. There are three options for
dealing with this extremely complex physical and mathematical phenomenon. The first is to ignore the
effects of turbulence, however this is clearly undesirable for many applications as turbulence can have a
drastic effect on the flow condition. The second is to resolve the mathematical complexity of turbulence
by increasing the resolution of the computational domain to match the smallest scale turbulence events
possible. While this option provides the highest level of accuracy, for complex geometries it requires a
computational effort which is out of reach of even today’s most advanced computers. The last and most
common option is to make simplifying assumptions to the governing equations of fluid dynamics, the
Navier-Stokes equations, and numerically model the remaining turbulent properties. This report studies
the implementation of the Reynolds Averaged Navier-Stokes (RANS) method within the OpenFOAM en-
vironment both in the absence and presence of turbulence modelling, specifically the k − and k − ωSST
models.
One of the most complicated elements of CFD is the construction of an adequate computational grid,
particularly when complex three dimensional bodies are being studied. The OpenFOAM suite includes
the snappyHexM esh utility, which provides a simple means for creating a mesh about an externally
generated computational geometry. This utility is of great interest to DSTO as it would provide a more
time efficient means for conducting CFD simulations. snappyHexM esh was studied in tandem with the
accuracy of OpenFOAM’s solution.
The first test cases which were completed simulated the transient nature of two dimensional flow over
circular cylinders in a variety of geometrical configurations using the icoF oam solver. These cases served
the dual purposes of offering a fundamental grounding of OpenFOAM’s basic and advanced functions, as
well as providing a benchmark for testing of initial and boundary conditions to be utilised in later studies.
These simulations were validated by a qualitative comparison to published results. It was determined that
these test cases were able to faithfully reproduce fluid flow phenomena such as the Karman vortex street.
This was deemed evidence of OpenFOAM’s ability to solve the underlying physics of the flow, particularly
as this was a time dependent study, and thus a solid groundwork was laid for more complicated validations.
A challenging scenario for the high Reynolds number validation of OpenFOAM is that of the three di-
mensional flow over a sphere. This flow is characterised by both laminar and turbulent regions of the
boundary layer, with large adverse pressure gradients and separation. These simulations were completed
using the simpleF oam solver, which uses the SIMPLE algorithm to solve the RANS equations. This
averaging added an additional complexity as it requires fitting a highly time dependent flow to a time
independent, steady state solution. Simulation results were compared to the integrated flow properties
previously published for similar cases at a large range of Reynolds numbers. With varying results de-
pending on the implemented turbulence model.
The solution of the RANS equations without the use of a turbulence model produced much more accurate
results over a wider range of Reynolds numbers than was anticipated. For Reynolds numbers between 10
and 1000 it was found that coefficient of drag results were within 8% error of experimental data. This
proved to be a validation of snappHexM esh’s ability to produce a mesh compatible with a high quality
solution. Within the transition region it was seen that results began to deviate from the compared data,
however the overall trend remained faithful, particularly towards the end of the drag crisis. This is espe-
CP-AOO-123 ii
cially interesting considering that increased refinement of the mesh tended towards the actual solution.
At a Reynolds number of 106 the converged solution agreed exceptionally well with experimental results
with an error of less than 10%, with trends suggesting that higher Reynolds number simulations would
conform to similar levels of accuracy. It is postulated that this unexpected accuracy can be explained by
the numerically induced artificial diffusion due to the choice of linear upwind differencing as the discreti-
sation scheme.
The k − ωSST turbulence model was implemented with use of a wall function so that it could be solved
on the same computational grid as the k − model for direct comparison. Early expectations were that
the k − model would outperform the no-turbulence-model configuration for flows within the transition
region and beyond. While the model did not perform as well as expected in the transition region, very
accurate results (with negligible error for the coefficient of drag) were acheived post drag crisis. This was
not expected as it was thought the highly time dependent nature of the flow would be far too complex
for the steady state averaging of RANS to work effectively. The k − model was seen to perform with no
more accuracy than the k − ωSST model throughout the transition region, but performed substantially
worse and followed an incorrect trend post drag crisis. As these two models were implemented on the
same computational grid, it was recommended that the k − ωSST model should first be considered when
implementing similarly defined flow simulations.
The fundamental reasoning behind the choice of a sphere for the validation study was to confirm the
performace of OpenFOAM over a bluff body so that it may be adapated studies concerning the Jou-
bert submarine hull. Owing to this an additional investigation was performed into the applicability of
snappyHexM esh to create an adequate computational grid for this geometry. This was to serve the
additional purpose of contrasting the performance of the turbulence models on a geometry posessing
different boundary layer properties. Due to technical difficulties involving the computer model geometry
in stereolithography format, this is continuing at the presnt time.
CP-AOO-123 iii
Contents
1 Introduction 1
2 Theory of Turbulence 2
2.1 The nature of turbulence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 The Reynolds Averaged Navier-Stokes equations . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 The closure problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Turbulence models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 The Boussinesq approximation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2 Turbulent kinetic energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.3 The Standard k − model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.4 The Wilcox k − ω model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.5 The k − ωSST model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.6 Wall functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Literature Review 9
4 Software and utilities 11

4.1 OpenFOAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Solvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2 blockMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3 snappyHexMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 2D cylinder simulations 14
5.1 Single cylinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Streamwise dual cylinders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3 Offset dual cylinders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Mesh details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Flow over a sphere 19

6.1 No turbulence model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1 Mesh generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.2 Qualitative flow data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.3 Vorticity contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.4 Coefficient of Drag, CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.5 Coefficient of Pressure, CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.6 Separation angle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Turbulence models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1 Mesh generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 Turbulence parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.3 Qualitative flow data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.4 Vorticity contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.5 Coefficient of drag, CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.6 Coefficient of pressure, CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.7 Separation angle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Submarine Hull 34
7.1 Problems with Joubert bare hull meshing . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8 Conclusion 36
9 References 38
CP-AOO-123 iv
A Residual plots 40
B snappyHexMesh 42
B.1 Fundamentals and activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.2 geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
B.3 castellatedMeshControls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.3.1 Basic controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.3.2 refinementSurfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.3.3 refinementRegions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B.4 addLayersControls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.4.1 layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.4.2 Basic controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.5 Possible problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5.1 Layer addition problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5.2 ASCII and binary problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5.3 Display issues in ParaVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.6 snappyHexM esh Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C Design Diary 47
D Case directories 51
D.1 Dual offset cylinders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.1.1 0 directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.1.2 constant directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.1.3 system directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
D.2 No turbulence sphere RANS modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.2.1 0 directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.3 k − ωSST case directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
D.3.1 0 directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
CP-AOO-123 v
List of Figures
1 The Joubert submarine hull design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Different regions of Reynolds number. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Examples of three dimensional and highly rotational flows [3] [4]. . . . . . . . . . . . . . 3
4 Turbulence is a phenomenon of many scales, from atmospheric to near molecular motion
[5] [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5 Reynolds decomposition of velocity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 Physical interpretation of terms in the Reynolds stress equations [2]. . . . . . . . . . . . . 5
7 Two methods of modelling near wall effects - wall functions (left) and direct (right). [14] . 8
8 The process of castellating, removing and snapping to an irregular surface [38]. . . . . . . 13
9 snappyHexMesh steps 1, 2 and 3 (left to right) indicating increasing quality and refinement. 13
10 Final mesh of single cylinder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11 Simulated flow field magnitude of velocity (top) compared with lines of constant stream
function (bottom) [25]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12 Final mesh for the dual cylinder (streamwise) case . . . . . . . . . . . . . . . . . . . . . . 16
13 Velocity magnitude for the dual-cylinders in streamwise orientation. . . . . . . . . . . . . 16
14 Comparison of velocity field and simulated vorticity contours (top) with Singha. et al. [26]
(bottom). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15 The final mesh for dual offset cylinders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
16 Experimental dual cylinder vorticity contours with numerical vorticity overlaid [27]. . . . 18
17 Computational domain of minimum refinement for laminar cases . . . . . . . . . . . . . . 20
18 Computational domain of maximum refinement for laminar cases . . . . . . . . . . . . . . 20
19 Qualitative field properties for no turbulence model configuration at various Re. . . . . . 21
20 Comparison of vorticity for varying Reynolds number with no turbulence model. . . . . . 22
21 Comparison of CD (changing mesh refinement, no turbulence model) with experimental
data [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
22 Comparison of coefficient of pressure about sphere. . . . . . . . . . . . . . . . . . . . . . . 24
23 Wall shear stress for Re = 102 , 103 , 105 , 106 (left to right) with no turbulence model. . . . 25
24 Separation angles of simulation and comparative data. . . . . . . . . . . . . . . . . . . . . 26
25 Qualitative flow field data for k − and k − ωSST models. . . . . . . . . . . . . . . . . . 29
26 Comparison of vorticity for varying Reynolds number and turbulence model. . . . . . . . 30
27 Comparison of drag coefficient for differing models against experiment [39]. . . . . . . . . 31
28 Cp results for simulations using the k − and k − ωSST model. . . . . . . . . . . . . . . . 32
29 Shear stress for the k − and k − ωSST models. . . . . . . . . . . . . . . . . . . . . . . . 33
30 Example mesh created using snappyHexMesh (magnification of the tail region). . . . . . . 34
31 Tail section after castellating, snapping and layer addition phases (left to right). . . . . . 35
32 Velocity profile in the tail region of the Joubert bare hull. . . . . . . . . . . . . . . . . . . 35
33 Velocity residuals for k − ωSST at Re = 1 million . . . . . . . . . . . . . . . . . . . . . . 40
34 Velocity residuals for k − at Re = 1 million . . . . . . . . . . . . . . . . . . . . . . . . . 40
35 Velocity residuals for k − ωSST at Re = 300,000 . . . . . . . . . . . . . . . . . . . . . . . 41
36 Velocity residuals for k − at Re = 300,000 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
37 View of case structure of an OpenFOAM directory . . . . . . . . . . . . . . . . . . . . . . 51
List of Tables
1 Drag as a function of mesh refinement for a range of Re with no turbulence model. . . . . 23
2 Separation angles for a range of Re. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Turbulent parameters for various Reynolds numbers. . . . . . . . . . . . . . . . . . . . . . 28
4 Comparison of initial conditions and CD for k-ω model. . . . . . . . . . . . . . . . . . . . 28
5 Drag as a function of mesh refinement for a range of Re and turbulence model. . . . . . . 31
6 Separation angles for a range of Re. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Drag as a function of mesh refinement for a range of Re. . . . . . . . . . . . . . . . . . . . 35
CP-AOO-123 vi
1 Introduction
Fluid mechanics is an area of research with far reaching implications for a multitude of industries and
sectors. As such there is an enormous motivation to push forward into new technologies and new method-
ologies for assessing fluid motion and, in particular, its effect on objects and bodies. Knowledge of these
interactions and the phenomena that occur can have implications in scientific research from fields as
diverse as air-sea interactions through to biological fluid motion within the body. Fluid dynamics is also
of great importance to the technical engineering design of mechanical systems.
Historically fluid dynamics research has leant heavily on experimental modelling and scale testing. This
empirical approach stems from the innate complexity of fluid mechanics theory and the difficulty of
adapting analytical solutions to anything other than simple geometries and flow types. In recent times,
one core area of fluids research - which has coupled its growth to that of the emergence of new computing
technologies - is Computational Fluid Dynamics (CFD). CFD is a field of fluid dynamics study which
investigates the use of numerical schemes and algorithms for solving the governing equations of fluid
dynamics. This allows solutions to be formed and data to be collected for many flow properties over very
complex systems that would otherwise be impossible.
Due to the iterative nature of the numerical solutions obtained, CFD studies are becoming increasingly
useful as the processing power of computers and the capabilities of software develop. One of the limiting
factors now facing CFD users is the cost of CFD software packages. One solution to this problem is the
use of freely available open-source software such as OpenFOAM. Open-source software, however, must
first be tested and proven to give accurate results. By comparing simulations from OpenFOAM with
previous simulations and laboratory experimental results, this project aims to validate the OpenFOAM
suite for particular flow scenarios.
The Defence Science and Technology Organisation (DSTO) places great importance in fluids research,
as many defence systems that they research, design and implement - such as aircraft and submarines -
draw their operational capacity from interactions with fluids. Design parameters such as thrust, lift and
drag all have a solid basis in the theory of fluid dynamics and thus a detailed understanding of these
interactions can lead to breakthroughs in not only efficiency but other core areas for defence including
noise mitigation through acoustical analysis.
Of particular relevence to this report is to determine if the OpenFOAM suite can be successfully imple-
mented to derive the integrated flow properties about the Joubert submarine hull design (Fig.1). This
problem is approached first by the consideration of more basic two and three dimensional shapes as an
early proof of validity. In addition, several different turbulence models will be used to simulate the flow
and the results of each will be used to provide an indication as to the applicability of each model to the
particular flow scenario.
Figure 1: The Joubert submarine hull design.
CP-AOO-123 1
2 Theory of Turbulence
An exact set of equations describing the velocity and pressure of a fluid in both time and space arise
from applying Newton’s second law to the motion of a fluid element. These equations are known as the
Navier-Stokes (N-S) and continuity equations.

∂ui ∂ui ∂ P ∂ ∂ui
+ uj =− + ν (1)
∂t ∂xj ∂xi ρ ∂xj ∂xj
∂ρui
=0 (2)
∂xi
Due to the non-linearity and complexity of the Navier-Stokes equations most CFD applications make
simplifications to the original formulation. Turbulent flows are particularly difficult to analyse and as a
result there have been many turbulence models introduced in an attempt to simplify and thus yield a
realisable solution.
Turbulence is a particularly important aspect of fluid motion as it affects many properties of the entire
flow field. Integral properties such as coefficients of drag and lift are heavily dependent on turbulence
as it has a role in determining both the skin friction and pressure drag on a body. Turbulence also has
the effect of increasing the total diffusivity of a flow making it an important aspect in many diffusion
problems.
2.1 The nature of turbulence

Turbulence is not a property of a particular fluid, but is instead a property of the flow conditions [1].
Fluids are governed by two separate yet constantly competing forces:
• Viscous forces, which arise from the viscosity of the fluid. This force describes the resistance of a
fluid to deformation under shear stresses.
• Inertial forces, due to the fluid resisting a change in its current state of motion.
The balance of these two fundamentally significant forces defines the nature of a flow. The ratio of the
viscous forces to the inertial forces is described by the important non-dimensional parameter Re, which
is known as the Reynolds number, UD
Re = (3)
ν
where U is a mean velocity, D is a characteristic length scale and ν is the viscosity of the fluid.
In scenarios where the Reynolds number is low, the viscous forces dominate resulting in a flow which is
smooth in nature. This flow condition is termed laminar flow and can be thought of as adjacent fluid
layers sliding past one another. Laminar flows are very ordered with little spanwise movement or eddying
motion being present.
As the Reynolds number rises the inertia of the fluid increases until the viscous forces are no longer strong
enough to maintain the fluid in a laminar condition. At this point irregular and unpredictable eddying
motion is interspersed with periods of laminar flow. This type of fluid flow is known as transition and is
an unstable scenario occuring before full turbulence (Fig.2).
Figure 2: Different regions of Reynolds number.
CP-AOO-123 2
As the Reynolds number continues to increase the fluid becomes fully turbulent. The complexity of
turbulence is such that there is no precise definition within the field of fluid dynamics, nor does there
exist any general theory of turbulence. Instead, turbulence is characterised by a number of observable
properties [2]:
• Irregular flow properties in both space and time - velocity and pressure fields fluctuate about mean
values in a seemingly random nature.
• Highly rotational and three dimensional flows (Fig.3).
• High diffusivity due to eddying motion.

• A large range of scales - eddies within a turbulent flow can have a continuous range of scale ranging
over many orders of magnitude (Fig.4).
• Larger eddies decay and their kinetic energy is transferred from larger to smaller eddies until the
smallest eddies dissipate into heat due to molecular viscosity. Thus turbulence decays with time
unless supplied with external energy.
Figure 3: Examples of three dimensional and highly rotational flows [3] [4].
Figure 4: Turbulence is a phenomenon of many scales, from atmospheric to near molecular motion [5]
[6].
Despite the inherent complexity of turbulence and the non-linearity of the Navier-Stokes equations the
importance of this flow regime has pushed engineers, physicists and mathematicians to continue to at-
tempt to solve the problem of turbulence by introducing mathematical models to describe this range of
physical phenomena.
CP-AOO-123 3
2.2 The Reynolds Averaged Navier-Stokes equations
Figure 5: Reynolds decomposition of velocity.
One of the most prominent and widely known approaches to further understand turbulence was intro-
duced by Osborne Reynolds. Understanding the unsteady and random nature of turbulence, Reynolds
decided upon a statistical approach to studying the Navier-Stokes equations. Reynolds proposed that
the properties of a turbulent flow could be described by the sum of a mean and fluctuating component:
ui (x, t) = Ui (x) + u0i (x, t) (4)

0
where u (x, t) is the random fluctuating component of velocity due to turbulence and Ui (x) is defined as
a time independent average of the velocity ui (x, t), given by:
Z t+T
1
Ui (x) = lim ui (x, t)dt (5)
T →∞ T t
By substituting these averaged terms into the Navier-Stokes and continuity of mass equations (Eq.1,
Eq.2), Reynolds reached the resulting equations

∂Ui ∂ P ∂ ∂Ui
Uj = − + ν − u0i u0j (6)
∂xj ∂xi ρ ∂xj ∂xj
∂Ui
= 0 (7)
∂xi
Equation (7) is termed the Reynolds Averaged Navier-Stokes (RANS) equation. The RANS equation is
identical to the original N-S
equations
except that the total velocity is replaced by the mean velocity and
0 0
there is an additional term −uj ui , which arises due to the non-linearity of the N-S equations. This
term is known as the Reynolds-stress tensor [7]
τij = −u0i u0j (8)

and describes a time averaged rate of momentum transfer due to turbulence. As stated by Wilcox [1]:
“Herein lies the fundamental problem of turbulence. In order to compute all mean-flow
properties of the turbulent flow under consideration, we need a prescription for computing
u0i u0j ”.
At present there is no general prescription for the Reynolds-stress tensor [8]. Using very accurate anemom-
etry techniques experimentalists are able to measure this quantitatively, however such a measurement
provides the Reynolds stress only for a particular flow scenario at a given location. While this information
is useful in helping to validate given assumptions about the Reynolds stress, it does not aid in further
deriving a general description for τij . Despite the fact that there is no definite description known for τij
engineers and scientists must be able to utilise some description of turbulence in order to move forward
with design and analysis. This is the role of turbulence modelling, which has its basis in modelling the
Reynolds stress tensor.
CP-AOO-123 4
2.3 The closure problem
The Reynolds-stress tensor is a symmetric tensor and thus has six unknown independent components.
Thus, by performing a Reynolds-averaging six further unknown quantities have been added to the four
previous unknown variables (pressure and the three velocity components) for a grand total of ten un-
knowns. As by deriving RANS there have been no new equations introduced this leaves only the four
original equations (continuity and the three separate momentum conservation equations). Thus the sys-
tem to be solved is not yet closed. There is therefore a closure problem of turbulence: either to find more
equations to solve for these unknowns or to determine suitable models to describe them [9] [2].
To add rigour to the analysis, one approach is to determine further exact equations by taking moments
about the N-S equations. This approach gives an exact equation for the Reynolds stresses [1]:

∂τij ∂τij ∂U j ∂Ui ∂ ∂τij
+ Uk = −τik − τjk + ij − Πij + ν + Cijk (9)
∂t ∂x ∂xk ∂xk |{z} |{z} ∂xk ∂xk
|{z} | {z k} | {z }
(d) (e)
| {z }
(a) (b) (c) (f )
Whilst this equation is complicated, it can be broken down into more manageable terms which can be
interpreted physically as [2]:
(a) Time rate of change of the Reynolds stress tensor
(b) Convection term - transport of stress due to convection
(c) Turbulent production term - turbulence produced by velocity gradients
∂u0 ∂u0
(d) Dissipation rate: ij = 2ν ∂xki ∂xkj - transfer of mechanical energy into heat at the small scales of
turbulence
∂u0
0
0
∂u
(e) Pressure-strain correlation term: Πij = pρ ∂xji + ∂xji - promotes isotropy of the turbulence
(f ) Total diffusion: where ρCijk = ρu0i u0j u0k + p0 u0i δjk + p0 u0j δik - due to molecular and turbulent effects
Figure 6: Physical interpretation of terms in the Reynolds stress equations [2].
Whilst this equation for τij is exact, it is dependent upon further terms which are also unknown.
CP-AOO-123 5
2.4 Turbulence models
There are various types of RANS turbulence models with a large range of complexity, from relatively
simple algebraic relationships to multi-equation models. Simpler models normally have coefficients which
are very finely tuned for a particular application. With increased complexity these models become
applicable to a greater number of problems and are arguably more accurate for a larger range of flow
scenarios. For the purposes of this report the focus will be on the most commonly implemented models
in industry usage - the k − and k − ωSST models.
2.4.1 The Boussinesq approximation

Before commencing with the description of these models it is useful to explain some of the assumptions
which these models share. One assumption is based upon the 1877 work completed by Boussinesq who
postulated that the momentum transfer due to small scale turbulent eddies can be modelled by using
an eddy-viscosity, νT [7]. This assumption was based upon the analogy of momentum transfer through
molecular motion in a gas. This results in the statement that the Reynolds stress tensor is proportional
∗
to the traceless mean strain rate tensor, Sij and can be written as [10]:
∗ 2
τij = 2µT Sij − ρkδij (10)
3
The eddy-viscosity is often computed in terms of a length scale, known as the mixing length scale. Us-
ing this approximation the length scale used in computing the eddy-viscosity is assumed to be analagous
to the mean free path of a gas. The resulting turbulent length scale is termed the mixing length scale, lmix .
While the Boussinesq approximation seems physically acceptable, it is not generally a valid assumption.
This is particularly the case for complex flows with strong curvatures or strongly accelerating/decelerating
flows. Since two-equation models are based upon the Boussinesq assumption they have inherent problems
in calculating flows with rotation or separation [2].
2.4.2 Turbulent kinetic energy

Turbulent kinetic energy is a measure of the energy contained in a flow due to the random velocity
fluctuations and is defined as:
1 0 0 1 02
k= ui ui = u + v 02 + w02 (11)
2 2
It can be seen that the turbulent kinetic energy can be obtained by taking the trace of the Reynolds
stress tensor
τij = −u0i u0i = −2k (12)

and thus by substitution into (Eq.9) an exact equation can be obtained for the turbulent kinetic energy,
which is used extensively in many two-equation turbulence models [1].

∂k ∂k ∂U i ∂ ∂k 1 0 0 0 1 0 0
+ Uj = τij −+ ν − ui ui uj − p uj (13)
∂t ∂xj ∂xj ∂xj ∂xj 2 ρ
Whilst this equation is exact, the dissipation term () is unknown. A model for the turbulent dissipation
is the basis of the second equation in the two equation models which are utilised later in this report.
CP-AOO-123 6
2.4.3 The Standard k − model
The Standard k − turbulence model has historically been the most popular two-equation RANS tur-
bulence model [11]. The k − model solves the exact turbulent kinetic energy equation (Eq.13) and the
rate of turbulent dissipation modelled by
2

∂ ∂ ∂Ui ∂ ∂
+ Uj = C1 τij − C2 + (ν + νT /σ ) (14)
∂t ∂xj k xj k xj ∂xj
where the kinematic eddy viscosity is modelled by
νT = Cµ k 2 / (15)
and the closure coefficients are given by [1]
C1 = 1.44, C2 = 1.92, Cµ = 0.09, σk = 1.0, and σ = 1.3 (16)
2.4.4 The Wilcox k − ω model

The k − ω model is also a two-equation turbulence model which solves the exact turbulent kinetic energy
equation (Eq.13). Rather than determine , the k − ω model uses a second equation to model ω, the
specific dissipation rate. This equation is given by [12]:

∂ω ∂ω ω ∂Ui ∂ ∂ω
+ Uj = α τij − βω 2 + (ν + σνT ) (17)
∂t ∂xj k ∂xj ∂xj ∂xj
where the kinematic eddy viscosity is defined as
k
νT = (18)
ω
and the closure coefficients are given by [1]
α = 5/9, β = 3/40 σ = 1/2 (19)
2.4.5 The k − ωSST model

The k − ω Shear Stress Transport (SST ) model is a hybrid two equation eddy viscosity model which aims
to gain the benefits of both the k − ω and k − models. The formulation utilises the k − ω model within
the inner regions of the boundary layer close to the walls. In the outer free stream regions the k − model
is utilised as it is known to be less sensitive to inlet turbulent properties [13]. This combination has made
the k − ωSST model popular for adverse pressure gradients and separated flows which are notoriously
difficult scenarios in which to gain accurate results.
CP-AOO-123 7
2.4.6 Wall functions
The boundary layer region is arguably one of the most important flow phenomenons to calculate correctly
as it defines the nature of the remaining flow field. Unfortunately, due to the large changes in velocity
gradient throughout this region a similarly large amount of detailed information is required in order to be
able to approximate the boundary layer effects with any accuracy. There are two common methodologies
in treating the region of the boundary layer. The first is to decrease the size of the cells near the wall
so as to capture the increasingly steep velocity gradient and adequately define the boundary layer (Fig.7
right). This method has an advantage in that it attempts to model the actual physics of the problem,
however the increase in computational requirements can make this inefficient for some flow typesand may
introduce convergence and numerical stability concerns.
Figure 7: Two methods of modelling near wall effects - wall functions (left) and direct (right). [14]
The second method to address the boundary layer is to implement a mathematical model which ap-
proximates the near wall as a continuation of Prandtl’s law of the wall [14]. This method estimates the
gradient of velocity within the first grid cell closest to the wall (Fig.7 left). In flows where the gradients
are very steep, wall functions perform less well than an equivalent simulation using a finer mesh (as will
be shown). However, wall functions are often preferred as they increase the efficiency of computation
by allowing the minimum grid size of the mesh to be increased whilst still maintaining a fairly accurate
approximation of the boundary layer region. This is particularly true for large Reynolds numbers as the
required grid size using traditional grid refinement methods decreases rapidly with increasing velocity
and hence the computational load can become unfeasable.
CP-AOO-123 8
3 Literature Review
Both commercial and open source software require validation before they may attain acceptance by in-
dustry and the research community. Perfomance of the OpenFOAM software package has previously
been evaluated in a variety of different physical applications, including turbulent flow past aerofoils [15],
boiling flows [16], supersonic flow in a mixed compression intake [17], viscoelastic two-phase flows [18],
noise simulation of tandem cylinders [19], simulation of flow in the Holleforsen tube [20], gas-solid flu-
idized bed hydrodynamics [21] and compressible flows in high voltage circuit breaker diffusers [22]. To
date OpenFOAM has performed well under these test conditions giving CFD users confidence that it is
indeed accurate. In order to validate OpenFOAM for the purposes required by DSTO, a collection of
comparable data was collected for a range of geometries.
The areas of OpenFOAM that DSTO are interested in validating have less research performed than the
aforementioned analyses. DSTO have a strong interest in high Reynolds flows over bluff bodies such
as submarines and an investigation into very unsteady turbulent flows over such bodies was requested.
For this application, comparison with previous works regarding cylinder and sphere flow was required.
Detailed below is a range of experimental results, steady RANS and transient simulations. These papers
lay the groundwork for determining the accuracy of OpenFOAM and the RANS solver simpleFoam.
Cylinders
Significant work has been completed on various aspects of flow about a circular cylinder. This is a popular
flow configuration due to its relatively simple implementation yet surprisingly complicated resulting flow
structures. The case of a single cylinder in cross flow is often used as a baseline simulation for many
further applications, and thus has been a feature of many previous investigations. A major motivation
for the implementation of flow over a cylinder in this report is the large amount of experimntal data
available. For example, a report outlining the visual aspects of the wakes behind cylinders at a range of
Reynolds numbers and under varying flow parameters, entitled “Circular cylinder wake configurations:
A flow visualization survey”, was completed by M. Coutanceau and J. Defaye [23]. This paper gives
excellent photographic reviews of various wake properties which are useful in comparing the results of
numerical simulations.
“Experimental determination of the main features of the viscous ow in the wake of a circular cylinder in
uniform translation”, completed by M.Coutanceau and R.Bouard [24], provides an overview of flow fields
including velocity magnitudes and wake dimensions. The study “A Numerical investigation of unsteady
flow past a circular cylinder using 2-D finite volume method ” by Md. Mahbubar Rahman, Md. Mashud
Karim and Md. Abdul Alim [25], gives a comprehensive overview of both quantitative and qualitative
data for single cylinder flows at Re = 1000 and Re = 3900, which agree well with experimental data.
More complicated cylinder studies arise when considering multiple objects at various positions relative
to one another. For the purposes of streamwise cylinder comparison the numerical modelling work per-
formed in “High resolution numerical simulation of low Reynold’s number incompressible flow about two
cylinders in tandem” by S.Singha [26] at a Reynolds number of Re = 150 provide qualitative data for
review. By repeating the centerline spacings of the cylinders as simulated by Singha a direct visual
comparison could be made of the vortical structures behind the two streamwise cylinders by creating
vorticity contours in the same manner.
CP-AOO-123 9
A review of the work concerning cylinders positioned other than on a single streamwise axis “Two circular
cylinders in cross-flow: A review ” was completed by D.Sumner [27]. Sumner completes a comprehen-
sive review of numerical results and contrasts them with classic flow visualisation techniques such as
dye-release and Particle Image Velocimetry. Various different wake scenarios occur depending on the
Reynolds number and relative orientation of the two cylinders. Particular results compared to within
this report are those for offset cylinders in a flow of Re = 880 at an angle of 40◦ and distance of 3 cylinder
diameters.
Spheres
Whilst there are many publications discussing RANS simulations and modelling over various surface ge-
ometries there are few cases concerning flow over spheres at high Reynolds numbers. This is mainly due
to the complexity which a spherical geometry poses by containing both a laminar and turbulent boundary
layer for most Reynolds numbers, as well as having a large adverse pressure gradient. For this reason
much of the compared literature are large-eddy and direct numerical simulation results. As the RANS
simulations which were conducted throughout this report give only mean and integrated data there is
no way of comparing to the transient and fluctuating phenomena which are documented and quantified
in these papers [?] [29]. However, as mean results can be computed from a large-eddy simulation result,
these mean values are utilised for comparison.
DSTO has provided a document containing an analysis of flow over a sphere for a range of high Reynolds
numbers using the commercial code Fluent, “Simulation of Flow Past a Sphere Using the Fluent Code”
by D.A. Jones and D.B. Clarke [30]. This report contains results including the average coefficient of drag,
separation angle and velocity magnitude contours and is referred to throughout this study. Comparisons
are made for high Reynolds number since this is the primary focus.
“Experiments of the flow past spheres at very high Reynolds numbers” by E.Achenbach [31] is an experi-
mental investigation of many aspects of sphere flow including drag and pressure coefficients as well as wall
shear stresses. The report outlines data covering a range of Reynolds numbers from 1×104 ≤ Re ≤ 1×106 .
A numerical investigation with significant scope across a wide range of Reynolds numbers “LES and
DES Investigations of Turbulent Flow Over a Sphere” was completed by Constantinescu and Squires [28]
[29]. This paper addresses a range of Reynolds numbers which allows comparison of average CD , wake
region velocity profiles, separation angles and recirculation lengths. While this document also contains
information regarding energy spectral densities and Strouhal numbers, the averaged results obtained in
this report are not compatible with this kind of analysis.
Submarine hull
For quantitative comparisons over the Joubert hull research performed by DSTO was analysed. This
research “RANS simulations using OpenFOAM software” by D.A. Jones, B. Anderson, M. Chapuis, C.
Fureby, M. Liefvendah, D. Norrison, C. Troeng and R. Widjaja [32] is an internal document in drafting
stages at DSTO in conjunction with the Swedish Defence Research Agency. It contains a range of drag
coefficients using many differencing schemes for the convective divergence term, CP and Cf curves over
submarine centreline and comparisons with previous experimental work performed by DSTO.
DSTO have previously conducted experiments on small scale models of the Joubert hull at increased flow
velocities to maintain appropriate Reynolds numbers. A variety of quantities were sampled including CP ,
velocity profiles normal to hull surface at a range of hull locations and Cf . These experimental results
confirm the accuracy of DSTO’s simulations [32] as good agreement was achieved. The simulations were
performed using a structured mesh and the ability to mesh the Joubert hull with snappyHexMesh is yet
to be investigated though it is of significant interest.
CP-AOO-123 10
4 Software and utilities
4.1 OpenFOAM
OpenFOAM is a free, open source CFD software package that is gaining wide acceptance in both aca-
demic institutions and industry bodies [33]. This uptake stems both from its free-to-use nature and
adaptable programming capabilities - allowing the user to tailor simulations directly to specific problems
being studied. OpenFOAM is not a conventional program in the sense that it is a collection of solvers
for analysing different flow conditions and other physical problems. In addition, OpenFOAM possesses
a range of mesh creation and conversion utilities which maximise its effectiveness and ease of integration
with existing models. OpenFOAM’s post-processing interface with the open source software ParaView
provides a convenient, detailed suite for the analysis and interpretation of data [34].
It would be remiss not to address the user-interface hurdles that this code presents. The lack of a
graphical user interface (GUI) that typically accompanies such software presents a learning curve that is
significantly steeper than a commercial package such as Fluent or Star-CCM+, which have user-friendly
GUIs. In addition to this, the highly customisable nature of OpenFOAM’s coding makes a detailed
knowledge of all the parameters involved in a particular problem (such as boundary conditions and inital
values) necessary. As these values must be manually entered, obtaining a solution in OpenFOAM - even
an incorrect one - is more labour intensive than a commercial software package that provides default
values from which a user can then begin to investigate a particular problem.
4.1.1 Solvers
While the OpenFOAM package is known to be a collection of numerical solvers, the specific codes imple-
mented in the two major sections of this report are:
• icoF oam - the standard laminar, incompressible solver
• simpleF oam - a steady state solver of the RANS equations
The icoF oam solver uses the PISO algorithm to solve the incompressible, laminar Navier-Stokes equa-
tions. This gives a time dependent, transient solution and as such requires specification of both initial
conditions and boundary conditions. From the OpenFOAM community page [35], the procedure which
icoF oam follows can be summarised as:
1. Set the boundary conditions.

2. Solve the discretized momentum equation to compute an intermediate velocity field.
3. Compute the mass fluxes at the cells faces.
4. Solve the pressure equation.

5. Correct the mass fluxes at the cell faces.
6. Correct the velocities on the basis of the new pressure field.
7. Update the boundary conditions.
8. Repeat from 3 for the prescribed number of times.

9. Increase the time step and repeat from 1.
The simpleF oam solver makes use of the SIMPLE algorithm to produce a steady state solution to the
RANS equations previously mentioned. This gives a time averaged solution which iterates to a specified
convergence tolerance. From the OpenFOAM community page [36], the SIMPLE algorithm follows the
procedure :
CP-AOO-123 11
1. Set the boundary conditions.
2. Solve the discretized momentum equation to compute the intermediate velocity field.
3. Compute the mass fluxes at the cells faces.
4. Solve the pressure equation and apply under-relaxation.
5. Correct the mass fluxes at the cell faces.

6. Correct the velocities on the basis of the new pressure field.
7. Update the boundary conditions.
8. Repeat till convergence.
4.1.2 blockMesh
blockM esh is a meshing utility provided to create structured meshes for use within the OpenFOAM
environment [37]. It is capable of producing parametric meshes with grading and curved edges which are
defined by one or more hexahedral blocks that can be bounded by straight lines, arcs or splines with each
block having eight vertices.
The points are defined by listing vertices in terms of their x, y and z locations:
vertices
(
(x1 y1 z1)
(x2 y2 z2)
. . .
(xn yn zn)
);
Individual blocks, which are a collection of cells, are defined by linking together eight vertices to make a
hex block:
blocks
(
hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (a b c)
);
Where (0 1 2 3 4 5 6 7) define the geometry. (0 1) defines the local x-axis (x1) direction, (1 2) defines
the yl direction and (0 1 2 3) defines the plane zl = 0. (10 10 10) defines the number of nodes in x1,
y1 and z1 respectively and (a b c) defines the grading in xl, yl and zl respectively. A larger number for
simpleGrading makes the final cell in the specified axis larger than the first cell on the same axis.
Boundaries are defined by creating faces from previously defined vertices, using the right hand rule to
ensure surface normals point out of the computational domain. For example an inlet may be defined as:
inlet
{ type patch;
faces
(
(0 4 7 3)
);
};
This structured meshing approach was used for the 2D cylinders and to create the background mesh for
snappyHexMesh utility (Sec.4.1.3). A complete case directory for a cylinder example can be found in the
appendix (App.D.1.2).
CP-AOO-123 12
4.1.3 snappyHexMesh
In the early stages of this project and in many commercial applications structured meshes are used to
define the solution domain in a simulation. This approach is acceptable for projects featuring simple
geometries, however it becomes much more difficult and sometimes impossible to define more complex
geometries. Unstructured meshes are therefore of great interest to professional modellers and academic
institutions for their practical applications.
OpenFOAM contains an unstructured mesh generation utility titled snappyHexMesh which generates
three dimensional meshes containing hexahedra and split hexahedra from surface geometries in .STL
or .OBJ format. This meshing tool works by iteratively refining from a background mesh, which can
easily be created using blockmesh, removing any cells which are within the geometry (as specified in the
snappyHexMeshDict file) and morphing the resulant orthogonal cells to the surface geometry in a process
called snapping. This process is best explained visually (Fig.8).
Figure 8: The process of castellating, removing and snapping to an irregular surface [38].
There is an optional layering step which shrinks back the refined, snapped mesh and inserts hexahedral
cells of a specified width in order to increase the quality of the mesh. This quality increase comes from
the snapping phase which can create highly skewed cells when applied to non-ideal geometries. This is an
inevitable tradeoff however since the refinement and removal process creates only orthogonal cells which
conform poorly to a curved geometry. This process was applied to the sphere for use in later simulations
(Sec.6). A more detailed explanation for snappyHexM esh, including a step-by-step explanation of the
various coding options (App.B).
The iterative process described will produce a basic mesh as shown (Fig.9) which highlights the three
stages of mesh creation in a real application. It should be noted that mesh irregularities are not an
indication of poor mesh quality but are artifacts produced by ParaView’s inability to render tetrahedra.
It can be seen in later discussion (Section 6.1) that this method of creating a three dimensional mesh
does indeed create appropriate geometries for simulation.
Figure 9: snappyHexMesh steps 1, 2 and 3 (left to right) indicating increasing quality and refinement.
CP-AOO-123 13
5 2D cylinder simulations
As was previously mentioned, the nature of OpenFOAM’s command line based interface leads to a steep
learning curve, more so than with traditional commercial software packages. On top of the demands of the
technical CFD knowledge, an extensive background in linux systems and some knowledge of C++ coding
is required to facilitate a full understanding of the operation of OpenFOAM. In an effort to overcome
this obstacle (while still keeping in mind the eventual intention of validating the OpenFOAM package for
high Reynolds numbers) a series test cases escalating in difficulty were completed. These cases permit the
learning of OpenFOAM’s basic and advanced functions, in addition to providing a basis for qualitative
comparison to published data - thus contributing to the goal of validation.
The first set of test cases involved simulating unsteady, incompressible, laminar flow using the icoFoam
solver. A cylindrical geometry was chosen in a variety of alignments due to the significant quantity of
literature for comparison and the relative simplicity of a two dimensional simulation. The results of
these simulations were then compared to qualitative results from literature to assess the accuracy of the
solutions.
5.1 Single cylinder

The first test scenario was that of a single cylinder in streamwise flow at Re = 1000. It is known that the
existence of the Karman vortex street is heavily dependent on accurate numerical reproduction of the
boundary layer, which in turn is dependent on the boundary/inlet/outlet conditions. By qualitatively
matching this data confidence can be gained in the conditions implemented and in their use continuing
with more complicated problems.
Meshes were created using the blockM esh utility, which was outlined in section 4. This is a complicated
procedure and defining the domain and refinement levels for minimum cell distortion was a challenging
optimisation process. The mesh which produced the best result in terms of minimising cell distortion
(Fig.10) was generated using a curved inlet surface which also offered good near-cylinder refinement and
improvements in the accuracy of the solution.
Figure 10: Final mesh of single cylinder.
CP-AOO-123 14
The structured mesh contained 38 vertices based on 11 hex blocks for a total of 44,000 cells and 87,300
internal faces. The left (inlet), upper and lower faces were specified using an inflow condition for velocity,
whereas the right wall (outlet) was defined using a zero gradient condition which assists in dissipating
any potential back-flow which can lead to numeric instability. The simulation was run for 150 iterations,
sufficient to obtain a solution with several periods of shedding.
5.1.1 Results
The single cylinder results (Fig.11) display the magnitude of the velocity across the computational domain.
The quality of the shedding obtained from the simulation was greater than expected using the icoF oam
laminar solver, particularly given what is a relatively coarse mesh by the standards set in previous studies.
The mesh refinement and the timesteps chosen ensured that the solution closely approximated the physical
motions of fluid under the specified conditions. It is evident from the comparison with literature (Fig.11)
that the result is not entirely accurate though this qualitative agreement with overall shape and the
presence of shedding is an indicator of successful implementation. Given the computationally intensive
nature of the icoF oam solver it was deemed unecessary to further refine the mesh in search of better
agreement with published literature.
Figure 11: Simulated flow field magnitude of velocity (top) compared with lines of constant stream
function (bottom) [25].
5.2 Streamwise dual cylinders

A test scenario of increased complexity was chosen in order to gain more experience using the blockMesh
utility, as well as to further investigate boundary and initial conditions. Dual cylinders positioned in a
streamwise direction was a logical progression from the single cylinder case and comparable qualitative
data was available for Re = 150.
blockMesh was again utilised in the construction of a structured mesh for this dual cylinder mesh. The
final mesh (Fig.12) contained 63 vertices, 21 hex blocks 53,600 cells and 214,900 internal faces. The
simulation used the same initial and boundary conditions as the single cylinder case (Sec 5.1). However,
due to the lower Reynolds number 2000 iterations were required in order to allow the vortex street to
fully form. Due to the larger computational requirement of this flow condition a decomposition of the
computational domain was implemeneted for multi-core processing. This was completed using an in-built
OpenFOAM utility decomposePar. Decomposition of this simulation case served as an introduction into
the required time for simulations to complete and was a useful precursor to implementing simulations on
the high performance computer used later for more advanced 3D simulations.
CP-AOO-123 15
Figure 12: Final mesh for the dual cylinder (streamwise) case
The structure of the dual streamwise mesh (Fig.12) demonstrates the level of cell refinement required
for agreement with results obtained from literature. Adequate resolution of the boundary layer for
qualitatively similar solutions was achieved with a cell density of 5.
5.2.1 Results
The dual streamwise cylinder simulation was performed with the intention of observing the effect of
dual-cylinder proximity on the creation of vortices in the street. It was anticipated that a close alignment
would result in a single street of joined vorticies due to the second cylinder being positioned directly in
the wake of the upstream cylinder. This was clearly observed in the simulated results (Fig.13).
Figure 13: Velocity magnitude for the dual-cylinders in streamwise orientation.
CP-AOO-123 16
The magnitude of vorticity (Fig.14) was computed for comparison with simulations conducted by S.Singha
[26]. It is clear that the contours of vorticity magnitude are in excellent agreement. This result gives
greater confidence that the unsteady solver icoFoam correctly solves fluctuating data at Re = 150,
suggesting that a steady RANS investigation may be able to achieve agreeable results. In additon it also
provides great confidence in the selected boundary and initial conditions.
Figure 14: Comparison of velocity field and simulated vorticity contours (top) with Singha. et al. [26]
(bottom).
5.3 Offset dual cylinders

5.3.1 Mesh details
To construct the dual cylinder offset mesh (Fig.15), blockMesh was again used. The angle of the second
cylinder from the horizontal is 40◦ , and the distance between their centrelines is three cylinder diameters.
The simulation was run with at Re = 880 in order to match comparable experimental data compiled by
D.Sumner [27]. The same initial and boundary conditions were utilised in the offset cylinder case as were
used in the streamwise positioned cylinders (Sec. 5.2), although the complexity of the mesh required
multiple faces to be asigned inlet and outlet conditions. The final mesh contains 87 vertices, 31 hex
blocks 68,200 cells and 135,720 internal faces.
CP-AOO-123 17
Figure 15: The final mesh for dual offset cylinders.
5.3.2 Results
A comparison of vorticity contours with experimental data (Fig.16) again shows good agreement. It
should be noted that the experimental results have been produced using smoke streaklines which show a
history of the flow whereas the vorticity contours shown are an instantaneous solution. This comparison
still holds quite well in the region close to the downstream side of the cylinder compared to experimental
results from Sumner [27].
Figure 16: Experimental dual cylinder vorticity contours with numerical vorticity overlaid [27].
CP-AOO-123 18
6 Flow over a sphere
There are several reasons for choosing to simulate flow over a sphere to assess the accuracy of results
and hence the validity of the OpenFOAM suite. Primarily, there is a significant amount of both experi-
mental and computational data such as coefficient of drag, coefficient of pressure, separation angles and
recirculation lengths. This multitude of data allows for a variety of comparisons to be made for various
flow statistics thus determining the accuracy of the simulations resulting from changes in the simulation
parameters.
In addition, a sphere is a bluff body, which is characterised by a separated flow region making it common
to many industry applications. Whilst it is well known that many RANS turbulence models do not
faithfully describe separated flows, the cost effectiveness of RANS leads many researchers to continue
using these models for bluff bodies. In order to be able to implement such models for these types of flows,
it is useful to know which models are applicable under which flow conditions and with what accuracy
they can be applied. Simulating flow over a sphere for a range of Reynolds numbers, using a number of
different turbulence models, creates an element of rigour that can be added for future simulations under
similar flow conditions using OpenFOAM.
This flow type is solved within the OpenFOAM environment by utilising simpleFoam. simpleF oam is a
steady state incompressible solver which can implement a number of different RANS turbulence models.
To cover a broad range of OpenFOAM’s capabilities with simpleF oam three different turbulence models
will be implemented. k − , k − ωSST and a “laminar” model which deactivates all turbulence modelling.
Simulations were run until the solution was deemed converged according to velocity residuals. These were
found to be the most challenging to converge and are included (App.A) for both turbulence models at
high Reynolds numbers. Lower Reynolds residuals are not included as the exhibit similar characteristics
but converge faster.
6.1 No turbulence model

Before comparative analysis of the OpenFOAM implementation of turbulence models can be made, a
base-line case must be created in order to gauge the scale of any changes brought on from turbulence
modelling. This no-turbulence-model scenario will be established by setting the eddy viscosity to zero
throughout the flow field. This is acheived mathematically by forcing the Reynolds stress tensor to zero:
τij = 0
The implementation of this control case within the OpenFOAM environment is achieved by setting the
turbulence model option to a ’dummy’ function named laminar, which effectively deactivates any mod-
elling and achieves the above mathematical condition.
It was expected from both previous experience with OpenFOAM and existing literature that there will be
good agreement with experimental results in the laminar region of sphere flow through to approximately
Re = 100. Agreement with experimental results in this low speed regime would demonstrate some level
of accuracy for OpenFOAM as a solver, ensuring that the numerical scheme is accurately reproducing the
physics inherent in the problem. In addition, this low Reynolds regime would serve to provide an early
verification of the snappyHexM esh utility, and thus allow for the implementation of turbulence models
with a degree of confidence. It was assumed that the results at higher Reynolds numbers, especially
in the transition region, would be significantly aberrant due to the scale of turbulent effects and flow
phenomena such as the drag crisis.
As expected the low Reynolds number results for the no-turbulence-model cases demonstated good agree-
ment with results obtained from literature, as was expected. However, there was a surprising level of
accuracy obtained in the transitional flow region from Re = 103 to Re= 106 . As further results will
show, this agreement was increased as the mesh was further refined. Thus, the no-turbulence-model con-
figuration handles some flow properties much better than others which can give deceptive or misleading
results for other properties. This is most likely due to a cancellation of errors aided by the choice of linear
upwind differencing as a numerical solution scheme.
CP-AOO-123 19
6.1.1 Mesh generation
A three dimensional sphere can be accurately meshed for high resolution simulations with relative ease
using the mesh creation tool discussed previously (Section 4.1.3). The primary features of the mesh
were ensuring the near wall refinement was appropriate to define the boundary layer and thus simulate
separation adequately, as well as ensuring the refinement of the outer region was adequate for simulation
of wake characteristics. This was performed by the relative definition of layer thickness in the snappy-
HexMeshDict file. This is further discussed in the appendix (App.B).
The number of layer refinement iterations was set to four, enforcing four reductions in cell size during the
refinement iteration process. In addition, a refinement region was created in the wake zone of the sphere
to ensure adequate resolution of separation and vortex shedding. The number of layers per refinement
iteration (buffer layers) was set to 15 to provide a good balance of refinement and computational effi-
ciency. These parameters were implemented throughout the entirety of the following no-turbulence-model
sections.
Within the computational set for the no-turbulence-model RANS simulations, proof of solution accuracy
independent of mesh density is required to lend integrity to the solutions. No-turbulence-model compu-
tational domains range from 281,000 cells for Re = 1 in the most coarse mesh to 1.26 million cells at
Re = 1, 000, 000 for the most fine mesh.
Figure 17: Computational domain of minimum refinement for laminar cases
Figure 18: Computational domain of maximum refinement for laminar cases
It should be noted that the artifacts seen in the mesh (Fig.17) and (Fig.18) are a rendering issue within
ParaView and not indicative of poor mesh quality. In addition, the far field has been deliberately left
relatively coarse. The intention of this coarseness in the downstream region is twofold; to reduce com-
putational effort (since fewer cells require fewer computations) and to numerically dissipate turbulence
in the far field to aid outlet conditions, reducing any reverse flow noise which should intefere with the
solution .
CP-AOO-123 20
6.1.2 Qualitative flow data
Figure 19: Qualitative field properties for no turbulence model configuration at various Re.
The flow visualisation (Fig.19) shows that the simulations are producing flow fields which are in agreement
with expectations. This gives an early indication that the snappyHexM esh utility is able to create a
mesh capabale of producing an accurate result. It can be seen that as the Reynolds number increases
the flow becomes more turbulent. This also causes the wake to become asymmetrical as the inherently
unsteady time dependent nature of the flow is averaged for a steady RANS solution. While this does not
greatly affect the qualitative aspects of the flow field it will be seen that this has adversely effected the
quantitative data.
CP-AOO-123 21
6.1.3 Vorticity contours
(a) Re = 100
(b) Re = 1000
(c) Re = 100, 000
(d) Re = 1, 000, 000
Figure 20: Comparison of vorticity for varying Reynolds number with no turbulence model.
This comparison of vorticity iso-contours (Fig.20) demonstrates the relatively more complex vortex struc-
tures as the Reynolds number increases. This result is expected and confirms that the no-turbulence-
model is predicting the general pattern of increased three-dimensionality. This is despite the fact that
RANS attempts to average the results of an inherently unsteady phenomenon to fit a steady state solu-
tion. One point to note is that the wake profile decreases dramatically from Re = 1, 000 to Re = 106 ,
which was expected due to the drag crisis during laminar to turbulent boundary layer transition. This
is an unexpected result with no-turbulence-model configuration as the boundary layer transition to full
turbulence is the root cause of the drag crisis. This shows that the RANS equations are able to predict
at least some of this behaviour without further modelling.
CP-AOO-123 22
6.1.4 Coefficient of Drag, CD
Figure 21: Comparison of CD (changing mesh refinement, no turbulence model) with experimental data
[39]
.
Table 1: Drag as a function of mesh refinement for a range of Re with no turbulence model.
Coarse mesh Fine mesh Extra fine mesh

Re CDexp Cells CD Error % Cells CD Error % Cells CD Error %
1 27 281k 30.7 12.05 656k 30.7 12.05 1.29M 30.7 12.05
5 7.4 281k 7.50 1.33 656k 7.50 1.33 1.29M 7.50 1.33
10 4.3 281k 4.50 4.44 656k 4.50 4.44 1.29M 4.50 4.44
102 1.1 281k 1.10 0.00 656k 1.10 0.00 1.29M 1.10 0.00
103 0.47 281k 0.52 9.62 656k 0.51 7.84 1.29M 0.51 7.84
104 0.41 281k 0.47 12.77 656k 0.52 21.15 1.29M 0.52 21.15
5 × 104 0.47 281k 0.20 -135.00 656k 0.33 -42.42 1.29M 0.44 -6.82
105 0.45 281k 0.18 -150.00 656k 0.22 -104.55 1.29M 0.31 -45.16
2 × 105 0.42 281k 0.17 -147.06 656k 0.14 -200.00 1.29M 0.20 -110.00
3 × 105 0.17 281k 0.16 -6.25 656k 0.16 -6.25 1.29M 0.16 -6.25
4 × 105 0.091 281k 0.15 39.33 656k 0.12 24.17 1.29M 0.14 35.00
5 × 105 0.093 281k 0.16 41.88 656k 0.14 33.57 1.29M 0.14 33.57
106 0.14 281k 0.15 6.67 656k 0.13 -7.69 1.29M 0.13 -7.69
The coefficient of drag results (Fig.21) (Tab.1) were calculated using a function definition known as
f orceCoef f s in the case directory. This utility integrates the pressure field over the sphere patch sur-
face, in a direction specified by the user, to produce the drag coefficient. It should be noted that this
utility does not include the effects of skin friction on the total drag. This is justified in the cases studied
since the viscous drag is small compared to the pressure drag (with exception to Re = 1).
These results correlate well with the experimental data in the low Re region (5 ≤ Re ≤ 100) as expected.
This was proven to be independent of the mesh as all levels of refinement produced an agreeably similar
solution (within 5%). This level of accuracy also extended to higher Reynolds numbers (103 ≤ Re ≤ 104 )
than was expected. Given these promising results it would be advised that the use of RANS without
a turbulence model can confidently reproduce the averaged coefficient of drag over a three-dimensional
CP-AOO-123 23
bluff body of medium complexity (with separation) up to Re ≈ 1000. It should be noted that the result
at Re = 1 is relatively inaccurate. The reason for this descrepancy is that at such a low Reynolds number
the viscous drag accounts for a higher percentage of the total drag on the sphere, which is not accounted
for in this simulation.
The most significant observable result was greater than expected correlation with experimental data in
the transitional and turbulent Reynolds region (104 ≤ Re ≤ 106 ). Though particular results such as
Re = 100, 000 are substantially incorrect, the overall margins and trends are far more consistent than one
would expect from a configuration which makes no attempt to model the significant turbulent phenomena
occuring in this region. The most promising result from these simulations is that there is a trend for
increased mesh refinement towards the experimental data even in the transition region, which is notori-
ously difficult to simulate correctly. This does not categorically state that infinite refinement would yield
the correct drag solution, but there is the strong suggestion that further refinement would approach the
correct result. This is however a computationally intense activity since when the cell size approaches zero
the simulation tends towards a direct numerical simulation. It can be seen that this would eventuate
in diminishing returns and hence further refinement was not performed in this study due to insufficient
computational resources.
A further feature of the results is the accuracy of the solution for all levels of refinement at Re = 106 . This
is extremley surprising as at such a high Reynolds number the flow is extremely time dependent and yet
the steady state RANS simulation is able to determine the integral properties of the flow within a margin
of error of < 8%. It is understood that this result is a continuation of the downward trend through the
transition region and may be conincidentally correct rather than representative of a succesful simulation.
However, the solution remained accurate for all refinment levels which were utilised. This suggests
that the result may not be coincidental and should not be dismissed without investigation. Further
flow characteristics will be analysed to determine the likelihood of simulating this highly turbulent flow
without a turbulence model.
6.1.5 Coefficient of Pressure, CP
(a) No-turbulence-model Cp simulation results at z = 0. (b) Constantinescu and Squires [28].
Figure 22: Comparison of coefficient of pressure about sphere.
The CP results (Fig.22a) compare reasonably well with those previously published (Fig.22b). However,
the comparative plots of CP identify the fundamental problem with the no-turbulence-model configu-
ration. While the no-turbulence-model is applicable in low speed regions and unexpectedly accurate at
Re = 300, 000 and Re = 106 the transition region is poorly simulated (see Re = 105 results). At Re = 105
it was previously seen that the drag coefficient significantly deviates from experimental results and the
reason for this is demonstrated in the CP curve. Clearly the pressure balance in and near the transition
region is poorly simulated using RANS without a turbulence model.
CP-AOO-123 24
By comparison with the coefficient of drag results (Fig.21) it is evident that a more accurate CP plot
correlates with a drag that agrees more closely with experimental data. This is expected since CD is the
integral of CP over the sphere surface in the streamwise direction (ignoring friction). For Re = 10, 000 this
result is explicable due to the fact that the flow is still approximately laminar. At Re = 300, 000 and Re =
106 , the result is correct contrary to expectation. This can, at least in part, be accounted for due to the
difference in apparent separation angles at these flow conditions relative to the experimental results. It
is clear that the CP data for these Re are skewed by several degress away from the front of the sphere.
This indicates a smaller wake region and hence a decrease in overall pressure drag. Further investigation
into the location of separation angles was conducted (Sec 6.1.6).
6.1.6 Separation angle

Separation angle is an indicative measure of the size of the wake region occuring behind the sphere and
hence the amount of pressure drag the body experiences. Separation angles are commonly referred to in
literature and therefore provide a useful point of comparison. Separation is defined as the point at which
the wall shear stress is equal to zero. The separation angle is the angle to this position measured from
the upstream stagnation point on the sphere.
In order to compute this using OpenFOAM, the utility wallShearStress was implemented to plot the
shear stress on the surface of the sphere (Fig.23). The magnitude of the shear stress was then plotted as
a function of distance along the surface of the sphere to determine the point at which zero shear stress
occured. The separation angles for a range of Reynolds numbers were investigated and tabulated (Tab.6).
It should be noted that no separation was apparent at Re = 1 and Re = 10 which is consistent with the
assertion that separation should not occur until Re ≈ 21 [40].
Figure 23: Wall shear stress for Re = 102 , 103 , 105 , 106 (left to right) with no turbulence model.
Table 2: Separation angles for a range of Re.
Re θs,lower (◦ ) θs,upper (◦ ) θs,mean (◦ ) Lit. Error (%)

102 126.6 126.9 126.7 125 1.3
103 99.1 100.5 99.8 100 -0.2
104 88.4 85.0 86.7 88 -1.5
5 × 104 110.5 102.8 106.7 84 21
105 109.4 114.8 112.1 83 26
2 × 105 122.6 117.7 120.1 84 30
3 × 105 122.0 119.4 120.7 105 13
4 × 105 122.0 124.6 123.3 118 4.3
5 × 105 147.2 110.8 129.0 119 7.8
106 139.2 129.7 134.4 121 10
CP-AOO-123 25
An important consideration for assessing the separation angle for the sphere, especially for highly turbu-
lent flows, is the potential asymmetry which has already been noted in the flow visualisations (Sec 6.1.2
and Sec 6.1.3). For an asymmetrical solution it could be the case that the separation points above and
below the centreline of the sphere do not agree. Thus, an average separation angle has been calculated
in order to decrease this effect. It should also be noted that the separation angles have been assessed for
the centreline plane of the sphere only (the z = 0 plane), which is a simplifying assumption given the
highly three dimensional nature of the flow.
A more visual comparison of experimental and simulated separation angles has been illustrated (Fig.24).
In this representation the simulated results have been shown on the upper half of a sphere, with the lower
half showing results for the same Reynolds number from literature [31] [29].
Figure 24: Separation angles of simulation and comparative data.
This graphic (Fig.24) visually demonstrates the agreement between simulation and experimental results
for separation angles across four separate Reynolds numbers. Evidently Re = 100 and Re = 1, 000 are
accurate since the laminar assumption still holds in this regime. At Re = 106 and Re = 3 × 105 the
agreement is surprisingly accurate in keeping with the unexpected results obtained at these high Reynolds
numbers for CD . However, in the transitional region the simulation yields a significantly inaccurate result
at Re = 100, 000.
This result further reinforces the relative merits and fundamental failings of utilising RANS without a
turbulence model. Low Reynolds numbers, and to a lesser extent Re = 106 , are well resolved yielding
an accurate result while the transition region is poorly simulated. However this is not particularly
detrimental to running RANS simulations without a turbulence model, since the transition region has
been proven repeatedly to be a challenging flow regime to model correctly. This analysis shows that an
approach to simulation using RANS without a turbulence model is able to produce the correct wake size
for up to Re = 1, 000. Although results have shown accurate agreement for higher Reynolds numbers past
the drag crisis, this area requires further investigation as the correlation could be due to a cancellation
of errors and may not be repeatable. The reason for the close correlation in this region is suspected
to be due to choice of numerical discretisation scheme, linear upwind differencing. The solution to the
RANS equations without using a turbulence model is a current area of research, which suggests that the
numerical diffusion inherent in certain discretisation schemes may act to smear and dissipate the flow
field in a similar manner as does the eddy viscosity of a turbulence model [41].
CP-AOO-123 26
6.2 Turbulence models
Having gained confidence in OpenFOAM’s capability to deal with the underlying physical phenomena
inherent to flow over a sphere, the two popular turbulence models (k − and k − ωSST ) are now im-
plemented. As wall functions have been used in this application, the concept of mesh refinement is not
directly applicable. This is due to the fact that the minimum surface cell size is required to be within
the log-law region of the boundary layer to obtain the correct y + value. Although k − ωSST can be
implemented without the use of a wall function, this was not undertaken as a comparison between k −
and k − ωSST on the same mesh is desired. The range of Reynolds numbers which have been studied
do not extend to the laminar region since the models are not designed for use within this flow scenario
and as such would not normally be implemented here.
It is well known that the k − turbulence model has difficulty obtaining correct results for flows which
have large adverse pressure gradients such as flow over a bluff body. However, k − ωSST has been
adapted to cope more readily with such flows. Regardless of the model it was expected that the use of
a steady RANS solver on such a highly time dependent flow would produce significant deviation from
experimental results. Despite this it was expected that both turbulence models would more closely agree
with the experimental data during transition and full turbulent regimes than a RANS implementation
with turbulence modelling deactivated.
The results of the turbulence modelling in this scenario show that both turbulence models underpredict
the coefficient of drag in the region before the drag crisis, with mixed results at higher Reynolds numbers.
It was found that post drag crisis the k − ωSST model performs well. This is likely owing to the fact that
after the drag crisis the wake size decreases due to the turbulent nature of the boundary layer. As will be
shown both turbulence models tend to obtain higher than expected separation angles which becomes less
of a problem for drag caculation as the actual wake size decreases. Conversely, the k − model remains
inconsistent. With regards to specific models, it was noted that the results for the k − ωSST model at
Re > 5 × 105 were comparatively more accurate than without a turbulence model, while the k − model
follows a trend which does not closely match the experimental CD .
6.2.1 Mesh generation

Creating a mesh for a turbulence model is fundamentally similar to creating a mesh for the non-turbulence-
model cases. snappyHexMesh is used and refinement regions are included on the sphere patches and
immediately downstream of the sphere. The most significant difference is that the control of y + is now
an important factor. y + is defined as
u∗ y
y+ = (20)
ν
and is a measure of the distance between the first cell center and the wall of the geometry. For successful
implementation of k − and k − ωSST with wall functions the y + value should be such that the first
cell is positioned within the log-law region of the boundary layer, which correlates to y + ≈ 40 − 200.
Layer addition for turbulence models therefore relies on appropriately defining the first cell to be in this
range. The first section of non-layered (castellated) mesh is therefore set to be no more refined than these
surface layers in order to maintain mesh consistency and avoid sudden changes in cell size which can lead
to numerical inaccuracies.
While y + and the associated mesh coarseness does reduce computation time for a turbulence model, the
requirements for y + at low velocities result in excessively large cells (equal to the radius of the sphere
or greater) at the sphere surface. It is for this reason that subsequent post-processing ignores the low
Reynolds cases.
CP-AOO-123 27
6.2.2 Turbulence parameters
As mentioned previously (Sec 4.1) turbulent boundary and initial conditions must be set manually
throughout the flow field before an OpenFOAM simulation can be processed. In order to set these
initial and boundary values the following equations (Eq.21) were utilised [42]. These values apply to both
the internal field at the first iteration and also the patch faces (inlets, outlets and sphere surface).
3 √
3 2 k2 k
k = (U I) , = Cµ , ω= (21)
2 l l
Where I is the initial turbulent intensity, l is a turbulent length scale and Cµ is a closure coefficient.
Since the incoming flow is assumed to be non-turbulent in nature and by consultation with experienced
CFD users, it was ascertained that a reasonable value for the initial turbulence intensity in the case of
non-turbulent flow over an object was 0.5% [43]. Similarly, it was ascertained that a reasonable value for
the turbulent mixing length was 5% of the sphere diameter, thus l = 0.1m was chosen [44]. Cµ is readily
accepted in literature to have a value of Cµ = 0.09 [1]. Using these values, the turbulence parameters
were calculated for each of the test cases (Tab.3).
Table 3: Turbulent parameters for various Reynolds numbers.
Re k ω
10k 2.11E-07 8.72E-11 4.59E-03
50k 5.27E-06 1.09E-08 2.30E-02
100k 2.11E-05 8.72E-08 4.59E-02
200k 8.44E-05 6.98E-07 9.19E-02
300k 1.90E-04 2.35E-06 1.38E-01
400k 3.38E-04 5.58E-06 1.84E-01
500k 5.27E-04 1.09E-05 2.30E-01
1M 2.11E-05 8.72E-08 4.59E-02
In order to give confidence that a slight inaccuracy in turbulence parameteres would not have an adverse
affect on the solution a sensitivity study was conducted (Tab.4). This study showed that the solution
is fundamentally insensitive to large changes in k and ω due to the iterative nature of the solver. It
was found that a deviation of three orders of magnitude in initial conditions resulted in no more than a
5% change in the CD solution. With these results, the initial calculations of turbulent parameters were
accepted.
Table 4: Comparison of initial conditions and CD for k-ω model.
k
0.000084 0.00672 0.0084 0.01008 0.84
0.009186 - - 0.22546 - -
0.73488 - 0.22346 0.22680 0.22436 -
ω 0.9186 0.22889 0.22970 0.22770 0.22580 0.23968
1.10232 - - 0.22622 - -
91.86 - - 0.22468 - -
CP-AOO-123 28
6.2.3 Qualitative flow data
Figure 25: Qualitative flow field data for k − and k − ωSST models.
As with the no-turbulence-model cases, the results utilising turbulence models produce a flow field which
is in agreement with the expected flow profiles. Compared to the no-turbulence-model cases these results
have a less erratic wake region due to the numerically induced eddy viscosity. This has the intended
purpose of smoothing the time dependent flow field, thus making the physics more compatible with a
steady state RANS solver. Another point to note is that both models correctly predict a decreasing wake
size with increasing Reynolds number. However, it should be noted that both turbulence models predict
a much smaller wake region than does the no-turbulence-model case which will be investigated further in
subsequent sections (Sec 6.2.7).
CP-AOO-123 29
6.2.4 Vorticity contours
(a) Vorticity contours for the k − model.
(b) Vorticity contours for the k − ωSST model.
Figure 26: Comparison of vorticity for varying Reynolds number and turbulence model.
As expected both turbulence models predict an increase in the separation angle for increased Reynolds
numbers. Whilst this indicates that the models are correctly reproducing this aspect of the physics of
the wake, a comparison to the no-turbulence-model case (and later experimental data) shows that wakes
in the transition region are smaller than in reality.
A direct contrast of the results for the k − and k − ωSST models shows that at lower Reynolds numbers
the k − ωSST implementetion is more effective at smoothing out the solution, thus obtaining a symmet-
rical wake pattern in the transitional flow regime (Re = 100, 000). As will be shown, this does not imply
a more accurate solution to the integrated properties.
By comparison with the no-turbulence-model vorticity iso-contours (Fig.20) it is evident that the solution
is being smoothed by the turbulence models. For both k − and k −ωSST there is no discernable increase
in vortex shedding as Reynolds number increases, unlike the no-turublence-model case. This is a feature of
turbulence models and is useful when attempting to enforce a mean behaviour to the integrated properties
of a highly time-dependent turbulent flow.
CP-AOO-123 30
6.2.5 Coefficient of drag, CD
Figure 27: Comparison of drag coefficient for differing models against experiment [39].
Table 5: Drag as a function of mesh refinement for a range of Re and turbulence model.
Best no-turbulence k− k − ωSST

Re CDexp Cells CD Error % Cells CD Error % Cells CD Error %
104 0.41 1.29M 0.52 21.15 112,155 0.37 -10.81 112,155 0.36 -13.89
5 × 104 0.47 1.29M 0.44 -6.82 348,484 0.24 -95.83 348,484 0.23 -104.35
105 0.45 1.29M 0.31 -45.16 348,484 0.19 -136.84 348,484 0.17 -164.71
2 × 105 0.42 1.29M 0.20 -110.00 462,176 0.14 -200.00 462,176 0.14 -200.00
3 × 105 0.17 1.29M 0.16 -6.25 543,275 0.13 -30.77 543,275 0.13 -30.77
4 × 105 0.091 1.29M 0.14 35.00 543,275 0.12 24.17 543,275 0.12 24.17
5 × 105 0.093 1.29M 0.14 33.57 2.37M 0.11 15.45 2.37M 0.097 4.12
106 0.14 1.29M 0.13 -7.69 2.37M 0.099 -41.41 2.37M 0.14 0.00
The coefficient of drag for both turbulence models were calculated for a range of Reynolds numbers
(Tab.5) and were compared against the most highly refined no-turbulence-model results (Fig.27). It is
clear that until the drag crisis (Re ≈ 3 × 105 ) both models underestimate the drag on the sphere with a
substantial margin of error (up to 200%). Post drag crisis, the k − ωSST model initially over predicts and
then corrects to match the experimental data whereas the k − model continues on its slowly decreasing
trend. Clearly these models capture the decrease in drag due to the drag crisis, however the result is
smeared over a larger range of Reynolds numbers than the real pheonomenon. A factor which may explain
the underprediciton of drag is the decreased size of the wake region. This has the effect of altering the
overall pressure distribution about the sphere. An analysis of the pressure distribution and separation
angles was conducted to confirm this possibility (Sec 6.2.6 & Sec 6.2.7).
CP-AOO-123 31
The correction of the k − ωSST result post drag crisis is an expected outcome since beyond the drag
crisis the boundary layer is fully turbulent which is the models intended application domain. What is
surprising is that the model is still able to produce such good agreement (< 5% error) given a forced
steady state solution for what is a highly time-dependent and unsteady flow. Conversely, the k − model
performs either no better or substantially worse than than the k − ωSST for all Reynolds numbers on the
same mesh. It is interesting that the RANS simulation without turbulence modelling also outperforms
the k − model, although this result may not be directly compared due to the finer mesh of the no-
turbulence-model case.
6.2.6 Coefficient of pressure, CP
(a) Cp against Re for the k − model. (b) Cp against Re for the k − ωSST model.
Figure 28: Cp results for simulations using the k − and k − ωSST model.
The coefficient of pressure over the centreline of the sphere (z = 0 plane) was calculated for each turbu-
lence model (Fig.28). It is clear that there is a very high level of agreement between the results obtained
and the previously shown comparative data (Fig.22b). The result that the CP curves are consistent
and follow the same general trend shows that the turbulence models are able to capture and reproduce
some of the fundamental physics inherent in this complex problem. One of the factors that influences
the ability of the turbulence models to reproduce such accurate data is their implementation of an eddy
viscosity term which tends to smear the properties of the flow by acting as an artificial diffusion. This
smoothing is evidenced in comparison to the no-turbulence-model results (Fig.22) by the difference in the
downstream section of the sphere which exhibits large fluctuations in the absence of a turbulence model
but is essentially constant when a model is present.
An important inference from these results is that both turbulence models have a region of positive pres-
sure at the downstream side of the sphere which is not present in the experimental data. As the coefficient
of drag is calculated by integrating the pressure about the sphere this effect leads to an overall decrease
in the calculated drag. This coincides with the lower calculated drag coefficients previously determined
to be a feature of the turbulence models. In addition, it can also be seen that the separation angle has
been overestimated leading to a smaller wake profile. This effect is explored in more detail in section
6.2.7. Since a decreased wake region also constitues a lower pressure drag, it possible that there is a
summative effect causing the dramatic decrease in drag compared to the experimental result.
CP-AOO-123 32
6.2.7 Separation angle
Figure 29: Shear stress for the k − and k − ωSST models.
Table 6: Separation angles for a range of Re.
k− k − ωSST
Re θs,lower (◦ ) θs,upper (◦ ) θs,mean (◦ ) θs,lower (◦ ) θs,upper (◦ ) θs,mean (◦ ) Lit.
104 145.6 146.2 145.9 144.4 144.5 144.4 88
5 × 104 123.1 139.9 131.5 118.0 133.0 125.5 84
105 123.7 137.6 130.7 134.0 131.3 132.6 83
2 × 105 103.7 140.5 122.1 129.0 130.7 129.9 84
3 × 105 137.5 136.5 137.0 131.7 132.4 132.1 105
4 × 105 135.7 135.9 135.8 144.9 149.1 147.0 118
5 × 105 136.0 137.0 136.5 152.9 172.8 162.9 119
106 150.6 134.2 142.4 139.2 164.2 151.7 121
The separation angle data above (Tab.6) was calculated in the same manner as for the no-turbulence-
model cases (see Sec 6.1.6). The results clearly show a large overstimation of the separation angle
compared to experimental results [31] [29] when utilising both the k − and k − ωSST models. This
result is useful in explaining the large underestimation of the coefficient of drag for the sphere simulations.
By overestimating the separation angle the models have effectively decreased the wake size and hence the
overall pressure drag on the body. It can be seen that the error in separation angle decreases as Reynolds
number increases and thus the error in the CD result should also decrease (as observed).
It is clear that the error associated with the turbulence models at lower and transitional Reynolds numbers
is very significant. Utilising the k − and k − ωSST models for such a purpose is clearly not appropriate
as these models were invented for the purposes of solving fully turbulent boundary layer flows. For a more
accurate depiction of the integrated properties associated with separation angle a no-turbulence-model
configuration would naturally be suggested in this region.
CP-AOO-123 33
7 Submarine Hull
The Defence Science and Technology Orgaqnisation (DSTO) is interested in the use of OpenFOAM for
studying flow over complex geometries. Of particular importance is the study of flow over the Joubert
submarine hull. This is an interesting case as the Joubert hull, in its operating environment, is within
a very high Reynolds number flow scenario. In addition, the design of the hull ensures that the bound-
ary layer remains fully attached along most of the hull’s length. Due to the high Reynolds number the
boundary layer is both attached and fully turbulent making it well suited for simulations using RANS
turbulence models. It was expected that the turbulence models would perform accurately over the hull,
since the effects of separation are less pronounced. DSTO has shown great interest in the ability of
the snappyHexM esh utility to produce high quality meshes for in-depth analysis. If it is found that
snappyHexM esh is able to meet this requirement then it would provide DSTO with a more time effi-
cient approach to modelling flow about complex bodies.
Despite significant and continued efforts to succesfully implement the snappyHexM esh utility the con-
struction of a functional mesh is at this stage incomplete. The difficulties encountered stem from both
the complexity of the geometry and substantial technical difficulties involving the definition of the .STL
file which was provided. Although at this stage a mesh has not been completed, it is thought that the
snappyHexM esh utility will ultimately be capable of prodcucing an adequate mesh, provided a series of
technial specifications are met.
7.1 Problems with Joubert bare hull meshing

A series of refinement difficulties led to a poor quality result in attempting to mesh the Joubert submarine
hull using the snappyHexM esh utility. After various attempts at meshing the hull, it was discovered
that a flaw near the tail section (Fig.30) could not be eliminated due to the definition of the underlying
.STL file.
Figure 30: Example mesh created using snappyHexMesh (magnification of the tail region).
To investigate the cause of this problem it is best to focus more intently on the tail region during the
snapping stage to investigate how these problems propagate to the final mesh (Fig.31). The cells around
the tail are evidently of poor quality when the snapping phase has been completed. This is due to the
geometry being non-ideal and hence very challenging for the iterative snapping process to appropriately
deform the orthogonal cells to the very non-orthogonal geometry of the submarine bare hull.
The poor mesh quality at the snapping phase resulted in very poor layer addition. Since layers are added
by first forcing the existing snapped mesh away from the .STL surface, these cells were forced back in
such a way that was not conducive to quality layer addition. Running a simulation on this mesh yielded
incorrect results compared to DSTO’s previous simulations and experimental data. Hence, the mesh was
deemed too poor to allow the numerical solvers to function accurately. In an attempt to remedy this the
mesh was also built without the layer addition phase but maintaining adequate control of the y + value
with such an erratic cell structure was extremely challenging and results remained poor. This underlies
CP-AOO-123 34
the major complication with snappyHexMesh - geometries that are approaching orthogonality are much
harder to accurately refine.
Figure 31: Tail section after castellating, snapping and layer addition phases (left to right).
As well as significantly reducing mesh quality (Fig.32), these deformed cells were also affecting mesh
statistics. When the utility yPlusRAS was run to determine the minimum, mean and maximum y +
values the calculations revealed an average of 150. Whilst this would be an acceptable value in itself, it
was clearly skewed by the maximum value which was over 1, 500 in the tail section. This was confirmed
when the y + value was viewed in ParaView and it could clearly be seen that the majority of cells had a
y + value of 14.
Figure 32: Velocity profile in the tail region of the Joubert bare hull.
DSTO also offered to supply a structured mesh ,that had previously been created, as a point of com-
parison to the snappHexM esh mesh. However, the structured mesh also presented problems due to
incompatabilities with different versions of OpenFOAM. This reinforced the challenges associated with
meshing complex geometries - creating a mesh is a more complicated procedure than is often made clear
and can present serious challenges to researchers and commercial users.
7.2 Simulation results

Despite the poor mesh quality, simulations were performed to quantify the error that these meshes were
producing. The results (Tab.7) highlight the importance of high mesh quality and the effect which
meshing errors can have on final solutions. Case 2 was especially poor as the y + mesh statistic could not
be trusted due to the bias to the tail cells.
Table 7: Drag as a function of mesh refinement for a range of Re.
Mesh information
Case Model Layers Cells Acceptable y+ave CD Error %
1 no turb Yes 8,021,152 No N/A 0.024 2300
2 k− Yes 898,189 No Varies 0.011 1000
3 k− Yes 2,770,007 No 155 Varies N/A
4 k− Yes 898,189 No 109 0.58 57900
CP-AOO-123 35
8 Conclusion
The majority of work completed has confirmed that the OpenFOAM software suite and its implemen-
tation of both the RANS solver simpleF oam (as well as the associated turbulence models k − and
k − ωSST ) perform as expected for a variety of tests. Given many of the previous successes in validating
OpenFOAM for a range of other flow conditions this report adds to the evidence that OpenFOAM is a
highly capable CFD software package. There were also several interesting outcomes of the simulations
that were unexpected.
The comparatively high level of accuracy of the steady state RANS equations, without any implemen-
tation of a turbulence model, was surprising. It was expected and confirmed that this implementation
produces excellent concordance with experimental data within the laminar region (1 ≤ Re ≤ 1, 000),
with results being accurate to within 5% for the coefficient of drag and a maximum error of 1.3% for the
separation angle. Beyond this region it was predicted that the RANS solver without a turbulence model
would give very poor results. Contrary to expectation, it was shown that the outcomes far exceeded these
predictions for not only the transitional region but also for fully turbulent flow. The most surprising result
was the agreement of the non-turbulence-model’s solutions at very high Reynolds numbers (Re = 106 ),
being accurate to within < 8% for the coefficient of drag and < 10% for the separation angle. Whilst
further research is required to determine the root cause behind this unexpected accuracy, it is postulated
that a major factor could be the numerically induced artificial diffusion due to the choice of linear upwind
differencing as the discretisation scheme. This is a developing area of research within the field of CFD and
is becoming increasingly popular with some researchers who have previously recommended turbulence
modelling for solving such problems [41].
The performance of the steady state solver in the post drag crisis region during the implementation of
the k − ωSST turbulence model was also of note. Whilst it was clearly expected that k − ωSST would
perform comparatively very well in the post drag crisis conditions (due to the fully turbulent boundary
layer) there was not a strong belief that a steady state solution would be capable of so accurately ex-
tracting the mean properties of such a highly time-dependent flow field. The results in this configuration
show an error of approximately 4.12% for coefficient of drag at Re = 5 × 105 , decreasing to a negligible
error at Re = 106 . These results are effectively mirrored in the separation angle analysis.
The k − model which was implemented in these simulations was the lesser sophisticated of the two
turbulence models analysed and thus it was initially suspected that it would encounter difficulties in such
a complex flow scenario as a three dimensional sphere. Results show that these suspicions were confirmed
within the OpenFOAM environment and it has been illustrated in this case to be a less effective tool
than k − ωSST for simulations of flow over a sphere. Throughout the entire range of Reynolds numbers
studied it has been a constant theme that the determination of integrated flow properties is more accu-
rately simulated using the k − ωSST model on the same mesh or by use of RANS without a turbulence
model on a more refined grid.
Regardless of which model was implemented, it has been shown that solving the steady state RANS
equations can give accurate results. This is an important outcome as there is no obvious reason why this
should be the case. Flow over a sphere, particularly at high Reynolds numbers, is a highly fluctuating and
time-dependent phenomenon. Despite this the Reynolds averaging undertaken has been able to simplify
this problem and extract mean and integrated quantities at a much higher level of accuray than was
expected. This result is significant due to the cost effectiveness of implemeneting the RANS simulations.
Whilst much more accuracy and detail can be gained through more advanced large-eddy, detached-eddy
or direct numerical simulations, they require much longer run times for simulations to complete. For
most industry designers a great deal of the information provided by these advanced analyses may not be
required and often the most important parameters for design are the integrated and averaged properties
available through RANS. Thus, for some particular design scenarios, even involving some level of erratic
time-dependent behaviour, it may be possible to conduct a more efficient study through the use of RANS
rather than a more sophistaced computational model.
CP-AOO-123 36
It was hoped that the Joubert submarine hull and its fully attached boundary layer flow could be used
to demonstrate the better suitability of both the k − and k − ωSST models to this flow condition.
Whilst this was ultimately unsuccesful the surprising level of accuracy obtained over the sphere (for
what is a technically more difficult simulation involving steep adverse pressure gradients) suggests that
snappyHexM esh would, with further investigation, be capable of producing a high quality mesh for
accurate simulation. The difficulties encountered using both snappyHexM esh and the provided struc-
tured mesh only serve to highlight the problems facing industry in meshing complex geometries. This,
if anything, underscores the need for a utility such as snappyHexM esh which could remove the labour
intensive mesh generation element from the CFD process.
While in this report the k − ωSST turbulence model was implemented with the use of a wall function, a
further investigation could be conducted to determine the accuracy of this model without wall functions
on more highly refined meshes. This would serve to allow for a more direct comparison with the no-
turbulence-model case which was simulated in this analysis. These results would also highlight the
effects that the wall function implementation has had on the accuracy of a solution in a complex flow
scenario with adverse pressure gradients. Another interesting avenue of research would be to continue
with current simulations through to higher Reynolds numbers. While at the present time it seems that
the k − ωSST model has begun to follow an accurate trend based upon coefficient of drag results, this
further study could help to confirm this trend. Similarly it would be useful to see the continuation of the
no-turbulence-model tests to determine whether the obsevred accuracy at Re = 106 is due to correlation
with experimental data or a fortunate intersection due to cancellation of errors. It may also be possible
that the k − model may become more accurate and reliable at higher Reynolds numbers.
CP-AOO-123 37
9 References
[1] David. C. Wilcox, Tubulence modeling for CFD, DCW Industries, Inc. Third edition, 2006
[2] R. Schiestel, Modelling and simulation of turbulent flows, Wiley Press, 2007
[3] M. Van Dyke, An Album of Fluid Motion Parabolic Press, Inc. 12th edition, 1982
[4] Photograph courtesy of NASA Langley Research Center
[5] S. Thoroddsen M.-J. Thoraval/KAUST, Down the street

[6] Unknown, http://en.wikipedia.org/wiki/File:Jet.jpg
[7] J. Piquet, Turbulence flows: Models and Physics, Springer, 2003
[8] T. B. Gatski, M. Yousuff Hussaini & John Leask Lumle, Simulation and Modeling of Turbulent Flows
Oxford University Press, 1996
[9] Ching Jen Chen & Shenq-Yuh Jaw, Fundamentals of turbulence modeling, Taylor & Francis (1998)
[10] Unknown author, http://www.cfd-online.com/Wiki/Boussinesq eddy viscosity assumption, cfd-
online forum, last revised Jan 3, 2012
[11] Unknown author, www.cfd-online.com/Wiki/K-epsilon models cfd-online forum, last revised June
18, 2012
[12] Unknown author, http://www.cfd-online.com/Wiki/Wilcox%27s k-omega model cfd-online forum,
last revised March 8, 2011
[13] Unknown author, http://www.cfd-online.com/Wiki/SST k-omega model cfd-online forum, last re-
vised February 28, 2011
[14] Unknown author, http://www.cfd-online.com/Wiki/File:HRNvsLRN.png cfd-online forum, last re-
vised October 31, 2011
[15] Lin Gaoa,Jinglei Xua,Ge Gaoa, Numerical Simulation of Turbulent Flow past Airfoils on Open-
FOAM, International Conference on Advances in Computational Modeling and Simulation
[16] Christian Kunkelmann, Peter Stephan, CFD Simulation of boiling flows using the volume-of-fluid
method within OpenFOAM, Numerical Heat Transfer, Part A, 56: 631646 2009
[17] N M Sudharsan, V A Jambekhar, V Babu, A validation study of OpenFOAM using the supersonic
flow in a mixed compression intake, Proceedings of the Institution of Mechanical Engineers; 2010;
224, G6; ProQuest Military Collection pg. 673
[18] Florian Habla et al., Numerical simulation of viscoelastic two-phase flows using OpenFOAM, Chem-
ical Engineering Science 66 (2011) 54875496
[19] Con J. Doolan, Flow and Noise Simulation of the NASA Tandem Cylinder Experiment using Open-
FOAM, 15th AIAA/CEAS Aeroacoustics Conference.
[20] Nilsson H. and Page M., OpenFOAM simulation of the flow in a Holleforsen draft tube model,
Proceedings of the third IAHR/ERCOFTAC workshop on draft tube ow 8-9 December 2005, Porjus,
Sweden
[21] Nicoleta Herzog et al., A comparative study of different CFD-codes for numerical simulation of
gassolid fluidized bed hydrodynamics, Elsevier, Computers and Chemical Engineering 39 (2012) 4146.
[22] Benjamin Wuthrich, Yongjoong Lee, Verification and validation studies of OpenFOAM for transonic
compressible flow simulations inside high voltage circuit breaker diffusers, 978-1-4244-2092-6, IEEE.
[23] Madeleine Coutanceau and Jean-Rene Defaye, Circular cylinder wake configurations: A flow visual-
ization survey, Appl Mech Rev vol 44, no 6, June 1991.
CP-AOO-123 38
[24] M. Coutanceau and R.Bouard, Experimental determination of the main features of the viscous ow in
the wake of a circular cylinder in uniform translation. Part 1. Steady ow, Journal of Fluid Mechan-
ics/Volume 79/Issue 02/February 1977
[25] Md. Mahbubar Rahman, Md. Mashud Karim and Md. Abdul Alim, Numerical investigation of
unsteady flow psat a circular cylinder using 2-D finite volume method, Journal of Naval Architecture
and Marine Engineering, Vol. 4, No. 1 2007.
[26] S.Singha & K.P.Sinhamahapatra, High-Resolution Numerical Simulation of Low Reynolds Number
Incompressible Flow About Two Cylinders in Tandem, Journal of Fluids Engineering-transactions,
Vol. 32: No.1 2010
[27] D.Sumner, Two circularcylinders in cross-flow: A review, Journal of Fluids and Structures, Vol. 26,
Issue 6 2010
[28] K.D. Squires et al, LES and DES Investigations of Turbulent Flow Over a Sphere at Re = 1000,
Flow, Turbulence and Combustion 70: 267-298, 2003.
[29] K.D. Squires et al, LES and DES Investigations of Turbulent Flow Over a Sphere, AIAA 2000-0540.
[30] D.A. Jones & D.B. Clarke, Simulation of Flow Past a Sphere Using the Fluent Code, Maritime
Platforms Division, DSTO Defence Science and Technology Organisation, May 2008.
[31] E.Achenbach, Experiments of the flow past spheres at very high Reynolds numbers, Journal of Fluid
Mechanics, Vol. 6, Part 3 (1972)
[32] D.A. Jones, B. Anderson, M. Chapuis, C. Fureby, M. Liefvendah, D. Norrison, C. Troeng and R.
Widjaja RANS simulations using OpenFOAM software, Maritime Platforms Division, DSTO Defence
Science and Technology Organisation, (in progress 2012).
[33] OpenFOAM Foundation, The Open source CFD toolbox http://www.openfoam.com/, last revised
September 12, 2012
[34] ParaView, http://www.paraview.org/ Last revised September 20, 2012

[35] Unknown author, http://openfoamwiki.net/index.php/IcoFoam Last revised November 24, 2009
[36] Unknown author http://openfoamwiki.net/index.php/The SIMPLE algorithm in OpenFOAM Last
revised March 3, 2010
[37] OpenFOAM Foundation http://www.openfoam.org/docs/user/blockMesh.php Copyright 2012
[38] OpenFOAM Foundation http://www.openfoam.org/docs/user/snappyHexMesh.php Copyright 2012

[39] H. Schlichting, Boundary Layer Theory, McGraw-hill Book Co., 1960
[40] T.V.S. Sekhar, R. Sivakumar, S. Vimala, On the effective control of flow separation around a sphere
at low magnetic Reynolds number, 4th International Conference on Fluid Mechanics and Fluid Power.
[41] W.J.Rider, F.Grinstein, http://www.scholarpedia.org/article/Turbulence: Monotone-

Integrated and Implicit Large-Eddy Simulation Last revised September 10, 2010
[42] Unknown author, http://www.cfd-online.com/Wiki/Turbulence free-stream boundary conditions
Last revised June 20, 2011
[43] Unknown author, http://www.cfd-online.com/Wiki/Turbulence intensity Last revised January 3,

2012
[44] Unknown author, http://www.cfd-online.com/Wiki/Turbulent length scale Last revised June 15,
2012
CP-AOO-123 39
A Residual plots
Figure 33: Velocity residuals for k − ωSST at Re = 1 million
Figure 34: Velocity residuals for k − at Re = 1 million
CP-AOO-123 40
Figure 35: Velocity residuals for k − ωSST at Re = 300,000
Figure 36: Velocity residuals for k − at Re = 300,000
CP-AOO-123 41
B snappyHexMesh
B.1 Fundamentals and activation
snappyHexMesh is an unstructured hexagonal mesh that conforms to the geometry supplied in stere-
olithography (STL) format. The mesh approximately conforms to the surface by iteratively refining a
blockMesh mesh into a castellated mesh according to the surface geometry. The second phase morphs
nodes onto the surface to improve mesh smoothness and reduce jagged edges in the mesh. The third
optional phase compresses the surface layers back and adds additional hexahedral refinement layers at
the specified patch surface. The controls for each of these operations and their effects are explained in
greater depth in later sections.
The three primary controls are castellatedMesh, snap and doLayers. Setting these controls to true creates
the broken down mesh, enforces the snap to the surface to remove jagged edges and adds refinement layers
respectively. Setting these to false will turn off any of the selected operations reducing mesh quality but
also reducing processing time.
Since the snappyHexMesh executes from a blockMesh file the quality of the starting mesh is important.
Forums on OpenFOAM suggest the original mesh should have an aspect ratio of as close to 1 as possible
to ensure a quality mesh. This is to allow the final mesh an aspect ratio as close to 1 as possible, though
simulations in the past have clearly demonstrated simpleFoam has some degree of immunity to high
aspect ratios (ratios up 1000 acceptable).
B.2 geometry
In high speed flow regions or regions of potential separation additional refinement is required to ad-
equately resolve and visualise the flow. There are two primary commands that can create regions of
refinement; searchableBox and searchableSphere. These are user defined regions and are added in the
geometry subdictionary with the .stl file as follows.
geometry
{
sphere.stl // STL filename
{
type triSurfaceMesh;
sphere; // user defined surface name
}
refinementBox // User defined region name

{
type searchableBox; // region defined by bounding box
min (1.5 1 -0.5);
max (3.5 2 0.5);
}
refinementSphere // User defined region name

{
type searchableSphere; // region defined by bounding sphere
centre (1.5 1.5 1.5);
radius 1;
}
}
CP-AOO-123 42
B.3 castellatedMeshControls
There are a variety of controls within the castellated mesh subdictionary that allow for optimisation of
the initial mesh.
Keyword Description Example

locationInMesh Define meshed region (5.1 0 0)
maxLocalCells Max number of cells per processor 1.00E+06
maxGlobalCells Overall cell limit 2.00E+06
minRefinementCells Defines refinement 0 (maximum refinement)
nCellsBetweenLevels Number of buffer layers 6
resolveFeatureAngle Gives detail to edges 30
refinementSurfaces Dictionary of surfaces for refinement
refinementRegions Dictionary of regions for refinement
B.3.1 Basic controls

locationInMesh defines a point that is external to the geometry and within the region that defines the
mesh to inform the program which area is to be meshed. It is important to not let this be on a vertex of
the original blockMesh and decimals are advised to avoid this.
maxLocalCells and maxGlobalCells define the maximum number of cells that are permitted in the final
mesh. When attempting to create detailed well resolved meshes from a fine original mesh 2E+6 was
found to be insufficient and this threshold may need to be raised for detailed runs.
minRefinementCells states the number of ”unrefined” cells that are permitted when refinement ceases.
This can save time that would otherwise be spent refining a very small number of problem cells. For
maximum refinement setting this feature to 0 ensures all cells are ideally refined reducing the maximum
skewness in mesh statistics.
nCellsBetweenLevels controls the number of buffer layers that are present for every level of refinement
near the geometry surface. In the case of a sphere a value of 1 adds 1 spherical layer of refinement. 6
was used in the following test cases and gives 6 layers.
resolveFeatureAngles allocates more cells to sharp edges, a control that is not particularly relevant for a
sphere or the Joubert hull.
B.3.2 refinementSurfaces
Overall refinement of the mesh is controlled by the refinementSuraces command in the regions subdic-
tionary where larger numbers in the levels definition result in more precise refinement and smaller cells.
refinementSurfaces
{
sphere // user defined file name
{
level (6 6); // default (min max) refinement for whole surface
}
}
B.3.3 refinementRegions
The sections of increased refinement are implemented by calling the user defined region name and stat-
ing the mode (inside, outside or distance) where inside specificies refinement to be performed inside the
CP-AOO-123 43
region, outside refines outside the region and distance performs refinement as a function of distance from
the geometry surface.
refinementRegions
{
refinementBox // user defined region
{
mode inside;
levels ((1.0 4)); // refinement level 4 (1.0 entry ignored for inside mode)
}
}
The refinementBox approach is well suited to a structured rectangular wake region behind a sphere or a
hull, and experimentation has been performed using a spherical refinement region about the sphere.stl
file. While this yielded good refinement and mesh statistics it is not applicable to non-spherical shapes
and as a result layer addition was explored and is detailed later.
B.4 addLayersControls
Since the refinementSphere lacked applicability to non-spherical geometries layer addition was explored
as a method of improving resolution in the inflation layer. addLayersControls is a subdictionary con-
taining all of the relevant controls for refinement and quality. Layer addition works by compressing the
castellated and snapped mesh back as far as is required to accommodate the additional layers and then
iteratively adds the new layers.
Keyword Description Example

relativeSizes Relative to cell size or absolute true/false
layers Patch name and number of layers
expansionRatio Size of layer compared to previous inner layer 1.1
finalLayerThickness Thickness of layer furthest from the wall 0.8
minThickness Minimum thickness of cell layer 0.0001
B.4.1 layers
Definition of the number of layers to be inserted requires the patch name (this file uses the user defined
surface name ‘sphere’) and the number of layers to be added.
layers
{
("sphere.*")
{
nSurfaceLayers 10;
}
}
B.4.2 Basic controls

relativeSizes states whether or not the values given in the following controls are relative to undistorted
cell size or absolute size.
CP-AOO-123 44
expansionRatio defines the size of the layer compared to the adjacent inner layer. Since relativeSizes true
this value is as a proportion of the inner layer’s thickness.
finalLayerThickness defines the thickness of the outer ring of the added layers as a proportion of the first
cell outside the region of additional layers. For equivalent cell sizes this number should be approximately 1.
minThickness sets a size limit on the innermost cell. If this cell is smaller than the limit according to
other values the cell will not be made and the next layer created instead. In order to create maximum
refinement this value is set arbitrarily low.
B.5 Possible problems

B.5.1 Layer addition problems
When additional layers are added the aspect ratio increases significantly. This is due to an effort to re-
solve the boundary layer appropriately and add many layers; this results in extremely thin layers. While
a large aspect ratio can produce logical and accurate results this is a quantity that needs to be watched
when attempting to improve the inflation layer.
A method of decreasing the aspect ratio is to increase the value of the surface refinement levels. While
exploring snappyHexMesh three different quality STL’s were used (2Mb, 46Mb and 148Mb). It was
discovered that low resolution spheres did not support significant layer addition. This is not a problem
that appears to have been encountered by other users on OpenFOAM forums but there is evidently a
correlation based on experience.
STL size (Mb) maximum refinement levels maximum added layers

8 (4 4) 4
46 (5 5) 20
148 (6 6) 30+
When attempting to appropriately define the inflation layer it is important to have a good quality STL
file to ensure maximum refinement on the surface. There appears to be no corresponding increase in
computation time other than the additional time required by the layer addition iterations when a more
refined STL is used.
B.5.2 ASCII and binary problems

Efforts to use binary encoded STL files were unsuccessful, and only ASCII was accepted by the snappy-
HexMesh file. It is not understood why the binary format was not accepted since OpenFOAM advertises
compatability with binary STL files.
B.5.3 Display issues in ParaVIEW

When snappyHexMesh has completed the meshing process and the final result is viewed in ParaVIEW
the mesh appears to be wildly unstructured and chaotic. This caused concern intially but is simply a
visual rendering error, not a problem with the mesh itself. Since the program can only display triangles
any hexagonal cells are represented poorly. Additionally, artefacts appear after the layer addition step
which make the further regions of the mesh appear worse, but are again problems with display rather
than problems with the mesh itself.
CP-AOO-123 45
B.6 snappyHexM esh Conclusions
Geometry can be defined in two ways, and for a sphere or a submarine hull both definitions are required.
The STL surface must be specified and a region (in this instance a rectangle for the wake region) stated
for use in the castellatedMeshControls to create a downstream refinement region. This allows significant
control over the wake region to ensure that all shedding effects can be captured and solved accurately in
high Reynolds flows.
castellatedMeshControls contain four important controls that should be explored and altered to create a
suitable and well resolved mesh. The obvious two are refinementSurfaces and refinementRegions. Though
the effect on y-plus that these controls have is not fully understood there appears to be a relationship
between increased surface refinement and a reduction in the y-plus value. The other two controls that
are not immediately obvious are nCellsBetweenLayers - which creates a buffer zone of n-cells to ‘flesh
out’ the mesh close to the surface and provides a more gradual transition from fine to coarse cells - and
minRefinementCells - which specifies a number of aberrant cells that can be present when mesh refine-
ment ends, with a 0 value indicating maximum refinement and minimum skewness.
When an STL file of appropriate refinement is used addLayersControls gives a significant amount of con-
trol over the inflation layer on a specified surface. An issue that was encountered for some time was the
challenge of appropriately naming the patch surface since STL and patch are defined slightly differently
according to OpenFOAM. The example given in section B.4.1 demonstrates a method of naming the
patch that will be accepted. Increasing the size and refinement of the inflation layer significantly reduces
the maximum skewness within a mesh. Though the reason for this is not fully understood it appears to
be because the added layers are structured layers, whereas the cells that are present at the end of the
snapping phase are both unstructured and distorted (since they were morphed in order to conform to the
surface in the snapping phase).
snappyHexMesh has been proven as a method for creating a refined mesh as shown by the solutions over
a sphere discussed in this paper. Especially at low Reynolds number flows the utility produced an ade-
quately refined mesh to simulate the flow correctly. Even at high Reynolds number flows the solution was
accurate enough to suggest that the mesh was appropriate and the models were in fact poorly modelling
the flow. This cannot be proven without further research however but initial signs are certainly positive.
What became apparent over the course of the project however (when simulations turned to the Joubert
hull) was that certain geometries can be harder to mesh than expected. It was also discovered in the
sphere section that an stl file of inappropriate refinement would not support sufficient layer addition and
there is a suspicion that the current Joubert stl is exhibiting similar problems. The conclusion being that
snappy can be a sensitive utility and may require significant understanding to implement properly.
CP-AOO-123 46
47
Week of: 27/2/2012 5/3/2012 12/3/2012
Submissions
Time estimate (hrs) 10 10 15
Activity OpenFOAM familiarisa- Familiarisation and Open- Preparation for SoW and
tion FOAM tutorials further tutorial problems
Participants Mitch and Ben All All
Outcomes Improved understanding Improved understanding Completed SoW (to best
and some implementation of understanding) and
gained appreciation of
solvers and icoFoam
Week of: 19/3/2012 26/3/2012 2/4/2012
Submissions Scope of Works DSTO presentation
Time estimate (hrs) 15 20 10
Activity Planning future simula- Preparation for progress Brief rest to complete
tions based on SoW and presentation to DSTO other assignments, with
current abilities with soft- some cylinder simulations
ware
Participants All All All
Outcomes Better understanding of Completed a range of Developed inlet and outlet
Design Diary
intended direction (simu- cylinder simulations (sin- conditions, internal field

lation of cylinders at high gle, streamwise double, and initial condition defi-
Re) and far improved abil- offset double) at a range nitions for marginally bet-
ities with OpenFOAM, in- of Re for presentation ter results (by comparison
cluding basic simulations to DSTO to demonstrate to literature)
over a cylinder in laminar learning and results. Ob-
CP-AOO-123
incompressible flow (ico- tained acceptable qualita-
Foam) tive agreement with litera-
ture (including brief lit re-
C
view)
48
9/4/2012 16/4/2012 23/4/2012 30/4/2012
15 12 5 8
Substantial literature re- Refinement of results for Relaxed project week in Additional assignment
view DSTO for purpose of pol- order to consolidate other work due to looming
ished PR1 subjects and complete as- deadline for PR1
signments
All All All All
Having established our in- Since original simulations Slightly better post- Developing a plan for
tended direction (high Re lacked adequate mesh re- processing. Overall, fairly PR1, including structure,
cylinder flow according to finement for accurate so- minor gains over previous desired results, intended
DSTO’s interests) an in- lutions (due to time con- week’s progress outcomes and our conclu-
depth literature review as straints) additional mesh sions so far
performed in depth to refinement was added to
assess turbulence models improve simulation accu-
and the availability of racy. Diminishing returns
comparable data was observed and qual-
itative results improved
marginally
7/5/2012 14/5/2012 21/5/2012 28/5/2012
Progress Report 1 SWOTVAC
15 20 15 -
Begin compilation of data Continue data post- Acting on feedback from Preparation for exams.
and preparation of PR1 processing and prepara- PR1 and continuing with No project work com-
tion of PR1 cylinder simulations pleted
All All All All
Developing a cohesive Finalising post-processing Considering the direction Exam preparation
structure based on results and data interpretation while improving a test-
and findings so far. Post- and writing a report for ing aspects fo the simula-
processing and comparing PR1. Discussion devel- tion. This includes tweak-
to literature was also oped regarding findings ing discretisation, mesh
completed. and suggestions for future refinement and bound-
CP-AOO-123
direction of the project ary conditions for superior
considered. Advice sought agreement with literature.
from supervisor regarding
what direction to take.
49
4/6/2012 11/6/2012 18/6/2012 25/6/2012
Exams Exams
- - 15 20
Priority given to exams Priority given to exams Resuming research after Further investigation of
and performing well in and performing well in exams high Re cylinder flow
them them
All All Ben, Mitchell All
Exams Exams Developing further the Ascertaining the validity
cylinder simulations in of implementing pisoFoam
order to simulate high for the purposes of run-
Reynolds transient flows. ning LES simulations over
Investigation into two a high Re cylinder. Ba-
dimensional time vary- sics of simulation estab-
ing flow using pisoFoam lished, though a great deal
considered. Beginning of further simulation and
research into implement- research required
ing pisoFoam for DSTO’s
applications
2/7/2012 9/7/2012 16/7/2012 23/7/2012
DSTO second meeting University resumes
20 15 10 10
Preparation for second Acting on advice from Learning snappyHexMesh Developing snappy and
meeting with DSTO DSTO utility simpleFoam
All All Tim All
Developing a plan for pre- Having discovered RANS Further experimentation Upon return to uni fur-
senting to DSTO. Sum- simulations to be of and learning of snappy ther exploration was con-
marised progress so far greater interest to DSTO undertaken to determine ducted into the new direc-
and sought their input on exploration of simple- whether this utility is a tion of the project. PR2
direction and interests to Foam was conducted. viable option for DSTO. is approaching and a suc-
further target subsequent Further investigation Current progress suggests cessful result for flow over
investigations of snappyHexMesh for that it can in fact be ap- a sphere is desired by this
creating unstructured plied to the Joubert hull time.
CP-AOO-123
meshes was highlighted for meshing
as an area of interest and
foundations established
here
30/7/2012 6/8/2012 13/8/2012 20/8/2012
Progress Report 2 DSTO third meeting
50
20 20 25 20
Preparing for PR2 presen- Preparing for meeting Changing simulation Queuing and running
tation with DSTO parameters after DSTO sphere simulations with-
meeting out turbulence models
All All All All
Preparation of the PR2 Acting on advice from Having spoken at length In keeping with the al-
report, including a mod- academic examiner mod- with DSTO changes to tered approach from the
erately successful sphere els tweaked slightly and simulations were made DSTo meeting a range
simulation. Boundary sphere simulations quali- and certain simulation ac- of Re (1-1M) simulations
conditions and internal tatively resemble previous curacy checks performed. were run with no turbu-
field working, though research. Quantitative re- Having hopefully isolated lence model using the sim-
meshing lacks refinement sults still appear to be in- the issue simulations can ple algorithm and snappy.
and implementation of accurate however and fur- continue in earnest with This was an exciting but
the turbulence models ther investigation required the intention of having all challenging result and job
possibly incorrect results within a month management on the su-
percomputer took a great
deal of effort
27/8/2012 3/9/2012 10/9/2012 17/9/2012
Informal DSTO meeting Informal DSTO meeting
20 20 25 40
Queuing and running tur- Attempting to mesh and Post-processing of most Finalising post-
bulence model simulations run Joubert hull sphere cases and inter- processing, interpret-
over sphere preting results. Running ing results beginning
aberrant cases reporting
All All All All
By repeating the process Efforts to run the Jou- Ran post-processing on Acting on advice from
from the previous week bert mesh were unsuc- sphere to show to DSTO, DSTO, completing all
and applying simple to cessful. .stl file possibly initial responses seem post-processing, in-
turbulence models a great to blame, and implemen- positive and Joubert hull terpreting results and
deal of additional data tation of snappy proving research abandoned in implications for conclu-
was obtained for k-epsilon difficult. Meeting with favour of more complete sions. Preparation of
and k-omegaSST models DSTO next week to ask results over a sphere. draft report for DSTO
CP-AOO-123
advice and finalise results Some spherical cases had to critique and provide
and interpreting of them problems, these were re- feedback
run on high performance
computer
Week of: 24/9/2012 1/10/2012
Submissions Informal DSTO meeting Final Submission
Time (hrs) 40 unsure
Activity Writing final draft of re- Preparation for endeavour
port and presentation
Participants All All
Outcomes Acting on advice of Work surrounding the fi-
DSTO, minor corrections nal stages of our FYP
made and report struc-
ture finalised including
appendices, references
and all content. Project
completed!
D Case directories
An OpenFOAM case directory is broken into three parts; time-based files, files which inform the constant
aspects of a simulation and the files which state how the simulation run. How this is arranged is apparent
below (Fig.37).
Figure 37: View of case structure of an OpenFOAM directory
CP-AOO-123 51
Contained below are all of the files from the most important simulations. The first is the dual offset
cylinders, the second a RANS simulation at Reynolds number of 1 million with no turbulence model and
the third a RANS simulation with k − ωSST model. The files are arranged in the order seen below, while
files are not shown if they do not apply to a certain case (ie omega does not appear in the cylindrical
simulations):
0
• U
• p
• k
• omega
• nut
• nuTilda
constant
• RASProperties
• transportProperties
• blockMeshDict
system
• controlDict
• decomposeParDict
• fvSchemes
• fvSolution
• forceCoeffs
• snappyHexMeshDict
CP-AOO-123 52
D.1 Dual offset cylinders
D.1.1 0 directory
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0.044 0 0);
boundaryField
{
inletWall
{
type fixedValue;
value uniform (0.044 0 0);
}
outletWall
{
type inletOutlet;
inletValue uniform (0 0 0);
value uniform (0 0 0);
}
// ************************************************************************* //
cylinder1Wall
{
type fixedValue;
}
cylinder2Wall
{
type fixedValue;
}
// ************************************************************************* //
backWall
{
CP-AOO-123 53
type empty;
}
frontWall
{
type empty;
}
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
object p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 2 -2 0 0 0 0];
internalField uniform 0;
boundaryField
{
inletWall
{
type zeroGradient;
}
outletWall
{
type outletInlet;
outletValue uniform 0;
value uniform 0;
}
// ************************************************************************* //
cylinder1Wall
{
type zeroGradient;
}
cylinder2Wall
{
type zeroGradient;
}
CP-AOO-123 54
// ************************************************************************* //
backWall
{
type empty;
}
frontWall
{
type empty;
}
}
// ************************************************************************* //
D.1.2 constant directory
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "constant";
object transportProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
transportModel Newtonian;
nu nu [ 0 2 -1 0 0 0 0 ] 1e-05;
CrossPowerLawCoeffs
{
nu0 nu0 [ 0 2 -1 0 0 0 0 ] 1e-06;
nuInf nuInf [ 0 2 -1 0 0 0 0 ] 1e-06;
m m [ 0 0 1 0 0 0 0 ] 1;
n n [ 0 0 0 0 0 0 0 ] 1;
}
BirdCarreauCoeffs
{
nu0 nu0 [ 0 2 -1 0 0 0 0 ] 1e-06;
nuInf nuInf [ 0 2 -1 0 0 0 0 ] 1e-06;
k k [ 0 0 1 0 0 0 0 ] 0;
n n [ 0 0 0 0 0 0 0 ] 1;
}
// ************************************************************************* //
CP-AOO-123 55
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
convertToMeters 0.1;
// ************************************************************************* //
vertices
(
// ************************************************************************* //
//BACK PLANE
(-10 12.284 0) //0
(-1.4142 12.284 0) //1
(1.4142 12.284 0) //2
(4.7142 12.284 0) //3
(7.5426 12.284 0) //4
(50 12.284 0) //5
(1.4142 6.5562 0) //6
(4.7142 6.5562 0) //7
(7.5426 6.5562 0) //8
(50 6.5562 0) //9
(5.42132 5.8491 0) //10
(6.8355 5.8491 0) //11
(5.42132 4.4349 0) //12
(6.8355 4.4349 0) //13
(1.4142 3.7278 0) //14
(4.7142 3.7278 0) //15
(7.5426 3.7278 0) //16
(50 3.7278 0) //17
(-10 1.4142 0) //18
(-1.4142 1.4142 0) //19
(1.4142 1.4142 0) //20
(4.7142 1.4142 0) //21
(7.5426 1.4142 0) //22
(50 1.4142 0) //23
(-0.7071 0.7071 0) //24
(0.7071 0.7071 0) //25
(0.7071 -0.7071 0) //26
(-0.7071 -0.7071 0) //27
(1.4142 -1.4142 0) //28
(50 -1.4142 0) //29
(-10 -1.4142 0) //30
(-1.4142 -1.4142 0) //31
(-10 -6.1556 0) //32
CP-AOO-123 56
(-1.4142 -6.1556 0) //33
(1.4142 -6.1556 0) //34
(50 -6.1556 0) //35
//FRONT PLANE +36

(-10 12.284 0.1) //0
(-1.4142 12.284 0.1) //1
(1.4142 12.284 0.1) //2
(4.7142 12.284 0.1) //3
(7.5426 12.284 0.1) //4
(50 12.284 0.1) //5
(1.4142 6.5562 0.1) //6
(4.7142 6.5562 0.1) //7
(7.5426 6.5562 0.1) //8
(50 6.5562 0.1) //9
(5.42132 5.8491 0.1) //10
(6.8355 5.8491 0.1) //11
(5.42132 4.4349 0.1) //12
(6.8355 4.4349 0.1) //13
(1.4142 3.7278 0.1) //14
(4.7142 3.7278 0.1) //15
(7.5426 3.7278 0.1) //16
(50 3.7278 0.1) //17
(-10 1.4142 0.1) //18
(-1.4142 1.4142 0.1) //19
(1.4142 1.4142 0.1) //20
(4.7142 1.4142 0.1) //21
(7.5426 1.4142 0.1) //22
(50 1.4142 0.1) //23
(-0.7071 0.7071 0.1) //24
(0.7071 0.7071 0.1) //25
(0.7071 -0.7071 0.1) //26
(-0.7071 -0.7071 0.1) //27
(1.4142 -1.4142 0.1) //28
(50 -1.4142 0.1) //29
(-10 -1.4142 0.1) //30
(-1.4142 -1.4142 0.1) //31
(-10 -6.1556 0.1) //32
(-1.4142 -6.1556 0.1) //33
(1.4142 -6.1556 0.1) //34
(50 -6.1556 0.1) //35
//CORRECTIONS
(-10 6.5562 0) //72
(-10 3.7278 0) //73
(-1.4142 6.5562 0) //74
(-1.4142 3.7278 0) //75
(4.7142 -1.4142 0) //76
(7.5426 -1.4142 0) //77
(4.7142 -6.1556 0) //78
(7.5426 -6.1556 0) //79
(-10 6.5562 0.1) //80

(-10 3.7278 0.1) //81
(-1.4142 6.5562 0.1) //82
(-1.4142 3.7278 0.1) //83
(4.7142 -1.4142 0.1) //84
CP-AOO-123 57
(7.5426 -1.4142 0.1) //85
(4.7142 -6.1556 0.1) //86
(7.5426 -6.1556 0.1) //87
);
// ************************************************************************* //
blocks
(
// ************************************************************************* //
hex (72 74 1 0 80 82 37 36) (40 40 1) simpleGrading (0.2 10 1) //0

hex (74 6 2 1 82 42 38 37) (50 40 1) simpleGrading (1 10 1) //1
hex (32 33 31 30 68 69 67 66) (40 40 1) simpleGrading (0.2 0.1 1) //20
hex (33 34 28 31 69 70 64 67) (50 40 1) simpleGrading (1 0.1 1) //21
);
// ************************************************************************* //
edges
(
// ************************************************************************* //
//CYLINDER1
//INNER
arc 27 24 (-1 0 0)
arc 63 60 (-1 0 0.1)
arc 24 25 (0 1 0)
arc 60 61 (0 1 0.1)
CP-AOO-123 58
arc 25 26 (1 0 0)
arc 61 62 (1 0 0.1)
arc 26 27 (0 -1 0)
arc 62 63 (0 -1 0.1)
//OUTER
arc 31 19 (-2 0 0)
arc 67 55 (-2 0 0.1)
arc 19 20 (0 2 0)
arc 55 56 (0 2 0.1)
arc 20 28 (2 0 0)
arc 56 64 (2 0 0.1)
arc 28 31 (0 -2 0)
arc 64 67 (0 -2 0.1)
//CYLINDER2
//INNER
arc 12 10 (5.1284 5.142 0)
arc 48 46 (5.1284 5.142 0.1)
arc 10 11 (6.1284 6.142 0)

arc 46 47 (6.1284 6.142 0.1)
arc 11 13 (7.1284 5.142 0)

arc 47 49 (7.1284 5.142 0.1)
arc 13 12 (6.1284 4.142 0)

arc 49 48 (6.1284 4.142 0.1)
//OUTER
arc 15 7 (4.1284 5.142 0)
arc 51 43 (4.1284 5.142 0.1)
arc 7 8 (6.1284 7.142 0)

arc 43 44 (6.1284 7.142 0.1)
arc 8 16 (8.1284 5.142 0)

arc 44 52 (8.1284 5.142 0.1)
arc 16 15 (6.1284 3.142 0)

arc 52 51 (6.1284 3.142 0.1)
);
// ************************************************************************* //
boundary
(
// ************************************************************************* //
inletWall
{
type patch;
faces
(
CP-AOO-123 59
(5 4 40 41)
(4 3 39 40)
(3 2 38 39)
(2 1 37 38)
(1 0 36 37)
(0 72 80 36)
(72 73 81 80)
(73 18 54 81)
(18 30 66 54)
(30 32 68 66)
(32 33 69 68)
(33 34 70 69)
(34 78 86 70)
(78 79 87 86)
(79 35 71 87)
);
}
outletWall
{
type inletOutlet;
faces
(
(9 5 41 45)
(17 9 45 53)
(23 17 53 59)
(29 23 59 65)
(35 29 65 71)
);
}
// ************************************************************************* //
cylinder1Wall
{
type wall;
faces
(
(24 25 61 60)
(25 26 62 61)
(26 27 63 62)
(27 24 60 63)
);
}
cylinder2Wall
{
type wall;
faces
(
(10 11 47 46)
(11 13 49 47)
(13 12 48 49)
(12 10 46 48)
);
}
// ************************************************************************* //
CP-AOO-123 60
backWall
{
type empty;
faces
(
(0 1 74 72)
(1 2 6 74)
(2 3 7 6)
(3 4 8 7)
(4 5 9 8)
(6 7 15 14)
(7 10 12 15)
(7 8 11 10)
(11 8 16 13)
(12 13 16 15)
(8 9 17 16)
(14 15 21 20)
(15 16 22 21)
(16 17 23 22)
(18 19 31 30)
(19 24 27 31)
(19 20 25 24)
(25 20 28 26)
(27 26 28 31)
(22 23 29 77)
(30 31 33 32)
(31 28 34 33)
(77 29 35 79)
(74 75 73 72)
(74 6 14 75)
(73 75 19 18)
(75 14 20 19)
(20 21 76 28)
(21 22 77 76)
(28 76 78 34)
(76 77 79 78)
);
}
frontWall
{
type empty;
faces
(
(80 82 37 36)
(82 42 38 37)
(42 43 39 38)
(43 44 40 39)
(44 45 41 40)
(50 51 43 42)
(51 48 46 43)
(46 47 44 43)
(49 52 44 47)
(51 52 49 48)
(52 53 45 44)
(56 57 51 50)
(57 58 52 51)
(58 59 53 52)
CP-AOO-123 61
(66 67 55 54)
(67 63 60 55)
(60 61 56 55)
(62 64 56 61)
(67 64 62 63)
(85 65 59 58)
(68 69 67 66)
(69 70 64 67)
(87 71 65 85)
(81 83 82 80)
(83 50 42 82)
(54 55 83 81)
(55 56 50 83)
(64 84 57 56)
(84 85 58 57)
(70 86 84 64)
(86 87 85 84)
);
}
);
// ************************************************************************* //
mergePatchPairs
(
);
D.1.3 system directory
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
application icoFoam;
startFrom startTime;
startTime 0;
stopAt endTime;
endTime 10000;
CP-AOO-123 62
deltaT 0.01;
writeControl timeStep;
writeInterval 100;
purgeWrite 0;
writeFormat ascii;
writePrecision 6;
writeCompression off;
timeFormat general;
timePrecision 6;
runTimeModifiable true;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object decomposeParDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
numberOfSubdomains 2;
method scotch;
simpleCoeffs
{
n ( 2 2 1 );
delta 0.001;
}
hierarchicalCoeffs
{
n ( 1 1 1 );
delta 0.001;
order xyz;
}
CP-AOO-123 63
manualCoeffs
{
dataFile "";
}
distributed no;
roots ( );
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
ddtSchemes
{
default Euler;
}
gradSchemes
{
default Gauss linear;
grad(p) Gauss linear;
}
divSchemes
{
default none;
div(phi,U) Gauss linear;
}
laplacianSchemes
{
default none;
laplacian(nu,U) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
}
interpolationSchemes
{
default linear;
CP-AOO-123 64
interpolate(HbyA) linear;
}
snGradSchemes
{
default corrected;
}
fluxRequired
{
default no;
p ;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
solvers
{
p
{
solver PCG;
preconditioner DIC;
tolerance 1e-06;
relTol 0;
}
U
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-05;
relTol 0;
}
}
PISO
{
nCorrectors 2;
nNonOrthogonalCorrectors 0;
CP-AOO-123 65
pRefCell 0;
pRefValue 0;
}
// ************************************************************************* //
CP-AOO-123 66
D.2 No turbulence sphere RANS modelling
D.2.1 0 directory
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 -1 0 0 0 0];
boundaryField
{
inletWall
{
type freestream;
freestreamValue $internalField;
}
outletWalls
{
type zeroGradient;
}
"sphere_.*"
{
type fixedValue;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
CP-AOO-123 67
version 2.0;
format ascii;
object p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 2 -2 0 0 0 0];
boundaryField
{
inletWall
{
type zeroGradient;
}
outletWalls
{
type fixedValue;
value $internalField;
}
"sphere_.*"
{
type zeroGradient;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object RASProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
RASModel laminar;
turbulence off;
CP-AOO-123 68
printCoeffs on;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
nu nu [0 2 -1 0 0 0 0] 1.5e-05;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
convertToMeters 1;
vertices
(
(-5 -5 -5)
(-5 -5 5)
(-5 5 5)
(-5 5 -5)
(20 -5 -5)
(20 -5 5)
(20 5 5)
(20 5 -5)
CP-AOO-123 69
);
blocks
(
hex (0 4 7 3 1 5 6 2) (50 20 20) simpleGrading (1 1 1)
);
edges
(
);
boundary
(
inletWall
{
type patch;
faces
(
(0 1 2 3)
(5 6 2 1)
(7 3 2 6)
(7 4 0 3)
(4 5 1 0)
);
}
outletWalls
{
type patch;
faces
(
(7 6 5 4)
);
}
);
mergePatchPairs
(
);
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
CP-AOO-123 70
format ascii;
class dictionary;
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
application simpleFoam;
startFrom latestTime;
startTime 0;
stopAt endTime;
endTime 5000;
deltaT 1;
writeInterval 600;
purgeWrite 0;
writeFormat ascii;
writePrecision 6;
writeCompression compressed;
timeFormat general;
timePrecision 6;
functions
{
#include "forceCoeffs"
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
CP-AOO-123 71
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
method ptscotch;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
ddtSchemes
{
default steadyState;
}
gradSchemes
{
}
divSchemes
{
default none;
div(phi,U) Gauss linearUpwindV grad(U);
div(phi,k) Gauss upwind;
div(phi,omega) Gauss upwind;
div((nuEff*dev(T(grad(U))))) Gauss linear;
}
laplacianSchemes
{
default Gauss linear corrected;
}
{
default linear;
}
snGradSchemes
{
CP-AOO-123 72
default corrected;
}
fluxRequired
{
default no;
p;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
solvers
{
p
{
solver GAMG;
tolerance 1e-15;
relTol 0.1;
smoother GaussSeidel;
nPreSweeps 0;
nPostSweeps 2;
cacheAgglomeration on;
agglomerator faceAreaPair;
nCellsInCoarsestLevel 10;
mergeLevels 1;
}
U
{
solver smoothSolver;
tolerance 1e-15;
relTol 0.01;
nSweeps 1;
}
k
{
tolerance 1e-15;
CP-AOO-123 73
relTol 0.1;
nSweeps 1;
}
omega
{
tolerance 1e-15;
relTol 0.1;
nSweeps 1;
}
}
SIMPLE
{
pRefCell 0;
pRefValue 0;
}
potentialFlow
{
}
relaxationFactors
{
fields
{
p 0.3;
}
equations
{
U 0.7;
k 0.7;
omega 0.7;
}
}
cache
{
grad(U);
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
forces
{
CP-AOO-123 74
type forceCoeffs;
functionObjectLibs ( "libforces.so" );
outputControl timeStep;
outputInterval 1;
patches ( "sphere_.*" );
pName p;
UName U;
rhoName rhoInf; // Indicates incompressible
log true;
rhoInf 1.18; // Redundant for incompressible
liftDir (0 1 0);
dragDir (1 0 0);
CofR (0 0 0); // Axle midpoint on ground
pitchAxis (0 0 0);
magUInf 7.5;
lRef 2; // Wheelbase length
Aref 3.14; // Estimated
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object snappyHexMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
// Which of the steps to run

castellatedMesh true;
snap true;
addLayers true;
// Geometry. Definition of all surfaces. All surfaces are of class

// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
// - to ’snap’ the mesh boundary to the surface
geometry
{
sphere.stl
{
name sphere;
CP-AOO-123 75
}
refinementBox
{
type searchableBox;
min (0 -2 -2);
max (10 2 2);
}
};
// Settings for the castellatedMesh generation.

castellatedMeshControls
{
// Refinement parameters
// ~~~~~~~~~~~~~~~~~~~~~
// If local number of cells is >= maxLocalCells on any processor

// switches from from refinement followed by balancing
// (current method) to (weighted) balancing before refinement.
maxLocalCells 500000;
// Overall cell limit (approximately). Refinement will stop immediately

// upon reaching this number so a refinement level might not complete.
// Note that this is the number of cells before removing the part which
// is not ’visible’ from the keepPoint. The final number of cells might
// actually be a lot less.
maxGlobalCells 10000000;
// The surface refinement loop might spend lots of iterations refining just a
// few cells. This setting will cause refinement to stop if <= minimumRefine
// are selected for refinement. Note: it will at least do one iteration
// (unless the number of cells to refine is 0)
//Pay attention here in order to further refine cells
minRefinementCells 10;
//This is a buffer to help me catch it
// Allow a certain level of imbalance during refining

// (since balancing is quite expensive)
// Expressed as fraction of perfect balance (= overall number of cells /
// nProcs). 0=balance always.
maxLoadUnbalance 0.10;
// Number of buffer layers between different levels.

// 1 means normal 2:1 refinement restriction, larger means slower
// refinement.
nCellsBetweenLevels 10;
// Explicit feature edge refinement
CP-AOO-123 76
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Specifies a level for any cell intersected by its edges.

// This is a featureEdgeMesh, read from constant/triSurface for now.
features
(
//{
// file "someLine.eMesh";
// level 2;
//}
);
// Surface based refinement

// ~~~~~~~~~~~~~~~~~~~~~~~~
// Specifies two levels for every surface. The first is the minimum level,
// every cell intersecting a surface gets refined up to the minimum level.
// The second level is the maximum level. Cells that ’see’ multiple
// intersections where the intersections make an
// angle > resolveFeatureAngle get refined up to the maximum level.
refinementSurfaces
{
sphere
{
// Surface-wise min and max refinement level
level (4 4);
}
}
// Resolve sharp angles

resolveFeatureAngle 30;
// Region-wise refinement
// ~~~~~~~~~~~~~~~~~~~~~~
// Specifies refinement level for cells in relation to a surface. One of

// three modes
// - distance. ’levels’ specifies per distance to the surface the
// wanted refinement level. The distances need to be specified in
// descending order.
// - inside. ’levels’ is only one entry and only the level is used. All
// cells inside the surface get refined up to the level. The surface
// needs to be closed for this to be possible.
// - outside. Same but cells outside.
refinementRegions
{
refinementBox
{
mode inside;
levels ((1.0 3));
}
}
CP-AOO-123 77
// Mesh selection
// ~~~~~~~~~~~~~~
// After refinement patches get added for all refinementSurfaces and

// all cells intersecting the surfaces get put into these patches. The
// section reachable from the locationInMesh is kept.
// NOTE: This point should never be on a face, always inside a cell, even
// after refinement.
locationInMesh (-2.9 0 0);
// Whether any faceZones (as specified in the refinementSurfaces)

// are only on the boundary of corresponding cellZones or also allow
// free-standing zone faces. Not used if there are no faceZones.
allowFreeStandingZoneFaces true;
}
// Settings for the snapping.

snapControls
{
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 5;
//- Relative distance for points to be attracted by surface feature point

// or edge. True distance is this factor times local
// maximum edge length.
tolerance 4.0;
//- Number of mesh displacement relaxation iterations.

nSolveIter 0;
//- Maximum number of snapping relaxation iterations. Should stop

// before upon reaching a correct mesh.
nRelaxIter 5;
//- Highly experimental and wip: number of feature edge snapping

// iterations. Leave out altogether to disable.
// Do not use here since mesh resolution too low and baffles present
//nFeatureSnapIter 10;
}
// Settings for the layer addition.

addLayersControls
{
// Are the thickness parameters below relative to the undistorted
// size of the refined cell outside layer (true) or absolute sizes (false).
relativeSizes true;
// Per final patch (so not geometry!) the layer information

layers
CP-AOO-123 78
{
"sphere.*"
{
nSurfaceLayers 15;
}
}
// Expansion factor for layer mesh

expansionRatio 1.05;
//- Wanted thickness of final added cell layer. If multiple layers

// is the
// thickness of the layer furthest away from the wall.
// Relative to undistorted size of cell outside layer.
// is the thickness of the layer furthest away from the wall.
// See relativeSizes parameter.
finalLayerThickness 0.8;
//- Minimum thickness of cell layer. If for any reason layer

// cannot be above minThickness do not add layer.
minThickness 0.0001;
//- If points get not extruded do nGrow layers of connected faces that are
// also not grown. This helps convergence of the layer addition process
// close to features.
// Note: changed(corrected) w.r.t 17x! (didn’t do anything in 17x)
nGrow 0;
// Advanced settings
//- When not to extrude surface. 0 is flat surface, 90 is when two faces
// make straight angle.
featureAngle 30;

nRelaxIter 3;
// Number of smoothing iterations of surface normals

nSmoothSurfaceNormals 1;
// Number of smoothing iterations of interior mesh movement direction

nSmoothNormals 3;
// Smooth layer thickness over surface patches

nSmoothThickness 10;
// Stop layer growth on highly warped cells

maxFaceThicknessRatio 0.5;
// Reduce layer growth where ratio thickness to medial

// distance is large
maxThicknessToMedialRatio 0.3;
// Angle used to pick up medial axis points

// Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x.
CP-AOO-123 79
minMedianAxisAngle 90;
// Create buffer region for new layer terminations

nBufferCellsNoExtrude 0;
// Overall max number of layer addition iterations. The mesher will exit
// if it reaches this number of iterations; possibly with an illegal
// mesh.
nLayerIter 5000;
}
// Generic mesh quality settings. At any undoable phase these determine

// where to undo.
meshQualityControls
{
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 65;
//- Max skewness allowed. Set to <0 to disable.

maxBoundarySkewness 20;
maxInternalSkewness 4;
//- Max concaveness allowed. Is angle (in degrees) below which concavity
// is allowed. 0 is straight face, <0 would be convex face.
// Set to 180 to disable.
maxConcave 80;
//- Minimum pyramid volume. Is absolute volume of cell pyramid.

// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minVol -1e30;
//- Minimum quality of the tet formed by the face-centre

// and variable base point minimum decomposition triangles and
// the cell centre. This has to be a positive number for tracking
// to work. Set to very negative number (e.g. -1E30) to
// disable.
// <0 = inside out tet,
// 0 = flat tet
// 1 = regular tet
minTetQuality 1e-30;
//- Minimum face area. Set to <0 to disable.

minArea -1;
//- Minimum face twist. Set to <-1 to disable. dot product of face normal
//- and face centre triangles normal
minTwist 0.02;
//- minimum normalised cell determinant

//- 1 = hex, <= 0 = folded or flattened illegal cell
minDeterminant 0.001;
CP-AOO-123 80
//- minFaceWeight (0 -> 0.5)
minFaceWeight 0.02;
//- minVolRatio (0 -> 1)

minVolRatio 0.01;
//must be >0 for Fluent compatibility

minTriangleTwist -1;
// Advanced
//- Number of error distribution iterations

nSmoothScale 4;
//- amount to scale back displacement at error points
errorReduction 0.75;
}
// Advanced
// Flags for optional output

// 0 : only write final meshes
// 1 : write intermediate meshes
// 2 : write volScalarField with cellLevel for postprocessing
// 4 : write current intersections as .obj files
debug 0;
// Merge tolerance. Is fraction of overall bounding box of initial mesh.

// Note: the write tolerance needs to be higher than this.
mergeTolerance 1e-6;
// ************************************************************************* //
CP-AOO-123 81
D.3 k − ωSST case directory
D.3.1 0 directory
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 1 -1 0 0 0 0];
boundaryField
{
inletWall
{
type freestream;
freestreamValue $internalField;
}
outletWalls
{
type zeroGradient;
}
"sphere_.*"
{
type fixedValue;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
CP-AOO-123 82
{
version 2.0;
format ascii;
object p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 2 -2 0 0 0 0];
boundaryField
{
inletWall
{
type zeroGradient;
}
outletWalls
{
type fixedValue;
}
"sphere_.*"
{
type zeroGradient;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
object k;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 2 -2 0 0 0 0];
internalField uniform 0.0021;
boundaryField
{
CP-AOO-123 83
outletWalls
{
type fixedValue;
}
inletWall
{
type fixedValue;
}
"sphere_.*"
{
type fixedValue;
}
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
object omega;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 0 -1 0 0 0 0];
boundaryField
{
outletWalls
{
type fixedValue;
}
inletWall
{
type fixedValue;
}
"sphere_.*"
CP-AOO-123 84
{
type fixedValue;
}
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
object nut;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 2 -1 0 0 0 0];
boundaryField
{
inletWall
{
type calculated;
value uniform 0;
}
outletWalls
{
type calculated;
value uniform 0;
}
"sphere_.*"
{
type nutkWallFunction;
value uniform 0;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
CP-AOO-123 85
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
object nuTilda;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dimensions [0 2 -1 0 0 0 0];
boundaryField
{
inletWall
{
type freestream;
freestreamValue uniform 0.14;
}
outletWalls
{
type freestream;
freestreamValue uniform 0.14;
}
"sphere_.*"
{
type nutkWallFunction;
value uniform 0;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
CP-AOO-123 86
object RASProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
RASModel kOmegaSST;
turbulence on;
printCoeffs on;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
nu nu [0 2 -1 0 0 0 0] 1.5e-05;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
convertToMeters 1;
vertices
(
(-5 -5 -5)
(-5 -5 5)
CP-AOO-123 87
(-5 5 5)
(-5 5 -5)
(20 -5 -5)
(20 -5 5)
(20 5 5)
(20 5 -5)
);
blocks
(
hex (0 4 7 3 1 5 6 2) (55 22 22) simpleGrading (1 1 1)
);
edges
(
);
boundary
(
inletWall
{
type patch;
faces
(
(0 1 2 3)
(5 6 2 1)
(7 3 2 6)
(7 4 0 3)
(4 5 1 0)
);
}
outletWalls
{
type patch;
faces
(
(7 6 5 4)
);
}
);
mergePatchPairs
(
);
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
CP-AOO-123 88
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
application simpleFoam;
startFrom latestTime;
startTime 0;
stopAt endTime;
endTime 5000;
deltaT 1;
writeInterval 600;
purgeWrite 0;
writeFormat ascii;
writePrecision 6;
writeCompression compressed;
timeFormat general;
timePrecision 6;
functions
{
#include "forceCoeffs"
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
CP-AOO-123 89
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
method ptscotch;
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
ddtSchemes
{
default steadyState;
}
gradSchemes
{
}
divSchemes
{
default none;
div(phi,U) Gauss linearUpwindV grad(U);
div(phi,k) Gauss upwind;
div(phi,omega) Gauss upwind;
div((nuEff*dev(T(grad(U))))) Gauss linear;
}
laplacianSchemes
{
default Gauss linear corrected;
}
CP-AOO-123 90
{
default linear;
}
snGradSchemes
{
default corrected;
}
fluxRequired
{
default no;
p;
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
solvers
{
p
{
solver GAMG;
tolerance 1e-15;
relTol 0.1;
nPreSweeps 0;
nPostSweeps 2;
cacheAgglomeration on;
agglomerator faceAreaPair;
nCellsInCoarsestLevel 10;
mergeLevels 1;
}
U
{
tolerance 1e-15;
relTol 0.01;
nSweeps 1;
CP-AOO-123 91
}
k
{
tolerance 1e-15;
relTol 0.1;
nSweeps 1;
}
omega
{
tolerance 1e-15;
relTol 0.1;
nSweeps 1;
}
}
SIMPLE
{
pRefCell 0;
pRefValue 0;
}
potentialFlow
{
}
relaxationFactors
{
fields
{
p 0.3;
}
equations
{
U 0.7;
k 0.7;
omega 0.7;
}
}
cache
{
grad(U);
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
CP-AOO-123 92
\*---------------------------------------------------------------------------*/
forces
{
type forceCoeffs;
functionObjectLibs ( "libforces.so" );
outputControl timeStep;
outputInterval 1;
patches ( "sphere_.*" );
pName p;
UName U;
rhoName rhoInf; // Indicates incompressible
log true;
rhoInf 1.18; // Redundant for incompressible
liftDir (0 1 0);
dragDir (1 0 0);
CofR (0 0 0); // Axle midpoint on ground
pitchAxis (0 0 0);
magUInf 7.5;
lRef 2; // Wheelbase length
Aref 3.14; // Estimated
}
// ************************************************************************* //
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object snappyHexMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
// Which of the steps to run

castellatedMesh true;
snap true;
addLayers true;
// Geometry. Definition of all surfaces. All surfaces are of class

// searchableSurface.
// Surfaces are used
// - to specify refinement for any mesh cell intersecting it
// - to specify refinement for any mesh cell inside/outside/near
CP-AOO-123 93
// - to ’snap’ the mesh boundary to the surface
geometry
{
sphere.stl
{
name sphere;
}
refinementBox
{
type searchableBox;
min (0 -2 -2);
max (10 2 2);
}
};
// Settings for the castellatedMesh generation.

castellatedMeshControls
{
// Refinement parameters
// ~~~~~~~~~~~~~~~~~~~~~
// If local number of cells is >= maxLocalCells on any processor

// switches from from refinement followed by balancing
// (current method) to (weighted) balancing before refinement.
maxLocalCells 500000;
// Overall cell limit (approximately). Refinement will stop immediately

// upon reaching this number so a refinement level might not complete.
// Note that this is the number of cells before removing the part which
// is not ’visible’ from the keepPoint. The final number of cells might
// actually be a lot less.
maxGlobalCells 10000000;
// The surface refinement loop might spend lots of iterations refining just a
// few cells. This setting will cause refinement to stop if <= minimumRefine
// are selected for refinement. Note: it will at least do one iteration
// (unless the number of cells to refine is 0)
//Pay attention here in order to further refine cells
minRefinementCells 10;
//This is a buffer to help me catch it
// Allow a certain level of imbalance during refining

// (since balancing is quite expensive)
// Expressed as fraction of perfect balance (= overall number of cells /
// nProcs). 0=balance always.
maxLoadUnbalance 0.10;
// Number of buffer layers between different levels.
CP-AOO-123 94
// 1 means normal 2:1 refinement restriction, larger means slower
// refinement.
nCellsBetweenLevels 20;
// Explicit feature edge refinement

// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Specifies a level for any cell intersected by its edges.

// This is a featureEdgeMesh, read from constant/triSurface for now.
features
(
//{
// file "someLine.eMesh";
// level 2;
//}
);
// Surface based refinement

// ~~~~~~~~~~~~~~~~~~~~~~~~
// Specifies two levels for every surface. The first is the minimum level,
// every cell intersecting a surface gets refined up to the minimum level.
// The second level is the maximum level. Cells that ’see’ multiple
// intersections where the intersections make an
// angle > resolveFeatureAngle get refined up to the maximum level.
refinementSurfaces
{
sphere
{
// Surface-wise min and max refinement level
level (4 4);
}
}
// Resolve sharp angles

resolveFeatureAngle 30;
// Region-wise refinement
// ~~~~~~~~~~~~~~~~~~~~~~
// Specifies refinement level for cells in relation to a surface. One of

// three modes
// - distance. ’levels’ specifies per distance to the surface the
// wanted refinement level. The distances need to be specified in
// descending order.
// - inside. ’levels’ is only one entry and only the level is used. All
// cells inside the surface get refined up to the level. The surface
// needs to be closed for this to be possible.
// - outside. Same but cells outside.
refinementRegions
CP-AOO-123 95
{
refinementBox
{
mode inside;
levels ((1.0 3));
}
}
// Mesh selection
// ~~~~~~~~~~~~~~
// After refinement patches get added for all refinementSurfaces and

// all cells intersecting the surfaces get put into these patches. The
// section reachable from the locationInMesh is kept.
// NOTE: This point should never be on a face, always inside a cell, even
// after refinement.
locationInMesh (-2.9 0 0);
// Whether any faceZones (as specified in the refinementSurfaces)

// are only on the boundary of corresponding cellZones or also allow
// free-standing zone faces. Not used if there are no faceZones.
allowFreeStandingZoneFaces true;
}
// Settings for the snapping.

snapControls
{
//- Number of patch smoothing iterations before finding correspondence
// to surface
nSmoothPatch 5;
//- Relative distance for points to be attracted by surface feature point

// or edge. True distance is this factor times local
// maximum edge length.
tolerance 4.0;
//- Number of mesh displacement relaxation iterations.

nSolveIter 0;

nRelaxIter 5;
//- Highly experimental and wip: number of feature edge snapping

// iterations. Leave out altogether to disable.
// Do not use here since mesh resolution too low and baffles present
//nFeatureSnapIter 10;
}
// Settings for the layer addition.

addLayersControls
CP-AOO-123 96
{
// Are the thickness parameters below relative to the undistorted
// size of the refined cell outside layer (true) or absolute sizes (false).
relativeSizes false;
// Per final patch (so not geometry!) the layer information

layers
{
"sphere.*"
{
nSurfaceLayers 2;
}
}
// Expansion factor for layer mesh

expansionRatio 1;
//- Wanted thickness of final added cell layer. If multiple layers

// is the
// thickness of the layer furthest away from the wall.
// is the thickness of the layer furthest away from the wall.
// See relativeSizes parameter.
finalLayerThickness 0.01;
//- Minimum thickness of cell layer. If for any reason layer

// cannot be above minThickness do not add layer.
minThickness 0.0001;
//- If points get not extruded do nGrow layers of connected faces that are
// also not grown. This helps convergence of the layer addition process
// close to features.
// Note: changed(corrected) w.r.t 17x! (didn’t do anything in 17x)
nGrow 0;
// Advanced settings
//- When not to extrude surface. 0 is flat surface, 90 is when two faces
// make straight angle.
featureAngle 30;

nRelaxIter 3;
// Number of smoothing iterations of surface normals

nSmoothSurfaceNormals 1;
// Number of smoothing iterations of interior mesh movement direction

nSmoothNormals 3;
// Smooth layer thickness over surface patches

nSmoothThickness 10;
// Stop layer growth on highly warped cells

maxFaceThicknessRatio 0.5;
CP-AOO-123 97
// Reduce layer growth where ratio thickness to medial
// distance is large
maxThicknessToMedialRatio 0.3;
// Angle used to pick up medial axis points

// Note: changed(corrected) w.r.t 17x! 90 degrees corresponds to 130 in 17x.
minMedianAxisAngle 90;
// Create buffer region for new layer terminations

nBufferCellsNoExtrude 0;
// Overall max number of layer addition iterations. The mesher will exit
// if it reaches this number of iterations; possibly with an illegal
// mesh.
nLayerIter 5000;
}
// Generic mesh quality settings. At any undoable phase these determine

// where to undo.
meshQualityControls
{
//- Maximum non-orthogonality allowed. Set to 180 to disable.
maxNonOrtho 65;
//- Max skewness allowed. Set to <0 to disable.

maxBoundarySkewness 20;
maxInternalSkewness 4;
//- Max concaveness allowed. Is angle (in degrees) below which concavity
// is allowed. 0 is straight face, <0 would be convex face.
// Set to 180 to disable.
maxConcave 80;
//- Minimum pyramid volume. Is absolute volume of cell pyramid.

// Set to a sensible fraction of the smallest cell volume expected.
// Set to very negative number (e.g. -1E30) to disable.
minVol -1e30;
//- Minimum quality of the tet formed by the face-centre

// and variable base point minimum decomposition triangles and
// the cell centre. This has to be a positive number for tracking
// to work. Set to very negative number (e.g. -1E30) to
// disable.
// <0 = inside out tet,
// 0 = flat tet
// 1 = regular tet
minTetQuality 1e-30;
//- Minimum face area. Set to <0 to disable.

minArea -1;
//- Minimum face twist. Set to <-1 to disable. dot product of face normal
CP-AOO-123 98
//- and face centre triangles normal
minTwist 0.02;
//- minimum normalised cell determinant

//- 1 = hex, <= 0 = folded or flattened illegal cell
minDeterminant 0.001;
//- minFaceWeight (0 -> 0.5)

minFaceWeight 0.02;
//- minVolRatio (0 -> 1)

minVolRatio 0.01;
//must be >0 for Fluent compatibility

minTriangleTwist -1;
// Advanced
//- Number of error distribution iterations

nSmoothScale 4;
//- amount to scale back displacement at error points
errorReduction 0.75;
}
// Advanced
// Flags for optional output

// 0 : only write final meshes
// 1 : write intermediate meshes
// 2 : write volScalarField with cellLevel for postprocessing
// 4 : write current intersections as .obj files
debug 0;
// Merge tolerance. Is fraction of overall bounding box of initial mesh.

// Note: the write tolerance needs to be higher than this.
mergeTolerance 1e-6;
// ************************************************************************* //
CP-AOO-123 99

Capstone Project: Final Report

Uploaded by

Copyright:

Available Formats

Capstone Project: Final Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capstone Project: Final Report

Uploaded by

Copyright:

Available Formats

Capstone Project

Department of Mechanical Engineering

Project Title: OpenFOAM validation for high Reynolds number flows

Date: 1st October, 2012

Student Workers: Benjamin Hillier, 329147

Academic Supervisor: Professor Andrew Ooi

Academic Examiner: Dr. Jason Monty

Client Organisation: Defence Science and Technology Organisation

External Mentors: Dr. Ronny Widjaja

Version: v5.3.11 Final, 1st October, 2012

Terminology & Nomenclature

4 Software and utilities 11

6 Flow over a sphere 19

Figure 1: The Joubert submarine hull design.

2.1 The nature of turbulence

Figure 2: Different regions of Reynolds number.

• High diffusivity due to eddying motion.

Figure 5: Reynolds decomposition of velocity.

ui (x, t) = Ui (x) + u0i (x, t) (4)

τij = −u0i u0j (8)

Figure 6: Physical interpretation of terms in the Reynolds stress equations [2].

2.4.1 The Boussinesq approximation

2.4.2 Turbulent kinetic energy

τij = −u0i u0i = −2k (12)

C1 = 1.44, C2 = 1.92, Cµ = 0.09, σk = 1.0, and σ = 1.3 (16)

2.4.4 The Wilcox k − ω model

α = 5/9, β = 3/40 σ = 1/2 (19)

2.4.5 The k − ωSST model

• icoF oam - the standard laminar, incompressible solver

• simpleF oam - a steady state solver of the RANS equations

1. Set the boundary conditions.

4. Solve the pressure equation.

8. Repeat from 3 for the prescribed number of times.

5. Correct the mass fluxes at the cell faces.

5.1 Single cylinder

Figure 10: Final mesh of single cylinder.

5.2 Streamwise dual cylinders

Figure 13: Velocity magnitude for the dual-cylinders in streamwise orientation.

5.3 Offset dual cylinders

6.1 No turbulence model

Figure 17: Computational domain of minimum refinement for laminar cases

Figure 18: Computational domain of maximum refinement for laminar cases

(c) Re = 100, 000

(d) Re = 1, 000, 000

Coarse mesh Fine mesh Extra fine mesh

6.1.5 Coefficient of Pressure, CP

(a) No-turbulence-model Cp simulation results at z = 0. (b) Constantinescu and Squires [28].

Figure 22: Comparison of coefficient of pressure about sphere.

6.1.6 Separation angle

Table 2: Separation angles for a range of Re.

Re θs,lower (◦ ) θs,upper (◦ ) θs,mean (◦ ) Lit. Error (%)

Figure 24: Separation angles of simulation and comparative data.

6.2.1 Mesh generation

Table 3: Turbulent parameters for various Reynolds numbers.

Table 4: Comparison of initial conditions and CD for k-ω model.

(a) Vorticity contours for the k −  model.

(b) Vorticity contours for the k − ωSST model.

Best no-turbulence k− k − ωSST

6.2.6 Coefficient of pressure, CP

C1 = 1.44, C2 = 1.92, Cµ = 0.09, σk = 1.0, and σ = 1.3 (16)

(a) Vorticity contours for the k − model.

Best no-turbulence k− k − ωSST

Figure 29: Shear stress for the k − and k − ωSST models.

Figure 34: Velocity residuals for k − at Re = 1 million

Figure 36: Velocity residuals for k − at Re = 300,000

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\

/--------------------------------- C++ -----------------------------------\