Home

=**Background**= toc This page has been created by four final year Mechanical Engineering students undertaking their last research project at The University of Melbourne and is intended as a guide for future work with OpenFOAM and other CFD programs. The study is focused around the analysis of two cylindrical elements in a hydrodynamic flow, and how they interact while taking into consideration factors such as the wake, boundary layer separation and Reynolds number of the flow among other things. The pre-text to this investigation involves the emulation of an Unmanned Underwater Vehicle (UUV) trailing behind a submarine. The wake and vortices shed from the submarine hull and appendages can significantly influence the dynamic stability of the UUV, and thus creates a potential danger of collision between the vehicles. This study is being done under the supervision of The University of Melbourne Department of Mechanical Engineering and the Australian Defence Science and Technology Organisation (DSTO).

The majority of this study will be accomplished through use of the open source computational fluid dynamic software OpenFoam.

=Context of the Project= Initially the project was focused around building up to a an analysis of two cylinders in flow being simulated using the open source CFD software OpenFOAM. However half way through the projects duration it was thought to instead change the scope of the project to incorporate a real life scenario. The DSTO provided us with a mesh of a submarine that was analysed using the ANSYS program Fluent. It was thought that we could verify the results obtained by Fluent, and try an mimic them using OpenFoam. However due to the lack of computational power and them time involved in running cases with such large meshes in turbulent flows the task was set aside as and extra project. The in dept analysis of one cylinder in turbulent flow became the main focus of the team over the remaining duration of the project time frame. Due to the time and computational constraints it became difficult for the group to complete as in depth analysis of the task as they would have wished, however the skills acquired in setting up many of these problems and overcoming the boundaries of OpenFOAM were thought to be invaluable. In light of the absence of useful OpenFOAM/Linux Based CFD documentation this site acts as somewhat a guide line for future studies in this field to ensure the smooth transition from other popular software packages. It will go through many of the skills and techniques required to effectively simulate both laminar and turbulent flows using numerous inbuilt solvers and will also cover some of the issues that arose in this particular study and the techniques adopted to get around them. =Analysis of a Single Cylinder=

As the analysis of a single cylinder in flow became the primary goal of the project half way through the research study. It then became essential to simply concentrate on one cylinder but try perfect the validation of results over a large set of reynolds numbers both low and high, and also why adopting the use of different solvers in OpenFOAM, namely icoFoam and pisoFoam.

Three cases in particular when heavily concentrated upon these being:
 * Analysis of a two dimensional cylinder using icoFoam.
 * Analysis of a three dimensional cylinder using icoFoam.
 * Analysis of a three dimensional cylinder using pisoFoam.

However the analysis of two cylinders in flow was also started before the redirection of the project. The submarine mesh was also run however limited results were available due to the long computational time duration required by these cases.

Mesh Generation
Many would say that the generation of the mesh for the problem is perhaps the most important step in obtaining very accurate data. As a result it was crucial for us to continually work on refining the mesh throughout the Investigation process. Familiarisation with OpenFoam was perhaps one of the biggest hurdles in the initial stages of the project. Due to the fact that it was an open source software many of the niceties offered by other computational fluid dynamics software packages such as Fluent where absent. OpenFoam lacks the conventional graphical user interface, and the command based nature of the program made it very difficult to actually visualise the mesh.

To obtain accurate data it was important to generate a mesh that was not only consistent but also quite fine. The only issue that arose with developing a mesh that was so fine was the time it took run simulations on these cases. The finer the mesh the longer the problem will take to output data computationally. This was extremely frustrating for the team seeing as they did not have access to laboratory computers with multiple free cores. The team was essentially forced to "dumb down" the meshes so as to obtain some relevant data. However the method in which these meshes were developed and the technique for running these cases will prove invaluable to future teams that look to take on similar CFD projects based on OpenFOAM.

Use of Solvers
Although the OpenFOAM library does incorporate numerous different solvers two in particular where concentrated on by the group. icoFoam, which is particularly useful for laminar flow problems, and pisoFoam which is adopted for problems with a more turbulent flow pattern.

