OpenFoam Tips

Disclaimer
“This offering is not approved or

endorsed by OpenCFD Limited, the
producer of the OpenFOAM software
and owner of the OPENFOAM® and
OpenCFD® trade marks.”
Module'0' 1'
These lectures notes are licensed under the Creative Commons
Attribution-ShareAlike 4.0 International License.
To view a copy of this license, visit

http://creativecommons.org/licenses/by-sa/4.0/
Module'0' 2'
Introductory OpenFOAM® Course
University of Genoa, DICCA

Dipartimento di Ingegneria Civile, Chimica e Ambientale
Module'0' 3'
Training agenda
Module 0.
•  Training agenda
•  Housekeeping issues
Module 1.
•  Introduction to OpenFOAM®
•  Library organization
•  My first tutorial
Module'0' 4'
Training agenda
Module 2.
•  CFD workflow
•  Geometry generation
•  Getting more productive using a GUI
Module 3.
•  Meshing preliminaries
•  Mesh quality assessment
•  Mesh conversion and manipulation
•  Meshing in OpenFOAM®
•  Meshing with cfMesh
•  Meshing with open-source tools
Module'0' 5'
Training agenda
Module 4.
•  Scientific visualization
•  Post-processing and plotting
•  Co-processing
•  Scripting
•  Data analytics
Module 5.
•  Running in parallel
•  GPU
Module'0' 6'
Training agenda
Module 6.
•  The finite volume method. A crash introduction
•  On the CFL number
•  Boundary conditions and initial conditions
•  Unsteady and steady simulations
•  Assessing convergence
Module'0' 7'
Training agenda
Module 7.
•  Programming in OpenFOAM® - Building blocks
•  Programming in OpenFOAM® - Implementing boundary
conditions and applications
•  Implementing boundary conditions using swak4foam
•  Field initialization using swak4foam
Module'0' 8'
Training agenda
Module 8.
•  Advanced modeling capabilities:
•  Turbulence modeling
•  Multiphase flows
•  Source terms
•  Heat-transfer and conjugate heat transfer
•  Discrete particle modeling
•  Moving reference frames and sliding grids
•  Moving bodies and rigid body motion
Module'0' 9'
Training agenda
Module 9.
•  Tips and tricks
Module 10.
•  Conclusions and wrap-up session
Module'0' 10'
The Team
Joel GUERRERO
joel.guerrero@unige.it
'
'
guerrero@wolfdynamics.com'
Module'0' 11'
The Team
Damiano NATALI
damiano.natali@unige.it
'
'
natali@wolfdynamics.com '
Module'0' 12'
Before we begin
Housekeeping issues
Module"0" 1"
Before we begin
Who does not have a working installation of
OpenFOAM®?
•  And I hope not to see hands up.
Module"0" 2"
Before we begin
What about your OpenFOAM® skills?
•  Totally new.
•  Beginner.
•  Intermediate.
•  Advanced.
•  Guru.
Module"0" 3"
Before we begin
Any clue on the FVM, CFD, multi-physics
simulations, scientific computing, or numerical
methods?
•  Not a clue.
•  I know two or three things.
•  Snug as a bug in a rug.
•  Guitar hero.
Module"0" 4"
Before we begin
You are in Linux, you see this nice window that
everybody calls terminal. Now what?
Module"0" 5"
Before we begin
How confortable are you with Linux?
•  If you are new to Linux, do not worry, we are going to give you a crash
introduction to the basic Linux commands.
•  Also, if you installed our Linux version, we are going to show how to use
it and what applications are installed.
Module"0" 6"
Afternoon Session Morning Session
(1:30 pm – 4:30 pm) (9:00 am – 12:30 am)
• Running my first OpenFOAM® case. • Before we start - Housekeeping issues.

• Setting cases in OpenFOAM®. Choosing • Introduction - Overview of OpenFOAM®.
boundary conditions, initial conditions, and • Physical models, solvers and utilities.
physical models. • Library organization and code structure.
• Selecting solver parameters. • Running my first OpenFOAM® case.
Day 1
• Controlling solution behavior and solution • Introduction to post-processing and scientific

monitoring. visualization with paraFoam.
• CFD simulation lifecycle.

• Scientific visualization using paraFoam. • Finite Volume Discretization: theoretical
• Sampling, function objects and co-processing in background.
OpenFOAM®. • Meshing preliminaries.
• Assessing mesh quality. • Running in parallel.
• Mesh generation with OpenFOAM®. • How to choose the right numerics.
Day 2
Introduction to blockMesh and snappyHexMesh. • Getting convergence from scratch.

• Hands-on tutorials. • Hans-on tutorials.
• More on geometry generation, mesh generation, • Advanced mesh generation with blockMesh and
and post-processing using Open Source tools. snappyHexMesh.
• Advanced post-processing with paraview and • Geometry generation, mesh generation and
visit. post-processing using Open Source tools.
The above outline is a guide only and every attempt will beModule"0"
• How to setup a case from scratch using • Python scripting and automation.
Day 3
Helyx-os gui. • Hands-on tutorials.
(4:30 pm – 5:00 pm)

• Hands-on tutorials.
• Basics of C++ programming.

• Extending OpenFOAM® capabilities. • Programming in OpenFOAM®: building blocks.
• OpenFOAM® extended project. • OpenFOAM solvers: brief overview and
• Advanced physical modeling capabilities. walkthrough.
• Moving bodies, sliding grids and MRF. • Modifying OpenFOAM® solvers, utilities and
• Turbulence modeling (RANS and LES). boundary conditions.
Day 4
Tips and tricks. • OpenFOAM® documentation.

Before we begin
•
• Hands-on tutorials. • Implementing boundary and initial conditions
End of the day. Last minute issues and additional questions.
using external libraries.

Provisional timetable
• Numerical optimization and design of

experiments: theoretical background.
• Coupling Dakota with OpenFOAM®.
• Wrap-up session.
• Running parametric studies, optimization
• Open Forum: Questions, doubts and attendees
studies and DACE experiments using Dakota.
own cases.
Day 5
• Surrogate based optimization for engineering

design.
• Hands-on tutorials.
7" made to adjust the course content to suit the needs of the attendees
Before we begin
Linux for open source CFD
Module"0" 8"
Before we begin
•  First at all and in order to avoid compatibility issues during the course, I
highly advise you to install our custom made Linux version. You can find it in
the following:
https://susestudio.com/a/XrxjaO/joel-s-opensuse-13-2-kde-4-desktop
•  A virtual machine distribution and an ISO distribution are available for

download.
•  In the provided USB key you will find the virtual machine distribution.
•  I also remind you that it is a fully working Linux OpenSUSE 13.2 version
(with KDE 4), that you can modify or upgrade to fit your needs.
•  So if you do not like KDE, you can install Gnome or whatever you want to
use.
Module"0" 9"
Before we begin
•  This Linux version was created with CFD applications in mind for CFD
users. It comes with many CFD, CAD, mesh generation, visualization,
numerical libraries, optimization, plotting applications and editing utilities pre-
installed. It also comes with all the compilers and libraries necessary to
compile most of the applications.
•  In the version available for download you have all the applications necessary
for this course.
•  By the way, in my personal copy I have many multi-physics, CFD, FEA,

CAD, multibody dynamics, visualization, numerical libraries, meshing,
scientific computing, python and developing applications installed.
Module"0" 10"
Before we begin
•  FYI, I regularly update the distributions.
•  The OpenFOAM® version installed is 2.3.x, which you can update by using
the Git revision control system.
Module"0" 11"
Before we begin
Training material
Module"0" 12"
Before we begin
Training material
•  In the USB key you will also find all the training material (tutorials, slides,
quick reference guides, OpenFOAM® user guide, OpenFOAM®
programmers manual, and lectures notes).
•  You can extract the training material wherever you want. However, I highly
recommend you to extract all the training material in your OpenFOAM® user
directory. From now on, this directory will become
•  $PTOFC
(abbreviation of path to OpenFOAM® course).
•  You can add this alias to your .bashrc file by adding the following line,
•  alias PTOFC='cd $PATH_TO_TUTORIALS'
Module"0" 13"
Before we begin
Training material
•  By the way, to uncompress the tutorials go to the directory where you copied
the training material and then type in the terminal,
•  tar –zxvf file_name.tar.gz
•  On the other side, if you are interested in compressing a directory, you can
proceed as follows,
•  tar –zcvf file_name.tar.gz directory_name
Module"0" 14"
Before we begin
•  By the way, use the tutorials included in the training

material just for recreational, instructional, or learning
purposes and not for validation, benchmarking or
standard practices.
Module"0" 15"
Before we begin
Installing OpenFOAM® - Working on your own
Module"0" 16"
Before we begin
Installing OpenFOAM® - Working on your own
•  If for any reason you do not want to use our Linux version, you are free
to install any Linux version you like.
•  FYI, I do not like Ubuntu.
•  To install OpenFOAM®, just follow the instructions given in

http://www.openfoam.org/
•  If for any reason the instructions given in http://www.openfoam.org/ do

not work for you, you can use my instructions. They work fine with Linux
OpenSUSE 12.1 or newer versions.
•  You can find my instructions in the supplement slides.
•  My instructions are exactly the same as the one you will find in
http://www.openfoam.org/, I only added a few tips and comments.
Module"0" 17"
Before we begin
Additional Tools
As we will be working with the CFD simulation

lifecycle (from geometry generation, to mesh
generation, to governing equations solution, to
post-processing) by using open source tools,
the following additional tools might come in
handy:
Module"0" 18"
Before we begin
For geometry generation, mesh generation, and visualization, the following open source
applications might come in handy:
CAD - 3D modeling - Surface modeling

•  Salome (http://www.salome-platform.org/). *
•  Google SketchUp (http://sketchup.google.com/). **
•  pythonOCC (http://www.pythonocc.org/). *
•  Blender (http://www.blender.org/). *
•  Openscad (http://www.openscad.org/). *
•  OpenVSP (http://www.openvsp.org/). *
* Note: precompiled binaries are available for these applications.

** Note: it is possible to install Google SketchUp in linux by using wine
(http://www.winehq.org/).
Module"0" 19"
Before we begin
Mesh Generation
•  Salome (http://www.salome-platform.org/). *
•  Engrid (http://engits.eu/en/engrid). *
•  GMSH (http://www.geuz.org/gmsh/). *
•  Triangle (http://www.cs.cmu.edu/~quake/triangle.html).
•  Tetgen (http://tetgen.berlios.de/).
•  cfMesh " "(http://www.c-fields.com/).
•  Overture (http://www.overtureframework.org/).
Module"0" 20"
Before we begin
Mesh manipulation tools

•  Mesquite (http://trilinos.sandia.gov/packages/mesquite/index.html).
•  Stellar (http://www.cs.berkeley.edu/~jrs/stellar/).
•  Pyramid (http://www.openchannelsoftware.org/projects/Pyramid).
•  MSTK/Mesh tools (https://software.lanl.gov/MeshTools/trac).
•  Meshkit (http://press3.mcs.anl.gov/sigma/meshkit-library/).
Module"0" 21"
Before we begin
Visualization
•  Visit (https://wci.llnl.gov/codes/visit/). *
•  Paraview (http://www.paraview.org/). *
•  Mayavi (http://code.enthought.com/projects/mayavi/) . *
Module"0" 22"
Before we begin
STL files manipulation

•  Meshlab (http://meshlab.sourceforge.net/).
•  Netfabb (Freeware) (http://www.netfabb.com/). *
•  ADMESH (http://www.varlog.com/admesh-htm).
Module"0" 23"
Before we begin
OpenFOAM® GUI
•  Helyx-os (http://engys.com/products/helyx-os).
Note: precompiled binaries are available for these applications.
Module"0" 24"
Before we begin
And of course we will need,
OpenFOAM® solver
•  OpenFOAM® (http://www.openfoam.org/).
Module"0" 25"
Before we begin
Also, the following OpenFOAM® utilities might come in handy
OpenFOAM® utilities
•  PyFoam (http://openfoamwiki.net/index.php/Contrib_PyFoam).
•  swak4foam (http://openfoamwiki.net/index.php/Contrib/swak4Foam).
•  setDiscreteFields (http://openfoamwiki.net/index.php/Contrib_setDiscreteFields).
Module"0" 26"
Before we begin
Additionally, to deal with numerical optimization the following applications might come in
handy
Optimization Frameworks
•  DAKOTA (http://dakota.sandia.gov/).
•  OpenMDAO (http://www.openmdao.org/).
Module"0" 27"
Before we begin
By the way, you do not need to install all these tools. These are tools that I often use or
I feel confortable with.
If you want to keep things to a minimum, install only:

•  Salome
•  Paraview (in addition to the paraview version distributed with OpenFOAM®)
•  Helyx-os
•  OpenFOAM®
•  DAKOTA
•  swak4foam
•  PyFoam
Module"0" 28"
Course objectives
Introduce the CFD simulation lifecycle by using
open source tools.
“From geometry generation, to mesh generation, to
governing equations solution, to post-processing”.
Geometry description
Mesh generation
Visualization
Module"0" 29"
Course objectives
•  Introduce OpenFOAM® (this is the workhorse of the course).
•  By the end of the week, help you to become an out-of-the-box

user of OpenFOAM®.
•  But also, introduce you the building blocks to help you to

become an OpenFOAM® user at a developer level.""
•  By friday, you should also be able to make simple modifications

to OpenFOAM® solvers and utilities, and to explore the source
code to learn more about the library.
Module"0" 30"
Course objectives
•  Introduce you to CAD, meshing and post processing using

open source tools, and how to use these tools together with
OpenFOAM®
•  Demystify the FVM in order to teach you how to choose the

right numerics.
•  Give you some guidelines of how to assess mesh quality, and

how to avoid or reduce mesh induce errors.
•  Do some post-processing and data analysis to get quantitative

and qualitative results, and use this information to take
decisions.
Module"0" 31"
Course objectives
•  Address your doubts about the tools used and methods

involved.
•  Not to confuse you at a higher level.
•  Help you to get a degree?.
Module"0" 32"
Prerequisites
•  No prior knowledge of the tools to be used (OpenFOAM®,

Salome, Dakota and so on), C++ or Linux is required, but a
basic knowledge of Linux is beneficial.
•  A basic knowledge of CFD, scientific computing, and numerical

optimization is also desirable.
•  For hands-on examples, you are required to bring your own

laptop with a working installation of Linux and OpenFOAM®
(version 2.3.0 or 2.3.x preferable).
•  By the way, I use OpenSUSE Linux distribution. But you are

free to install any Linux distribution.
Module"0" 33"
What I will try to keep to a minimum
•  This is not a C++ course, so I will try to keep C++ programming

to a minimum.
•  This is not a course on Finite Volume Methods (FVM) -

Computational Fluid Dynamics (CFD), so I will keep the theory
to a minimum.
•  This is not a Linux system administration course, so I will try to

keep Linux system administration issues to a minimum.
•  I am doing this for your own convenience and keeping things

easy. Remember, after all this is an introductory course.
Module"0" 34"
What I need from you
•  Ask as many questions as you like and feel free to interrupt me

at anytime.
•  Helps me understand what you are missing.
•  Helps you clarify misunderstandings.
•  Helps others with the same question.
Module"0" 35"
•  Sometimes I have the tendency to go really fast in some issues,

please stop me if you are not following me.
•  Tell me if you do not understand.
•  Tell me if an example does not work.
•  Let me know if you have any specific requirement.
Module"0" 36"
•  If you have a case of your own, let me know and I will try to do
my best to help you to setup your case. But remember,
the physics is yours.
Module"0" 37"
•  Based on this course, I am trying to write some lectures notes

on CFD and related topics, they are far from being complete
but you can take a look at them.
•  A help is needed and much appreciated. To help me, take a

look at the lectures notes and let me know if you find errors.
Suggestions for better wording, figures or new material are also
welcome.
•  The lectures notes are available with the course’s material in

the USB key.
•  Follow-up problems, questions and suggestions at

joel.guerrero@unige.it.
Module"0" 38"
What about OpenFOAM® documentation?
•  OpenFOAM® comes with many very powerful

features but they hard to use and not very well
documented.
•  In general, the learning curve is steep.
•  If you are new to the Linux world, it can be even
more challenging and this in fact makes the learning
curve steeper.
Module"0" 39"
•  OpenFOAM® comes with an user guide and

programmer’s guide.
•  At a first glance, you will have the impression that the
user and programmer’s guide do not provide much
details.
•  But before complaining about the lack of
documentation,
Module"0" 40"
… read carefully and digest all the information

contained in the user guide and programmer’s
guide.
It might not be much, but it is enough to get you

started.
FYI, most of this training is based on the user

guide and programmer’s guide.
Module"0" 41"
Remember,
You have the source code so take

some time and explore it.
Module"0" 42"
How to learn more about OpenFOAM®
•  Read the user and programmer’s guide.

•  Explore the source code and doxygen documentation
(OpenFOAM® C++ documentation)
•  Get familiar with all the applications and utilities
available by doing all the tutorials available in the
OpenFOAM® installation (or at least those that
interest you), and dig into each one to learn more
about all features available.
Module"0" 43"
•  Also, with the course material you will find many

tutorials which are different from those that come with
the OpenFOAM® installation. Try to go through each
one to understand and get functional using
OpenFOAM®.
•  In each tutorial folder there is a README.FIRST file.
In this file you will find general comments and the
instructions of how to run the case.
•  Let me know if a tutorial does not work or is outdated.
It is a difficult task to maintain all these tutorials.
Module"0" 44"
•  By the way, use the tutorials just for recreational,

instructional, or learning purposes and not for
validation or benchmarking.
Module"0" 45"
10 steps to get functional with OpenFOAM®
•  Learn by doing.
•  Learn from an OpenFOAM® case or course tutorial.
•  Try to change the case and study the outcome.
•  Introduce errors in the case and try to understand OpenFOAM® output.
•  Make a totally different case using the same solver.
•  Learning C++ is extremely beneficial.
•  Learning Python will not hurt you, specially for data analytics
•  Understand the solver. For this you will need some C++ skills and finite
volume method theoretical background.
•  Top level development, make your own solver or modify and existing
one and setup the case.
•  Try to do some debugging and profiling. For profiling you can use
Valgrind, it is an amazing tool.
•  Very important, understand the theory.
Module"0" 46"
Useful links
•  User manual, programmer manual and source code.
•  The Doxygen manual

(http://www.openfoam.org/docs/cpp/).
•  CFD-Online OpenFOAM® user discussion group

(http://www.cfd-online.com/Forums/openfoam/).
•  OpenFOAM® wiki (http://www.openfoamwiki.net).
•  OpenFOAM® website (http://www.openfoam.com/).
•  OpenFOAM® extend project

(http://www.extend-project.de).
Module"0" 47"
CFD/FVM/C++ Bibliographical references
•  Numerical Heat Transfer and Fluid Flow.
S. Patankar. 1980, Taylor & Francis
•  An Introduction to Computational Fluid Dynamics.
H. K. Versteeg, W. Malalasekera. 2007, Prentice Hall.
•  Computational Methods for Fluid Dynamics.
J. H. Ferziger, M. Peric. 2001, Springer.
•  Computational Fluid Dynamics: Principles and Applications.
J. Blazek. 2006, Elsevier Science.
•  Computational Techniques for Multiphase Flows
G. H. Yeoh, J. Tu. 2009, Butterworth-Heinemann
•  Turbulence Modeling for CFD
D. Wilcox. 2006, DCW Industries.
•  A Finite Volume Method for the Prediction of Three-Dimensional Fluid Flow in Complex
Ducts.
M. Peric. PhD Thesis. 1985. Imperial College, London.
•  Error analysis and estimation in the Finite Volume method with applications to fluid
flows.
H. Jasak. PhD Thesis. 1996. Imperial College, London.
•  Computational fluid dynamics of dispersed two-phase flows at high phase fractions
H. Rusche. PhD Thesis. 2002. Imperial College, London.
Module"0" 48"
CFD/FVM/C++ Bibliographical references
•  The C++ Programming Language.
B. Stroustrup. 2013, Addison-Wesley.
•  The C++ Standard Library.
N. Josuttis. 2012, Addison-Wesley.
•  C++ for Engineers and Scientists.
G. J. Bronson. 2012, Cengage Learning.
•  Sams Teach Yourself C++ in One Hour a Day.
J. Liberty, B. Jones. 2004, Sams Publishing.
•  C++ Primer.
S. Lippman, J. Lajoie, B. Moo. 2012, Addison-Wesley.
•  http://www.cplusplus.com/
•  http://stackoverflow.com/
Module"0" 49"
Module 1
Module'1')'Lecture'1' 1'
Today’s lecture
1.  OpenFOAM® brief overview
OpenFOAM® brief overview
General description:
•  OpenFOAM® stands for Open Source Field Operation and
Manipulation.
•  OpenFOAM® is first and foremost a C++ library used to solve

partial differential equations (PDEs), and ordinary differential
equations (ODEs).
•  It comes with several ready-to-use or out-of-the-box solvers,

pre-processing utilities and post-processing utilities.
•  It is licensed under the GNU General Public License (GPL).

That means it is freely available and distributed with the source
code.
•  It can be used in massively parallel computers. No need to pay
for separate licenses.
•  It is under active development, its capabilities mirror those of

commercial CFD applications.
•  It counts with a wide-spread community around the world

(industry, academia and research labs).
•  It has extensive multi-physics capabilities:
•  Computational fluid dynamics.
•  Heat transfer and conjugate heat transfer.
•  Combustion and chemical reactions.
•  Multiphase flows and mass transfer.
•  Stress analysis and fluid-structure interaction.
•  Particle methods (DEM, DSMC, MD) and lagragian particles
tracking.
•  Dynamic mesh handling, 6 DOF solvers, and adaptive mesh
refinement.
•  Computational aero-acoustics, computational
electromagnetics, computational
Module'1')'Lecture'1'
solid mechanics, etc. 5'
Brief overview – Description and implementation:
•  Finite Volume Method (FVM) based solver.
•  Collocated polyhedral unstructured meshes.
•  Second order accuracy in space and time. Many discretization

schemes available (including high order methods).
•  Pressure-velocity coupling via segregated methods (SIMPLE

and PISO).
•  But also coupled solvers are under active development.
Brief overview – Description and implementation:
•  Massive parallelism through domain decomposition.
•  It comes with it own mesh generation tools.
•  It also comes with many mesh manipulation and conversion

utilities.
•  Meshes generated using many of the major mesh generators

can be converted to OpenFOAM® format.
•  All components implemented in library form for easy re-use.
Brief overview – Physical models:
•  Physical modeling library:
•  Thermophysical models and physical properties for liquids

and gases.
•  Transport/rheology models. Newtonian and non-Newtonian

viscosity models.
•  Extensive turbulence modeling capabilities (RANS, SRS,

DES and LES).
Brief overview – Physical models:
•  Physical modeling library:
•  Lagragian particle methods (DSMC, MD).
•  Discrete particle modeling (DPM, MP-PIC).
•  VOF method for multiphase flows .
•  Interphase momentum transfer models for multiphase flows.
•  Combustion, flame speed, chemical reactions, porous

media, etc.
Brief overview – Solvers:
•  OpenFOAM® comes with several ready-to-use or out-of-the-
box solvers:
•  Basic solvers: Laplace, potential flow, passive scalar

transport.
•  Incompressible and compressible flows: segregated

pressure-based algorithms (SIMPLE and PISO).
•  Heat transfer modeling capabilities: buoyancy-driven flows,

conjugate heat transfer.
•  OpenFOAM® comes with several ready-to-use or out-of-the-
box solvers:
•  Multiphase flows: Euler-Euler, VOF for free surfaces,

multiple phases, cavitation, phase change.
•  Combustion and fire dynamic solvers.
•  Stress analysis, electromagnetics, acoustics, MHD, fluid-

structure interaction, etc.
•  And if this is not enough for you, you can implement your own
solvers.
•  OpenFOAM® is designed to be a flexible and programmable

environment for numerical simulations by using a high level
programming language that is a direct representation of the
equations being solved.
•  New solvers can be easily implemented using OpenFOAM®

high level programming or equation mimicking, e.g.:
Brief overview – Equation mimicking:
•  The equation,
@⇢U
+r· U r · µrU = rp
@t
can be written in OpenFOAM® as follows,
solve
(
fvm::ddt(rho,U)
+ fvm::div(phi,U)
- fvm::laplacian(mu,U)
==
- fvc::grad(p)
);
Correspondence between the implementation and the original

equation is clear.
Brief overview – Customizing solvers:
•  Equation mimicking syntax, achieved through the use of object
oriented programming, enables users to create custom solvers
with relative ease.
•  Users have total freedom to modify existing solvers or use them

as the starting point for new solvers.
•  Access to complete source: no secret modeling tricks or black

magic.
Brief overview – Customizing solvers:
•  OpenFOAM® design encourages code and libraries re-use.
•  As solvers can be tailored by a user for a specific need,

OpenFOAM® is ideal for research and development.
•  Top level solvers are written in few 100s lines of code, and are
optimized for efficiency.
Brief overview – Core technology:
•  OpenFOAM® is assembled from components: foundations
libraries (vectors and tensors algebra, mesh handling,
discretization, boundary conditions, linear solvers, parallel
computing, etc.), physical modeling libraries, utilities and
solvers.
•  All applications and utilities, are compiled using common

functionality in the collection of libraries distributed with
OpenFOAM®.
Brief overview – Core technology:
•  This ensures consistency across the whole of the OpenFOAM®
distribution, rather than having a suite of packages compiled
from entirely separate source code.
•  Transparent solution algorithms which can be viewed by the

user, encouraging better understanding of the underlying
physics.
OpenFOAM® is an excellent piece of C++

and software engineering. Decent piece of
CFD code.
H. Jasak
Module 1
Today’s lecture
1.  OpenFOAM® directory organization

2.  Directory structure of an application/utility
3.  Applications/utilities in OpenFOAM®
4.  Directory structure of an OpenFOAM® case
Today’s lecture

OpenFOAM® directory organization
$WM_PROJECT_DIR If you installed OpenFOAM® in the default

location, the directory $WM_PROJECT_DIR should
applications be:
bin
$HOME/OpenFOAM/OpenFOAM-2.3.x
doc
In this directory you will find all the directories
etc containing OpenFOAM® installation. In this
directory you will also find additional files (such as
platforms
README.org, COPYING, etc.), but the most
src important one is Allwmake, which compiles
OpenFOAM®.
tutorials
wmake Typing wcleanAll will search all the directories

below the current one and will delete all the
Allwmake compiled files. So if you type wcleanAll in
Additional
$WM_PROJECT_DIR, it will delete all the compiled
files files in your OpenFOAM® installation.
$WM_PROJECT_DIR
applications By the way, as I use OpenFOAM® version 2.3.x,

the environment variable $WM_PROJECT_DIR
bin points to:
doc
etc
platforms
If you use OpenFOAM® version 2.3.0, the
src environment variable $WM_PROJECT_DIR will
point to
tutorials
wmake $HOME/OpenFOAM/OpenFOAM-2.3.0
Allwmake
Additional
files
$WM_PROJECT_DIR
OpenFOAM® environment variables
applications
bin The entries starting with the symbol $ are

environment variables. You can find out the value
doc of an environment variable by echoing its value,
etc for example:
platforms
echo $WM_PROJECT_DIR
src
tutorials will give you the following output on the terminal

wmake
Allwmake
To see all the environment variables type env.
Additional
files
$WM_PROJECT_DIR
OpenFOAM® aliases
applications
bin By the way, you can go to any of these directories

by using the predefined aliases set by
doc OpenFOAM® (see $WM_PROJECT_DIR/etc/
etc config/alias.sh). For example:
platforms
alias foam='cd $WM_PROJECT_DIR'
src alias app='cd $FOAM_APP'
tutorials alias src='cd $FOAM_SRC'
alias tut='cd $FOAM_TUTORIALS’
wmake
Allwmake
For a complete list type alias in the terminal.
Additional
files
Let us now study the applications directory
$WM_PROJECT_DIR
applications
solvers
test
utilities
Let us visit applications directory. Type in the terminal app or

cd $WM_PROJECT_DIR/applications. Here you will find the following
sub-directories:
•  solvers, which contains the source code for the distributed solvers.
•  test, which contains the source code of several test cases that show the usage
of some of the OpenFOAM® classes.
•  utilities, which contains the source code for the distributed utilities.
There is also an Allwmake script, which will compile all the content of solvers
and utilities. To compile the test cases in test go to the desired test case
directory and compile it by typing wmake.
Let us now study the bin directory
$WM_PROJECT_DIR
bin
Let us visit the bin directory:

•  The bin directory contains shell scripts, such as paraFoam, foamNew,
foamLog, foamJob, etc.
Let us now study the doc directory
$WM_PROJECT_DIR
doc
Let us visit the doc directory:

•  The doc directory contains the documentation of OpenFOAM®, namely; user
guide, programmer’s guide and Doxygen generated documentation in html format.
•  The Doxygen documentation needs to be compiled by typing Allwmake doc in

$WM_PROJECT_DIR.
•  You can access the Doxygen documentation online,

http://www.openfoam.org/docs/cpp/
$WM_PROJECT_DIR
doc
•  Documentation usage:
acroread $WM_PROJECT_DIR/doc/Guides-a4/UserGuide.pdf
acroread $WM_PROJECT_DIR/doc/Guides-a4/ProgrammersGuide.pdf
firefox file://$WM_PROJECT_DIR/doc/Doxygen/html/index.html
•  Notice that I am using acroread for opening the *.pdf files and firefox for
the *.html files.
Let us now study the etc directory
$WM_PROJECT_DIR
etc
Let us visit the etc directory:

•  The etc directory contains the environment files, global OpenFOAM®
instructions, and the default thermochemical database thermoData/
thermoData.
•  It also contains the super dictionary controlDict, where you can set
several debug flags and the defaults units.
Let us now study the platforms directory
$WM_PROJECT_DIR
platforms
linux64GccDPOpt
bin
lib
Let us visit platforms directory. Type in the terminal

cd $WM_PROJECT_DIR/platforms.
This directory contains the binaries generated when compiling the applications
directory (after compilation the binaries will be located in the directory
$WM_PROJECT_DIR/platforms/linux64GccDPOpt/bin) and the libraries
generated by compiling the source code in the src directory (after compilation, the
libraries will be located in the directory $WM_PROJECT_DIR/platforms/
linux64GccDPOpt/lib).
If you installed OpenFOAM® following the default instructions, you compiled the 64
bits version, using the gcc compiler, with double precision, and optimized version.
This is reflected in the name of the directory linux64GccDPOpt. 18'
Let us now study the src directory
$WM_PROJECT_DIR
src/ …
Let us visit src directory. Type in the terminal src or

cd $WM_PROJECT_DIR/src.
This directory contains the source code for all the foundation libraries, this is the
core of OpenFOAM®. It is divided in different subdirectories and each of them
can contain several libraries.
A few interesting directories are:
•  finiteVolume. This library provides all the classes needed for the finite
volume discretization, such as mesh handling, finite volume discretization
operators (divergence, laplacian, gradient, fvc/fvm and so on), and boundary
conditions (fields/fvPatchFields). In lnInclude you also find the very
important file fvCFD.H, which is included in most applications.
•  OpenFOAM. This core library includes the definitions of the containers used for
the operations, the field definitions, the declaration of the mesh and mesh
features such as zones and sets.
•  turbulenceModels, which contains many turbulence models.
$WM_PROJECT_DIR
src/ …
Let us visit src directory. Type in the terminal src or

cd $WM_PROJECT_DIR/src.
In this directory you will also find the Allwmake script, which will compile all the
content of the src directory.
To compile a specific library, go to the desired sub-directory and compile it by
typing wmake.
Let us now study the tutorials directories
$WM_PROJECT_DIR
tutorials
Let us visit the tutorials directory. Type in the terminal tut or

cd $WM_PROJECT_DIR/tutorials.
•  The tutorials directory contains example cases for each solver. These
are the tutorials distributed with OpenFOAM®.'
Let us now study the wmake directory
$WM_PROJECT_DIR
wmake
Let us visit the wmake directory.
OpenFOAM® uses a special make command: wmake.
wmake understands the file structure in OpenFOAM® and has some default
compiler directives that are set in the wmake directory. There is also a command,
wclean, that cleans up the output from the wmake command.
If you add a new compiler name in the bashrc file, you should also tell wmake
how to interpret that name. In wmake/rules you will find the default settings for
the available compilers.
You can also find a few scripts that are useful when organizing your files for
compilation, or for cleaning up. Module'1')'Lecture'2' 25'
•  We just studied the directory WM_PROJECT_DIR, which

contains the original installation of OpenFOAM®.
•  Any modification you add to the source code in

WM_PROJECT_DIR, will affect the whole library.
•  Tip of day,
Unless you know what are you doing,

do not modify anything in the original
installation ($WM_PROJECT_DIR),
except for updates!
Let us now study the OpenFOAM® user directory
$HOME/OpenFOAM
$WM_PROJECT_DIR
$WM_PROJECT_USER_DIR
User directory $WM_PROJECT_USER_DIR (USER_NAME-2.3.x)

In $WM_PROJECT_USER_DIR directory, all user files are located.
If you are going to develop applications of your own, it is recommended to put the
source code in $WM_PROJECT_USER_DIR following the same structure as in
$WM_PROJECT_DIR/applications.
It is recommended to create two more directories:
$WM_PROJECT_USER_DIR/run
$WM_PROJECT_USER_DIR/src
This is done so you do not modify anything in the original installation,

except for updates!
$HOME/OpenFOAM
$WM_PROJECT_DIR
$WM_PROJECT_USER_DIR
User directory $WM_PROJECT_USER_DIR (USER_NAME-2.3.x)

Place user developed library source code in $WM_PROJECT_USER_DIR/src
directory, with the same directory structure as in $FOAM_SRC.
In the $WM_PROJECT_USER_DIR/run directory (which has the alias run) you can
place your cases (this is not compulsory).
In $WM_PROJECT_USER_DIR/platforms/linux64GccDPOpt/bin, the binaries
of the user developed applications will be located; whereas, in
$WM_PROJECT_USER_DIR/platforms/linux64GccDPOpt/lib, the binaries of
the user developed libraries will be located.

except for updates!
Remember, you can do all the

modifications you want in your user
directory ($WM_PROJECT_USER_DIR).
By proceeding in this way, you do not
mess around with the original
installation.
Environment variables
•  Remember, OpenFOAM® uses its own environment variables.
•  OpenFOAM® environment settings are contained in the

OpenFOAM-2.3.x/etc directory.
•  If you installed OpenFOAM® in the default location, they should

be in:
•  $HOME/OpenFOAM/OpenFOAM-2.3.x/etc
Environment variables
•  If you are running bash or ksh (if in doubt type echo $SHELL),
you sourced the $WM_PROJECT_DIR/etc/bashrc file by
adding the following line to your $HOME/.bashrc file:
•  source $HOME/OpenFOAM/OpenFOAM-2.3.x/etc/
bashrc
source $HOME/OpenFOAM/OpenFOAM-2.3.x/etc/bashrc
•  By sourcing the file $WM_PROJECT_DIR/etc/bashrc, we start

to use OpenFOAM® environment variables.
•  By default, OpenFOAM® uses the system compiler and the

system MPI compiler.
WARNING
Remember, when you use OpenFOAM® you are using its
environment settings, that is, path to libraries and
compilers.
So if you are developing your own software or compiling

applications, and you are having compilation problems
due to conflicting libraries or missing compilers, try to
unload OpenFOAM® environment variables
Today’s lecture

Directory structure of an OpenFOAM® solver
$WM_PROJECT_DIR/applications/solvers
appName The appName directory contains the source

code.
appName.C
The Make directory contains compilation
createFields.H instructions.
appName/appName.C: is the actual source
code.
Make
appName/createFields.H: declares all
files the field variables and initializes the solution.
options Make/files: names all the source files
(.C). Specifies the appName name and
location of the output file.
Make/options: specifies directories to
search for include files and libraries to link
the solver against.
$WM_PROJECT_USER_DIR /applications/solvers
appName
appName.C
createFields.H
Make
files
options
REMEMBER
For your own applications, it is recommended to put the source code in
$WM_PROJECT_USER_DIR following the same structure as in $WM_PROJECT_DIR/
applications. Also, you will need to modify Make/files and Make/options to show
the new name and location of the compiled binaries and libraries to link the solver against.
except for updates!. You can do anything you want to your own copies,
so you do not risk messing things up.
Directory structure of an OpenFOAM® utility
$WM_PROJECT_DIR/applications/utilities
appName The appName directory contains the source

code.
appName.C
The Make directory contains compilation
header_files(.H) instructions.
appName/appName.C: is the actual source
code.
Make
appName/header_files (.H): header
files files needed to compile the utility.
options Make/files: names all the source files
(.C). Specifies the appName name and
location of the output file.
Make/options: specifies directories to
search for include files and libraries to link
the utility against.
$WM_PROJECT_USER_DIR /applications/utilities
appName
appName.C
Header files (.H)
Make
files
options
REMEMBER
For applications of your own, it is recommended to put the source code in
$WM_PROJECT_USER_DIR following the same structure as in $WM_PROJECT_DIR/
applications. Also, you will need to modify Make/files and Make/options to show
the new name and location of the compiled binaries and libraries to link the utility against.
except for updates!. You can do anything you want to your own copies,
so you do not risk messing things up.
REMEMBER
You can put your OpenFOAM® cases, solvers, utilities
and libraries in any directory, but it is highly advisable to
save everything in your OpenFOAM® user directory or
$WM_PROJECT_USER_DIR.
Today’s lecture

Solvers in OpenFOAM®
•  In $FOAM_SOLVERS (use alias sol to go there) you will find the directories
containing the source code for the solvers available in the OpenFOAM® installation
(version 2.3.x):
•  basic
•  combustion
•  compressible
•  discreteMethods
•  DNS
•  electromagnetics
•  financial
•  heatTransfer
•  incompressible
•  lagrangian
•  multiphase
•  stressAnalysis
•  For example, in the sub-directory incompressible you will find several sub-
directories containing the source code of the following solvers:
•  adjointShapeOptimizationFoam
•  boundaryFoam
•  icoFoam
•  nonNewtonianIcoFoam
•  pimpleFoam
•  pisoFoam
•  shallowWaterFoam
•  simpleFoam
•  Inside each directory you will find a *.C file with the same name as the directory.
This is the main file, where you will find the top-level source code and a short
description of the solver. In incompressible/icoFoam/icoFoam.C you will find
the following description:
Transient solver for incompressible, laminar flow of
Newtonian fluids. Module'1')'Lecture'2' 45'
REMEMBER
You have the source code right there.
So take your time and dig into each directory to get a

complete description of each solver.
Utilities in OpenFOAM®
•  In $FOAM_UTILITIES (use alias util to go there) you will find the directories
containing the source code for the utilities available in the OpenFOAM® installation
(version 2.3.x):
•  mesh
•  miscellaneous
•  parallelProcessing
•  postProcessing
•  preProcessing
•  surface
•  thermophysical
As for the solver, take your time and dig into each directory to get a
complete description of each utility.
•  For example, in the sub-directory mesh/generation you will find several sub-
directories containing the source code of the following utilities:
•  blockMesh
•  extrude
•  extrude2DMesh
•  foamyHexMesh
•  foamyQuadMesh
•  snappyHexMesh
•  Inside each utility directory you will find a *.C file with the same name as the
directory. This is the main file, where you will find the top-level source code and a
short description of the utility. In snappyHexMesh/snappyHexMesh.C you will find
the following description:
Automatic split hex mesher. Refines and

snaps to surface.
•  For example, in the sub-directory postProcessing/velocityField you will find
several sub-directories containing the source code of the following utilities:
•  Co •  Q
•  enstrophy •  streamFunction
•  flowType •  streamFunction
•  Lambda2 •  uprime
•  Mach •  vorticity
•  Pe
•  Inside each utility directory you will find a *.C file with the same name as the
directory. This is the main file, where you will find the top-level source code and a
short description of the utility. In Q/Q.C you will find the following description:
Calculates and writes the second invariant of the velocity

gradient tensor.
Q = 0.5*(sqr(tr(gradU)) - tr(((gradU)&(gradU)))) [1/s^2]
The -noWrite option just outputs the max/min values without
writing the field.
REMEMBER
You have the source code right there.
So take your time and dig into each directory to get a

complete description of each utility.
Applications and libraries in OpenFOAM®
•  If you are interested in knowing all the solvers, utilities and

libraries that come with OpenFOAM®, you can read the
applications and libraries section in the user guide (chapter 3).
•  In the directory $WM_PROJECT_DIR/doc/ you will find the

OpenFOAM® documentation in pdf format. To open the user
guide type in the terminal,
•  acroread $WM_PROJECT_DIR/doc/Guides-a4/
UserGuide.pdf
•  If you have internet access you can read the online user guide. Go to the link
http://www.openfoam.org/docs/user/, then go to chapter 3 (applications and libraries), and then
go the sub-sections, 3.5 Standard solvers, 3.6 Standard utilities, and/or 3.7 Standard libraries.
•  The solvers in the OpenFOAM® distribution are in the

$FOAM_SOLVERS directory, reached quickly by typing sol in
the terminal.
•  The utilities in the OpenFOAM® distribution are in the

$FOAM_UTILITIES directory, reached quickly by typing util
in the terminal.
•  The source code of the libraries in the OpenFOAM® distribution

is in the $FOAM_SRC directory, reached quickly by typing src in
the terminal. Module'1')'Lecture'2' 53'
Today’s lecture

Directory structure of an OpenFOAM® case
$WM_PROJECT_USER_DIR/run
case_directory (case name) case_directory: path to the
case, often located in
system $WM_PROJECT_USER_DIR/run
controlDict
system: contains run-time control
fvSchemes and solver numerics.
fvSolution constant: contains physical
constant properties and turbulence
modeling properties and so on.
physical properties
constant/polyMesh: contains
polyMesh the polyhedral mesh information.
mesh information
0: contains boundary conditions
0 and initial conditions.
boundary/initial conditions time_directories: contains the
solution and derived fields.
time_directories
solution files
REMEMBER
You always run the solvers and utilities in the the top
level of the case directory (the directory with the case
name).
Not in the directory system, not in the directory
constant, not in the directory 0.
REMEMBER
You can put your OpenFOAM® cases, solvers, utilities
and libraries in any directory, but it is highly advisable to
save everything in your OpenFOAM® user directory or
$WM_PROJECT_USER_DIR.
•  In the USB key you will find many tutorials (which are different
from those that come with the OpenFOAM® installation), let us
work with these tutorials to understand and get functional using
OpenFOAM®.
•  You can extract the tutorials wherever you want. However, I

highly recommend you to extract them in your OpenFOAM®
user directory or in $WM_PROJECT_USER_DIR/run. From now
on, this directory will become
•  $PTOFC
(abbreviation of path to OpenFOAM® course).
•  You can add this alias to your .bashrc file,
•  alias PTOFC='cd $PATH_TO_TUTORIALS’

•  By the way, to uncompress the tutorials go to the directory
where you copied the training material and type in the terminal,
•  tar –zxvf file_name.tar.gz
•  On the other side, if you want to compress a directory you can

proceed as follows,
•  tar –zcvf file_name.tar.gz directory_name
•  At this point we are ready to run our first

case.
•  So buckle up and enjoy the ride.
Module 1
Today’s lecture
1.  Before we start

2.  My first OpenFOAM® case setup
3.  A deeper view to my first OpenFOAM® case
setup
4.  My second OpenFOAM® case setup
5.  My third OpenFOAM® case setup
6.  My first 3D OpenFOAM® case setup
7.  Hands-on session
Today’s lecture

setup
Before we start
Before we run our first

OpenFOAM® case
Before we start
Simulation workflow – Generic global view.
GEOMETRY
MESH
SOLVER CO-PROCESSING
VISUALIZATION
Before we start
Simulation workflow – Parametric or optimization approach.
GEOMETRY
MESH
PARAMETRIZATION
OPTIMIZATION
VISUALIZATION
Before we start
Simulation workflow – Concurrent approach.
PARALLEL ASYNCHRONOUS OR CONCURRENT DRIVER
MULTIDIMENSIONAL OR PARAMETRIC STUDY
DESIGN OF EXPERIMENTS
SENSITIVITY ANALYSIS
OPTIMIZATION STUDY
UNCERTAINTY QUANTIFICATION
ROBUST DESIGN AND OPTIMIZATION UNDER UNCERTAINTY
MULTIOBJECTIVE OPTIMIZATION
SURROGATE BASED OPTIMIZATION
HUMAN DECISION MAKER

DECISION MATRIX OR
GEOMETRY GEOMETRY GEOMETRY
MESH MESH MESH
SOLVER CO-PROCESSING SOLVER CO-PROCESSING SOLVER CO-PROCESSING
PARAMETRIZATION PARAMETRIZATION PARAMETRIZATION

OPTIMIZATION OPTIMIZATION OPTIMIZATION
VISUALIZATION VISUALIZATION VISUALIZATION
CASE 1 CASE 2 CASE N
AUTOMATIC POST-PROCESSING
Before we start
Now we are ready

to run our first
OpenFOAM® case
Today’s lecture

setup
My first OpenFOAM® case setup
Flow in a lid-driven square cavity
Ux = 1 m/s
h = 0.1 m
(0,0,0)
l = 0.1 m
Running the case
blockMesh
icoFoam functionObjects
paraFoam
At the end of the day you should get something like this
Mesh
Pressure field Velocity magnitude field
•  Let us go to the directory:
$PTOFC/first_tutorial/cavity
What are we going to do?
•  We will use the lid-driven square cavity tutorial as a general example to show you
how to set up and run solvers and utilities in OpenFOAM®.
•  In this tutorial we are going generate the mesh (domain discretization), using
blockMesh. However, we can use any application that can generate a valid mesh for
OpenFOAM®.
•  After generating the mesh, we look for topological errors and assess the mesh quality.
For this we use the utility checkMesh. Later on, we are going to talk about what is a
good mesh.
•  Then we proceed to find the numerical solution using icoFoam, which is a transient
solver for incompressible, laminar flow of Newtonian fluids. By the way, I hope you did
not forget where to look for this information.
•  And we finish by doing some cool visualization and post-processing using paraFoam
(a paraview fork).
Running the case
•  While we run this case, we are going to see a lot of information on the screen
(standard output stream or stdout), but it will not be saved. This information is
mainly related to convergence of the simulation.
•  In the directory $PTOFC/first_tutorial/cavity you will find the cavity tutorial.
•  From this point on, please follow me.
•  We are all going to work at the same pace.
Running the case
•  In the directory $PTOFC/first_tutorial you will find the cavity tutorial.
•  In the terminal window type:
•  cd $PTOFC/first_tutorial/cavity
•  ls –l
(Just to list all the directories and files. Does the directory structure look familiar to you?)
•  blockMesh
(Geometry definition and mesh generation utility)
•  checkMesh
(Check topology and mesh quality)
•  icoFoam
(This will run the solver and will show the standard output on the fly. The standard output stream will not be saved)
•  paraFoam
(Visualization utility)
Running the case
•  In the previous case, we run the simulation but we did not save the standard output
stream (stdout) in a log file. We saw the information on the fly.
•  My advice is to always save the standard output stream (stdout) in a log file.
•  It is of interest to always save the log as if something goes wrong, and you will like to
do some troubleshooting you will need this information.
•  Also, if you are interested in plotting the residuals, you will need this log file.
•  By the way, if at any point you ask me what went wrong with your simulation, I will ask
you for this file. I might also ask for the standard error stream (stderr).
Running with log files
•  To save a log file of the simulation, we proceed as follows:
•  cd $PTOFC/first_tutorial/cavity
(if you are not already in this directory)
•  foamCleanTutorials
(To erase the saved solution. It will erase the mesh and all the folders, except for 0, constant and system)
•  blockMesh
•  checkMesh
•  icoFoam > log.icoFoam
(This will redirect your standard output to an ascii file with the name log.icoFoam, you will not see the information on
the fly. If you do not add the > log.icoFoam modifier you will see your standard output on the fly and it will not be
saved)
•  gedit log.icoFoam
(Here I use gedit to open the log.icoFoam file, but you can use any editor.)
•  foamLog log.icoFoam
(This utility will extract the information inside log.icoFoam and it will save it in an editable format.
•  cd logs
•  gnuplot
(We now use gnuplot to plot the information extracted from the log file)
These steps are optional
•  But what if I want to save the standard output stream (stdout), and monitor the
information on the fly?
•  To do this, you can proceed as follows:
•  icoFoam > log.icoFoam | tail –f log.icoFoam
This will redirect your standard output to an ascii file with the name log.icoFoam.
Then using the pipeline operator ( | ) it will use tail to show you the information on
the fly.
•  You can also save the standard output stream (stdout) and the standard error
stream (stderr) , as followsm
•  icoFoam > log.icoFoam 2>&1 | tail –f log.icoFoam
This will redirect the standard output and standard error streams to an ascii file with
the name log.icoFoam. Then using the pipeline operator ( | ) it will use tail to
show you the information on the fly.
•  You can also save the standard output in a log.icoFoam, send the job to
background and then use tail to output the information on the fly. To do this you
can proceed as follows,
•  icoFoam > log.icoFoam &
The bash operator & will send the job to background.
•  Now you cab type in the terminal windows:
•  tail –f log.icoFoam
This will use tail to show you the information on the fly.
•  You can also save the standard output in log.icoFoam, open a new terminal
window and then use tail to output the information on the fly. To do this you can
proceed as follow:
•  icoFoam > log.icoFoam
•  Now, in a new terminal window type,
•  tail –f log.icoFoam
This will use tail to show you the information on the fly. Notice that you will need
to open a new terminal window and you need to be in the case directory.
•  You can also use the Linux command tee,
•  icoFoam | tee log.icoFoam
This will redirect your standard output to an ascii file with the name log.icoFoam,
and it will show you at the same time the information that is saved in the
log.icoFoam.
•  If for any reason you do not want to see the standard output stream and you are not
interested in saving the log file, you can proceed as follows,
•  icoFoam > /dev/null
•  Finally, when you run in a cluster, you are always interested in saving the logs files
in order to monitor the solution. Remember to always redirect the solver standard
output and error streams to a log file. We are going to briefly address this issue
later.
•  To monitor your solution, just login to the cluster, go to the working directory (the
directory where you launched the solver) and type
•  tail –f name_of_the_log_file
•  You can login and logout with no problem, everything is being managed by the job
scheduler.
•  Besides the log file you are saving, the job scheduler will save all the standard
output stream (stdout) and standard error stream (stderr) in a default file. You
can also access these files to monitor the solution.
•  It is also possible to plot the log information on the fly. The easiest way to do this is
by using PyFoam (you will need to install it):
•  pyFoamPlotRunner.py [options] <foamApplication>
•  To run this case with pyFoamPlotRunner.py, in the terminal type:
•  pyFoamPlotRunner.py icoFoam
•  If you need help or want to know all the options available,
•  pyFoamPlotRunner.py --help
•  If you do not feel confortable using pyFoamPlotRunner.py to run the solver, it is
also possible to plot the information saved in the log file using PyFoam. To do this
you will need to use the utility pyFoamPlotWatcher.py. For example, in the
terminal type:
•  icoFoam > log.icoFoam &
•  pyFoamPlotWatcher.py log.icoFoam
This will plot the information saved in log.icoFoam. To use

pyFoamPlotWatcher.py you will need to install gnuplot.
•  This is a screenshot on my computer. In this case, pyFoamPlotRunner is plotting
the initial residuals and continuity errors on the fly.
•  You can save log files for every single solver or utility
implemented in OpenFOAM®.
Stopping the simulation
•  Your simulation will automatically stop at the time value you set using the keyword
endTime in the controlDict dictionary.
endTime 0.5;
•  If for any reason you want to stop your simulation before reaching the value set by the
keyword endTime, you can change this value to a number lower than the current
simulation time (you can use 0 for instance). This will stop your simulation, but it will
not save your last time-step or iteration, so be careful.
Refer to the UserModule'1')'Lecture'3'

Guide for more Information 30'
•  If you want to stop the simulation and save the solution, in the controlDict
dictionary made the following modification,
stopAt writeNow;
•  This modification can be done on the fly (you will need to set the keyword
runTimeModifiable to yes in the controlDict dictionary). This will stop your
simulation and will save the current time-step or iteration.

•  You can also kill the process. For instance, if you did not launch the solver in
background, go to its terminal window and press ctrl-c. This will stop your
simulation, but it will not save your last time-step or iteration, so be careful.
•  If you launched the solver in background, just identify the process id and terminate it.
Again, this will not save your last time-step or iteration.
•  When working on my workstation, I usually proceed in this way:
icoFoam > log.icofoam | tail –f log.icofoam
This will run the solver icoFoam (by the way, this works for any solver or utility), it
will save the standard output stream in the file log.icofoam and will show the
solver output on the fly. If at any moment I want to stop the simulation, and I am not
interested in saving the last time-step, I press ctrl-c.
•  If I am interested in saving the last time step, I modify the controlDict dictionary
and add the following keyword
stopAt writeNow;
•  Remember, this modification can be done on the fly. However, you will need to set the
keyword runTimeModifiable to Module'1')'Lecture'3'
yes in the controlDict dictionary. 33'
Cleaning the case folder
•  If you want to erase the mesh and the solution in the current case folder, you can type
in the terminal,
foamCleanTutorials
•  If you are looking to only erase the mesh, you can type in the terminal,
foamClearPolyMesh
•  If you are only interested in erasing the saved solutions, in the terminal type,
foamListTimes -noZero | xargs rm -rf
Cleaning the case folder
•  Another fancy way to clean the case folder is as follows. In the terminal type,
•  shopt -s extglob
(You just need to type this once in the terminal. If you do not know what we are doing, just google this)
•  rm -rf !(0_org|constant|system|script)
(This will erase everything in the case directory except for the folders and files 0_org, constant, system
and script)
•  To make your life easier, you can write a small shell script with the following
information,
#!/bin/sh
shopt -s extglob
rm -rf !(0_org|constant|system|script)
Today’s lecture

setup
A deeper view to my first OpenFOAM® case setup
•  We will take a look at what we did when running the cavity tutorial by looking at the
case files.
•  First at all it should be noted that icoFoam is a transient solver for incompressible,
laminar flow of Newtonian fluids.
•  The case directory originally contains the following sub-directories: 0, constant, and
system. After running icoFoam it also contains the time step directories 0.1, 0.2,
0.3, 0.4, 0.5 and the log.icoFoam file (if you chose to redirect the standard
output stream).
•  The time step directories contain the values of all the variables at those time
steps (the solution). The 0 directory is thus the initial condition and boundary
conditions.
•  The constant directory contains the mesh and dictionaries for thermophysical
and turbulence models.
•  The system directory contains settings for the run, discretization schemes and
solution procedures.
•  The icoFoam solver reads the files in the case directory and runs the case
according to those settings.
The constant directory
(and by the way, open each file and go thru its content)
•  The transportProperties file is a dictionary for the dimensioned scalar nu, or the
kinematic viscosity.
•  In this case, where we are working with an incompressible flow, we only need to
define the kinematic viscosity.
µ
⌫=
⇢
•  Later on, I will ask you to change the Reynolds number, to do so you can change the
value of nu. Remember,
⇢⇥U ⇥L U ⇥L
Re = =
µ ⌫
•  You can also change the free stream velocity U or the reference length L.
•  Depending on the physics involved and models used, you will need to define more
variables in the dictionary transportProperties.
•  For instance, for a multiphase case you will need to define the density rho and
kinematic viscosity nu for each single phase. You also will need to define the surface
tension .
•  Depending of your physical model, you will find more dictionaries in the constant
directory.
•  For example, if you need to set gravity, you will need to create the dictionary g.
•  For the sake of completeness, if you work with compressible flows you will need to
define the dynamic viscosity mu, and many other physical properties in the dictionary
thermophysicalProperties, yes it is a different dictionary.
•  As we are not working with compressible flows, I am not going into details. If you are
interested in learning more, you can take a look at the tutorials that deal with
compressible flows.
•  The polyMesh directory originally contains the blockMeshDict dictionary for the
blockMesh mesh generator. After generating the mesh, it will contain the mesh in
OpenFOAM® format.
•  We will now take a quick look at the blockMeshDict dictionary in order to
understand what we have done (and yes, this is part of the meshing session as well).
•  Go to the directory constant/polyMesh and open blockMeshDict dictionary
with your favorite text editor, I will use gedit.
The constant/polyMesh/blockMeshDict dictionary
The blockMeshDict dictionary first of all contains a list with a number of vertices:
convertToMeters 0.1;
vertices
(
(0 0 0) //Vertex 0
(1 0 0) //Vertex 1
(1 1 0) //Vertex 2
(0 1 0) //Vertex 3
(0 0 0.1) //Vertex 4
(1 0 0.1) //Vertex 5
(1 1 0.1) //Vertex 6
(0 1 0.1) //Vertex 7
);
•  There are eight vertices defining a 3D block. OpenFOAM® always uses 3D meshes,
even if the simulation is 2D.
•  convertToMeters 0.1; multiplies the coordinates by 0.1. It is a scaling factor.
The blockMeshDict dictionary then defines a block and the mesh from the vertices:
blocks
(
hex (0 1 2 3 4 5 6 7) (20 20 1) simpleGrading (1 1 1)
);
•  hex means that it is a structured hexahedral block.

•  (0 1 2 3 4 5 6 7) are the vertices used to define the block (and yes, the order
is important). Each hex block is defined by eight vertices, in sequential order.
Where the first vertex in the list represents the origin of the coordinate system.
•  (20 20 1) is the number of mesh cells in each direction.
•  simpleGrading (1 1 1) is the expansion ratio or mesh stretching, in this case
equidistant.
The blockMeshDict dictionary also defines three boundary patches:
boundary frontAndBack //NAME

( {
movingWall //NAME type empty; //TYPE
{ faces
type wall; //TYPE (
faces (0 3 2 1) //FACE
( (4 5 6 7) //FACE
(3 7 6 2) //FACE );
) ; }
} );
fixedWalls //NAME
{
type wall; //TYPE
faces
(
(0 4 7 3) //FACE
(2 6 5 1) //FACE
(1 5 4 0) //FACE
);
}
1 2
Each boundary patch in the blockMeshDict dictionary defines a type, a name, and a
list of boundary faces:
fixedWalls
{
type wall;
faces
(
(0 4 7 3)
(2 6 5 1)
(1 5 4 0)
);
}
•  wall is the type of the boundary and fixedWalls is the name of the patch.
•  The patch is defined by three faces of the block according to the list, which refers to
the vertex numbers.
•  When defining the block and boundaries, the vertices in the lists must be neighbors.
•  The order of the vertices in the block must be such that if you sit down in the origin of
coordinates (vertex 0 for this case), and you look towards the axis z (where the axis z
is coming out of the screen), the vertices are marched in a counter clockwise sense.
•  The type empty tells OpenFOAM® that this is a 2D case.
•  This is how the block created with blockMeshDict looks like,

•  To sum up, the blockMeshDict dictionary generates a block with:

•  x/y/z dimensions 0.1/0.1/0.01.
•  20 x 20 x 1 cells.
•  wall fixedWalls patch at three sides.
•  wall movingWall patch at one side.
•  empty frontAndBack patch at two sides.
•  If you are interested in visualizing the actual blocking, you can use paraFoam with
the following option,
•  paraFoam –block'

The constant/polyMesh/boundary file
•  First at all, this file is automatically generated after you create the mesh
using blockMesh or snappyHexMesh, or you convert the mesh from any
of the compatible formats.
•  In this file, the geometrical information related to the base patch type of each
boundary of the domain is specified.
•  The base type is different from the numerical type (or primitive type).
•  The base type is described purely in terms of geometrical information, while
the numerical type assign a field value to the boundary type.
•  You define the numerical patch type (or the value of the boundary condition),
in the directory 0 or time directories.
•  The base patch type of each boundary of the domain is specified in the file
boundary, which is located in the directory constant/polyMesh/.
•  The patch type is specified under the type keyword for each patch defined
in the file boundary.
movingWall
{
type wall;
nFaces 20;
startFace 760;
}
fixedWalls
{
type wall;
nFaces 60;
startFace 780;
}
frontAndBack
{
type empty;
inGroups 1(empty);
nFaces 800;
startFace 840;
} Module'1')'Lecture'3' 50'
•  The base patch type of each boundary must be consistent with the
numerical patch type, or the boundary condition used in the field files located
in the directory 0 or time directories.
•  In this example, the base patch type of the patch frontAndBack (defined
in the file boundary), is consistent with the numerical patch type defined in
the field files 0/U and 0/p. They are of the type empty. Same for the
other patches.
•  This is extremely important, specially if you are converting meshes as not
always the patches are set automatically.
•  Hence, I highly advise you to do a sanity check and verify that the base
patch type (the patch type defined in the file boundary), is consistent with
the numerical patch type (the patch type defined in the field files contained in
the time directories or directory 0).
The system directory
•  The system directory consists of three dictionary files:

•  controlDict
•  fvSchemes
•  fvSolution
•  controlDict contains general instructions on how to run the case.
•  fvSchemes contains instructions for the discretization schemes that will be
used for the different terms in the equations.
•  fvSolution contains instructions on how to solve each discretized linear
equation system.
•  Do not worry, we are going to study in details the most important entries of
each dictionary.
The 0 directory
•  The 0 directory contains the initial and boundary conditions for all primitive variables,
in this case p and U. For this case, the U file contains the following:
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
movingWall
{
type fixedValue;
value uniform (1 0 0);
}
fixedWalls
{
type fixedValue;
}
frontAndBack
{
type empty;
}
}
The 0 directory
•  dimensions [0 1 -1 0 0 0 0]; states that the dimension of U is m/s.

•  internalField uniform (0 0 0); sets U to zero internally (initial conditions).
•  The boundary patches movingWall and fixedWalls are given the type
fixedValue; with value uniform (1 0 0), and (0 0 0) respectively (boundary
conditions).
•  The frontAndBack patch is given type empty, indicating that no solution is
required in that direction since the case is 2D.
•  You should now be able to understand the file 0/p.
•  The time step directories are similar but the internalField now contains the
solution. There is also a phi file, containing the resulting face fluxes that are needed
to yield a perfect restart.
The 0 directory
•  And by the way if you take some time and read the files 0/U and 0/p, you will see
that each numerical patch type (the patch type defined in U and p), is consistent with
the base patch type (the patch type defined in the file constant/polyMesh/
boundary).
The log.icoFoam file
•  If you followed the previous instructions you should now have a log.icoFoam file.
This file contains all the residuals and convergence information.
•  It is of interest to have a graphical representation of the residual. To do so, the

foamLog utility is used.
•  Let us now execute foamLog utility. In the terminal type:
•  foamLog log.icoFoam
•  A directory logs has now been generated, with extracted values in ascii format in two
columns. The first column is the time or iteration number, and the second column is
the value at that time.
•  Add this point, you can plot the residuals using gnuplot, qtiplot or xmgrace (or your
favorite plotting application).
•  Type foamLog -help for more information.

At this point you should have realized a few things:
•  OpenFOAM® is fully dimensional. You need to define the dimensions for

each field data and physical properties. Your dimensions shall be
consistent.
Dimensions in OpenFOAM®
No. Property Unit Symbol
1 Mass Kilogram kg
2 Length meters m
3 Time second s
4 Temperature Kelvin K
5 Quantity moles mol
6 Current ampere A
Luminuous
7 candela cd
intensity
dimensions [kg, m, s, K, mol, A, cd]

•  Each file in the case directory has a header, you should always keep this
header, if not, OpenFOAM® will complain.
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.3.0 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
•  In the header of your field variables, the class type should be consistent with
the type of field variable you are using. That is to say, if the field variable is
a vector, the class should be volVectorField
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
•  And if the field variable is a scalar, the class should be volScalarField.
/*--------------------------------*- C++ -*----------------------------------*\

| ========= | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
object p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
•  If you misspell something or forget a compulsory keyword or file,

OpenFOAM® will complain and will tell you where is and what is the error.
•  It is very important to read the screen and understand the output.
“Experience is simply the name we give our mistakes.”'
Error output
•  Sometimes OpenFOAM® will give you the error FOAM FATAL IO ERROR.
•  This error only means that there is a problem with a dictionary and it is likely
that you misspelled something or you are forgetting a keyword.
•  This error does not mean that the actual OpenFOAM® installation is
corrupted.
•  Maybe the guys of OpenFOAM® went a little bit extreme here.
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / O peration | Version: 2.3.x |
\*---------------------------------------------------------------------------*/
Build : 2.3.x-5d8318b22cbe
Exec : icoFoam
Date : Nov 02 2014
Time : 00:33:41
Host : "linux-cfd"
PID : 3675
Case : /home/cfd/my_cases_course/cavity
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
--> FOAM FATAL IO ERROR:
•  Also, before entering into panic, read carefully the output because
OpenFOAM® is telling you what is the error and how to correct it.
/*---------------------------------------------------------------------------*\
| ========= | |
\*---------------------------------------------------------------------------*/
Exec : icoFoam
Date : Nov 02 2014
Time : 00:33:41
Host : "linux-cfd"
PID : 3675
nProcs : 1
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
--> FOAM FATAL IO ERROR:
banana_endTime is not in enumeration:

4
(
endTime
nextWrite
noWriteNow
writeNow
)
file: /home/cfd/my_cases_course/cavity/system/controlDict.stopAt at line 24.
From function NamedEnum<Enum, nEnum>::read(Istream&) const

in file lnInclude/NamedEnum.C at line 72.
FOAM exiting Module'1')'Lecture'3' 65'

•  Instead, you should worry about the SIGFPE error signal. This error signal indicates
that something went really wrong (erroneous arithmetic operation).
•  This message (that seems a little bit difficult to understand), is giving you a lot
information.
•  For instance, this output is telling us that the error is due to SIGFPE and the class
associated to the error is lduMatrix. It is also telling you that the GAMGSolver
solver is the affected one (likely the pressure is becoming unbounded).
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 in "/lib64/libc.so.6"
#3 Foam::DICPreconditioner::calcReciprocalD(Foam::Field<double>&, Foam::lduMatrix const&) at ??:?
#4 Foam::DICSmoother::DICSmoother(Foam::word const&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double>
const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&) at ??:?
#5 Foam::lduMatrix::smoother::addsymMatrixConstructorToTable<Foam::DICSmoother>::New(Foam::word const&,
Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::FieldField<Foam::Field, double> const&,
Foam::UPtrList<Foam::lduInterfaceField const> const&) at ??:?
#6 Foam::lduMatrix::smoother::New(Foam::word const&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double>
const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&,
Foam::dictionary const&) at ??:?
#7 Foam::GAMGSolver::initVcycle(Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&,
Foam::PtrList<Foam::lduMatrix::smoother>&, Foam::Field<double>&, Foam::Field<double>&) const at ??:?
#8 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#9 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#10 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#11
at ??:?
#12 __libc_start_main in "/lib64/libc.so.6"
#13
at /home/abuild/rpmbuild/BUILD/glibc-2.17/csu/../sysdeps/x86_64/start.S:126
Floating point exception
•  By default the floating point exception trapping (FOAM_SIGFPE) signal is enable
(signal processing).
•  Signal processing defines how a program handles various signals while it executes.
The SIGFPE signal indicates an erroneous arithmetic operation (such as division by
zero), and the default action is the abnormal termination of the process.
•  FPE, which stands for floating-point exception, also handles integer arithmetic errors.
/*---------------------------------------------------------------------------*\
| ========= | |
\*---------------------------------------------------------------------------*/
Exec : interDyMFoam
Date : Nov 02 2014
Time : 01:16:57
Host : "linux-cfd"
PID : 4876
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Dictionary files hints and advanced

features
Dictionary files hints
•  If you do not know which entries are available for a specific keyword in a dictionary,
just use a dummy word (a word that does not exist in OpenFOAM®) and the solver
will list the alternatives. For instance if we add,
stopAt banana;
in the controlDict dictionary file; the solver will give you the following message:
banana is not in enumeration

4
(
nextWrite
writeNow
noWriteNow
endTime
)
•  I love to add bananas, from now on let us call this shortcut the banana method (not
related to Rosenbrock's banana function).
Dictionary files advanced features
•  C++ commenting:
// This is my comment
/*
My comments, line 1
My comments, line 2
*/
•  #include directive:
#include “initialConditions”
Do not forget to create the respective include file initialConditions.
•  Macro expansion:
flowVelocity (20 0 0);
/*
some code lines here
*/
internalField uniform $flowVelocity;
/*
some code lines here
*/
•  Instead of writing (the poor man’s way):
leftWall
{
type fixedValue;
}
rightWall
{
type fixedValue;
}
topWall
{
type fixedValue;
}
•  You can write (the lazy way):
“(left|right|top)Wall”
{
type fixedValue;
}
•  You could also try (even lazier):
“.*Wall”
{
type fixedValue;
}
•  OpenFOAM® understands the syntax of regular expressions (regex or regexp). 73'

•  Switches: they are used to enable or disable a function or a feature in the dictionaries.
•  Switches are logical values, hence they are paired. You can use the following values:
false true
off on
no yes
n y
f t
none true
•  You can find all the valid switches in the following file:
OpenFOAM-2.3.x/src/OpenFOAM/primitives/bools/Switch/Switch.C
•  Switches: they are used to enable or disable a function or a feature in the dictionaries.
•  For example, the following entries in the dictionary controlDict are valid:
runTimeModifiable yes;
runTimeModifiable true;
runTimeModifiable on;
Solvers and utilities help
•  If you need help about a solver or utility, you can use the flag –help. For
instance:
•  icoFoam –help
will print some basic help and usage information about icoFoam.
•  Remember, you have the source code there so you can always
check the original source.
•  The doc directory contains the documentation of OpenFOAM®, namely;
user guide, programmer’s guide and Doxygen generated documentation in
html format.
•  To use the Doxygen documentation you will need to compile it first.

•  cd $WM_PROJECT_DIR
•  ./Allwmake doc
Note: You will need to install doxygen and graphviz/dot
•  You can also access the Doxygen documentation online.

http://www.openfoam.org/docs/cpp/
•  Documentation usage. In the terminal type:
acroread $WM_PROJECT_DIR/doc/Guides-a4/ProgrammersGuide.pdf
firefox file://$WM_PROJECT_DIR/doc/Doxygen/html/index.html
•  Notice that I am using acroread for opening the *.pdf files and firefox
for the *.html files.
•  The helper utility, foamHelp, allows the user to bring up documentation from
a terminal prompt. The foamHelp utility will give you more information on
boundary conditions and function objects.
•  To open the Doxygen documentation, e.g.
•  foamHelp boundary -browse fluxCorrectedVelocity
•  To list all boundary conditions for a given field, e.g.
•  foamHelp boundary -field p
•  To list fixed value patches for a given field, e.g.
•  foamHelp boundary -fixedValue -field U
•  To open the Doxygen documentation of a functionObject, e.g.
•  foamHelp functionObject -browse forces
•  To use the option –browse, you will need to compile the Doxygen
documentation.
•  To get more information on how to use foamHelp,

•  foamHelp boundary –help
•  foamHelp functionObject –help
•  A high-level view of the boundary conditions and function objects help can
also be accessed from the main Doxygen page, just look for the
Using the code section.
Now we are ready

to go bananas and
modify the case
•  Break time!!!
•  But it you want to keep playing with

OpenFOAM®, try to do as many changes as
you like to the case dictionaries and study the
output (specially the errors).
•  I would start by changing the mesh cell

number and the viscosity.
Today’s lecture

setup
My second OpenFOAM® case setup
Damp break free surface flow
l = 0.584 m
Gravity
0.146 m
Water column
h = 0.584 m
0.292 m
Y
X 0.048 m
(0,0,0)
0.024 m
Running the case
blockMesh
setFields
interFoam functionObjects
paraFoam
Mesh Initial conditions
VOF Fraction Pressure field
$PTOFC/first_tutorial/dampBreak
•  We will use the damp break tutorial for our second OpenFOAM® case setup.
•  In the directory $PTOFC/first_tutorial/dampBreak you will find this tutorial.
•  cd $PTOFC/first_tutorial/dampBreak
•  ls –l
•  blockMesh
•  checkMesh
•  cp 0/alpha.water.org 0/alpha.water
(This is done in order to keep a copy of the original alpha.water boundary and initials conditions. Why?, in the next
step we are going to use the utility setFields, which overwrites the file alpha.water)
•  setFields
(This utility will initialize fields according to an user criterion. It uses a dictionary, which is located in the directory system.
It will overwrite the initial conditions, so it is advisable to keep a backup of the files located in the directory 0)
•  Let us study all the dictionaries.
•  gedit constant/transportProperties
(Take a look at the dictionary and notice the differences with the previous case)
•  gedit constant/g
(Take a look at the new dictionary)
•  gedit 0/alpha.water.org
(Take a look at the original dictionary)
•  gedit 0/alpha.water
(Take a look at the modified dictionary, it might take a while to open)
•  gedit 0/U
(Take a look at the dictionary)
•  gedit 0/p_rgh
•  Let us study all the dictionaries.
•  gedit constant/polyMesh/blockMeshDict
•  gedit constant/polyMesh/boundary
•  gedit system/fvSchemes
(Take a look at the dictionary and identify the changes)
•  gedit system/fvSolution
•  gedit system/controlDict
•  gedit system/setFieldsDict
(Take a look at the new dictionary)
•  Now we are ready the run the simulation.
•  paraFoam –block
(This will use paraFoam blockMesh reader to visualize the blocks)
•  interFoam > log.interFoam | tail –f log.interFoam

(This will redirect your standard output to an ascii file with the name log.interFoam. If you do not add the
> log.interFoam modifier you will see your standard output stream on the fly and it will not be saved)
•  paraFoam
•  If you want to take a look at the residuals,
•  foamLog log.interFoam
(If you chose to redirect the standard output. This step is optional)
•  cd logs
(This step is optional)
•  gnuplot
(If you chose to redirect the standard output stream. We now use gnuplot to visualize the files in
the directory, if you do not know how to use gnuplot follow me. This step is optional)
These steps are optional
Today’s lecture

setup
My third OpenFOAM® case setup
•  At this point I think we all know

what we are doing.
•  If not, please raise your hand.
•  Unless it is strictly necessary,

from now on I will not go into
details about the dictionaries and
files we are using.
Flow around a cylinder
20
(0,0,0)
20
Y
20 Module'1')'Lecture'3'
30 100'
All the dimensions are in meters
Running the case
External
pre-processor
fluentMeshToFoam
ico/piso/simple/potentia/
Foam functionObjects
postProcessing
paraFoam
utilities
Mesh
Mean pressure field Mean velocity field
Instantaneous velocity magnitude field Instantaneous vorticity magnitude field
Aerodynamic coefficients for Reynolds 200
$PTOFC/first_tutorial/vortex_shedding
•  In this tutorial, we are going to learn how to setup the solvers potentialFoam,
simpleFoam, pisoFoam and pimpleFoam. We are also going to learn how to
setup a turbulent case and how to use a few utilities.
•  In the directory $PTOFC/first_tutorial/vortex_shedding you will find this

tutorial. In the terminal window type:
•  cd $PTOFC/first_tutorial/vortex_shedding
•  In this directory, you will find thirteen folders, each one representing a different case
setup. In the terminal window type:
•  ls –l
(Just to list all the directories and files)
•  Let us go first to the folder c2. In the terminal window type:
•  cd c2
•  ls –l

•  Let us go first to the folder c2. In this tutorial we convert the mesh from Fluent format
to OpenFOAM® format.
•  fluent3DMeshToFoam ../../../meshes/vortex_shedding/
ascii.msh
(This utility will convert the mesh to OpenFOAM®)
•  checkMesh
Note: In the folder c1 you will find theModule'1')'Lecture'3'

same setup, but to generate the mesh we use
109'
blockMesh
•  At this point, let us use gedit to modify the file constant/polyMesh/boundary,
in the terminal window type:
•  gedit constant/polyMesh/boundary
•  We manually edit the boundary dictionary because the utility

fluent3DMeshToFoam does not recognizes Fluent boundary conditions. There is
no clear, direct correspondence between OpenFOAM® and Fluent boundary
conditions.
•  Most of the times, when you convert a mesh from a third party format, you will need to
manually edit the boundary dictionary.
Note: In the folder c1 you will find theModule'1')'Lecture'3'

same setup, but to generate the mesh we use
110'
blockMesh
•  In the file constant/polyMesh/boundary, look for the entries back and front
and change them to:
back
{
type empty;
nFaces 9200;
startFace 18620;
}
front
{
type empty;
nFaces 9200;
startFace 27820;
}
•  We change the patches back and front from patch to empty, because it is a 2D
problem. The empty type patch means do not do anything in the third dimension.
•  After finishing the modifications to the file constant/polyMesh/boundary, in the
terminal window type:
•  checkMesh
•  icoFoam > log.icofoam | tail –f log.icofoam
•  pyFoamPlotWatcher.py log.icofoam
(To use this utility you need to install pyFoam. Also, you will need to open a new terminal window and go to the case
directory, if you are not already there)
•  paraFoam
•  At this point try to use the following utilities. In the terminal type:
•  vorticity –noZero
(This utility will compute and write the vorticity field. The –noZero option means do not compute the vorticity field for the
solution in the directory 0. If you do not add the –noZero option, it will compute and write the vorticity field for all the
saved solutions, including 0)
•  wallGradU –latestTime
(This utility will compute and write the velocity gradient at the walls. The –latestTime option means compute the
velocity gradient only for the last saved solution)
•  foamToVTK –time 50:300

(This utility will convert the saved solution from OpenFOAM® format to VTK format. The –time 50:300 option means
convert the solution to VTK format only for the time directories 50 to 300)
•  Co –noWrite
(This utility will compute and write the Courant number. The –noWrite option means do not write the Courant number
to the solution directories. It will only show you the minimum and maximum values for all the saved solutions, including
the directory 0)
•  As an exercise, try to use the following utilities:
•  stressComponents
•  wallShearStress
•  wallGradU
•  Q
•  Pe
•  yPlusRAS
•  refineWallLayer
•  refineHexMesh
•  renumberMesh
•  Be careful, some of these utilities will not run with this tutorial. Try to figure
out why.

•  Now try to do the rest of the cases.
•  Remember, each directory corresponds to a

different solver or setup, so try to figure out
what solver and setup we are using.
•  I have two words for you, thank you. This is what you will find in each
directory,
•  c1 = blockMesh – icoFoam – Re = 200.

•  c2 = fluentMeshToFoam – icoFoam – Re = 200.
•  c3 = blockMesh – potentialFoam – Re = 200.
•  c4 = blockMesh – mapFields – icoFoam – Re = 200.
•  c5 = blockMesh – mapFields – icoFoam – Re = 200, finer mesh.
•  c6 = blockMesh – pimpleFoam – Re = 200, no turbulence model.
•  c7 = blockMesh – pisoFoam – Re = 200, no turbulence model.
•  I have two words for you, thank you. This is what you will find in each
directory,
•  c8 = blockMesh – pimpleFoam – Re = 200, SST  !

turbulence model with wall functions.
turbulence model and no wall functions.
•  c11 = blockMesh – simpleFoam – Re = 100000, SST  !
•  c12 = blockMesh – pisoFoam – Re = 100000, LES Smagorinsky
turbulence model.
•  c13 = blockMesh – pimpleFoam – Re = 1000000, Spalart Allmaras
turbulence model.
Today’s lecture

setup
My first 3D OpenFOAM® case setup
Running the case
SALOME
blockMesh
Geometry module
snappyHexMesh
pimpleFoam functionObjects
postProcessing
paraFoam
utilities
Mesh
Cut planes colored by velocity magnitude, pressure and vorticity

Cut planes and Q criterion iso-surfaces
Streamlines
Q criterion iso-surfaces and pressure contours
Streamlines, Q criterion iso-surfaces and pressure contours
This geometry can be used to conduct an optimization study.
For instance, the goal can be to optimize the slant angle to obtain
the minimum drag.
$PTOFC/first_tutorial/ahmed_body
•  In this tutorial, we use pimpleFoam to solve a 3D case.
•  Running a 3D simulation is not different from the previous 2D simulations. The only
difference is that we need to define the boundary conditions in the third dimension.
•  It also requires more computational resources.
•  In the directory $PTOFC/first_tutorial/ahmed_body you will find this tutorial.
•  In the directory $PTOFC/first_tutorial/ahmed_body you will find this tutorial.
•  From this point on, please follow me. In the terminal window type:
•  cd $PTOFC/first_tutorial/ahmed_body
•  ls –l
•  blockMesh
(To generate the background mesh for snappyHexMesh)
•  surfaceFeatureExtract
(Extract geometry features for snappyHexMesh. We are going to talk about this utility later on)
•  snappyHexMesh –overwrite
(3D Mesh generation. We are going to talk about snappyHexMesh later on)
•  Do not worry, starting from tomorrow we are going to talk about what is happening
when we use the utilities blockMesh, surfaceFeatureExtract, and
snappyHexMesh.
•  Now we are ready to run the simulation.
•  checkMesh
•  pimpleFoam > log.pimplefoam | tail –f log.pimplefoam
•  pyFoamPlotWatcher.py log.pimplefoam
(You will need to open a new terminal window and go to the case directory, if you are not already there)
•  paraFoam
•  You do not need to run this case until the end time.
•  Just run a few time-steps, monitor the solution and try to do some
post-processing and visualization.
•  At this point, try to use the following utilities:
•  yPlusRAS –time 0.1:0.2

•  Q -latestTime
•  wallShearStress –latestTime
•  Co
•  vorticity –noZero
•  paraFoam -builtin

OpenFOAM® tutorials and additional tutorials
OpenFOAM® tutorials
•  The OpenFOAM® installation comes with many tutorials, try to do all of them (or at
least those that interest you).
Additional tutorials
•  In the course’s directory ($PTOFC) you will find many tutorials (which are different
from those that come with the OpenFOAM® installation), try to go through each one
to understand and get functional using OpenFOAM®.
•  In each tutorial directory there is a README.FIRST file. In this file you will find
general comments and the instructions of how to run the case
•  Let me know if a tutorial does not work or is outdated. It is a difficult task to maintain
all these tutorials.
•  Finally, fell free to bring your own cases.
Tutorials warning
•  Use the tutorials just for recreational, instructional, or
learning purposes and not for validation or
benchmarking.
Thank you for your attention
Today’s lecture

setup
Hands-on session
In the course’s directory ($PTOFC) you will find many tutorials (which are different from
those that come with the OpenFOAM® installation), let us try to go through each one to
understand and get functional using OpenFOAM®.
If you have a case of your own, let me know and I will try to do my best to help you to
setup your case. But remember, the physics is yours.
Module 2
Today’s lecture
1.  CFD simulation workflow
CFD simulation workflow
Geometry description
Mesh generation
Visualization
GEOMETRY
UP TO 70% OF USER TIME

THIS IS THE BOTTLENECK
MESHING
CASE SETUP UP TO 10% OF USER TIME
VISUALIZATION UP TO 20% OF USER TIME
The percentages shown are based on my personal experience.
GEOMETRY
MESH
PARAMETRIZATION
OPTIMIZATION
VISUALIZATION
Parametric or optimization approach – Simulation loop
PARALLEL ASYNCHRONOUS OR CONCURRENT DRIVER
MULTIDIMENSIONAL OR PARAMETRIC STUDY
DESIGN OF EXPERIMENTS
SENSITIVITY ANALYSIS
OPTIMIZATION STUDY
UNCERTAINTY QUANTIFICATION
ROBUST DESIGN AND OPTIMIZATION UNDER UNCERTAINTY
MULTIOBJECTIVE OPTIMIZATION
SURROGATE BASED OPTIMIZATION
HUMAN DECISION MAKER

DECISION MATRIX OR
GEOMETRY GEOMETRY GEOMETRY
MESH MESH MESH
SOLVER CO-PROCESSING SOLVER CO-PROCESSING SOLVER CO-PROCESSING
PARAMETRIZATION PARAMETRIZATION PARAMETRIZATION

OPTIMIZATION OPTIMIZATION OPTIMIZATION
VISUALIZATION VISUALIZATION VISUALIZATION
CASE 1 CASE 2 CASE N
AUTOMATIC POST-PROCESSING
Concurrent approach – Simulation nested loop
CASE SETUP POST
GEOMETRY MESHING
AND SOLVER PROCESSING
Salome blockMesh OpenFOAM® (FVM) paraFoam

Blender snappyHexMesh Code Saturne (FVM) paraView
Free-CAD Salome SU2 (FVM) VISIT
Google Sketch-Up Engrid Overture (FDM) Gnuplot
pythonOCC GMSH ELMER (FEM-DG) Scilab
Openscad TETGEN Fenics (FEM) Grace
OpenVSP pythonOCC OpenLB (LBM) Python
Calculix Palabos (LBM) Shell scripting
cfMesh R computational
statistics
This list does not enumerate all the open source applications available. It only shows those applications that7' I like
to use or I feel confortable with.
OpenFOAM built-in meshing technology
blockMesh or
external mesher
Background mesh Any commercial or open source CAD or solid modelling tool
snappyHexMesh
Geometry
foamyHexMesh
Any commercial or open source CAD or solid modelling tool (STL file)
blockMesh foamyQuadMesh
Salome cfMesh
OpenFOAM polyMesh
Any open source

TETGEN GMSH Netgen Engrid Calculix Commercial meshers
mesher
Any commercial or open source CAD or solid modelling tool
The diagram does not show all the applications available.
Module 2
Today’s lecture
1.  Geometry generation using open source

tools - Preliminaries
Geometry generation using open source tools
•  The best way to learn how to use the geometry

generation tools is by doing.
•  Hereafter we are going to show you how to get
started with the geometry generation tools. The
rest is on you.
•  There are many video tutorials available on
internet for each specific tool, so feel free to surf
the web.
•  There are always many ways to accomplish a

task when creating a geometry, this give you the
freedom to work in a way that is confortable to
you. Hereafter I am going to show you my way.
•  There is no wrong or right way to generate a

geometry. The only rule you should keep in mind
is that by the end of the day you should get a
unique clean and watertight geometry.
•  Remember, the quality of the mesh and hence of

the solution, greatly depends on the geometry.
So always do your best when creating the
geometry.
Potential geometry issues
•  Missing faces. •  Cracks.

•  Small faces. •  Gaps.
•  Misaligned faces. •  Free faces, edges, nodes.
•  Overlapping faces. •  Hard edges.
•  Sliver faces (high aspect-ratio). •  Small edges.
•  Repeated faces. •  Sharp angles.
•  Several surfaces connected to a •  Repeated edges.
single surface. •  High curvature NURBS.
.. among others.
These issues must be fixed in order to create a smooth, clean,

watertight body and to prevent meshing issues
Potential geometry issues
•  These issues must be fixed in order to create a smooth, clean,

watertight body and to prevent meshing issues
•  In general, when generating the geometry and by using good

geometry generation practices, we should not experience these
geometry issues.
•  At the end of the day we are interested in getting a smooth,

clean, watertight body.
•  Usually, we find these issues when importing or exporting the

geometry from/to different formats.
Remember, before going to the meshing stage we must fix/
cleanup the geometry.
So, how do we prepare the geometry for mesh generation?
•  Delete hard edges.

•  Delete small edges/faces.
•  Fill holes.
•  Split surfaces with high curvature.
•  Sew faces.
•  Remove sliver faces.
•  Connect/disconnected edges/faces.
•  Delete sharp edges.
•  Remove unnecessary details (defeaturing). This includes points, edges and
faces.
•  Boolean operations among bodies.
•  Decompose geometry into meshable sections.
Let us take a look at a corrupt or incomplete geometry

Geometry repair/cleanup
To improve quality, split the single surface

into two surfaces
Sew faces
Align faces
Delete overlapping faces
Connect/disconnect edges
•  Many times, it is not necessary to model all the details of the geometry. In these
cases you should consider simplifying the geometry (geometry defeaturing).
•  Geometry defeaturing can save you a lot of time when generating the mesh.
So be smart, and use it whenever is possible.
Original Geometry
Defeatured Geometry
•  Salome: is a history based CAD tool (parametric design). It has quite
extensive capabilities for creation and manipulation of solid geometries.
http://www.salome-platform.org/
•  Free-CAD: is a history based CAD tool (parametric design). Light CAD

software, good for not very complicated mechanical designs.
http://sourceforge.net/apps/mediawiki/free-cad/
•  Google Sketch-Up: is a direct 3D modeling tool. There are many plugins

available that extend Google Sketch-Up capabilities.
http://sketchup.google.com/
•  Blender: is a direct 3D modeling tool. Extremely powerful for surface

modeling and manipulation.
http://www.blender.org/
Friendliness/Easiness to use: Good Fairly Good Mild Bad Very Bad

•  pythonOCC: is a 3D CAD/CAE/PLM development framework for the Python
programming language. It provides features such as advanced topological
and geometrical operations, data exchange (STEP, IGES, STL import/export),
2D and 3D meshing, rigid body simulation, parametric modeling.
http://www.pythonocc.org/
•  Openscad: is a 3D programming modeling tool. It reads in a script file that

describes the object and renders the 3D model from this script file.
http://www.openscad.org/
•  OpenVSP: is a parametric aircraft geometry tool. It allows users to create a

3D model of an aircraft defined by common engineering parameters.
http://www.openvsp.org/
Friendliness/Easiness to use: Good Fairly Good Mild Bad Very Bad

Module 3
Meshing and mesh quality
This lecture is about meshing and mesh quality
assessment for CFD computations
Generating high quality meshes is a critical step for CFD computations.

Depending on the quality of the mesh you can get very different results,
which can made post-processing, validation, assessment and
interpretation of the solution a difficult task, due to contrasting or
misleading results because of meshing issues. This holds independently
of the solver used.
This lecture is about meshing and mesh quality
assessment for CFD computations
I do not know how much I will stress this, but try to always
use a good quality mesh.
Have always in mind, garbage in - garbage out.
As I am a really positive guy, I prefer to say,
good mesh - good results.
Who owns the mesh, owns the solution
Today’s lecture
1.  Meshing preliminaries
Meshing preliminaries
•  Mesh generation consist in dividing the physical domain into a finite number
of discrete regions, called control volumes or cells in which the solution is
sought (domain discretization).
•  Meshes used for the FVM method can consist of tetrahedras, pyramids,
prisms, hexes, dodecahedrons, or any kind of polyhedral element (or a mix
of all of them).
•  The meshes can be unstructured or structured (grids). In our discussion,

when we talk about unstructured or structured meshes we refer specifically
to the method used to generate them.
•  When we pass the mesh information to an unstructured FVM solver, we

pass the data structure, connectivity information (points, faces, and cells
information), neighbors information, and geometrical information (cell
volume, face area and so on).
•  In the next slides, I will show a few meshes generated by using different
meshing methods.
•  Also, I will present a table with a comparison of four commonly used mesh
generation methods.
•  The figures of merit used to compare the meshes are related to the method
used to generate the mesh and not to the flow solver.
•  All the methods that we are going to talk about, can generate a valid mesh
to be used with the FVM.
Single-block C-type structured grid around a NACA 4412 airfoil

Multi-block structured grid around a NLR 7301 airfoil with flap

Unstructured triangular meshModule'3')'Lecture'6'

around a NHLP-2D three element airfoil 11'
Overlapping structured grid around a NLR 7301 airfoil with flap

Cartesian mesh aroundModule'3')'Lecture'6'

a Drela DAE11 low Reynolds airfoil 13'
STRUCTURED UNSTRUCTURED CARTESIAN OVERLAPPING
Geometric Flexibility/
Adaptation
Grid Adaptation/
Local Refinement
Viscous Computation
Moving/Deforming
Meshes Quality
Interpolation/
Conservation
Grid generation
easiness
Memory
Requirements
CPU Requirements
Good Fairly Good Mild Bad Very Bad

Unstructured Vs. Structured meshes, Who wins?
A structured mesh requires as input
the blocking definition (blue lines in
the figure).
For complicated geometries, it can
be extremely difficult arrive to the
right blocking, it requires a lot user
experience.
After defining the blocking, the mesh
generation time is quite fast, in the
order of seconds or minutes.
Unstructured meshes, only requires

as input the element size on the lines
and surfaces that define the
geometry.
After defining the element size, the
meshing process can be quite time
consuming and memory expensive.
Meshing time is in the order of
minutes or hours, even days.
Unstructured Hybrid Mesh

(tetras, prisms and hexs)
Cell count:
approx. 5 000 000
Structured Mesh
(hexahedrals)
Cell count:
approx. 5 000 000

Cell count:
approx. 5 000 000
Structured Mesh
(hexahedrals)
Cell count:
approx. 5 000 000

Cell count:
approx. 5 000 000
Structured Mesh
(hexahedrals)
Cell count:
approx. 5 000 000

Cell count:
approx. 5 000 000
Structured Mesh
(hexahedrals)
Cell count:
approx. 5 000 000

Cell count:
approx. 5 000 000
Structured Mesh
(hexahedrals)
Cell count:
approx. 5 000 000

Cell count:
approx. 5 000 000
Structured Mesh
(hexahedrals)
Cell count:
approx. 5 000 000
Unstructured Vs. Structured meshes,
Who wins?
•  Each mesh type has its advantages and disadvantages.
•  From a practical point of view, the time invested to setup and generate the
mesh should be reasonable. It must meet your project requirements in
terms of time frame.
•  The mesh density should be high enough to capture all relevant flow
features, without degenerating due to clustering or stretching.
•  At the end of the day, the mesh you use must has a good overall quality
and must be smooth.
•  But wait, what is a good mesh?. Mesh quality and smoothness will be
studied in the next lecture. Module'3')'Lecture'6' 23'
What cell type do I use?
•  It is clear from the previous discussion that the cell type,
depends on the mesh type.
•  Structured meshes are made of hexahedra.
•  Unstructured meshes are mainly made of tetrahedral,

pyramids, hexahedra, and prisms (hybrid meshes).
•  By the way, there is a new guy in town, polyhedral cells.

This type of cells have very interesting properties.
What cell type do I use?
•  Each cell type has its very own properties when it comes to
domain discretization, we are going to talk about this later on
when we deal with the FVM.
Module 3
Today’s lecture
1.  Mesh quality assessment in OpenFOAM®
Mesh quality assessment
What is a good mesh?
•  There is no written theory when it comes to mesh generation. Basically, the
whole process depends on user experience.
•  A standard rule of thumb is that the elements shape and distribution should
be pleasing to the eye.
22rd IMR Meshing Maestro Contest Winner

Travis Carrigan, John Chawner and Carolyn Woeber. Pointwise.
http://imr.sandia.gov/22imr/MeshingContest.html
•  The user can rely on grid dependency studies, but they are time consuming
and expensive.
Coarse mesh Medium mesh Fine mesh Extra fine mesh
Cells ≈ 3 500 000 ≈ 11 000 000 ≈ 36 000 000 ≈ 105 000 000
CD 0.0282 0.0270 0.0268 0.0269
CM -0.0488 -0.0451 -0.0391 -0.0391
4th AIAA CFD Drag

Prediction Workshop
•  No single standard benchmark or metric exists that can effectively assess
the quality of a mesh, but you can rely on suggested best practices.
•  After generating the mesh, we measure these quality metrics and we use
them to assess mesh quality.
•  Hereafter, I will present you the most common mesh quality metrics:
•  Orthogonality.
•  Skewness.
•  Aspect Ratio.
•  Smoothness.
Mesh quality metrics. Mesh orthogonality
•  Mesh orthogonality is the angular deviation of the vector S (located at the
face center f ) from the vector d connecting the two cell centers P and N. In
this case is 20 .
•  Affects the gradient of the face center f.
•  It adds diffusion to the solution.
•  It mainly affects the diffusive terms.
S
d
P f N
Mesh quality metrics. Mesh skewness
•  Skewness is the deviation of the vector d that connects the two cells P and
N, from the face center f. The deviation vector is represented with
and fi is the point where the vector d intersects the face f .
•  Affects the interpolation of the cell centered quantities to the face center f.
•  It adds diffusion to the solution.
•  It affects the convective terms.
f S
P
Di
d fi
N
Mesh quality metrics. Mesh aspect ratio AR
•  Mesh aspect ratio AR is the ratio between the longest side x and the
shortest side y .
•  Large AR are ok if gradients in the largest direction are small.
•  High AR smear gradients.
Dy
Dx
Mesh quality metrics. Smoothness
•  Smoothness, also known as expansion rate, growth factor or uniformity,
defines the transition in size between contiguous cells.
•  Large transition ratios between cells add diffusion to the solution.
•  Ideally, the maximum change in mesh spacing should be less than 20%:
y2
 1.2
y1
Dy2
Dy1
Steep transition Smooth transition
Element type close to the walls -
Cell/Flow alignment
•  Hexahedrals, prisms, and quadrilaterals can be stretched easily to resolve
boundary layers without losing quality.
•  Triangular and tetrahedral meshes have inherently larger truncation error.
•  Less truncation error when faces aligned with flow direction and gradients.
P f f
Dy
P
⇥ 2 ⇥
f = P + y + O( yModule'3')'Lecture'7'
) f = P + y + O( 10'y 2 )
⇥y ⇥y
Striving for quality
•  For the same cell count, hexahedral meshes will give more accurate
solutions, especially if the grid lines are aligned with the flow.
•  But this does not mean that tetra meshes are no good, by carefully choosing
the numerical scheme you can get the same level of accuracy as in hex
meshes. The problem with tetra meshes are mainly related to the way
gradients are computed.
Tetra
QOI
Hexa
Year
•  Hexahedrals, prisms, and quadrilaterals can be easily aligned with the flow.
•  They can also be stretched to resolve boundary layers without losing much
quality.
•  Triangular and tetrahedral meshes can easily be adapted to any kind of

geometry. The mesh generation process is almost automatic.
•  Triangular and tetrahedral meshes have inherently larger truncation error.
•  Tetra meshes normally need more computing resources during the solution
stage. But his can be easily offset by the time saved during the mesh
generation stage.
•  Increasing the cells count will likely improve the solution accuracy, but at the
cost of a higher computational cost.
•  But attention, finer mesh does not mean a good or better mesh. After
refining your mesh, always check the quality metrics.
•  And by the way, you can combine all cell types to get a hybrid mesh.
•  The mesh density should be high enough to capture all relevant flow
features. In areas where the solution change slowly, you can use larger
elements. A good mesh does not rely in the fact that the more cells we use
the better the solution.
23rd IMR Meshing Maestro Contest Winner

Zhoufang Xiao , Jianjing Zheng, Dawei Zhao, Lijuan Zeng, Jianjun Chen, Yao Zheng
Center for Engineering & Scientific Computation, Zhejiang University, China.
http://www.sandia.gov/imr/MeshingContest.html
•  To keep cell count low, use non-uniform meshes to cluster cells only where
they are needed. Use local refinements and solution adaption to further
refine only on selected areas.
•  In boundary layers, quad, hex, and prism/wedge cells are preferred over
triangles, tetrahedras, or pyramids.
•  If you are not using wall functions (turbulence modeling), the mesh adjacent
to the walls should be fine enough to resolve the boundary layer flow. Have
in mind that this will rocket the cell count and increase the computing time.
•  Use hexahedral meshes whenever is possible, specially if high accuracy in

predicting forces is your goal (drag prediction) or for turbo machinery
applications.
•  For complex flows without dominant flow direction, quad and hex meshes
loose their advantages.
•  Keep orthogonality, skewness, and aspect ratio to a minimum.
•  Change in cell size should be smooth.
•  Always check the mesh quality. Remember, one single cell can cause
divergence or give you inaccurate results.
•  Plan your meshing approach.
•  When you strive for quality, you avoid the GIGO syndrome.
•  Remember, a poor quality mesh will generate inaccurate

solutions, questionable results and/or will slow down
solution convergence.
•  Just to end for good the mesh talk:
•  A good mesh is a mesh that serves your project objectives.
•  So, as long as your results are physically realistic, reliable and accurate;
your mesh is good.
•  At the end of the day, the final mesh will depend on the physic involve.
•  Know your physics and generate a mesh able to resolve that physics,
without over-doing.
Mesh quality metrics in OpenFOAM®
Mesh quality metrics in OpenFOAM®
•  In $WM_PROJECT_DIR/src/OpenFOAM/meshes/primitiveMesh/
primitiveMeshCheck/primitiveMeshCheck.C you will find the
quality metrics used in OpenFOAM®. Their maximum (or minimum) values
are defined as follows:
•  Foam::scalar Foam::primitiveMesh::closedThreshold_ = 1.0e-6;

•  Foam::scalar Foam::primitiveMesh::aspectThreshold_ = 1000;
•  Foam::scalar Foam::primitiveMesh::nonOrthThreshold_ = 70; // deg
•  Foam::scalar Foam::primitiveMesh::skewThreshold_ = 4;
•  Foam::scalar Foam::primitiveMesh::planarCosAngle_ = 1.0e-6;
Checking mesh quality in OpenFOAM®
•  OpenFOAM® comes with the utility checkMesh which checks the validity of
the mesh.
•  checkMesh will look for/check for:
•  Mesh stats and overall number of cells of each type.
•  Check topology (boundary conditions definitions).
•  Check geometry and mesh quality (bounding box, cell volumes,
skewness, orthogonality, aspect ratio, and so on).
•  If for any reason checkMesh finds errors, it will give you a message and it
will tell you what check failed.
•  It will also write a set with the faulty cells, faces, and/or points. These sets
are saved in the directory constant/polyMesh/sets/
•  Mesh topology and patch topology errors must be repaired.
•  You will be able to run with mesh quality errors such as skewness, aspect
ratio, minimum face area, and non-orthogonality. But remember, they will
severely tamper the solution accuracy, might give you strange results, and
eventually can made the solver blow-up.
•  Unfortunately, checkMesh does not repair these errors. You will need to
check the geometry for possible errors and generate a new mesh.
•  To visualize the failed sets you can use the utility foamToVTK. This utility
converts the failed sets to VTK format.
•  To visualize the failed faces/cells/points in paraFoam you will need to

proceed as follows:
•  foamToVTK -set_type name_of_sets
where set_type is the type of sets ( faceSet, cellSet, pointSet,

surfaceFields) and name_of_sets is the name of the set in the directory
constant/polyMesh/sets (highAspectRatioCells,
nonOrthoFaces, wrongOrientedFaces, skewFaces,
unusedPoints, and so on)
•  At the end, foamToVTK will create a directory named VTK, where you will find the
failed faces/cells/points in VTK format. At this point you can use paraFoam to
visualize the failed sets.
•  Alternatively, you can load the failed sets

directly within paraFoam.
•  In paraFoam, simply select the option
Include Sets and then select the sets you
want to visualize.
•  Remember, you will need to create the sets.
To do so just run the checkMesh utility, if
there are problems in the mesh checkMesh
will automatically save the sets in the
directory constant/polyMesh/sets
•  Personally speaking, I do prefer to use foamToVTK.
•  Let us check the mesh quality of a tricky geometry.

•  For this we will use the wing body case that you will
find in the directory:
$PTOFC/mesh_conversion_manipulation/
M2_wingbody
•  In the directory
$PTOFC/mesh_conversion_manipulation/M2_wingbody you will
find this tutorial.
We will now check the mesh quality of a sample case. From now on follow me.
•  Go to the directory $PTOFC/mesh_conversion_manipulation/

M2_wingbody. In the terminal type:
•  cd $PTOFC/mesh_conversion_manipulation/M2_wingbody
•  fluent3DMeshToFoam ../../meshes/M2_wingbody/ascii.msh
•  checkMesh
(It will automatically generate the failed sets, if there are any)
At this point, read the screen output and try to assess the mesh quality.
Is it a good mesh?
•  The utility checkMesh will automatically write the failed sets (if there are
any). The information related to the faulty sets is saved in the directory
constant/polyMesh/sets
•  In the terminal type:
•  ls constant/polyMesh/sets
What faulty sets do you see?
•  To visualize the failed sets you can to convert them to VTK format:
•  foamToVTK -faceSet nonOrthoFaces

•  foamToVTK -pointSet unusedPoints
•  paraFoam
foamToVTK will write the faulty sets in the directory ./VTK
•  At this point you can visualize the faulty sets by using paraFoam.
•  Alternatively, you can open the faulty sets directly in paraFoam
(as previously explained).
By following the instructions, you should get something like this
Non orthogonal faces (green) and unused points (yellow)
Non orthogonal faces (green) and unused points (yellow)
Removing bad quality sets from the mesh in

OpenFOAM®
Removing bad quality sets from the mesh
•  It is possible to remove the bad quality sets (cells, faces, points) detected by
checkMesh. This is mesh manipulation.
•  You can do this by using the utilities topoSet and subsetMesh.
•  The utility topoSet operates on cellSets/faceSets/pointSets

through the dictionary topoSetDict. You can use this utility to create or
manipulate sets.
•  subsetMesh selects a section of the mesh based on a cellSet. To create

a cellSet we use topoSet.
•  Just to make it clear, the sets created or manipulated by topoSet are

located in the folder constant/polyMesh/sets.
•  These sets are later used by subsetMesh to create a new polyMesh using
the information contained in the cellSet.
•  By the way, removing the bad quality sets is not the solution to the meshing
problems.
•  I am just showing you how to manipulate the mesh using the faulty sets.
•  Let us remove the nonOrthoFaces from the polyMesh. From now on
follow me.
•  checkMesh
(It will automatically generate the failed sets)
•  topoSet
(It will create the cellSet that we will use with subsetMesh. It reads the dictionary system/topoSetDict)
•  subsetMesh newcells
(It uses the set newcells created with topoSet, to create a new polyMesh. The new polyMesh will not contain the
cells connected to the nonOrthoFaces faces)
•  checkMesh -time 1
(It will check the new polyMesh. It will give a few errors related to the patch oldInternalFaces. The error is due to
the fact that by default oldInternalFaces is set to empty patch type. To remove the error, change the patch type of
oldInternalFaces to the type patch or wall. You will need to do this modification in the file constant/
polyMesh/boundary. By the way and in case you did not notice it, there are no more non-orthogonality problems)
•  paraFoam
•  This trick, will remove the bad quality cells, but not necessary the new mesh
is a good one. Just take a look at the surface.
•  You can also manually modify the polyMesh.
•  It is quite easy to understand the polyMesh format. It works like a linked

list.
•  If you often use similar meshes and you know where exactly are the errors,
you can write a small script to modify your mesh, I have mine that works on
very specific meshes.
Module 3
Today’s lecture
1.  Mesh conversion

Today’s lecture
1.  Mesh conversion

Mesh conversion
•  OpenFOAM® gives users a lot of flexibility when it comes to meshing.
•  You are not constrained to use OpenFOAM® meshing tools.
•  To convert a mesh generated with a third party software to OpenFOAM®

polyMesh format, you can use the OpenFOAM® mesh conversion utilities.
•  If your format is not supported, you can write your own conversion tool.
•  By the way, many of the commercially available meshers can save the mesh
in OpenFOAM® polyMesh format or in a compatible format.
Mesh conversion
•  Some of the utilities available for mesh conversion are listed below:
•  ansysToFoam: converts an ANSYS input mesh file OpenFOAM® format.
•  cfx4ToFoam: converts a CFX 4 mesh to OpenFOAM® format.
•  fluent3DMeshToFoam: converts a Fluent mesh to OpenFOAM® format.
•  gambitToFoam: converts a GAMBIT mesh to OpenFOAM® format.
•  gmshToFoam: reads .msh file as written by Gmsh.
•  ideasUnvToFoam: I-Deas unv format mesh conversion.
•  plot3dToFoam: plot3d mesh (ascii/formatted format) converter.
•  star4ToFoam: converts a STAR-CD (v4) PROSTAR mesh into OpenFOAM®
format.
•  tetgenToFoam: Converts .ele and .node and .face files, written by tetgen.
In the User Guide you will find the complete listing

Mesh conversion
Ansys CFX Fluent 2D mesh Fluent 3D mesh Gambit GMSH
ansysToFoam cfx4ToFoam fluentMeshToFoam fluent3DMeshToFoam gambitToFoam gmshToFoam
Ideas UNV
ideasUnvToFoam
KIVA3D
kivaToFoam
Mesh adventure system

mshToFoam
netgen
OpenFOAM polyMesh
netgenNeutralToFoam
plot3d
plot3dToFoam
starCD-samm mesh
sammToFoam
starCD-prostar
star4ToFoam
starCD-smap
smapToFoam
Your own format and Any commercial or open starCCM 2.6 CGNS VTK Legacy format Tetgen
converter source application that ccm26ToFoam cgnsToFoam vtkUnstructuredToFoam tetgenToFoam
produces an output in
any of the previous
formats Requires CD-adapco
Extended version
ccmio library
The diagram is not complete. Refer to the user guide or source code to
get more information about all the conversion utilities available in
OpenFOAM®
Mesh conversion
(version 2.3.x):
•  mesh
•  surface
•  Thermophysical
•  In the sub-directory mesh you will find the source code for the mesh utilities included
in the OpenFOAM® installation.
Mesh conversion
•  Let us visit the mesh directory. In the terminal type:
•  util
•  cd mesh
•  In this directory you will find the directories containing the source code for the
following mesh utilities
•  advanced
•  conversion
•  generation
•  manipulation
•  In the directory conversion you will find the utilities source code for the mesh
conversion utilities. Let us visit this directory, in the terminal type:
•  cd conversion
•  ls -l
Mesh conversion
•  In the directory $FOAM_UTILITIES/mesh/conversion you will find the following
mesh conversion utilities:
•  ansysToFoam •  kivaToFoam
•  cfx4ToFoam •  mshToFoam
•  datToFoam •  netgenNeutralToFoam
•  fluent3DMeshToFoam •  Optional/ccm26ToFoam
•  fluentMeshToFoam •  plot3dToFoam
•  foamMeshToFluent •  sammToFoam
•  foamToStarMesh •  star3ToFoam
•  foamToSurface •  star4ToFoam
•  gambitToFoam •  tetgenToFoam
•  gmshToFoam •  vtkUnstructuredToFoam
•  ideasUnvToFoam •  writeMeshObj
For more information about the mesh conversion

utilities, refer to theModule'3')'Lecture'8'
User Guide 9'
Mesh conversion
•  Let us do some mesh conversion.

•  Our first case will be the mixing elbow, which you will
find in the directory:
M3_mixing_elbow_salome
Mesh conversion
•  In the directory $PTOFC/
mesh_conversion_manipulation/
M3_mixing_elbow_salome you will find this tutorial.
Mesh conversion
Case 1. Mixing elbow (internal mesh).
Let us convert to OpenFOAM® a mesh generated using Salome.
From now on, follow me.
our mesh in Salome looks like this one. 12'
Mesh conversion
Let us convert to OpenFOAM® a mesh generated using Salome.
Remember to export the mesh in UNV format in Salome. Then use the mesh
converter utility ideasUnvToFoam to convert the mesh to OpenFOAM® native format.
In the terminal window type:
•  cd $PTOFC/mesh_conversion_manipulation/
M3_mixing_elbow_salome
•  ideasUnvToFoam ../../meshes/M3_mixing_elbow_salome/
Mesh_1.unv
(To convert the mesh to polyMesh from ideas format)
•  checkMesh
•  paraFoam
Mesh conversion
•  The next example is a square tube with periodic

boundary conditions. You will find this tutorial in the
directory:
M1_square_tube_periodic
Mesh conversion
M1_square_tube_periodic you will find this tutorial.
Mesh conversion
Case 2. Square tube with periodic boundary conditions
(external mesh).
Let us convert the mesh from fluent format to OpenFOAM® format.

M1_square_tube_periodic
•  fluent3DMeshToFoam ../../meshes/M1_square_tube_periodic/
ascii.msh
Attention: The mesh must be in ascii format
•  createPatch –overwrite –noFunctionObjects

(This utility is used to create the periodic patches. By the way, take a look at the dictionary createPatchDict)
•  checkMesh –time 0
•  paraFoam
Mesh conversion
•  Let us go back to the mixing elbow mesh, our task

now is to convert the tetrahedral mesh to a general
polyhedral mesh. You will find this tutorial in the
directory:
M7_polydualmesh/
Mesh conversion
mesh_conversion_manipulation/M7_polydualmesh/
you will find this tutorial.
Mesh conversion
Case 3. Polyhedral mesh.
And at the end, our Module'3')'Lecture'8'

mesh should looks like this one. 19'
Mesh conversion
And at the end, our Module'3')'Lecture'8'

mesh should looks like this one. 20'
Mesh conversion
The utility polyDualMesh only works with tetrahedral meshes
Mesh conversion
•  In this tutorial we are going to generate a polyhedral mesh.
•  First we need to generate a tetrahedral mesh and then we need to convert it to
polyhedral mesh by using the utility polyDualMesh.
•  From now on, you can follow me. In the terminal type:
•  cd $PTOFC/mesh_conversion_manipulation/M7_polydualmesh/
•  ideasUnvToFoam ../../meshes/M3_mixing_elbow_salome/
Mesh_1.unv
(This mesh already has the patches assigned, you do not need to use the utility autoPatch)
•  checkMesh
(To check the mesh before converting it to polyhedral type)
•  polyDualMesh 30 –concaveMultiCells –overwrite

–noFunctionObjects
(This utility will convert a tetra mesh to polyhedral mesh)
•  checkMesh
(To check the mesh after converting it to polyhedral type)
•  paraFoam
Mesh conversion
•  Our final example is the static mixer mesh. You will

find this case in the directory:
M9_static_mixer_gmsh
Mesh conversion
M9_static_mixer_gmsh you will find this tutorial.
Mesh conversion
Static mixer geometry
Mesh conversion
Static mixer mesh
Tetra mesh Polyhedral mesh
Mesh conversion
Case 4. Static mixer (internal mesh).
Let us convert the mesh from GMSH format to OpenFOAM® format.
In the terminal type:
•  cd $PTOFC/mesh_conversion_manipulation/M9_static_mixer_gmsh
(The geometry is in the directory ./geometry)
•  gmshToFoam ../../meshes/M9_static_mixer_gmsh/
staticmixer.msh
(If you generated a mesh of your own, just add the right file name and path)
•  autoPatch 45 –overwrite -noFunctionObjects

(This utility will automatically find the patches according to a given angle criterion)
•  checkMesh
•  paraFoam
Mesh conversion
Case 4. Static mixer (internal mesh).
Let us convert the mesh from GMSH format to OpenFOAM® format.
•  Now that we have a polyMesh and we used the utility autoPatch to

automatically find the boundary patches, let us setup this case and in no
more than 20 minutes.
•  Can you convert the tetrahedral mesh to a general polyhedral mesh?
•  Do you take the challenge?
•  If you find it hard, try to use Helyx-os.

Mesh conversion
In the directories $PTOFC/sHM, and $PTOFC/mesh_conversion_manipulation
and $PTOFC/geometries_meshers_tutorials, you will find many tutorials, try to
go through each one to understand and get functional using the meshing tools.
Module 3
Today’s lecture
1.  Geometry and mesh manipulation utilities

Today’s lecture
1.  Geometry and mesh manipulation utilities

Geometry and mesh manipulation utilities
•  First at all, by mesh manipulation I mean modifying

OpenFOAM® polyMesh format.
•  The modifications can be scaling, rotation, translation, mirroring,

topological changes, mesh refinement and so on.
•  OpenFOAM® comes with many mesh manipulation utilities. Some of them
are listed below:
•  checkMesh: checks validity of a mesh.
•  mirrorMesh: mirrors a mesh around a given plane.
•  setSet: manipulate a cell/face/point/ set or zone interactively.
•  splitMeshRegions: splits mesh into multiple regions.
•  refineWallLayer: utility to refine cells next to patches.
•  refineMesh: utility to refine cells in multiple directions.
•  renumberMesh: renumbers the cell list in order to reduce the bandwidth,
reading and renumbering all fields from all the time directories.
•  topoSet: operates on cellSets/faceSets/pointSets through a dictionary.
•  transformPoints: transforms the mesh points in the polyMesh directory
according to the translate, rotate and scale options.

(version 2.3.x):
•  mesh
•  surface
•  In the sub-directory mesh you will find the source code for the mesh utilities in the
OpenFOAM® installation.
•  Let us visit the mesh directory. In the terminal type:
•  util
•  cd mesh
following mesh utilities
•  advanced
•  conversion
•  generation
•  manipulation
•  In the directory manipulation you will find the utilities source code for the mesh
manipulation utilities. Let us visit this directory, in the terminal type:
•  cd manipulation
•  ls -l
•  In the directory $FOAM_UTILITIES/mesh/manipulation you will find the
following mesh manipulation utilities:
•  attachMesh •  orientFaceZone
•  autoPatch •  polyDualMesh
•  checkMesh •  refineMesh
•  createBaffles •  renumberMesh
•  createPatch •  rotateMesh
•  deformedGeom •  setSet
•  flattenMesh •  setsToZones
•  insideCells •  singleCellMesh
•  mergeMeshes •  splitMesh
•  mergerOrSplitBaffles •  splitMeshRegions
•  mirrorMesh •  stitchMesh
•  moveDynamicMesh •  subsetMesh
•  moveEngineMesh •  topoSet
•  moveMesh •  transformPoints
•  objToVTK •  zipUpMesh
For more information about the mesh manipulation utilities, refer to the User Guide
•  Inside each utility directory you will find a *.C file with the same name as
the directory. This is the main file, where you will find the top-level source
code and a short description of the utility.
•  For instance, in the directory checkMesh, you will find the file
checkMesh.C, which is the source code of the utility checkMesh. In the
source code you will find the following description:
Checks validity of a mesh.
Usage
- checkMesh [OPTION]
\param -allGeometry \n
Checks all (including non finite-volume specific) geometry
\param -allTopology \n
Checks all (including non finite-volume specific) addressing
\param -meshQuality \n
Checks against user defined (in \a system/meshQualityDict) quality settings
\param -region \<name\> \n

Specify an alternative mesh region.
Take your time and dig into each directory to get a complete description of each utility.
•  In OpenFOAM® it is also possible to manipulate the geometries in STL
format. Some of the utilities available are listed below:
•  surfaceAutoPatch: patches surface according to feature angle.
Like autoPatch.
•  surfaceCheck: checks geometric and topological quality of a surface.
•  surfaceClean: removes baffles and collapses small edges, by removing
triangles. Converts sliver triangles into split edges.
•  surfaceFeatureExtract: extracts and writes surface edge features to file.
•  surfaceMeshInfo: miscellaneous information about surface.
•  surfaceMeshTriangulate: extracts triSurface from a polyMesh.
•  surfaceTransformPoints: transform (scale/rotate) a surface. Like
transformPoints but for surfaces.

(version 2.3.x):
•  mesh
•  surface
•  In the sub-directory surface you will find the source code for the surface
manipulation utilities in the OpenFOAM® installation.
•  Let us visit the surface directory. In the terminal type:
•  util
•  cd surface
•  In this directory you will find the directories containing the source code for the surface
manipulation utilities.
•  Let us see what is inside this directory, in the terminal type:

•  ls -l
•  In the directory $FOAM_UTILITIES/surface you will find the following surface
manipulation utility directories:
•  surfaceAdd •  surfaceMeshExport
•  surfaceAutoPatch •  surfaceMeshImport
•  surfaceBooleanFeatures •  surfaceMeshInfo
•  surfaceCheck •  surfaceMeshTriangulate
•  surfaceClean •  surfaceOrient
•  surfaceCoarsen •  surfacePointMerge
•  surfaceConvert •  surfaceRedistributePar
•  surfaceFeatureConvert •  surfaceRefineRedGreen
•  surfaceFeatureExtract •  surfaceSplitByPatch
•  surfaceFind •  surfaceSplitByTopology
•  surfaceHookUp •  surfaceSplitNonManifolds
•  surfaceInertia •  surfaceSubset
•  surfaceLambdaMuSmooth •  surfaceToPatch
•  surfaceMeshConvert •  surfaceTransformPoints
•  surfaceMeshConvertTesting
For more information about the surface manipulation utilities, refer to the User Guide
•  For instance, in the directory surfaceTransformPoints, you will find the
file surfaceTransformPoints.C, which is the source code of the utility
surfaceTransformPoints. In the source code you will find the following
description:
Transform (scale/rotate) a surface.

Like transformPoints but for surfaces.
The rollPitchYaw option takes three angles (degrees):
-  roll (rotation about x) followed by
-  pitch (rotation about y) followed by
-  yaw (rotation about z)
The yawPitchRoll does yaw followed by pitch followed by roll.
Take your time and dig into each directory to get a complete description of each utility.
•  We will now do some surface manipulation.

•  For this we will use the ahmed body tutorial located in
the directory:
M6_ahmed_body_transform
M6_ahmed_body_transform you will find this tutorial.
STL surface manipulation

Geometry manipulation in OpenFOAM®
•  We will now manipulate a STL geometry. From now on follow me.
M6_ahmed_body_transform. In the terminal type:
M6_ahmed_body_transform
•  surfaceMeshInfo ./constant/triSurface/ahmed_body.stl
•  surfaceCheck ./constant/triSurface/ahmed_body.stl
•  surfaceTransformPoints -rollPitchYaw '(0 0 15)’./constant/
triSurface/ahmed_body.stl ./constant/triSurface/rotated.stl
Note: in this case we only manipulated the STL file.
Geometry manipulation in OpenFOAM®
•  We will now manipulate a STL geometry. From now on follow me.
M6_ahmed_body_transform. In the terminal type:
•  surfaceTransformPoints -translate '(0 0.12 0)' ./constant/

triSurface/rotated.stl ./constant/triSurface/
translated.stl
•  surfaceTransformPoints -scale '(0.9 1.1 1.3)' ./constant/
triSurface/translated.stl ./constant/triSurface/
scaled.stl
•  surfaceInertia -density 2700 –noFunctionObjects ./constant/
triSurface/ahmed_body.stl
•  surfaceClean ./constant/triSurface/scaled.stl 1 100 ./
constant/triSurface/smooth.stl
Note: in this case we only manipulated the STL file.
•  We will now do some mesh manipulation.

•  Remember when I told you not to forget about the
cylinder geometry?. Guess what?. We are going to
use it again.
•  For this we will use the heated body tutorial located in
the directory:
M10_cylinder_transform
Mesh manipulation
M10_cylinder_transform you will find this tutorial.
Temperature
Mesh manipulation in OpenFOAM®
•  We will now manipulate a mesh. From now on follow me.
M10_cylinder_transform. In the terminal type:
•  cd $PTOFC/mesh_conversion_manipulation/M10_cylinder_transform
•  blockMesh
•  transformPoints -rollPitchYaw '(0 0 90)'
•  transformPoints -scale '(0.01 0.01 0.01)’
•  createPatch -noFunctionObjects –overwrite
(It reads the dictionary system/createPatchDict)
•  checkMesh
•  paraFoam
Note: in this case we manipulated the mesh.
•  We will now do some mesh manipulation. This time we

are going to mirror a mesh.
•  For this we will use the wing body tutorial located in
the directory:
M2_wingbody
mesh_conversion_manipulation/M2_wingbody you will
find this tutorial.
Original mesh Mirrored mesh
Geometry and mesh manipulation in OpenFOAM®
•  We will now manipulate a mesh. From now on follow me.
•  Go to the directory $PTOFC/mesh_conversion_manipulation/M2_wingbody. In the
terminal type:
•  cd $PTOFC/mesh_conversion_manipulation/M2_wingbody
•  blockMesh
•  fluent3DMeshToFoam ../../meshes/M2_wingbody/ascii.msh
•  checkMesh
•  mirrorMesh –noFunctionObjects
(This utility uses the dictionary mirrorMeshDict, located in the directory system)
•  checkMesh
•  foamToVTK -faceSet nonOrthoFaces
•  foamToVTK -pointSet unusedPoints
•  paraFoam
Note: in this case we manipulated the mesh.
In the directories $PTOFC/sHM, and $PTOFC/mesh_conversion_manipulation,
you will find many tutorials, try to go through each one to understand and get functional
using the meshing tools.
Module 3
Today’s lecture
1.  Mesh generation using blockMesh and

snappyHexMesh - Workflow.
2.  A few snappyHexMesh meshing cases.
3.  Hands-on session.
Today’s lecture

Mesh generation using blockMesh and snappyHexMesh
•  OpenFOAM® comes with its own meshing applications.
•  If you are not confortable using OpenFOAM® meshing applications, you can
use an external mesher.
•  OpenFOAM® comes with many mesh conversion utilities. Many popular

meshing formats are supported. To name a few: cfx, fluent, gmsh, ideas,
netgen, plot3d, starccm, VTK.
•  In this training, we are going to address how to mesh using OpenFOAM®

technology.
•  OpenFOAM® comes with the following meshing applications:
•  blockMesh
•  foamyHexMesh
•  foamyQuadMesh
•  You can find the source code of these applications in the directory:
•  $WM_PROJECT_DIR/applications/utilities/mesh/generation
•  In this directory you can also find the master dictionaries for each meshing
application.
blockMesh
•  “blockMesh is a multi-block mesh generator.”
•  For simple geometries, the mesh generation utility blockMesh can be used.
•  The mesh is generated from a dictionary file named blockMeshDict located in

the constant/polyMesh directory.
•  The blockMeshDict can be parameterize using m4.
•  We are going to address m4 scripting later on.
•  We are going to work with this application, in the training material you will
find many tutorials.
blockMesh
snappyHexMesh
•  “Automatic split hex mesher. Refines and snaps to surface.”
•  For complex geometries, the mesh generation utility snappyHexMesh can be

used.
•  The snappyHexMesh utility generates 3D meshes containing hexahedra and

split-hexahedra from a triangulated surface geometry in Stereolithography
(STL) format.
•  The mesh is generated from a dictionary file named snappyHexMeshDict

located in the system directory and a triangulated surface geometry file
located in the directory constant/triSurface.
•  We are going to address how to use this tool, in the training material you will
find many tutorials.
snappyHexMesh
blockMesh workflow
blockMesh workflow
•  As we are going to use blockMesh to generate the background mesh, I am
going to briefly address how blockMesh works.
•  As the background mesh consist of a single block (most of the times),

blockMesh can be used with no problem.
•  It is highly recommended to create a template of the dictionary

blockMeshDict that you can change according to the dimensions of your
domain.
•  You can also use m4 scripting to automate the whole process.
•  We are going to address m4 scripting and advanced blockMesh meshing

later on.
•  The meshing utility blockMesh, reads the dictionary blockMeshDict located

in the directory constant/polyMesh
blockMesh workflow
blockMeshDict
vertices edges blocks patches
blockMesh
OpenFOAM polyMesh
blockMesh workflow
Refer to OpenFOAM®Module'3')'Lecture'10'
User Guide for more Information 13'
snappyHexMesh workflow
blockMesh or external mesher
Geometry
Background mesh
(STL file)
snappyHexMesh
OpenFOAM polyMesh
•  To generate a mesh with snappyHexMesh, we proceed as follows:
•  Generation of a background or base mesh.
•  Geometry definition.
•  Generation of a castellated mesh or cartesian mesh.
•  Generation of a snapped mesh or body fitted mesh.
•  Addition of layers close to the surfaces or boundary layer
meshing.
•  Check/enforce mesh quality.
Geometry
Background mesh
(STL file)
snappyHexMesh
OpenFOAM polyMesh
•  All the volume and surface refinement is done in reference to the
background or base mesh.
Base cell RL 1 RL 2 RL 3
* RL = refinement level
Geometry
Background mesh
(STL file)
snappyHexMesh
OpenFOAM polyMesh
•  The meshing utility snappyHexMesh reads the dictionary
snappyHexMeshDict located in the directory system.
•  The utility surfaceFeatureExtract reads the dictionary
surfaceFeatureExtractDict located in the directory system.
•  The output of the utility surfaceFeatureExtract (*.eMesh), is located in the
directory constant/triSurface.
•  The final mesh must be located in the directory constant/polyMesh
Geometry
Background mesh
(STL file)
snappyHexMesh
OpenFOAM polyMesh
•  The STL geometry can be obtained from any geometry modeling tool.
•  The STL file can be made up of a single surface describing the geometry.
•  Alternatively, the STL file can be made up of multiple surfaces that describe
the geometry.
•  In the case of a STL file with multiple surfaces, we can use local refinement
in every individual surface. This gives us more control when generating the
mesh.
•  The STL geometry is located in the directory constant/triSurface
Geometry
Background mesh
(STL file)
snappyHexMesh
OpenFOAM polyMesh
•  The background or base mesh can be generated using blockMesh or an
external mesher.
•  The following criteria must be observed when creating the background
mesh:
•  The mesh must consist purely of hexes.
•  The cell aspect ratio should be approximately 1, at least near the
STL surface.
•  There must be at least one intersection of a cell edge with the
STL surface.
Geometry
Background mesh
(STL file)
snappyHexMesh
OpenFOAM polyMesh
Let us take a look at

snappyHexMesh in action by
meshing wolf dynamics logo
•  The process of generating a mesh using snappyHexMesh will be described using this figure.
•  The objective is to mesh a rectangular shaped region (shaded grey in the figure) surrounding an object
described by a STL surface (shaded green in the figure).
•  This is an external mesh (e.g. for external aerodynamics). You can also generate an internal mesh (e.g. flow in
a pipe), in this case you will mesh the interior of the green region.
Step 1. Creating the background hexahedral mesh

•  Before snappyHexMesh is executed the user must create a background mesh of hexahedral cells that fills the
entire region as shown in the figure. This can be done by using blockMesh or any other mesher.
•  The following criteria must be observed when creating the background mesh:
•  The mesh must consist purely of hexes.
•  The cell aspect ratio should be approximately 1, at least near the STL surface.
•  There must be at least one intersection of a cell edge with the STL surface.
Step 2. Cell splitting at feature edges

•  Cell splitting is performed according to the specification supplied by the user in the castellatedMeshControls
sub-dictionary in the snappyHexMeshDict dictionary.
•  The splitting process begins with cells being selected according to specified edge features
as illustrated in the figure.
•  The feature edges can be extracted from the Module'3')'Lecture'10'
STL geometry file using the utility surfaceFeatureExtract. 24'
Step 3. Cell splitting at surfaces

•  Following feature edges refinement, cells are selected for splitting in the locality of specified surfaces as
illustrated in the figure.
•  The surface refinement (splitting) is performed according to the specification supplied by the user in the
refinementMeshControls in the castellatedMeshControls sub-dictionary in the snappyHexMeshDict dictionary.
Step 4. Cell removal

•  Once the feature edges and surface splitting is complete, a process of cell removal begins.
•  The region in which cells are retained are simply identified by a location vector within the region, specified by
the locationInMesh keyword in the castellatedMeshControls sub-dictionary in the snappyHexMeshDict
dictionary.
•  Cells are retained if, approximately speaking,Module'3')'Lecture'10'
50% or more of they volume lies within the region. 26'
Step 5. Cell splitting in specified regions

•  Those cells that lie within one or more specified volume regions can be further split by a region (in the figure,
the rectangular region within the red rectangle).
•  The information related to the refinement of the volume regions is supplied by the user in the
refinementRegions block in the castellatedMeshControls sub-dictionary in the snappyHexMeshDict dictionary.
•  This is a valid castellated or cartesian mesh that can be used for a simulation.
Step 6. Snapping to surfaces

•  After deleting the cells in the region specified and refining the volume mesh, the points are snapped on the
surface to create a conforming mesh.
•  The snapping is controlled by the user supplied information in the snapControls sub-dictionary in the
snappyHexMeshDict dictionary.
Step 6, continuation. Snapping to surfaces

•  Sometimes, the default snapControls options are not enough and you will need to adjust the values to get a
good mesh, so it is advisable to save the intermediate steps with a high writing precision (controlDict).
•  This is a valid snapped or body fitted mesh that can be used for a simulation.
Step 7. Mesh layers

•  The mesh output from the snapping stage may be suitable for simulation, although it can produce some
irregular cells along boundary surfaces.
•  There is an optional stage of the meshing process which introduces boundary layer meshing in selected parts
of the mesh.
•  This information is supplied by the user in theModule'3')'Lecture'10'
addLayersControls sub-dictionary in the snappyHexMeshDict
30'
dictionary.
Step 7, continuation. Mesh layers

•  This is the final step of the mesh generation process using snappyHexMesh.
•  This is a valid body fitted mesh with boundary layer meshing, that can be used for a simulation.
snappyHexMesh in action
•  Let us study the snappyHexMesh dictionary of this

tutorial.
•  You will find this case in the directory:
$PTOFC/sHM/M9_wolf
Let us explore the snappyHexMeshDict dictionary.
The dictionary snappyHexMeshDict consists of five main sections:
•  geometry
Definition of geometry entities to be used for meshing
•  castellatedMeshControls
Definition of feature, surface and volume mesh refinement
'
•  snapControls
Definition of surface mesh snapping and advanced parameters
•  addLayersControls
Definition of boundary layer meshing and advanced parameters
•  meshQualityControls
Definition of mesh quality metrics
•  In the snappyHexMeshDict dictionary you will find more than 70

parameters.
•  It is really tricky to get a good mesh at the first time.
•  My best advice is to start with a smooth geometry (no sharp angles) and
study the effect of every parameter.
•  Then use a geometry with sharp angles and try to get a good mesh. Sharp
angles are difficult to deal with.
•  Finally, try to add the boundary layer mesh. Again, start first with a smooth
geometry and then use a geometry with sharp angles.
castellatedMesh true; //or false

snap true; //or false
addLayers true; //or false
geometry
{
...
...
}
castellatedMeshControls
{
...
...
}
snapControls
{
...
...
}
•  The snappyHexMesh dictionary is made up of five sections, namely:
addLayersControls geometry, castellatedMeshControls, snapControls,
{ addLayersControls and meshQualityControls. Each section
... controls a step of the meshing process.
...
} •  In the first three lines we can turn off and turn on the different
meshing steps. For example, if we want to generate a body fitted
meshQualityControls mesh with no boundary layer we should proceed as follows:
{
... castellatedMesh true;
... snap true;
}
Module'3')'Lecture'10' addLayers false; 36'

snap true;
addLayers true;
//or false
//or false
•  Before continuing, I want to let you know
that there are more than 80 parameters in
geometry
snappyHexMesh.
{
...
... •  Adding the fact that there is no native GUI,
} it is quite difficult to control the mesh
castellatedMeshControls generation process.
{
...
... •  Nevertheless, snappyHexMesh generates
}
really good hexa dominant meshes.
snapControls
{
... •  Hereafter, I will only comment on the most
...
}
important parameters.
addLayersControls
{ •  The parameters that you will find in the
...
...
snappyHexMeshDict dictionaries
} distributed with the tutorials, in our opinion
meshQualityControls
are really robust and will work most of the
{ times.
...
...
}
geometry
{
wolfExtruded.stl STL file to read

{
type triSurfaceMesh;
name wolf; Name of the surface inside snappyHexMesh
regions Use this option if you have a STL with multiple patches defined
{
wolflocal This is the name of the region or surface patch in the STL file
{
name wolf_wall; User-defined patch name. This is the final name of the patch
}
}
}
•  In this section we read in the STL geometry. Remember, the input
box Name of geometrical entity geometry is always located in the directory constant/triSurface
{
type searchableBox; •  We can also define geometrical entities that can be used to refine the
min (-100.0 -120.0 -50.0 ); mesh, create regions, or generate baffles.
max (100.0 120.0 150.0 );
} •  You can add multiple STL files.
sphere Name of geometrical entity •  If you do not give a name to the surface, it will take the name of the
{ STL file.
type searchableSphere; Note 1
centre (120.0 -100.0 50.0 ); •  The geometrical entities are created inside snappyHexMesh.
radius 40.0;
} Note 1:
If you want to know what geometrical entities are available, just
} misspelled something in the type keyword.
{
//Refinement parameters
maxLocalCells 100000;
maxGlobalCells 2000000;
nCellsBetweenLevels 1;
...
...
//Explicit feature edge refinement

features Dictionary block'
(
...
...
);
//Surface based refinement

refinementSurfaces Dictionary block'
{
...
...
} •  In the castellatedMeshControls section, we define the global
refinement parameters, explicit feature edge refinement,
//Region-wise refinement surface based refinement, region-wise refinement and the
refinementRegions Dictionary block' material point.
{
... •  In this step, we are generating the castellated mesh.
...
}
Note 1:
//Mesh selection The material point indicates where we want to create the mesh,
locationInMesh (-100.0 0.0 50.0 ); Note 1' that is, inside or outside the body to be meshed.
}
{
// Refinement parameters
maxLocalCells 100000;
maxGlobalCells 2000000;
minRefinementCells 0;
maxLoadUnbalance 0.10;
nCellsBetweenLevels 1; Note 1
//Local curvature and

//feature angle refinement
resolveFeatureAngle 30; Note 2
planarAngle 30;
allowFreeStandingZoneFaces true;
//Explicit feature edge refinement

Note 1:
features Dictionary block'
This parameter controls the transition between cell
(
refinement levels.
{
file "wolfExtruded.eMesh"; Note 3
Note 2:
level 2;
This parameter controls the local curvature refinement. The
}
higher the value, the less features it captures. For example
);
if you use 100, it will not add refinement in high curvature
areas. It also controls edge feature snapping, high values
...
will not resolve sharp angles in surface intersections.
...
...
Note 3:
This file is automatically created when you use the utility
}
surfaceFeatureExtract. The file is located in the directory
constant/triSurface
{
...
...
...

{
//wolf was defined in the geometry section

wolf Note 1
{
level (1 1); //Global refinement
regions Note 2
{
wolflocal Note 3
Note 1:
{
The surface wolf was defined in the geometry section.
level (2 4); Local refinement
Note 2:
patchInfo
The region wolflocal was defined in the geometry section.
{
type wall; Note 4
Note 3:
}
Named region in the STL file. This refinement is local.
}
To use the surface refinement in the regions, the local
}
regions must exist in STL file. We created a pointer to this
}
region in the geometry section.
...
...
}
Module'3')'Lecture'10' Note 4: 41'
You can only define patches of type wall or patch.
{

{
...
...
...
//This surface or geometrical entity
//was defined in geometry section
sphere Note 1
{
level (1 1);
faceZone face_inner;
cellZone cell_inner;
cellZoneInside inside;
//faceType internal;
Note 1:
} Optional specification of what to do with faceZone faces:
} internal: keep them as internal faces (default)

baffle: create baffles from them. This gives more freedom in mesh motion
... boundary: create free-standing boundary faces (baffles but without
... the shared points)
}
e.g., faceType internal;
{
...
...
...
//Region-wise refinement
refinementRegions Dictionary block'
{
box Note 1
{
mode inside;
levels (( 1 1 ));
}
//Mesh selection
locationInMesh (-100.0 0.0 50.0 );
} Note 1:
This region or geometrical entity was created in the geometry section.
{
...
...
...
//Region-wise refinement
refinementRegions Dictionary block'
{
//This region or geometrical entity

//was defined in the geometry section
box
{
mode inside;
levels (( 1 1 ));
}
//Mesh selection This point defines where do you want the mesh
locationInMesh (-100.0 0.0 50.0 ); Can be internal mesh or external mesh
snapControls
{
//Number of patch smoothing iterations

//before finding correspondence to surface
nSmoothPatch 3;
tolerance 2.0;
//- Number of mesh displacement relaxation

//iterations.
nSolveIter 300; Note 1
//- Maximum number of snapping relaxation

//iterations. Should stop before upon
//reaching a correct mesh.
nRelaxIter 5; Note 2
// Feature snapping
//Number of feature edge snapping iterations.

nFeatureSnapIter 10; Note 3
Note 1:
//Detect (geometric only) features by The higher the value the better the body fitted mesh. 300 is
//sampling the surface (default=false). already a high value, the default value is 30.
implicitFeatureSnap false;
Note 2:
// Use castellatedMeshControls::features Increase this value to improve the body fitted mesh.
// (default = true)
explicitFeatureSnap true; Note 3:
Increase this value to improve the edge features.
multiRegionFeatureSnap false;
•  In this step, we are generating the body fitted mesh.
}
addLayersControls
{
//Global parameters
relativeSizes true;
expansionRatio 1.2;
finalLayerThickness 0.5;
minThickness 0.1;
layers Note 1
{
wolf_wall Note 2
{
nSurfaceLayers 3;
//Local parameters
//expansionRatio 1.3;
//finalLayerThickness 0.3;
//minThickness 0.1;
}
}
// Advanced settings
nGrow 0;
featureAngle 130; Note 3 Note 1:
maxFaceThicknessRatio 0.5; In this section we select the patches where we want to add the
nSmoothSurfaceNormals 1; layes. We can add multiple patches (if they exist).
nSmoothThickness 10;
minMedianAxisAngle 90; Note 2:
maxThicknessToMedialRatio 0.3; This patch was created in the geometry section.
nSmoothNormals 3;
slipFeatureAngle 30; Note 3:
nRelaxIter 5; Specification of feature angle above which layers are collapsed
nBufferCellsNoExtrude 0; automatically.
nLayerIter 50;
nRelaxedIter 20; •  In this step, we are generating the boundary layer mesh.
}
meshQualityControls
{
maxNonOrtho 75; Note 1
maxBoundarySkewness 20;
maxInternalSkewness 4; Note 2
maxConcave 80;
minVol 1.00E-13;
minTetQuality 1e15;
//minTetQuality -1e30;
minArea -1;
minTwist 0.02;
minDeterminant 0.001;
Note 1:
Maximum non-orthogonality angle.
minFaceWeight 0.05;
Note 2:
minVolRatio 0.01;
Maximum skewness angle.
minTriangleTwist -1;
•  During the mesh generation process, the mesh quality is continuously
monitored.
minFlatness 0.5;
•  The utility snappyHexMesh will try to generate a mesh using the mesh
nSmoothScale 4;
quality parameters defined by the user.
errorReduction 0.75;
•  If a mesh motion or topology change introduces a poor quality cell or
}
face the motion or topology change is undone to revert the mesh 47'
back
to a previously valid error free state.
debugFlags
(
// write intermediate meshes
mesh
// write current mesh intersections as .obj files

intersections
// write information about explicit feature edge

// refinement
featureSeeds
// write attraction as .obj files

attraction
// write information about layers

layerInfo
);
writeFlags
(
// write volScalarField with cellLevel for •  At the end of the dictionary you will find the sections:
// postprocessing debugFlags and writeFlags
scalarLevels
•  By default they are commented. If you uncomment them you will
// write cellSets, faceSets of faces in layer enable debug information.
layerSets
•  debugFlags and writeFlags will produce a lot of outputs that you
// write volScalarField for layer coverage can use to post process and troubleshoot the different steps of
layerFields the meshing process.
);
Was that explanation good

enough for you?
Is it clear ?
Questions?
Before proceeding to compute the solution,

remember to always check the quality of
the mesh
Today’s lecture

•  Meshing with snappyHexMesh

•  Meshing case 1. 3D Cylinder (external mesh).
$PTOFC/sHM/M1_cyl
Case 1. 3D Cylinder (external mesh).
Let us generate the mesh by using SnappyHexMesh.
At this point, your Module'3')'Lecture'10'

mesh should looks like this 53'


•  cd $PTOFC/sHM/M1_cyl
•  blockMesh
(And by the way, take a look at the snappyHexMeshDict dictionary)
•  checkMesh -latestTime
•  paraFoam
•  At this point, you should have in your case directory two time directories 1 and 2 (if
you chose a time step of 1 in your controlDict).
•  In the time directory 1, you should have the mesh with the castellated mesh.
•  In the time directory 2 you should have the mesh with the conforming mesh (the
mesh after snapping).
•  Additionally, if you chose to generate the boundary layer mesh, you should have a
time directory 3, where you should have the mesh with the inflation layer.
•  In the directory $PTOFC/sHM/M1_cyl_er_bl you will find the case setup for
generating the boundary layer mesh.
•  We are going to deal with boundary layer meshing later on.
•  So far you do not have a valid mesh in the directory constant/polyMesh.

•  You must copy the mesh from the time directory 2 (or 3) to your constant directory.
•  mv constant/polyMesh constant/polyMesh.org
(To have a backup of the background mesh folder, this is optional)
•  cp -r 2/polyMesh constant/polyMesh
(To copy the new mesh to your constant/polyMesh directory, this is compulsory)
•  rm -rf 1
(If you do not want to keep this time folder)
•  rm -rf 2
•  Now you are ready to run. Remember, you will need to set the boundary condition
patches and they must be compatible with the patch type defined in the file
constant/polyMesh/boundary
•  Alternatively, snappyHexMesh can automatically overwrite the original background

mesh contained in constant/polyMesh. In the terminal type:
•  snappyHexMesh -overwrite
•  If you use this option, you will not save intermediate steps.
•  Hence, you will not be able to visualize the intermediate steps.
•  You might be wondering, why should we save the intermediate steps? Besides is
cool to look at what snappyHexMesh is doing, there is another reason.
•  If you save the intermediate steps, you will be able to restart the meshing process
from a saved state (castellated or snapped mesh).
•  Therefore, in case something goes wrong or you do not like the final mesh you do not
need to start from zero.

•  Meshing case 2. 3D Cylinder (external mesh), with
feature edge refinement.
$PTOFC/sHM/M1_cyl_er
Let us generate the mesh by using SnappyHexMesh with feature edge
refinement.

refinement.

refinement.
No feature edge refinement Feature edge refinement

•  By the way, do not fool yourself, razor type sharp angles are hard to find in
real applications.
•  If you can smooth the edges, do it (chamfer, bevel, fillet, taper, round,
bullnose, etc).
•  By smoothing the edges you are doing geometry defeaturing.
•  It will also made your life easier when generating the boundary layer mesh,
if you need one at all.
Sharp edges Module'3')'Lecture'10' Smooth edges 63'

refinement.

•  cd $PTOFC/sHM/M1_cyl_er
•  blockMesh
(This utility reads the surfaceFeatureExtractDict dictionary which is located in the system directory)
•  paraview
(Take a look at the .obj files created by surfaceFeatureExtract, we use paraview instead of paraFoam
because by default paraFoam reads the mesh generated by blockMesh. The .obj files are located in the directory
constant/extendedFeatureEdgeMesh)
•  paraFoam
refinement.
•  The utility surfaceFeatureExtract will create a file named *.eMesh (e.g.
banana.eMesh), this file will be saved in the directory constant/triSurface This file
contains the information of the feature edges.
•  By the way, try to read the file, it is easy to understand.
•  If you need to capture features that were not captured by surfaceFeatureExtract, you can
manually create this file.
•  Next, you should tell to snappyHexMesh that you want to use refinement in the feature edges,
and this is done by pointing to the *.eMesh file in the snappyHexMeshDict dictionary
// Explicit feature edge refinement
features
(
{
file “banana.eMesh”;
level 4;
}
);
•  snappyHexMesh knows that the *.eMesh file is in constant/triSurface
refinement.
•  At this point, you should have in your case directory two time directories 1 and 2 (if
you chose a time step of 1 in your controlDict).
•  Additionally, if you chose to generate the boundary layer mesh, you should have a
time directory 3, where you should have the mesh with the inflation layer.
•  In the directory $PTOFC/sHM/M1_cyl_er_bl you will find the case setup for
generating the boundary layer mesh.
•  We are going to deal with boundary layer meshing later on.
refinement.

•  You must copy the mesh from the time directory 2 (or 3) to your constant directory.
•  rm -rf 1
•  rm -rf 2
constant/polyMesh/boundaryModule'3')'Lecture'10' 67'
refinement.

need to start from zero. Module'3')'Lecture'10' 68'

•  Meshing case 3. 3D Cylinder (external mesh), with
feature edge refinement and boundary layer.
$PTOFC/sHM/M1_cyl_er_bl
refinement and boundary layer.


Effect of featureAngle on boundary layer collapsing
featureAngle 30 featureAngle 130

•  How do I enable boundary layer?.

•  In the file snappyHexMeshDict, look for the following entry:

snap true; //or false
addLayers true; //or false
...
...
...

•  cd $PTOFC/sHM/M1_cyl_er_bl
•  blockMesh
(This utility reads the surfaceFeatureExtractDict dictionary which is located in the system directory)
•  paraview
•  paraFoam
•  At this point, you should have in your case directory three time directories 1, 2, and 3
(if you chose a time step of 1 in your controlDict).
•  In the time directory 3 you should have the mesh with the conforming mesh and the
boundary layer.

•  You must copy the mesh from the time directory 3 to your constant directory. In the
terminal type:
•  rm -rf 1
•  rm -rf 2
•  rm –rf 3
constant/polyMesh/boundary

need to start from zero. Module'3')'Lecture'10' 77'

•  Meshing case 4. Mixing elbow (internal mesh), initial
mesh.
$PTOFC/sHM/M2_mixing_elbow1



•  cd $PTOFC/sHM/M2_mixing_elbow1
•  blockMesh
(It will use an includedAngle of 130 degrees as defined in the dictionary ./system/surfaceFeatureExtractDict)
•  paraview
•  paraFoam

•  Also, you will not be able to restart the meshing process from a saved state
(castellated or snapped mesh).
•  The mesh used in the previous case was a STL with multiple surfaces.
•  In the directory geometry, you fill find the file

mixing_pipe_onesurface.stl, this STL has one single surface.
•  Try to use this STL file to generate the mesh. You will notice that the
final mesh has only one patch, namely mixing_elbow.
•  Also, is not possible to have local control on the mesh refinement and
boundary layer meshing.
•  You will also face the conundrum that as there is only one surface patch,
it is not possible to assign boundary conditions.
•  To solve the problem of the single surface patch, you can use the utility
autoPatch. To do so, you can proceed as follows:
•  autoPatch 60
•  The utility autoPatch will use an angle criterion to find the patches, and
will assign the name auto0, auto1, auto2 and auto3 to the new patches.
•  The naming convention is autoN, where N is the patch number.
•  Remember, autoPatch will manipulate the mesh located in the directory

constant/polyMesh.

•  Meshing case 5. Sphere (external mesh), boundary
layer mesh.
$PTOFC/sHM/M3_sphere_sHM
Case 5. Sphere (external mesh).
Let us generate first the geometry using blender (or whatever you want to
use) and then the mesh by using SnappyHexMesh.
Mesh with no inflation layer.

addLayers false; in snappyHexMeshDict
Mesh with inflation layer.

addLayers true; in snappyHexMeshDict
Mesh with no inflation layers Mesh with inflation layers
Inflation layers with different control parameters
For this tutorial you will first need to generate the geometry using blender or whatever
you want to use, I will use blender. In the terminal type:
•  cd $PTOFC/sHM/M3_sphere_sHM
(The geometry was generated with blender. You will find the blender file and the STL file are in the directory geometry)
•  blender
(This step is optional. For geometry modeling. Do not forget to export the geometry in ascii STL format.)
•  blockMesh
•  snappyHexMesh –noFunctionObjects
•  paraFoam
(To copy the new mesh to your constant/polyMesh directory, this is compulsory
•  rm -r 1, rm -r 2, rm -r 3
(If you do not want to keep these time folders)

•  If you do not like the inflation layer or you want to try different layer parameters,
you do not need to start the meshing form scratch.
•  To restart the meshing process from a saved state you need to run
snappyHexMesh, save the intermediate steps (castellation and snapping), and
then create the inflation layers starting from the snapped mesh.
•  Before creating the mesh with the inflation layers, you will need to transfer the
snapped mesh to the directory constant/polyMesh, and erase the intermediate
steps.
•  Do not forget to turn off the castellation and snapping options in the
snappyHexMeshDict dictionary.
•  castellatedMesh false;
•  snap false;
•  addLayers true;
Let us restart the meshing from a saved state.

•  cd $PTOFC/sHM/M3_sphere_sHM
•  foamCleanTutorials
•  foamClearPolyMesh
•  blockMesh
•  paraFoam
(To visualize your mesh)

•  Meshing case 6. 2D cylinder (external mesh)
$PTOFC/sHM/M4_2d_cylinder




•  cd $PTOFC/sHM/M4_2d_cylinder
•  blockMesh
•  extrudeMesh –noFunctionObjects
(Take a look at the dictionary ./system/extrudeMeshDict, this dictionary tells OpenFOAM® to create the 2D mesh)
•  checkMesh –time 0
•  paraFoam


•  Meshing case 7. BWB body (external mesh),
meshing in parallel.
$PTOFC/sHM_1/M7_bwb_parallel
Case 7. Meshing in parallel using snappyHexMesh.
BWB body (external mesh)

•  cd $PTOFC/sHM_1/M7_bwb_parallel
•  cp constant/triSurface/N2A_Hybrid.stl constant/triSurface/
surfacemesh.stl
(The geometry was generated using openvsp)
•  surfaceTransformPoints –scale ‘(0.3048 0.3048 0.3048)’

constant/triSurface/N2A_Hybrid.stl constant/triSurface/
surfacemesh.stl
(The geometry was generated using openvsp)
•  surfaceFeatureExtract -noFunctionObjects
•  blockMesh
•  To do the meshing in parallel:

•  decomposePar
(Take a look at the dictionary ./system/decomposeParDict, in this dictionary you need to specify the decomposition
method and the number of partitions. Later on we are going to deal with running in parallel)
•  mpirun –np 8 snappyHexMesh –parallel –overwrite

(This step will generate the mesh in parallel)
Notice the syntax used to run snappyHexMesh in parallel:

mpirun -np 8 snappyHexMesh –parallel –overwrite
where mpirun is a shell script to use the MPI library (you need to install MPI), -np
is the number of processors you want to use, –parallel is a flag that you shall
always use if you want to run in parallel, and –overwrite is an option specific to
snappyHexMesh.
•  To do the meshing in parallel:
•  mpirun –np 8 checkMesh –parallel -constant

(To run checkMesh in parallel)
•  reconstructParMesh –mergeTol 1e-06 –constant

(Reconstruct the mesh using geometry information only)
•  paraFoam –builtin
(To visualize the decomposed mesh)
•  At this point you are ready to run the simulation.
•  But first you will need to transfer the boundary and initial conditions information to the
decomposed mesh, to do this
•  decomposePar -fields
•  If you want to do the meshing in serial, you can proceed as follows:
•  blockMesh
•  snappyHexMesh –overwrite
•  checkMesh
•  paraFoam
•  By the way, if you want to use symmetry, just modify the blockMeshDict dictionary
so the background mesh cut the geometry in the middle.
•  You can also modify the geometry and get half the airplane.
•  Do not forget to change the boundary conditions and the boundary file.
•  This applies to any geometry using serial and parallel meshing
In the directories $PTOFC/sHM, and $PTOFC/mesh_conversion_manipulation,
you will find many tutorials, try to go through each one to understand and get functional
using the meshing tools.
Module 4
Before we begin
Big spoiler alert for those who like cool and

fantastic looking CFD pictures.
Before we begin
Cool and fantastic looking pictures do not imply

that the results are correct.
Before we begin
As we are going to do some post-processing, I want to

remind you that CFD does not stand for
•  Colorful Fluid Dynamics

•  Careful Fit of Data
•  Colors For Directors
Today’s lecture
1.  Data visualization with paraFoam
Data visualization with paraFoam
•  paraFoam is the main post-processor distributed with OpenFOAM®.
However, you can use other alternatives (commercial or open source).
•  paraFoam is a wrapper of a third-party open source product named

Paraview (www.paraview.org).
•  Paraview is based on VTK, the visualization toolkit (www.vtk.org).
•  paraFoam comes with many built-in filters. By using these filters you can
manipulate your data in order to create vectors, streamlines, iso-surfaces,
cut-planes, plot over a lines, and so on.
•  We will now do some post-processing using

paraFoam. For this we will use the cavity3d tutorial
located in the directory:
$PTOFC/postprocessing/cavity3d/
•  In the directory $PTOFC/postprocessing/cavity3d/ you
will find this tutorial.
Mesh and initial conditions of passive scalar
Contours of velocity magnitude in two different cutplanes
Iso-surfaces of passive scalar colored by velocity Volume rendering of passive scalar colored by T
magnitude concentration
•  By the way, to run this case you will need to compile the solver
my_icoFoam.
•  In this solver we simply added a transport equation for a passive scalar. In

the directory programming/applications/solvers/my_icoFoam, you
will find the source code. To compile the solver:
•  cd $PTOFC/programming/applications/solvers/my_icoFoam
•  wmake
•  which my_icoFoam
•  We will now do some post-processing using paraFoam. From now on
follow me.
•  Go to the postprocessing/cavity3d/ directory. In the terminal type:
•  cd $PTOFC/postprocessing/cavity3d/
•  cp 0/T.org 0/T
•  setFields
•  blockMesh
•  my_icoFoam
•  paraFoam
•  A few words about paraFoam. You should have in mind that paraFoam is
not a visualization tool per-se (binary) , it is a script that calls paraview.
•  When you use paraFoam, it will generate a file named

case_name.OpenFOAM (where case_name is the name of the case,
cavity3d in this tutorial), which is necessary since Paraview needs a file
to be specified.
•  If you want to read multiple cases, you will need to generate the
case_name.OpenFOAM file manually. In the terminal,
•  touch new_case_name.OpenFOAM
•  Let us do another fantastic tutorial. This time we will

use the yf17 tutorial located in the directory:
$PTOFC/postprocessing/yf17/
•  In the directory $PTOFC/postprocessing/yf17/ you will
find this tutorial.
Try to capture the vortex
•  We will now do some post-processing using paraFoam. From now on follow
me.
•  Go to the postprocessing/yf17/ directory. In the terminal type:
•  cd $PTOFC/postprocessing/yf17/c1
•  cd c1
•  fluent3DMeshToFoam ../../../meshes/yf17/yf17.cas
•  cp –r fs_0.20 0.20
•  paraFoam
•  We do not need to run this case, the solution is in the directory fs_0.20.
but if you want you can run the simulation, the case is ready to go. Have in
mind that is time consuming.
•  The mesh is in the directory $PTOFC/meshes/yf17/
•  At this point, try to get familiar with the user interface and most important, try
to use all the features available in paraFoam.
•  Sometimes it can happen that you have a mesh, but you do not have the
*.stl file of the geometry.
•  You can extract the geometry from a valid polyMesh. From within the case
directory, type in the terminal:
•  surfaceMeshTriangulate –patches ‘(fuselage strake
wing vertical-tail horizontal-tail intake intake-ramp
exhaust)’ –noFunctionOnjects yf17.stl
•  At this point you should have the aircraft mesh in the file yf17.stl. Now
you can use this file as an input for snappyHexMesh.
•  The stl file of the geometry is in the directory

$PTOFC/postprocessing/yf17/c1/geo/yf17.stl
Data visualization
In the directory $PTOFC/postprocessing you will find many tutorials, try to go
through each one to understand and get functional using the post processing tools.
Module 4
Today’s lecture
1.  Data visualization with VISIT
Data visualization with VISIT
•  VISIT is an open source interactive parallel visualization and graphical
analysis tool.
•  VISIT was developed by the U.S. Department of Energy (DOE) Advanced
Simulation and Computing Initiative (ASCI) to visualize and analyze the
results of terascale simulations
•  VISIT contains a rich set of visualization filters for data manipulation.
•  VISIT can read OpenFOAM® native format.
•  VISIT can also read other formats, such as VTK format. To convert the
OpenFOAM® results to VTK format you need to use the foamToVTK utility.
•  VISIT can be downloaded from the following site:
https://wci.llnl.gov/codes/visit/home.html
•  Personally speaking, for large datasets, I do prefer to use VISIT rather than
paraFoam.
•  Let us do some post-processing with VISIT. This time

we will use the multiphase dambreak tutorial located in
the directory:
$PTOFC/postprocessing/
multiphase_dambreak/
•  In the directory $PTOFC/postprocessing/
multiphase_dambreak you will find this tutorial.
Mesh Initial conditions
VOF Fraction VOF Fraction volume rendering
•  Let us do some post-processing using VISIT. From now on follow me.
•  Go to the postprocessing/multiphase_dambreak directory. In the

terminal type:
•  cd $PTOFC/postprocessing/multiphase_dambreak
•  rm –rf 0
•  cp –r 0_org 0
•  blockMesh
•  setFields
•  multiphaseInterFoam
•  To do post-processing with VISIT, let us first convert the case to VTK format.
•  foamToVTK
•  cd VTK
•  visit
(I added this alias to my .bashrc file. In visit you will need to open the VTK files)
•  Now that we warmed-up, let us do a very cool tutorial.

This time we will use the vespa tutorial located in the
directory:
$PTOFC/postprocessing/vespacoarse/
•  In the directory $PTOFC/postprocessing/vespacoarse
Pressure contours and bounding box
Pressure contours on driver and motorcycle and cut plane with velocity
magnitude contours
Pressure contours on driver and motorcycle and velocity magnitude volume rendering
Surface mesh and cut plane with velocity vectors
•  Let us do some post-processing using VISIT. From now on follow me.
•  Go to the postprocessing/vespacoarse directory. In the terminal

type:
•  cd $PTOFC/postprocessing/vespacoarse/
•  We do not need to run this case, the solution is in the directory

$PTOFC/postprocessing/vespacoarse/sol_500
•  However, we need a valid mesh in order to do the post processing.
•  However, we need a valid mesh in order to do the post processing.
•  If you are in a hurry, the mesh is in the directory sol_mesh,

•  cp -r sol_mesh/polyMesh constant
•  If you want to generate the mesh, in the terminal type:

•  blockmesh
•  snappyHexMesh –overwrite –noFunctionObjects
•  checkMesh
•  Now that we have a valid mesh, we can convert the saved solution to VTK
format.
•  cp -r fs_500 500
•  foamToVTK -latestTime
•  cd VTK
•  visit
(I added this alias to my .bashrc file)
If you are into immerse visualization, you can do stereo rendering
Normal rendering Red/Green Stereo rendering (eye angle 4).

Suitable for immerse visualization.
Pressure contours on driver and motorcycle
Red/Green Stereo rendering (eye angle 4), suitable for immerse visualization.
Pressure contours on driver and motorcycle 20'
Red/Green Stereo rendering (eye angle 0.8), suitable for immerse visualization.
Pressure contours on driver and motorcycle 21'
•  By the way, you can also do stereo rendering with paraview/paraFoam. To
do so, type in the terminal:
•  paraFoam –stereo
or
•  paraview --stereo
•  The previous mesh was generated using snappyHexMesh, so feel free to
take a look at the snappyHexMesh dictionary and the .stl file containing
the geometry.
•  I really like this geometry, it is an actual 3D scan of a Vespa scooter. I

would like to thanks Paul McIntosh for sharing the geometry and the case
setup (http://www.vespalabs.org).
•  At this point, try to get familiar with the user interface and most important, try
to use all the features available in VISIT.
Data visualization
Module 4
Today’s lecture
1.  Data conversion

2.  Data manipulation
Today’s lecture

Data conversion
•  OpenFOAM® gives users a lot of flexibility when it comes to scientific

visualization.
•  You are not obliged to use OpenFOAM® visualization tools (paraFoam or

paraview).
•  You can convert the solution obtained with OpenFOAM® to many third party
formats. To do this, you can use OpenFOAM® data conversion utilities.
•  If you are looking for a specific format and it is not supported, you can write
your own conversion tool.
Data conversion
Fluent solution Ensight GMV Tecplot tetDualMesh
foamDataTofluent foamToEnsight foamToGMV foamToTecplot360 foamToTetDualMesh
VTK
foamToVTK
OpenFOAM polyMesh or Fluent mesh

foamMeshToFluent
solution
Mesh boundaries
foamToSurface
Extract surface from

polyMesh patches
surfaceMeshTriangulate
starCD mesh Fieldview 9 CGNS Abaqus mesh

Your own format
foamToStarMesh foamToFieldview9 foamToCGNS foamMeshToAbaqus
Extended version Extended version Extended version Extended version
The diagram is not complete. Refer to the user guide or source code to
get more information about all the conversion utilities available in
OpenFOAM®
Data conversion
(version 2.3.x):
•  mesh
•  surface
•  In the sub-directory postProcessing you will find the source code for the post
processing utilities included in the OpenFOAM® installation.
Data conversion
•  Let us visit the postProcessing directory. In the terminal type:
•  util
•  cd postProcessing
following post processing utilities
•  dataConversion •  sampling
•  foamCalc •  scalarField
•  graphics •  stressField
•  lagrangian •  turbulence
•  miscellaneous •  velocityField
•  noise •  wall
•  patch
Data conversion
•  Let us go to the directory dataConversion, in the terminal type:
•  cd dataConversion
•  ls –l
•  In the directory $FOAM_UTILITIES/postProcessing/dataConversion you will

find the following data conversion utilities:
•  foamDataToFluent •  foamToTecplot360
•  foamToEnsight •  foamToTetDualMesh
•  foamToEnsightParts •  foamToVTK
•  foamToGMV •  smapToFoam
For more information about the data conversion

utilities, refer to the User Guide
Today’s lecture

Data manipulation
•  First at all, by data manipulation I mean modifying a

field variable or computing a new field variable using
the saved solution (primitive variables).
Data manipulation
(version 2.3.x):
•  mesh
•  surface
•  In the sub-directory postProcessing you will find the source code for the post
processing utilities included in the OpenFOAM® installation.
Data manipulation
•  Let us visit the postProcessing directory. In the terminal type:
•  util
•  cd postProcessing
•  In this directory you will find the directories containing the source code for many post
processing and data manipulation utilities,
•  dataConversion •  sampling
•  foamCalc •  scalarField
•  graphics •  stressField
•  lagrangian •  turbulence
•  miscellaneous •  velocityField
•  noise •  wall
•  patch
For more information about the post processing

utilities, refer to the User Guide
Data manipulation
•  OpenFOAM® utilities can also be cloned and customized to create user
defined utilities.
•  A friendly advice, always remember to develop your own utilities in your user
directory (WM_PROJECT_USR_DIR), and to keep the same directory
structure as in the original OpenFOAM® installation.
•  In the postProcessing directory, you will find the data manipulation

utilities for post-processing. For example, in the sub-directory
postProcessing/velocityField you will find the following utilities
source code directories:
•  Co, Pe, enstrophy, Q, flowType, streamFunction,
Lambda2, uprime, Mach, vorticity.

Data manipulation
•  For instance, in the directory postProcessing/velocityField/Pe, you

will find the file Pe.C, which is the source code of the utility Pe. In the source
code you will find the following description:
Calculates and writes the Pe number as a

surfaceScalarField obtained from field phi.
The -noWrite option just outputs the max/min values

without writing the field.
•  Take your time and dig into each directory to get a complete
description of each utility.
Data manipulation
•  Remember the cylinder case?

•  We will now do some data manipulation and post-
processing using the cylinder mesh.
•  For this we will use the supersonic cylinder tutorial
$PTOFC/postprocessing/supersonic_cyl/
Data manipulation
supersonic_cyl/ you will find this tutorial.
Data manipulation
Courant number
Data manipulation
Mach number
Data manipulation
Z vorticity
Data manipulation
Density contours
Data manipulation
Courant number animation

Data manipulation
•  Let us do some data manipulation.
•  But before starting, I want to remind you that by data

manipulation I mean modifying a field variable or computing a
new field variable using the primitive variables computed during
the solution stage.
Data manipulation
•  Go to the postprocessing/supersonic_cyl/ directory. In the terminal
type:
•  cd $PTOFC/postprocessing/supersonic_cyl/
•  ls –al 0
(Take a look at the files in the diectory 0. By the default the solver will compute only the primitive variables p, T, and U)
•  blockMesh
•  checkMesh
•  renumberMesh -overwrite
•  sonicFoam > log.sonicfoam | tail -f log.sonicfoam
(This is a supersonic solver - compressible flows -. Take a look at the dictionaries, as they are different from the
dictionaries from the incompressible solvers. The theory is also slightly different)
•  paraFoam
Data manipulation
•  After finding the solution, we can compute the new field variables using the
primitive variables computed during the solution stage.
•  Mach
•  vorticity
•  Co
•  wallGradU
•  enstropy
•  Pe
Data manipulation
•  After finding the solution, we can compute the new field variables using the
primitive variables computed during the solution stage.
•  To visualize peclet number (computed as a surface field), you will need to

converted it to VTK and then plot it as a glyph.
•  foamToVTK –surfaceFields
•  Now you can see the pretty colors in paraview/paraFoam,
•  paraFoam
Data manipulation
•  By the way, if you take a look at the dictionary controlDict, you will see
that we are using a functionObject named writeRegisteredObject.
•  This functionObject will compute field variables that are not computed
by default by the solver.
•  For instance, in this case the solver will only compute p, T and U, by using
this functionObject we can compute rho as well.
•  What are functionObject?. Later on we are going to address them.
Data manipulation
•  For instance, in this case the solver will only compute p, T and U, by using
this functionObject we can compute rho as well.
additional_fields
{
type writeRegisteredObject;
functionObjectLibs ( "libIOFunctionObjects.so" );
objectNames ("rho”);
enabled true;
outputControl outputTime;
}
•  What are functionObject?. Later on we are going to address them.
Data manipulation
Module 4
Today’s lecture
1.  The sample utility

2.  Probes
3.  foamLog
Today’s lecture

2.  Probes
3.  foamLog
The sample utility
•  OpenFOAM® provides the sample utility to sample field data for plotting.
•  The sampling locations are specified for a case through a sampleDict

dictionary located in the case system directory.
•  During the job execution, inside the case directory a new folder named
postProcessing/, will be created. In this folder, the sampled values are
stored.
•  Data can be written in a range of formats including well-known plotting

packages such as: grace/xmgr, gnuplot and jPlot.
•  The sampling can be executed by running the utility sample in the case
folder and according to the application syntax.
•  A final word, this utility does not do the sampling while the solver is running.
It does the sampling after you finish the simulation.
For more information about the sample utility, refer to the user guide.
The sample utility
•  Let us do some sampling.

•  For this we will use the turbulent backstep case, which
you will find in the directory:
$PTOFC/postprocessing/turb_backstep/
The sample utility
turb_backstep/ you will find this tutorial.
The sample utility
Mesh
The sample utility
Velocity magnitude contours Pressure contours
The sample utility
Turbulence kinetic energy (k) contours Turbulence dissipation rate (epsilon) contours
The sample utility
[U/Uc] 0 0.02
Exp
CFD
0 1 2 3 4 5 6 7 8 9 10 [x/H]
Turbulence kinetic energy (k) profiles
[U/Uc] -0.5 0 0.5

Exp
CFD
0 1 2 3 4 5 6 7 8 9 10 [x/H]
Velocity magnitude profiles
The sample utility
We will now do some post-processing using the sample utility. From now on
follow me.
•  Go to the postprocessing/turb_backstep directory. In the terminal
type:
•  cd $PTOFC/postprocessing/turb_backstep/
•  blockmesh
•  cp 0_org/* 0
•  setDiscreteFields
(If you do not have this tool, copy the files located in the directory 0init to the directory 0)
•  simpleFoam
•  sample –latestTime
(The utility sample reads the dictionary ./system/sampleDict)
•  At this point take a look at the case folder. You will notice that the sample
utility creates a new folder named postProcessing, which contains the
folder sets where you will find n time directories (one for each time step
sampled). Module'4')'Lecture'14' 11'
•  You can use the following options with the sample utility (and most of the
utilities):
(The –latestTime option will do the sampling only for the last saved solution)
•  sample –noZero
(The –noZero option will do the sampling for all the saved solutions except the time directory 0)
•  sample –time 500:1000

(The –time 500:1000 option will do the sampling for all the solutions saved in the time directories 500 to 1000)
•  sample
(If you do not add any option, the utility will do the sampling for all the saved solutions, including time directory 0)
•  To know what options you can use with the sample utility (and most of the
utilities), type in the terminal:
•  sample –help
The sample utility
•  You will find in the case directory a small shell script named script. From
the terminal type:
•  ./script
(Take some time and read the script to understand what is going on)
•  This script will generate two output files in .eps format using the gnuplot
scripts located in the case folder (profilek.gp and profileU.gp). Take
a look at these files, this is a part of the post-processing tutorials.
•  To visualize the .eps files, from the terminal type:

•  evince profilek.eps
•  evince profileU.eps
or whatever application you use to view .eps files
•  Let us now study the sampleDict dictionary. Go to the system directory

and open the file sampleDict.Module'4')'Lecture'14' 13'
The sample utility
•  The sampleDict dictionary contains at least the following entries (the
header is not shown):
// Set output format
setFormat raw;
// Surface output format.
surfaceFormat foamFile;
// interpolationScheme.
interpolationScheme cellPointFace;
// Fields to sample.
fields
( U k );
// Set sampling definition:
sets
(
x=0H //Name of the sample set
{
type midPoint;
axis z;
start (0 0.5 1);
end (0 0.5 4);
}
//...
//More lines here//
//...
);
// Surface sampling definition:
surfaces
(
);
The sample utility
The sampleDict file
•  The sampleDict file contains several entries to be set according to the

user needs. You can set the following entries,
•  The choice of the interpolationScheme.

•  The format of the line data output.
•  The format of the surface data output.
•  The fields to be sample.
•  The sub-dictionaries that controls each sampling operation.
•  In these sub-dictionaries you can set the name, type and geometrical
information of the sampling operation.
Today’s lecture

2.  Probes
3.  foamLog
Probes
•  OpenFOAM® provides the probeLocations utility to sample field data in
some discrete points.
•  Probes can be created by using the probesDict dictionary, which must be

contained in the system folder.
•  During the job execution, inside the case directory a new folder named
postProcessing/, will be created. In this folder, the probed values are
stored.
•  The probed values are saved in a ascii file, with the name of the probed
field.
•  The probing can be executed by running the utility probeLocations in the

case folder and according to the application syntax.
•  A final word, this utility does not probe while the solver is running. It does the
probing after you finish the simulation.
Probes
•  Let us do some probing.

•  For this we will use the cylinder vortex shedding case,
which you will find in the directory:
$PTOFC/postprocessing/2d_cylinder_60
Probes
$PTOFC/postprocessing/2d_cylinder_60 you will find
this tutorial.
Probes
Mesh
Probes
Instantaneous velocity Instantaneous pressure
Reynolds number equal to 60
Probes
Pressure probes time history
Aerodynamic coefficients for Reynolds 60
Probes
We will now run a simulation using some probes. From now on follow me.
•  Go to the postprocessing/2d_cylinder_60 directory. In the terminal

type:
•  cd $PTOFC/postprocessing/2d_cylinder_60
•  blockMesh
•  icoFoam > log | tail –f log
•  probeLocations –noFunctionObjects
Note: do not erase the log file, we are going to use it in the next tutorial.
•  Let us explore the case directory. You will see that we have a new folder
named postProcessing/probes, which contains the ./0 time directory,
this is the directory from which we started to do the sampling.
•  If you start to sampling from time 20, in the directory postProcessing/
probes you will find the time directory 20 with the probes information. 24'
Probes
•  Let us now study the probesDict dictionary. Go to the system directory
and open the file probesDict. The probesDict dictionary contains at
least the following entries (the header is not shown):
// Fields to be probed. runTime modifiable!

fields
(
p
U
);
// Locations to be probed. runTime modifiable!

// You can add as many as you like
probeLocations
(
( 5 0.5 0)
( 5 0 0 )
( 5 -0.5 0 )
( 10 0.5 0 )
( 10 0 0 )
( 10 -0.5 0 )
( 2 1 0 )
);
Today’s lecture

2.  Probes
3.  foamLog
foamLog
•  During execution, OpenFOAM® writes values of residuals, number of
iterations and so on, on the standard output (terminal).
•  It is possible to extract this information with the foamLog utility, provided the
standard output has been written to a file (logfile).
•  solver_name > logfile

•  foamLog logfile
•  All the information extracted from the logfile file is saved in the directory
logs
•  To plot this info we can use gnuplot, grace, xmgr, octave, qtiPlot
and/or jPlot (just to name a few).
foamLog
•  By default, the files are presented in two-column format of time and the
extracted values. You can plot each file by using gnuplot or your favorite
plotting tool. Depending of your case setup, you will find the following files:
•  courant_0
•  contCumulative_0
•  contGlobal_0
•  contLocal_0
•  executionTime_0
•  Separator_0
•  Time_0
•  p_0
•  pFinalRes_0
•  pIters_0
•  Ux_0
•  UxFinalRes_0
•  UxIters_0
•  Uy_0
•  UyFinalRes_0
•  UyIters_0 Module'4')'Lecture'14' 28'
foamLog
•  Let us analyze the log file of the previous tutorial. In the terminal type:
•  cd $PTOFC/postprocessing/2d_cylinder_60/
(If you are not already in there)
•  foamLog log
•  cd logs
•  gnuplot
•  plot ‘CourantMean_0’ using 1:2 with lines
•  plot ‘p_0’ u 1:2 w l, ‘pFinalRes_0’ u 1:2 w l
•  If you do not have the log file from the previous tutorial, you can use the log
file icofoam_run, which is located in the case directory top level.
foamLog
•  This is a screenshot on my computer. This is a plot of the pressure initial and
final residual using gnuplot. You can plot any of the output files generated
by foamLog.
foamLog
•  It is also possible to plot this information on the fly.
•  To do this you will need to install PyFoam and use the following utility:
•  pyFoamPlotWatcher.py name_of_log_file
•  You can also try to write your own script.

•  Remember, in order to use pyFoamPlotWatcher.py you need to save the
log file.
foamLog
•  Let us run again the case postprocessing/2d_cylinder_60 but this
time using pyFoamPlotWatcher.py. In the terminal type:
•  cd $PTOFC/postprocessing/2d_cylinder_60
•  blockMesh
•  icoFoam > log | tail –f log
•  In a new terminal window and inside the directory

postprocessing/2d_cylinder_60, type in the terminal:
•  pyFoamPlotWatcher.py log
•  You do not need to run until the end time, just run for a few seconds to see
the output of pyFoamPlotWatcher.py.
foamLog
•  This is a screenshot on my computer. In this case, pyFoamPlotWatcher is
showing the initial residuals and continuity errors on the fly.
Post-processing
Module 4
Today’s lecture
1.  functionObjects
2.  Co-processing
Today’s lecture
2.  Co-processing
functionObjects
•  It is possible to perform data extraction/manipulation operations while the
simulation is running by using the functionObject feature.
•  functionObject are small pieces of code executed at a regular interval

without explicitly being linked to the application.
•  When using functionObject, files of sampled data can be written for

plotting and post processing.
•  functionObject are specified in the controlDict dictionary and

executed every timestep or pre-defined intervals.
•  All functionObject are runtime modifiable.
•  All the information related to the functionObject is saved in the directory

postProcessing.
functionObjects
•  Below is a list of some of the available functionObject that can be called
at run-time:'
'
•  fieldAverage - temporal averaging of fields.
•  fieldMinMax - writes min/max values of fields.
•  fieldValue - averaging/integration across sets of faces/cells, e.g. for flux across a plane.
•  readFields - loads fields to the database for post-processing.
•  surfaceInterpolateFields - generates surfaceFields from volFields for further postprocessing.
•  forces - calculates pressure/viscous forces and moments.
•  forceCoeffs - calculates lift, drag and moment coefficients.
•  sampledSet - data sampling along lines, e.g. for graph plotting.
•  probes - data probing at point locations.
•  isoSurface - generation of an isosurface of given fields in one of the standard sample formats.
•  cuttingPlane - generation of a cuttingPlane with field data in one of the sample formats.
•  sampledPatch - generation of a surface of a patch with field data in one of the sample formats.
•  systemCall - execute any system call, e.g. email you to tell you your job is finished.
•  abortCalculation - aborts the calculation if a given file is present in the case directory.
•  partialWrite - allows registered objects, e.g. fields, to be written at different times (frequencies).
•  nearWallFields - generates a volField with boundary values from interpolated internal field.
•  streamLine - generates streamlines in one of the sample formats.
•  timeActivatedFileUpdate - modifies case settings at specified times in a simulation.
•  writeRegisteredObject - writes registered objects, e.g. fields that are not scheduled to be written in
the application, i.e. created with NO_WRITE.

functionObjects
•  And by the way, these three functionObject are really powerful:'
•  systemCall
•  timeActivatedFileUpdate
•  writeRegisteredObject
•  Try to figure out what they do and when they can be used.
•  As usual, you can also program your own functionObject.

functionObjects
•  Let us do some sampling using functionObject.

•  For this we will use the cylinder vortex shedding case,
which you will find in the directory:
$PTOFC/postprocessing/2d_cylinder_100
functionObjects
$PTOFC/postprocessing/2d_cylinder_100 you will find
this tutorial.
functionObjects
Mesh
functionObjects
Velocity magnitude Vorticity
functionObjects
Mean velocity magnitude Mean pressure
functionObjects
Aerodynamic coefficients time history – Reynolds number = 100
functionObjects
•  You can compute the vortex shedding

frequency by computing the power
spectral density (PSD) function.
•  The PSD can be computed using the
FFT method.
•  For this you can use matlab, scilab,
octave, scipy.
•  The plotting utility QtiPlot (which is
similar to gnuplot), has a built in FFT
tool.
•  In this case I used scipy.
PSD – Reynolds number = 100
functionObjects
Pressure probes time history – Reynolds number = 100
functionObjects
Velocity probes time history – Reynolds number = 100
functionObjects
Pressure minimum and maximum values – Reynolds number = 100
functionObjects
Velocity components minimum and maximum values – Reynolds number = 100
functionObjects
•  We will now run a simulation using functionObject. From
now on follow me.
•  Go to the postprocessing/2d_cylinder_100 directory.

•  cd $PTOFC/postprocessing/2d_cylinder_100/
•  blockMesh
•  icoFoam > log &
•  tail -f log
functionObjects
•  Let us explore the case directory. You will see that we now
have a new directory named postProcessing. Inside this
directory, you will find many subdirectories pointing to the
functionObject used.
•  By the way, we are saving an extremely large amount of

information.
•  This is typical of unsteady simulations, and sometimes it can be

too daunting to post-process and analyze the data.
•  To ease the pain of doing data analytics and post-processing,

you can use shell or Python scripting.
functionObjects
•  Inside the directory postProcessing, you will find the
following sub-directories:
•  forceCoeffs_object
•  forces_object
•  inMassFlow
•  minmaxdomain
•  outMassFlow
•  patchMassFlows_massFlow
•  probes1
•  probes2
•  sampleset
•  surfaceSampling
functionObjects
•  Inside the directory postProcessing, you will many sub-
directories with the information of each of the
functionObject used during the simulation.
•  Inside each sub-directory you will find the time directory 0, this
is the time directory from which we started to sample using
functionObject.
•  If you start to sample from time 50, you will find the time
directory 50.
functionObjects
Some shell and awk scripting
•  Let us go to the postProcessing/minmaxdomain/0 directory. Now type in the
terminal:
•  To erase the parentheses in fieldMinMax.dat and save the output in out.txt,

type in the terminal:
•  cat fieldMinMax.dat | tr -d "()" > out.txt
•  To extract the velocity from out.txt, and save the output in vel_minmax.txt
•  awk '0 == NR % 2' out.txt > vel_minmax.txt
•  To extract the pressure from out.txt, and save the output in pre_minmax.txt
•  awk '1 == NR % 2' out.txt > pre_minmax.txt
•  To erase the temporal file out.txt, type in the terminal:

•  rm out.txt Module'4')'Lecture'15' 22'
functionObjects
•  Let us go to the postProcessing/minmaxdomain/0 directory. Now type in the
terminal:
•  To erase the header in pre_minmax.txt, type in the terminal:
•  awk '{if (NR!=1) {print}}’ pre_minmax.txt > temp

•  mv temp pre_minmax.txt
•  To erase the header in vel_minmax.txt, type in the terminal:
•  awk '{if (NR!=1) {print}}’ vel_minmax.txt > temp

•  mv temp vel_minmax.txt
functionObjects
•  Let us go to the postProcessing/forceCoeffs_object/0 directory. Now type
in the terminal:
•  To compute the mean value of the aerodynamic coefficients (drag coefficient in this case)
using the data in forceCoeffs.dat, type in the terminal:
•  awk ‘NR>=5009 && NR { total += $3; count++}

END { print “Mean_drag ” total/count}’ forceCoeffs.dat
(This is one line)
•  To compute the mean value of the aerodynamic coefficients (lift coefficient in this case)
using the data in forceCoeffs.dat, type in the terminal:
•  awk ‘NR>=5009 && NR { total += $4; count++}

END { print “Mean_lift ” total/count}’ forceCoeffs.dat
(This is one line)
functionObjects
•  Let us go to the postProcessing/forceCoeffs_object/0 directory. Now type
in the terminal:
•  To compute the standard deviation of the aerodynamic coefficients (drag coefficient in this
case) using the data in forceCoeffs.dat, type in the terminal:
•  awk ‘NR>=5009 && NR { total += $3; totalsq += $3*$3; count++}

END { print “Std_dev drag ” sqrt(totalsq/count –
(total/count)^2)}’ forceCoeffs.dat
(This is one line)
•  To compute the standard deviation of the aerodynamic coefficients (lift coefficient in this
case) using the data in forceCoeffs.dat, type in the terminal:
•  awk ‘NR>=5009 && NR { total += $4; totalsq += $4*$4; count++}

END { print “Std_dev drag ” sqrt(totalsq/count –
(total/count)^2)}’ forceCoeffs.dat
(This is one line)
functionObjects
•  In the directory scripts (located in the top level case directory) you will find three
scripts that will do the post processing automatically, namely:
•  script_force_coe
•  script_minmax
•  script_probes
•  To run the scripts you need to be inside the scripts directory. In the terminal type,
•  cd scripts
•  sh script_name
•  To know what the scripts are doing, what information is saved and where the output
file of the script is saved, just take a look at the scripts.
functionObjects
•  The script script_force_coe will compute the mean value and standard
deviation of the lift and drag coefficients.
•  The script script_probes will extract the information of the probes.
•  The script script_minmax will extract the minimum and maximum values of
the field variables.
Feel free to adapt these scripts to your needs. I just showed how to compute the
average and standard deviation and do some manipulation of the information saved
in the output files, but you can do many things in an automatic way.
The power of scripting!!!

functionObjects
Plotting in gnuplot
•  Let us do some plotting using gnuplot. Type in the terminal (you must be inside the
scripts directory):
•  gnuplot
•  plot [][-1:1] 'vel_minmax.txt' u 1:3 w l title "min_ux”
or you can try to plot everything
•  plot [][-1:q] 'vel_minmax.txt' u 1:3 w l title "min_ux",'vel_minmax.txt' u 1:4 w

l title "min_uy",'vel_minmax.txt' u 1:5 w l title "min_uz",'vel_minmax.txt' u 1:9
w l title "max_ux",'vel_minmax.txt' u 1:10 w l title "max_uy",'vel_minmax.txt' u
1:11 every 100 w p pt 7 ps 0.5 lc 8 title "max_uz”
(This is one line)
functionObjects
Plotting in gnuplot
•  Let us do some plotting using gnuplot. Type in the terminal (you must be inside the
scripts directory):
•  gnuplot
•  plot [][1:2] ’forceCoeffs.dat' u 1:3 title ”Drag coefficient”

with lines
(This is one line)
•  plot [][-1:1] ’forceCoeffs.dat' u 1:4 title ”Lift coefficient”

with lines
(This is one line)
functionObjects
•  Let us now study the controlDict dictionary. Go to the case system
directory and open the file controlDict using your favorite text editor
•  At the end of the controlDict dictionary, you will find a new sub-
dictionary entry,
functions
(
//some functionObjects here//
);
here, all the functionObject are defined.
functionObjects
•  The functionObject entry in the controlDict dictionary, contains at
least the following information:
function_object_name Name,of,func%onObject,
{
type function_object_to_use; func%onObject,to,use,
functionObjectLibs ("function_object_library.so"); Library,to,use,
enabled true;
timeStart 100; Keywords,and,sub8

timeEnd 200;
dic%onaries,specific,to,
//... the,func%onObject,
//functionObject //
//keywords and sub-dictionaries //
//...
}
functionObjects
•  This is the functionObject entry in the controlDict dictionary,
Name,of,func%onObject, additional_fields
{
func%onObject,to,use, type writeRegisteredObject;
Library,to,use, functionObjectLibs ("libIOFunctionObjects.so");
objectNames ("U_0")
enabled true;
Keywords,and,sub8dic%onaries,
specific,to,the,func%onObject,
timeStart 100;
timeEnd 200;
}
functionObjects
Name,of,func%onObject, fieldAverage
{
func%onObject,to,use, type fieldAverage;
Library,to,use, functionObjectLibs ("libfieldFunctionObjects.so");
enabled true;
cleanRestart false;
timeStart 20;
timeEnd 200;
fields
(
U
{
mean on;
specific,to,the,func%onObject, prime2Mean on;
base time;
}
p
{
mean on;
prime2Mean on;
base time;
}
); Module'4')'Lecture'15' 33'
}
functionObjects
Name,of,func%onObject, forces_object
{
func%onObject,to,use, type forces;
Library,to,use, functionObjectLibs ("libforces.so");
outputControl timeStep;
outputInterval 1;
patches ("cylinder");
Keywords,and,sub8dic%onaries, //If multiple patches are present

specific,to,the,func%onObject, //patches ("body1" "body2" "body3");
pName p;
Uname U;
rhoName rhoInf;
rhoInf 1.0;
CofR (0 0 0);
functionObjects
Name,of,func%onObject, forceCoeffs_object
{
func%onObject,to,use, type forceCoeffs;
Library,to,use, functionObjectLibs ("libforces.so");
patches ("cylinder");
pName p;
Uname U;
rhoName rhoInf;
Keywords,and,sub8dic%onaries, rhoInf 1.0;
specific,to,the,func%onObject, log true;
CofR (0.0 0 0);
liftDir (0 1 0);
dragDir (1 0 0);
pitchAxis (0 0 1);
magUInf 1.0;
lRef 1.0;
Aref 2.0;
outputInterval 1;
functionObjects
Name,of,func%onObject, minmaxdomain
{
func%onObject,to,use, type fieldMinMax;
enabled true;
mode component;
Keywords,and,sub8dic%onaries, outputControl timeStep;

specific,to,the,func%onObject, outputInterval 1;
log true;
fields (p U);
}
functionObjects
Name,of,func%onObject, probes1
{
func%onObject,to,use, type probes;
Library,to,use, functionObjectLibs ("libsampling.so");
probeLocations
(
(2 1 0)
);
Keywords,and,sub8dic%onaries, fields
specific,to,the,func%onObject, (p U);
outputInterval 1;
}
functionObjects
Name,of,func%onObject, probes2
{
func%onObject,to,use, type probes;
probeLocations
(
(5 0.5 0)
(5 0 0)
Keywords,and,sub8dic%onaries, (5 -0.5 0)
specific,to,the,func%onObject, (10 0.5 0)
(10 0 0)
(10 -0.5 0)
);
fields
(p U);
outputInterval 1;
}
functionObjects
Name,of,func%onObject, surfaceSampling
{
func%onObject,to,use, type surfaces;
enabled true;
interpolationScheme cellPoint;
surfaceFormat raw;
fields
(
specific,to,the,func%onObject, p
);
surfaces
(
nearWall
{
type patch;
patches ( "cylinder" )
//distance 0;
interpolate true;
triangulate false;
}
}
functionObjects
Name,of,func%onObject, sampleset
{
func%onObject,to,use, type sets;
enabled true;
outputInterval 1;
setFormat raw;
surfaceFormat vtk;
fields
( p U );
sets
(
Keywords,and,sub8dic%onaries, lineX1
{
type midPoint;
axis y;
start (5 -4 0);
end (5 4 0);
}
//...
//More lines here//
//...
}
functionObjects
Name,of,func%onObject, inMassFlow
{
func%onObject,to,use, type faceSource;
enabled true;
//outputControl outputTime;
Keywords,and,sub8dic%onaries, outputInterval 1;
log true;
valueOutput false;
source patch;
sourceName in;
operation sum;
fields
( phi );
}
functionObjects
Name,of,func%onObject, outMassFlow
{
func%onObject,to,use, type faceSource;
enabled true;
outputInterval 1;
Keywords,and,sub8dic%onaries, log true;

valueOutput true;
surfaceFormat raw;
source patch;
sourceName out;
operation sum;
fields
( phi );
}
functionObjects
Name,of,func%onObject, massFlow
{
func%onObject,to,use, type patchMassFlow;
Library,to,use, functionObjectLibs ("libsimpleFunctionObjects.so");
verbose true;
patches
(
in
Keywords,and,sub8dic%onaries, out
specific,to,the,func%onObject, );
factor 1
outputControlMode timeStep;
outputInterval 1;
}
•  To use this functionObject you will need to install swak4foam.
functionObjects
•  In the previous example we only used a few of the functionObject
available in OpenFOAM®, namely:
writeRegisteredObject
fieldAverage
forces
forceCoeffs
fieldMinMax
probes
surfaces
sets
faseSource
patchMassFlow
For more information about functionObject, refer to the user guide.

functionObjects
•  Sometimes it can happen that you forget to use a functionObject.
•  To solve this conundrum, you can use the utility

execFlowFunctionObjects, this utility will executed the
functionObject using the saved solutions.
•  For instance, let us say that you forgot to save the additional field U_0_0,
you do not need rerun the simulation. Open the dictionary controlDict
and uncomment the section corresponding to the functionObject
additional_fields_forgot (at the end of the file). Then type in the
terminal,
•  execFlowFunctionObjects -latestTime
Today’s lecture
2.  Co-processing
Co-processing
•  Multi-physics and CFD simulations have the potential to overwhelm any computer
(including the largest super computers) with the output obtained from simulations.
•  The traditional approach is to run a simulation and save the solution at given time-
steps or intervals for post processing at a later time.
•  An alternative way to do post processing, is to extract results or pretty pictures while
the simulation is running (on the fly), this is co-processing.
GEOMETRY
MESH
VISUALIZATION
Co-processing
•  For unsteady and big simulations, co-processing is an
alternative if we do not want to overflow the system with tons of
data.
•  By doing co-processing, we can do visualization on-the-fly.
•  In principle, co-processing is similar to doing sampling using

functionObject, but when we do co-processing we output
pretty pictures (e.g., streamlines, iso-surfaces, cut-planes),
while when we do sampling using functionObject we save
data for plotting (we save a quantity of interest).
Co-processing
•  An added benefit of co-processing is that results can be
immediately reviewed and problems can be immediately
addressed.
•  Co-processing requires that you identify what you want to see

before running the simulation.
•  In OpenFOAM®, you can output on-the-fly streamlines, cutting

planes, iso-surfaces, wall bounded stream lines, forces and
force coefficients written into data bins.
Co-processing
•  By the way, we define the co-processing as a
functionObject, and you can change it on-the-fly.
•  Finally, co-processing can save a large amount of information

so check your hardware limitations.
•  Plan everything in advanced.
Co-processing
•  Let us do some co-processing using

functionObjects.
•  For this we will use the vespa case, which you will find
in the directory:
$PTOFC/postprocessing/vespacoarse/
Co-processing
•  In the directory $PTOFC/postprocessing/vespacoarse
Co-processing
•  Go to the postprocessing/vespacoarse directory. In the
terminal type:
•  cd $PTOFC/postprocessing/vespacoarse/
•  We do not need to run this case for a long time. In the directory
$PTOFC/postprocessing/vespacoarse/c1/fs_500 you
will find a converged solution.
•  Let us run this case for 20 iterations. After finishing the

simulation, go to the directory $PTOFC/postprocessing/
vespacoarse/postProcessing and take a look at the cool
pictures saved concurrently.
Co-processing
•  To run the case, you will need a valid mesh.
•  In the directory sol_mesh you will find the mesh, you do not
need to generate it. To run the case, type in the terminal,
•  rm –rf 0
•  cp –rf 0org 0
•  cp -r sol_mesh/polyMesh constant
•  checkMesh
•  potentialFoam –noFunctionObjects
Co-processing
•  If you are in the mood and you feel like you want to generate
the mesh, in the terminal type:
•  rm –rf 0
•  cp –rf 0org 0
•  blockmesh
•  snappyHexMesh –overwrite –noFunctionObjects
•  checkMesh
•  potentialFoam –noFunctionObjects
•  Attention, the mesh generation is time consuming

•  A friendly reminder, you can run most of the applications and
solvers in parallel. I hopeModule'4')'Lecture'15'
you remember how to do it. 55'
Co-processing
•  To run the simulation in parallel:
•  decomposePar
•  mpirun -np 6 renumberMesh -overwrite
-noFunctionObjects -parallel
•  mpirun -np 6 simpleFoam -parallel >
log.simplefoam | tail –f log.simplefoam
•  mpirun -np 6 yPlusRAS -parallel
•  mpirun -np 6 wallShearStress -parallel
•  I guess you know how to run the simulation in serial or use

more/less processors. Module'4')'Lecture'15' 56'
Co-processing
•  Now you can go to the directory $PTOFC/postprocessing/
vespacoarse/postProcessing and take a look at the cool
pictures saved concurrently.
•  In the directory $PTOFC/postprocessing/vespacoarse/

postProcessing you will find the following sub-directories:
•  cuttingPlane
•  isoSurface
•  sets/streamLines
•  sets/wallBoundedStreamLines
Co-processing
•  In each of these sub-directories you will find the pretty pictures
saved in VTK format.
•  To visualize the VTK files you can use paraview/paraFoam.
•  By the way you can choose a different output format.
•  Also, you can have different saving frequencies.
•  At this point, let us take a look at few of the files located in the
system directory.
Co-processing
•  This is a functionObject for co-processing,
Name,of,func%onObject, cuttingPlane
{
outputInterval 5;
surfaceFormat vtk;
fields (p U);
surfaces
(
Keywords,and,sub8dic%onaries, xNormal
specific,to,the,func%onObject, {
type cuttingPlane;
planeType pointAndNormal;
pointAndNormalDict
{
basePoint (0 0 0);
noramlVector (0 1 0);
}
interpolate true;
}
);
}
Co-processing
•  This is a functionObject for co-processing,
Name,of,func%onObject, isoSurface
{
outputInterval 10;
surfaceFormat vtk;
fields (p U);
Keywords,and,sub8dic%onaries, surfaces
specific,to,the,func%onObject, (
constantIso
{
type isoSurfaceCell;
isoField p;
isoValue 30;
interpolate false;
regularise false;
}
);
}
Co-processing
•  At this point, take a look at all the functionObject used for
co-processing. In this case we used,
•  readFields
•  forceCoeffs
•  isoSurface
•  cuttingPlane
•  nearWallFields
•  streamLine
•  wallBoundedStreamLine
•  By the way, you can add the functionObject for co-processing directly
in the dictionary controlDict or you can use the #include statement
and have the dictionary entry for the specific functionObject in a
separate file (cuttingPlane, forceCoeffs, readFields,
streamLines, wallBoundedStreamLines, ./files/isoSurface, in
this case).
Post-processing
Module 5
Today’s lecture
1.  Running in parallel

2.  Running in a cluster using a job scheduler
Today’s lecture

Running in parallel
The method of parallel computing used by OpenFOAM® is known as
domain decomposition, in which the geometry and associated fields are
broken into pieces and distributed among different processors.
Shared memory architectures – Workstations and portable computers
Distributed memory architectures – Cluster and super computers

Running in parallel
Why use parallel computing?
•  Save time: run faster (speed-up) and increase your productivity, with the
potential of saving money in the design process.
•  Solve larger and more complex problems: thanks to parallel computing
we can solve bigger problems (scalability). A single computer has limited
physical memory.
•  Provide concurrency: A single computer or processor can only do one
thing at a time. Multiple processors or computing resources can do many
things simultaneously.
•  Save money: in theory, throwing more resources at a task will shorten its
time to completion, with potential cost savings. Parallel computers can be
built from cheap, commodity components.
•  Limits to serial computing: both physical and practical reasons pose
significant constraints to simply building ever faster serial computers (e.g,
transmission speeds, CPU clock rate, limits to miniaturization, hardware
cooling, economic limitations).
!
Running in parallel
Speed-up and scalability example
•  You can find this case and the parallel and serial timing in the directory
$PTOFC/mycases1/elbow3d/sHM_mesh.
•  The parallel case with 1 processor runs slower than the serial case due to the extra overhead
when calling the MPI library. Module'5')'Lecture'16' 6'
Running in parallel
Some facts about running OpenFOAM® in parallel:
•  Applications generally do not require parallel-specific coding. The parallel
programming implementation is hidden from the user.
•  Most of the applications and utilities run in parallel.
•  If you write a new solver, it will be in parallel (most of the times).
•  I have been able to run in parallel up to 14000 processors.
•  I have been able to run OpenFOAM® using single GPU and multiple GPUs.
•  Do not ask me about scalability, that is problem/hardware specific.
•  If you want to learn more about MPI and GPU programming, do not look in
my direction.
•  Did I forget to mention that OpenFOAM® is free.
Running in parallel
To run OpenFOAM® in parallel you will need to:
•  Decompose the domain. To do so we use the decomposePar utility. You

also will need a dictionary named decomposeParDict which is located in
the system directory of the case.
•  Distribute the jobs among the processors or computing nodes. To do

so, OpenFOAM® uses the public domain OpenMPI implementation of the
standard message passing interface (MPI). By using MPI, each processor
runs a copy of the solver on a separate part of the decomposed domain.
•  Finally, the solution is reconstructed to obtain the final result. This is

done by using the reconstrucPar utility.
Running in parallel
Domain Decomposition
•  The mesh and fields are decomposed using the decomposePar utility.
•  The main goal is to break up the domain with minimal effort but in such a
way to guarantee a fairly economic solution.
•  In other words, we want to minimize the inter-processors communication

and the processor workload.
•  The mesh and fields are broken up according to a set of parameters

specified in a dictionary named decomposeParDict that must be located in
the system directory of the case.
Running in parallel
Domain Decomposition
•  In the decomposeParDict file the user must set the number of domains in
which the case should be decomposed. Usually it corresponds to the
number of cores available for the calculation.
•  numberOfSubdomains NP;
where NP is the number of cores/processors.
•  The user has a choice of seven methods of decomposition, specified by the

method keyword in the decomposeParDict dictionary.
•  On completion, a set of subdirectories will be created, one for each

processor. The directories are named processorN where N = 0, 1, 2, 3,
and so on. Each directory contains the decomposed fields.
Running in parallel
Domain Decomposition Methods
•  simple: simple geometric decomposition in which the domain is split into

pieces by direction.
•  hierarchical: Hierarchical geometric decomposition which is the same as

simple except the user specifies the order in which the directional split is
done.
•  manual: Manual decomposition, where the user directly specifies the

allocation of each cell to a particular processor.
•  multiLevel: similar to hierarchical, but all methods can be used in a nested

form.
•  structured: 2d decomposition of a structured mesh (special case)

Running in parallel
Domain Decomposition Methods
•  scotch: requires no geometric input from the user and attempts to minimize
the number of processor boundaries. Similar to metis but with a more
flexible open-source license.
•  metis: requires no geometric input from the user and attempts to minimize
the number of processor boundaries. You will need to install metis as it is
not distributed with OpenFOAM®. Also, you will need to compile the
metisDecomp library.
Please be aware that there are license

restrictions using metis.
Running in parallel
Running in parallel – Gathering all together
Running in parallel
polyMesh/ and 0/'
decomposePar'
Processor0 processor1' processor2' processor3'
•  Inside each processorN folder you will have the mesh information, boundary and
initial conditions and the solution for that processor.
Running in parallel
mpirun –np <NPROCS> <application/utility> –parallel
•  To run in parallel we use the MPI library.

•  The number of processors to use or <NPROCS>, needs to be the same as the
number of partitions.
•  Do not forget to use the flag –parallel
. 15'
Running in parallel
•  In the decomposed case, you will find the mesh

information, boundary and initial conditions and
the solution for every processor.
•  The information is inside the directory
processorN.
reconstructPar'
•  When you reconstruct the case, you glue together

all the information contained in the decomposed
case.
•  All the information (mesh, boundary and initial
conditions and the solution), is inside the original
case folder.
Running in parallel
•  Summarizing, to run in parallel we proceed in the following way:
•  decomposePar
•  mpirun –np <NPROCS> <application/utility> –parallel
•  reconstructPar
•  paraFoam
•  You can do the post-processing and visualization on the decomposed case

or reconstructed case. We are going to address this later on.
Running in parallel
Let us run a case in parallel
Running in parallel
•  Let us run the Rayleigh-Taylor instability.

•  Go to the directory:
$PTOFC/parallel_tut/rayleigh_taylor
Running in parallel
•  In the directory $PTOFC/parallel_tut/rayleigh_taylor
Running in parallel
Mesh VOF Fraction
Running in parallel
•  Go to the $PTOFC/parallel_tut/rayleigh_taylor directory. In the
terminal type:
•  cd $PTOFC/parallel_tut/rayleigh_taylor/c1
•  blockMesh
•  checkMesh
•  cp 0/alpha.phase1.org 0/alpha.phase1
•  funkySetFields -time 0
(If you do not have this tool, copy the file alpha.phae1.init to alpha.phase1. The file is located in the directory 0.
The funkySetFields utility is part of pyFoam.)
•  decomposePar
(This will decompose the case. It reads the decomposeParDict dictionary that is located in the directory system)
•  ls –al
(Just to list all the directories and files. Do you see something different now?)
Running in parallel
•  Go to the $PTOFC/parallel_tut/rayleigh_taylor directory. In the
terminal type:
•  mpirun –np 8 renumberMesh –overwrite -parallel

•  mpirun -np 8 interFoam –parallel | tee log.interfoam
•  paraFoam
Here I am using 8 processors. In your case, use the maximum number of

processor available in your laptop, for this you will need to modify the
decomposeParDict dictionary located in the system folder. Specifically,
you will need to modify the entry numberOfSubdomains, and set its value
to the number of processors you want to use.
Running in parallel
•  Remember the cylinder case? I told you not to forget

about it.
•  Let us run this case in parallel.
$PTOFC/parallel_tut/cylinder_par
Running in parallel
•  In the directory $PTOFC/parallel_tut/cylinder_par
Running in parallel
•  In the directory $PTOFC/parallel_tut/cylinder_par you will find this
•  cd $PTOFC/parallel_tut/cylinder_par
•  ls –l
•  blockMesh
•  decomposePar
(This will decompose the case. It reads the decomposeParDict dictionary that is located in the directory system)
•  ls –l
(Just to list all the directories and files. Do you see something different now?)
Running in parallel
•  In the directory $PTOFC/parallel_tut/cylinder_par you will find this
•  mpirun –np 4 checkMesh –parallel

•  mpirun –np 4 renumberMesh –overwrite –parallel
(This utility renumber the mesh to minimize the bandwidth)
•  mpirun –np 4 icoFoam –parallel | tee –f log.icofoam

(Wait, what is that –builtin option?, we are going to address that later on)
Here I am using 4 processors. In your case, use the maximum number of

processor available in your laptop, for this you will need to modify the
decomposeParDict dictionary located in the system folder. Specifically,
you will need to modify the entry numberOfSubdomains, and set its value
to the number of processors you want to use.
Running in parallel
•  By the way, as a part of the never ending task of verification and validation, it is a
good idea to check from time to time that the serial solution and parallel solution are
equal.
•  It might happen that you get different results. If this happens, there is a problem in
the parallel implementation or processors inter-communication.
•  In this case, the serial and parallel solutions are equal.
Running in parallel
Running in parallel – Post-processing and

visualization
Running in parallel
•  The traditional way is to first reconstruct the case and then do the post-
process and visualization on the reconstruct case.
•  To do so, in the terminal type:
•  paraFoam
Running in parallel
•  What is the meaning of the option –builtin we used with paraFoam?
•  The option –builtin let us post-process the decomposed case directly.
•  By the way, you will need to select on the object inspector the Decomposed
Case option.
Running in parallel
•  Both of the previous methods are valid.
•  When we use the option –builtin we work on the decomposed case

directly.
•  That is to say, we do not need to reconstruct the case, we save one step
Running in parallel
•  But wait, there is a third option.
•  The third option consist in post-processing each decomposed domain

individually.
•  To load all processor directories, you will need to manually create the file
processorN.OpenFOAM (where N is the processor number) in each
processor folder.
•  After creating all processorN.OpenFOAM files, you can launch paraFoam

and load each file.
Running in parallel
•  Let us post-process each decomposed domain

individually.
•  For this we are going to use the yf17 tutorial, that you
will find in the directory:
$PTOFC/parallel_tut/yf17
Running in parallel
•  In the directory $PTOFC/parallel_tut/yf17 you will find
this tutorial.
Running in parallel
•  Let us post-process each decomposed domain individually. From now on
follow me.
•  Go to the $PTOFC/parallel_tut/yf17 directory. In the terminal type:
•  cd $PTOFC/parallel_tut/yf17
Running in parallel
•  In this directory you will find three directories, namely hierarchical,
scotch and scotch_celldist. Let us decompose these cases and
visualize the partitioning. First we start with the scotch partitioning method.
•  cd $PTOFC/parallel_tut/yf17/scotch
•  decomposePar
•  By the way, you do not need to run this case. We just need to decompose it
to visualize the partitions.
Running in parallel
follow me.
•  cd $PTOFC/parallel_tut/yf17/scotch
•  decomposePar
•  touch processor0.OpenFOAM
•  Notice that we are using 4 processors/partitions.
•  If you want to change the number of partitions, feel free to modify the
decomposeParDict dictionary.
Running in parallel
follow me.
•  cp processor0.OpenFOAM processor0
•  paraFoam
(Do not forget to open each of the processorN.OpenFOAM files)
•  To visualize the partitions, you will need to open in paraFoam each

processorN.OpenFOAM file.
Running in parallel
•  In paraFoam open each *.OpenFOAM file within the processorN
directory.
•  By doing this, we are opening the mesh partition for each processor.
•  Now, choose a different color for each set you just opened, and visualize the
partition for each processor. You will need to play with transparency and
volume rendering to see the cell distribution among the processors.
•  If you partitioned the mesh with many processors, creating the files
*.OpenFOAM manually can be extremely time consuming, for doing this in
an automatic way you can create a small shell or Python script.
•  Also, changing the color for each set in paraFoam can be extremely time
consuming, for automate this you can write a Python script.
Running in parallel
Mesh partitioning – Scotch Method

Running in parallel
•  Now do the same with the directory hierarchical, which contains the
hierarchical partitioning and compare both partitioning methods.
Running in parallel
Mesh partitioning – Hierarchical Method

Running in parallel
Mesh partitioning – Scotch Method Mesh partitioning – Hierarchical Method
Running in parallel
•  By the way, if you do not want to post-process each decomposed domain
individually, you can use the option –cellDist. This option applies for all
decomposition methods. In the terminal type:
•  cd $PTOFC/parallel_tut/yf17/scotch_celldist
•  decomposePar -cellDist
•  The option –cellDist will write the cell distribution as a

volScalarField field that can be used for post-processing. The new field
variable will be saved in the file cellDist located in the time directory 0.
•  Then launch paraFoam and post process the case as you usually do. You
will need to play with transparency and volume rendering to see the cell
distribution among the processors.
Running in parallel
Decomposing big meshes
Running in parallel
Decomposing big meshes
•  One final word, the utility decomposePar does not run in parallel. So, it is
not possible to distribute the mesh among different computing nodes to do
the partitioning in parallel.
•  If you need to partition big meshes, you will need a computing node with
enough memory to handle the mesh. I have been able to decompose
meshes with up to 500.000.000 elements, but I used a computing node with
512 gigs of memory.
•  For example, in a computing node with 16 gigs of memory, it is not possible

to decompose a mesh with 30.000.000; you will need to use a computing
node with at least 32 gigs of memory.
•  Same applies for the utility reconstructPar.

Running in parallel
Do all solvers/utilities run in parallel?
Running in parallel
Do all utilities run in parallel?
•  At this point you should have realized that not all solvers/utilities run in
parallel. To know what solvers/utilities do not run in parallel, in the terminal
type:
•  find $WM_PROJECT_DIR -type f | xargs grep –sl ‘noParallel’
•  By the way, paraFoam by default does not run in parallel. To run paraFoam in
parallel you will need to compile it with MPI support.
•  To compile paraFoam with MPI support in $WM_THIRD_PARTY_DIR/

makeParaView4 set the option withMPI'to'true,'
withMPI = true
•  Another important utility that does not run in parallel is blockMesh.

Running in parallel
Right syntax to run in parallel
Running in parallel
•  The syntax used to run OpenFOAM® solvers in parallel:
•  mpirun –np <NPROCS> <application/utility> –parallel
where mpirun is a shell script to use the mpi library, <NPROCS> is the
number of processors you want to use (same as the number of partitions),
<application/utility> is the OpenFOAM® solver or utility you want
to use, and -parallel is a flag you shall always use if you want to run in
parallel.
Running in parallel
•  For example, to run the solver icoFoam in parallel you will need to proceed
as follows:
•  mpirun -np 8 icoFoam -parallel
In this case we are using 8 processors.
Running in parallel
•  For example, to run the utility foamToEnsight in parallel you will need to
proceed as follows:
•  mpirun -np 2 foamToEnsight -parallel
In this case we are using 2 processors.
'
Today’s lecture

Running in a cluster using a job scheduler
•  Running OpenFOAM® in a cluster is similar to running in a normal
workstation with shared memory.
•  The only difference is that you will need to launch your job using a job
scheduler.
•  Common job schedulers are:
•  Terascale Open-Source Resource and Queue Manager (TORQUE).
•  Simple Linux Utility for Resource Management (SLURM).
•  Portable Batch System (PBS).
•  Sun Grid Engine (SGE).
•  Maui Cluster Scheduler.
•  BlueGene LoadLeveler (LL).
•  Ask your system administrator the job scheduler installed in your system.
Hereafter I will assume that you are using PBS.
•  To launch a job in a cluster with PBS, you will need to write a small shell
script where you tell to the job scheduler the resources you want to use and
what you want to do.
#!/bin/bash
#
# Simple PBS batch script that reserves 16 nodes and runs a
# MPI program on 128 processors (8 processor on each node)
# The walltime is 24 hours !
#
#PBS -N openfoam_simulation //name of the job
#PBS -l nodes=16,walltime=24:00:00 //max execution time
#PBS -m abe -M joel.guerrero@unige.it //send an email as soon as the job
//is launch or terminated
cd PATH_TO_DIRECTORY //go to this directory
#decomposePar //decompose the case, this line

//is commented
mpirun –np 128 pimpleFoam -parallel > log //run parallel openfoam
The green lines are not PBS comments, they are comments inserted in this slide. PBS comments use the number
sign (#).
•  To launch your job you need to use the qsub command (part of the PBS job
scheduler). The command qsub will send your job to queue.
•  qsub script_name
•  Remember, running in a cluster is no different from running in your

workstation or portable computer. The only difference is that you need to
schedule your jobs.
•  Depending on the system current demand of resources, the resources you

request and your job priority, sometimes you can be in queue for hours, even
days, so be patient and wait for your turn.
•  Remember to always double check your scripts.
•  Finally, remember to plan how you will use the resources available.
•  For example, if each computing node has 8 gigs of memory available and 8
cores. You will need to distribute the work load in order not to exceed the
maximum resources available per computing node.
•  So if you are running a simulation that requires 32 gigs of memory, the
following options are valid:
•  Use 4 computing nodes and ask for 32 cores. Each node will use 8 gigs
of memory and 8 cores.
•  But the following options are not valid:

•  Use 2 computing nodes. Each node will need 16 gigs of memory.
•  Use 16 computing nodes and ask for 256 cores. The maximum number
of cores for this job is 128.
NOTE: In this example each computing node has 8 gigs of memory available and 8 cores. !
Running in parallel
In the directory $PTOFC/parallel_tut you will find many tutorials, try to go through
each one to understand how to setup a parallel case in OpenFOAM®.
Module 6
Today’s lecture
1.  Finite Volume Method: A Crash Introduction
Finite Volume Method: A Crash introduction
Before continuing,
I want to remind you that this
is not a FVM/CFD course'
Theoretical background
•  Let us use the general transport equation as the starting point to explain the FVM,
Z Z Z Z
⇤ ⇥
dV + ⇥ · ( u⇥) dV ⇥·( ⇥⇥) dV = S (⇥) dV
VP ⇤t
| {z } VP | {z } VP | {z } VP | {z }
convective term diffusion term source term
temporal derivative
•  We want to solve the general transport equation for the transported quantity in a
given domain, with given boundary conditions and initial conditions.
•  This is a second order equation. For good accuracy, it is necessary that the order of
the discretization is equal or higher that the order of the equation that is being
discretized.
•  Hereafter we are going to assume that the discretization practice is at least second
order accurate in space and time.
•  Let us use the general transport equation as the starting point to explain the FVM,
Z Z Z Z
⇤ ⇥
dV + ⇥ · ( u⇥) dV ⇥·( ⇥⇥) dV = S (⇥) dV
VP ⇤t
| {z } VP | {z } VP | {z } VP | {z }
temporal derivative
•  Hereafter we are going to assume that the discretization practice is at least second
order accurate in space and time.
•  As consequence of this requirement, all dependent variables are assumed to vary

linearly around a point P in space and instant t in time,
⇥(x) = ⇥P + (x xP ) · (⇥⇥)P where ⇥P = ⇥(xP )

✓ ◆t
⇤⇥
⇥(t + t) = ⇥t + t where ⇥t = ⇥(t)
⇤t
PROFILE ASSUMPTIONS
•  Let us divide the solution domain into arbitrary control volumes such as the one
illustrated below.
•  The control volumes can be of any shape
(e.g., tetras, hexes, prisms, pyramids,
dodecahedrons, and so on).
•  The only requirement is that the elements
need to be convex and the faces that
made up the control volume, need to be
planar.
•  We know all the connectivity information
(P location, neighbors N’s of P, faces
Y
connectivity, vertices location and so on).
X
Z
N
X
Z
illustrated below.
•  The control volume has a volume V

and is constructed around point P, which
is the centroid of the control volume.
Therefore the notation .
•  The volume V of all control volumes is
known.
•  We also know the neighbors of the control
Y volume .
X
X
Module'6')'Lecture'17' VP 8'
Z
illustrated below.
•  The control volume faces are labeled f,
which also denotes the face center.
•  The face area vector Sf point outwards
from the control volume, is located at the
face centroid, is normal to the face and
has a magnitude equal to the area of the
face.
•  The vector from the centroid P to the face
center f is named Pf.
illustrated below.
•  The vector from the centroid P of to

the centroid N of VN is named d.
•  The location where the vector d intersects
a face is fi .
•  We know this information for all control
volumes and all faces.
illustrated below.
•  Putting all together, is a lot geometrical

information that we need to track.
•  A lot of overhead goes into the data book-
keeping.
Summarizing:
•  The control volume has a volume V and is constructed around point P, which is
the centroid of the control volume. Therefore the notation .
•  The vector from the centroid P of to the centroid N of VN is named d.
•  The control volume faces are labeled f, which also denotes the face center.
•  The location where the vector d intersects a face is fi .
•  The face area vector Sf point outwards from the control volume, is located at the
face centroid, is normal to the face and has a magnitude equal to the area of the face.
•  The vector from the centroid P to the face center f is named Pf.
•  In the control volume illustrated, the centroid P is given by
Z
(x xP ) dV = 0
VP
•  In the same way, the centroid of face f is given by

Z
(x xP )dS = 0
Sf
•  Finally, we assume that the values of all variables are computed and stored in
the centroid of the control volume and that they are represented by a
piecewise constant profile (the mean value),
Z
1
P = = (x)dV
VP VP
•  This is known as the collocated arrangement.

•  This is the variable arrangement and mean value assumptions.
•  Let us integrate the general transport equation in space over arbitrary control
volumes, this yields to
Z Z Z Z
⇤ ⇥
dV + ⇥ · ( u⇥) dV ⇥·( ⇥⇥) dV = S (⇥) dV
VP ⇤t
| {z } VP | {z } VP | {z } VP | {z }
temporal derivative
•  Next, we recall the Gauss’s theorem,

Z I
· adV = dS · a
V V
where is a closed surface bounding the control volume and dS

represents an infinitesimal surface element with associated normal n pointing
outward of the the surface .
•  Notice that
ndS = dS
•  Let us integrate the general transport equation in space over arbitrary control
volumes, this yields to
Z Z Z Z
⇤ ⇥
dV + ⇥ · ( u⇥) dV ⇥·( ⇥⇥) dV = S (⇥) dV
VP ⇤t
| {z } VP | {z } VP | {z } VP | {z }
temporal derivative
•  Hereafter, we use the Gauss's theorem to convert the volume integrals into surface
integrals,
Z I I Z
⇤
( ⇥) dV + dS · ( u⇥) dS · ( ⇥⇥) = S (⇥) dV
⇤t VP ⇥VP | {z } ⇥VP | {z } VP
convective flux diffusive flux
Z I
•  Recall the Gauss’s theorem · adV = dS · a
V Module'6')'Lecture'17'
V 16'
Convective, diffusive, gradients and source

terms approximations
•  Integrating in space each term of the general transport equation and by using
Gauss’s theorem, yields to the following discrete equations for each term
Convective term:
(
where we have approximated the integrant
By using Gauss’s theorem we convert by means of the mid point rule, which is
volume integrals into surface integrals second order accurate
Gauss’s theorem:
Z I
· adV = dS · a
V V
Diffusive term:
(
where we have approximated the integrant
By using Gauss’s theorem we convert by means of the mid point rule, which is
volume integrals into surface integrals second order accurate
Gauss’s theorem:
Z I
· adV = dS · a
V V
Source term: Z
S ( ) dV = Sc VP + Sp VP P
VP
This approximation if exact if S is either constant of varies

linearly within the control volume; otherwise is second order
accurate Sc is the constant part of the source term and
Sp is the non-linear part
Gradient term:
1 X
(r )P = (Sf f)
VP
f
where we have approximated the centroid

gradients by using the Gauss theorem.
This method is second order accurate
Convective term:
Diffusive term:
Source term: Z
S ( ) dV = Sc VP + Sp VP P
VP
Gradient term:
1 X
(r )P = (Sf f)
VP
f
•  Using the previous equations to evaluate the general transport equation over all the
control volumes, we obtain the following semi-discrete equation
Z X X
⇤ ⇥
dV + Sf · ( u⇥)f Sf · ( ⇥⇥)f = (Sc VP + Sp VP ⇥P )
VP ⇤t
| {z } f | {z } f | {z } | {z }
convective flux difussive flux source term
temporal derivative
C
where S · (⇢u ) = F is the convective flux and S · (⇢ r ) = F D is the
diffusive flux.
•  Recalling that all variables are computed and stored at the centroid of the control
volumes.
•  The face values appearing in the convective and diffusive fluxes have to be computed
by some form of interpolation from the centroid values of the control volumes at both
sides of face f.
Convective fluxes
•  By looking the figure below, the face values appearing in the convective flux can be
computed as follows,
fN
ff
fP
d
P f N
•  This type of interpolation scheme is known as linear interpolation or central

differencing and it is second order accurate.
•  However, it may generate oscillatory solutions (unbounded solutions).
A B
fN ff fN
F F
fP ff fP
d d
P f N P f N
(
f = P for F̊ 0,
f =
f = N for F̊ < 0.
•  This type of interpolation scheme is known as upwind differencing and it is first order
accurate.
•  This scheme is bounded and diffusive.
A F B F
fN fP
ff ff
fP fN
fPP fNN
duu du dd dd du duu
PP ff P f N P f N ff NN
8 1 2 1
>
> + ( PP ) = for F 0,
< P
2
P
3
P
2
PP
f =
>
> 1 2 1
: + (
N N NN ) = N NN for F < 0.
2 3 2
•  This type of interpolation scheme is known as second order upwind differencing
(SOU), linear upwind differencing (LUD) or Beam-Warming (BW), and it is second
order accurate.
•  For highly convective flows or in the presence of strong gradients, this scheme is
oscillatory (unbounded).
•  To prevent oscillations in the SOU, we add a gradient or slope limiter function (r).
8 1
> +
>
< P P( P PP ) for F 0,
2
f =
>
> 1
: +
N P ( NN N) for F < 0.
2
•  When the limiter detects strong gradients or changes in slope, it switches to low
resolution (upwind).
•  The concept of the limiter function (r) is based on monitoring the ratio of
successive gradients, e.g.,
N P P N
rP = and rP+ =
P PP N NN
•  By adding a well designed limiter function (r) , we get a high resolution (second
order accurate), and bounded scheme. This is a TVD scheme.
•  More on TVD schemes on the nextModule'6')'Lecture'17'
slides. 28'
TVD Schemes
•  A TVD scheme, is a scheme that does not create new local undershoots and/or
overshoots in the solution or amplify existing extremes.
•  In CFD we want stable, non-oscillatory, bounded, high order schemes. We want high
resolution schemes, in other words, TVD and second order accurate schemes.
•  The Sweby diagram (Sweby, 1984), gives the necessary and sufficient conditions for
a scheme to be TVD. In the figure, the grey area represents the admissible TVD
region. However, not all limiter functions are second order.
8 1
> +
>
< P P( P PP ) for F 0,
2
(r) = 2r (D) (r) = r (CD) f =
>
>
: 1 +
N P ( NN N) for F < 0.
2
3
2 (r) = 2
1 (r) = 1 (SOU )
(r) = 0 (U D)
0 1 2 3
Module'6')'Lecture'17' TVD REGION 30'
r
•  Not all TVD schemes are high resolution.
•  The choice of the limiter function (r) dictates the order of the scheme and its
boundedness.
•  High resolution schemes falls in the blue area. Conversely, low resolution schemes
falls in the grey area.
•  The development of high resolution schemes is one of the most remarkable
achievements of the history of CFD.
(r) = 2r (D) (r) = r (CD)
2 (r) = 2
1 (r) = 1 (SOU )
(r) = 0 (U D)
0 1 2 3
TVD - HIGH RESOLUTION REGION 31'
r TVD - LOW RESOLUTION REGION
•  The drawback of the limiters is that they reduce the accuracy of the scheme locally to
first order (low resolution scheme), when r  0 (sharp gradient, opposite slopes or
zero gradient). However, this is justify when it serves to suppress oscillations.
•  The various limiters have different switching characteristics and are selected
according to the particular problem and solution scheme.
•  No particular limiter has been found to work well for all problems, and a particular
choice is usually made on a trial and error basis.
(r) = 2r (D) (r) = r (CD)
2 SUPERBEE (r) = 2
VANLEER
1 MINMOD (r) = 1 (SOU )
(r) = 0 (U D)
0 1 2 3
TVD - HIGH RESOLUTION REGION 32'
r
•  Let us see how the superbee, minmod and vanleer TVD schemes behave in a
numerical schemes killer test case.
•  The oblique double step profile in a uniform vector field (pure convection).
•  By the way, this problem has an exact solution.
•  Let us see how the superbee, minmod and vanleer TVD schemes behave in a
numerical schemes killer test case.
•  The oblique double step profile in a uniform vector field (pure convection).
SuperBee Minmod vanLeer
•  Comparison of the TVD-minmod method (2nd order) and upwind method (1st order).
•  The upwind method is extremely stable and non-oscillatory.
•  On the other hand, the upwind method is highly diffusive.
Upwind – 1st order TVD-Minmod – 2nd order
•  Let us see how the non-linear limiter functions compare.
•  Let us see how the linear limiter functions compare.
•  Let us see how the linear and non-linear limiter functions compare.
•  If you are interested, you will find this case in the

directory:
$PTOFC/my_cases0/oblique_step/c2/d2
Interpolation of convective fluxes in a

skew mesh
•  In the case of a skew mesh (as the one in the figure), we should introduce a
correction in order to maintain second order accuracy and avoid unboundedness,
1. f = fi + i ·( ) fi
f S 2. fi = fx P + (1 fx ) N
P
Di
d fi r fi = fx r P + (1 fx ) r N
N
fi N | xfi xN |
fx = = .
PN |d|
1 X 1 X h i
3. ( )P = Sf f = Sf fi + i ·( ) fi
VP VP
f f
( N P)
⇥ fi = Initial approximation of the face gradient
|d|
•  In the case of a skew mesh (as the one in the figure), we should introduce a
correction in order to maintain second order accuracy and avoid unboundedness,
1 X
1. (r )P = (Sf f)
VP
f
D Pf
f
S ( P + Pf · P) +( N + Nf · N)
P D Nf
2. f =
2
d
N
3. (r )f = fx (r )P + (1 fx ) (r )N
( P + N) (r P +r N)
f = and r f = are the initial approximations
2 2
Diffusive fluxes
•  By looking the figures below, the face values appearing in the diffusive flux in an
orthogonal mesh can be computed as follows,
S
d S d
P f N P f N
Orthogonal mesh
N P
S · (⇥ )f = |S| .
|d|
•  This is a central difference approximation of the first order derivative. This type of
approximation is second order accurate.
•  By looking the figures below, the face values appearing in the diffusive flux in a non-
orthogonal mesh ( 20 ) can be computed as follows,
S
d S d
P f N P f N
Non-orthogonal mesh
N P
S · (⇥ )f = | ?| + k · (⇥ )f .
|d| | {z }
| {z } non-orthogonal contribution
orthogonal contribution
•  This type of approximation is second order accurate but involves a larger truncation
error. It also uses a larger numerical stencil, which make it less stable.
Correction of diffusive fluxes in a

non-orthogonal mesh
•  By looking the figures below, the face values appearing in the diffusive flux in a non-
orthogonal mesh ( 40 ) can be computed as follows,
S S k
k
d d
P f D N P f D N
Minimum correction approach Over-relaxed approach
d·S d
? = d. ? = |S|2 .
d·d d·S
S= ? + k.
N P
S · (⇥ )f = | ?| + k · (⇥ )f .
|d| | {z }
•  The face gradient of the non-orthogonal contribution is computed by using linear
interpolation from the gradient of the control volumes centroid, computed using Gauss
theorem.
N P
S · (⇥ )f = | ?| + k · (⇥ )f .
|d| | {z }
S
d
P f N
(r )f = fx (r )P + (1 fx ) (r )N where
Mesh induced errors
•  Mesh induced errors. In order to maintain second order accuracy, and to avoid
unboundedness, we need to correct non-orthogonality and skewness errors.
S
d S d
P f N P f N
Orthogonal and non skew mesh Non-orthogonal and non skew mesh
f S f S
P Di Di
P d N
d fi fi
N
Orthogonal and skew mesh Module'6')'Lecture'17' Non-orthogonal and skew mesh 50'
Temporal discretization
•  Using the previous equations to evaluate the general transport equation over all the
control volumes, we obtain the following semi-discrete equation
Z X X
⇤ ⇥
dV + Sf · ( u⇥)f Sf · ( ⇥⇥)f = (Sc VP + Sp VP ⇥P )
VP ⇤t
| {z } f | {z } f | {z } | {z }
convective flux difussive flux source term
temporal derivative
C
where S · (⇢u ) = F is the convective flux and S · (⇢ r ) = F D is the
diffusive flux.
•  After spatial discretization, we can proceed with the temporal discretization. By

proceeding in this way we are using the Method of Lines (MOL).
•  The main advantage of the MOL method, is that it allows us to select numerical
approximations of different accuracy for the spatial and temporal terms. Each term
can be treated differently to yield to different accuracies.
•  Now, we evaluate in time the semi-discrete general transport equation
2 3
Z t+ t ✓ ◆ X X
4 ⇤ ⇥ VP + Sf · ( u⇥)f Sf · ( ⇥⇥)f 5 dt
t ⇤t P f f
Z t+ t
= (Sc VP + Sp VP ⇥P ) dt.
t
•  At this stage, we can use any time discretization scheme, e.g., Crank-Nicolson, euler
implicit, forward euler, backward differencing, adams-bashforth, adams-moulton.
•  It should be noted that the order of the temporal discretization of the transient term
does not need to be the same as the order of the discretization of the spatial terms.
Each term can be treated differently to yield different accuracies. As long as the
individual terms are at least second order accurate, the overall accuracy will also be
second order.
Linear system solution
•  After spatial and temporal discretization and by using equation
2 3
Z t+ t ✓ ◆ X X
4 ⇤ ⇥ VP + Sf · ( u⇥)f Sf · ( ⇥⇥)f 5 dt
t ⇤t P f f
Z t+ t
= (Sc VP + Sp VP ⇥P ) dt.
t
in every control volume of the domain, a system of linear algebraic equations for
the transported quantity is assembled
0 1 0 1 0 1
..
a11 a12 .
B C B C B C
B .. C B C B C
B a21 a22 a23 . C B C B C
B C B C B C
B .. .. .. .. C B C B C
B . . . . C B S C B bS C
B C B C B C
B .. .. .. .. .. C B C B C
B . . . . . C B C=B C
B C⇥B W C B bW C
B aS aW aP aE aN C
B C B C B bP C
C B C B C
P
B .. .. .. ..
B . . . . C B C B bE C
C B C B C
E
B B C B C
B .. .. .. .. C B C B C
B . . . . C
@ A @ N A @ bN A
.. ..
. . aP P
and which can be solved by using any iterative or direct method.
So, what does OpenFOAM® do?
It simply discretize in space and time the governing

equations in arbitrary polyhedral control volumes over
the whole domain. Assembling in this way a large set of
linear discrete algebraic equations (DAE), and then it
solves this system of DAE to find the solution of the
transported quantities.
Therefore, we need to give to OpenFOAM® the following information:
•  Discretization of the solution domain or the mesh. This information is

contained in the directory constant/polyMesh/
•  Boundary conditions and initials conditions. This information is contained in
the directory 0/
•  Physical properties such as density, gravity, diffusion coefficient, viscosity,
etc. This information is contained in the directory constant/
•  Physics involve, such as turbulence modeling, mass transfer, etc. This
information is contained in the directories constant/ and/or system/
•  How to discretize in space each term of the governing equations (diffusive,
convective, gradient and source terms). This information is set in the
system/fvSchemes dictionary.
Therefore, we need to give to OpenFOAM® the following information:
•  How to discretize in time the obtained semi-discrete governing equations.

This information is set in the system/fvSchemes dictionary.
•  How to solve the linear system of discrete algebraic equations. This
information is set in the system/fvSolution dictionary.
•  Set runtime parameters and general instructions on how to run the case
(such as time step and maximum CFL number). This information is set in the
system/controlDict dictionary.
•  Additionally, we may set sampling and functionObjects for post-
processing. This information is contained in the specific dictionaries
contained in the directory system/
Discretization schemes implemented

in OpenFOAM®
•  We will now illustrate a few of the discretization

schemes available in OpenFOAM® using a model
case.
•  The case consist in pure convection of a scalar in a
vector field in a one dimensional tube.
•  If you are interested, this case is located in the
directory:
$PTOFC/my_cases0/pureconvection/c1
•  Pure convection of a scalar in a vector field in a one dimensional tube.
•  This problem has an exact solution in the form of a traveling wave.
•  In the figure, we show the solution for time = 0.5 s
Comparison of different spatial discretization schemes.

Euler in time – 100 cells – CFL = 0.1
Linear limiters on the Sweby diagram.

Linear limiters on the Sweby diagram.

Non-linear limiters on the Sweby diagram.

Non-linear limiters on the Sweby diagram.

All limiters together
Comparison of different gradient limiters.

Linear upwind in space – Euler in time – 100 cells – CFL 0.1



Comparison of different temporal discretization schemes

and gradient limiters.
Linear upwind in space – 100 cells – CFL 0.1
Comparison of different temporal discretization schemes

and gradient limiters.
Comparison of Crank Nicolson blending factor using cellLimited

leastSquares 0.5.
Comparison of Crank Nicolson blending factor using cellLimited

leastSquares 0.5.
Comparison of Crank Nicolson blending factor using cellMDLimited

Gauss linear 1.0 gradient limiter.
Comparison of Crank Nicolson blending factor using cellMDLimited

Gauss linear 1.0 gradient limiter.
Comparison of different time-step size (different CFL number).

Linear upwind in space – Euler in time – 100 cells
u t
CF L =
x
Comparison of different mesh sizes.

Linear upwind in space – Euler in time
u t
CF L =
x
•  Accuracy
•  Stability
•  Boundedness
Play by these terms and you will

succeed.
My favorite FVM/CFD references
•  As I mentioned earlier this is not a FVM/CFD course, but I

highly advise you to take some time and study the theory in
depth.
•  There is vast amount of literature in the field of FVM/CFD.

I will give you some of my favorite references, which are closed
related to what you will find in OpenFOAM®.
•  Therefore, I am involuntarily omitting other references which

are equally or even more important. Sorry for those guys.
•  Numerical Heat Transfer and Fluid Flow.
S. Patankar. 1980, Taylor & Francis
•  An Introduction to Computational Fluid Dynamics.
H. K. Versteeg, W. Malalasekera. 2007, Prentice Hall.
•  Computational Methods for Fluid Dynamics.
J. H. Ferziger, M. Peric. 2001, Springer.
•  Computational Fluid Dynamics: Principles and Applications.
J. Blazek. 2006, Elsevier Science.
•  A Finite Volume Method for the Prediction of Three-Dimensional Fluid Flow in Complex
Ducts.
M. Peric. PhD Thesis. 1985. Imperial College, London.
•  Error analysis and estimation in the Finite Volume method with applications to fluid
flows.
•  Computational fluid dynamics of dispersed two-phase flows at high phase fractions
H. Rusche. PhD Thesis. 2002. ImperialModule'6')'Lecture'17'
College, London. 84'
Module 6
Today’s lecture
1.  Boundary and initial conditions
Boundary conditions and initial conditions
•  First at all, when we use OpenFOAM® to find the approximate solution of
the governing equations, we are solving an Initial Boundary Value Problem
(IBVP).
•  In an IBVP, we need to impose appropriate boundary conditions and initial

conditions.
•  No need to say that the boundary conditions and initial conditions need to be
physically realistic.
•  Boundary conditions are a required component of the numerical method,

they tell what is going on the boundaries of the domain. You can see them
as source terms.
•  Initial conditions are also a required component of the numerical method,

they define the initial state of the problem.
A few words about boundary conditions
•  Boundary conditions can be divided into three fundamental or
mathematical types:
•  Dirichlet boundary conditions.
•  Neumann boundary conditions.
•  Robin Boundary conditions.
•  By the way, during this discussion the semantics is not important, that
depends of how you want to call the boundary conditions or how they are
named in the solver, i.e.,
•  in, inlet, inflow, velocity inlet, incoming flow and so on.
•  out, outlet, outflow, velocity outlet, outgoing flow and so on.
•  solid wall, non-penetrating wall, fixed wall and so on.

•  When we use a Dirichlet boundary condition, we prescribe the value of a
variable at the boundary.
•  When we use a Neumann boundary condition, we prescribe the gradient

normal to the boundary.
•  Robin boundary conditions, are a mixed of Dirichlet boundary conditions

and Neumann boundary conditions.
•  You can use any of these three boundary conditions in OpenFOAM®.
•  Defining boundary conditions involves:
•  Determining the boundary condition type.
•  Finding the location of the boundary condition in the domain.
•  Giving the required physical information.
•  The choice of the boundary conditions depend on:
•  Geometrical considerations.
•  Physics involved.
•  Information available at the boundary condition location.
•  Numerical considerations.
•  To define boundary conditions you need to know the location of the
boundaries (where they are in your mesh), and supply the information at the
boundaries.
•  You must know what information is required at the boundaries, you must
know the physics involved.
BC
Types of boundary conditions (B

IC Dirichlet
Neumann
Robin
BC BC
BC Initial contions (IC):

Uniform or non-uniform value in the
whole domain
Patches with uniform or non-uniform
values
Y BC
X Module'6')'Lecture'18' 8'
A few words about initial conditions
•  Initial conditions can be divided into two groups:
•  Uniform initial conditions.
•  Non-uniform initial conditions.
•  For non-uniform initial conditions, the value used can be obtained from:
•  Another simulation, including a solution with different grid resolution.
•  A potential solver.
•  Experimental results.
•  A mathematical function
•  Reduced order model. Module'6')'Lecture'18' 10'

•  Defining initial conditions involves:
•  Determining the initial condition type.
•  Finding the location of the initial condition in the domain.
•  Giving the required physical information.
•  The choice of the initial conditions depend on:
•  Geometrical considerations.
•  Physics involved.
•  Information available.
•  Numerical considerations.
•  For initial conditions, you need to supply the initial information or initial state
of your problem.
•  This information can be a uniform value or a non-uniform value.
•  You can apply the initial conditions to the whole domain or zones of the
domain (patches).
BC
Types of boundary conditions (B

IC1 Dirichlet
Neumann
Robin
BC BC
BC IC2 Initial contions (IC):

whole domain
Patches with uniform or non-unifor
values
Y BC
X Module'6')'Lecture'18' 12'
A few considerations and guidelines
•  Remember:
•  Poorly defined boundary conditions can have a significant

impact on your solution.
•  Sometimes, finding the right boundary conditions can be really

tricky.
•  Initial conditions are as important as the boundary conditions.
•  A good initial condition can improve the stability and convergence

rate.
•  On the other hand, unphysical initial conditions can slow

down the convergence rate or can cause divergence.
•  You need to define boundary conditions and initials conditions for

every single variable you are solving.
•  The required values of the boundary conditions and initial conditions depend
on the equations you are solving and physical models used, e.g.,
•  For incompressible, and laminar flows you will need to set only the
velocity and pressure.
•  If you are solving a turbulent compressible flow you will need to set
velocity, pressure, temperature and the turbulent variables.
•  For multiphase flows you will need to set the primitives variables for
each phase. You might also need to initialize the phases patches.
•  If you are doing turbulent combustion or chemical reactions, you will

need to define the species, reactions and primitive and turbulent
variables.
•  By the way, you also need to define the physical properties.
•  Remember, the physics is yours.

•  General guidelines when choosing the boundary conditions and initial
conditions:
•  Boundary conditions and initial conditions need to be physically

realistic.
•  Minimize grid skewness, non-orthogonality, growth rate, and aspect

ratio near the boundaries. You do not want to introduce diffusion
errors early in the simulation, specially close to the inlets.
•  Try to avoid large gradients in the direction normal to the boundaries

near inlets and outlets. That is to say, put your boundaries far away
from where things are happening.
conditions:
•  Do not force the flow at the outlet, use a zero normal gradient for all
flow variables except pressure. The solver extrapolates the required
information from the interior.
•  Be careful with backward flow at the outlets (flow coming back to the
domain) and backward flow at inlets (reflection waves), they
required special treatment.
•  If possible, select inflow and outflow boundary conditions such that

the flow either goes in or out normal to the boundaries.
•  Use zero gradient boundary conditions only with incompressible

flows and when you are sure that the flow is fully developed.
conditions:
•  At least one boundary condition should specify pressure

(total or static).
•  Outlets that discharge to the atmosphere can use a static pressure

boundary condition. This is interpreted as the static pressure of the
environment into which the flow exhausts.
•  Inlets that take flow into the domain from the atmosphere can use a
total pressure boundary condition (e.g. open window).
•  Mass flow inlets produce a uniform velocity profile at the inlet.
conditions:
•  The mass flow distribution at mass flow outlets is based on the

upstream values.
•  Pressure specified boundary conditions allow a natural velocity

profile to develop.
•  Velocity inlet boundary conditions are intended for incompressible

flow.
•  For compressible flows use mass flow inlets or pressure boundary

conditions.
•  Inlets and outlets boundary conditions:
•  Inlets are for regions where inflow is expected; however, inlets might support outflow
when a velocity profile is specified.
•  Pressure boundary conditions do not allow outflow at the inlets.
•  Velocity specified inlets are intended for incompressible flows.
•  Pressure and mass flow inlets are suitable for compressible and incompressible
flows.
•  Same concepts apply to outlets, which are regions where outflow is expected.
Slip wall or symmetry Slip wall or symmetry

Pressure or
Velocity Inlet Mass flow Inlet
Uniform flow Uniform flow
Outlet Outlet
No-slip wall No-slip wall
Outflow Artificial wall

allowed prevents outflow
Y Slip wall or symmetry Slip wall or symmetry
•  Zero gradient and backflow boundary conditions:
•  Zero gradient boundary conditions extrapolates the values from the domain. They
require no information.
Slip wall or symmetry
•  Zero gradient boundary conditions canPressure
be
Mass used at inlets and outlets.
or
flow Inlet
•  Backflow boundary conditions provide a generic outflow/inflow Uniform

condition,
flow with
specified inflow/outflow for the case of return flow.
•  In the case of a backflow outlet, when the flux is positiveNo-slip (out
wall of domain) it applies a
Neumann boundary condition (zero gradient), andArtificial

when wall
the flux is negative (into of
domain), it applies a Dirichlet boundary condition prevents
(fixed value).
outflow
•  Same concept applies to backflow inlets. Slip wall or symmetry
Slip wall or symmetry Slip wall or symmetry
Zero gradient outlet Inlet - Outlet

Uniform flow No back flow treatment Uniform flow Back flow treatment
No-slip wall No-slip wall
Inlet Inlet
Back flow Back flow

allowed not allowed
Y Slip wall or symmetry Slip wall or symmetry
•  Symmetry boundary conditions:
•  I do not like to use symmetry boundary conditions. They are a big simplification of
the problem, specially if you are dealing with turbulence.
•  However, they help to reduce mesh dimension and they speed-up the computations.
•  Have in mind that symmetry boundary conditions only apply to planar faces.
•  To use symmetry boundary conditions, both the geometry and the flow field must be
symmetric.
•  Mathematically speaking, setting a symmetry boundary condition is equivalent to:
•  Zero normal velocity at the symmetry plane.
•  Zero normal gradients of all variables at symmetry plane.
SLIP WALLS SLIP WALLS
NO-SLIP WALLS
SLIP WALLS
SYMMETRY
OUTFLOW
INFLOW
Y Y
X Z
SLIP WALLSModule'6')'Lecture'18' SLIP WALLS 22'

•  Domain dimensions (when the dimensions are not known):
•  As a general guideline you can use the dimensions illustrated in the figure, where L is
a reference length. In this case, L is the wing chord.
•  Always verify that there are no significant gradients normal to any of the boundaries
patches. If there are, you should consider increasing the domain dimensions.
5L
5L 15L 5L
Y 5L Y
X Z
Z
•  Location of the outlet boundary condition:
•  Place outlet boundary conditions as far as possible from recirculation zones or
backflow conditions, by doing this you increase the stability.
•  Remember, backflow conditions requires special treatment.
Y Y
X
X Z
Boundary conditions in OpenFOAM®
•  OpenFOAM® distinguish between base type boundary conditions and
numerical type boundary conditions.
•  Base type. This boundary condition is based on geometry information
or an inter-processor communication link (halo boundaries).
•  Numerical type. This boundary condition assigns the value to the field
variables in the given patch. It can be of primitive type or derived type.
•  Some base type and numerical type boundary conditions are paired. That
is, you define the same type for the base type and the numerical type.
•  OpenFOAM® distinguish between base type boundary conditions and
numerical type boundary conditions.
Unpaired Paired
symmetry
empty
patch
Base type wedge
wall
cyclic
processor
fixedValue
fixedGradient
zeroGradient
symmetry
fixedFluxPressure empty
Numerical type inletOutlet wedge
totalPressure cyclic
processor
uniformFixedValue
and so on …
•  Base type boundary conditions are defined in the file boundary located in
the directory constant/polyMesh
•  The file boundary is automatically created when you generate or convert
the mesh.
•  When you convert a mesh to OpenFOAM® format, you might need to
manually modify the file boundary. This is because the conversion utilities
do not recognize the boundary type of the original mesh.
•  Remember, if a base type boundary condition is missing, OpenFOAM® will
complain and will tell you where and what is the error.
•  Also, if you misspelled something OpenFOAM® will complain and will tell
you where and what is the error.
•  Numerical type boundary conditions are defined in the field variables
dictionaries located in the directory 0 (e.g. U, p).
•  When we talk about numerical type boundary conditions we are referring to
Dirichlet, Neumann or Robin boundary conditions.
•  In OpenFOAM®, numerical type boundary conditions can be of primitive or
derived type.
•  You need to manually create the field variables dictionaries (e.g. 0/U, 0/p).
I hope you know how to do it, because we have done it.
•  Remember, if you forget to define a boundary condition, OpenFOAM® will
complain and will tell you where and what is the error.
•  Also, if you misspelled something OpenFOAM® will complain and will tell
you where and what is the error.
•  The name of the base type boundary condition and the name of the
numerical type boundary condition needs to be the same, if not,
OpenFOAM® will complain.
•  Pay attention to this, specially if you are converting the mesh from another
format.
0/U 0/p constant/polyMesh/boundary
inlet inlet inlet
oUtlet outlet outlet
top top top
bottom bottom Bottom
cylinder cylinder cylinder
sym sym sym

•  The following base type boundary conditions are paired. That is, the type
needs to be same in the boundary dictionary and field variables
dictionaries (e.g. U, p).
constant/polyMesh/boundary 0/U - 0/p
symmetry symmetry
symmetryPlane symmetryPlane
empty empty
wedge wedge
cyclic cyclic
processor processor
•  The following numerical type boundary conditions can be any of the
primitive or derived type available in OpenFOAM®. Mathematically
speaking; they can be Dirichlet, Neumann or Robin boundary conditions.
constant/polyMesh/boundary 0/U - 0/p
fixedValue
fixedGradient
zeroGradient
fixedFluxPressure
inletOutlet
patch freeStream
slip
totalPressure
uniformFixedValue
and so on … 32'
•  The wall base type boundary condition is defined as follows:
constant/polyMesh/boundary 0/U 0/p
type fixedValue;
wall zeroGradient
•  This boundary condition is not contained in the patch base type boundary
condition group, because specialize modeling options can be used on this
boundary condition.
•  An example is turbulence modeling, where turbulence can be generated or
dissipated at the walls.
•  There are numerous primitive and derived type boundary conditions
implemented in OpenFOAM®.
•  You can find the source code of the numerical boundary conditions in the
following directory:
•  $FOAM_SRC/finiteVolume/fields
•  The wall boundary conditions for the turbulence models (wall functions), are
located in the following directory:
•  $FOAM_SRC/turbulenceModels/
•  To get more information about all the boundary conditions available in
OpenFOAM® you can read the Doxygen documentation, just look for the
Using the code section at the bottom of the page.
•  If you did not compile the Doxygen documentation, you can access the
information online, http://www.openfoam.org/docs/cpp/
A few boundary conditions setup
•  Boundary conditions setup:
At inflow: At outflow: At no-slip wall: At symmetry plane: At slip walls:
U = fixed value U = back flow U =0 U = symmetry U = slip
p = zero gradient p = fixed value p = zero gradient p = symmetry p = slip
T = fixed value T = back flow T = zero gradient T = symmetry T = slip
 = fixed value  = back flow  = zero gradient or fixed value  = symmetry  = slip
! = fixed value ! = back flow ! = zero gradient or fixed value ! = symmetry ! = slip
NO-SLIP WALLS
SLIP WALLS
SYMMETRY
OUTFLOW
INFLOW
Y Y
X Z
SLIP WALLS Module'6')'Lecture'18' SLIP WALLS 37'

At inflow: At outflow: At no-slip wall: At symmetry plane:
U = fixed value U = back flow U =0 U = symmetry
p = zero gradient p = fixed value p = zero gradient p = symmetry
T = fixed value T = back flow T = zero gradient T = symmetry
 = fixed value  = back flow  = zero gradient or fixed value  = symmetry
! = fixed value ! = back flow ! = zero gradient or fixed value ! = symmetry
SYMMETRY SYMMETRY
NO-SLIP WALLS
SYMMETRY
OUTFLOW
SYMMETRY
INFLOW
Y Y
X Z
SYMMETRY Module'6')'Lecture'18' SYMMETRY 38'

NO-SLIP WALLS NO-SLIP WALLS
NO-SLIP WALLS
SYMMETRY
OUTFLOW
SYMMETRY
INFLOW
Y Y
X Z
NO-SLIP WALLSModule'6')'Lecture'18' NO-SLIP WALLS 39'

OUTFLOW OUTFLOW
NO-SLIP WALLS
SYMMETRY
OUTFLOW
INFLOW
OUTFLOW
Y Y
X Z
OUTFLOW Module'6')'Lecture'18' OUTFLOW 40'

SYMMETRY SYMMETRY
NO-SLIP WALLS
SLIP WALLS
SYMMETRY
OUTFLOW
INFLOW
Y Y
X Z
SYMMETRY Module'6')'Lecture'18' SYMMETRY 41'

NO-SLIP WALLS
SLIP WALLS
SYMMETRY
OUTFLOW
INFLOW
Y Y
X Z

At inflow: At outflow: At no-slip wall: At periodic patches: At slip walls:
U = fixed value U = back flow U =0 U = periodic U = slip
p = zero gradient p = fixed value p = zero gradient p = periodic p = slip
T = fixed value T = back flow T = zero gradient T = periodic T = slip
 = fixed value  = back flow  = zero gradient or fixed value  = periodic  = slip
! = fixed value ! = back flow ! = zero gradient or fixed value ! = periodic ! = slip
NO-SLIP WALLS OUTFLOW
PERIODIC
INFLOW
PERIODIC
Y Y
X Z

•  So far we have not study turbulence, however, in all previous configurations
we are missing one boundary condition?
•  Do you know which one?
•  Do not worry we are going to address the boundary conditions needed for
turbulence modeling later on.
•  All the previous boundary conditions setup will generate a well posed
problem.
•  However, some of them are more stable.

•  A very robust and stable configuration is to set the inlet velocity and
the static pressure at outlet. The inlet total pressure is an implicit
result of the solution.
•  You can also set mass flow rate at inlet and the static pressure at
outlet. The inlet total pressure will be adjusted to get the given mass
flow.
•  Less robust but still stable, total pressure at inlet with static pressure
at outlet. This configuration is sensitive to initial conditions.
•  And some configurations are unreliable.
•  Inlet velocity, mass flow or total pressure at inlet and zero gradient at
outlet. These combinations should be avoided because the static
pressure level is not fixed.
•  Velocity at outlet. Unless the flow is fully developed, you will be
forcing the flow to an unrealistic condition.
•  Zero gradients at inlet and outlet, this will result in an ill-posed
problem.
•  Velocity at inlet and outlet. The configuration is unstable.
•  Inlet velocity and pressure zero gradient at outlet. This combination

should be avoided because the static pressure level is not fixed.
•  Qualitatively speaking the results are very different.
•  Visualization or co-processing helped us to identify a potential
problem.
BCs 1. BCs 2.
Inlet velocity and fixed outlet pressure Inlet velocity and zero gradient outlet pressure
•  Inlet velocity and pressure zero gradient at outlet. This combination

should be avoided because the static pressure level is not fixed.
•  However, quantitatively speaking the results seem to be fine.
•  Very misleading.
Residual plot for pressure Quantity of interest – Force coefficient on the body
A mental exercise
•  Let us do a mental exercise.
•  What boundary conditions will you use for this case?
•  By the way, there is no wrong or right answer (maybe there are a few bad
choices), everything depends of what do you want to do.
BC
Types of boundary conditions (BC):

IC Dirichlet
Neumann
Robin
BC BC
BC Initial contions (IC):

whole domain
Patches with uniform or non-uniform
values
Y BC
•  One of the possible scenarios, external aerodynamics.
Slip wall or symmetry
Uniform flow
Inlet value Outlet value
No-slip wall
Y Slip wall or symmetry
•  Another possible scenarios, buoyant flow and a heated body.
Outlet value
Uniform flow
Adiabatic wall Adiabatic wall

Wall temperature
X Module'6')'Lecture'18'
Wall temperature 52'
•  For those interested in marine applications, a virtual towing tank and 1DOF
simulation.
Outlet value
Phase 1
Moving wall (1DOF)
Inlet value Outlet value
Phase 2
Y Slip wall
•  And if you go to the real world (3D), nothing change. You just need to
impose the boundary conditions in the third dimension.
Symmetry Symmetry
No-slip walls
Outlet value
Inlet value
Periodic
Periodic
Uniform flow Y Uniform flow Y
X Z
Symmetry Symmetry
Periodic
Outlet value
Inlet value
Y
Periodic
X
Z
Module 6
Today’s lecture
1.  Unsteady and steady simulations

2.  Understanding residuals
Today’s lecture

Unsteady and steady simulations
•  Nearly all flows in nature and industrial applications are unsteady (or
transient).
•  If you are dealing with turbulence (almost every scenario), you need to take
into account the unsteadiness inherent of turbulent flows.
•  Unsteadiness is due to:
•  Instabilities.
•  Non-equilibrium initial conditions.
•  Time-dependent boundary conditions.
•  Source terms.
•  Moving or deforming bodies.
•  Turbulence.
•  Buoyancy.
•  Convection, and so on.
•  A few examples of unsteady applications:
•  Internal and external aerodynamics.
•  Shock wake interaction.
•  Hydrodynamics, sea keeping, free surface, waves.
•  Multiphase flows.
•  Turbomachinery.
•  Moving and deforming bodies.
•  Fluid-structure interaction.
•  Vortex-induced vibrations.
•  Unsteady heat transfer.
•  HVAC.
Vortex shedding
Buoyant flow
Multiphase flow
Turbulent flow
Flapping UAV
Multiphase flows – Continuous stirred tank reactor

Marine applications - Sea keeping

How to run unsteady simulations in OpenFOAM®?
•  Select the time step. The time-step must be chosen in such a way that it
resolves the time-dependent features and maintains solver stability.
•  Select the temporal discretization scheme.
•  Set the tolerance (absolute and/or relative) of the linear solvers.
•  If it applies, monitor the CFL condition.
•  Monitor the stability and boundedness of the solution.
•  Monitor a quantity of interest.
•  And of course, you need to save the solution with a given frequency.
•  Have in mind that unsteady simulations generate a lot of data.
•  End time of the simulation?, it is up to you.
How to run unsteady simulations in OpenFOAM®?
•  In the system/controlDict dictionary you set runtime parameters

and general instructions on how to run the case (such as time step and
maximum CFL number). You also set the saving frequency.
•  In the system/fvSchemes dictionary you set the temporal
discretization scheme.
•  In the system/fvSolution dictionary you set the linear solvers.
•  Also, you will need to set the number of corrections of the
velocity-pressure coupling method used (e.g. PISO or PIMPLE), this is
done in the system/fvSolution dictionary.
•  Additionally, you may set functionObjects in the system/
controlDict dictionary. The functionObjects are used to do
sampling, probing and co-processing.
What about steady simulations?
•  First at all, steady simulations are a big simplification of reality.

•  As I told you before, most of the flows you will encounter are unsteady.
•  In steady simulations we made two assumptions:
•  We ignore unsteady fluctuations. That is, we neglect the temporal
derivative in the governing equations.
•  We perform time averaging when dealing with stationary turbulence
(RANS modeling)
•  The advantage of steady simulations is that they require lower
computational cost and are easier to post-process and analyze.
•  In OpenFOAM® is possible to run steady simulation.

•  To do so, you need to use the appropriate solver and set the discretization
scheme to deal with a steady simulation.
•  As you are not solving the temporal derivative, you do not need to set the
time step. However, you need to tell to OpenFOAM® how many iterations
you would like to run.
•  You can also set the residual controls. If you do not set the residual
controls, OpenFOAM® will run until reaching the maximum number of
iterations.
•  You also need to set the under-relaxation factors. The under-relaxation

factors control the change of the variable .
n n 1 n⇤ n 1
P = P + ↵( P P )
•  If < 1 means that we are using under-relaxation.
•  Under-relaxation is a feature typical of steady solvers using the SIMPLE

method.
•  If you do not set the under-relaxation factors, OpenFOAM® will use the
default hard-wired values (1.0 for all field variables).
•  These are the under-relaxation factors I often use (which are the commonly
used).
relaxationFactors
{
p 0.3;
U 0.7;
k 0.7;
omega 0.7;
}
•  According to the physics involved you will need to add more under-relaxation
factors.
•  The under-relaxation factors are bounded between 0 and 1.
relaxationFactors
0 1
Velocity
Stability
•  Selecting the under-relaxation factors it is kind of equivalent to selecting the

right time step.
How to run steady simulations in OpenFOAM®?
•  In the system/controlDict dictionary you set runtime parameters

and general instructions on how to run the case (such as the number of
iterations to run). You also set the saving frequency.
•  In the system/fvSchemes dictionary you set the temporal
discretization scheme, for steady simulations it must be steadyState.
•  In the system/fvSolution dictionary you set the linear solvers,
under-relaxation factors and residual controls.
•  Also, you will need to set the number of corrections of the
velocity-pressure coupling method used (e.g. SIMPLE), this is done in
the system/fvSolution dictionary.
•  Additionally, you may set functionObjects in the system/
controlDict dictionary. The functionObjects are used to do
sampling, probing and co-processing.
How to choose the time-step in unsteady

simulations and monitor the solution
•  Remember, when running unsteady simulations the time-step must be
chosen in such a way that it resolves the time-dependent features and
maintains solver stability.
When you use large time

steps you do not resolve well
the physics
By using a smaller time step

you resolve better the physics
•  When running unsteady simulations, it is highly advisable to monitor a
quantity of interest.
•  The quantity of interest can fluctuate in time, this is an indication of
unsteadiness.
•  Remember to choose wisely where to do the sampling.
sampling
•  Remember to choose wisely where to do the sampling.
•  When you run unsteady simulations, flow variables can stop changing with
time. When this happens, we say we have arrived to a steady state.
•  Remember this is the exception rather than the rule.
•  If you use a steady solver, you will arrive to the same solution (maybe not),
in less iterations.
•  Steady simulations require less computational power than unsteady
simulations.
•  They are much faster than unsteady simulations.
•  They are easier to post-process and analyze.
•  Steady simulations require less computational power than unsteady
simulations.
•  But sometimes they do not converge to the right solution.
•  You can use the solution of an unconverged steady simulation as initial
conditions for an unsteady simulation.
•  Before talking about residuals, let me clarify something.
•  When I talk about iterations in unsteady simulations, I am talking about the
time-step or outer-iterations.
•  Before talking about residuals, let me clarify something.
•  When I talk about iterations in unsteady simulations, I am talking about the
time-step or outer-iterations.
•  And we loop inside each time-step (outer-iteration), until reaching the linear
solver tolerance or maximum number of iterations.
Today’s lecture

Understanding residuals
•  This is the typical residual plot for an unsteady simulation.
•  The solution must converge at every time-step.
•  The first time-steps the solution might not converge, this is acceptable.
•  Also, you might need to use a smaller time-step during the first iterations to
maintain solver stability.
•  If the solution is not converging, try to reduce the time-step size.
•  You can also increase the number of maximum inner iterations.
•  If the initials residuals fall bellow the convergence criterion, you might say
that you have arrived to a steady solution.
•  Remember, residuals are not a direct indication that you are converging to
the right solution.
•  It is better to monitor a quantity of interest.
•  And by the way, you should get physically realistic values.
•  To monitor the stability, you can check the minimum and maximum values of
the field variables.
•  If you have bounded quantities, check that you do not have over-shoots or
under-shoots.
•  Let us study in details the residual plot of an unsteady solution.
•  Pay attention that we are plotting the residuals against iterations or
time-steps or outer-iterations.
•  Let us do the distinction between inner-iterations and outer-iterations.
•  This the plot of the number on inner-iterations against the number of
outer-iterations (time-steps).
•  Each time-step is converging to the given criterion (linear solvers) in n
inner-iterations.
•  This is the residual plot of an unsteady solution that reached a steady-state
behavior.
•  Pay attention that we are plotting the residuals against iterations or
time-steps or outer-iterations.
•  And this the plot of the number of inner-iterations against the number of
outer-iterations (time-steps).
•  Notice that after 2000 time-steps, the solution arrives to the convergence
criterion (in the linear solvers) in just 1 iteration.
•  Let us study the residual plot of a steady solver.
•  Notice that I am making the distinction between steady solver and unsteady
solution.
•  Here the initial residuals are not falling. This is an indication of an unsteady
solution.
•  Let us study the residual plot of a steady solver.
•  In this case initial residuals are falling below the convergence criterion,
hence we have reached a steady-state.
•  In comparison to unsteady solvers, steady solvers require less iterations to
arrive to a converge solution, if they arrived.
•  Let us compare the solution of a steady solver and the solution of a
unsteady solver.
•  In comparison to unsteady solvers, steady solvers require less iterations to
arrive to a converge solution, if they arrived.
•  Finally, let us compare the residuals of a first order and a second order
numerical scheme.
•  This is the residual plot of an unsteady simulation and the final residuals of
both methods are converging to the desired tolerance.
•  This is the plot of the number of inner-iterations against the number of outer-
iterations (time-steps).
•  As you can see, the first order method is less computationally expensive.
•  However, the fact that the first order method converge faster and is less
computationally expensive, it does not mean it is better.
•  As you can see, it converge to the wrong solution.
•  All the previous examples correspond to the cylinder case at Reynolds
number equal to 200 and 20.
•  If you are interested in reproducing the previous results, the case is located
in the directory:
$PTOFC/first_tutorial/vortex_shedding/c1
•  This is the output of all residuals for a Reynolds number equal to 200.
•  This is the output of the inner-residual against the outer-residuals for a
Reynolds number equal to 200.
•  This is the output of the aerodynamic coefficients for a Reynolds number
equal to 200.
•  This is the output of all residuals for a Reynolds number equal to 20.
•  This is the output of the inner-residual against the outer-residuals for a
Reynolds number equal to 20.
•  This is the output of the aerodynamic coefficients for a Reynolds number
equal to 20.
Module 6
Today’s lecture
1.  On the CFL number
On the CFL number
•  First at all, what is the CFL or Courant number?
•  In one dimension, the CFL number is defined as,
u t
CF L =
x
•  The CFL number is a measure of how much information ( u )
traverses a computational grid cell ( x ) in a given
time-step ( t ).
On the CFL number
•  The CFL number is a necessary condition to guarantee the
stability of the numerical scheme.
•  But not all numerical schemes have the same stability

constrains.
•  By doing a linear stability study, we can find the stability

requirements of each numerical scheme (but this is out of the
scope of this lecture).
On the CFL number
CFL number condition
On the CFL number
•  Let us talk about the CFL number condition.
•  The CFL number condition is the maximum allowable CFL

number a numerical scheme can use.
•  For the n - dimensional case, the CFL number condition

becomes,
Xn
ui
CF L = t  CF Lmax
i=1
x i
On the CFL number
To get a better idea of the importance of the CFL

number condition, let us talk again about
explicit and implicit methods.
On the CFL number
Explicit methods
•  Most of the explicit numerical schemes have a CFL condition

close to 1.0.
•  Some of them have a CFL condition of 0.5, and some of them

can go up to 2.0.
•  If you choose a CFL number larger than the maximum

allowable by the explicit numerical scheme, your numerical
solution will become unstable and it will diverge.
•  Explicit numerical schemes are conditionally stable.
•  In OpenFOAM® you will find explicit numerical schemes, so be

careful when choosing your time-step or CFL number.
On the CFL number
Implicit methods
•  On the other hand, implicit numerical schemes are

unconditionally stable.
•  In other words, they are not constrained to the CFL number

condition.
•  However, the fact that you are using a numerical scheme that is
unconditionally stable, does not mean that you can choose a
time step of any size.
•  The time-step must be chosen in such a way that it resolves the

time-dependent features, and it maintains the solver stability.
•  In OpenFOAM® you will find many implicit numerical schemes.

On the CFL number
Some facts of explicit and implicit methods
•  For the same CFL number, the time-step of explicit methods is

usually an order of magnitude lower than the time-step required
for implicit methods.
•  This means that they are approximately ten times slower than
implicit methods.
•  However, the memory requirements are really low and they are
extremely easy to parallelize.
•  Explicit methods perform really well in GPUs.
•  Also, explicit methods are really easy to implement.
On the CFL number
•  Explicit numerical schemes are extremely accurate.
•  If you are interested in using large time steps (large CFL

number) with implicit methods, it is highly advisable that you
choose a time step in such a way that it resolves the temporal
scales (good accuracy).
•  If you use large time steps with implicit methods, it is likely that
you will need to increase the cell count in order to maintain the
accuracy of the solution, and this translates in an increased
computational cost.
On the CFL number
•  In my personal experience, I have been able to go up to a

CFL = 5.0 while maintaining the accuracy and without
increasing too much the computational cost.
•  But as I am often interested in the unsteadiness of the solution,

I usually use a CFL number in the order of 1.0
On the CFL number
My personal view of the CFL number
On the CFL number
•  I like to view the CFL number as follows,
u t u speed of the PDE

CF L = = =
x x/ t speed of the mesh
•  It is an indication of the amount of information that propagates

through one cell (or many cells), in one time-step.
On the CFL number
•  The CFL number is an indication of the amount of information
that propagates through one cell (or many cells), in one time-
step. f P
fE
CV CENTER FACE CENTER CV FACE
f(x)
f
CV W
CV P
CV P
W P E x
CV E
CV W
CV E
fW
i+2
CFL = 1 i+1
BOUNDARY NODE i
i-1
i-2
CFL = 2
CFL = 3
u t u speed of the PDE

CF L = = =
x x/ t speed of the mesh
On the CFL number
•  By the way, and this is extremely important, the CFL condition is
a necessary condition for stability (and hence convergence).
•  But it is not always sufficient to guarantee stability.
•  Other properties of the discretization schemes that you should

observe are: conservationess, boundedness, transportiveness,
and accuracy.
•  The CFL number is not a magical number !!!
Comparison of different time-step size (different CFL number)

for a model problem.
Linear upwind in space – Euler in time – 100 cells
u t
CF L =
x
Comparison of different mesh sizes for a model problem.

Linear upwind in space – Euler in time
u t
CF L =
x
Module 7
Today’s lecture
1.  Programming in OpenFOAM®.

Building blocks.
Programming in OpenFOAM®
During this session we will:
•  First, we will start by taking a look at the algebra of tensors in

OpenFOAM®.
•  Then, we will take a look at how to generate tensor fields from tensors.
•  Next, we will learn how to access mesh information.
•  Finally we will see how to discretize a model equation and solve the
linear system of equations using OpenFOAM® classes and templates.
During this session we will:
•  And of course, we are going to program a little bit in C++.
•  But do not be afraid, after all this is not a C++ course.
•  Remember, all OpenFOAM® components are implemented in library

form for easy re-use.
•  OpenFOAM® encourage code re-use. So basically we are going to take

something that already exist and we are going to modify it to fix our
needs.
•  I like to call this method CPAC (copy-paste-adapt-compile).

By the way and in case you did not know it,
•  In the directory $WM_PROJECT_DIR/applications/test,

you will find the source code of several test cases that show
the usage of most of the OpenFOAM® classes.
•  For your convenience, I already copied the directory

$WM_PROJECT_DIR/applications/test to the
directory $PTOFC/test
Some preliminaries,
•  OpenFOAM® represents scalars, vectors and matrices as tensor fields.

A zero rank tensor is a scalar, a first rank tensor is a vector and a second
rank tensor is a matrix.
•  The PDEs we want to solve involve derivatives of tensor fields with

respect to time and space.
•  The PDEs must be discretized in time and space before we solve them.
Basic tensor classes in OpenFOAM®
•  OpenFOAM® contains a C++ class library named primitive
($FOAM_SRC/OpenFOAM/primitives/). In this library, you will find the
classes for the tensor mathematics.
•  In the following table, we show the basic tensor classes available in
OpenFOAM®, with their respective access functions.
Tensor Rank Common name Basic class Access function
0 Scalar scalar
1 Vector vector x(), y(), z()
2 Tensor tensor xx(), xy(), xz() …
In OpenFOAM®, the tensor

0 1
1 2 3
T=@ 4 5 6 A
7 8 9
can be declared in the following way
tensor T(1, 2, 3, 4, 5, 6, 7, 8, 9);
We can access the component T13 or Txz using the xz ( ) access function.
For instance, the following code line
Info << “Txz = “ << T.xz ( ) << endl;
Will generate the following output
Txz = 3
Notice that in OpenFOAM® we use the function Info instead of the function cout.
Algebraic tensor operations in OpenFOAM®
•  Tensor operations operate on the entire tensor entity instead of a series of
operations on its components.
•  The OpenFOAM® syntax closely mimics the syntax used in written
mathematics, using descriptive functions or symbolic operators.
•  Some of the algebraic tensor operations are listed in the following table.
Mathematical OpenFOAM®
Operation Remarks
description description
Addition a+b a + b
Scalar
sa s * a
multiplication
Outer product rank a, b >=1 ab a * b
Inner product rank a, b >=1 a.b a & b
Double inner
rank a, b >=2 a:b a && b
product
The list is not complete
Examples of the use of some tensor classes
•  In the directory $WM_PROJECT_DIR/applications/test you will find

many examples showing you the use of the classes in OpenFOAM®.
•  For your convenience, I already copied the directory $WM_PROJECT_DIR/

applications/test to the directory $PTOFC/test
Examples of the use of some tensor classes
•  Let us now compile a tensor class example. From the terminal:
•  cd $PTOFC/test/tensor
•  wmake
(This will compile the source code and put the binary in the directory $FOAM_USER_APPBIN)
•  Test-tensor
At this point look at the output and study the file Test-tensor.C, and try to
understand what we have done.
After all, is not that difficult, right?
Dimensional units in OpenFOAM®
•  As you might already notice, OpenFOAM® is fully dimensional.
•  Dimensional checking is implemented as a safeguard against implementing

a meaningless operation.
•  OpenFOAM® encourages the user to attach dimensional units to any tensor

and it will perform dimension checking of any tensor operation.
•  You can check $FOAM_SRC/OpenFOAM/dimensionedTypes/ for the

dimensional classes.
Dimensional units in OpenFOAM®
•  Units are defined using the dimensionSet class tensor, with its units
defined using the dimensioned<Type> template class, the <Type>
being scalar, vector, tensor, etc. The dimensioned<Type> stores the
variable name, the dimensions and the tensor values.
•  For example, a tensor with dimensions is declare in the following way:
dimensionedTensor sigma
(
0 6
1
10 0 0
“sigma”,
dimensionSet(1, -1, -2, 0, 0, 0, 0), ⌘ =@ 0 106 0 A
tensor(10e6,0,0,0,10e6,0,0,0,10e6) 0 0 106
);
Units correspondence in dimensionSet
No. Property Unit Symbol
1 Mass kilogram kg
2 Length meters m
3 Time second s
4 Temperature Kelvin K
5 Quantity moles mol
6 Current ampere A
Luminuous
7 candela cd
intensity
dimensionSet (kg, m, s, K, mol, A, cd)

Units correspondence in dimensionSet
(
0 6
1
“sigma”,
10 0 0
dimensionSet(1, -1, -2, 0, 0, 0, 0), ⌘ =@ 0 106 0 A
tensor(1e6,0,0,0,1e6,0,0,0,1e6)
);
0 0 106
dimensionSet (kg, m, s, K, mol, A, cd)

Dimensional units examples
Add the following lines to Test-tensor.C (in the directory
$PTOFC/test/my_tensor you will find the modified files):
•  Before the main function main ( ):
#include “dimensionedTensor.H”
•  Before return(0):
(
"sigma",
dimensionSet(1, -1, -2, 0, 0, 0, 0),
tensor(1e6,0,0,0,1e6,0,0,0,1e6)
);
Info<< "Sigma: " << sigma << endl;
Compile, run, and look at the output.

By the end of this exercise, your output should looks like this:
Sigma sigma [1 -1 -2 0 0 0 0] (1e+06 0 0 0 1e+06 0 0 0 1e+06)
Notice that the object sigma, which belongs to the dimensionedTensor class,
contains the name, the dimensions and values.
Try to add the following member functions of the dimensionedTensor class in Test-
tensor.C (in the directory $PTOFC/test/my_tensor you will find the modified
files):
Info << “Sigma name: “ << sigma.name ( ) << endl;

Info << “Sigma dimensions: “ << sigma.dimensions ( ) << endl;
Info << “Sigma value: “ << sigma.value ( ) << endl;
Also, extract some of the values of the tensor by adding the following line:
Info<< "Sigma yy (22) value: " << sigma.value().yy() << endl;
Note that the value() member function first converts the expression to a tensor, which
has a yy() member function. The dimensionedTensor class does not have a yy()
member function, so it is not possible to directly get its value by using sigma.yy().
OpenFOAM® lists and fields
•  OpenFOAM® frequently needs to store sets of data and perform mathematical

operations.
•  OpenFOAM® therefore provides an array template class List<Type>, making it

possible to create a list of any object of class Type that inherits the functions of the
Type. For example a List of vector is List<vector>.
•  Lists of the tensor classes are defined in OpenFOAM® by the template class
Field<Type>. For better code legibility, all instances of Field<Type>, e.g.
Field<vector>, are renamed using typedef declarations as scalarField,
vectorField, tensorField, symmTensorField, tensorThirdField and
symmTensorThirdField.
OpenFOAM® lists and fields
•  You can check $FOAM_SRC/OpenFOAM/fields/Fields for the field classes.
•  Algebraic operations can be performed between Field subject to obvious restrictions

such as the fields having the same number of elements.
•  OpenFOAM® also supports operations between a field and a zero rank tensor, e.g.
all values of a Field U can be multiplied by the scalar 2 by simple coding the
following line, U = 2.0 * U.
Construction of a tensor field in OpenFOAM®
Add the following to Test-tensor.C (in the directory
$PTOFC/test/my_tensor you will find the modified files):
•  Before main():
#include "tensorField.H"
tensorField tf1(2, tensor::one);

Info<< "tf1: " << tf1 << endl;
tf1[0] = tensor(1, 2, 3, 4, 5, 6, 7, 8, 9);
Info<< "tf1: " << tf1 << endl;
Info<< "2.0*tf1: " << 2.0*tf1 << endl;
Compile, run, and look at the output.

Did something look familiar to you?
Absolutely yes, we already study these concepts in the

previous lecture. That is: typedef declarations,
classes and templates.
Remember, OpenFOAM® uses typedef declarations,

classes and templates a lot!
Let us take a look at the whole solution

process:
•  Creation of the tensors.

•  Mesh assembly.
•  Fields creation.
•  Equation discretization.
All by using OpenFOAM® classes and

template classes
Discretization of a tensor field in OpenFOAM®
•  The dicretization is done using the FVM (Finite Volume Method).
•  The cells are contiguous, i.e., they do not overlap and completely fill the domain.
•  Dependent variables and other properties are stored at the cell centroid.
•  No limitations on the number of faces bounding each cell.
•  No restriction on the alignment of each face.
•  The mesh class polyMesh is used to construct the polyhedral mesh using the
minimum information required.
•  You can check $FOAM_SRC/OpenFOAM/meshes/ for the polyMesh classes.
•  The fvMesh class extends the polyMesh class to include additional data needed for
the FVM discretization.
•  You can check $FOAM_SRC/src/finiteVolume/fvMesh for the fvMesh classes.
•  The template class geometricField relates a tensor field to a fvMesh. Using

typedef declarations geometricField is renamed to volField (cell center),
surfaceField (cell faces), and pointField (cell vertices).
•  You can check $FOAM_SRC/OpenFOAM/fields/GeometricFields for the

geometricField classes.
•  The template class geometricField stores internal fields, boundary fields, mesh
information, dimensions, old values and previous iteration values.
•  A geometricField inherits all the tensor algebra of its corresponding field, has
dimension checking, and can be subjected to specific discretization procedures.
Data stored in the fvMesh class
Access
Class Description Symbol
function
volScalarField Cell volumes V V()
surfaceVectorField Face area vector Sf Sf()
surfaceScalarField Face area magnitude |Sf | magSf()
volVectorField Cell centres C C()
surfaceVectorField Face centres Cf Cf()
surfaceScalarField Face fluxes g Phi()
Examine a fvMesh
•  Let us study a fvMesh example. First let us compile the Test-mesh application.
From the terminal
•  cd $PTOFC/test/mesh
•  wmake
•  In $PTOFC/test/my_mesh/cavity, you will find a modified copy of the cavity

tutorial. From the terminal:
•  cd $PTOFC/test/my_mesh/cavity
•  blockMesh
•  Now run Test-mesh in the $PTOFC/test/my_mesh/cavity directory. Look at

the output.
Examine a fvMesh
•  Let us take a look at the file Test-mesh.C
•  C() gives the center of all cells and boundary faces.

•  V() gives the volume of all the cells.
•  Cf() gives the center of all the faces.
Examine a fvMesh
Now, try to add in Test-mesh.C the following lines (in the directory
$PTOFC/test/my_mesh you will find the modified files):
•  before return(0):
Info<< mesh.C().internalField()[1][1] << endl;

Info<< mesh.boundaryMesh()[0].name() << endl;
•  Compile, run, and look at the output.
Examine a volScalarField
Let us now read a volScalarField that corresponds to the mesh in
$PTOFC/test/my_mesh/cavity. Add the following to Test-mesh.C
volScalarField p
(
IOobject
(
"p",
runTime.timeName(),
mesh,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
);
Info<< p << endl;
Info<< p.boundaryField()[0] << endl;
•  Compile, run, and look at the output.

Equation discretization in OpenFOAM®
•  In this phase, OpenFOAM® converts the PDEs into a set of linear algebraic
equations, A x = b, where x and b are volFields (geometricField). A is a
fvMatrix, which is created by a discretization of a geometricField and inherits
the algebra of its corresponding field, and it supports many of the standard algebraic
matrix operations.
•  The fvm (finiteVolumeMethod) and fvc (finiteVolumeCalculus) classes

contain static functions for the differential operators, and discretize any
geometricField.
•  fvm returns a fvMatrix, and fvc returns a geometricField.
•  In the directories $FOAM_SRC/finiteVolume/finiteVolume/fvc and

$FOAM_SRC/finiteVolume/finiteVolume/fvm you will find the respective
classes.
Discretization of the basic PDE terms in OpenFOAM®
The list is not complete
Mathematical fvm::
Term description
expression fvc::
laplacian(phi)
Laplacian r2 , · laplacian(Gamma, phi)
⇥ , ⇤ ⇥ ddt(phi)
Time derivative
ddt(rho,phi)
⇥t ⇤t
div(psi,scheme)
Convection ·( ), ·( ) div(psi,phi)
Sp(rho,phi)
Source ⇢ SuSp(rho,phi)
vol<type>Field ⇢ scalar, volScalarField surfaceScalarField

•  Ok, let us apply what we have learnt so far.

•  We will now write a solver to solve the convection-
diffusion equation.
•  For this we will use the convection-diffusion tutorial
$PTOFC/test/my_convection_diffusion
•  In the directory $PTOFC/test/my_convection_diffusion
Solution of the convection-diffusion equation
Let us now solve the convection-diffusion equation
⇥T
+ ⇥ · ( T) ⇥ · ( ⇥T ) = 0
⇥t
Using OpenFOAM® equation mimicking pragma, we can write this equation as
solve
(
fvm::ddt(T)
+ fvm::div(phi,T)
- fvm::laplacian(DT,T)
);
•  In $PTOFC/test/my_convection_diffusion, you will find the source code for
the solver of the convection-diffusion equation. In the terminal:
•  cd $PTOFC/test/my_convection_diffusion
•  wmake
•  Now go to the $PTOFC/test/my_convection_diffusion/case directory and

run the new solver. In the terminal:
•  cd $PTOFC/test/my_convection_diffusion/case
•  blockMesh
•  my_test_convection_difusion
•  paraFoam
Mesh (20 cells)
Solution plot with different mesh resolution
Now you know how to program in

OpenFOAM® using all C++ features.
Not that hard, right?
I just presented the basic building blocks to program in
OpenFOAM®.
For more information you should refer to the

programmer’s guide, doxygen documentation
and the OpenFOAM® coding guide in the
openfoamwiki site.
http://openfoamwiki.net/index.php/OpenFOAM_guide
As usual,
remember that you have
the source code.
In the directories $PTOFC/c++_tuts, $PTOFC/test and $PTOFC/programming
you will find many tutorials, try to go through each one to understand the basic concepts
of C++ and how to program in OpenFOAM®.
Module 7
Today’s lecture
1.  How to implement a new boundary condition

in OpenFOAM®
2.  How to implement my own application in
OpenFOAM®
3.  How to add temperature to icoFoam
Today’s lecture

in OpenFOAM®
OpenFOAM®
How to implement a new boundary condition in OpenFOAM®
Remember, all components in OpenFOAM® are implemented in library

form for easy re-use. So, in order to implement a new boundary
condition, we should follow these basic steps:
•  The implementations of the boundary conditions are located in the

directory $FOAM_SRC/finiteVolume/fields/fvPatchFields/
•  To add a new boundary condition, start by finding one that does

almost what you want to do. Then, copy that boundary condition
implementation to $WM_PROJECT_USER_DIR and modify it according
to your needs.

form for easy re-use. So, in order to implement a new boundary
condition, we should follow these basic steps:
•  Rename all the copied .C and .H files, for instance you can change
their names to myFvPatchField.*. In the new files, search for all
text occurrences with originalFvPatchField (the original name of
the .C and .H files) and replace them with myFvPatchField.
•  Modify the boundary condition to suit your needs. After you finish
modifying it, compile it and use it as a dynamic library.
Parabolic inlet boundary condition

We will add a new parabolic inlet profile boundary condition.
•  In the directory $PTOFC/programming/src/finiteVolume/

fields/fvPatchFields/derived/parabolicVelocity you will
find the new boundary condition. Notice that we kept the same directory
structure as in $FOAM_SRC.
From the terminal type:
•  cd $PTOFC/programming/src/finiteVolume/fields/
fvPatchFields/derived/parabolicVelocity
•  wmake libso
Starting from OpenFOAM® version 2.2.1, the argument libso is not

required anymore.
If you did not get any error, the new boundary condition is ready to use. wmake
will compile the new boundary condition and will place the new library in the
directory $WM_PROJECT_USER_DIR /platforms/linux64GccDPOpt/lib
(environment variable $FOAM_USER_LIBBIN).
Remember to modify the files located in the Make directory, so they

reflect the location of the new library and its name.
By the way, take a look at the files.

Let us now setup a new case using the new boundary condition. From the
terminal:
•  cd $PTOFC/mycases1/elbow2d_1/elbow_parabolic_inlet_0
Before running the solver we need to:

•  Add the new boundary condition parabolicVelocity in 0/U.
velocity-inlet-5
{
type parabolicVelocity;
maxValue 2.0;
n (1 0 0);
y (0 1 0);
value (0 0 0); //dummy value
}

Let us now setup a new case using the new boundary condition.
•  Then add the line:
libs (“parabolicvelocityBC.so”)
to the case controlDict dictionary in the system directory.
Remember to always add the newly created boundary condition to your control
dictionary controlDict. If you do not do this OpenFOAM® will complain.
Now we are ready to run the case. From the terminal type:
•  cd $PTOFC/mycases1/elbow2d_1/elbow_parabolic_inlet_0
•  fluentMeshToFoam ../../../meshes/elbow2d_1/ascii.msh
•  checkMesh
•  icoFoam
•  paraFoam

Mesh

Parabolic inlet profile Uniform inlet profile

Inlet profiles
A closer look to the parabolic inlet boundary condition

•  The parabolicVelocityFvPatchVectorField boundary condition
consists of two files:
parabolicVelocityFvPatchVectorField.C
parabolicVelocityFvPatchVectorField.H
•  The .H file is the header file, and it is included in the header of the .C file.
•  We can see that in the .H file we create a sub class to the

fixedValueFvPatchVectorField:
class parabolicVelocityFvPatchVectorField: public fixedValueFvPatchVectorField
i.e. this is for Dirichlet boundary conditions for a vector field.

•  The class has private data and takes in the following data
//- Peak velocity magnitude

scalar maxValue_;
//- Flow direction
vector n_;
//- Direction of the y-coordinate
vector y_;
•  The TypeName("parabolicVelocity"), used when specifying the

boundary condition, is defined.
•  There are some public constructors and member functions that are defined
in detail in the .C file.
•  We used the third constructor when we tested the boundary condition, i.e.
we read the member data from a dictionary.

•  The actual implementation of the boundary condition can be found in the
updateCoeffs() member function:
boundBox bb(patch().patch().localPoints(), true);

vector ctr = 0.5*(bb.max() + bb.min());
const vectorField& c = patch().Cf();
scalarField coord = 2*((c - ctr) & y_)/((bb.max() - bb.min()) & y_);
vectorField::operator=(n_*maxValue_*(1.0 - sqr(coord)));
•  The member function write defines how to write out the boundary values in
the time directory. The final line, writeEntry("value", os); writes out
all the values, which is only needed for post-processing.

Find out more about all the variables by including the following lines at the end
of the updateCoeffs member function:
Info << “c” << c << endl;

Info << “ctr” << ctr << endl;
Info << “y_” << y_ << endl;
Info << “bb.max()” << bb.max() << endl;
Info << “bb.min()” << bb.min() << endl;
Info << “(c - ctr)” << c - ctr << endl;
Info << “((c - ctr) & y_)” << ((c - ctr) & y_) << endl;
Info << “((bb.max() - bb.min()) & y_)” << ((bb.max() - bb.min()) & y_) << end;
Info << “coord” << coord << endl;
Wait, what if I do not want to program my boundary

condition?
•  You can save the pain of programming the boundary conditions in
OpenFOAM® if you use swak4foam.
•  swak4foam offers the possibility of implementing new boundary conditions

without the need of programming.
•  If you go to the directory $PTOFC/mycases1/elbow2d_1/

elbow_parabolic_inlet_1, you will find a case where we use
swak4foam to implement a parabolic profile inlet.
•  Do not worry, I will show how to use swak4foam and how to run this case.
Wait, what if I do not want to program my boundary

condition?
•  I highly advise you to spend some time and try to learn how to use
swak4foam as it will save you a lot of time.
•  I have been able to program really complex boundary conditions using

swak4foam. It works most of the times.
•  For more information about swak4foam you can visit the following site
http://openfoamwiki.net/index.php/Contrib/swak4Foam.
•  Let us go to the directory $PTOFC/mycases1/elbow2d_1/

elbow_parabolic_inlet_1, from now on follow me.
Paraboloid inlet boundary condition

Starting from the parabolic inlet profile boundary condition, let us now create a
new boundary condition to model a paraboloid inlet profile.
•  In the directory $PTOFC/programming/src/finiteVolume/fields/

fvPatchFields/derived/p3d you will find the new boundary condition.
Notice that we kept the same directory structure as in $FOAM_SRC.
•  Notice that we also kept the same naming convention for the files and
classes as for the parabolic inlet profile boundary condition, that is, we simply
cloned the directory. This is to show you how the code can be reused.
•  Starting from this point, we can modify the files to fit our needs.

•  As we simply cloned the directory parabolicVelocity, the name of the

paraboloid inlet boundary condition is the same as the one used in the
parabolicVelocity boundary condition and the implementation consists
of two files:
parabolicVelocityFvPatchVectorField.C
parabolicVelocityFvPatchVectorField.H
•  By the way, take a look at the files and identify all the modifications.

•  While this approach will work, I highly recommend you to change the names
of the files and classes. For instance, if you use the library
parabolicvelocityBC.so and p3d.so in the same case, you will have
a conflict between the libraries as both of them use the same symbols.
•  In the directory $PTOFC/programming/src/finiteVolume/fields/

fvPatchFields/derived/paraboloid you will find the paraboloid
inlet boundary condition. For your convenience, in this implementation I
already replaced all instances of parabolicVelocity by paraboloid
(names of files, classes and functions).

•  By the way, take a look at the files in the directory $PTOFC/programming/

src/finiteVolume/fields/fvPatchFields/derived/paraboloid
and identify all the modifications (in naming convention and implementation).
To compile:
fvPatchFields/derived/paraboloid
•  wmake libso

required anymore


terminal:
•  cd $PTOFC/mycases1/elbow3d/elbow_paraboloid
•  Add the new boundary condition parabolicVelocity in 0/U.
inlet1
{
type paraboloid;
maxValue 0.4;
n (1 0 0);
y (0 1 0);
y1 (0 0 1);
radius 1.0;
value uniform (0 0 0); //dummy value
}

libs (“paraboloid.so”)
•  cd $PTOFC/mycases1/elbow3d/elbow_paraboloid
•  blockMesh
•  checkMesh
•  icoFoam
•  paraFoam
Note: you will need to modify the boundary file in the directory constant/polyMesh. If you do not know how
to modify the file boundary, take a look at the README.FIRST file for instructions.

Geometry

Mesh

Paraboloid profile

Velocity magnitude contours in a cut plane

Atmospheric boundary layer
Starting from the parabolic inlet profile boundary condition, let us now created a new
boundary condition to model the atmospheric boundary layer.
In the directory $PTOFC/programming/src/finiteVolume/fields/

fvPatchFields/derived/ablVelocity you will find the new boundary condition.
Take a look at the new boundary condition and identify the changes we have done.
Also, try to figure out what kind of law we used to model the atmospheric boundary layer
inlet profile. In the terminal type:
fvPatchFields/derived/ablVelocity
•  wmake libso

required anymore


terminal:
•  cd $PTOFC/mycases4/building/c0

•  Add the new boundary condition ablVelocity in 0/U.
inflow
{
type ablVelocity;
n (1 0 0);
y (0 1 0);
maxValue 12.3;
value (0 0 0); //dummy value
}

libs (“ablvelocityBC”)
•  fluent3DMeshToFoam ../../../meshes/building/
ascii1.msh
•  checkMesh
•  simpleFoam
•  paraFoam
By the way, this case is expensiveModule'7')'Lecture'22'

so you better run in parallel. 39'
To run this case, you can use as initial conditions the solution obtained using
potentialFoam. From the terminal type:
•  cd $PTOFC/mycases4/building/potential
•  rm ./0/*
•  cp 0org/U 0/U
•  cp 0org/p 0/p
ascii1.msh
•  checkMesh
•  potentialFoam –writep -noFunctionObjects
To run this case, you can use as initial conditions the solution obtained using
potentialFoam. From the terminal type:
•  rm ./0/*
•  cp ./0rg/* ./0
•  cp ../potential/0/U 0/
•  cp ../potential/0/p 0/
ascii1.msh
•  checkMesh
•  simpleFoam

Mesh

Pressure and velocity contours






Inlet profile
Today’s lecture

in OpenFOAM®
OpenFOAM®
How to implement my own application in OpenFOAM®

form for easy re-use. So, in order to implement a new application, we
should follow these basic steps:
•  The applications implementations are located in $WM_PROJECT_DIR/

applications
•  To add a new application, start by finding one that does almost what
you want to do. Then, copy that application implementation to
$WM_PROJECT_USER_DIR and modify it according to your needs.
•  You can also write a solver from scratch. Remember to keep the
prototype body of a solver or utility.
•  After you finish modifying or writing your own application, compile it

and use it as you normally do.
Laplace equation solver
Let us write a solver for the Laplace equation:
•  In the directory $PTOFC/programming/applications/solvers/

my_laplace_st/ you will find the new application.
From the terminal type:
•  cd $PTOFC/programming/applications/solvers/
my_laplace_st/
•  wmake
directory $WM_PROJECT_USER_DIR /platforms/linux64GccDPOpt/bin
(environment variable $FOAM_USER_APPBIN).

So, what changes did we introduce in my_laplace_st directory:
•  We created volumeScalarField T in createFields.H

•  We created the dimensionedScalar DT in createFields.H
•  We created the dimensionedScalar sourceterm in
createFields.H
•  We added the Laplace equation in my_lapace_st.C
solve
(
fvm::ddt(T) - fvm::laplacian(DT, T) - sourceterm
);
@T S
r · ( rT )
@t
So, what changes did we introduce in my_laplace_st directory:
•  Additionally we added in my_laplace_St.C the line:
#include "write.H”
This line of code will look for the header file write.H and will write out
volScalarField gradTx, volScalarField gradTx and
volScalarField gradTx (the T gradient)
Let us now setup a new case using my_laplace_st. From the terminal:
•  cd $PTOFC/mycases0/laplace_1/c1
•  Add the new field variable file T to 0 directory.

•  In fvSchemes, add the following lines:
•  grad(T) Gauss linear;
•  laplacian(DT,T) Gauss linear corrected;
•  In fvSolution, add the solutions settings for T.
•  In transportProperties, add the diffusion coefficient DT and the
source term sourceterm.Module'7')'Lecture'22' 54'
Remember to always add the new entries to the case dictionaries in the
directory system. Also, you will need to initialize all the fields you use in your
solver. If you do not do this OpenFOAM® will complain.
Let us now setup a new case using my_laplace_st. From the terminal:
•  blockMesh
•  my_laplace_st
•  paraFoam
•  gnuplot gnuplot_script
•  evince T_sampling.ps

Mesh (5 cells)

Comparison analytical solution versus numerical solution
Today’s lecture

in OpenFOAM®
OpenFOAM®
How to add temperature to icoFoam
•  Hereafter we will modify an existing solver (icoFoam).
•  The modification will consist in adding temperature to the solver.
•  We will need to copy the original solver into the directory

$WM_PROJECT_USER_DIR. Remember to use the exact directory structure.
•  After creating the new application’s directory, various small changes are
necessary to introduce in the solver files.
•  Finally, the new field (temperature), needs to be added to the initial and
boundary conditions. Also, we need to tell to OpenFOAM® how to discretize
the new terms, this is done in the fvSchemes dictionary. In the
fvSolution dictionary, we need to set the solver that we want to use to
solve the field temperature.
•  In the folder $PTOFC/programming/applications/solvers/
icoFoam/, you will find a copy of the original icoFoam solver. Let us copy
the content of this folder to the folder my_icoFoam. From the terminal:
•  cp -r $PTOFC/programming/applications/solvers/
icoFoam/ $PTOFC/programming/applications/solvers/
my_icoFoam/
•  Now rename the file icoFoam.C to my_icoFoam.C.

•  mv icoFoam.C my_icoFoam.C
Remember, it is highly advisable that the directory and the file

have the same name.
•  Now go to the Make sub-directory, and open the file files with your favorite
editor and add the following changes:
my_icoFoam.C
EXE = $(FOAM_USER_APPBIN)/my_icoFoam
•  No changes are necessary for the file options.
•  Now go back to the my_icoFoam directory and compile the application. In

the terminal,
•  cd ..
•  Before compiling the new application, make sure that you do not have old
binaries, old object files or old dependencies files in your application
directory. In the terminal:
•  wclean
This will clean the directory.
•  Now we are ready to compile the new application. In the terminal:

•  wmake
•  If everything went fine, your new solver binary should be in the

$FOAM_USER_APPBIN directory. Check this with:
•  ls $FOAM_USER_APPBIN
You should see the new solver my_icoFoam in this directory.

•  So far we only compiled the application with a new name.

•  Let us now add the necessary changes in order to solve the temperature
field.
•  First, we need to create the new temperature field. Open the
createFields.H file using your favorite editor.
•  The first thing we can notice in createFields.H is that OpenFOAM® loads
the kinematic viscosity from the transportProperties dictionary file. Let
us add a new transport property related to the thermal diffusion which we will
denote as DT. Make the following changes:
dimensionedScalar nu
(
//Look for these lines
transportProperties.lookup("nu"));
//Starting from here add this line

dimensionedScalar DT
(
transportProperties.lookup("DT")
);
//Done adding new lines
•  If you keep reading the file, you will see that the scalar field p
(volScalarField) and the velocity field U (volVectorField) are
created. We need to add the new field for temperature T
(volScalarField).
•  After the creation of the field U and before the line #include
“createPhi.H”, add the following lines:
Info<< "Reading field T\n" <<endl;
volScalarField T
(
IOobject
(
"T",
runTime.timeName(),
mesh,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
•  Save the modifications in createFields.H. At this point we have created
the new field T and the new transport property DT.
•  Let us now add the new equation to solve. Recalling that we want to add the
transport equation for the scalar T (temperature) to the current solver
⇤T
+ ⇥ · (⇥T ) ⇥ · ( ⇥T ) = 0
⇤t
Using OpenFOAM® equation mimicking syntax, we can write this equation
as
fvScalarMatrix TEqn
(
fvm::ddt(T)
+ fvm::div(phi,T)
- fvm::laplacian(nu,T)
);
TEqn.solve( );
•  Now, we need to add the new equation to the file my_icoFoam.C. Using
your favorite editor add the following modifications.
•  Because the temperature transport depends on the velocity field, we will add
the equation after the momentum equation is solved (after the PISO loop),
but before the time step is written. Edit your file so it looks like this:
U -= rAU*fvc::grad(p);
U.correctBoundaryConditions( );
}
//Starting from here add these lines
fvScalarMatrix TEqn
(
fvm::ddt(T)
+ fvm::div(phi,T)
- fvm::laplacian(nu,T)
);
TEqn.solve( );
//End adding lines
runTime.write();
•  Save the modifications and compile the new solver. From the terminal
•  wclean
•  wmake
•  If everything went fine, your new solver binary should be in the

$FOAM_USER_APPBIN directory. Check this with:
•  ls $FOAM_USER_APPBIN
You should see the new solver my_icoFoam in this directory.
•  The next step is to test the new solver.
•  Go to the directory $PTOFC/mycases1/elbow2d_1/

elbow_plus_temperature. In the terminal:
•  cd $PTOFC/mycases1/elbow2d_1/elbow_plus_temperature
•  In this directory you will find the case setup files for a case using
my_icoFoam solver.
•  Notice that we need to create the field file for T in the 0 directory (initial and
boundary conditions).
•  We also need to add the new transport property to the

transportProperty dictionary in the constant directory.
•  We need to tell to OpenFOAM® how to discretize the new equations. This

is done in the fvSchemes dictionary in the system directory.
•  Finally, you will need to tell to OpenFOAM® how to solve the field T. This is
done in the fvSolution dictionary in the system directory.
•  Take a look at these files (T, transportProperties, fvSchemes and

fvSolution) and identify all the additions and changes made.
•  Always remember, OpenFOAM® is fully dimensional so your

dimensions must be consistent.
•  We will now use the new solver. From now on follow me.
•  cd $PTOFC/mycases1/elbow2d_1/
elbow_plus_temperature
(This is one line)
•  fluentMeshToFoam ../../../meshes/elbow2d_1/
ascii.msh
(This is one line)
•  checkMesh
•  my_icoFoam
•  paraFoam
Mesh
Contours of velocity magnitude and temperature

Contours of pressure
•  In the directory $PTOFC/mycases1/elbow2d_1/, you will find various

setup for the same geometry. For instance you could use the solver
my_icoFoam with the parabolic inlet boundary condition we previously
created (elbow_parabolic_inlet_plus_temperature).
•  Try to run all cases and identify the changes in the dictionaries.
Remember, all components in OpenFOAM® are implemented in library form for
easy re-use. So, in order to implement a new application, we should follow
these basic steps:
•  The applications implementations are located in $WM_PROJECT_DIR/

applications
•  To create a new application, start by finding one that does almost what you
want to do. Then, copy that application implementation to your user directory
$WM_PROJECT_USER_DIR and modify it according to your needs.
•  You can also write a solver from scratch. Remember to keep the prototype
body of a solver.
•  After you finish modifying or writing your application, compile it and use it as
you normally do.
At this point you should be able

to modify OpenFOAM® solvers
and utilities, and create your own
applications and boundary
conditions.
Mesh generation using open source tools
In the folders $PTOFC/programming/applications and
$PTOFC/programming/src you will find many tutorials, try to go through each one to
understand how to program in OpenFOAM®.
Module 8
Today’s lecture
1.  A crash introduction to turbulence modeling

in OpenFOAM®
Today’s lecture
1.  A crash introduction to turbulence modeling

in OpenFOAM®
A crash introduction to turbulence modeling in OpenFOAM®
•  The majority of natural and engineering

flows are turbulent, hence the
necessity of modeling turbulence.
Before continuing, I want to share a

few amazing images that show the
beauty and complexity of turbulence
in nature and engineering
Buoyant plume of smoke rising from a stick of incense

Photo credit: https://www.flickr.com/photos/jlhopgood/ Module'8')'Lecture'23' 6'
This work is licensed under a Creative Commons License (CC BY-NC-ND 2.0)
Buoyant plume of smoke rising from a stick of incense

Photo credit: M. Rosic Module'8')'Lecture'23' 7'
Copyright on the images is held by the contributors. Apart from Fair Use, permission must be sought for any other purpose.
Tugboat riding on the turbulent wake of a ship

Photo credit: https://www.flickr.com/photos/oneeighteen/ Module'8')'Lecture'23' 8'
This work is licensed under a Creative Commons License (CC BY-NC 2.0)
Turbulent waters
Photo credit: https://www.flickr.com/photos/thepaegan Module'8')'Lecture'23' 9'
This work is licensed under a Creative Commons License (CC BY-NC-ND 2.0)
Spring votex in turbulent waters

Photo credit: https://www.flickr.com/photos/kenii/ Module'8')'Lecture'23' 10'
Wake turbulence behind individual wind turbines

Photo credit: NREL's wind energy research group. Module'8')'Lecture'23' 11'
Von Karman vortices created when prevailing winds sweeping east across the northern Pacific Ocean
ecountered Alaska's Aleutian Islands
Photo credit: USGS EROS Data Center Satellite Systems Branch.
Von Karman Vortex Streets in the northern Pacific Photographed from the International Space Station''
Photo credit: NASA Module'8')'Lecture'23' 13'
Trailing vortices
Photo credit: Steve Morris. AirTeamImages. Module'8')'Lecture'23' 14'
Vortices on a 1/48-scale model of an F/A-18 aircraft inside a Water Tunnel

Photo credit: NASA Dryden Flow Visualization Facility. http://www.nasa.gov/centers/armstrong/multimedia/imagegallery/FVF
Wind Tunnel Test of New Tennis Ball

Photo credit: NASA http://tennisclub.gsfc.nasa.gov/tennis.windtunnelballs.html
Bullet at Mach 1.5

Photo credit: Andrew Davidhazy. Rochester Institute of Technology.
Flow visualization over a spinning spheroid

Photo credit: Y. Kohama. Module'8')'Lecture'23' 18'
Flow around an airfoil with a leading-edge slat

Photo credit: S. Makiya et al. Module'8')'Lecture'23' 19'
•  Modeling turbulence is not an easy task.
•  There is no universal turbulence model, hence you need to

know the capabilities and limitations of the turbulence models.
•  Turbulence can be wall bounded or free shear. Depending of

what you want to simulate, you will need to choose an
appropriate turbulence model and simulation techniques.
•  Simulating turbulent flows in OpenFOAM® (or any general CFD

solver) requires selecting a turbulence model, providing initial
conditions and boundary conditions for the closure equations of
the turbulent model, and selecting a near-wall modeling.
•  You also need to choose the discretization scheme of the

turbulent equations. Module'8')'Lecture'23' 20'
“Essentially, all models are wrong,

but some are useful”
G.E.P Box
•  Equations cannot be derived from fundamental principles.

•  All turbulence models contain some sort of empiricism.
•  Some calibration to observed physical solutions is contained in
the' turbulence models.
'
•  Also, some intelligent guessing is used.
•  A lot of uncertainty is involved
! 21'
Turbulence near the wall - Law of the wall

1
u+ = ln y + + C +

20
18
16
14
12
+
U 10
8 u+ = y +
6
4
0
-1 0 1 2 3
10 10 10 10 10
+
Y
Viscous sublayer Buffer Log-law layer

Layer
Inner region Outer region 22'
Energy spectrum for a turbulent flow – log-log scales
Modeled in RANS
E()
Computed in DNS
Computed in LES Modeled in LES
GS scales SGS scales
E() ⇠ ✏2/3  5/3
1 1

l ⌘
Inner region
Energy Inertial Viscous
Viscous sublayer
Containing Sub-range range
Buffer Eddies Module'8')'Lecture'23' 23'
Log-law layer
Layer
Turbulence near the wall
Outer region
Boundary layer
Log-law layer
30 < y+ < 300
Buffer layer
10 < y+ < 30
Viscous sublayer
y+ < 10
Wall
Outer region
Boundary layer
Log-law layer
30 < y+ < 300
Buffer layer
10 < y+ < 30
Viscous sublayer
Wall Function
y+ < 10
Wall
Outer region
Boundary layer
Log-law layer
30 < y+ < 300
Buffer layer
10 < y+ < 30
Viscous sublayer
Scalable Wall Function
y+ < 10
Wall
Overview of turbulence modeling approaches
RANS
Increasing computational costs

URANS
Increasing complexity
SAS
DES
LES
DNS
Overview of turbulence modeling approaches
RANS LES
RANS/URANS DES/LES DNS

•  Solves the time-averaged NSE. •  Solves the filtered unsteady NSE. •  Solves the unsteady laminar NSE.
•  All turbulent spatial scales are •  SGS scales are modeled, GS are •  Solves all spatial and temporal
modeled. resolved. scales; hence, requires extremely
fine meshes and small time-steps.
•  Many models are available. One •  Resolves the temporal scales, hence
equation models, two equation requires small time-steps. •  No modeling is required.
models, Reynolds stress models,
•  For most industrial applications, it is •  It is extremely computational
transition models, and so on.
computational expensive. However, expensive.
•  This is the most widely approach for thanks to the current advances in
•  Not practical for industrial flows.
industrial flows. parallel and scientific computing it is
becoming affordable. •  It is intrinsically 3D and asymmetric.
•  Unsteady RANS (URANS), use the
same equations as the RANS but •  Many models are available.
with the transient term retained.
•  It is intrinsically 3D and asymmetric.
•  It can be used in 2D and 3D cases.
RANS/URANS Turbulence models available in OpenFOAM®

•  LRR
•  LamBremhorstKE
•  LaunderGibsonRSTM
•  LaunderSharmaKE
•  LienCubicKE
•  LienCubicKELowRe
•  LienLeschzinerLowRe
•  NonlinearKEShih
•  RNGkEpsilon
•  SpalartAllmaras
•  kEpsilon
•  kOmega
•  kOmegaSST
•  kkLOmega
•  laminar
•  qZeta
•  realizableKE
•  v2f
DES/LES Turbulence models available in OpenFOAM®
•  DeardorffDiffStress
•  LRRDiffStress
•  Smagorinsky
•  SpalartAllmaras
•  SpalartAllmarasDDES
•  SpalartAllmarasIDDES
•  dynLagrangian
•  dynOneEqEddy
•  homogeneousDynOneEqEddy
•  homogeneousDynSmagorinsky
•  kOmegaSSTSAS
•  laminar
•  mixedSmagorinsky
•  oneEqEddy
•  spectEddyVisc
Short description of some of the turbulence models available in

OpenFOAM®
Model Short description
Suitable for external aerodynamics, tubomachinery and high speed flows. Good for mildly
Spalart-Allmaras complex external/internal flows and boundary layer flows under pressure gradient. Performs
poorly for free shear flows and flows with strong separation.
Robust. Widely used despite the known limitations of the model. Performs poorly for complex
Standard k–epsilon flows involving severe pressure gradient, separation, strong streamline curvature. Suitable for
initial iterations, initial screening of alternative designs, and parametric studies.
Suitable for complex shear flows involving rapid strain, moderate swirl, vortices, and locally
transitional flows (e.g. boundary layer separation, massive separation, and vortex shedding
Realizable k–epsilon behind bluff bodies, stall in wide-angle diffusers, room ventilation). It overcome the limitations of
the standard k-epsilon model.
Superior performance for wall-bounded boundary layer, free shear, and low Reynolds number
Standard k–omega flows compared to models from the k-epsilon family. Suitable for complex boundary layer flows
under adverse pressure gradient and separation (external aerodynamics and turbomachinery).
Offers similar benefits as standard k–omega. Not overly sensitive to inlet boundary conditions
SST k–omega like the standard k–omega. Provides more accurate prediction of flow separation than other
RANS models.
Turbulence models available in OpenFOAM®
•  As you can see, there is a cornucopia, plethora, fullness, abundance of turbulence

models implemented in OpenFOAM®, from RANS to LES.
•  You can also implement yours!
•  You can find the turbulence models in the following directories:
•  $FOAM_SRC/turbulenceModels
•  $FOAM_SRC/TurbulenceModels
•  The wall functions are in the following directories:
•  $FOAM_SRC/turbulenceModels/compressible/RAS/derivedFvPatchFields/
wallFunctions
•  $FOAM_SRC/turbulenceModels/compressible/RAS/backwardsCompatibility/
wallFunctions
•  $FOAM_SRC/turbulenceModels/incompressible/RAS/derivedFvPatchFields/
wallFunctions
•  $FOAM_SRC/turbulenceModels/incompressible/RAS/backwardsCompatibility/
wallFunctions Module'8')'Lecture'23' 32'
•  If you have absolutely no idea of what model to use, I highly recommend you
the  ! family models or the realizable  ✏
•  Remember, when a turbulent flow enters a domain, turbulent boundary conditions
and initial conditions must be specified.
•  Also, if you are dealing with wall bounded turbulence you will need to choose the
near-wall treatment. You can choose to solve the viscous sub-layer or use wall
functions.
•  You will need to give the appropriate boundary conditions to the near-wall treatment.
•  The initial conditions and boundary conditions change from model to model and
depends on the physics involve, so get familiar with the theory.
•  Remember, there is no universal turbulence model.
•  To set the initial conditions and boundary conditions, my best advise is to find and
read the original reference used to implement the turbulence model.
•  For instance, if you are interested in the incompressible version of the  !
turbulence model, you can go to the directory:
$FOAM_SRC/turbulenceModels/incompressible/RAS/kOmegaSST
and take a look at the source code.
•  If you open the file $FOAM_SRC/turbulenceModels/incompressible/RAS/

kOmegaSST/kOmegaSST.H, in the header you fill find the references used to
implement the model in OpenFOAM®, namely:
Menter, F., Esch, T., “Elements of Industrial Heat Transfer Prediction”,

16th Brazilian Congress of Mechanical Engineering (COBEM), Nov. 2001.
Hellsten, A. “Some Improvements in Menter’s k-omega-SST turbulence
model”, 29th AIAA Fluid Dynamics Conference, AIAA-98-2554, June 1998.
•  You have the source code, so take your time and try to read it.
Near-wall treatment and wall functions

Outer region Outer region
Boundary layer
Boundary layer
Log-law layer Log-law layer
30 < y+ < 300 30 < y+ < 300
Buffer layer Buffer layer

10 < y+ < 30 10 < y+ < 30
Viscous sublayer Viscous sublayer
Wall Function
y+ < 10 y+ < 10
Wall Wall
No wall-functions Wall-functions
•  Generally speaking, wall functions is the approach to use if you are more interested in
the mixing in the outer region, rather than the forces on the wall.
+ +
•  By the way, wall functions should never be used if y < 30 . What is y ?, we are
going to talk about this later on.
•  If accurate prediction of forces or heat transfer on the wall are key to your simulation
(aerodynamic drag, turbomachinery blade performance, heat transfer) you might not
want to use wall functions. Module'8')'Lecture'23' 37'
•  To deal with wall bounded turbulence, several wall functions are available in
OpenFOAM®, e.g., alphatJayatillekeWallFunction,
epsilonWallFunction, nutUSpaldingWallFunction,
omegaWallFunction, v2WallFunction.
•  If the first node normal to the wall is in the viscous sub-layer region, you do not use
wall functions. This approach is computationally expensive.
•  Instead, if the first node normal to the wall is in the log-law layer, you need to use wall
functions.
•  When positioning the first node normal to the wall, try to avoid as much as possible
the buffer layer, this is the transition region and things are not very clear there.
•  If you want to find where are the directories containing the wall functions, type in the
terminal:
•  find $FOAM_SRC/turbulenceModels –iname wallFunctions
•  I am going to be really loud on this. To enable wall functions, you need to define the
base type boundary condition of the patch as a wall.
•  The base type boundary conditions are defined in the file constant/polyMesh/
boundary.
•  The specific wall function or numerical type boundary condition to use, is defined in
the field dictionaries located in the directory 0, or the directory where you set the
initial and boundary conditions.
 ! Turbulence model overview
•  It is called  ! because it solves two additional equations for modeling the

turbulence, namely, the turbulent kinetic energy  and the specific kinetic
energy !.
@ ⇤ ⇤
⇢ + ⇢r · (ū) = ⌧ R :rū ⇢! + r · [(µ + µT ) r]
@t
@! ! R
⇢ + ⇢r · (ū!) = ↵ ⌧ :rū ⇢! 2 + r · [(µ + µT ) r!]
@t 
•  At the end of the day, we want to determine the turbulent eddy viscosity
⇢
µT =
!
•  The turbulent eddy viscosity is used to compute the Reynolds stress tensor,
2 h i 2
R R T
⌧ = ⇢ u0 u0 = 2µT D̄ ⇢I = µT ru + (ru) ⇢I,
3 3
•  The Reynolds stress tensor is derived from the Boussinesq Approximation.
Incompressible RANS equations
•  The following equations are the incompressible Reynolds-Averaged Navier-Stokes

equations (RANS). These are the equations we want to solve.
r · (ū) = 0,
@ ū rp̄ 1
+ r · (ūū) = + ⌫r2 ū r · ⌧ R.
@t ⇢ ⇢
where ⌧R is the Reynolds stress tensor and is given by,
2 h i 2
R R T
⌧ = ⇢ u0 u0 = 2µT D̄ ⇢I = µT ru + (ru) ⇢I,
3 3
•  To arrive to these equations, we used Reynolds averaging.

 ! Turbulence model free-stream boundary conditions
•  The initial value for the turbulent kinetic energy  can be found as follows
3
 = (U I)2
2
•  The initial value for the specific kinetic energy ! can be found as follows
⇢ µt 1
!=
µ µ
µt u0
•  Where is the viscosity ratio and I= is the turbulence intensity. '
µ ū
•  If you are totally lost, you can use these reference values. They work most of the
times, but it is a good idea to have some experimental data or initial estimate.
Low Medium High
I 1.0 % 5.0 % 10.0 %
µt /µ 1 10 100
•  By the way, use these guidelines for external aerodynamics only.

 ! Turbulence model wall functions
•  Follow these guidelines if you are struggling to find the boundary conditions for the
near-wall treatment.
•  I highly recommend you to read the source code and find the references used to
implement the model.
•  As for the free-stream boundary conditions, you need to give the boundary conditions
for the near-wall treatment.
•  When it comes to near-wall treatment, you have three options:
•  Use wall functions:
30  y +  300
•  Use scalable wall functions, this only applies with the  ! family models:
1  y +  300
•  Resolve the boundary layer (no wall functions):
y+  6 Module'8')'Lecture'23' 48'

+
•  If you are planning to use wall functions ( 30  y  300 ),
the following values are good choices.
•  For  you should use the wall function kqRWallFunction with the following value:
wall = 
•  For ! you should use the wall function omegaWallFunction with the following
value:
6⌫
!wall = 10 2
y
where = 0.075 and y is the distance to the first cell center normal to the
wall.

+
•  If you are planning to use scalable wall functions ( 1  y  300 ),
•  For  you should use the wall function kqRWallFunction with the following value:
wall = 0
•  For ! you should use the wall function omegaWallFunction with the following
value:
6⌫
!wall = 10 2
y
where = 0.075 and y is the distance to the first cell center normal to the
wall.

+
•  If you are planning not to use wall functions ( y  6 ),
•  For  you should use fixedValue with the following value:
wall = 1e 10
•  For ! you should use fixedValue with the following value:
!wall = 1e 10
•  To avoid potential erroneous arithmetic operations, I like to use a small value

instead of 0.
Setting nut boundary conditions for the

 ! Turbulence model
Setting nut boundary conditions for the  ! Turbulence model
•  Remember, all this fancy treatment for the closure equations is done to compute
nut.
•  Therefore we need to define boundary conditions for nut as well.
•  nut is the turbulent viscosity and is not a physical property.
•  We only define nut boundary conditions at the walls.
•  If you do not create the nut dictionary, OpenFOAM® will create it automatically
for you.
•  But be careful, what OpenFOAM® does might not be the best option.
•  The source code of the nut wall functions is located in the directory:
$FOAM_SRC/turbulenceModels/incompressible/RAS/
derivedFvPatchFields/wallFunctions/nutWallFunctions
Setting nut boundary conditions for the  ! Turbulence model
•  As we are using the  ! turbulence model and we are interested in using

continuous wall functions, we use the following wall function:
•  nutUSpaldingWallFunction
•  nutUSpaldingWallFunction is a generic wall function that uses U instead of k. It
can be used with all low-Re and high-Re turbulence models.
•  A low-Re turbulence model solves the boundary layer ( y +  6 ).
•  A high-Re turbulence model uses wall functions ( 30  y +  300 ).
•  Other nut wall function options are:
•  nutkRoughWallFunction (high-Re)
•  nutkWallFunction (high-Re)
•  nutLowReWallFunction (low-Re)
•  nutUWallFunction (high-Re)
y + wall distance units
+
•  To compute the wall distance units y ,
use the following equation Outer region
+ ⇢ ⇥ U⌧ ⇥ y
y =
Boundary layer
Log-law layer
30 < y+ < 300
µ
Buffer layer
10 < y+ < 30
•  Where y is the distance to the first cell

Viscous sublayer
y+ < 10
center normal to the wall, and U⌧ is Wall
the friction velocity and is equal to
r
⌧w
U⌧ =
⇢
where ⌧w is the wall shear stresses.
+
•  We never know a priori the y value.
•  What we usually do is to run the simulation for a few time-steps or iterations, and then
+
we get an estimate of the y value.
•  After determining where we are in the boundary layer (viscous sub-layer, buffer layer
or log-law layer), we take the mesh as a good one or we modify it if is deemed
necessary.
•  It is an iterative process and it can be very time consuming.
+
•  Have in mind that it is quite difficult to get uniform y values at the walls. This does
not mean that what you have done is wrong, use common sense.
•  To get an initial estimate of the distance from the wall to the first cell center y , you
can proceed as follows,
Estimating normal wall distance

•  To estimate the distance from the wall to the first cell center y you can proceed as
follows,
⇢⇥U ⇥L 0.2
1. Re = 2. Cf = 0.058 ⇥ Re
µ Skin friction coefficient of a flat plate
r
1 2 ⌧w
3. ⌧w = ⇥ Cf ⇥ ⇢ ⇥ U1 4. U⌧ =
2 ⇢
+ ⇢ ⇥ U⌧ ⇥ y µ ⇥ y+
5. y = y=
µ ⇢ ⇥ U⌧
Turbulence modeling guidelines and tips

•  Compute Reynolds number and determine whether the flow is turbulent.
•  Estimate y before generating the mesh.
•  Run the simulation for a few time steps and get a better prediction of y + and
correct your initial prediction of y .
•  The realizable  ✏ or SST  ! models are good choices for general

applications.
•  If you are interesting in modeling the smallest eddies, DES or LES is the right choice.
•  If you do not have any restriction in the near wall treatment method, use wall
functions.
•  Choose your near-wall modeling strategy ahead of time and check y + and y
values to make sure the near-wall mesh is suitable.

•  The utility refineWallLayer, can be used to refine the cells next to patches. This
can save you a lot time, as you do not have to go back to the meshing stage.
•  Be aware of the limitations of the turbulence model chosen, find and read the original
references used to implement the model in OpenFOAM®.
•  Use the utilities yPlusRAS or yPlusLES to check the y + value.

•  Use the default model constants unless you know what are you doing or you are
confident that you have better values.
•  Set reasonable boundary and initial conditions for the turbulence model variables.
A few applications
LES simulation
Iso-surfaces of Q criterion. Walls colored by instantaneous pressure.
LES simulation
Cut plane with instantaneous velocity magnitude. Walls colored by

instantaneous pressure.
LES simulation
Instantaneous velocity magnitude. Instantaneous vorticity magnitude.
LES simulation
Mesh and instantaneous velocity magnitude.
LES simulation
Energy spectrum and -5/3 slope.

LES simulation Vs. RANS simulation
LES RANS LES RANS
•  LES simulations are colored by instantaneous values.

•  RANS simulations are colored by mean values.
LES (instantaneous velocity) RANS
LES (instantaneous velocity)

Module'8')'Lecture'23' RANS 70'
LES (Mean velocity) Module'8')'Lecture'23' RANS 71'

DES simulation
Iso-surfaces of Q criterion.
SAS simulation
Iso-surfaces of vorticity magnitude.
URANS simulation
Iso surfaces of Q criteron.
Iso-surfaces of Q criterion.
References
•  Turbulent Flows
Stephen B. Pope
•  Turbulence: An Introduction for Scientists and Engineers

P. A. Davidson
•  Large Eddy Simulation for Incompressible Flows

Pierre Sagaut

David C. Wilcox
Module 8
Today’s lecture
1.  A crash introduction to multiphase flows

modeling in OpenFOAM®
Introduction to multiphase flows
What is multiphase flow?

•  A multiphase flow is a fluid flow consisting of more than one phase
component and have some level of phase separation above molecular level.
•  Multiphase flows exist in many different forms. Two phase flows can be
classified according to the state of the different phases:
•  Gas-Liquid mixture.
•  Gas-Solid mixture.
•  Liquid-Solid mixture.
•  Immiscible liquid-liquid.
Multiphase vs. Multispecies

•  Multiphase flows have some level of phase separation at a scale well above
molecular level.
•  Multispecies flows has a mixing on the molecular level, there is no interphase
that indicates a separation at macroscopic level.
Water + oil = multiphase Water + tea = multispecies

Clear and distinct interface Molecular mixing, no interface
Multiphase flows in industry and nature based on

the state of the different phases
•  Multiphase flows are very common in industry and in nature, the following
are a few examples depending on the state of the different phase.
•  Gas–particle flows:
•  Natural: sand storms, volcanoes, avalanches, rain droplets, mist
formation.
•  Biological: aerosols, dust particles, smoke (finely soot particles),
•  Industrial: pneumatic conveyers, dust collectors, fluidized beds, solid
propellant rockets, pulverized solid particles, spray drying, spray casting.
•  Liquid–solid flows:
•  Natural: sediment transport of sand in rivers and sea, soil erosion, mud
slides, debris flows, iceberg formation.
•  Biological: blood flow, eyes, lungs.
•  Industrial: slurry transportation, flotation, fluidized beds, water jet cutting,
sewage treatment plants, bio-reactors.
Multiphase flows in industry and nature based on

the state of the different phases
•  Gas–liquid flows:
•  Natural: ocean waves.
•  Biological: blood flow, eyes, lungs.
•  Industrial: boiling water and pressurized water nuclear reactors,
chemical reactor, desalination systems, sewage treatment plants,
boilers, heat exchangers, internal combustion engines, liquid propellant
rockets, fire sprinkler suppression systems.
•  Liquid–liquid flows:
•  Industrial: emulsifiers, fuel-cell systems, micro-channel applications,
extraction systems.
•  Gas–liquid–solid flows:
•  Industrial: air lift pumps, fluidized beds, oil transportation.
•  As you can see, multiphase flows are

present in many industrial processes and
natural systems.
•  Hence the importance in understanding,
modeling, and simulating multiphase
flows.
Classifying multiphase flow: phase morphology

•  Disperse phase: the phase is dispersed as non-contiguous isolated regions
within the other phase (the continuous phase) .
•  Continuous phase: the phase is contiguous throughout the domain and there
is one well defined interphase with the other phase.
•  When we work with a disperse phase we say that the system is dispersed:
disperse-continuous flow.
•  When we work with continuous phases we say that the system is separated:
continuous-continuous flow.
Dispersed system' Separated system'

Overview/remarks on modeling approaches

•  Simulating multiphase flows is not an easy task.
•  The complex nature of multiphase flows is due to:
•  The transient nature of the flows.
•  The existence of dynamically changing interfaces.
•  Significant discontinuities (fluid properties and fluid separation).
•  Complicated flow field near the interface.
•  Interaction of small scale structures.
•  Particle-particle interactions.
•  Mass transfer.
Overview/remarks on modeling approaches

Free surface
(system scale)
•  Multiphase flows are inherently multi-scale

in nature.
•  It is necessary to account for the cascade
effect of the various flow physics at
different scales: Large bubbles
(system scale)
•  Large flow structures within the fluid Medium bubbles

flow (system-scale). (system-scales)
•  Local structural changes due to

coalescence and breakage processes
(meso-scales). Small bubbles interaction
(meso-scales)
•  Motion and interaction of discrete
constituents or small particles (micro-
scale).
Bubble break-up
And coalescence
(meso-scales) Small sized particles
(micro-scales)
How to treat the wide range of behaviors in

multiphase flows
Increase!
•  Fully resolved: solves complete
physics. All spatial and temporal scales
More modeling required!

are resolved.
Computational power!
•  Eulerian-Lagragian: solves idealized
isolated particles that are transported
with the flow. One- or two-way coupling
is possible. Can account for turbulence,
momentum transfer, and mass transfer.
•  Eulerian-eulerian: solves two or more
co-existing fluids. The system can be
dispersed or separated, and can account
for turbulence, momentum transfer, and Increase!
mass transfer. Module'8')'Lecture'24' 11'

multiphase flows
Separated system Dispersed system
Eulerian-Eulerian approach
Eulerian-Eulerian approach Eulerian-Lagragian approach
(Multi-fluid and mixture
(VOF) (Particle tracking)
models)

multiphase flows
Free surface flows and surface tracking at scales larger than grid size
Applicability of VOF method to separated systems (non-interpenetrating continua)

multiphase flows
•  Bubbles, droplets and/or particles •  Bubbles, droplets and/or particles

bigger than grid scales (GS). smaller than grid scales (sub-grid
•  Can be resolved using VOF. scales or SGS).
•  We need to use models to resolved
SGS.

multiphase flows
Average phase
properties
VOF ≈ 0.5
Dispersed phase in a continuous phase

VOF is not able to handle bubbles smaller than grid scales

multiphase flows
Bubble coalescence, bubble break-up and wake entrainment in dispersed systems

multiphase flows
•  Eulerian-Lagragian approach:
•  The particles can be smaller or larger than the grid size.

•  Can have couple or uncoupled hydrodynamics.
•  The particle position is tracked at all times.
•  Can account for particle interaction and mass transfer.
•  The particles can interact with the boundaries: escape, bounce, stick, wall film.

multiphase flows
Dense regime: particles motion is controlled
primarily by particle-particle collisions.
Dilute regime: particle motion is controlled by

the drag and lift forces on the particle
(particles follow the fluid flow).
volume of the phase in a cell/domain

volume fraction of a phase =
volume of the cell/domain
l
>1 l
x <1 l
V OF = 1 x << 1
V OF < 1 x
V OF << 1 x = grid resolution
V OF = liquid volume fraction
l = liquid characteristic length scale
Separated flow system, dispersed flow system and particles can be present in the 18'
same
problem.
Volume-of-Fluid (VOF) governing equations

for separated systems
Volume-of-Fluid (VOF) governing equations for separated systems
•  The incompressible, isothermal governing equations can be written as

follows,
r·U=0
@⇢U
+ r · (⇢UU) = rp + r · ⌧ + ⇢g + f + ⇢S
@t
Surface tension
Source terms:
•  Porous media
•  Coriolis forces
•  Centrifugal forces
•  Mass transfer
Module'8')'Lecture'24' •  and so on … 20'
•  Phase transport equation and interface tracking with surface compression,
@
+ r · U + r · (Ur (1 )) = 0
@t
0< <1
Interface compression velocity
•  The fluid properties can be written on either side of the interface as follows,
⇢= 1 ⇢1 + (1 1 )⇢2
µ= 1 µ1 + (1 1 )µ2
•  Phase transport equation and interface tracking with surface compression,
@
+ r · U + r · (Ur (1 )) = 0
@t
Ur = min(c |U|, max(|U|)) · n
•  Coefficient to control the magnitude of the compression (cAlpha).

•  Usually 0 < cAlpha < 2.
•  Recommended value 1.'
•  Continuum surface force (CSF) model for the calculation of the surface
tension,
@⇢U
+ r · (⇢UU) = rp + r · ⌧ + ⇢g + f + ⇢S
@t
f = kr
✓ ◆
r
k =r·
|r |
•  k represents the local curvature, based on local gradients.

•  The CSF model neglects the effects of a variable surface tension coefficient.
Eulerian-Eulerian governing equations for

dispersed systems
Eulerian-Eulerian governing equations for dispersed systems
•  The Eulerian-Eulerian approach solves the governing equations for each

phase, it treats the phases as interpenetrating continua.
follows,
Interface forces or Surface tension
momentum transfer
@↵k ⇢k
+ r · (↵k ⇢k Uk ) = 0
@t
@(↵k ⇢k Uk )
+ r · (↵k ⇢k Uk Uk ) = r · (↵k ⌧k ) ↵k rp + ↵k ⇢k g + Mk + f + Sk
@t
X X P Source terms:
↵k = 1.0 ⇢m = ↵k ⇢k k ↵ k ⇢k U k •  Porous media
Um = •  Coriolis forces
k k ⇢m • 
• 
Centrifugal forces
Mass transfer
Module'8')'Lecture'24' •  and so25'
on …
Eulerian-Eulerian governing equations for dispersed systems
•  The incompressible, isothermal governing equations with interface tracking

can be written as follows,
Interface forces or Surface tension
momentum transfer
@↵k ⇢k
+ r · (↵k ⇢k Uk ) = 0
@t
@(↵k ⇢k Uk )
+ r · (↵k ⇢k Uk Uk ) = r · (↵k ⌧k ) ↵k rp + ↵k ⇢k g + Mk + f + Sk
@t
@↵k ⇢k
+ r · Uk ↵k ⇢k + r · (Ur ↵k ⇢k (1 ↵k )) = 0 Source terms:
@t •  Porous media
•  Coriolis forces
•  Centrifugal forces
•  Mass transfer
X X P •  and so on …
↵k = 1.0 ⇢m = ↵k ⇢k k ↵ k ⇢k U k
Um =
k k ⇢m
Interfacial momentum transfer models
•  Closure relations for the interface forces (models),
Ml = Mg = MD + ML + MV M + MT D
Drag
3 Cd
MD = ↵g ⇢l |Ul Ug |(Ul Ug )
4 db
Lift
ML = ↵g ⇢l Cl (Ul Ug ) ⇥ r ⇥ Ul
Virtual Mass ✓ ◆
Dl Ul Dg Ug
MV M = ↵g ⇢l CV M (Ul
Dt Dt
Turbulence Dispersion
MT D = ⇢l CT D r↵g
Interfacial momentum transfer models
Interfacial momentum transfer models in OpenFOAM®
•  In OpenFOAM®, there are many interfacial momentum

transfer models implemented.
•  I want to remind you that there is no universal model, it is
up to you to choose the model that best fit the problem you
are solving.
•  You need to know the applicability and limitations of each
model, for this refer to the literature.
•  Remember, you have the source code so feel free to
explore it.
Eulerian-Eulerian governing equations for

dispersed systems of gas-solid or
liquid-solid (Eulerian-Granular KTGF)
Eulerian-Eulerian governing equations for dispersed systems of
gas-solid or liquid-solid (Eulerian-Granular KTGF)
•  The Eulerian-Granular KTGF (kinetic theory of granular flow), is based on the

kinetic theory of granular flow (analogous to kinetic theory of gases).
•  In the E-G KTGF the liquid phase is solved as in the Eulerian-Eulerian
method and the solid phase is solved using appropriate closure relations.
follows,
@↵k ⇢k
+ r · (↵k ⇢k Uk ) = 0 =P
↵s,k Momentum transfer
@t k
k ↵s,k
@(↵k ⇢k Uk )
+ r · (↵k ⇢k Uk Uk ) = r · (↵k ⌧k ) ↵k rp k rpk + ↵ k ⇢k g + M k
@t
Stress tensor for solid
and fluid Disperse phase
Module'8')'Lecture'24'Shared pressure pressure 31'
•  With the following closure relations


3 @↵s ⇢s ⇥s
+ r · (↵s ⇢s ⇥s Us ) = ( rps I + ⌧s ) : rUs + r · (ks r⇥s ) s + Js
2 @t
•  Granular temperature
1 Particle fluctuating velocity
⇥s = U2f s
3
•  Solid stress tensor

1 2
⌧s = ps I + 2↵s µs (rUs + rUTs ) + ↵s ( s µs )r · Us I
2 3
•  Equation of state for the dispersed phase

ps = ⇢s ↵s ⇥s + 2⇢s ↵s2 g0 ⇥s (1 + esModule'8')'Lecture'24'
) 32'
•  Plus the following additional terms that require closure relations (models),
s Solid bulk viscosity
µs Solid bulk viscosity
⌧f Frictional stresses
g0 Radial distribution function
 Conductivity of granular energy
es Coefficient of restitution of colliding particles
s Dissipation of granular energy

Js Exchange of fluctuating energy between the phases
Mk Momentum transfer models (usually only drag for gas-solid)
For a complete derivation of the governing equation and closure relations, refer to:
Derivation, Implementation, and Validation of Computer Simulation Module'8')'Lecture'24'
Models for Gas-Solid Fluidized Bed 33'
B. van Wachem. PhD Thesis. 2000, TUDelft.
Closure relations for Eulerian-Granular KTGF in OpenFOAM®
•  In OpenFOAM®, there are many closure relations for

Eulerian-Granular kinetic theory of granular flows.
are solving.
explore it.
Eulerian-Lagrangian governing equations
•  In the Eulerian-Lagrangian framework, the continuous phase is solved in an

Eulerian reference system and the particles or dispersed phase is solved in a
Lagrangian reference system.
•  The governing equations can be written as follows
dU
m = Fdrag + Fpressure + Fvirtual mass + Fother
dt
+
Any of the Eulerian formulations (single or multi-phase)
•  In this formulation the secondary phase is treat as discrete particles

dispersed in the continuous fluid.
•  The particles can be smaller or larger than the grid size.
•  The particles can be transported passively.
•  Or they can be coupled with the fluid governing equations. That is, the
particles can modify the fluid field.
•  This formulation accounts for particle interaction and mass transfer.
•  The particles can interact with the boundaries and have a fate. They can
escape, bounce, stick, or form a wall film.
•  If you want, you can add angular momentum to the formulation.
•  Depending on the number or particles tracked, this type of approach can be
computational expensive.
•  There are two approaches to model Eulerian-Lagrangian systems with

hydrodynamic coupling in OpenFOAM®
•  The DPM or Dense Particle Flows* approach, which includes the effect of
the particulate volume fraction on the continuous phase, suitable for dense
particle flow simulation.
•  The MPPIC or Multiphase Particle-in-Cell method** for collisional exchange.

In this approach, particle-particle interactions are represented by models
which utilize mean values calculated on the Eulerian mesh.
•  The MPPIC is suitable for dense to dilute regimes.
*D.M. Snider, An Incompressible Three-Dimensional Multiphase Particle-in-Cell Model for Dense Particle Flows, Journal of
Computational Physics, Volume 170, Issue 2, 1 July 2001, Pages 523–549
**P. J. O’Rourke et al., A model for collisional exchange inModule'8')'Lecture'24' 38' 64,
gas/liquid/solid fluidized beds, Chemical Engineering Science, Volume
2009, pages 1784-1797
Eulerian-Lagrangian models in OpenFOAM®
•  In OpenFOAM®, there are many models for Eulerian-

Lagrangian methods.
are solving.
explore it.
A few applications
Simulation of gravity current – Onset of Kelvin-Helmholtz instability
Liquid-liquid interaction (VOF) !
Rayleigh-Taylor instability – Liquid-liquid interaction
(VOF with AMR)
Rayleigh-Taylor instability – Liquid-liquid-liquid interaction
(VOF with 3 phases)
Particle interaction (no hydrodynamic coupling)!
Fluidized bed hydrodynamics – Gas-solid interaction with hydrodynamic
coupling!
Particles interaction' VOF air and U air'
MRF vs. Sliding grids – VOF
interFoam with MRF interFoam with dynamic meshes
Dynamics of gas-liquid flow in a reactor tank (Euler-Euler)!
Bubble column – Eulerian-Eulerian approach
Free surface – Sea keeping (VOF)!
Free surface – Water splash (VOF)!
Three rising bubbles – VOF with AMR
Why multiphase flow simulations are not easy?

Reactor design
The objective of reactor design is to create the right conditions for reactions. The
temperature and reactant species distribution, appropriate residence time and
removal of products must be considered. Including the effect of a catalyst may
be necessary. A comprehensive understanding of all the competing and
interacting mechanisms is required to arrive at better designs and improved
processes. In particular, gas-solids reacting flows involve, not only complex
interactions of granular materials with gas flow, but also phase-change,
heterogeneous and homogeneous reactions, heat and mass transfer.
Moreover, the spatial and temporal scales may vary over many orders of
magnitude. Thus modeling gas-solid reacting flows requires the integration of
the best physics and chemistry models from various science and engineering
fields with the most advanced computational algorithms. These algorithms must
be scalable to large high-performance computers in order to bear on this
important topic.
Excerpt from the preface of “Computational Gas-Solids 52'
Flows and Reacting Systems: Theory, Methods and Practice”
May, 2010, Eds. S. Pannala, M. Syamlal and T. O’Brien,
Some useful bibliographical references

•  Multiphase Flow Analysis Using Population Balance Modeling:
Bubbles, Drops and Particles
G. H. Yeoh, C. P Cheung, J. Tu. 2013, Butterworth-Heinemann
•  Error analysis and estimation in the Finite Volume method with
applications to fluid flows.
Some useful bibliographical references

•  Computational fluid dynamics of dispersed two-phase flows at high
phase fractions
H. Rusche. PhD Thesis. 2002. Imperial College, London.
•  Towards the numerical simulation of multi-scale two-phase flows
H. Marschall. PhD Thesis. 2011. Technische Universität München.
•  Derivation, Implementation, and Validation of Computer Simulation
Models for Gas-Solid Fluidized Bed
B. van Wachem. PhD Thesis. 2000, TUDelft.
•  Gas-Particle flow in a vertical pipe with particle-particle intractions
J. L. Sinclair, R. Jackson AIChE Journal. Volume 35, Issue 9, 1473-1486,
September 1989
Module 9
Today’s lecture
1.  Tips and tricks in OpenFOAM®
Tips and tricks in OpenFOAM®
Where and how should we

put more salt
… and as this is kind of a cooking recipe, it comes with a

small warning
•  What I am about to show you is based on my personal experience.
•  To draw these kind of conclusions or observations, I conducted hundreds of

numerical experiments, under different conditions, with different meshes
(from good quality meshes to bad quality meshes with different element
types), and different physics and models involved.
•  Most important of all, before starting this long road, I got familiar with the
theory behind the FVM and CFD, the physics behind what I was doing, and
OpenFOAM® source code.
•  At this point, I highly advise you to conduct similar numerical experiments

and draw your own conclusions.
•  Please, use these slides as a reference only. I am not responsible for your
failures and mistakes.
Our vertical workflow
•  Do you remember this vertical workflow? I hope so.
•  Everything starts with the geometry. So in order to
get a good mesh, you need a good geometry. GEOMETRY GENERATION
•  When it comes to geometry generation, the only rule

you should keep in mind is that by the end of the day
MESH GENERATION
you should get a unique clean and watertight
geometry.
•  Geometry defeaturing can made your life easier. Do
CASE SETUP AND SOLUTION
not fool yourself, if you have no constraints avoid
sharp angles.
•  And as for the mesh concerns, try to keep the
POST-PROCESSING
skewness, orthogonality, aspect ratio, and growth rate
low.
•  No need to say that if you have a bad geometry, is
likely probable that your mesh will be bad as well.
Module'9')'Lecture'25' 6'1
•  Always remember: good mesh – good results.
OpenFOAM® shell environment
•  You can have as many versions of OpenFOAM® as you like living together. You just
need to source the right environment variables. For instance, on my workstation I
have nine versions living together. This is how my .bashrc file looks like,
### OPENFOAM ###
# source $HOME/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-1.6-ext.GPU/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-1.7.1/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.0.x/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.3.0-debug/etc/bashrc
source $HOME/OpenFOAM/OpenFOAM-2.3.x/etc/bashrc
### OPENFOAM ###
•  If at any time I want to use a different version of OpenFOAM®, I just source the right
OpenFOAM® environment variables. For instance if I want to switch from version
2.2.0 to version 2.3.x, I modify my .bashrc as follows,
Old .bashrc New .bashrc

### OPENFOAM ### ### OPENFOAM ###
# source $HOME/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc

# source $HOME/OpenFOAM/OpenFOAM-1.6-ext.GPU/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-1.6-ext.GPU/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-1.7.1/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-1.7.1/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.0.x/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-2.0.x/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.1.1/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-2.1.1/etc/bashrc
source $HOME/OpenFOAM/OpenFOAM-2.2.0/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-2.2.0/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.3.0-debug/etc/bashrc # source $HOME/OpenFOAM/OpenFOAM-2.3.0-debug/etc/bashrc
# source $HOME/OpenFOAM/OpenFOAM-2.3.x/etc/bashrc source $HOME/OpenFOAM/OpenFOAM-2.3.x/etc/bashrc
### OPENFOAM ### ### OPENFOAM ###
•  Then open a new terminal, and you can start using the new version. You can also
have two different versions of OpenFOAM® running together at the same time in
different terminals.
•  You can also use aliases to sourceModule'9')'Lecture'25'
the OpenFOAM® version. 8'
•  When switching from one OpenFOAM® version to another one, it is highly advisable
to clear as many OpenFOAM environment settings as possible, to do so you can use
the script unset.sh. In the terminal type:
•  unset
•  Be careful, there may be more than one unset.sh script. The OpenFOAM® specific
script is located in the directory $WM_PROJECT_DIR/etc/config.
•  You can also use the alias wmUNSET, which is set in the OpenFOAM® environment
variables. Remember, you can type alias in the terminal window to see all the
aliases available.
•  In the directory $WM_PROJECT_DIR/etc/config, you will also find many useful

scripts. For instance, you can take a look at the script aliases.sh, in this script you
will find all the aliases defined in OpenFOAM®
Looking for information in OpenFOAM® source code
•  To locate files you can use the find command. For instance, if you want to locate a
file that contains the string fvPatch in its name you can proceed as follows,
•  find $FOAM_SOLVERS -name “*fvPatch*”

This command will locate the files containing the string “*fvPatch*” in the
directory $FOAM_SOLVERS
•  If you want to find a string inside a file, you can use the command grep
•  grep -r -n LES $FOAM_SOLVERS

This command will look for the string LES in all files inside the directory
$FOAM_SOLVERS. The option -r means recursive and -n will output the line
number.
•  As you might already know, there are a gazillion dictionaries in OpenFOAM®. The
easiest way to find all of them is to do a local search in the installation directory as
follows,
•  For instance, if you are interested in finding all dictionary files that end with the
“Dict” word in the tutorials directory, in the terminal type:
•  find $FOAM_TUTORIALS -name "*Dict”
•  find $FOAM_TUTORIALS -iname ”*dict”
•  A few more advanced commands to find information in your OpenFOAM® installation.
•  To find which tutorial files use the boundary condition "slip":
•  find $FOAM_TUTORIALS -type f | xargs grep -sl 'slip’
•  To find where the source code for the boundary condition "slip" is located:
•  find $FOAM_SRC -name "*slip*”
•  To find what applications do not run in parallel
•  $WM_PROJECT_DIR -type f | xargs grep -sl ’noParallel’
•  Remember, OpenFOAM® understand REGEX syntax.

OpenFOAM® Doxygen documentation
•  The best source of information is the source code and the Doxygen documentation.
•  The $WM_PROJECT_DIR/doc directory contains the Doxygen documentation of

OpenFOAM®.
•  Before using the Doxygen documentation, you will need to compile it. To compile the
Doxygen documentation, from the terminal:
•  cd $WM_PROJECT_DIR
•  ./Allwmake doc
Note: You will need to install doxygen and graphviz/dot
•  After compiling the Doxygen documentation you can use it by typing:

•  firefox file://$WM_PROJECT_DIR/doc/Doxygen/html/index.html
•  The compilation is time consuming.
Intensive IO
•  If you are doing intensive IO or running big cases, I highly advise you to save the
solution in binary format. When using binary format, the IO is a way much faster and
the output files use less space.
•  Remember, you can get a performance gain when you save in binary format as you
minimize any requirement for parsing.
'
•  If OpenFOAM® binary format is not good enough for you, you can try another format.
For instance you can use HDF5 format with OpenFOAM®.
http://openfoamwiki.net/index.php/Contrib/IOH5Write
'
Intensive IO
•  Know your hardware, intensive IO can slow-down your computations or crash your
system, even the most powerful supercomputers.
•  For big simulations, most of the times the bottleneck is the IO.
•  No need to say that eventually you will run out of space if you are working with big
files.
•  One naïve solution to the IO bottleneck and big datasets space, do not save your
solution very often. But be careful, at least save your solution before stopping your
solution or reaching the job maximum time.'
Running in a cluster
•  Best advice, familiarize with your hardware.
•  Do not get overwhelm when running in a cluster. Running OpenFOAM® in a cluster

is not different from running in your workstation or portable computer. The only
difference is that you need to schedule your jobs.
•  Depending on the system current demand of resources, the resources you request
and your job priority, sometimes you can be in queue for hours, even days, so be
patient and wait for your turn.
•  Consequently, remember to always double or triple check your scripts. It will be a

waste of time if after two days in queue, your simulation did not start because there
were errors in your scripts.
•  For those running on fancy clusters, such as blue gene supercomputers, I have found
a processor limit of 512, after that is quite difficult to get any improvement.
•  Also, the IO is really time consuming.'

Running in a cluster
•  By the way, I know it looks super cool, but try to avoid spaces or funny characters
when naming directories and files, specially if you run in clusters. e.g.:
•  my dictionary.dict instead use my_dictionary.dict

•  #my_file;txt instead use my_file.txt
•  my/solution!!! instead use my_solution
•  working@home instead use working_at_home
'
'
OpenFOAM® mesh quality and checkMesh utility
•  Before running a simulation remember to always check the mesh quality using the
checkMesh utility.
•  Remember, good quality meshes are of paramount importance to obtain accurate
results.
•  checkMesh will also check for topological errors.
•  Have in mind that topological errors must be repaired.
•  You will be able to run with mesh quality errors (such as skewness, aspect ratio,
minimum face area, and non-orthogonality), but they will severely tamper the solution
accuracy and can made the solver run super slow or even blow-up.
•  In my personal experience, I have found that OpenFOAM® is very picky when it
comes to mesh quality. So if checkMesh is telling you that the mesh is bad, you
better correct those errors.
•  Unfortunately, to correct mesh quality errors you will have to remesh the geometry.
•  If for any reason checkMesh finds errors, it will give you a message and it will tell you
what check failed.
•  It will also write a set with the faulty cells, faces, and/or points. These sets are saved
in the directory constant/polyMesh/sets/
•  If at any point you want to visualize the failed faces/cells/points you will need to
convert them to VTK format using the utility foamToVTK.
•  At the end, foamToVTK will create a directory named VTK, where you will find the
failed faces/cells/points in VTK format. At this point you can use paraFoam/
paraview to visualize the failed sets.
•  I want to emphasize the fact that you will be able to run with mesh quality errors such
as skewness, aspect ratio, minimum face area, and non-orthogonality.
•  However, they will severely tamper the solution accuracy and can made the solver
explode.
•  If you want to know the quality metrics hard-wired in OpenFOAM®, just read the file
$WM_PROJECT_DIR/src/OpenFOAM/meshes/primitiveMesh/
primitiveMeshCheck/primitiveMeshCheck.C. Their maximum (or minimum)
values are defined as follows:
•  Foam::scalar Foam::primitiveMesh::closedThreshold_ = 1.0e-6;

•  Foam::scalar Foam::primitiveMesh::aspectThreshold_ = 1000;
•  Foam::scalar Foam::primitiveMesh::nonOrthThreshold_ = 70; // deg
•  Foam::scalar Foam::primitiveMesh::skewThreshold_ = 4;
•  Foam::scalar Foam::primitiveMesh::planarCosAngle_ = 1.0e-6;
•  By the way, if you are not happy with these values, you can just change them and
voila, your quality problems are solved (I am kidding of course).
OpenFOAM® mesh quality and renumberMesh utility
•  Before running a simulation, I highly recommend you to use the renumberMesh
utility. This utility will renumber the mesh to minimize its bandwidth, in other words, it
will make the linear solver run faster (at least for the first time-steps)
•  Summarizing, before running a simulation remember to always check the mesh

quality using checkMesh and then reduce the mesh bandwidth by using the
renumberMesh. This is a good standard practice, I always do it (at least for big
meshes).
•  Before running a simulation, try to always get a good quality mesh. Remember,
garbage in – garbage out. Or in a positive way, good mesh – good results.
Boundary conditions
•  Boundary conditions should be physically realistic. They must represent the physics
involved.
•  Minimize grid skewness, non-orthogonality, growth rate, and aspect ratio near the
boundaries. You do not want to introduce diffusion errors early in the simulation,
specially close to the inlets.
•  Get a good quality mesh at the boundaries.
•  Remember, for each single variable you are solving you need to specify a boundary
condition.
Boundary conditions
•  Try to avoid large gradients in the direction normal to the boundaries near inlets and
outlets. That is to say, put your boundaries far away from where things are
happening.
•  Do not force the flow at the outflow, use a zero normal gradient for all flow variables
except pressure. The solver extrapolates the required information from the interior.
•  Be careful with backward flow at the outlets (flow coming back to the domain) and
backward flow at inlet (reflection waves), they require special treatment.
Initial conditions
•  First at all, a good initial condition can improve the stability and convergence rate. On
the other hand, unphysical boundary conditions can slow down the convergence rate
or can cause divergence.
•  As for boundary conditions, for each single variable you are solving you need to
specify initial conditions.
•  When it is possible, use potentialFoam to get an initial solution. It is computational

inexpensive.
•  potentialFoam can also give you an idea of the sensitivity of the mesh quality.
Initial conditions
•  You can also get a computational inexpensive solution on a coarse mesh and then
interpolate it to a fine mesh. This will be a very good initial solution only if the solution
in the coarse mesh is acceptable.
•  By the way, do not forget to use a good quality coarse mesh.
•  Use mapFields to map the solution from a coarse mesh to a finer mesh. It also
works the other way around, but I do not see any reason to proceed in this way.
Initial conditions
•  If you are using a turbulence model, you can initialize the velocity and pressure fields
from the solution obtained from a laminar case.
•  If you are running an unsteady simulation and if the initial transient is of no interest,
you can initialize your flow using the solution obtained from a steady simulation.
•  Always try to get initial conditions that are close to the solution (I know this is difficult
to achieve as we do not know the solution, if we knew the solution we would not have
a job).
•  I want to remind you again, initial conditions should be physically realistic.
Starting and running a simulation
•  Remember, you can change the parameters in the dictionaries controlDict,
fvSchemes and fvSolution on the fly. But you will need to set the keyword
runTimeModifiable to yes in the controlDict dictionary.
•  When starting a simulation and if the initial transient is of no interest, you can start the
simulation by using a high value of viscosity (low Reynolds number), and as the
simulation runs you can change the value until you reach the desired value.
•  If you are working with high Reynolds numbers and you do not like the trick of
increasing the viscosity, you can get a very good initial solution using an Euler solver
with upwind.
•  You can also start the simulation by using a first order scheme and then switch to a
high order scheme.
Starting and running a simulation
•  You can also change the convergence criterion of the linear solvers on the fly.
•  For instance, you can start using a not so tight convergence criterion with a robust
numerical scheme, and as the simulation runs you can tighten the convergence
criterion to increase the accuracy.
•  When the simulation starts I usually use more correctors steps (for
•  and PIMPLE methods), and as the solution advance or stabilizes I decrease the
number of corrector steps, but I always use at least one corrector step.
•  Remember to always check the time step continuity errors. This number should be
small (negative or positive), if it increases in time for sure something is wrong.
•  If you want to know how the continuity errors are computed just type in the terminal
find $FOAM_SRC –iname *continuity*, and open any of the files.
Discretization schemes
•  Never get a final solution using first order schemes. They are too diffusive, which
means they will under predict the forces and smear the gradients. In the other side,
first order schemes are extremely robust, so you might be tented to use them as they
will always give you a solution.
•  You can start using a first order scheme, and then switch to a high order scheme.
Remember, you can change the parameters on the fly.
•  This means, start robustly and end with accuracy.
•  By the way, an accurate numerical scheme needs a good quality mesh.
•  Bad quality meshes will add numerical oscillations and reduce the accuracy of the
numerical solution.
Discretization schemes
•  If you have a good mesh and a good initial solution, you can start immediately with
a high order scheme, but be careful, remember to always check the stability of the
solution.
•  If at one point your solution starts to oscillate, you can switch to upwind and let the
simulation stabilize, then you can switch back to high order accuracy.
•  Have in mind that this behavior is telling you that something is happening so you
better adjust other parameters, such as, solver tolerances, non-orthogonal
corrections, number of correctors, gradient discretization and so on.
•  Try to always use a good quality mesh. Avoid the GIGO syndrome.
•  In the next slides I will show you how I usually setup the discretization schemes.
Discretization schemes – Convective terms
•  A robust numerical scheme but too diffusive,
divSchemes
{
div(phi,U) Gauss upwind;
div(phi,omega) Gauss upwind;
div(phi,k) Gauss upwind;
div((nuEff*dev(T(grad(U))))) Gauss linear;
}
•  An accurate and stable numerical scheme,
divSchemes
{
div(phi,U) Gauss linearUpwind grad(U);
div(phi,omega) Gauss linearUpwind default;
div(phi,k) Gauss linearUpwind default;
}
•  An even more accurate but oscillatory scheme,
divSchemes
{
div(phi,U) Gauss linear;
div(phi,omega) Gauss linearUpwind default;
}
Discretization schemes – Diffusive terms
•  For the discretization of the diffusive terms, you can use a fully orthogonal scheme,
laplacianSchemes
{
default Gauss linear corrected;
}
•  You can also use a scheme that uses a blending between a fully orthogonal scheme
and a non-orthogonal scheme,
laplacianSchemes
{
default Gauss linear limited ;
}
•  The method you use highly depends on the quality of the mesh.
•  For meshes with low non-orthogonality you can use the corrected scheme or the
limited 1 scheme.
•  For meshes with high non-orthogonality you can use the limited scheme.
The higher the non-orthogonality the lower the value of the blending factor .
0 1
•  Bad quality mesh •  Good quality mesh
•  Non-orthogonal correction •  Orthogonal correction
•  Bounded on low quality meshes •  Unbounded on low quality meshes
•  An accurate numerical scheme on orthogonal meshes (this is a very good quality
mesh with uniform cell size, this is what we want),
laplacianSchemes
{
default Gauss linear orthogonal;
}
snGradSchemes
{
default orthogonal;
}
•  An accurate numerical scheme on orthogonal meshes (with non-orthogonal
corrections),
laplacianSchemes
{
default Gauss linear limited 1;
}
snGradSchemes
{
default limited 1;
}
•  A less accurate numerical scheme valid on non-orthogonal meshes (with non-
orthogonal corrections),
laplacianSchemes
{
default Gauss linear limited 0.5;
}
snGradSchemes
{
default limited 0.5;
}
Discretization schemes – Gradient terms
•  Let us talk about the gradSchemes, this entry defines the way we compute the
gradients.
•  The gradients can be computed using the Gauss method or the least squares
method. The keywords are:
•  Gauss linear;
•  leastSquares;
•  In practice, the leastSquares method is more accurate, however, I have found that
it tends to be more oscillatory on tetrahedral meshes.
•  You can also use gradient limiters.
•  Gradient limiters will avoid over and under shoots on the gradient computations.
There are four available,
cellMDLimited Less diffusive

cellLimited
faceMDLimited
faceLimited More diffusive
•  The following entry corresponds to the leastSquares method using gradient

limiters
cellMDLimited leastSquares 1.0;
•  Gradient limiters avoid over and under shoots on the gradient computations.
•  The gradient limiter implementation in OpenFOAM®, uses a blending factor .
gradSchemes
{
default cellMDLimited Gauss linear ;
}
0 1
Accuracy Stability
Limiter off Module'9')'Lecture'25'
Limiter on 42'
Discretization schemes – How to choose the schemes
•  If after checking the mesh quality, the non-orthogonality is higher than 80, I prefer to
redo the mesh and improve the quality.
•  By the way, if you are running LES simulations, do not even think about running in
highly non-orthogonal meshes. Better spend more time in getting a good quality
mesh, maybe with non-orthogonality less than 60.
•  Do not try to push too much the numerical scheme on highly non-orthogonal meshes.
You already know that the quality is low, so this highly influence the accuracy and
stability of the solution. Specially the gradient computations.
•  I do not like to run simulations on highly orthogonal meshes, but if I have to, I often
use the following numerical scheme.
•  Non-orthogonality more than 80. I do not waste my time. I prefer to go back and get a
better mesh. But if you want, you can try something like this,
gradSchemes laplacianSchemes
{ {
default faceLimited leastSquares 1.0; default Gauss linear limited 0.333;
grad(U) faceLimited leastSquares 1.0; }
}
divSchemes snGradSchemes
{ {
div(phi,U) Gauss linearUpwind grad(U); default limited 0.333;
div(phi,omega) Gauss upwind; }
}
•  Non-orthogonality between 70 and 80
{ {
default cellLimited leastSquares 1.0; default Gauss linear limited 0.5;
grad(U) cellLimited leastSquares 1.0; }
}
{ {
div(phi,omega) Gauss upwind; }
}
{ {
default cellMDLimited Gauss linear 0.5; default Gauss linear limited 0.777;
grad(U) cellMDLimited Gauss linear 0.5; }
}
{ {
div(phi,omega) Gauss linearUpwind default; }
}
{ {
default cellMDLimited Gauss linear 0.5; default Gauss linear limited 1.0;
grad(U) cellMDLimited Gauss linear 0.5; }
}
{ {
div(phi,omega) Gauss linearUpwind default; }
}
•  I guess at this point you know how to adjust the numerical scheme for meshes with
non-orthogonality less than 40.
•  Additionally, I also change the number of non-orthogonal corrections.
•  Non-orthogonality between 70 and 80:

nNonOrthogonalCorrectors 3;
•  Non-orthogonality between 50 and 70:

•  Non-orthogonality less than 50:

•  I always like to do at least one correction.

Under-relaxation factors
•  Because of the non-linearity of the equations being solved, it is necessary to control
the change of . This is achieved by under-relaxation as follows,
⇤
n n 1 n n 1
P = P + ↵( P P )
here ↵ is the relaxation factor,
Means under-relaxation. This will slow down the convergence
<1 rate but increases the stability.
↵=1 Means no relaxation at all. We simple use the predicted value of .
Means over-relaxation. It can sometimes be used to accelerate

>1 convergence rate but will decrease the stability.
•  In plain English, this means that the new value of the variable depends upon the
old value, the computed change of , and the under-relaxation factor ↵ .
•  Under-relaxation factors are typical of steady solvers using the SIMPLE method.
•  To find out what are and how to change the under-relaxation factors requires
experience and understanding.
•  In general, under-relaxation factors are there to suppress oscillations.
•  Small under-relaxation factors will significantly slow down convergence. Sometimes

to the extent that the user thinks the solution is converged when it really is not.
•  The recommendation is to always use under-relaxation factors that are as high as

possible, without resulting in oscillations or divergence.
•  I highly recommend you to use the default under-relaxation factors.
•  If you have to change the under-relaxation factors, start by decreasing the values of
the under-relaxation factors in order to improve the stability of the solution.
•  Remember, low under-relaxation factors will slow down the solver while high under-
relaxation factors will speed up the computation, but you will give up stability.
•  In order to find the optimal under-relaxation factors for your case, it will take some trial
and error.
•  These are the under-relaxation factors I often use (which by the way are the
commonly used).
relaxationFactors
{
p 0.3;
U 0.7;
k 0.7;
omega 0.7;
}
•  According to the physics involved you will need to add more under-relaxation factors.
•  If you do not define the new under-relaxation factors, they will be set to 1.0 by default.
relaxationFactors
0 1
Velocity
Stability
Linear solvers
•  The linear solvers are defined in the fvSolution dictionary. You will need to define
a solver for each variable you are solving.
•  The solvers can be modified on the fly.
•  The GAMG solver (generalized geometric-algebraic multigrid solver), can often be the
optimal choice for solving the pressure equation. However, I have found that when
using more than 1024 processors is better to use Newton-Krylov type solvers.
Linear solvers
•  When solving multiphase problems, I have found that the GAMG solver might give
problems when running in parallel, so be careful. The problem is mainly related to
nCoarsestCells keyword, so usually I have to set a high value of cells (in the order
1000).
•  The utility renumberMesh can dramatically increase the speed of the linear solvers,
specially during the firsts iterations.
•  I usually start by using a not so tight convergence criterion and as the simulation runs,
I tight the convergence criterion.
Linear solvers
•  These are the linear solvers I often use.
•  For the pressure equation I usually start with a tolerance equal to 1e-5 and relTol
equal to 0.01. After a while I change these values to 1e-6 and 0.001 respectively.
p
{
solver GAMG;
tolerance 1e-5;
relTol 0.01;
smoother GaussSeidel;
nPreSweeps 0;
nPostSweeps 2;
cacheAgglomeration on;
agglomerator faceAreaPair;
nCellsInCoarsestLevel 1000;
mergeLevels 1;
}
Linear solvers
p
{
solver GAMG;
tolerance 1e-6;
relTol 0.001;
nPreSweeps 0;
nPostSweeps 2;
mergeLevels 1;
}
Linear solvers
•  If I do not use the GAMG solver for the pressure, I often use the PCG solver.
•  If the speed of the solver is too slow, I change the convergence criteria to 1e-4 and
relTol equal to 0.05. I usually do this during the first iterations.
p
{
solver PCG;
preconditioner DIC;
tolerance 1e-4;
relTol 0.05;
}
Linear solvers
•  For the velocity equation I always use a tolerance equal to 1e-8 and
relTol equal to 0.0
U
{
solver PBiCG;
preconditioner DILU;
tolerance 1e-8;
relTol 0.0;
}
Linear solvers
•  I like to set the minimum number of iterations to three, especially for the pressure.
•  If your solver is doing too much iterations, you can set the maximum number of
iterations. But be careful, if the solver reach the maximum number of iterations it will
stop, we are talking about unconverged iterations.
•  You can set the maximum number of iterations specially during the first time-steps
where the solver takes longer.
•  I use minIter and maxIter on symmetric and asymmetric matrix solvers.
p
{
solver PCG;
preconditioner DIC;
tolerance 1e-4;
relTol 0.01;
minIter 3;
maxIter 100;
}
Linear solvers
•  The default option is the conventional segregated solution. That is, you first solve for
velocity component x, then velocity component y and finally velocity component z.
•  You can get some improvement in terms of stability and turn around time by using the
coupled matrix solver for vectors and tensors, i.e., if you are solving the velocity field,
you solve all the velocity components at once.
•  To select the coupled solver you need to use the keyword coupled in the
fvSolution dictionary.
•  In the coupled matrix solver you set tolerance as a vector (absolute and relative)
U
{
type coupled;
solver cPBiCCCG;
preconditioner DILU;
tolerance (1e-08 1e-08 1e-08);
relTol (0 0 0);
minIter 3;
Linear solvers
•  Remember, you must do at least one corrector step when using PISO solvers.
•  When you use the PISO and PIMPLE solvers, you also have the option to set the
tolerance for the final corrector step (.*Final).
•  By proceeding in this way, you can put all the computational effort only in last
corrector step (.*Final).
pFinal
{
solver GAMG;
tolerance 1e-06;
relTol 0.0;
nPreSweeps 0;
nPostSweeps 2;
mergeLevels 1;
}
Linear solvers
•  By proceeding in this way, you can put all the computational effort only in last
corrector step (.*Final).
•  For all the intermediate corrector steps, you can use a more relaxed convergence
criterion.
•  For example, you can use the following solver and tolerance criterion for all the
intermediate corrector steps (p), then in the final corrector step (pFinal) you tight the
solver tolerance.
p pFinal
{ {
solver GAMG; solver GAMG;
tolerance 1e-05; tolerance 1e-06;
relTol 0.05; relTol 0.0;
smoother GaussSeidel; smoother GaussSeidel;
nPreSweeps 0; nPreSweeps 0;
nPostSweeps 2; nPostSweeps 2;
cacheAgglomeration on; cacheAgglomeration on;
agglomerator faceAreaPair; agglomerator faceAreaPair;
nCellsInCoarsestLevel 1000; nCellsInCoarsestLevel 1000;
mergeLevels 1; mergeLevels 1;
} }
Transient simulations and time-step selection
•  Remember, the fact that we are using an implicit solver (unconditionally stable), does
not mean that we can choose a time step of any size.
•  The time-step must be chosen in such a way that it resolves the time-dependent
features and it maintain the solver stability.
•  In my personal experience, I have been able to go up to a CFL = 5.0 while
maintaining the accuracy. To achieve this I had to increase the number of corrector
steps in the PIMPLE solver, decrease the under-relaxation factors and tightening the
convergence criteria; and this translates into a higher computational cost.
•  I have managed to run with CFL numbers up to 40, but this highly reduces the
accuracy of the solution. Also, is quite difficult to maintain the stability of the solver.
•  As I am often interested in the unsteadiness of the solution, I usually use a CFL

number not larger than 1.0.
•  If accuracy is the goal (e.g., predicting forces), definitively use a CFL less than 1.0.
•  If you are doing LES simulations, I highly advice you to use a CFL less than 0.6 and if
you can afford it, less than 0.3
•  If you are doing LES or you are interested in the accurate prediction of forces,
definitely you need high quality meshes, preferable made of hexahedral elements.
•  I usually use the PIMPLE solver. In the PIMPLE solver you have the option to limit
your time-step to a maximum CFL number, so the solver automatically choose the
time-step. This is a very cool feature.
•  In the PISO solver you need to give the time-step size. So basically you need to
choose your time-step so it does not exceed a target CFL value.
Module'9')'Lecture'25' 10
67'
•  You can easily also modify the PISO solver so it automatically choose the time-step
according to a maximum CFL number, you just need to add one line of code.
•  Remember, setting the keyword nOuterCorrectors equal to 1 in the PIMPLE

solver is equivalent to use the PISO solver.
•  The PIMPLE solver is a solver specially formulated for large time-steps. So in order
to increase the stability you will need to add more corrector steps
(nOuterCorrectors and nCorrectors).
•  A smaller time-step may be needed in the first iterations to maintain solver stability.
Have in mind that the first time steps may take longer to converge, do not be alarmed
of this behavior, it is perfectly normal.
•  If you are interested in the initial transient, you should start using a high order
discretization scheme, with a tight convergence criterion, and the right flow properties.
•  If you start from an approximate initial solution obtained from an steady simulation,
the initial transient will not be accurate.
•  If the solution is not converging or is taking too long to converge, try to reduce your
time-step.
•  If you use the first order Euler scheme, try to use a CFL number less than 1.0 and
preferably in the order of 0.6-0.8, this is in order to keep temporal diffusion to a
minimum. Yes, numerical diffusion also applies in time.
•  In order to speed up the computation and if you are not interested in the initial
transient, you can start using a large time-step (high CFL).
•  When you are ready to sample the quantity of interest, reduce the time-step to get a
CFL less than one and let the simulation run for a while before doing any sampling.
•  My recommendation is to always monitor your solution, and preferably use the

PIMPLE solver.
•  When using the PIMPLE or PISO solver (with maximum CFL feature enable), the
solver will use as a time-step for the first iteration the value set by the keyword
deltaT in the controlDict dictionary. So if you set a high value, is likely that the
solver will explode.
•  My advice is to set a low deltaT and then let the solver gradually adjust the time-
step until the desired maximum CFL is reached.
•  Some fancy high order numerical schemes (such as the vanLeer, vanAlbada,
superbee, MUSCL, OSPRE – cool names no – ), are hard to start. So it is better to
begin with a small time-step and increase it gradually.
•  And by small time-step I mean a time-step that will give a CFL about 0.1.
•  Remember, you can change the temporal discretization on the fly. As for the spatial
discretization, first order schemes are robust and second order schemes are
accurate.
Transient simulations and temporal discretization schemes
•  The temporal discretization schemes are set in the fvSchemes dictionary. To select
the schemes you need to use the keyword ddtSchemes.
•  Euler is a first order implicit scheme (bounded).
•  Backward is a second order implicit scheme (unbounded). Similar to the linear

multistep Adams-Moulton scheme.
•  Crank-Nicolson is a second order implicit scheme (bounded).
•  It you do not know what temporal discretization scheme to use, go for the Crank-
Nicolson.
•  The Crank-Nicolson as it is implemented in OpenFOAM®, uses a blending factor .

FYI, you can change the blending on the fly.
•  Setting equal to 0 is equivalent to running a pure Euler scheme (robust but first
order accurate). By setting the blending factor equal to 1 you use a pure Crank-
Nicolson (accurate but oscillatory, formally second order accurate). If you set the
blending factor to 0.5, you get something in between first order accuracy and second
order accuracy, or in other words, you get the best of both worlds.
ddtSchemes
{
default CrankNicolson ;
}
•  The Crank-Nicolson as it is implemented in OpenFOAM®, uses a blending factor .
ddtSchemes
{
default CrankNicolson ;
}
0 1
Pure Euler Pure Crank-Nicolson
1st order, bounded Module'9')'Lecture'25'
2nd order, bounded 74'
Notes on convergence
•  Determining when the solution is converged can be really difficult.
•  Solutions can be considered converged when the flow field and scalar fields are no
longer changing, but usually this is not the case for unsteady flows. Most flows in
nature and industrial applications are highly unsteady.
•  It is a good practice to monitor the residuals. But be careful, residuals are not always
indicative of a converged solution. The final residuals will reach the tolerance
criterion in each iteration, but the flow field may be continuously changing from instant
to instant.
•  In order to properly assess convergence, it is also recommended to monitor a

physical quantity. If this physical quantity does not change in time you may say that
the solution is converge.
•  But be careful, it can be the case that the monitored quantity exhibit a random
oscillatory behavior or a periodic oscillatory behavior, in the former case you are in
the presence of a highly unsteady and turbulent flow with no periodic behavior; in
latter case you may say that you have reached a converged periodic unsteady
solution.
•  Remember, for unsteady flows you will need to analyze/sample the solution in a given
time window. Do not take the last saved solution as the final answer.
•  If your goal is predicting forces (e.g., drag prediction). You should monitor the forces,
and use them as your convergence criterion.
•  The convergence depends on the mesh quality, so a good quality mesh means
faster convergence and accurate solution.
76'
•  In general, overall mass balance should be satisfied. Remember, the method is
conservative. What goes in, goes out.
•  Residuals are not your solution. Low residuals do not automatically mean a correct
solution, and high residuals do not automatically mean a wrong solution.
•  Initial residuals are often higher with higher order discretization schemes than with
first order discretization. That does not mean that the first order solution is better.
•  Always ensure proper convergence before using a solution. A not converged solution
can be misleading when interpreting the results.
Monitoring minimum and maximum values of field variables
•  I always monitor the minimum and maximum values of the field variables. For me this
is the best indication of stability and accuracy. For this, I use functionObject.
•  If at one point of the simulation, velocity is higher that the speed of light (believe me,
that can happen), you know that something is wrong.
•  And believe me, using upwind you can get solutions at velocities higher that the
speed of light, you can even do coffee if you want.
•  You can also see an oscillatory behavior of the minimum and maximum values of the
monitored quantity. This is also an indication that something is going bananas.
•  For some variables (e.g. volume fraction), the method must be bounded. This means
that the values should not exceed some predefined minimum or maximum value
(usually 0 and 1).
Again, our friend mesh quality
Mesh quality and cell type
•  I do not know how much to stress this, but try to always use a good quality
mesh. Remember, garbage in - garbage out.
•  Or in a positive way, good mesh – good results.
•  Use hexahedral meshes whenever is possible, specially if high accuracy in predicting

forces is your goal (e.g., drag prediction).
•  For the same cell count, hexahedral meshes will give more accurate solutions,
especially if the grid lines are aligned with the flow.
•  But this does not mean that tetra mesh are no good, by carefully choosing the
numerical scheme, you can get the same level of accuracy. The problem with tetra
meshes are mainly related to the way gradients are computed.
82'
•  Tetra meshes normally need more computing resources during solving stage. But his
can be easily offset by the time saved during the mesh generation stage.
•  If the geometry is slightly complicated, it is just a waste to spend time on hex

meshing. Your results will not be better, most of time, if not always. With todays
advances in HPC and numerical methods, the computing time saved with hex mesh
is marginal compared with time wasted in mesh generation.
•  Increasing the cells count will likely improve the solution accuracy, but at the cost of a
higher computational cost.
•  But attention, finer mesh does not mean a good or better mesh.
•  Very often when you refine your mesh (specially when it is done automatically), the
overall quality of the mesh is reduced due to clustering and stretching of the mesh.
•  Change in cell size should be smooth.
•  In boundary layers, quad, hex, and prism/wedge cells are preferred over triangles,
tetrahedras, or pyramids.
•  The mesh density should be high enough to capture all relevant flow features. A
good mesh should be done in such a way that it resolve the physics of interest and it
is adequate for the models used, and not in the fact that the more cells we use the
better the accuracy.
•  A good mesh resolve physics, and does not need to follow the CAD model. We are
talking about geometry defeaturing, you do not need to resolve all features of your
CAD model.
84'
•  There is a new type of meshes in town, polyhedral meshes.
•  Many meshing guys and CFDers claim that polyhedral meshes are the panacea of
meshing.
•  In polyhedral meshes the cells have more neighbors than in tetrahedral and/or
hexahedral meshes, hence the gradients are approximated better on polyhedral
meshes.
•  But attention, this does not mean that this kind of meshes are the solution to all
meshing problems, is just a new religion in the meshing and CFD community, you
need to become a true believer.
•  Another interesting property of polyhedral meshes is that they reduce the cell count.
But there is a catch, they increase the number of faces so you need to compute more
fluxes (diffusive and convective).
•  Polyhedral meshes are not easy to generate, most of the times you need to start from
tetrahedral meshes.
•  In my personal experience, polyhedral meshes inhered the same quality problems of

the starting tetrahedral mesh, sometimes they made things worst.
•  Are polyhedral meshes better than hex or tet meshes? You need to conduct your
own numerical experiments.
•  Just to end for good the meshing talk:
•  A good mesh is a mesh that serves your project objectives.
•  So, as long as your results are physically realistic, reliable and accurate; your
mesh is good.
•  At the end of the day, the final mesh will depend on the physic involve.
•  Know your physics and generate a mesh able to resolve that physics, without
over-doing.
•  At this point, I think you got the idea of the relevance of the mesh.
87'
Who owns the mesh, owns the solution
88'
My simulation is always exploding
•  If after choosing the numerical scheme, linear solvers, and time step, your simulation
always crash, you can try this.
•  Set the discretization scheme of the convective terms to upwind.
•  Set the discretization scheme of the diffusive terms to Gauss linear
limited 0.5
•  Set the discretization scheme of the gradient terms to cellLimited Gauss
linear 1.0
•  Set the temporal discretization scheme to euler.
•  Use the PISO method, and set nCorrectors 3,'and'
nNonOrthogonalCorrectors 2.'
•  Use a high value of viscosity.
•  Use Newton-Krylov type linear solvers (do not use multigrid), and set the
minimum number of iterations to 5 (minIter 5) for all variables.
•  Use a CFL number of the order of 0.2 and set deltaT to a low value in order to
avoid jumps during the first iteration.
My simulation is always exploding
•  This is one of a hell stable numerical scheme. However is first order accurate.
•  If this does not work, you should check your boundary conditions, initial conditions,
physical properties and model properties.
•  You should also know the limitations of the solver you are trying to use, maybe the
solver is not compatible or can not solve the physics involve.
functionObject
•  When using utilities (e.g. mirrorMesh), do not use functionObject as they might
cause some problems. Yon can run the utility as follows,
•  utility_name –noFunctionObjects
Do this only if you are not interested in computing the actual functionObject
•  If you forget to use a functionObject, you do not need to re-run your simulation.
You can use the utility execFlowFunctionObjects, this utility will compute the
functionObject values from the saved solutions. Do not forget to add the new
functionObject to your controlDict before using
execFlowFunctionObjects.
•  Remember, functionObject can be temporarily disabled by launching the solver

(or utility) with the option –noFunctionObjects.
On the incompressible solvers
•  I am going to be really loud on this.
•  For those using the incompressible solvers (icoFoam, simpleFoam, pisoFoam,

pimpleFoam), I want to remind you that the pressure used by these solvers is the
modified pressure or
p
P =
So when visualizing your results do not forget to multiply the pressure by the density
in order to get the physical pressure. This will not made much different if you are
working with air, but if you are working with water, you will notice the difference.
Updating OpenFOAM®
•  For those who like to always get the latest version of OpenFOAM®, I will give you a
word of advise.
•  Before changing to the newest version, run a series of test cases just to check the
consistency of the results.
•  It has come to my attention (and maybe yours as well), that the guys of OpenFOAM®
might change (and will change) something in the new releases and you might not get
the same results.
•  No need to say that very often the syntax change from version to version.
•  Personally speaking, I have a test matrix of five cases (involving different physics and
models). So before deploying the new version, I always check if I get the same
results. This is part of the continuous and arduous task of verification and validation.
•  A new version of OpenFOAM® not necessary is a guarantee of innovation, and an

old version of OpenFOAM® is no guarantee of efficiency.
Best tip ever (and totally free)
•  I know I sound like a broken record on this, but try to always

get a good quality mesh.
•  Use accurate and robust numerical schemes (in time and

space).
•  At this point we all know what is a good quality mesh and

what is an accurate numerical scheme, if not, please read the
theory. You do not do CFD without understanding the theory
and the physics involve.
94'
Module 10
Module'10'*'Lecture'26' 1'
•  Some kind of conclusion,
•  Good mesh – good results.

•  Start robustly and end with accuracy.
•  Stability, accuracy and boundeness, play
by these terms and you will succeed.
That was only the tip of the iceberg
Now the rest is on you

•  Finally, we hope you have found this intensive week useful.
•  In addition, we hope to see you again in some of our advanced training
sessions:
•  Multiphase flows
•  Advanced meshing
•  Optimization
•  Turbulence Modeling
•  Advanced post-processing and scripting
•  And many more available on request
•  Besides consulting services, we also offer ’Mentoring Days' which are days
of one-on-one coaching and mentoring on your specific problem.
•  For more information, ask your trainer, or visit our website
http://www.wolfdynamics.com/
TGIF
&
TGIO
Enjoy OpenFOAM®
el fin!

OpenFoam Tips

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

OpenFoam Tips

Diunggah oleh

Hak Cipta:

Format Tersedia

Disclaimer

“This offering is not approved or

To view a copy of this license, visit

University of Genoa, DICCA

• And I hope not to see hands up.

• I know two or three things.

• Snug as a bug in a rug.

• Running my first OpenFOAM® case. • Before we start - Housekeeping issues.

• Controlling solution behavior and solution • Introduction to post-processing and scientific

• CFD simulation lifecycle.

Introduction to blockMesh and snappyHexMesh. • Getting convergence from scratch.

Helyx-os gui. • Hands-on tutorials.

(4:30 pm – 5:00 pm)

• Basics of C++ programming.

Tips and tricks. • OpenFOAM® documentation.

using external libraries.

• Numerical optimization and design of

• Surrogate based optimization for engineering

Linux for open source CFD

• A virtual machine distribution and an ISO distribution are available for

• By the way, in my personal copy I have many multi-physics, CFD, FEA,

• FYI, I regularly update the distributions.

• alias PTOFC='cd $PATH_TO_TUTORIALS'

• tar –zxvf file_name.tar.gz

• tar –zcvf file_name.tar.gz directory_name

• By the way, use the tutorials included in the training

Installing OpenFOAM® - Working on your own

• FYI, I do not like Ubuntu.

• To install OpenFOAM®, just follow the instructions given in

• If for any reason the instructions given in http://www.openfoam.org/ do

• You can find my instructions in the supplement slides.

As we will be working with the CFD simulation

CAD - 3D modeling - Surface modeling

* Note: precompiled binaries are available for these applications.

* Note: precompiled binaries are available for these applications.

Mesh manipulation tools

* Note: precompiled binaries are available for these applications.

STL files manipulation

* Note: precompiled binaries are available for these applications.

Note: precompiled binaries are available for these applications.

If you want to keep things to a minimum, install only:

• Introduce OpenFOAM® (this is the workhorse of the course).

• By the end of the week, help you to become an out-of-the-box

• But also, introduce you the building blocks to help you to

• By friday, you should also be able to make simple modifications

• Introduce you to CAD, meshing and post processing using

• Demystify the FVM in order to teach you how to choose the

• Give you some guidelines of how to assess mesh quality, and

• Do some post-processing and data analysis to get quantitative

• Address your doubts about the tools used and methods

• Not to confuse you at a higher level.

• Help you to get a degree?.

• No prior knowledge of the tools to be used (OpenFOAM®,

• A basic knowledge of CFD, scientific computing, and numerical

• For hands-on examples, you are required to bring your own

• By the way, I use OpenSUSE Linux distribution. But you are

• This is not a C++ course, so I will try to keep C++ programming

• This is not a course on Finite Volume Methods (FVM) -

• This is not a Linux system administration course, so I will try to

• I am doing this for your own convenience and keeping things

• Ask as many questions as you like and feel free to interrupt me

• Sometimes I have the tendency to go really fast in some issues,

the physics is yours.

• Based on this course, I am trying to write some lectures notes

•  And I hope not to see hands up.

•  I know two or three things.

•  Snug as a bug in a rug.

•  A virtual machine distribution and an ISO distribution are available for

•  By the way, in my personal copy I have many multi-physics, CFD, FEA,

•  FYI, I regularly update the distributions.

•  alias PTOFC='cd $PATH_TO_TUTORIALS'

•  tar –zxvf file_name.tar.gz

•  tar –zcvf file_name.tar.gz directory_name

•  By the way, use the tutorials included in the training

•  FYI, I do not like Ubuntu.

•  To install OpenFOAM®, just follow the instructions given in

•  If for any reason the instructions given in http://www.openfoam.org/ do

•  You can find my instructions in the supplement slides.

•  Introduce OpenFOAM® (this is the workhorse of the course).

•  By the end of the week, help you to become an out-of-the-box

•  But also, introduce you the building blocks to help you to

•  By friday, you should also be able to make simple modifications

•  Introduce you to CAD, meshing and post processing using

•  Demystify the FVM in order to teach you how to choose the

•  Give you some guidelines of how to assess mesh quality, and

•  Do some post-processing and data analysis to get quantitative

•  Address your doubts about the tools used and methods

•  Not to confuse you at a higher level.

•  Help you to get a degree?.

•  No prior knowledge of the tools to be used (OpenFOAM®,

•  A basic knowledge of CFD, scientific computing, and numerical

•  For hands-on examples, you are required to bring your own

•  By the way, I use OpenSUSE Linux distribution. But you are

•  This is not a C++ course, so I will try to keep C++ programming

•  This is not a course on Finite Volume Methods (FVM) -

•  This is not a Linux system administration course, so I will try to

•  I am doing this for your own convenience and keeping things

•  Ask as many questions as you like and feel free to interrupt me

•  Sometimes I have the tendency to go really fast in some issues,

•  Based on this course, I am trying to write some lectures notes

•  A help is needed and much appreciated. To help me, take a

•  The lectures notes are available with the course’s material in

•  Follow-up problems, questions and suggestions at

•  OpenFOAM® comes with many very powerful

•  OpenFOAM® comes with an user guide and

•  Read the user and programmer’s guide.

•  Also, with the course material you will find many

•  By the way, use the tutorials just for recreational,

•  The Doxygen manual

•  CFD-Online OpenFOAM® user discussion group

•  OpenFOAM® wiki (http://www.openfoamwiki.net).

•  OpenFOAM® website (http://www.openfoam.com/).

•  OpenFOAM® extend project

1.  OpenFOAM® brief overview

•  OpenFOAM® is first and foremost a C++ library used to solve

•  It comes with several ready-to-use or out-of-the-box solvers,

•  It is licensed under the GNU General Public License (GPL).

•  It is under active development, its capabilities mirror those of

•  It counts with a wide-spread community around the world

•  Collocated polyhedral unstructured meshes.

•  Second order accuracy in space and time. Many discretization

•  Pressure-velocity coupling via segregated methods (SIMPLE

•  But also coupled solvers are under active development.

•  It comes with it own mesh generation tools.

•  It also comes with many mesh manipulation and conversion

•  Meshes generated using many of the major mesh generators

•  All components implemented in library form for easy re-use.

•  Thermophysical models and physical properties for liquids

•  Transport/rheology models. Newtonian and non-Newtonian

•  Extensive turbulence modeling capabilities (RANS, SRS,

•  Lagragian particle methods (DSMC, MD).

•  Discrete particle modeling (DPM, MP-PIC).

•  VOF method for multiphase flows .

•  Interphase momentum transfer models for multiphase flows.

•  Combustion, flame speed, chemical reactions, porous

•  Basic solvers: Laplace, potential flow, passive scalar

•  Incompressible and compressible flows: segregated

•  Heat transfer modeling capabilities: buoyancy-driven flows,

•  Multiphase flows: Euler-Euler, VOF for free surfaces,

•  Combustion and fire dynamic solvers.

•  Stress analysis, electromagnetics, acoustics, MHD, fluid-

•  OpenFOAM® is designed to be a flexible and programmable

•  New solvers can be easily implemented using OpenFOAM®

•  Users have total freedom to modify existing solvers or use them