CFD with OpenSource software

A course at Chalmers University of Technology

Taught by Håkan Nilsson

Project work:

Modeling high-pressure die casting: A

tutorial

Developed for OpenFOAM-2.3.1

Requires: ParaView, Salome

Author: Peer reviewed by:

Sebastian Kohlstädt Barlev Nagawkar
[email protected] Håkan Nilsson

Disclaimer: This is a student project work, done as part of a course where OpenFOAM and some
other OpenSource software are introduced to the students. Any reader should be aware that it
might not be free of errors. Still, it might be useful for someone who would like learn some details
similar to the ones presented in the report and in the accompanying files. The material has gone
through a review process. The role of the reviewer is to go through the tutorial and make sure that
it works, that it is possible to follow, and to some extent correct the writing. The reviewer has no
responsibility for the contents.

January 16, 2016

Learning outcomes

The reader will learn:

ˆ use an m4 script to create the blockMeshDict more easily

ˆ which options OpenFOAM offers for setting the mesh into motion

ˆ model a the moving piston in the shot sleeve by setting up a moving mesh.

ˆ display the results using ParaView.

ˆ how to create a simple geometry using the open source CAD-program Salome. (Appendix)

ˆ creating a decent mesh by using two alternative meshing tools: the Salome mesh workbench
as well as the OpenFOAM embedded tool snappyHexMesh. (Appendix)

1
Contents

1 Modeling high-pressure die casting 3

1.1 Tutorial description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 High-pressure die casting basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Tutorial start – preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Mesh generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Case setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.1 Boundary and initial conditions, numerical schemes . . . . . . . . . . . . . . 14
1.5.2 Make the mesh moving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Running the case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7 Post processing in ParaView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7.1 Mesh movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7.2 Fluid flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.8.1 Summary of the covered topics and experiences . . . . . . . . . . . . . . . . . 26
1.8.2 Outlook on further activities in the area . . . . . . . . . . . . . . . . . . . . . 26

A Additional material 28
A.1 CAD generation using Salome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2 Other mesh creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2.1 Using the mesh tools in Salome . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2.2 Creating a mesh using snappyHexMesh . . . . . . . . . . . . . . . . . . . . . 44

2
Chapter 1

Modeling high-pressure die casting

1.1 Tutorial description

High-pressure die casting is a very cost-efficient process that is therefore widely used in the auto-
motive and other industry. However, due to its complex nature, it up to this date appears to be
not thoroughly enough investigated from a scientific – in particular a modeling – point of view. The
high Reynolds and Weber numbers it bears have so far limited the success of modeling it thoroughly.
There are a couple of proprietary solvers in the market, yet their validity is hard to prove as the
everything that takes place inside the die, which can weigh up to 30t, remains a black box to some
extend. This tutorial aims to shed some light on these processes and claims to provide the reader
some ideas of how to set up a model for gaining some insights of the process. Due to the scientific,
i.e. reproduceable nature of scientific work, an emphasize is put on the use of open source software
only. It should hence be not be hard for any reader to redo the work himself and by doing so prove
the author right or wrong.
The tutorial includes the entire process chain starting with the CADing and ending with the post-
processing. Along the way, we will mesh the created geometry, select suitable boundary conditions
and numerical schemes. Particular regard is given to model the shot sleeve and thus how to the
setup everything that is needed for setting the mesh into motion.

3
1.2. HIGH-PRESSURE DIE CASTING BASICS CHAPTER 1. MODELING HPDC

1.2 High-pressure die casting basics

The process of high-pressure die casting is quite different from what most people think of when they
hear the word casting. Since this is also a tutorial for a course that comes more from a CFD/applied
mechanics background, it will be quite helpful to introduce some of its basics. High-pressure die
casting as opposed to gravity mold casting, which is more familiar to most people, involves the usage
of very big and very complicated machines. An engineering drawing of such a machine is outlined
in figure 1.1.

locking unit casting unit

hydraulic
moving aggregate
fixed plunger
clamping plate
plate
unit ejector unit tie bar

Figure 1.1: The layout and components of a high-pressure die casting machine according to DIN 24480.

We can see in this figure that the casting machine mainly consists of 3 units each serving a
particular purpose. The first unit from left to right is the clamping unit. Its purpose is to clamp
the two halves of the die properly together when the casting material is shot into it and the after
pressure is applied. Going further right, one recognizes the locking unit which is responsible for the
movement of the moving half of the die. In die casting always a fixed platen and a moving platen
come together with the corresponding parts of the die/mold mounted on them. The far right part
of the picture resembles the casting unit of the casting machine. Here we can also find the part of
the machine which will be looked upon more thoroughly during this project report, the shot sleeve.
The shot sleeve is a hollow cylinder that is attached to the plunger (see figure 1.1) and the
plunger slides in it. The hollow tube it forms inside connects the front of the plunger with the
gating system leading to the die. Propelled by the hydraulic aggregate, the plunger moves the melt
that was formerly charged into the shot sleeve, which can also be referred to as filling chamber,
towards the mold. For further illustration of the processes that happen next then one can have
closer look at the following figure 1.2.
In there, the three different process steps during casting are illustrated.
The major emphasis, however, shall be put in the processes and fluid mechanics phenomena that
happen inside the shot sleeve in the project report as this is the area of the casting that requires
the most attention from a CFD point of view. The reason for this is the face that the hollow
space inside the filling chamber changes its geometry quite significantly during the process as the
movement of the plunger reduces the hollow space inside there and by doing so, moves the melt
forward. The velocity of the plunger in the two different phases during casting is quite important for
the later outcome in terms of castings’ quality. As the three pictures in the following figure (figure
1.3) illustrate, there is only one velocity of the plunger in phase one that will prevent the melt wave
from crashing but at the same time prevent it from sending out waves towards the die. The three
figures show how the melt’s flow pattern emerges when moving the plunger at different velocities:

4
1.2. HIGH-PRESSURE DIE CASTING BASICS CHAPTER 1. MODELING HPDC

(a) pre-filling

(b) die-filling

(c) after-pressure

Figure 1.2: Three phases of die filling.

(a) velocity of the plunger in phase 1 is too slow, (b) velocity of the plunger is phase 1 is correct,
(c) velocity of the plunger in phase 1 is too fast.

Figure 1.3: Impact of increasing plunger propagation. The velocity increases from the left to the right
picture.

5
1.3. TUTORIAL START – PREPARATION CHAPTER 1. MODELING HPDC

1.3 Tutorial start – preparation

This tutorial will be based on the official tutorial sloshingTank2D for the compressibleInterDyMFoam
solver which is part of the official OpenFOAM distribution. I will use the OpenFOAM version 2.3.1
for all the modeling in the tutorial. The reason why this tutorial was picked here is that the same
solver will be used later on as well and the tutorial comes along with all the files that are needed for
the solver already. My ~/.bashrc is set up to use the alias openfoam231 for executing the command
source /opt/openfoam231/etc/bashrc. Less technically speaking this means that in the setup for
this tutorial openfoam231 will start the OpenFOAM environment. The name of my case folder
will be modelingHpdcShotSleeve and it will be located in $FOAM_RUN/. So the full path to the
case directory will be $FOAM_RUN/modelingHpdcShotSleeve. Let us now commence the tutorial by
opening a terminal and type the following. All the commands are also available in a file named
listOfCommandsForCopyAndPast inside the accompanying case files. Copying the commands from
there may be a bit less cumbersome as particularly the sed commands that come later are known
to cause problems.

openfoam231
mkdir $FOAM_RUN/modelingHpdcShotSleeve
tut
cd multiphase/compressibleInterDyMFoam/ras/sloshingTank2D/
cp -r * $FOAM_RUN/modelingHpdcShotSleeve
cd $FOAM_RUN/modelingHpdcShotSleeve

After doing this we will have a valid case in the newly created case folder. However, neither
the geometry nor the boundary conditions have anything to do with a shot sleeve in high-pressure
die casting. The following sections of this report will therefore modify the particular files in order
to create the geometry with the required boundary conditions. It will begin with the mesh in
the following section. In the following sections I will not reinitialize the OpenFOAM environment
again and also not navigate to the case directory again. So make sure you repeat the first and last
command in the listing above if you close your terminal in between or navigate for whatever reason
to another directory.

6
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

1.4 Mesh generation

Open the Allrun script in this tutorial and see in line 7 of the Allrun script that an m4 script is
used to create the file constant/polyMesh/blockMeshDict. You can access the file via

vi Allrun

display the line numbers by pressing : and then typing set number and Enter. For now, however,
no adjustments are to be made here and we can close the file by pressing : and typing q and enter.
The fact that the mesh is created by using the an m4 script requires us to do the necessary changes
there. The approach that was chosen here differs a bit from the one that was preferred in the course
where almost everything was done from the terminal. Here we also use the editor gedit for modifying
some of the files. The necessary steps to be done will be shown in the text. Everything that has
to be typed into the terminal or something that has to be copied, it will be inside the verbatim
environment.
Before we will finally start to modify the m4-file, let us compare first the geometry that is
created in the official with the geometry that shall be created during this report’s tutorial. We can
for example do that by typing

m4 constant/polyMesh/blockMeshDict.m4 > constant/polyMesh/blockMeshDict

blockMesh
paraFoam -block

to the terminal. paraFoam -block evaluates the blockMeshDict and sketches the outline of the
mesh in ParaView. Make sure you have selected another background color than white or if not do
so now, as the outline will otherwise not be displayed. With default view settings the screen in
ParaView should appear similar to figure 1.4.