For the simulations to be accurate, the Courant number must be less than one. This is well explained on its [|Wikipedia page]

To implement flows generating specific Re, one simply calculates the velocity for the required Re. OpenFOAM uses the Re equation with kinematic viscosity (Re = vL/nu). Entering the flow velocity into the case is covered in the tutorials so is not covered here.

pisoFoam although somewhat similar had the added RAS turbulence modelling component added to it. This was done with use of the k-epsilon model. it was therefore necessary for us to simply choose these parameters. As a starting point, k = 1e-5, epsilon = 0.1 are suitable values at the inlet and //internalfield//

To maintain simulation stability, the Courant Number is kept to be kept less than 1. This is best done by trial and error by setting the timestep in the //ControlDict// file, running the case for a few timesteps then adjusting if required. The team recommends making the max Courant number less than 0.7 (especially pisoFoam) as we found that despite it being less than 1 (say, ~0.8), the cases became unstable in the middle of the simulation.

Simulation & Data Acquisition (and some useful Linux commands)
__Getting Drag Coefficient__ is setup by editing the c//ontrolDict// file. Extra lines of code are added to the bottom of the file. An example of a controlDict file is below

code /**- C++ -*--*\ \*---*/ FoamFile {   version     2.0; format     ascii; class      dictionary; location   "system"; object     controlDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
 * \\     /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
 * \\   /   O peration     | Version:  2.0.0                                 |
 * \\ /    A nd           | Web:      www.OpenFOAM.com                      |
 * \\/    M anipulation  |                                                 |
 * \\/    M anipulation  |                                                 |

application    pisoFoam;

startFrom      startTime;

startTime      0;

stopAt         endTime;

endTime        240;

deltaT         0.01;

writeControl   timeStep;

writeInterval  400;

purgeWrite     0;

writeFormat    ascii;

writePrecision 6;

writeCompression off;

timeFormat     general;

timePrecision  6;

runTimeModifiable true;

functions {

forces {		type forceCoeffs; functionObjectLibs ("libforces.so"); enabled	true;

outputControl timeStep; outputInterval 1;

patches (cylinder); //change "cylinder" to object patch name rhoName	rhoInf; rhoInf 1000; log true;

CofR (0 0 0); liftDir (0 1 0); dragDir (1 0 0); pitchAxis (0 0 0);

magUInf 0.502; lRef 1; Aref 8; } }

// ************************************************************************* // code lRef and Aref are described well [|here,] :"for a 2D cilinder drag calculation in OpenFOAM lref should be the diameter (or the radius if you are simulating only half of the domain) and Aref should be lref*Zmesh, where Zmesh is cells' dimension in the direction orthogonal to your solution domain.".

The output is written to a file in a folder called //forces//

__Writing the terminal output to a log file__ was highly advantageous. Apart from the claimed performance increase, it allowed the team to store the output for future reference and to check running cases remotely. All the following commands assume the user is in the correct case directory.

Given the shared nature of the computers the team had access to running the cases used lines such as:

code nohup icoFoam > log & code

'nohup' allowed the icoFoam to run with the user logged out (but can be omitted if the user never logs out as Ubuntu allows multiple users to be logged in simultaneously).

'> log &' writes the terminal output to a log file. Running this command does not result in any update of progress shown in the terminal. To show the progress (as if one would run the solver without this suffix), use

code tail -f log

code which shows the bottom ('tail') of the log ('log') with it always being refreshed ('-f')

__Remote access__ to the laboratory computers was used to great effect with the SSH command to utility that time was not wasted by team members in travel to simply obtain data or start simulations. This meant that the team could simply check results from their home computers without the need to travel into university. The only requirement for this method to work is to know the ip adress of the computer that needs to be accessed. This was achieved through use of the simple code below: code ssh @ code

The user can then access the machine. ParaView is not able to be executed as it has its own window. However the user can edit and view files, using functions. If the user intended to view or edit the file 'ControlDict', some available programs are respectively code cat ControlDict

code code pico ControlDict code __Parallelisation__ was perhaps the greatest improvement to productivity that the team made. Parallelisation made it possible to unlock the power of multiple cores while processing many of the simulations. this meant that in many cases the simulations could run up to four to eight times faster than simply running simulations normally.

Parallelisation requires a file called decomopseParDict in the 'system' directory of the case

The following is an example of one of our decomposeParDict files (here the case has been broken up into 8 subdomains) code /**- C++ -*--*\ \*---*/ FoamFile {   version     2.0; format     ascii; class      dictionary; location   "system"; object     decomposeParDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
 * \\     /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
 * \\   /   O peration     | Version:  2.0.0                                 |
 * \\ /    A nd           | Web:      www.OpenFOAM.com                      |
 * \\/    M anipulation  |                                                 |
 * \\/    M anipulation  |                                                 |

numberOfSubdomains 8;

method         scotch;

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // code Note that the Scotch decomposition method was employed for is automation and simplicity; requiring no geometric input and it also attempts to minimize the number of processor boundaries.

The steps below show the workflow that the team recommends after decomposeParDict has been created.

In order of entry:

1. Mesh the domain (if required) code blockMesh code 2. Run non-parallelised case to check Courant Number is less than 1. Once checked, kill the process with Cntrl-C code icoFoam code 3. Decompose the mesh (this will create folders called processor0, processor1, etc.) code decomposePar code 4. Run the case ('8' refers to the number of sections the mesh has been decomposed into, we wish to run the icoFoam solver and write the terminal output to a log file) code mpirun -np 8 icoFoam -parallel > log & code 5. Consolidate the results code reconstructPar

code The case can now be examined and postprocessed as usual.

__Post Processing__ allowed the team to obtain the results and simulation data The initial appreciation of the results was simply performed through visual observation of the flow around the cylinder. This was achievable through use of the tools in ParaView. once the simulation had finished running and the appropriate reconstructions had been applied, the "paraFoam" command simply needed to be executed to pull up ParaView. Once in ParaView, it was simply necessary to mesh the parts that needed to be viewed and navigate to the display tab. In the display tab the desired property could be chosen from the list, and then the animation could run using the play button in the task bar at the top of the window.

Displayed below is the output of both the pisoFoam and icoFoam simulations for a Reynolds number of 50,000. media type="youtube" key="39Mj9zv9TX0" height="315" width="420" align="center"

media type="youtube" key="Hs9jGwhRcyY" height="315" width="420" align="center"

__Digitising graphs into data points__ The projects aim was to essentially validate our simulation data against experimental data sourced from others. As much of this data has been published as plots in books and PDFs, with no corresponding numerical tables, it was necessary to digitise this information for manipulation. This was achieved through the use of the 2-D digitizing software; Get Data: Graph Digitizer, which can be obtained from the following website.

[]

The main step we took during the digitizing process were:


 * Importing image of scientific plot with supported format; TIFF, JPEG, BMP
 * Setting maximum and minimum axis values
 * Selecting the appropriate data points (see below)
 * Exporting TXT file of tabulated coordinate
 * Importing TXT file into MS Excel to be graphed/formatted





Validation of our particular models was done through developing velocity and pressure coefficient graphs. paraFoam supplied us with the tools necessary to develop these graphs, however some insight was required.

To obtain the Cp plots initially you needed to apply just the pressure data (p) and just the cylinder patch. After this the "Extract Surface" filter was added and also the "Plot on Intersection Curves". Then make sure that the plane is slicing the region that needs to plotted. A graph will be produced, however the data can be saved in *.csv format for ease of manipulation in excel. A diagram of the process can be seen below:



The velocity plots follow a similar trend, initially you need to apply the velocity data (U) and all of the patches. To develop the plots the "Plot Over Line" filter is used. In the properties prompt of this filter the coordinates of the line can be input. The line can then be viewed in the pipeline browser. After applying this the plot will be developed, and the data may be saved in a similar manner in *.csv format. A diagram of the processes can be seen below:

Animating results
The team followed the suggestion from the [|OpenFOAM user guide] regard to animations (see end of page).