open foam tutorial starting

R-TechHôtel d' Entreprises - Parc Technologique Cap Delta09340 Verniolle – France

Ref: Thesis Report

Date: 25/02/07

Author: Vincent RIVOLA Page: 1/77

Comparative Study of the CFD codesMistral and OpenFOAM

-Application to fluid-structure interaction


Ref: Thesis Report

Date: 25/02/07


Abstract

The company R.TECH* is using the computational fluid dynamics code MISTRAL* they have been developing since the start of the company in 2002. This code has been optimized for supersonic and hypersonic flows but is also used for low speed flow studies. For future activities in collaboration with CNES, like fluid structure interaction on balloons, the company investigates the capabilities of using another code named OpenFOAM. The reason is that OpenFOAM can be used as a pure incompressible solver, so for incompressible flows the use of Mistral is not optimal (even though the results obtained are good). As well, OpenFOAM includes already some mesh motion algorithm, which makes it a good candidate to be used for fluid structure interaction kind of problems.

The first part of the study presents the capacities of the software OpenFOAM. It also shows the necessity of the creation of a converter program named GridPro2FOAM. Indeed, R.TECH is using the software GridPro* to create the meshes used in MISTRAL. To make a good comparison between the two codes, it's necessary to have the same meshes. GridPro is also producing high quality meshes which are preponderant to obtain good results. Since GridPro files are not directly readable by OpenFOAM, a conversion program is needed.

The working principle of GridPro2FOAM is explained in the second part. Then, will come the comparison itself between MISTRAL and OpenFOAM on different test cases. Indeed, before using OpenFOAM on a whole study, its capacities have to be verified and compared with another software.

According to the results obtained, OpenFOAM will be applied to the fluid structure interaction problem on balloons in order to see if it is able to fulfil the requirements of CNES balloons activities simulation. Different solver possibilities will be studied, including the coupling with another software, named IMPACT*.

Finally, a specific solver treating fluid structure interaction will be presented, as well as the future developments needed for the solver to be able to cope with all the requirements.

*: more informations on these terms can be found in the annexes.


Ref: Thesis Report

Date: 25/02/07


Table of ContentsAbstract................................................................................................................................... ..................21 OpenFOAM:....................................................................................................................... ....................5

1.1 OpenFOAM tutorials:.................................................................................................. ....................51.1.1 Lid-driven cavity flow:............................................................................................. .................5

Pre-processing:........................................................................................................................... .6Post-processing:............................................................................................................ ..............8Finer mesh:............................................................................................................................. .....9Increasing Reynolds number:............................................................................... .....................11

1.1.2 Other tutorials:................................................................................................................. .....14Stress analysis of a plate hole:............................................................................. .....................14Breaking of a dam:................................................................................................................... ..17

1.2 Cylinder Test Case:.......................................................................................... ............................192 GridPro2FOAM:............................................................................................................................... ....23

2.1 GridPro output files:.................................................................................................. ....................232.2 OpenFOAM input files:.............................................................................................................. ...272.3 GridPro2FOAM code:........................................................................................ ...........................30

2.3.1 The classes:....................................................................................................... ...................31Node:.......................................................................................................................... ...............31Face:........................................................................................................................................ ..31Patch:............................................................................................................. ...........................31Block:................................................................................................................................ .........31

2.3.2 The “main”:................................................................................................................. ...........313 Test cases:............................................................................................................................. ..............33

3.1 The flat plate:............................................................................................................... .................333.1.1 Presentation:...................................................................................................... ...................333.1.2 Results:.......................................................................................................... .......................35

Effect of grid shape:............................................................................................................ .......35Effect of the Reynolds number:.................................................................................................. 37Effect of the code:................................................................................................................. .....37

3.2 The Von Karman vortex street:.................................................................................... .................393.2.1 Presentation:...................................................................................................... ...................393.2.2 Results:.......................................................................................................... .......................41

Influence of the grid:.............................................................................................. ....................41Influence of wall refinement:................................................................................... ...................43Influence of the code:..................................................................................... ...........................44

3.3 Conclusion of comparisons:............................................................................................ ..............444 Application of OpenFOAM to Fluid-structure interaction:................................................................. .....45

4.1 Mesh deformation:..................................................................................................... ...................454.2 Multi physical domain computations:.............................................................. ..............................47

4.2.1 Different coupling approaches:.................................................................................... ..........47Weakly coupled:............................................................................................. ...........................47Strongly coupled:........................................................................................................ ...............48Fully coupled:........................................................................................................................... ..48

4.2.2 OpenFOAM coupling possibilities:................................................................................. ........48IcoFsiFoam:................................................................................................................... ............48IcoStructFoam:.................................................................................................. ........................49


Ref: Thesis Report

Date: 25/02/07


Conclusion:................................................................................................................... .............494.3 Implementing new possibilities in OpenFOAM:.................................................................. ...........49

4.3.1 Solver requirements:...................................................................................... .......................504.3.2 Solver evolution:.......................................................................................................... ..........50

Mixing icoFsiFoam and icoStructFoam:....................................................................... ..............51Interface mesh clustering:...................................................................................................... ....52Thinner mesh and compressible solver:.......................................................... ..........................53

5 Coupling OpenFOAM with another code:........................................................................... ..................565.1 Architecture of the coupling solver:................................................................................ ...............56

5.1.1 General solver working principle:........................................................... ...............................565.1.2 Mesh motion part:................................................................................................................. .585.1.3 Displacement computation:.............................................................................. .....................59

5.2 Application case description:...................................................................................................... ...615.3 Case test results:........................................................................................................ ..................62

5.3.1 Flow field evolution:................................................................................................... ............635.3.2 Mesh evolution:................................................................................................ .....................65

5.4 Future developments:.............................................................................................. .....................666 Conclusion:...................................................................................................................................... .....68ANNEXES........................................................................................................................ .......................70


Ref: Thesis Report

Date: 25/02/07


1 O penFOAM:

1.1 O penFOAM tutorials:

OpenFOAM is delivered with a user guide (ref[1]), aimed to help the user to investigate all the possibilities offered by the software. The first part is a series of tutorials presenting three of the different cases already implemented among the different program solvers. The three tutorials are the following ones:

● Lid-Driven cavity flow,● Stress analysis of a plate with a hole,● Breaking of a dam.

Since the lid-driven cavity flow is a case closer than the others to the work done by RTECH, it was particularly interesting to see which results would be obtained using OpenFOAM. This will be a good opportunity to begin to have an idea about the validity of the code.

The two other cases are interesting because they permit to become familiar with the program. Within these two cases, one can discover some of the possibilities offered by OpenFOAM and learn how to apply them.

OpenFOAM is also using a nice post-processing program called Paraview (ref [1]) that will be discussed later in this report.

1.1.1 Lid-driven cavity flow:

The lid-driven cavity flow is a two dimensional problem, involving isothermal and incompressible flow. The geometry of the domain is as follows:

figure 1: Lid-driven cavity scheme.

The three walls in black are stationary while the top wall is moving in the x-direction at 1m/s. Since the speed is very low and dimensions of the problem quite small, the problem is initially solved on a

Ux=1m/s

d = 0.1m


Ref: Thesis Report

Date: 25/02/07


uniform mesh and assumed to be laminar. Therefore, the problem is solved using icoFoam which is the OpenFOAM solver for laminar, isothermal and incompressible flow. The effects of a mesh grading and Reynolds number increase will be discussed later by using the solver turbFoam which is the solver for turbulent, isothermal and incompressible flow.

The tutorial is split in three main parts which are the pre-processing, the run and the post-processing.

• Pre-processing:

This part can be performed in two ways, either by using a graphics interface named FoamX or editing the files that needs to be changed. Indeed this part in mainly related to the creation of the grid, the choice of initial conditions and appropriate solvers. All these informations are contained in specific files that can be read/write by FoamX or directly “by hand” using a text editor.

– Mesh Generation:The first thing exposed in this tutorial is how to create a mesh using the tool blockMesh. Here the

cavity domains represented by a uniform mesh of 20 by 20 cells. The tool blockMesh in OpenFOAM, uses input files which have the following format:

• a header part with informations about the version of the software, the studied case, the directories containing useful files, etc.

• a second part with the most important and practical informations. This part contains the position of the vertices, the format of the blocks and of the patches in the following form:

Vertices are defined by their three coordinates:

vertices ( (0 0 0) (1 0 0) (1 1 0) (0 1 0) (0 0 1) (1 0 1) (1 1 1) (0 1 1));

Blocks are defined by their form, the vertices that they contain, and characteristics of the mesh:

blocks ( hex (0 1 2 3 4 5 6 7) (16 16 16) simpleGrading (1 1 1));

Patches are defined by a name and the vertices used to create them:

patches ( wall movingWall ( (3 7 6 2) ) wall fixedWalls ( (0 4 7 3) (2 6 5 1) (1 5 4 0) ) empty frontAndBack (


Ref: Thesis Report

Date: 25/02/07


(0 3 2 1) (4 5 6 7) ));

– Boundary conditions:As can be seen just above, each patch is characterized by a name and a boundary condition

type. For example, for the last patch of the list above, the name of is frontAndBack and the boundary condition type is empty (since the case is two dimensional). Each type of boundary condition will give the possibility to change certain variable properties. For example, selecting wall for a given patch, there is the possibility to set a fixedValue for the velocity U and the condition for the pressure p on this wall will be zeroGradient. For other boundary condition type the possibilities will be different. – Physical properties:

Depending on the studied case and the choose solver, different physical properties can be access and set properly. For the lid-driven cavity flow, the only physical property is the kinematic viscosity which is a member of the transportProperties dictionary. It must be set according to the desired Reynolds number since the latest is defined by the formula:

Re=

d×∣U∣

where d and |U| are the characteristic length and velocity respectively and is the kinematic viscosity. Here, we take d = 0.1 m, |U| = 1 m/s , so to obtain Re = 10, must be equal to 0.01 m2/s.

– Control:In this part of FoamX, the parameters influencing the run can be set. Especially, time parameters

like startTime, endTime, deltaT, etc. These parameters are really important, in order to achieve good temporal accuracy and numerical stability when running the solver icoFoam. This can be done by always having a Courant number less than 1. The Courant number is defined as follows:

Co= t∗∣U∣ x

where t is the time step, |U| is the magnitude of the velocity through that cell and x is the cell size in the direction of the velocity. The condition Co<1 must be insure across the whole domain. Since |U| isn't constant and x can vary (not here but for other meshes), the worse case must be assumed to compute Co. Here the cell size is:

x=d

n=

0.1

20=0.005m

Then deltaT must be set to:

deltaT =Co× x

∣U∣=

1×0.0051

=0.005s

In order to write results all along the run, parameters like writeInterval permit to manage the time interval at which the data will be written on the disk. This is important in order to make an interesting


Ref: Thesis Report

Date: 25/02/07


post-processing study.

– Discretisation and linear solver settings:The choice of discretisation and solvers is of tremendous importance to obtain an accurate

solution using the most efficient way. In OpenFOAM this choice has to be implemented in the fvSchemes and fvSolutions dictionaries. For this case, finite volume discretisation is used. There are some other possibilities but there is no need to discuss them now, and it will be done later.

At this point, i.e. after the settings of initial conditions and the creation of the mesh, one should have a look at the mesh in order to check if there isn't any mistake before running the case. This can be done with the paraFoam tool which launches the software ParaView in order to visualize the grid. The following mesh is obtained:

figure 2: Mesh of 20x20 cells.