Figure 1.4: The outline of the blockMesh in the basic tutorial.

The geometry consists of 3 separate blocks that are automatically joined together as outlined in
the OpenFOAM user guide if the same vertices are used and the faces overlap. You may now close
the ParaView window we just opened. Figure 1.5 gives an overview with more detailed labeling
of the vertices. Please note that according to the coordinate system, the geometry is oriented in a
way that we look upon its front, i.e. referring to the coordinate system we look into the opposite
direction of the x-vector. This was chosen as the structure of the m4-dictionary chose this orientation
for labeling
Please open the m4-dictionary for the basic tutorial now
gedit constant/polyMesh/blockMeshDict.m4

7
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

luct, 3, 11 ruct, 7, 15

block 2

luc, 2, 10 ruc, 6, 14

block 1 y

llc, 1, 9 rlc, 5, 13
block 0
llcb, 0, 8 rlcb, 4, 12

Figure 1.5: The labeling of the vertices.

and look into the lines. You can see that the basic structure of this macro file. After the usual
OpenFOAM header it starts with a part where general m4 macros are defined (line 16), followed by
a part of user-defined parameters (line 29). After the derived parameters (line53) the parametric
description starts (from line 75). This is the part where the information that is relevant for the
blockMesh utility later will be put. The basic idea behind the m4-dictionary is that the user
specifies only a certain set of values that fully constrain the domain he wants to create the mesh
in, while all the other parameters are derived from these basic input variables. Another smart idea
in the idea of creating the blockMeshDict with m4-macros is the way of addressing the different
vertices with abbreviated names as it is done here an shown in figure 1.5.
This functionality is maintained most notably by the command in line 21 of the m4-dictionary:
define(vlabel, [[// ]Vertex $1 = VCOUNT define($1, VCOUNT)define([VCOUNT], incr(VCOUNT))]).
This line defines a function that whenever it is called returns a string that starts with ”// Vertex”
then puts the value with which it was called next ($1 represents that), then followed by an ”=” and
the value that VCOUNT currently has. It then additionally defines the funtion that number of
the vertex – which is represented by VCOUNT in this case – is returned whenever this vertex is
addressed by its label.
Bearing this in mind the lines starting at line 77 and below become understandable more easily.
Line 101 for example creates block 0 with the help of the other previously defined hex2D-macro in
line 23 where to each of the provided parameters is added to a b or an f, respectively depending on
whether the vertex that is part of the front (f) or the back (b) face.
Looking further down, one can also see that the patches are also assigned by addressing the
vertices by their labels. For example in line 120 of the m4-dictionary assigns the patch walls to the
face that is defined by the vertex pair llcb (i.e. vertex 0 and 8) and the vertex pair rlcb (i.e. vertex
4 and 12; compare figure 1.5).
After these explanatory remarks, we may now create our own m4-blockMeshDict. It is for this
purpose always a good start to do a hand-sketch on paper in order to think of proper labeling of the
vertices and consider how many independend coordinates one may need. This was done in figure
1.6.
As one can see in the figure, the domain shall also be constructed from three separate blocks.
Block 0 shall later be the region where the cells move, block 1 is the part of the shot sleeve that is
fixed and block 2 is the part that includes the outlet and the transition to the gating system of the
casting. One can also see in the figure how the different vertices in the domain were labeled and at
which positiions they were placed. Table 1.1 gives an overview of the chosen abbreviations and why
they were chosen in this particular way.

8
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

YOutlet
ol, 4, 12 or, 7, 15
YCylUp ibul, 3, 11block 2
pu, 1, 9 ibur, 6, 14
y

block 1
block 0 z

YCylDown
pd, 0, 8 lr, 5, 13
ibll, 2, 10
ZPiston ZboundaryMovingFix ZEndOfSleeve

Figure 1.6: The labeling of the vertices and variables for the m4-blockMeshDict for the shot sleeve.

Abbreviation Explanation
pd piston down: the lower vertice at the boundary towards the piston
pu piston up: the upper vertice at the boundary towards the piston
ibll internal boundary lower left
ibul internal boundary upper left
ol outlet left
lr lower right
ibur internal boundary upper right
or outlet right
YOutlet the y-level where the vertices of the outlet are
YCylUp the upper y-level where the shot sleeve/cylinder ends
YCylDown the lower y-level where the shot sleeve/cylinder starts
ZPiston The z-level where the boundary towards the piston is
ZBoundaryMovingFix the z-level where fixed and moving cells are connected
ZEndOfSleeve the z-level where the shot sleeve ends

Table 1.1: Explanation of the abbreviations in the figure 1.6 above.

As the reader can see in figure 1.6, 3 independent levels were needed in the y- and z-direction:
YOutlet, YCylUp, YCylDown as well as ZPiston, ZBoundaryMovingFix and ZEndOfSleeve. We
will use these coordinates of the levels and one coordinate each for the front and the back later in
the m4-dictionary to fully constrain all the vertices that shall be created. We will also use the labels
that were assigned to the particular vertices in figure 1.6.
We start this process by copying the original m4-dictionary and rename it to myblockMesh-
Dict.m4 and open it in gedit. This option was chosen to always have a backup copy present if we
mess things up.

cp constant/polyMesh/blockMeshDict.m4 constant/polyMesh/myblockMeshDict.m4
gedit constant/polyMesh/myblockMeshDict.m4

In the first 28 lines that contain the header and the general m4 macros we don’t need to do any
changes. In the section User-defined parameters, we however have to put in our own variables now.
We do this by replacing the content between line 31 and line 50 with the following content. So please
delete those lines and paste the following lines into the file from the following listing:

convertToMeters 1e-3; //because engineers prefer it in mm

define(thickness, 1.0) // thickness of shot sleeve slice (x-direction)

define(sSDiameter, 60) // height of shot sleeve slice (y-direction)/diameter of shot sleeve
define(lengthOfMovSleeve, 280) // length of moving area in shot sleeve (z-direction)

9
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

define(lengthOfFixSleeve, 20) //lenght of fixed area in shot sleeve (z-direction)

define(outletHeight, 20) //height of the outlet "chimney" (y-direction)

define(Nt, 1) // Number of cells in the length (1 for 2D) (x-direction)

define(NmA, 37) // Number of cells in the moving area (z-direction)
define(NHoSS, 15) // Number of cells in the height of the shot sleeve (y-direction)
define(NfA, 5) // Number of cells in the fixed area (z-direction)
define(NOH, 10) // Number of cells in the height of the outlet "chimney" (y-direction)

Due to the replacing, your next section in the m4-dictionary (derived parameters) should now start
at line 48 with the heading of the same name. If it doesn’t add some blank lines in between or the
line counting will not match with the report.
The next section we need to modify is the derived parameters section. To do that replace the
content between line 50 and line 67 with the lines in the following listing.

define(YCylUp, calc(sSDiameter/2.0)) //defining the 3 levels in y-direction

define(YCylDown, calc(-sSDiameter/2.0)) //as shown in the figure in the report
define(YOutlet, calc(sSDiameter/2 + outletHeight))

define(ZPiston, calc(-lengthOfMovSleeve - lengthOfFixSleeve)) //defining the 3 levels in z-direction

define(ZboundaryMovingFix, -lengthOfFixSleeve) //as shown in the figure in the report
define(ZEndOfSleeve, 0)

define(Xf, calc(thickness/2.0)) // Xf for x-coordinate of the front

define(Xb, calc(Xf - thickness)) // // Xb for x-coordinate of the back

After you have done that, the next paragraph in the m4-dict should start with ”//Parametric
description” on line 63. If necessary add or remove some white space to match it.
The next part is the definition of the vertices for this reason replace the content enclosed between
line 65 (”vertices”) and line 84 ”);” with the next listing’s content.

vertices
(
(Xb YCylDown ZPiston) vlabel(bpd)
(Xb YCylUp ZPiston) vlabel(bpu)
(Xb YCylDown ZboundaryMovingFix) vlabel(bibll)
(Xb YCylUp ZboundaryMovingFix) vlabel(bibul)
(Xb YOutlet ZboundaryMovingFix) vlabel(bol)
(Xb YCylDown ZEndOfSleeve) vlabel(blr)
(Xb YCylUp ZEndOfSleeve) vlabel(bibur)
(Xb YOutlet ZEndOfSleeve) vlabel(bor)

(Xf YCylDown ZPiston) vlabel(fpd)

(Xf YCylUp ZPiston) vlabel(fpu)
(Xf YCylDown ZboundaryMovingFix) vlabel(fibll)
(Xf YCylUp ZboundaryMovingFix) vlabel(fibul)
(Xf YOutlet ZboundaryMovingFix) vlabel(fol)
(Xf YCylDown ZEndOfSleeve) vlabel(flr)
(Xf YCylUp ZEndOfSleeve) vlabel(fibur)
(Xf YOutlet ZEndOfSleeve) vlabel(for)
);

10
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

As you can see, we only use the in total 8 previously definded coordinates for fully constraining
the entire domain. The 8 coordinates are the 6 levels shown in figure 1.6 in y- and z- direction plus
one coordinate for the front and one for the back. After this replacement the next section (”blocks”)
should start at line 86.
Next we define the blocks with our just defined vertices. For this purpose replace the paragraph
that starts with ”blocks” on line 86 and ends with ”);” on line 102 with the lines from the following
listing.

blocks
(
// block0
hex2D(pd, pu, ibul, ibll)
(NHoSS NmA Nt)
simpleGrading (1 1 1)

// block1
hex2D(ibll, ibul, ibur, lr)
(NHoSS NfA Nt)
simpleGrading (1 1 1)

// block2
hex2D(ibul, ol, or, ibur)
(NOH NfA Nt)
simpleGrading (1 1 1)
);

After this replacement the next section (”patches”) starts at line 104 as before, because the paragraph
the pasted into our myblockMeshDict.m4 was equal in line numbers to the one we overwrote. Make
sure however, you resemble the same amount of white space as this might get lost when copying
from the PDF-file.
Another interesting thing to bring to the readers attention is that the blocks we create do have
their own coordinate system, which is defined by the order in which vertices are introduced, not the
overall coordinate system, which was for example shown in 1.6. When we create block 0 for example,
we go first from pd to pu. Therefore this is our x1 direction. This means that the first entry in
the following list, where we define the number of cells to be created in this direction, refers to this
direction, which is actually the y-direction in the domains global coordinate system (compare figure
1.6).
The last section to be edited in this dictionary is the ”patches” section starting at line 104 and
ending at line 131. Modify it by replacing it with the following content.

boundary
(
slipWalls
{
type wall;
faces
(
quad2D(pd, ibll)
quad2D(ibul, pu)
);
}
movingWalls
{
type wall;
faces

11
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

(
quad2D(pu, pd)
);
}
fixedWalls
{
type wall;
faces
(
quad2D(ibur, or)
quad2D(ol, ibul)
quad2D(ibll, lr)
quad2D(lr, ibur)
);
}
outlet
{
type patch;
faces
(
quad2D(or, ol)
);
}
frontAndBack
{
type empty;
faces
(
frontQuad(pd, ibll, ibul, pu)
frontQuad(ibll, lr, ibur, ibul)
frontQuad(ibul, ibur, or, ol)
backQuad(pd, ibll, ibul, pu)
backQuad(ibll, lr, ibur, ibul)
backQuad(ibul, ibur, or, ol)
);
}
);

If you did everything as stated, the closing bracket and semicolon should be at line 155 in your
myblockMeshDict.m4. If it doesn’t check the white space. We are now ready for having m4 write
our blockMeshDict and look at it in gedit to see how m4 wrote the blockMeshDict based on the
commands we supplied. We do that by saving your myblockMeshDict.m4, closing gedit and by
typing the following command to the terminal:

m4 constant/polyMesh/myblockMeshDict.m4 > constant/polyMesh/blockMeshDict

gedit constant/polyMesh/blockMeshDict

Browse through the lines and see how m4 picked the particular numbers for the vertices that we
addressed with the previously definded labels (compare figure 1.6). If you’re done close gedit and
test our work by viewing the outline of the to be created mesh in ParaView.

paraFoam -block

If we did everything appropriately the outline should resemble the sketch in figure 1.6. Our last step
will of course be to create the mesh from our blockMeshDict.

12
1.4. MESH GENERATION CHAPTER 1. MODELING HPDC

blockMesh

After this section, our mesh is completely created as we like it and we are ready to proceed with
the next section, the setup of the initial and boundary conditions.

13
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

1.5 Case setup

1.5.1 Boundary and initial conditions, numerical schemes
Due to the focus of this tutorial being the mesh motion, only standard boundary conditions were
chosen. As the case files are distributed along with this project report the details of each file will
not be outlined here. Because this would basically only lead to paraphrasing the content. Except
for the outlet and movingWalls, all boundaries were chosen as walls with fixedValue (0 0 0) there
for velocity and zeroGradient for the outlet. For all the other parameters also mainly zeroGradient
conditions were chosen for all the boundaries. The pressure however at the outlet was fixed.
The commands/directions on how to modify the files specifically are given in the following.
The reader should proceed with caution when copying and pasting the commands from the listings
directly into the terminals as there may occur errors during copying and pasting from pdf files. The
single quote signs (’) in the sed commands particularly often cause problems. Due to this fact and for
the reader’s convenience an additional file named listOfCommandsForCopyAndPaste is also supplied
in the accompanying files on the webpage. It is located inside the modelingHpdcShotSleeve case.
Please copy the commands from there for smoother progress. First rename the alpha.water.org in
alpha.melt.org, rename the patches, and delete the 2nd patch entry and rename the other two:

mv 0/alpha.water.org 0/alpha.melt.org
sed -i '27,30d' 0/alpha.melt.org
sed -i 's/front/frontAndBack/g' 0/alpha.melt.org
sed -i 's/walls/"(movingWalls|fixedWalls|outlet|slipWalls).*"/g' 0/alpha.melt.org

For the 0/p file the necessary changes are very similar, hence the commands to look a lot alike.
We however also have to change the pressure of the internalField. For changing the 0/p file type
the following to the terminal:

sed -i '27,30d' 0/p

sed -i 's/front/frontAndBack/g' 0/p
sed -i 's/walls/"(movingWalls|fixedWalls|outlet|slipWalls).*"/g' 0/p
sed -i 's/uniform 1e6/uniform 1e5/g' 0/p

Also almost the same commands have to be applied for the p_rgh file. With an additional
addition that the outlet has to be defined as totalPressure condition.

sed -i '27,30d' 0/p_rgh

sed -i 's/front/frontAndBack/g' 0/p_rgh
sed -i 's/walls/"(movingWalls|fixedWalls|slipWalls).*"/g' 0/p_rgh
sed -i 's/uniform 1e6/uniform 1e5/g' 0/p_rgh

The modification for the outlet patch contains several lines, which is why it is probably easier to
simply copy and paste it from the listing into the file opened in gedit.

gedit 0/p_rgh

and copy and paste the following lines between lines 22 and 23 in the file.

outlet
{
type totalPressure;
p0 uniform 1e5;
U U;
phi phi;
rho rho;

14
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

psi none;
gamma 1;
value uniform 0;
}

The next file to edit is the T file. Once more quite similar to the ones before:

sed -i '33,36d' 0/T

sed -i 's/front/frontAndBack/g' 0/T
sed -i 's/walls/"(movingWalls|fixedWalls|slipWalls|outlet).*"/g' 0/T

The last file except for the pointMotionUz file, which will be addressed in the following section,
that must be modified is the U file. For this, we do the following:

sed -i '27,30d' 0/U

sed -i 's/front/frontAndBack/g' 0/U
sed -i 's/walls/movingWalls/g' 0/U

For the boundary conditions of the outlet as well as fixed and slipWalls the modifications are one
more quite spacious, which is why copying and pasting will most likely be easier. Therefore, please
open the U file with gedit

gedit 0/U

and copy the following content and insert it after line 22.

outlet
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}
"(slipWalls|fixedWalls).*"
{
type fixedValue;
value uniform (0 0 0);
}

At this point we should have made all the necessary changes to the files in the 0 folder except
for the mesh motion which comes later. We can now move on to the files in the constant directory.
Lets start with the g file, where only one small modification has to be made due to our altered mesh.

sed -i 's/( 0 0 -9.81 )/( 0 -9.81 0 )/g' constant/g

A similar task is to be done for the thermophysicalProperties and transportProperties file.

The change is the same in both so it can be done together. The thermophysicalProperties.water
file doesn’t need to be changed but, we must rename it.

sed -i 's/water/melt/g' constant/thermophysicalProperties constant/transportProperties

mv constant/thermophysicalProperties.water constant/thermophysicalProperties.melt

No changes have to be made in the RASProperties, turbulenceProperties and thermophysicalProperties.air

files. All the necessary changes have now been described. The constant/polyMesh folder does not
need to be addressed at this point as the changes there for the blockMeshDict.m4 file were already
thoroughly described in the mesh generation section. The physical reason why only so few changes
were necessary is that for accuracy aim of this tutorial the material properties of melt at high
temperature can be assumed as similar to water at ambient conditions.
We can thus now move on to the system folder.

15
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

In the controlDict we can remove all the lines after 49, because we don’t want to run function
objects and also with fixed time step. We then additionally have to change the adjustableTimeStep
entry to no and also change endTime to 0.25, delTaT to 1e-5, writeControl to timeStep, writeIntervall
to 500, writePrecision to 8 and timePrecision to 10.

sed -i '50,96d' system/controlDict

sed -i 's/adjustTimeStep yes/adjustTimeStep no/g' system/controlDict
sed -i 's/40/0.25/g' system/controlDict
sed -i 's/0.0001/1e-5/g' system/controlDict
sed -i 's/adjustableRunTime/timeStep/g' system/controlDict
sed -i 's/writeInterval 0.05/writeInterval 500/g' system/controlDict
sed -i 's/writePrecision 6/writePrecision 8/g' system/controlDict
sed -i 's/timePrecision 6/timePrecision 10/g' system/controlDict

The fvSchemes file is the easiest to change. We simply have to exchange water for melt by using
the same command as above.

sed -i 's/water/melt/g' system/fvSchemes

The changes in the fvSolution file are the most significant. First we have once again to replace
water with melt. We secondly have to add large chunks of code, which is why it was preferred to do
it once more using gedit.

sed -i 's/water/melt/g' system/fvSolution

gedit system/fvSolution

and add the following lines to the code by inserting it after line 101.
UFinal
{
solver smoothSolver;
smoother GaussSeidel;
tolerance 1e-06;
relTol 0;
nSweeps 1;
}