Inspecting the mesh shows there is no problem and so the case can be run. Once the case has been run, the results have to be post-process in order to visualize the different characteristics of the fluid.

• Post-processing:

Earlier in the report, it has been mentioned that the software would write results each writeInterval interval of time. These results have been stored in various directories respectively named with the run time of the data stored inside (directory 0.1 for the run time 0.1s for instance). This permits to retrieve easily among a lot of data, the ones of interest.

Then, it's easy to plot the pressure or the velocity field at a specific time. Furthermore, ParaView offers a whole range of post-processing possibilities like the plotting of the streamlines or the isobars for instance. ParaView is a really powerful tool which gives access to a lot of functionality (ref [1]).

Here below (figure 3 to 6), are depicted a series of images taken from the post-processing of the results for the lid-driven cavity flow:


Ref: Thesis Report

Date: 25/02/07


figure 3: Velocity field for a 20x20 cells mesh and U=1m/s.

figure 4: Pressure field for a 20x20 cells mesh and U=1m/s..

figure 5: Streamlines for a 20x20 cells mesh and U=1m/s.

figure 6: Isobars for a 20x20 cells mesh and U=1m/s.

Even if the results obtained with this coarse mesh are not so bad, a finer mesh is going to be used in order to see the improvements that it can bring.

• Thinner mesh:

The mesh density is now increased to 40 by 40 cells. But the nice thing is that OpenFOAM offers the possibility to start the computation of the solution on the fine mesh taking as initial condition the results obtained for the coarse mesh. Of course, on simple cases like the lid-driven cavity flow, the benefits are not so big, but on more complicated cases, this permits to reach the stable solution much faster. Here (figure 7 to 10), are the same graphs than before but plotted for a finer mesh:


Ref: Thesis Report

Date: 25/02/07


figure 7: Velocity field for a 40x40 cells mesh and U=1m/s.

figure 8: Pressure field for a 40x40 cells mesh and U=1m/s.

figure 9: Streamlines for 40x40 cells mesh and U=1m/s.

figure 10: Isobars for a 40x40 mesh and U=1m/s.

As could easily be thought before refining the mesh, the results obtained more detailed. However as can be seen on the images above the fine mesh is not useful everywhere on the field. Indeed, while the middle of the field doesn't need to be refine, the finer has to be used only in the corners.

This can be done by splitting the field into four blocks and using a mesh grading on the diagonal of each block. It means that x will no longer be uniform. It will be smaller in the corners than in the centre of the field. Now, the mesh looks like this:


Ref: Thesis Report

Date: 25/02/07


Figure 11: mesh graded with 20x20 cells.

The ratio of grading is equal to 2, which means that the the largest cell (in the centre) is twice as big as the smallest one (in the corners). This means that, x being smaller than in the uniform 20x20 cells mesh case, deltaT has to be decreased. A value of 2.5ms will then be used.

As done before, the results obtained on the coarse mesh are used as initial condition to start the computation for the graded mesh in order to converge faster. The results obtained with this method are quite similar to the previous one, but the computation time is lower since the mesh is only refined where it's needed.

• Increasing Reynolds number:

So far, the case has been run for a Reynolds number of 10. This is really low, but the nice thing is that it gives a stable solution quickly. Now, the goal is to obtain results for higher Reynolds numbers like 100 or 1000 for instance.

However, one must be careful and keep in mind that computation time can increase dramatically for a small increase in Reynolds number. Therefore, the best thing to do is to start the computation on the coarse mesh in order to converge quite fast to the solution. We will also take as a starting point the solution for a lower Reynolds number. The results for a Reynolds number equal to 100 are given in figure 12 to 15:

figure 12: Velocity field for a 20x20 cells mesh and Re=100.

figure 13: Pressure field for a 20x20 cells mesh and Re=100.


Ref: Thesis Report

Date: 25/02/07


figure 14: Streamlines for a 20x20 cells mesh and Re=100.

figure 15: Isobars for a 20x20 cells mesh and Re=100.

The results for a Reynolds number equal to 1000 are shown below:

figure 16: Velocity field for a 20x20 cells mesh and Re=1000.

figure 17: Pressure field for a 20x20 cells mesh and Re=1000.


Ref: Thesis Report

Date: 25/02/07


figure 18: Streamlines for a 20x20 cells mesh and Re=1000.

figure 19: Isobars for a 20x20 cells mesh and Re=1000.

And finally, in order to see the computation capacities of OpenFOAM, a case, with a really fine graded mesh of 160x160 cells with a ration of 4 between the largest and the smallest one, can be run. The results are the following:

figure 20: Velocity field for a 160x160 cells graded mesh and Re=10000.

figure 21: Pressure field for a 160x160 cells graded mesh and Re=10000.

One must be aware that the computation time increases dramatically with the refining of the mesh. For this case, no turbulence model has been take into account, which could be done for this kind of Reynolds number. So, playing with the size of the meshes must be done with precaution. The idea to keep in mind is to begin the computation on coarse mesh, in order to converge rapidly, and then refine the mesh step by step in order to reach the final desired mesh and run the computation on this one.


Ref: Thesis Report

Date: 25/02/07


figure 22: Streamlines field for a 160x160 cells graded mesh and Re=10000.

figure 23: Isobars field for a 160x160 cells graded mesh and Re=10000.

In fact, usually, the final fine mesh is created and two other meshes are generated from this one. One medium mesh which is twice coarser than the fine one. And the a coarse one which is twice coarser than the medium one.

1.1.2 Other tutorials:

There are two other tutorials given in the user guide which are the Stress analysis of a plate hole and the Breaking of a dam. They are not of direct interest for the future expected applications. However it is good to see the other possible applications of the software OpenFOAM, and it permits to become familiar with some tools provided in the package.

• Stress analysis of a plate hole:

As it can be seen on the figure 24, there are two symmetry planes for this case, the xz plane and yz plane. Therefore, the study will be focused on the right top part of the problem. The mesh for this case looks like the one on figure 25.


Ref: Thesis Report

Date: 25/02/07


figure 24: Plate hole case scheme.

figure 25: Plate hole mesh.

There is an analytical solution for the stress normal to the vertical plane of symmetry. The goal of this tutorial is to verify this analytical solution.

xxx=0

={ 1R2

2y2

3R4

2y4 if ∣y∣≥R

0 if ∣y∣R}


Ref: Thesis Report

Date: 25/02/07


Here is the solution obtained with OpenFOAM:

figure 26: Component of sigma along x axis.

Since the analytical solution is given for x=0, values of sigmaxx have to be extracted on this line, to obtain the following graph:

figure 27: Comparison of analytical and numerical solution.

Looking at the graph (figure 27) one could say that it would be nice to have more points for the OpenFOAM solution. However it's not possible to only increase the resolution of the sample to obtain the desired result. Indeed, if you increase the sample resolution without refining the mesh, you will end up with multiple points for the same value of sigma_xx, since this one is constant over a cell. So if you really wants more points, you need to refine the mesh and then increase the sample resolution. On a physical point of view, it's nice to see that our simulation fits quite well the analytical solution.


Ref: Thesis Report

Date: 25/02/07


• Breaking of a dam:

This tutorial is quite interesting. Just below (figure 28), there is a scheme of the situation. The goal of his tutorial is to simulate the motion of a column of water after the breaking of a dam, with an obstacle facing the fluid.

Figure 28: Dam break scheme.

The separation between the fluid and the atmosphere is represented by a constant which is equal to 1 for the liquid phase and 0 for the gas phase, so that at time t- just before the dam break, the field looks like this:

figure 29: Gamma field just before dam break.

As can be seen on the figure 29, there is not only blue or red colours (for gamma equal 0 and 1 respectively ), but also green, yellow, etc. This is only due to the interpolation which is done to go from 0 to 1 over a cell. Refining the mesh will result in finer boundary between the two phases.Then, let's break the dam and have a look at what happens:


Ref: Thesis Report

Date: 25/02/07


figure 30: Evolution of gamma during the simulation.

In this case, the pictures of figure 30 gives an idea of the motion of the column of water, but the interface between the two phases is quite thick. It would be nice to refine the mesh, however, for this type of simulation, the computation time would be increased dramatically and since it was not of prime interest for the remaining of the study, the refined mesh has not been run.

The tutorial (ref[2]) gives some pictures of the case run on a finer mesh and to give you an idea of the resolution improve, they are displayed on figure 31 and 32.

Figure 31: Solution on refined mesh, t=0.25s. Figure 32: Solution on refined mesh, t=0.5s.


Ref: Thesis Report

Date: 25/02/07


1.2 C ylinder Test Case:

Having a better idea of the possibilities offered by OpenFOAM, a new study case can be created without sticking to a tutorial. It's especially interesting to see how difficult it is to create a mesh for a study case. The new study case will still be quite simple, since it is the study of the flow around a cylinder. It's a good problem to begin with because it has been studied a lot of times in literature.In figure 33 a small scheme of the problem is sketched

Figure 33: Flow around a cylinder.

To study this case, the mesh should be able to depict all the details of the flow behind the cylinder. Furthermore the mesh has to be built keeping the possibility for the flow not to be symmetrical behind the cylinder. Hence, the whole domain has to be meshed. These remarks lead to the creation of the following mesh:

figure 34: Blocks for the creation of the mesh.

The mesh is composed by twenty blocks. Note that even if the mesh is represented in two dimensions, since ParaView only reads 3D meshes, this mesh is in fact in three dimensions. It is created using the tool blockMesh delivered with OpenFOAM. Let's first have a look at the input data the latest is using to generate the mesh.

The tool blockMesh is using the so-called blockMeshDict file which contains the informations needed for the creation of the vertices, of the blocks, of the edges... The first thing to do is to enter the 64 vertices using their three coordinates. There is a label assigned to each point (according to its position in the list of points).

U ?

12 11 10 9

815

1617187

6 19

20 13

14

1 32

5

4


Ref: Thesis Report

Date: 25/02/07


Then, the blocks are defined using the following form:

hex (0 1 8 9 32 33 40 41) (10 10 1) simpleGrading (1 1 1)

The prefix “hex” stands for hexahedra with respect to the shape of the block. The numbers between brackets are the labels of the points which compose the block. Then there is the number of cells in each direction (x,y, and z). And finally, the possibility to grade the mesh, like in the first tutorial. Note, the label of each point of the grid must be known in order to build the blocks.

Then when there are special edges, like here with the arcs, they must be specified as follows:

arc 24 25 (5.194134 4.53806 0)

The two first numbers are the starting and ending points of the arc. And the three numbers between brackets are the three coordinates of a third point (placed on the arc) in order to build the arc using three points. The problem is that the exact position of this point must be known, which means that 16 points for the front plane and 16 others for the back plane must be computed.

Finally, the patches are defined as follows:wall Inlet

( (0 32 41 9) (9 41 45 13) (13 45 50 18) (18 50 55 23)

)

Here “wall” describe the type of patch used, and “Inlet” is the name of the patch that is retrieved in the graphic interface of OpenFOAM. Each face of the patch is composed by four points labels. The patch defined above is composed by four faces. Again, one must exactly know which are the faces composed by the given points and then the patches that will be composed by this faces.

As can be understood reading the lines above, create even simple meshes with blockMesh gives rapidly a huge amount of work. To have an idea, it takes half a day to make the mesh for this case, and that's one of the simplest one that can be created. Furthermore, the writing of all these points by hand generates a high probability of making mistakes. Create meshes with one million points like it's sometimes the case in CFD, is unthinkable with this tool. The need of finding another solution becomes obvious.