cellMotionUz
{
solver PCG;
preconditioner DIC;
tolerance 1e-08;
relTol 0;
}
After this save and close gedit. This part of the code has to be added because different from the
official tutorial that uses a function for a predefined mesh motion, our mesh shall be moved due to
applied boundary conditions. This is why the solver needs to be told a way of how to solve for this
mesh motion.
The last dictionary in the system folder is the setFieldsDict. The first step once more is to
replace water with melt. After that we also have of course to modify the dimensions of the box for
which we want to set the alpha field value.

sed -i 's/water/melt/g' system/setFieldsDict

sed -i 's/( -100 -100 -100 ) ( 100 100 0 )/( -0.03 -0.03 -0.3 ) ( 0.03 0 0 )/g' system/setFieldsDict

The decomposeParDict in the system folder can be removed as we don’t need it.

16
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

rm system/decomposeParDict

If one additionally wants to change the Allrun and Allclean script as well, one can of course
also easily do that.

sed -i 's/water/melt/g' Allrun Allclean

sed -i 's/blockMeshDict.m4/myblockMeshDict.m4/g' Allrun

After this section all the necessary files in $FOAM_RUN/modelingHpdcShotSleeve should be pre-
pared apart from the ones necessary for the mesh motion. This will be addressed in the following
section.

1.5.2 Make the mesh moving

General remarks about the setup and solver
The course of this section will be as before in the preceding sections where general knowledge on
how the particular tools work will be presented in this subsection. After that all the necessary
instructions are given to transform the sloshingTank2D case into this shot sleeve case. So, if the
reader is interested only in the recipe for setting up the case, he may skip this section.
If one wants to implement a moving mesh in OpenFOAM , an abundant number of solvers for
doing so already exists. One can identify them by the three characters DyM in their particular name.
The expression DyM, however does only mean that the mesh undergoes changes while the solver is
running. It does, however, not tell anything about the actual solver, i.e. the way of solving/executing
this particular mesh motion. The solving of the mesh motion will occur always before the solving of
the actual fluid mechanics quantities. The proof for this will be given in the following text. As an
example, an excerpt from the logfile of compressibleInterDyMFoam is shown in the following listing:

Courant Number mean: 5.9863984e-05 max: 0.00040809301

Time = 1.6e-05

DICPCG: Solving for cellMotionUz, Initial residual = 1.0161082e-08, _

Final residual = 4.9577885e-10, No Iterations 1
Execution time for mesh.update() = 0.02 s
MULES: Solving for alpha.melt
Liquid phase volume fraction = 0.52174527 Min(alpha1) = 0 Min(alpha2) = -3.5527137e-15
MULES: Solving for alpha.melt
Liquid phase volume fraction = 0.52174554 Min(alpha1) = 0 Min(alpha2) = -3.5527137e-15
MULES: Solving for alpha.melt
Liquid phase volume fraction = 0.52174581 Min(alpha1) = 0 Min(alpha2) = -3.7747583e-15
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for T, Initial residual = 0.00020648579, Final residual = 6.0446425e-12, \
No Iterations 1
min(T) 299.99945
GAMG: Solving for p_rgh, Initial residual = 2.9243664e-05, Final residual = 2.8329781e-12, _
No Iterations 1
max(U) 1.9903874
min(p_rgh) 99839.893
GAMGPCG: Solving for p_rgh, Initial residual = 3.1842563e-08, _
Final residual = 1.990546e-24, No Iterations 1
max(U) 1.9926688
min(p_rgh) 99839.893
ExecutionTime = 1.49 s

17
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

In the listing above, after the initial lines that tell the observer about the Courant number and
the current time step, one observes a line starting with DICPCG: Solving for cellMotionUz,.
This line, which was broken here for fitting reasons (shown by the \) indicates that the moving of
the mesh was calculated. One can also read this from the source code. If you open
gedit $FOAM_SOLVERS/multiphase/compressibleInterFoam/\
compressibleInterDyMFoam/compressibleInterDyMFoam.C
you will find the line

mesh.update()

in line 91 of the source code followed a couple of paragraphs that reads the updated mesh and
corrects and adjusts the fluxes and velocities. The particular solver with the DyM in its name will
upon execution search for the dynamicMeshDict, which is a text file located in the

<case dir>/constant/

folder. It is also the most important dictionary for implementation of the mesh motion as it controls
the basic parameters of the moving mesh. An example of the file’s content, the content that was
used for most of the computations in this tutorial is shown in the following listing.

/*openFOAM header */

...

dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solver velocityComponentLaplacian z;

velocityComponentLaplacianCoeffs
{
component z;
diffusivity directional ( 0 200 1 );
}

In this dictionary the solver looks for the keyword dynamicFvMesh and the following entry then
specifies the class of which the dynamic mesh will be an object of. So far there have been are the
options

6
(
dynamicInkJetFvMesh
dynamicMotionSolverFvMesh
dynamicRefineFvMesh
multiSolidBodyMotionFvMesh
solidBodyMotionFvMesh
staticFvMesh
)

available. The number and which options you have for this entry is rather easy to find out by
try and error or the infamous dummy trick. It basically means that you replace a dictionary entry

18
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

with a dummy (e.g. bananas) and try to start the solver. It will then complain about the wrong
entry and tell you which options you have. The existence of the next line, however, the one that
starts with motionSolverLibs, and which entry to put in there is much more difficult to determine.
If one for example comments that line out the output in the logfile will simply be

--> FOAM FATAL ERROR:

solver table is empty

From function motionSolver::New(const polyMesh& mesh)

in file motionSolver/motionSolver/motionSolver.C at line 116.

FOAM exiting

with no hint that a particular entry in the dynamicMeshDict is missing. If one is new to this
field of modeling moving meshes, it can be thus quite time consuming to figure out what to put
there. A look at the $FOAM_LIBBIN directory can at least give an overview of conceivably suitable
libraries. Besides the one chosen in the file pasted above, there are other options available.
Once you have put the suitable library there, the process of setting up the case becomes more
straight forward again. One can then e.g. apply the dummy trick again and find out which solvers
are available in the chosen library. The listing below gives an overview.

Valid solver types are:

7
(
displacementComponentLaplacian
displacementInterpolation
displacementLaplacian
displacementLayeredMotion
displacementSBRStress
velocityComponentLaplacian
velocityLaplacian
)

It will from then on also ask automatically about the missing parameters in the dictionary
as well as the files. In this case the velocityComponentLaplacian – which requests already upon
initialization the direction in which the movement of the mesh shall be calculated – was selected.
This is in this case the z-direction as outlined before in the section discussing the mesh setup in
blockMesh (compare 1.6).
The solver will then also ask for the particular entries inside the subdictionary velocityCompo-
nentLaplacianCoeffs that is shown towards the end of the file dynamicMeshDict (see above). It
appears to be that this entry in the subdictionary is somewhat redundant as it was already earlier
defined when the solver was initialized, i.e. during velocityComponentLaplacian z.
The diffusivity then tells the solver how the movement of the cells in the mesh is supposed to
propagate throughout the mesh domain. Directional here stands for a linear propagation from the
source and the factors here are 0 for the x-direction as in the 2D-cases this was the empty direction,
200 for the y-direction and 1 i.e. no scaling in the z-direction where the major deformation occurred.
In the first trials of the case setups the author put 0 for the y-direction as well, which appeared
to him as the intuitive choice. However, the solver runs much more stable if the value is chosen to
be higher and it did not have a visible effect on the outcome of the mesh movement as observed in
ParaView. In the standard OpenFOAM distribution the other options for the diffusivity that are
available are:

10

19
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

(
directional
exponential
file
inverseDistance
inverseFaceDistance
inversePointDistance
inverseVolume
motionDirectional
quadratic
uniform
)

The particular options shown above give already by their names some hint on how they move the
mesh. They can also easily be tried out with a simple case. inverseDistance for example compresses
the cells the more the further they are away from the specified patch.
Apart from the dynamicMeshDict that the compressibleInterDyMFoam solver needs the chosen
solver in the *Dict will then ask for different files. In case of the solver velocityComponentLaplacian
that is used for this tutorial, the file

$CASE_DIR/0/pointMotionUz

is needed. This is another dictionary that specifies the boundary conditions for the motion of the
points at the boundary of the domain as well as the internalField. The following listing shows
the example of this dictionary that was used to create the results shown later in the results section.

/* openFOAM header */
...
dimensions [0 1 -1 0 0 0 0];

internalField uniform 0;