Besides blockMesh it exists a lot of programs which permit to create meshes in a much easier way. Especially because they are using a graphic interface which offers many more possibilities. The company R.TECH is using a software named GridPro. Some conversion tools are delivered with OpenFOAM, like fluentToFoam for instance, to convert the famous Fluent files in a format readable by OpenFOAM. Unfortunately, there is no converters for GridPro. Since GridPro generates high quality meshes, which is one of the most important issues if one wants to obtain accurate results, the company didn't want to use another software. Therefore, there was a necessity to create an interface between GridPro and OpenFOAM. But this will be discussed later.

Now, let's have a look at the results obtained running the case in OpenFOAM. The case has been run with an inlet velocity of 1m/s, and the purpose of the study is to see the difference between a viscous condition on the cylinder and a non viscous one. This is translated in OpenFOAM on the condition for the cylinder patch. Either a wall type (to simulate viscous flow) or a slip type (to simulate non-viscous flow) can be chosen.


Ref: Thesis Report

Date: 25/02/07


Just below (figure 35 and 36), there are the results obtained for both cases:

figure 35: Viscous condition on the cylinder for U=1m/s.

figure 36: Non viscous condition on the cylinder for U=1m/s.

On the first plot, the black circle shows an irregularity found in the solution during the analysis. In fact, this irregularity is due to a meshing problem. To better understand let's have a look at the mesh:


Ref: Thesis Report

Date: 25/02/07


figure 37: Mesh for viscous condition on the cylinder.

The location of the irregularity corresponds exactly with the location of a high jump in the mesh size. This kind of jump must be avoid to obtain good results. However, again, it's not really easy to do it with blockMesh. So the results that we obtain are not optimized. It's one more reason to use GridPro instead of blockMesh to create the grids.

In the next section GridPro2FOAM (the converter from GridPro to OpenFOAM) way of working shall be discussed, and also how it' will be used.


Ref: Thesis Report

Date: 25/02/07


2 GridPro2FOAM:

In this part, GridPro output data are going to be explained and manipulated. Secondly, OpenFOAM input files will have to be studied. And finally, GridPro2FOAM code itself will be presented.

2.1 GridPro out put files:

Once the mesh has been created using the graphic interface under GridPro, the software generates mainly two files:

– the first file “case.tmp“ contains all the points. For each block, It contains the number of cells in each direction, after which the coordinates are given (with the K index moving fastest, then the J index, and then the I index). It looks like this:

– the second file “case.tmp.conn” is the so-called connectivity file. It contains a lot of informations. This file permits to know the links between two blocks, the orientation of the coordinate axis of one block towards the others, and finally the boundary conditions for this particular mesh. For a simple two blocks grid, the file looks like this:

figure 38: First output file from GridPro.


Ref: Thesis Report

Date: 25/02/07


figure 39: Connectivity output file from GridPro. Let's have a look to an example to make it simpler to understand. The example of the cylinder is

chosen since it has already been studied before. For this case the mesh generated in GridPro is the following one:

For this specific mesh the connectivity file is as follows:

Figure 41: Connectivity file for the cylinder test case.And the file containing the points start like in figure 42, and keeps on going in the same way.

figure 40: Mesh generated by GridPro.

0

4

5 6 7

3

2

1

9

8

11

10


Ref: Thesis Report

Date: 25/02/07


figure 42: Points file for the cylinder case.

At the beginning of the connectivity file, there is for each block a line that resembles the following:

B 1 s 1 0 000 b 0 2 123 b 0 5 123 s 4 0 000 s 7 0 000 s 6 0 000 -1

Looking at the first letter and number translate this line is dealing with the connectivity of block 1 (which is block 0 on the figure 43).As can be seen, this is divided into six different alphanumeric groups. Each one of them is related to one of the faces of the hexahedra. Each item of this group is going to tell the connectivity of the face concerned.

There is to know which face is related to which alphanumeric group. In fact, each block has its own system of coordinates with its own i,j and k direction, as can be seen on the figure 43. The numbers that are written above each group correspond to a side of the coordinate system. For example, the number 0 corresponds to the side imin. number 1 is side imax, number 2 is jmin, number 3 jmax, number 4 kmin and finally number 5 corresponds to kmax.

0 1 2 3 4 5


Ref: Thesis Report

Date: 25/02/07


Figure 43: Mesh connectivity.

In the connectivity line, block 1 (the first number of the line, which is block 0 on the figure 43) is related by the imax side to block 2 (which is 1 on the figure 43). However, stopping here the analysis the orientation of the axis towards each other is unknown. The last three numbers of each group tell about the orientation. These three numbers are related to the orientation of the three axis i,j,k. The values have the following meaning:

– 1 means that the axis is oriented in the same direction as the i axis of the other block.– 2 .............................................................................................. j ....................................– 3 .............................................................................................. k ...................................– 4 .............................................................................................. -i ...................................– 5............................................................................................... -j ...................................– 6............................................................................................... -k ..................................

Then, in our case, “123” for the connectivity between block 1 and 2 means that, i of block 1 has the same orientation as i of block 2, j of block 1 has the same orientation as j of block 2, and k of block 1 has the same orientation as k of block 2.

The same can be done for the connectivity between block 1 and block 5 (which is block 4 on the figure43). And the axis orientation found will be the one drawn on the figure 43.

Remain the alphanumeric groups without the same type of letters and numbers, i.e. the ones beginning with an “s”. In fact, this means that the block is not linked with any other block on this side. Block 1, for instance, is not linked to any other block on the face imin , since this face is, in fact, a boundary of the domain. For this type of alphanumeric group the second number specifies the boundary condition which will be applied to this face. These boundary conditions are listed at the end of the connectivity file as it can be seen on figure 42.

In order to make a program to translate GridPro output files in OpenFOAM input files, there is still to learn which type of files needs to be created in order to be read by OpenFOAM. It's the second part that is going to be discussed now.


Ref: Thesis Report

Date: 25/02/07


2.2 OpenFOAM input files:

The input files of the small tool blockMesh has already been explained. But since this one one is not giving the expected results, another solution has to be found. Then, the output files of blockMesh are going to be studied, since these files are the ones used by OpenFOAM.

There are five important files that the conversion program will have to produce (given by order of creation):

– the file “points” which contains the three coordinates of each points of the mesh. Actually, this file is quite similar to the “.tmp” file in GridPro, and so it won't be to difficult to create. Note that each point has a label related to its position in the list (first point has label 0, second point label 1, etc...). Each coordinate is unique, i.e. it can only appears once in the list.

figure 44: extract from an input file "points" for OpenFOAM.

– the file “faces” which contains all the faces of the cells created from the different points. Note that the cells are not given explicitly in a file, they are derived internally by OpenFOAM based on the face informations. The different faces are specified using the label of the points. Here the faces are quadrilateral, so they will use four point's labels to be created as can be seen on the figure 44. Like for the points, a label is assigned to each face (first face has label 0, second face label 1, etc...).


Ref: Thesis Report

Date: 25/02/07


figure 45: extract from the input file "faces" for OpenFOAM.