boundaryField
{
slipWalls
{
type slip;
value uniform 1;
}
frontAndBack
{
type empty;
{
movingWalls
{
type fixedValue;
value uniform 1;
}
".*"
{
type fixedValue;
value uniform 0;
}
}

20
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

As one can easily understand from the above listing, the pointMotionUz file closely resembles
all the other dictionaries present in the 0-folder. It starts with the entry followed by the dimensions
which on can see belong to something velocity related as the the units are m s . The entry that follows
specifies the the internal field. This value is not of particular importance for the solver, so it was
just kept as copied from the tutorial.
The next entry then gives the values for the boundaries of the domain. As outlined in the
section about the mesh generation our domain consists of the five boundaries movingWalls, slipWalls,
fixedWalls as well as the outlet and frontAndBack because this is a 2D. As intuitively understandable
the slipWalls were assigned the slip condition, while the moving walls were given a fixedValue
condition of value 1 since it was the idea of this tutorial to model a plunger velocity of 1 m s .
The boundary conditions for frontAndBack were set to be of type empty as they usually are for
2D cases in OpenFOAM thus preventing the solver from solving in the third dimension. The other
boundaries outlet and fixedWalls were covered by the RegExp ”.*”. One can do that here as the
solver evaluates the dictionary files from top to bottom and thus will only enter this subdictionary
if no other subdictionary with the particular name has been inserted before.
With these files and the fvSolution and fvSchemes as well as the controlDict and the pre-
viously created mesh, the mesh motion case it now ready for running at least as far as the mesh
motion is concerned. This came in to be a very useful option in OpenFOAM as one can while setting
up the case determine whether occurring errors appear due to the crashing of the mesh solver or
are related to issues in solving the fluid mechanics equations. This can for example be of particular
importance when modeling of turbulence gets involved as turbulence models are also known to cause
instability during runtime. One can test whether the mesh without the flow behaves in the intended
way by navigating to the case directory, create the mesh (see the section about mesh creation) and
finally by typing
cd $FOAM_RUN/modelingHpdcShotSleeve
m4 constant/polyMesh/myblockMeshDict.m4 > constant/polyMesh/blockMeshDict
blockMesh
moveDynamicMesh
into the terminal window, in which an OpenFOAM environment has been initialized. The occurring
output is quite different from when running only the DyM-solver as the user can now see at runtime
that the calculated mesh is currently checked for quality. An example for the appearing output is
given in the following listing.

Time = 0.01927
DICPCG: Solving for cellMotionUz, Initial residual = 3.9692693e-08, _
Final residual = 7.2701455e-09, No Iterations 1
Point usage OK.
Upper triangular ordering OK.
Topological cell zip-up check OK.
Face vertices OK.
Face-face connectivity OK.
Mesh topology OK.
Boundary openness (3.5595098e-16 -1.876465e-18 -2.165152e-19) OK.
Max cell openness = 2.1176652e-16 OK.
Max aspect ratio = 7.0843306 OK.
Minimum face area = 2e-06. Maximum face area = 2.8337322e-05. Face area magnitudes OK.
Min volume = 7.9706994e-09. Max volume = 2.8337322e-08. _
Total volume = 1.72438e-05. Cell volumes OK.
Mesh non-orthogonality Max: 2.5119956 average: 0.1068763
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.022836038 OK.
Mesh geometry OK.

21
1.5. CASE SETUP CHAPTER 1. MODELING HPDC

Mesh OK.
ExecutionTime = 12.59 s ClockTime = 13 s

How to modify the necessary files for the tutorial

As it is the most important file, we will begin with the constant/dynamicMeshDict file. As the
ways that are used for moving the mesh are fundamentally different in both the official and this
tutorial, the easiest will be to open the dynamicMeshDictwith gedit

gedit constant/dynamicMeshDict

replace the content between the lines 18 and 37 with the following listing’s content.

dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solver velocityComponentLaplacian z;

velocityComponentLaplacianCoeffs
{
component z;
diffusivity directional ( 0 200 1 );
}

Since the official compressibleInterDyMFoam tutorial does not come along with a pointMotionUz
or similar file, please download the file from accompanying tutorial files (inside the 0 folder) and put
it into your 0 directory. If the reader wants to know more about the contents and why they were
chosen like the he can refer to the preceding section.

22
1.6. RUNNING THE CASE CHAPTER 1. MODELING HPDC

1.6 Running the case

The commands for running the case are fairly similar to all other OpenFOAM cases. One opens a
terminal sources the $WM_PROJECT_DIR/etc/bashrc and navigates to the case directory. Typing

m4 constant/polyMesh/myblockMeshDict.m4 > constant/polyMesh/blockMeshDict

blockMesh > log.blockMesh
cp 0/alpha.melt.org 0/alpha.melt
setFields > log.setFields
compressibleInterDyMFoam > log.compressibleInterDyMFoam
paraFoam

will run the case. All of my tutorial cases that involve terminal work do come along with a script,
where the user can also recapitulate the single steps to run the case. The results can then be viewed
paraFoam. For only calculating the mesh motion one has to type

m4 constant/polyMesh/myblockMeshDict.m4 > constant/polyMesh/blockMeshDict

blockMesh > log.blockMesh
moveDynamicMesh > log.moveDynamicMesh
paraFoam

to a terminal window in which the case directory (FOAM_RUN/modelingHpdcShotSleeve) is se-

lected and the $WM_PROJECT_DIR/etc/bashrc is sourced.

1.7 Post processing in ParaView

1.7.1 Mesh movement
As discussed in section 1.5.2 it is possible in OpenFOAM to calculate the mesh motion in the solver
independently from the flow solution. This was also done during this tutorial work in order to
present the results to the reader. The resulting pictures from ParaView can be seen in figure 1.7.

1.7.2 Fluid flow

Having done the calculations, one can visit the results in ParaView by typing paraFoam inside the
case directory into a terminal. After loading in all the data, on selects the alpha.melt field for display
and navigates to the shown time steps in order to see the results which are also displayed in figure
1.8.

23
1.7. POST PROCESSING IN PARAVIEW CHAPTER 1. MODELING HPDC

(a) at time 0 (b) at time 0.125

(c) at time 0.25

Figure 1.7: The deformation of the mesh due to the given parameters.

24
1.7. POST PROCESSING IN PARAVIEW CHAPTER 1. MODELING HPDC

(a) at time 0 (b) at time 0.125

(c) at time 0.25

Figure 1.8: The deformation of the mesh due to the given parameters.

25
1.8. CONCLUSION CHAPTER 1. MODELING HPDC

1.8 Conclusion
1.8.1 Summary of the covered topics and experiences
In this tutorial the reader should have seen some possibilities to do the entire process chain in CFD
with entirely open source software. A very simple geometry that was created with the help of an
m4 script and was set up as a moving mesh case in OpenFOAM . Particular regard was given to
the modifications compared to cases with static meshes. In the appendix: Salome, snappyHexMesh
and blockMesh were introduced and a tutorial for basic usage provided. In case of Salome for both
creating a geometry and meshing it. It was then shown how to simplify the use of the blockMeshDict
by making simple modifications.

1.8.2 Outlook on further activities in the area

Further activities in the field will be:

ˆ Test the solver setup for real world meshes (e.g. the meshes from the appendix) and check-
/improve stability.
ˆ Add layer addition and removal to the solver.

ˆ Add a turbulence model and test for stability.

ˆ Attach a real casting geometry to the shot sleeve and find out whether the previous and
cumbersome modeling of the shot sleeve is worth the effort, i.e. whether of not it impacts the
flow pattern in the die.

26
Study questions

1. Which line in the m4 file allows the user to refer to the vertices with labels?
2. How do you recognize that a solver is suitable for setting up a moving mesh case?
3. Which is the most important dictionary that is read by every solver that handles a moving
mesh?

4. How could one find out which libraries are available when looking for one that solves moving
meshes?
5. Where do you have to include the particular library for the mesh solver?
6. Which additional files in the 0-folder does the solver velocityComponentLaplacian need?

7. Which two ways does Salome offer for receiving directions (Appendix)?
8. What can you do using Salome if different areas of one face in the geometry are supposed to
belong to different boundary patches (Appendix)?
9. How do you tell snappyHexMesh which faces it shall assign which patch to (Appendix)?

27
Appendix A

Additional material

A.1 CAD generation using Salome

This section covers the preparation of the CAD-geometry that resembles a very simple casting
geometry: a cylinder with a box-like extension that resembles a shot sleeve and an outlet to the
gating system.
Salome is a software that is open source and freely available from its own internet representation
www.salome-platform.org.1 It is a platform that has a mainly French user base and is also supported
and used by several French multinational companies and the French government. Its main purpose
is the provision of a CAE pre- and post-processing software. If one wants to develop a deeper
knowledge of how to use Salome, it is recommended to study the tutorials on the salome webpage.
They are very good to follow and cover a lot of different areas.2 Upon start one has the option to
select from different workbenches. In this tutorial we will mainly use the CAD – or Geometry as it
is called in Salome – workbench and to some extend the Mesh workbench.
After starting Salome one finds the starting screen as seen in figure A.1. We can start a new
project/study by clicking on the icon in the upper left corner . One recognizes easily that the
main working area is in the middle. On top are the menu and icon panel. In the bottom one sees
a terminal for directly inputting Python code as Salome’s TUI/API can be commanded in Python.
Secondly, we must change to the geometry workbench. We can do this by clicking on the icon or
selecting geometry in the neighboring box. The basic key combinations for turning the object are
Ctrl and hold down the right mouse button and move the mouse and Ctrl and pressing the mouse
wheel translates the object. Ctrl and holding the left mouse and moving the mouse zooms.
We will here work with the Salome GUI, but Salome is also designed to work with Python script-
ing (TUI). For each operation presented for the GUI, the corresponding TUI command is also sup-
plied. In the accompanying files, you can also find the Python script salomeScriptCreateShotSleeve.py
in the root directory of the snappyHexMeshTutorial after you extract the files. It is generally rec-
ommended if one wants to do copy and past, to copy and past from the accompanying file as Python
in particular might be sensitive to copying errors. Please stick to one way of working when doing
the tutorial as it causes problems to do part of the work in the GUI and the other part in the TUI.
The reason for this is that it is not possible to refer to the objects that were created in the GUI
from the TUI without additionally initializing them as objects. How to do this can be read in on
the salome homepage.3 Therefore, for a smooth progress of the tutorial, please stick to one way of
working. To make sure that the commands in the TUI will work properly, first type the following
in the Python Console inside Saolome:

import math
1 One however has to create an account on that webpage first, which requires a valid email address, in order to be

able to download the software

2 http://www.salome-platform.org/user-section/documentation/current-release
3 http://www.salome-platform.org/user-section/salome-tutorials/edf-exercise-9

28
A.1. CAD GENERATION USING SALOME APPENDIX A.

import salome
salome.salome_init()
import GEOM
from salome.geom import geomBuilder
geompy = geomBuilder.New(salome.myStudy)
gg = salome.ImportComponentGUI("GEOM")

Figure A.1: The welcoming screen in Salome.

Inside the geometry workbench we can at first create a cylinder by clicking on the icon this
will open the box shown in the next figure (figure A.2). The corresponding TUI command for this
is:

c1 = geompy.MakeCylinderRH(30e-3,300e-3,"Cylinder_1")

It is here very important to keep in mind that Salome always works in SI-units, i.e. the numbers
displayed as default values are in meters and would thus create quite a large cylinder. This is
also different from the proprietary CAD-programs that I have used so far as those mostly work in
millimeters. In here we put in the values 0.03 for the radius and 0.3 for the length. The default
selection in the top of the box where one can decide to put the cylinder at origin or choose a center
point and an extrusion vector can be kept here. If we click Apply and Close the cylinder should be
extruded as intended. It might however be very small and thus not appear directly on the screen in
proper size. To cope with this we can use the icon (fit all) to zoom to our model.
If everything worked out properly you should have something similar to the shape in figure A.3.
If you are using the Python Console you need to click into the Object Browser on the upper left and
press F5 from time to time in order to see the items you just created.
The next step will be the creation of the outlet area. We create it as a simple box that we later
attach to our previously created cylinder. But at this time we do not want our box to be created
at origin but at another point in the model. We therefore need to specify the points that will fully
constrain the box’ shape first. We do so by clicking on the vertex icon and enter the values −0.02,
0, 0 for the vertex’ coordinates in x, y and z, respectively, in the prompt that is now popping up
which is entitled Point Construction. Click Apply first and then do the same once more for vertex

29
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.2: The dialog box for creating a cylinder.

2 but with the different values 0.02, 0.05, 0.02 again for x, y, and z, respectively. After creating the
second vertex, click on Apply and Close in the Point Construction dialog box.
The box is now created by clicking on the icon. If we do so the dialog as shown in figure A.4
will pop up. Select the previously created vertices. Click on the left icon, which allows you to create
the box from the two vertices. Click on Vertex 1 in the Object Browser and observe that it appears
as Point 1 in the box dialog. Click on Vertex 2 and it will become Point 2. You can see the box that
is about to be created in the visualization window, colored purple. Click on Apply and Close. This
will create a box at one end of the cylinder. The corresponding TUI commands for this operation
are:

v1 = geompy.MakeVertex(-0.02,0,0,"Vertex_1")
v2 = geompy.MakeVertex(0.02,0.05,0.02,"Vertex_2")
box1 = geompy.MakeBoxTwoPnt(v1,v2,"Box_1")

The next step is joining the two so far still independent geometries together. This is done by
using the fuse icon . In the opening dialog box (figure A.5) one then has to select the two
geometries that are to be fused and confirm with clicking Apply and Close. The corresponding TUI
commands for this purpose are:

f1 = geompy.MakeFuse(box1, c1)
id_fuse = geompy.addToStudy(f1, "Fuse_1")
gg.createAndDisplayGO(id_fuse)
gg.setDisplayMode(id_fuse,2)

The next step is rounding the edges at the transition from the cylinder to the outlet box. This
is done with the 3D fillet icon . In the top of the dialog box (figure A.6) one ticks the box next
to the blue box with the white edges because we would like to select the edges we want to smooth.
For this tutorial the radius of the fillets was chosen to be 0.01. Select the fused shape (Fuse 1 by
default naming) as the main object. One can then select the three edges at the joint between the

30
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.3: The resulting shape after creating a cylinder.

cylinder and the box by pressing the shift key on the keyboard and clicking on the edges with the
left mouse button. The corresponding TUI commands for this purpose are:

IDlist_e = []
f1_edges = geompy.SubShapeAllSortedCentres(f1, geompy.ShapeType["EDGE"])
IDlist_e.append(geompy.GetSubShapeID(f1, f1_edges[1]))
IDlist_e.append(geompy.GetSubShapeID(f1, f1_edges[9]))
IDlist_e.append(geompy.GetSubShapeID(f1, f1_edges[13]))
fil1 = geompy.MakeFillet(f1, 10e-3, geompy.ShapeType["EDGE"], IDlist_e)
id_fil1 = geompy.addToStudy(fil1,"Fillet_1")
gg.createAndDisplayGO(id_fil1)
gg.setDisplayMode(id_fil1,2)

As far as the geometry is concerned, the work is now more or less done. One further constraint,
however, arises as the mantle face of the shot sleeve shall later be assigned to two different patches
depending whether it is close to the ingate (fixedWalls) or in the area where the piston moves
(slipWalls). We for this reason have to split the mantle face of the cylinder. In order to to this we
first create a point (read above how to do that) at the coordinates (0, 0, 0.03) because we want all
of the area where the fillets start to be fixed. This point we use as the center point for creating a
circle. The circle icon creates it. Put 0.03 as radius as we want it to have the same radius as the
cylinder. Vector z as normal vector of the circle one can keep here as the cylinder was also extruded
along the z-vector (see figure A.7). Click Apply and Close. The TUI commands for these processes
are:

v3 = geompy.MakeVertex(0,0,0.03,"Vertex_3")

31
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.4: The dialog box for creating a box.

OZ = geompy.MakeVectorDXDYDZ(0, 0, 1)
circ1 = geompy.MakeCircle(v3,OZ,30e-3,"Circle_1")

With the constructed circle we can then partition the previously created fillet. Notice: Salome
always refers to the end object by the name of the last operation as you can see in the Object
Browser. In order to do so we click on the partition icon in order to open the box partition of
object with tool (figure A.8). If you put in the same parameters as shown in figure A.8, you should
after clicking Apply and Close see a circumferential line in the mantle face of the cylinder indicating
that this face is partitioned. For the Python Console the commands are:

partition = geompy.MakePartition([fil1], [circ1])

id_partition = geompy.addToStudy(partition,"Partition_1")
gg.createAndDisplayGO(id_partition)

Now the CAD modeling work is done. However, one can use another function of Salome in order
to prepare the model the later use in CFD. We can at this point already group the faces together
that shall later become the patches/boundaries of our model. For this purpose we click in the menu
panel at the very top of the window on New Entity → Group → Create Group. This opens the
window shown in figure A.9.
Select group of faces in panel Shape Type at the top, Partition 1 (or whatever you named it) as
main shape and name the group appropriately (in this case movingWalls) and select in the model
window the faces you want to assign to that group by clicking on them. Once again you can select
multiple faces by pressing the shift key on the keyboard while clicking. To see which faces you have
to assign to which group, you may see figure A.17 If you have selected the faces that belong to the
movingWall patch click Add in the window and if you are done Apply and Close.
Don’t be surprised by what is happening then because Salome by default normally will then only
display the group you just created. However, the other items in the object browser are still there
but just hidden. Clicking on the visibility icon in the object browser brings them back. Do
the above stated actions three more times in order to assign the group to the other faces that shall

32
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.5: The dialog window for fusing shapes.

later become patches/boundaries for proceeding with the tutorial, i.e. doing everything written in
this paragraph three more times and give them the other names slipWalls, fixedWalls and outlet,
respectively. Hint: If you do this several time as here you may click only Apply in the Create Group
dialog. You can then create a new group in the same box and the other has already been stored in
the study. Once again if you do not know which faces are supposed to belong to which patch, confer
with figure A.17 later in this report, which colors them accordingly. The Python Console commands
for this process are:

#create the groups

#creating a list with all faces in it faces 6,7,8,9,11,12,13,0
SubFaceList = geompy.SubShapeAllSortedCentres(partition, geompy.ShapeType["FACE"])
#group fixedWalls
fW = geompy.CreateGroup(partition, geompy.ShapeType["FACE"])
for i in [0,1,2,3,6,7,8,9,11,12,13] :
FaceID = geompy.GetSubShapeID(partition, SubFaceList[i])
geompy.AddObject(fW, FaceID)

id_group1 = geompy.addToStudy(fW, "fixedWalls")

gg.createAndDisplayGO(id_group1)
#group movingWalls
mW = geompy.CreateGroup(partition, geompy.ShapeType["FACE"])
geompy.UnionList(mW, [SubFaceList[5]])
id_group2 = geompy.addToStudy(mW, "movingWalls")
gg.createAndDisplayGO(id_group2)
#group slipWalls

33
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.6: The dialog box for creating fillets/smoothing the edges.

sW = geompy.CreateGroup(partition, geompy.ShapeType["FACE"])
geompy.UnionList(sW, [SubFaceList[4]])
id_group3 = geompy.addToStudy(sW, "slipWalls")
gg.createAndDisplayGO(id_group3)
#group outlet
outlet = geompy.CreateGroup(partition, geompy.ShapeType["FACE"])
geompy.UnionList(outlet, [SubFaceList[10]])
id_group4 = geompy.addToStudy(outlet, "outlet")
gg.createAndDisplayGO(id_group4)

In case you receive errors check whether they are caused by copy and paster errors from the
PDF as in Python indentations and white lines may matter. It is generally recommended to copy
and paste from the accommpanying files (in this case salomeScriptCreateShotSleeve.py). After all
the operations you should receive a geometry like the one shown in figure A.10a and your object
browser should look analog to figure A.10.
You may save your work now by clicking on the floppy disk in the icon panel or via File → Save.
Choose an appropriate name for your study for example /home/sebastian/projectChalmers/cases/modelingHpdcShotSle
and save it. If you later want to continue with adding different features to this model you can load
it back in via the folder icon in the icon panel or via File → Open. If picked the lasiest way and just
executet the accompanying Python script by directly loading it after opening Salome (File → Load
Script), please bear in mind that you then manually have to connect the visualization window via
File → Connect, move to the geometry workbench, expand the study tree in the Object Browser
and display the objects using the eye icon as shown in the paragraphs above. Now the CADing work
in Salome is completely finished and one can proceed with the mesh generation. This tutorial offers
two ways to do it: the mesh workbench in Salome or the snappyHexMesh utility which is part of
OpenFOAM .

34
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.7: The dialog box for creating a circle.

Figure A.8: The dialog box for partitioning objects.

35
A.1. CAD GENERATION USING SALOME APPENDIX A.

Figure A.9: The dialog box for grouping objects.

(a) Final tree in the object browser. (b) Final shape of the
geometry.

Figure A.10: The final result in Salome.

36
A.2. OTHER MESH CREATION APPENDIX A.

A.2 Example of other ways to create the mesh

A.2.1 Using the mesh tools in Salome
After doing all the steps that are presented in section A.1 one can now stay in Salome and switch
to the Mesh workbench by clicking on the mesh icon or select it in the drop-down box. Again,
one must zoom to fit the geometry in the visualization region in order to see it. Mesh generation is
done in two steps: First, you create the mesh by specifying the parameters and second you compute
it. If you want to create the mesh click on the icon. Then a window pops up like in figure A.11.
I will at this point not go into all the details of creating a perfect mesh in Salome. Therefore, in
the Create mesh box simply select Partition 1 as geometry by clicking on the twisted arrow and
then in the Object Browser on Partition 1, select Negten 1D-2D-3D as Algorithm and NETGEN 3D
Parameters as Hypothesis as shown in figure A.11. Next click on the left cog wheel icon right next
to the selection box where you just selected NETGEN 3D Parameters . Keep the default values
in that box and change Fineness to Very Fine in the box next to it. Click OK in this box and then
Apply and Close in the box Create mesh (figure A.11).
Similar to the operations in section A.1, one can also use the TUI/Python Console to command
Salome to do described steps. The commands for the operations of the preceding paragraph are as
follows.

# 1. import the necessary libraries

import SMESH, SALOMEDS
from salome.smesh import smeshBuilder
smesh = smeshBuilder.New(salome.myStudy)
# 2. Create a tetrahedral mesh on the box with NETGEN_1D2D3D algorithm (full netgen)
tetraN = smesh.Mesh(partition, "Mesh_1")
# create a Netgen_1D2D3D algorithm for solids
algo3D = tetraN.Tetrahedron(smeshBuilder.FULL_NETGEN)
# define hypotheses
n123_params = algo3D.Parameters()
# define number of segments
n123_params.SetNbSegPerEdge(20)
# define max element size
n123_params.SetMaxSize(30000)

Figure A.11: The dialog box for creating the mesh.

37
A.2. OTHER MESH CREATION APPENDIX A.

Figure A.12: Defining hypotheses for the mesh computation.

If you clicked Apply and Close in the dialog box the mesh is created. It is however not yet
computed. This is done by clicking the . One can then follow the progress in the status box (see
figure A.13). If it is finished it will summarize the newly created mesh as shown in figure A.14. The
Python Console command for this operation is simply:

# compute the mesh

tetraN.Compute()

Figure A.13: The status box while computing the mesh.

If the mesh computation is complete the next step is assigning the boundary patches. One can
do that by clicking on the create group icon . In the up-popping box (see figure A.15)
one selects group of faces in the top panel, the previously created mesh (Mesh 1 by default) as
mesh and then the box Group on Geometry. In the next selection box with the twisted arrow select
Direct geometry selecton (in the context menu that is opening) and then select the Geometrical
Object (Group on geometry) that we created at the and of section A.1. Simply select it from the
Object Browser. In this case in the figure A.15 did this process for fixedWalls. After clicking Apply
and Close the patch is assigned. You can check whether the assigning was successful from the newly
gained color of the face group.

38
A.2. OTHER MESH CREATION APPENDIX A.

Figure A.14: The summary of the created mesh.

If you don’t see the color, it is probably because the newly created face group is hidden by
default. Unhide them and you will see the color. For an unblurry representation additionally hide
the CAD object (Partition 1) in this case temporarily and you should see the coloring in the same
representation as in figure A.17. Repeat this action for all the 3 remaining patches. In the end, your
object browser should look similar to the one in figure A.16 and the visualization window in Salome
should look similar to the one in figure A.17. The Python Console commands for this are:

# create MESH groups on the faces previously defined

mFW = tetraN.GroupOnGeom(fW, "fixedWalls")
mMW = tetraN.GroupOnGeom(mW, "movingWalls")
mSW = tetraN.GroupOnGeom(sW, "slipWalls")
mOutlet = tetraN.GroupOnGeom(outlet, "outlet")

The last step is then to export the mesh into a format that is readable by OpenFOAM .
Salome here offers to export the mesh in .unv-files which can be imported into OpenFOAM by
using the ideasUnvToFoam utility. Therefore, select/mark the mesh in the object browser and
then click on File → Export → UNV file and save it under an appropriate name for example
$FOAM_RUN/caseMeshTutorials/salomeMesh/shotSleeve.unv. The corresponding Python Con-
sole command for this is shown below. It however has to be handled with care as the path for
exporting has to be adjusted depending on your file system structure.

#export the mesh as UNV file

#you though have to adjust the path first
tetraN.ExportUNV("/home/d4akohl/shotSleeve.unv", 0)

We can then switch to the terminal and type the commands of the following listing. You may
use another command than first one depending on how you source $WM_PROJECT_DIR/etc/bashrc.
The ideasUnvToFoam utility in OpenFOAM requires a valid case. We need one later either way
since we want to test whether our not our meshing was successful. We for this purpose copy the
basic pitzDaily case for the simpleFoam solver and test our mesh. Type to the terminal as follows:

openfoam231
tut

39
A.2. OTHER MESH CREATION APPENDIX A.

Figure A.15: The dialog box for creating mesh groups.

mkdir -p $FOAM_RUN/caseMeshTutorials/salomeMesh
cp -r incompressible/simpleFoam/pitzDaily/* !$
cd !$
sed -i 's/inlet/movingWalls/g' 0/*
sed -i 's/upperWall/fixedWalls/g' 0/*
sed -i 's/lowerWall/slipWalls/g' 0/*
sed -i 's/uniform (10 0 0)/uniform (0 0 -10)/g' 0/U
ideasUnvToFoam shotSleeve.unv
tree

As we can then see, the utility creates the typical OpenFOAM constant/polyMesh folder. If
all other necessary files are present, the case can be run. There is, however, one slight drawback
with this way of working. The boundaries that are now created by the ideasUnvToFoam utility are
all patches. If we were running simpleFoam right away, the solver would complain as we specified
wall functions as boundary conditions for the turbulence model for these patches. We therefore
need to change that first by opening the file in gedit. Please note that here no regard was given to
change any of the physical properties of the tutorial. It was simply applied for testing the mesh.
One additional hint: We leave the frontAndBack entries in the files/dictionaries in the 0 folder
untouched. For cleaning reasons, you may delete them manually if you like. However, them being
there does not cause any problems. The solver does not evaluate the entries of the dictionary as
we do not specifiy any boundary of that name in the constant/polyMesh/boundary file. In the

40
A.2. OTHER MESH CREATION APPENDIX A.

presented way of proceding, they were not deleted for convenience reasons. Please proceed with
editing the constant/polyMesh/boundary file by typing the commands of the next listing to the
terminal and edit the file. At the end of that listing, we will be able to view the results in ParaView.
The solution should converge well below 200 time steps.

# open the boundary file in gedit

gedit constant/polyMesh/boundary
# and change the type for fixed and slipWalls to wall manually
simpleFoam
paraFoam

41
A.2. OTHER MESH CREATION APPENDIX A.

Figure A.16: The object browser after assigning the patches and creating the mesh.

42
A.2. OTHER MESH CREATION APPENDIX A.

Figure A.17: The meshed shot sleeve in Salome.

43
A.2. OTHER MESH CREATION APPENDIX A.

A.2.2 Creating a mesh using snappyHexMesh

Preparing the STL-files
This section describes how you prepare the stl-files that will later be used by snappyHexMesh. The
first step will be to create the case folder. Upon execution, snappyHexMesh requires a more or less
valid case, which is why we will now create a simple tutorial case out of the pitzDaily case. Like in
the case for testing the Salome mesh, no regard was given to physical properties. They were simply
taken over from the pitzDaily case. We can later then use this simple case to test our mesh. For
this purpose, open a terminal an type:
openfoam231
mkdir -p $FOAM_RUN/caseMeshTutorials/snappyHexMesh/constant/triSurface
tut
cp -r incompressible/simpleFoam/pitzDaily/* $FOAM_RUN/caseMeshTutorials/snappyHexMesh
cd !$
sed -i 's/inlet/movingWalls/g' 0/*
sed -i 's/upperWall/fixedWalls/g' 0/*
sed -i 's/lowerWall/slipWalls/g' 0/*
sed -i 's/uniform (10 0 0)/uniform (0 0 -10)/g' 0/U
If you have done everything as described in section A.1, creating the necessary stl-files from here
is fairly easy. If not you can simply donwload the accompanying hdf-file from the webpage where
you got this report from and open it via File → Open in Salome. You can check that we are at the
same stage by comparing the object browser (see figure A.10. Very important is that you grouped
the faces that shall later construct one patch. Then you simply select/mark one group that shall
become one patch in the object browser and then navigate via the menu panel to File → Export →
STL and it even suggests the name of the group as default file name. Select the previously created
folder (see above in the listing) as target for saving. Make sure ASCII is set as export format, which
it is by default and repeat this action for all patches – 4 in this tutorial. You can also do this via
the Python Console with the following commands. Be careful, however that you need to adjust the
paths for the file names.

#export the grouped faces

#you though have to adjust the path first
geompy.ExportSTL(sW, "/home/d4akohl/snappyHexMeshTutorial/constant/triSurface/slipWalls.stl")
geompy.ExportSTL(mW, "/home/d4akohl/snappyHexMeshTutorial/constant/triSurface/movingWalls.stl")
geompy.ExportSTL(fW, "/home/d4akohl/snappyHexMeshTutorial/constant/triSurface/fixedWalls.stl")
geompy.ExportSTL(outlet, "/home/d4akohl/snappyHexMeshTutorial/constant/triSurface/outlet.stl")

After these actions you can close Salome.

After you have done that open them one by one with a text editor. At the top of the file you
should find the expression solid and the block is closed by endsolid at the end of the file. For
OpenFOAM to recognize the patches we have to name each solid in the stl-files. By changing the line
from solid to solid <patch name>E and endsolid to endsolid <patch name>. So for fixedWalls
for example change these two lines into solid fixedWalls and endsolid fixedWalls, respectively.
Do this accordingly with they other stl-files and insert their patch names.
The next step is joining the files back together into one closed solid. In Linux this can fairly
easily be done by using the cat command. We thus type

cd $FOAM_RUN/caseMeshTutorials/snappyHexMesh/constant/triSurface
cat fixedWalls.stl slipWalls.stl outlet.stl movingWalls.stl > shotSleeve.stl

by doing so we join the geometry back together only at this time all the patches are labeled prop-
erly and snappyHexMesh will later recognize them as boundaries and will create the constant/polyMesh/boudary
file accordingly. If we open the file now in ParaView, we shall see that the face zones that shall later
become patches have been assigned a different color. Open the file now if you like and check out the

44
A.2. OTHER MESH CREATION APPENDIX A.

different coloring (change the first command if necessary depding on how your ~/.bashrc is set up
and which version you use):

openfoam231
paraview

and then click on File → Open and select the file from the directory on the hard drive. Click on
Apply in the left panel and you should see it. Please notice the different coloring of the patches/re-
gions in the geometry. After you are done examining the geometry you may close ParaView.

Creating the background mesh with blockMesh

With the previous instructions in the main report on how to write an m4 script for the blockMeshDict,
it should be fairly easy to create your own even more complicated blockMeshDict the background
mesh for snappyHexMesh. For now, you can also use the one that is included in the accompanying
tutorial files, where everything is already set up. A general remark about the use of the accompany-
ing files: In the files everything is set up as such that you may after extracting the archive directly
start with executing the blockMesh command. For your convenience, there is an Allrun script in
the accompanying files that summarizes all the necessary commands. This report will proceed step
by step and the next step will be the creation of the background mesh. If you want to follow step
by step, download the blockMeshDict now and put it into constant/polyMesh. If you open the
blockMeshDict

cd $FOAM_RUN/caseMeshTutorials/snappyHexMesh
gedit constant/polyMesh/blockMeshDict

you will see that the outermost vertices of the bounding box of the shot sleeve are (−20 −20 0)
and (20 50 300) in millimeters. One however should select the number of cells in a way that they
produce the cell lenght you later want to have in the bulk mesh as snappyHexMesh does not refine
the bulk mesh if not told otherwise. So for example pick 1 mm as cell spacing and it should be fine
for this tutorial. You may close gedit. Do now create the background mesh before proceeding:

cd $FOAM_RUN/caseMeshTutorials/snappyHexMesh
blockMesh

Running snappyHexMesh
As the mesh created with snappyHexMesh was not finally used in the provided tutorial case, the cov-
erage of the usability of the snappyHexMesh tool will be quite concise and the author will only spread
some knowledge he obtained while using it which might be helpful to others. Once you have the stl-
files organized as described in the previous chapter, please download the surfaceFeatureExtractDict
and snappyHexMeshDict from the accompanying files and put them into the system folder. You
can then at first run

surfaceFeatureExtract

from the case directory. For this you must have the surfaceFeatureExtractDict located in the
<case dir>/system directory. This extracts all sharp edges where snappyHexMesh will later refine
the mesh. The edges it is suposed to extract are specified in the stl-files located in constant/triSurface
and they are also named in the surfaceFeatureExtractDict. It writes this information into the
<case dir>/constant/triSurface directory. Once this is done we can proceed with the meshing.
This can alternatively be done in parallel as well if one wishes to mesh rather large geometries
efficiently.

snappyHexMesh

45
A.2. OTHER MESH CREATION APPENDIX A.

starts this process which is composed out of 3 steps. While snappyHexMesh is running, we can have
a look at the governing dictionaries. The previously mentioned three steps’ parameters are specified
in the snappyHexMeshDict, which is located in the <case dir>/system directory. The reader may
type

gedit system/snappyHexMeshDict

from inside the <case dir> to open the snappyHexMeshDict, because we will have a look at it
now. At the top one can see the switches for the three steps mentioned above: First, creating
the castellated mesh, second, snapping to the surface defined by the stl-files and third, adding
(viscous) layers at specified regions. Another specialty is that you can also deliberately define
additional shapes such as boxes (searchableBox) inside the dictionary where it also refines the
mesh. Going further down in the dictionary, on recognizes the paragraph for each of the steps
and the specified parameters there. After each meshing step snappyHexMesh checks the quality
of the mesh it just created and iterates until quality criteria you specify in the bottom of the
snappyHexMeshDict are met. One can see that while looking at the output of snappyHexMesh.
At the end you should have a neat mesh which is refined to the surfaces for better resolution of
the viscous layer. If the reader would like to have further instructions about each single param-
eter, he/she may efer to the snappyHexMesh tutorial case snappyMultiRegionsHeater located at
$FOAM_TUTORIALS/mesh/snappyHexMesh/snappyMultiRegionHeater. Once \verbsnappyHexMesh+
is finished, we can run checkMesh to see that we created a sound mesh.

checkMesh

After this, we may open the case in ParaView by typing

paraFoam -builtin

to the terminal. The -builtin flag was chosen here as we did not create boundary condidtions
for the patches from the former blockMesh and without the -builtin flag ParaView will complain
about that. Please create a crinkle clip normal to the x-axis by clicking on the clip icon and select
surface with edges as representation. Click apply and see at first the box we created with blockMesh
Browse with the next frame buttons in the icon bar at the top through the different time steps and
see how snappyHexMesh altered the mesh. If you are done please close ParaView.

Testing the mesh with simpleFoam

Since the usablility of such meshes as we just created in snappyHexMesh in OpenFOAM ’s standard
solvers remains difficult to set up without additional alteration of the solvers. However, after all this
work, we would like to test the mesh for its usability in CFD cases. We therefore follow a similar
procedure as previously shown in the end of section A.2.1. We will use the pitzDaily tutorial for
simpleFoam that we already copied. However, here we have to move the created mesh with the
different steps from the case folder into a separate folder in order not to disturb simpleFoam.

cd $FOAM_RUN/caseMeshTutorials/snappyHexMesh
mkdir meshBackup
mv 1 2 3 meshBackup

The next step will be to erase the background blockMesh.

foamClearPolyMesh

No copy the last mesh created by snappyHexMesh to the constant/polyMesh folder and check
the mesh.

cp -rf meshBackup/3/polyMesh/* constant/polyMesh

checkMesh

46
A.2. OTHER MESH CREATION APPENDIX A.

If we browse through the output that checkMesh created we can see that there are still the empty
patches present in the constant/polyMesh/boundary file. They do, however, not contain any faces.
We can therefore delete them from the constant/polyMesh/boundary file. We must do this for
each time step or ParaView will complain. We also need to change the number that refers to the
number of items in the list from 10 to 4. It is preferable do this manually by opening the file in
gedit or by typing the following sed commands to the terminal.

sed -i '20,61d' constant/polyMesh/boundary

sed -i '18s/10/4/' constant/polyMesh/boundary

The case should now be ready for being run unsing simpleFoam. The solution should converge
well below 200 iterations again and we can after it is done evaluate the results using ParaView.

openfoam231
simpleFoam
paraFoam

The results are like when viewing the mesh best examined when creating a clip normal to the x axis.
Since you have now reached the final line of this tutorial, I sincerely do hope you found the
content useful. In case you encountered any problems or have suggestions, please feel free to contact
me by email. My address was stated on the front page of this report.

47