– the files “owner” and “neighbour”. In fact, these files are dealing with the connectivity problem that was treated by “.tmp.conn” in GridPro. But instead of treating the connectivity of the blocks, they are treating the connectivity of the cells. Each face will have a owner cell and a neighbour cell. It permits to set the orientation of the faces and to avoid orthogonality problems.The figure 46 is an extract from the file “owner”. The beginning of the file (except the header) gives the number of elements of the file, and the lines between brackets correspond to different cells numbers. For example, reading the first number, one should understand that the owner of face 0 is cell 0. The second line (corresponding to face1) explains that the owner of face1 is cell0. The third one says that the owner of face2 is cell1, etc...The figure 47 is an extract from the file “neighbour”. It has to be read in the same way as the file “owner”. A value of -1 indicates that the face has no neighbour cell (it's a boundary face).


Ref: Thesis Report

Date: 25/02/07


figure 46: extract from the input file "owner" for OpenFOAM.

figure 47: extract from the input file "neighbour" for OpenFOAM.

– Finally, there is the file “boundary”. The name is quite explicit; this file contains the boundary conditions of the problem. Each different boundary condition is defined by a boundary type, a name, a startFace label (the label of the face where the boundary starts) and nFaces which is the number of faces composing the boundary. This defines the range of cells having this boundary condition.


Ref: Thesis Report

Date: 25/02/07


figure 48: extract from the input file "boundary" for OpenFOAM.

Note that with this type of definition, a good ordering of the faces in the file “faces” is of tremendous importance. Indeed, the first thing to do is to order the faces according to the boundary condition for which they play a role, in order that all the faces having the same boundary condition are put next to each other. There shouldn't be any discontinuity in the list of faces having the same boundary condition. That means that if two faces have the same boundary conditions, the one with the lower owner id will be placed before the other in the list. And finally, if two faces have the same boundary condition and the same owner id, they will be ordered according to their neighbour id. The one having the lower neighbour id being placed first.

Now, that the type of output files is known, the program GridPro2FOAM can be done. So let's talk about the code itself, and see how to go from one type of files to the other.

2.3 GridPro2FOAM code:

The code has been written in C++. This is an object-oriented language, and like any others, it permits to declare different types with their own associated operations provided by the so-called classes. It permits to create programs which are quite clear and easier to understand (once you know the basics of this type of language). Each class needs two files to be created, a “*.hpp” and a “*.cpp”. The first one is used to declare the characteristics of the class and the operations that can be done on it. The second one is used to implement these operations.

The details of the program are not explained here, but the general philosophy will be approach.To go from GridPro output files to OpenFOAM input files, few classes are created: Node, Face,

Patch and Block. And the main which is called gridpro2FOAM. The names are quite explicit but, let give an idea of what's the role of each class.


Ref: Thesis Report

Date: 25/02/07


2.3.1 The classes:

• Node:

A Node is, in fact, a point which will be printed in the file “points”. They are defined by three coordinates and a boolean saying if the node is on a boundary or not. Different operations can be done with the nodes, with the main purpose to make them unique (by giving them an id) and then to print them.

• Face:

Knowing the working principles, defined above, of the input and output files, a Face is defined by four nodes, an owner and a neighbour cell and a boundary condition. Like the nodes, they have an id. The most important operation, that has to be done on it, is to find whether or not two faces need to be merged. Two faces need to be merged, to avoid duplication, if they are composed by the same nodes. The boundary condition, owner cell and neighbour cell will be used to order the faces, for later use in the creation of the file “boundary”.

Each face has an owner and an neighbour (which will have to be printed in the files with the same names). In fact, the faces have the owner and the neighbour corresponding to the owner and the neighbour of one of their point. That means that, when the points are made unique, the equivalent owner and neighbour have to be stored. Doing this, even if duplicated points are deleted, the faces will still have an owner and a neighbour.

One of the most important thing to deal with, is the orthogonality of the face. Each face has a surface vector oriented according to ordering of the nodes (with the rule of the right hand). An other vector is created from the centre of the owner cell to the centre of the neighbour cell. For the orthogonality to be correct, this two vectors must have the same orientation.

• Patch:

A Patch is defined by a boundary condition, an hostBlock, an hostFace, a donorBlock and an orientation. For each patch, there is a low corner and an high corner, which permit to see the limits of the patch. A matrix is created in order to transform the coordinates of the donorBlock in coordinates of the hostBlock, in order to find, reading the connectivity file of GridPro, the links and the orientation of the blocks.

This matrix will also permit to find the points, present on two different blocks but having the same coordinates, in order to make them unique.

• Block:

A Block is defined by its size I*J*K and an id. It's in this class that the GridPro file is read. Reading the file, nodes are created, and later the faces . Actually a lot of work is done in this class. It's also there that the boundary conditions are set and used to create the faces.

2.3.2 The “main”:

Then, let's walk through the code to see the actions ordering and explain a bit more in detail the issues that have been faced during the programming. The beginning of the program is basically reduced to the reading of the file “.tmp” from GridPro and the creation the important entities, like the blocks for


Ref: Thesis Report

Date: 25/02/07


instance. Then, patches are generated from the analysis of the connectivity file (splitting them between internal and external patches).

Once the patches are done, the program loops on a vector constituted with all patches, and make the edge points unique. This is done in “patch.cpp”; it's making a loop on the i,j, and k coordinates between the low corner and high corner and using the coordinate transform matrix between two blocks, it can detect if two points have the same absolute coordinates. If it's the case, an equivalence is created between the two points. If one point has already an equivalent, it will point directly to this equivalent. It can happen for some block corners which are linked with more than one other block. When all the points are unique, points and cells are counted in order to write the “points” file.

The following action is to loop on the blocks to create the faces that are put in a list (more easy to manipulate, especially for ordering) named faces. However, at this point, some faces are doubled. Like for the points, have to be unique. The program loops over all the faces, and looks if a merge between two faces is needed. A merge is needed if two faces are constituted with the same four nodes (even if they are not ordered in the same way). Then when two faces are the same, a manipulation of the owner and neighbour of these faces permits to get rid of the orthogonality issue and delete the useless face. Finally, the list of faces is sorted according to the requirements set before (on the boundary condition , the owner id and the neighbour id), and files “faces”, “owner” and “neighbour” are generated.

The last thing to do is to create the file “boundary”. Since the faces are well sorted according to their boundary condition, it's quite easy to find the beginning of a set of faces having the same boundary condition. Then the startFace is directly known, and since the startFace of the next boundary condition is also known, nFaces is rapidly deducted. With all these informations, and the reading of the last part of the connectivity file (the part where boundary conditions are written), the “boundary” file can be generated.

The next step of the study is to implement some meshes created in GridPro into the software OpenFOAM. Some basic cases, like steady flows over a flat plate or a cone, will be use to validate the code and to begin the comparison with Mistral.


Ref: Thesis Report

Date: 25/02/07


3 Test cases:

In order to measure the capacities of OpenFOAM, the code has to be compared to other codes on various test cases. These test cases are some well known study cases for which results are already available. They will also be used in order to make a comparison between OpenFOAM and MISTRAL. As it has already been explained at the beginning, the purpose of this study is to see if OpenFOAM is able to compete with, and maybe make better than, MISTRAL on low speed flows. The study has to be conducted on various regime, from laminar to turbulent, and on different shapes. Hence, the first case will be a laminar flow on a flat plate. Then, more difficult cases, likes laminar and turbulent flow over a sphere, will be studied later.

3.1 The flat plate:

3.1.1 Presentation:The flat plate is a good first test case, since an analytical solution can be obtained from the

Blasius theory. This cases have been studied a lot of times, lot of results are available and some of them will be used to compare with OpenFOAM. The results of Blasius theory and the results obtained by the NASA (ref[3])on a similar case will then be used, to measure the validity of the results obtained with OpenFOAM.

Consider an incompressible, two dimensional flow over a flat plate at 0° angle of attack, as sketched on figure 49. For such a flow, Blasius showed that the equation governing the boundary layer can be reduced to:

2f''' + ff'' = 0

where f is a function of which is equal to y× U∞

×x. This new variable is related to u by the

formula u=U∞× f ' .

This equation, being a single ordinary differential equation, it can be solved easily than the original boundary layer equation. The benefit is also that, thanks to the form of , the profile of the boundary layer is the same for all stations x. Such variables are called a similarity variable, and the result obtained using this variable is called a self-similar solution.

Since the NASA, with the code WIND, already conducted an interesting study on this case, it would have been nice to compare the results with them. The first idea was then to use the same mesh as them, in order to compare only the codes. However, this mesh is not really fine enough in the

Figure 49: Sketch of a laminar flow past a flat plate.

y

x

U


Ref: Thesis Report

Date: 25/02/07


boundary layer region to capture a nice velocity profile. Then the decision has been taken to generate another mesh using GridPro and to convert this mesh using GridPro2FOAM in order to use it under OpenFOAM. Even if the mesh is not exactly the same as the one of the NASA, the main idea remains the same: a first part of the mesh with non viscous ground boundary condition, and a second part with viscous boundary condition. This is done in order to cope with a singularity problem which would rise at the leading edge of the plate if no laminar flow was present before.

Figure 50: R-Tech grid.

Figure 51: NASA grid.

However, on the pictures above, except from little change in grid domain, it's difficult to see the differences between both meshes. The most important difference comes from the number of points present in the boundary layer. On the figure 52 and 53, a zoom is made on the mesh inside the boundary layer. The colour represents the speed of the flow, a colour red representing the speed U.

Figure 52: Boundary layer on R-TECH grid.

Figure 53: Boundary layer on NASA grid.

As can be easily seen on the figures 52 and 53, the number of cells in the boundary layer is much smaller for grid created by the NASA. Actually there are about four cells in the boundary layer of the NASA grid, whereas there are about twenty five cells in the one created by R-TECH. It will be interesting

Non viscous Viscous


Ref: Thesis Report

Date: 25/02/07


to see in the results the difference that refinement is generating.

3.1.2 Results:

• Effect of grid shape:

First, let's compare the results obtained with OpenFOAM on the R-TECH mesh, with the solution obtained with Blasius theory. The test is run with a infinite amount speed of Mach 0.1, at a temperature of 700 R, a Reynolds of 200000 on a flat plate of 1ft long.

This results are obtained using the solver simpleFoam in OpenFOAM. This solver is aimed to resolve Navier-Stokes equation for laminar, incompressible, steady flows. But it can also solve turbulent flow if the option is chosen. This will be done later for the study of the sphere. The results obtained are very good. The points representing the solution of the Blasius equation, extracted from a table published in the Cambridge journals (ref[4]) are very close to the OpenFOAM curve using the R-Tech grid. What happen if the grid from NASA is used?

As it was expected, the results are better on the mesh created by R-TECH than on the NASA grid. Indeed, looking at the figure 54, one can notice that the green curve is not closely following the Blasius solution like the black curve. But the effect of a unrefined mesh is even more noticeable on the figure 55, where the friction coefficient is plotted along the plate. For this curve, the refinement along x axis is playing the biggest role.

On the R-Tech grid, the mesh is refined at the leading edge of the plate. The result is that this mesh permits a better capture of the transition between the non viscous wall and the viscous one. So, the grid is really an important part of the work in the study of this type of flow.

Figure 54: OpenFOAM results on R-TECH grid, Re=200000.


Ref: Thesis Report

Date: 25/02/07


Figure 55: OpenFOAM results for u/U on both R-TECH and NASA grid.

Figure 56: OpenFOAM results for Cf on both R-TECH and NASA grid.


Ref: Thesis Report

Date: 25/02/07


• Effect of the Reynolds number:

Since the results are given using a similar variable in which the Reynolds number is taken into account, the boundary layer profile should remain the same for various Reynolds number. However, since some codes can have difficulties to handle lower speeds than the one used earlier, it's interesting to see if we obtain the same results for a speed of Mach 0.01 for instance.

Figure 57: Comparison of velocity profiles for two Reynolds number on the R-TECH grid.

According to the theory, the results obtained for Reynolds number of 200000 and 20000 are very similar. The difference between both of them can be neglected; the code is in agreement with the theory.

• Effect of the code:

Now, OpenFOAM has to be compared with the code developed and used by R-TECH: MISTRAL. In order to compare the codes, and nothing else, the computations are done on the same grid with the same initial and boundary conditions. These conditions are the same as the one used in the previous paragraph.

As can be seen on the pictures 58 and 59, two solutions have been plotted for MISTRAL. The first one is the dashed green line which is quite far from the Blasius theory solution. This solution is obtained using the AUSMDV scheme, which is the one usually used in MISTRAL. A preconditionor is used in order to be able to use MISTRAL (built for compressible flows) on this case. However, it looks like the preconditionor is not enough efficient for this type of speeds, and the results obtained are not really good. Using another scheme, AUSMP, results are much better and stick to the results obtained with OpenFOAM. AUSMP is a scheme which reduces a lot the numerical diffusion. It makes the code very precise. On the other hand, it can't be used in many other cases since the diffusion is too low and it


Ref: Thesis Report

Date: 25/02/07


doesn't converge easily.

Figure 58: Velocity profiles from both codes on R-TECH grid.

Figure 59: Friction coefficient from both codes on R-TECH grid.

On this first test case, OpenFOAM has taken a short advantage. It gives very accurate results, in a short time, especially because of its simplicity of use. However, MISTRAL, using an appropriate scheme is able to deliver results as good as the ones of OpenFOAM. The problem will be to see if this scheme is still able to give good results on other cases, for which the convergence is less easier.

The next study case will be the Von Karman vortex street. It will permit to see if OpenFOAM is still giving interesting results for more complex cases.


Ref: Thesis Report

Date: 25/02/07


3.2 The Von Karman vortex street:

3.2.1 Presentation:

Figure 60: Flow around a cylinder.

Again, the object of interest is the flow around a cylinder. In the laminar regime, the latest can take various shape, according to the value of the Reynolds number:

– For very low Reynolds number (Re<<1), the flow is symmetrical above an below the cylinder, but also upstream and downstream.

– Increasing a bit the Reynolds number (Re<4), the flow is no longer symmetrical upstream and downstream. Indeed it's disturbed on a longer distance downstream than upstream.

– For higher Reynolds number (Re<40), some re-circulations appear just behind the cylinder and develop in the wake.

– Then for Reynolds numbers from 40 to 400, the re-circulations presents in the wake which have developed oscillating up to Reynolds 40, become unstable and one of the vortices break away from the cylinder. This is called Strouhal instability. The vortices are shed alternatively at a constant frequency and for the so called structure of Von Karman vortex street.

– Finally, for Reynolds number higher than 400, turbulences develop and the Von Karman vortex street totally disappears.

This part of the report is going to focus on phase four described above, in which the Von Karman vortex street can be observed and analysed. The element of comparison between both OpenFOAM and MISTRAL codes will be the Strouhal number, which is a dimensionless number given by the formula:

S=n×d

U

with U the upstream velocity, d the diameter of the cylinder and n the vortex shedding frequency.

Different grids will also be tested for this case. One has been created with GridPro and converted with GridPro2FOAM, the other has been done using blockMesh.

U ?


Ref: Thesis Report

Date: 25/02/07


Figure 61: Mesh created with BlockMesh.

Figure 62: Mesh created with GridPro and converted with GridPro2Foam.

As one can see, the meshes look pretty different, although the diameter of the cylinder is the same, equal to one meter. The first one is formed by a O-H topology, while the second mesh is using an ellipse to refine the grid only in the wake. The size of both meshes is also a bit different (form -5 to +15m for the first one, against -5 to +10m for the second one), but this will not influence that much the results.


Ref: Thesis Report

Date: 25/02/07


3.2.2 Results:

• Influence of the grid:

Let's first have a look at the results obtained with OpenFOAM on both grids. The first thing to say is that the visualization of the vortices in the wake of the cylinder has not been really straight forward. The first meshes created for the study were bigger (field going from -20m to +40m in X-direction), and in order to reduce computation time, the size of the cells was taken too high. This was engendering two phenomena. The first one was high diffusion which was weakening the vortices. The second one comes from the fact that, the vortices being small, they were in fact smaller than the size of the cells, making them impossible to visualize.

Therefore, the time step has to be taken quite small, since it's directly proportional to the size of the cells. It has been taken generally of the order of 10-3 to preserve a maximum Courant number much smaller than one.

As usually, the case is run on a coarse mesh to initialize the field before running on a finer mesh. As soon as the first vortices are created and that an asymmetric pattern can be observed, the solution is saved and run on the medium an fine mesh to obtain the Von Karman vortex street.

Figure 63: Von Karman vortex street on blockMesh grid using OpenFOAM for Re=100.

The solution obtained using OpenFOAM on the mesh created with blockMesh for a Reynolds number of 100 is quite good. The vortices are shed regularly behind the cylinder with a frequency equal to 1,75 Hz, which gives a Strouhal number of 0,175.


Ref: Thesis Report

Date: 25/02/07


Figure 64: Von Karman vortex street on GridPro mesh using OpenFOAM for Re=100.

As one can easily see by comparing figures 63 and 64, the solutions obtained in both cases is very similar for a Reynolds number of 100. So similar that, no noticeable difference in vortex shedding frequency can be observed. But the most interesting thing is that the coarsest mesh gives results which are not too bad with a Strouhal number of 0,185. Then, medium and fine meshes give similar results with a Strouhal number of 0,178.

However the behaviour of the codes on both grids has to be checked for higher Reynolds numbers.

Figure 65: Von Karman vortex street on blockMesh grid using OpenFOAM for Re=1000.


Ref: Thesis Report

Date: 25/02/07


Figure 66: Von Karman vortex street on GridPro mesh using OpenFOAM for Re=1000.

The figures above 65 and 66 demonstrates that for high Reynolds numbers, the vortex shedding frequency is increased and the vortices are smaller. Both solutions keep the same similar pattern. However, GridPro mesh being shorter, the flow field is more disturbed by the outlet conditions.

But for this type of Reynolds number, typically higher than 400, on would expect no vortices at all, since the flow should be fully turbulent. The fact that some vortices are still visible is due to high numerical diffusion which is lowering the effective Reynolds number, entering in the range of admissible Reynolds number to obtain the Von Karman vortex street. Next step is to look at the influence of wall refinement at the surface of the cylinder.

• Influence of wall refinement:

Looking carefully at the grids, one can object that they are not refined on the surface of the cylinder, making impossible the catching of the boundary layer of the cylinder. In order to see if this can have an impact one the vortex shedding frequency, a refined mesh as been created with GridPro and is shown in figure 67.

As usually, the computations have been done on the coarsest mesh, then on the medium and finally on the finest one. On the coarsest mesh, the Strouhal number is equal to 0,172. The latest is equal to 0,18 on the medium mesh. The finest mesh didn't give any results since the solution was always blowing up even taking a very small deltaT of 10-5. But it's not so problematic. The results obtained on the coarse and medium meshes permit to say that the refinement on the wall is not really necessary in this case. The improvement in the results is not significant and the computation time is much higher than before. Then, the comparison of both OpenFOAM and MISTRAL codes will be done on non-refined grids.


Ref: Thesis Report

Date: 25/02/07


Figure 67: Refined mesh created with GridPro

• Influence of the code:

Like in the first test case, OpenFOAM has to be compared with MISTRAL on the Von Karman vortex shedding study.

Since the first mesh used with OpenFOAM has been created with blockMesh, it can't be used in MISTRAL. Indeed, if a converter has been done to go from GridPro to OpenFOAM, no converter has been done to go from blockMesh to GridPro since the quality of blockMesh grids are not really good.

Then, MISTRAL has only been tested on the mesh created with GridPro. This is not such a problem since it is the best mesh for this test case.

Finally, the results obtained with MISTRAL are the same as the one obtained with OpenFOAM, especially for the Strouhal number that was the reference parameter for this test case. Indeed, the Strouhal number obtained with MISTRAL is also of the order of 1,7 – 1,8.

3.3 Conclusion of com parisons:

The purpose of this part was to check whether OpenFOAM would be able to compete with MISTRAL on different test cases.

Results talk by themselves, OpenFOAM does at least as good as MISTRAL on these cases. Furthermore, for cases studied above, OpenFOAM appeared to be easier to run since it is directly able to deal with very low speed flows unlike MISTRAL.

More over, OpenFOAM is integrating other solvers aimed to solve structure or electromagnetism, or even finance. The structure solvers of OpenFOAM are particularly interesting within the idea of the creation of a fluid-structure interaction solver.

The object of next part will be to see if OpenFOAM can be modified as easily as it can be run and to try to create a fluid structure interaction solver which will be able to deal with the balloon problematic.


Ref: Thesis Report

Date: 25/02/07


4 A pplication of OpenFOAM to Fluid-structure interaction:

Now that the performances of OpenFOAM have been quantified, next step is to apply this good looking tool to the real cases that R-Tech will have to deal with in a close future. The first application for which it would be interesting to use OpenFOAM is the simulation of a balloon. Within its activities with the CNES, R-Tech would like to be able to cope with the fluid structure interaction issues which exist in this type of study. Currently this ability is not implemented in MISTRAL, and some initial FSI developments have been carried out in OpenFOAM.

CNES is studying different types of balloons which can be opened, closed, pressurized or not, flying at different altitudes. Then there are differences in the study of each type of balloon. But some important elements are always present and a kind of generic code can be used as a base for the creation of more specific codes which will have to deal with the characteristics of each balloon.

One of the common characteristic is the problem of mesh motion in such simulations. Indeed, the importance of a good mesh has already been proven in the previous part. In such simulations, the mesh must move nicely according to the displacement of studied object. Nicely means that the mesh must keep its topology and not deform that much that it would end up in solution errors or even the computation blowing up. This mesh deformation will be treated in the first sub part on a simple case before being implemented in a much complicated code.

Then, another common characteristic to all balloons problems will have to be handled. It's the problem of multi physical domains computation. Indeed, in a balloon simulation, you have to deal with at least two domains (fluid and structure) and often three (external fluid, structure and internal fluid), each domain having an impact on the other. The problem can be simulated in different ways and this will be explained in the second section.

The last part of the work being to manage the implementation in the code of all the physics that is involved in such a problem. There are aerodynamic, thermal, structure and others problems that all need to be taken into account to obtain useful results.

4.1 Mesh deformation: As explained just above, this is a really important part for moving object simulations like balloons.

And before implementing all the physics, this has to work properly. There is no hope to obtain interesting results if the computation mesh is not good enough and this, all over the computation.

Figure 68: Cylinder mesh created with GridPro.


Ref: Thesis Report

Date: 25/02/07


Then the first step is to see if OpenFOAM is able to handle mesh deformation as expected. This is is done on a simple case. Since some meshes have already been realized for previous test cases, one of them is used, the cylinder (figure 68). The problem treated here will be the oscillation of a cylinder inside a tunnel, which should create similar vortices as the ones studied in the previous part. Indeed, this is a simple shape and it's close enough to a balloon (on a mesh deformation point of view) to give an idea of the behaviour of the latest in the real problem.

Figure 69: Oscillating cylinder scheme.

In this first step, the solver icoDymFoam, present in release 1.3 of OpenFOAM, is going to be used. It is aimed to solve problems with auto motion mesh handling. The goal is to see, by running the cylinder case, if the mesh is not too much deformed during the computation. The results obtained are pretty good. The mesh motion looks nice and the equation solver is not disturbed by non expected cell movements, which is the most important thing.

Figure 70: Oscillating cylinder going up...

U


Ref: Thesis Report

Date: 25/02/07


Figure 71: ... and down.

Note that this problem can also be seen as a way to preconditioned the flow for static cylinder study with vortices already presents in the field. It's a way to obtain the Von Karman vortex street much faster than usually.

The most important thing is that the way auto motion mesh is implemented in OpenFOAM looks quite efficient and usable for the balloon problem. However, as mention before, this case making it even more clear, a lot of other things need to be implemented. Next step is then the handling of multi physical domain computation.

4.2 Multi physical domain computations:Here is the start of the real fluid structure interaction study. Multi physical domain computation

means that the final solver will have to cope with both fluid (liquid or gas) and structural (mainly polymers) problems, and more over the interaction between the different domains. This in not straight forward, and there are different ways to create such a solver.

4.2.1 Different coupling approaches:One of the points were solvers often diverge is the coupling strength of fluid solver and structure

solver. The coupling can be:

• Weakly coupled:

Fluid Solving Fluid

Solid Solving Solid


Ref: Thesis Report

Date: 25/02/07


This scheme means that fluid and solid parts are solved separately and coupled each n time steps. For example, the code begin by solving the fluid part during ten time steps. Then, a pressure distribution is extracted from this solution and applied to the solid part, which is solved. It gives a displacement of the solid part on which a new fluid solution has to computed. This method is the one used at the end of the study and will be detailed in part five.

• Strongly coupled:

In this case, fluid and structure are still solved separately but within each time step. This solution is adopted within OpenFOAM in the solvers studied later.

• Fully coupled:

In the last case, the more coupled one, equation of fluid and solid are totally coupled. This means that you will find solid variables in fluid equation and fluid variables in solid equation.

4.2.2 OpenFOAM coupling possibilities:To solve the balloon simulation problem, the first step has been to look at what has already been

done in OpenFOAM with respect to fluid structure interaction simulation. Indeed, there are two solvers in OpenFOAM, named icoFsiFoam and icoStructFoam, dealing with this type of simulation. Let's have a look at both of them and find their pro and cons and see if one is suitable for balloons studies.

• IcoFsiFoam:

IcoFsiFoam is a strongly coupled solver dealing with the interaction between one fluid region and one structural region. The nice thing about icoFsiFoam is that an auto mesh motion capacity is already integrated to the solver. It means that when a point of the interface between the fluid and the structure is moving, all other points of the domain will move according to this point displacement in order to avoid mesh deterioration as much as possible.

However icoFsiFoam is not easy to run and is only computing a domain with two regions. This is not enough for closed balloons studies for instance, since there are two separated fluid parts and one structural part between. This means that the final code should handle three regions. Note that this is the case only if everything (fluid and structure) is computed inside OpenFOAM. If a coupling with another

Fluid

Solid

Solving Fluid and Solid

Fluid Solid

Solving Fluid and Solid


Ref: Thesis Report

Date: 25/02/07


code (handling structural computation) is done, the structural part in OpenFOAM will disappear and two regions will be enough. But this will be explained in detail later on.

• IcoStructFoam:

This solver is not present in the original version of OpenFOAM. It has been developed by an OpenFOAM user and can be downloaded on a wiki page. Like icoFsiFoam, it is a strongly coupled fluid structure interaction solver, dealing with two regions, one fluid and one structure. It has been developed before the implementation in OpenFOAM of auto motion mesh handling. Thus, this very interesting feature is not present in this solver. The mesh motion is done in the post-processing part.

The solver is working particularly well for small structural deformations. If the deformations are too important, the post-processing deformation can result in such problems (figure 72).

Figure 72: Post processing mesh motion for icoStructFoam.

One the external part, you can see the fluid pressure for an inflow coming from the left. But this is not really the point here. The interesting part is the structure, plotted in black here, and especially its deformation. One can easily see that the mesh motion is not good since only the interface has moved and interior points didn't move in consequence.

• Conclusion:

Undoubtedly, there are interesting features in OpenFOAM which are used to deal with fluid structure interaction. For example, the auto mesh motion of icoFsiFoam or coding architecture of icoStructFoam, and finally the fact that, OpenFOAM has the possibility to solve not only fluid equations but also structure equations.

However, so far, none of the solvers which have been tried is able to treat the balloon simulation problem. Then, another solver has to be created to handle fluid structure interaction on balloons and to cope with its particularities. Different possibilities can be used and this is going to be explained in detail in the remaining of the report.

4.3 Im plementing new possibilities in OpenFOAM:

As explained earlier, in this part, the implementation of a new solver in OpenFOAM is going to be


Ref: Thesis Report

Date: 25/02/07


explained. The first thing to do is to write clearly the needs that the solver will have to fulfil with. Then, different solutions will have to considerate. And finally, there will be an explanation of the code created to treat the balloon simulation problem.

4.3.1 Solver requirements:Before the creation of any solver the study of the code requirements is an important part of the

work. However, even if this has to be clearly enunciate at the beginning of the study, that's also something that can change according to client needs or the discovery of inherent incapacities of the software. Then the requirements have to be adapted to the possibilities offered by the software.

For balloon studies, the problem can be quite different from one type of balloon to the other. Indeed, balloons can be opened or closed, pressurised or not, realised using different materials. Furthermore, they don't have the same size and don't evolve in the same environment. Then, one single solver cannot be expected to simulate every type of balloon. What is expected from the solver that is going to be created is to be the base for the creation of other more specific solvers which will deal with the particularities of each type of study. For those reason, one of the requirements is to make a solver which will be able to evolve in the future with an easy feature adding capacity.

Another requirement is that, as a kind of general balloon simulation solver, it will have to solve as many general problems as possible. For example, mesh motion handling is certainly one of the most important issues that the solver will have to resolve. One could object that, other softwares or even solvers already presents in OpenFOAM are solving mesh deformation. That's true, but the mesh deformation in a balloon study is really specific since the displacement of the cells is really large compared to their size. This implies the need of a really good interpolation method, to obtain the modification of an entire mesh from the motion of only one boundary. Note that the mesh motion handling will be of prime interest in this study, since it has not be done for this type of case before.

Finally other requirements like a compressible fluid or the possibility to implement thermal properties to the fluid parts will also be taken into account. However, since all the equations are present in OpenFOAM's other solvers, the implementation of such features is much a matter of time than a technical issue. Thus, it won't be the priority of the study.

Now that the purpose of the future solver is known, let's have a look at the different ways to create this one and the evolution that have been done before achieving the final solver.

4.3.2 Solver evolution:The requirements for the solver have been set. How can they be fulfilled is the new question. As a

starting point, there are mainly two possibilities for this solver. Either the whole solver will be coded inside OpenFOAM, either the code will have to couple OpenFOAM with another software in order to handle more complicate structural problems.

Indeed, OpenFOAM includes structural simulation capacities, but they are simple and incomplete for the type of problem that is expected to be solved. The structural equations present in OpenFOAM are only aimed to solve homogeneous structures with small deformation. The balloons studies imply inhomogeneous structures with loads on different points. Then, for sure, everything won't feasible inside OpenFOAM. And the coupling with another software like IMPACT cannot be avoid for some cases.

However, there are cases where the coupling should be avoidable and it could be nice to begin with those ones. So far, all the test cases have been done without going to deep in the code. And, as the need of going deeper will arise, the difficulties will increase too. So it's certainly a good thing to begin by creating a solver entirely in OpenFOAM before realising a coupling with another software. Even if the interest for such a solver will be limited in term of possible applications, it will bring a lot of informations


Ref: Thesis Report

Date: 25/02/07


on the way OpenFOAM code works. It will be easier to imagine the coupling once that first phase will have been done.

• Mixing icoFsiFoam and icoStructFoam:

This is the first step of the creation of the solver. The goal is simple: to take advantages of both codes and implement which is not done yet. This means, for example, that the new solver will have the architecture of icoStructFoam but with the auto motion mesh capacity. To sum up the the problematic, two questions have to be asked:

– What is available?

Two solvers for two regions computation domain, for incompressible fluid, and one including auto motion mesh.

– What has to be done?

A solver for three regions computation domain, including two compressible fluid regions, and the auto motion mesh capacity. The solver will also have to handle very thin polymer structures (of the order of 100µm).

Keeping these two questions in mind, the first step has been to add a region to the computation domain and to begin the testing. For computation time reasons, all along the development of this solver, the test case which has been used is the case of a flow over a moving cylinder. Moving means that the cylinder is either oscillating inside the flow or really deforming due to the difference between internal and external pressure. It's a two dimensional case which is close enough to a closed and pressurised balloon to give a good idea of the potential of the solver.

Figure 73: Three regions computation domain.

As can be seen on the figure above, the domain is now including three regions: external fluid (red), structure (green), internal fluid (blue). The external domain extends largely around the cylinder for the cylinder deformations not influence that much the rest of the computational domain. One can also notice that in this first step, the structural part is still quite thick compared to the cylinder size. Indeed, in this example the structure thickness is equal to 10 cm, which is rather big for a polymer.


Ref: Thesis Report

Date: 25/02/07


Figure 74: Three regions computation.

The results obtained look pretty interesting (figure 74). One can notice that, due to an over pressure on the front of the cylinder (the flow coming form the left), the structural mesh is compressed and the points of the different domains are moved in consequence. However, looking more closely to the two interfaces, some problems can be find out.

Figure 75: Interface mesh overlapping.

Indeed, some points of the interface are no more coincident and the external fluid mesh is overlapping the structural mesh for some patches. Of course, this is not really good since it ends up in mesh distortion and finally computation blowing up.

• Interface mesh clustering:

The solution found to solve this kind of problem have been to refine the mesh close to the interface. If we look at the results obtained, they are much better.


Ref: Thesis Report

Date: 25/02/07


Figure 76: Three regions domain computation refined at the external interface.

Figure 77: External interface without overlapping.

Comparing figures 76 and 77 directly shows that the refinement of the mesh has solved the problem. However, the refinement of the mesh cannot be done without precaution. You cannot refine the mesh as much as you want since it directly impacts on the time step that you choose for your computation. The finer the mesh, the smaller the time step, the longer the computation. Furthermore, the structure thickness still has to be decreased, which means that the thinnest cells will get thinner and thinner. Then, thinner structural meshes have to be tried with the solver, and the possibility of failure has to be considerate.

• Thinner mesh and compressible solver:

The next step is the test of a thinner mesh and the implementation of compressibility to solver


Ref: Thesis Report

Date: 25/02/07


equations. The possibility to have different thermophysical properties for each fluid region is also implemented. This means that you can have air in the external fluid part and helium inside the balloon (or the cylinder) for instance. It allows to try a new test case: the cylinder pumping. In fact a different pressure is prescribed inside and outside the cylinder, the external being smaller than internal. The purpose is to see if the mesh is able to deform as expected (according to the data given in ref[5]).

The structure mesh is now only one millimetre thick. It contains twelve cells in the normal direction, which means that each cell thickness is of the order of 100µm. So, if one makes the same displacement on such cells that was done before on 10cm thickness structure, relatively this displacement will be seen by the code as one hundred times bigger. This is really important since the main problem that appears in other solvers, is the incapacity to handle large displacement with respect to the cell size. The testing of this case is going to show if OpenFOAM can do that or if another solution has to be found.

Figure 78: Mesh with 1mm thick structure mesh.

Figure 79: 1mm Structure interface (black) between external fluid (blue) and internal fluid (red).


Ref: Thesis Report

Date: 25/02/07


On figure 78 and 79 which represent the mesh after displacement, it can be seen that the code is working quite well. Indeed, the displacement has been done without mesh distortion and the cell are still good looking. However, this is the case because, the mesh has just moved by one order of structure thickness as it can be seen on figure 80 looking at the difference between red mesh (starting mesh) which moved towards black mesh (final mesh).

Figure 80: Structure mesh movement between initial mesh (red) and final mesh (black).

And it is really difficult to make a bigger displacement since the need for very small cell size implies the need for a very small time step and thus very long computation times. The expected displacement according to initial pressure values and volumes, should be around eight millimetre, which eighty times bigger than what is obtained so far. There, the limits of such a solver, entirely integrated in OpenFOAM, can really be felt. The way the structure is handled implies too much limitations on size of the cells. Furthermore, the possibilities offered by such a structural solver are really small since it can only deal with homogeneous materials. No weights can be added, no differences between materials can be prescribed.

The best solution to give as many possibilities as possible to the final user look to be the coupling with a real structure code. The fluid would be solved by OpenFOAM and the structure by another solver specifically coded for this type of problems.


Ref: Thesis Report

Date: 25/02/07


5 Cou pling OpenFOAM with another code:

This is the final step of the work on OpenFOAM and that is why the final code is going to be explained in details in this part. As seen in the previous part, OpenFOAM has a lot of capacities but it looks like it is still not enough to manage a good balloon simulation. Then, another code has to be used, especially to simulate the structure part. In order to stick to the open source philosophy and thus have the possibility to modify the code as wanted, the structure solver code that is going to be used is named IMPACT (see annex for more informations).

In order to focus on the coupling between OpenFOAM and IMPACT, the possibilities regarding compressibility capacities and other secondary issues have been removed from the code that has been created so far. Indeed, the goal is to focus on the movement of the mesh, which is the biggest issue with respect to fluid structure interaction on a balloon.

Then, the goal of this part is make OpenFOAM and IMPACT able to communicate with each other. Generally speaking, OpenFOAM would solve the fluid part, write a pressure distribution, in order IMPACT to calculate the structure deformation and give the new shape back to OpenFOAM, for the new fluid computation. There are various problems to be solved and they are going to be investigate in this part. Note that, for lack of time reason, only the OpenFOAM part of the coupling have been realised. However, a draft of the future IMPACT coupling part will be also given.

Finally, the solver will be tried not only on the cylinder that has been used so far but also on a shape closer to the balloon shape.

5.1 Architecture of the cou pling solver:

The goal of this part is to detail the architecture of the solver in OpenFOAM which will be coupled with a solver in IMPACT. The first step is to make a diagram of the coupling way of working. It will permit to show how OpenFOAM and IMPACT will interact. It will also permit to understand what kind of parameters have to be extracted from OpenFOAM to be used in IMPACT.

5.1.1 General solver working principle:

The best thing to begin the explanation of the solver should be to make a diagram representing the working principle of the solver. It will give the different steps included in the code, each one of them being explained later in the report.

Let's go through this diagram (figure 81) and explain each step of the solver. After the solver's start, there is a condition which determines whether the solver takes care of mesh motion or not. Indeed there are few time steps before the beginning of mesh motion since the flow has to be solved first. Furthermore, the coupling between OpenFOAM and IMPACT won't be done each time step like it was done with previous solver since it would be too much computation time consuming and wouldn't bring so much benefits. Since this coupling is done in the part named here Mesh motion, the solver enters this part of the code only when time is equal to n*deltaT, n being chosen by the user.


Ref: Thesis Report

Date: 25/02/07


Figure 81: Solver working diagram.

Start

t>t1&t=nΔt ?

yesno

Compute pressuredistribution

Mesh motion

Solve external fluid

Solve internal fluid

Writing output files

t < tf ?yes

Endno


Ref: Thesis Report

Date: 25/02/07


Then, if the answer is no, the solver will directly jump to the computation of the different flow fields, and if the answer is yes, the solver will enter the coupling part.

5.1.2 Mesh motion part:Let say that the solver is entering the coupling part, it is interesting to do another diagram of this

specific part to better understand how it works.

Figure 82: Mesh motion part.

As can be seen on figure 82 mesh motion includes four steps. The first one is to detect the points which are on the moving interface. The user is writing in one of the case dictionaries the name of the moving interface before running the code, this name being used for the detection of the points.

Note at this point that there is now only one interface between internal fluid and external fluid. Indeed, since OpenFOAM is no more taking care of the structure, the only information that is needed is the displacement of the interface points and the structure mesh can be totally removed. Now, the mesh of the study case only incorporates two regions, the internal fluid, and the external one as it can be seen

Mesh motion

Detect interface points

Write interfacepoints in a file

Calculate displacement

Move points


Ref: Thesis Report

Date: 25/02/07


on figures 83 and 84.

Figure 83: Balloon mesh with two regions.

When the solver reaches the Detect interface point step on figure 82, it looks for the boundary points which belong to the interface specified by the user. Each point is then placed in a vector list which is written in a file named boundarypoints.

5.1.3 Displacement computation:The third phase is the displacement computation of these points. In fact, the final goal is to send

these points to the structure solver to make it move them. However in order to debug the OpenFOAM

Figure 84: Internal / external fluid interface.


Ref: Thesis Report

Date: 25/02/07


part of the code, the points movement is going to be prescribed by a routine. These routine can calculate the points displacement in two ways:

– Using formulas:

In this method the code is computing a displacement vector for each point of the boundary. These vectors will later be added to the corresponding points positioning vectors to move the mesh. The formulas used will be given later.

– Using a morphing method:

This method permits to go from one shape to the other. For example, you can go from a cylinder to an ellipse. You just have to know the initial boundary points and the final boundary points. The displacement is then computed at each time step by a simple formula which is final position minus current position divided by a number of step chosen by the user.

In any case, the purpose of this displacement prescribing step is to simulate the boundary points displacement that could be given by IMPACT if it was used. This corresponds to the Calculate displacement phase in figure 82, which is detailed in figure 85.

Figure 85: Displacement computation.

Calculatedisplacement

Read fileboundarypoints

Prescribe displacement

Move interfacepoints


Ref: Thesis Report

Date: 25/02/07


The last phase is the boundary points motion itself, and also the updating of the rest of the field according to the interface displacement. This part is kept inside OpenFOAM since it is one of its best feature. As described in the previous parts, it is able to modified the whole field according to one boundary displacement, minimising cells distortion. This is going to be checked in an application case which is the object of the next part.

5.2 A pplication case description:

Now that the code has been explained, it has to be applied on a case to see if can give the expected results. Keep in mind, that the main purpose of this application case is to determine if the moving mesh is reacting as expected. Then, very poor importance will be given to physical data results like velocity and pressure fields.

However, in order to simulate a case close enough to a real case, the displacement computation explained above has been the object of special attention. It has been decided to reproduce the deformation like the one happening during the deployment of a balloon (figure 86 and 87).

Figure 86: Balloon at time t0 (extracted from ref [6]).

Figure 87: Balloon at time t1=t0+2s

(extracted from ref [6]).

On the pictures above, the deformation occurring during the early phase of deployment is clearly visible. Of course it would very difficult to prescribe such a complex deformation, only by the mean of formulas. Then the deployment simulation will be restricted to the more simple deformation with the envelope going from the classic balloon shape to a kind of mushroom shape and coming back to the original shape (see figure ).

This is done by using the two displacement computation techniques explained in the previous part. The first phase of the deformation, i.e. balloon shape to mushroom shape deformation is done by the


Ref: Thesis Report

Date: 25/02/07


use of formulas. The second phase is done using morphing method. Indeed, the shape of the balloon is actually saved at the beginning of the computation and used as the final shape to be morphed on after a certain amount of iteration step decided by the user.

Figure 88: Two phases of the application case.

The formulas for the first phase deformation are empirically with a series of tests. The purpose is not to stick to the real case by doing exactly the same deformation but to have an idea of the capacity of OpenFOAM to reproduce the real deformations when it will be coupled with IMPACT.

For the second phase, the morphing code is the following one:

stepNumber = (endTime - nMotion*couplingTime.value())/couplingTime.value() + 1;

dx=1.1*(finalShapeBoundaryI[i].x() - X)/stepNumber;

dy=1.1*(finalShapeBoundaryI[i].y() - Y)/stepNumber;

These formulas are quite easy to understand. The first one computes the remaining number of steps between the moment of computation and the end of the simulation. The displacement components are computed for each boundary point by the difference between the current position and the aimed position, the whole thing divided by the remaining number of time step. For the last time step, stepNumber mustn't be zero but one, it is why one has been added in the first formula. Finally one can see that there is also a factor 1.1 in the second and third formulas. Indeed since, one can feel that, since the difference between current position and final position is decreasing with time, the displacement is smaller and smaller, and the point will never really reach the final position. The factor 1.1 is an empiric factor which is used to resolve this problem and get closer to final shape.

5.3 Case test results:

This is the last phase of the balloon simulation. Note, that this phase of testing is a little particular


Ref: Thesis Report

Date: 25/02/07


for the balloon deployment test case. Indeed, there are no results to compare with since this solver is using a new approach of fluid structure interaction on balloons and there is no experimental results either.

Furthermore, the solver isn't complete and it does not really calculate the structure part but prescribe a displacement. The interest of the test case is then to see if this prescribe displacement is working fine. What does it mean? First of all, it means to see if the mesh is really moving, that's a first step. Then, it also means to check, like it has been done for other test cases, the mesh quality after deformation. And finally look if a flow over the balloon can be solved and give at least physical possible results.

Figure 89: Mesh for the balloon deployment test case.

The colours of the figure above are not representative of any physical property, they are only aimed to differentiate the two regions of the mesh.

5.3.1 Flow field evolution:

The purpose of the series of pictures that is given in the following is to show how the flow field reacts to the mesh motion. It will also permit to say if the value are quite physical or totally wrong. It gives a good idea of the results that such a solver could give in a close future.

In this test case, the flow is coming from the top (to simulate a rising of the balloon) with a speed of 5 m/s. The upper part of the balloon was expected to react as a cylinder at the beginning of the computation. The speed on both sides should then be around twice the initial speed, i.e. 10 m/s. This is confirmed by the values observed in the first item of figure 90. As soon as the balloon is much deformed the equivalent side radius decreases and the maximum speed increases.


Ref: Thesis Report

Date: 25/02/07


Figure 90: Velocity field evolution through the mesh deformation.


Ref: Thesis Report

Date: 25/02/07


As one can easily see the deformation is not exactly like the one that can be observed on figure 87, but it is a good start. Furthermore the most important thing is to see that the deformation doesn't disturb the flow computation. This means that the mesh keep its quality and it is going to be checked in next paragraph.

5.3.2 Mesh evolution:

On figure 91, 92, and 93, you can see how the mesh moved between initial position and the maximum displacement time.

Figure 92: Lower part of the balloon. Figure 93: upper side part of the balloon.

Figure 91: Mesh deformation


Ref: Thesis Report

Date: 25/02/07


These pictures confirm the conclusion of the previous paragraph. The mesh moves but the distortion remains relatively reasonable and the flow can be computed normally.

The last thing to analyse is the morphing capacity of the code.

Figure 94: Initial shape.

Figure 95: Final shape after morphing.

Figures 94, 95, and 96 give quite impressive results. One can see that, if you plot the final shape obtained by morphing on the initial shape, there perfectly match. This is quite impressive, since by only prescribing the motion of the boundary you can come back to the initial position for all points of the field. Mesh motion features used for this solver are definitely working very well.

Figure 96: Final shape on top of initial shape.


Ref: Thesis Report

Date: 25/02/07


5.4 Future develo pments:

During this last part, the created solver has proven all its capacities. The results obtained on the balloon deployment test case give a nice impression of what could be done in a close future using OpenFOAM on this type of simulations.

However, there is still some work to do. Indeed during a first phase of the work, the main interest was to create a solver able to deal with multi physical domain problems. But even if results were not so bad, the limits of OpenFOAM have been almost reached. Then, it has been decided to keep the nice features of OpenFOAM, especially concerning mesh motion and to use another solver to compute the structure part. But in order to simplify the coupling, some physical properties (compressibility for instance) have been removed from fluid solver. Then, they will have to be added again, as well as some other physical properties will have to be implemented, like thermal exchange for instance.

When two solvers have to be coupled like in this case, it is important to keep them separated as long as possible, in order to debug each part separately. If the two solvers are directly coupled at the beginning of the study, it is difficult to say which part of the code is giving errors or which part is badly influencing the results. In this report the point was to make OpenFOAM able to send the informations to IMPACT, and to see if the informations given by IMPACT (like a prescribed displacement of the boundary) would lead to something usable in OpenFOAM.

Prescribing a displacement is working perfectly fine. Now, no matter who is giving the displacement, a routine, IMPACT or even another structure solver, OpenFOAM will deal with it. The second part of the work is now under IMPACT or another solver, to make it able to give the good information to OpenFOAM. For this part the same approach will be used in IMPACT. On this side of the coupling, the prescribed information will be a pressure field which will be used to compute the displacement of the boundary.

Finally, the last part of the work will be to make both solvers able to communicate, which is mainly a matter of data conversion and shouldn't be such a problem.


Ref: Thesis Report

Date: 25/02/07


6 Conclusion:

To sum up, this report gives an overview of the possibilities of OpenFOAM software. At the beginning, the purpose was to try this software on different cases. This has been done, and gave really good results, even impressive results considering that it is a non commercial software.

Furthermore, it has been discovered that OpenFOAM had high computation capacities not only in fluid dynamics but also in structure computation. Then, R.TECH being involved in balloon studies, the natural evolution was to apply this possibilities to fluid structure interaction since it was corresponding to a certain need for the CNES.

After the creation of different solvers with different possibilities and purposes, the limits of OpenFOAM began to appear since it only handle homogeneous structures and very thin ones are still problematic. So, it has been decided to find another way to solve the fluid structure interaction problem. This way is the coupling of OpenFOAM with a real structure solver, IMPACT. This solver being also an open source solver, the possibility to work on the code and create in-house solver remains unaffected.

Of course, coupling two solvers is a lot of work and remaining time was not enough to finish all the coupling work. However, the first results obtained are really encouraging, and this solver can definitely serve as the base for further work on fluid structure interaction. The final solver created can handle a two zones mesh created with GridPro. Don't forget that this can be done thanks to the previous creation of GridPro2FOAM which now freely distributed and already used in different places (Delft and Southampton for instance).

Finally, OpenFOAM capacities have been demonstrated and it can be considered as a real alternative to deal with fluid structure interaction issues.


Ref: Thesis Report

Date: 25/02/07


References1) Paraview, http://www.paraview.org/

2) OpenFOAM CFD tool box, User Guide.

3) NASA, Laminar flat plate, http://www.grc.nasa.gov/WWW/wind/valid/fplam/fplam.html

4) Cambridge, Laminar flat plate boundary layer: exact solution, http://journals.cambridge.org/production/action/cjoGetFulltext?fulltextid=379690

5) CNES ballonsPréparation Aérostat27/07/2006

6) CNES, S.Venel et J-M.Charbonnier, Memo: Analyse du dépoiement des ballons stratosphériques en phase de lacher

http://www.paraview.org/

http://journals.cambridge.org/production/action/cjoGetFulltext?fulltextid=379690



http://www.grc.nasa.gov/WWW/wind/valid/fplam/fplam.html






Ref: Thesis Report

Date: 25/02/07


ANNEXES


Ref: Thesis Report

Date: 25/02/07


Annexe I:

R.TECH & MISTRAL:

R.Tech is an SME specializing in Computational Fluid Dynamics, with expertise in modelling high-speed flows. State-of-the art computational simulations are performed by using innovative hardware techniques combined with close links to research institutes.

R.Tech's main efforts are centred on code development (CFD and engineering tools) as well as large-scale computations, which can be completed in a short turn-around time.

Grid generation for large complex three-dimensional structured grids is an area in which R.Tech is specialised using commercial software such as GridPro. Work in unstructured and hybrid grid generation is currently under development.

The computational power required for the simulation of complex studies is achieved using the R.Tech designed supercomputing facilities. Large-scale clusters of single or multi-processor machines are created to obtain combined CPU power, memory and storage space. R.Tech also offers services to port and benchmark existing codes on cluster architectures.

R.Tech develops a wide variety of new software (Engineering or Scientific) using various programming languages, such as Fortran77, Fortran90, C and C++. We also provide support for existing software for the implementation of new functionalities (e.g. physical models) or pure computational support (e.g. parallelisation of serial codes).

The core computational power is based on x86 architecture, from the high-end graphical workstations to clusters. Large computations are carried out on the Felicity cluster made of 11 compute nodes and one file server. Nodes are diskless making the cluster an easy and light system to maintain.

The working environment OS is based on Unix (Linux) while the programming language compilers are from Intel / GNU.A new cluster is now in use with 12 nodes.

The CFD tool employed in this work is MISTRAL, a tool that has been fully developed by R.Tech since 2001. The MISTRAL flow solver is a massively parallel flow solver that can also be used on a single processor workstation. Multidomain structured grids are chosen for Mistral as they are well suited for fast and accurate schemes, especially in the boundary layers.

MISTRAL is meant to solve for two-dimensional, axisymmetric or three-dimensional flows for steady or time dependent problems. The time integration is either explicit (single and multiple steps) or


Ref: Thesis Report

Date: 25/02/07


implicit (GMRES solver), additionally a dual time stepping technique can be employed for unsteady computations. The flow can be laminar or turbulent; the turbulence modeling can be based on a wide variety of models (we can cite the simple Baldwin-Lomax model, the SST Menter two-equation model ...). The solver can address any mixture with any chemistry set, the gas can be considered as either in perfect state, in chemical non-equilibrium, in thermo-chemical non-equilibrium, in ionized form. The flow regime ranges from nearly 0 speed flow, to low subsonic, high subsonic, transonic, supersonic, hypersonic and high hypersonic.

The MISTRAL flow solver has been validated on a wide range of test cases and used for industrial work in very low speed as well as very high hypersonic regime.


Ref: Thesis Report

Date: 25/02/07


Annexes II:

GridPro*:

GridPro is an automatic, object-oriented, multiblock grid generator. It provides users with a highly efficient, interactive capability to build topology, edit surfaces, set CFD boundary conditions, view grids and launch the grid generator.

Users interact with GridPro through the Az-Manager, an easy-to-use, dynamic 3D environment that combines a powerful scripting language with a user-friendly GUI front end. Automated processes minimize the amount of manual manipulation required to generate a grid, reducing errors in grid specification.

GridPro automatically creates templates of your grids to permit fast optimization to meet specific criteria.

To ensure that the highest quality grids are generated, the software engine incorporates a unique algorithm using advanced mathematical techniques. The algorithm optimizes each grid so that every element is smooth and orthogonal throughout the volumetric region under consideration.

– Highest Quality Mesh:GridPro generates a high quality mesh that greatly improves the accuracy of the solver. GridPro requires as little as one percent of the number of data points of other grid generation systems. You get superior results from lower quality CAD systems.

– Fast Results:A GridPro mesh enables solvers to get convergence three to ten times faster than when operating on lower quality grids. Automated processes reduce the operator interaction with the grid, often the slowest and most time consuming part of the grid generation process.

– Unique Technology:Our proprietary algorithms generate block-structured grids involving complex geometries. These grids can then easily be scaled and modified.

– Ease of Use:A 3D graphic environment enables users to readily specify, construct and modify grids. Built-in intelligence avoids errors. GridPro automatically generates templates for creating new grids in just a few clicks of the mouse.

– Flexibility:GridPro's Modular parametric design enables users to easily swap grids and alter their configuration geometry.

– CAD Integration:CADfix, an optional integrated input tool for GridPro, enables users to confidently accept and repair data from all major CAD systems. CADfix is a product of ITI Transcendata, the world's leading provider of data interoperability solutions.

*: extracted from www.gridpro.com

http://www.gridpro.com/




Ref: Thesis Report

Date: 25/02/07


Annexes III:

OpenFOAM*:

The OpenFOAM (Open Field Operation and Manipulation) CFD Toolbox can simulate anything from complex fluid flows involving chemical reactions, turbulence and heat transfer, to solid dynamics, electromagnetic and the pricing of financial options. OpenFOAM is produced by OpenCFD Ltd, is freely available and open source, licensed under the GNU General Public Licence.

The core technology of OpenFOAM is a flexible set of efficient C++ modules. These are used to build a wealth of: solvers, to simulate specific problems in engineering mechanics; utilities, to perform pre- and post-processing tasks ranging from simple data manipulations to visualisation and mesh processing; libraries, to create toolboxes that are accessible to the solvers/utilities, such as libraries of physical models.

OpenFOAM is supplied with numerous pre-configured solvers, utilities and libraries and so can be used like any typical simulation package. However, it is open, not only in terms of source code, but also in its structure and hierarchical design, so that its solvers, utilities and libraries are fully extensible.

OpenFOAM uses finite volume numerics to solve systems of partial differential equations ascribed on any 3D unstructured mesh of polyhedral cells. The fluid flow solvers are developed within a robust, implicit, pressure-velocity, iterative solution framework, although alternative techniques are applied to other continuum mechanics solvers. Domain decomposition parallelism is fundamental to the design of OpenFOAM and integrated at a low level so that solvers can generally be developed without the need for any ’parallel-specific’ coding.

*: extracted from http://www.opencfd.co.uk/openfoam/

http://www.opencfd.co.uk/openfoam/




Ref: Thesis Report

Date: 25/02/07


Annexes IV:

IMPACT*:

Impact is an open source finite element program suite which can be used to predict most dynamic events such as car crashes or metal sheet punch operations. They usually involve large deformations and high velocities.

Simulations are made on a virtual three dimensional model which can be created with a pre-processor or with the built-in Fembic language. Results are viewed in a post-processor.

Impact is designed to interface with the included pre- and post-processor by default, but there are also interfaces available for more advanced pre and post-processors such as GiD or Gmsh. Impact also has rudimentary support for Nastran file format.

Development is made by a team of volunteers from all over the world with the aim of creating a clean and compact program which is simple to understand and use.

Impact is licensed under the Gnu Public License which makes it free to use and modify as long as you release and publish your improvements under the same license.

Impact is written in Java which means it can be run on most hardware and operating systems.

*: extracted from http://impact.sourceforge.net/

http://impact.sourceforge.net/




Ref: Thesis Report

Date: 25/02/07


Annexes V

Stratospheric balloons*:

The stratosphere is too low to operate orbiting satellites, and sounding rockets traverse it too quickly to obtain meaningful data. But balloons - or lighter-than-air vehicles to use the scientific term- can stay aloft in this middle region of the atmosphere that extends through an altitude range between 12 and 45 km.

That is why they are a unique tool for scientific research, and why CNES has always sustained a keen interest in balloon activities.

CNES has built up its balloon activities in the last 40 years and today its balloon programme ranks second only to the United States. The agency has earned worldwide recognition for its expertise in the design, construction, launch and operation of lighter-than-air vehicles.

The 1st hot-air balloon in France took flight from the Ardèche region on 4 June 1783. As a tribute to the Montgolfier brothers who made the flight, this type of balloon is now called a Montgolfier balloon. French scientific balloon flights began in the early 1960s, conducted first by the national scientific research centre CNRS, and later by CNES.

Other major milestones in balloon development include:• 24 May 1972: 1st successful flight of a natural-shape French balloon, with a volume of 100,000

m3 ; • December 1982: 1st circumnavigation of the globe by a balloon-borne science experiment on an

infrared Montgolfier balloon ; • 2000: 1st Gamma-ray lens flown in space by a stratospheric balloon ; • 2005 : first flotilla of 25 superpressure balloons launched in the Antarctic polar vortex that

accumulated 1,500 flight days.

• 2006 : first operational flight of o pressurized balloon carrying 40 dropsondes.

CNES has a 50-strong team working on its balloon programme. In Europe, only CNES has the know-how to manage lighter-than-air craft from end to end, from construction through to operation. It has reached this pre-eminent position by nurturing highly specialized skills in information technology, materials simulation, mechanics, thermal design, aerodynamics and other required fields.

Since 1990, large-scale balloon launch campaigns geared toward studying the stratosphere have taken a new turn in Europe.

Now, several tens of balloons are released at the same time over a period of weeks. CNES’s

The Gap launch base ; credits CNES/P.Le Doaré


Ref: Thesis Report

Date: 25/02/07


success rate during these campaigns is proof of the level of excellence it has attained in nearly 40 years.

CNES’s balloon programme is a strategic tool enabling France to foster collaboration in science and technology fields with other European nations, such as Germany, Italy, Norway and Sweden. Outside Europe, CNES is also working with Brazil, Japan and the United States.

– Main benefits:The many benefits of balloons are attracting increasing interest from the scientific community. Their chief advantages are:

• low cost: it is 100 times cheaper to keep a balloon-borne gondola weighing 1 tonne aloft in the stratosphere for 24 hours than to send the same mass into orbit;

• ability to reuse most gondola components, thus achieving big economies of scale; • limited constraints on experiment payloads: balloons can carry instruments without constraints of

mass or volume, and withoutsubjecting them to the accelerations and vibrations of a rocket launch;

• experiments can be implemented quickly, because launching balloons is simple and there is a large choice of launch sites;

• they complement satellites in that their instruments can validate and calibrate satellite instruments.

– Adaptable and multipurpose:Lighter-than-air craft are currently employed in two ways. First, they serve as the main platform for science projects in their own right. Zero-pressure stratospheric balloons are often used for atmospheric research and astronomy, able to carry payloads of several tonnes up to altitudes of 40 km. Second, they also support other science or technology projects. For example, equipment that will fly on a satellite is tested on balloons before being launched. Here, the advantage of a balloon is that test equipment can be recovered and adjusted, which is much easier than attempting to correct equipment in orbit.Today, lighter-than-air craft are opening up new avenues of investigation for scientists. Sea-skimming aero clipper balloons trailing a probe through the water help scientist to look more closely at ocean-atmosphere interactions.

And in the future, balloons could play a key civil protection role by loitering over a fire, flood or other disaster area.

*:extracted from www.cnes.fr

Aerocliper ; credit: CNES.

http://www.cnes.fr/

open foam tutorial starting

Documents

software openfoam

openfoam tutorials

software gridpro

good results

thesis reportdate

vincent rivola page

good comparison

abstractthe company