Sig Turbomachinery / Organize the next meeting

From OpenFOAMWiki

1 Next meeting

The next meeting will be at the Turbomachinery session of the third OpenFOAM workshop in Milano, July 10-11, 2008.

The proposed ERCOFTAC conical diffuser case-study can be found below.

2 Previous meetings

The group was officially started at the second OpenFOAM workshop in Zagreb, 2007.

The planning of the group started at the first OpenFOAM workshop in Zagreb, 2006.

3 The ERCOFTAC conical diffuser case-study

Maryse Page, Hydro-Québec, Montréal, Canada

The ERCOFTAC conical diffuser testcase [1] is a swirling boundary layer developing in a conical diffuser (axi-symmetric expansion of a circular pipe). A description of the measurements made by Clausen, Koh and Wood is available in references [1]. The experimental set-up is such that the inlet swirl prevents boundary layer separation but is just insufficient to cause recirculation in the core of the flow. Experimental results are available in the ERCOFTAC Classic database (Case 60: Swirling Boundary Layer in Conical Diffuser). The testcase was included in the ERCOFTAC Workshop on Data Bases and Testing of Calculation Methods for Turbulent Flows held in Karlsruhe in 1995 [2]. The testcase is also part of the QNET-CFD Knowledge Base (Swirling diffuser flow).

Figure ERCOFTACdiffuser.1 shows a 3D view of the geometry. The inlet is in this case located at the end of the honeycomb that was used in the experiments to generate a plug flow with a solid body rotation/swirl. In the experiments it was open air after the end of the expansion.

Several two-dimensional flow computations were submitted to the ERCOFTAC Workshop in 1995 [2]. Two-dimensional computations [3] and three-dimensional [4] computations using the experimental data at the inlet of the conical diffuser were also published in 1996 and 1997. More recently, results were presented using OpenFOAM at the Second OpenFOAM Workshop [5]. Computations reflecting more the experimental set-up were presented in 2006 [6].

ERCOFTAC geometry.jpg

Figure ERCOFTACdiffuser.1. 3D view of the ERCOFTAC diffuser geometry.

3.1 How to get the files

The OpenFOAM ERCOFTAC conical diffuser base case described below was developed as a case-study for the third OpenFOAM workshop, Milano, 2008, and it can be found at the OpenFOAM-extend SourceForge project (work in progress). It includes a parametrization of the geometry and the O-grid, and a complete OpenFOAM case that solves the flow in the domain. The parametrization is made using m4, and instructions on how to run m4 are included below.

Get all the current files by doing:

 
svn checkout http://openfoam-extend.svn.sourceforge.net/svnroot/openfoam-extend/trunk/Breeder/OSIG/TurboMachinery/ercoftacConicalDiffuser ercoftacConicalDiffuser

Update your files every now and then by standing in the ercoftacConicalDiffuser directory, doing:

 
svn update

3.2 Case0: Base case

The case is set up according to the instructions in the ERCOFTAC database. Note however that we here use the z-axis as the main flow axis instead of the x-axis. The measured profiles at z=-25mm are used as inlet boundary conditions, and the outlet is located at the position where the diffuser ends into open air.

3.2.1 Case0, parametrization

Figure Case0.1 shows the definitions of the parameters rIn, diffuserLength and openingAngle. It is thus easy to modify the geometry in terms of these parameters.

ERCOFTAC base case BCD 2dView.jpg

Figure Case0.1. 2D view of Case0. The radius is here doubled for visualization reasons.

The grid generation in blockMesh is based on a number of cross-sections. It is easy to add or delete cross-sections in the m4 file if anyone would like to study another version of the same case. Figure Case0.2 shows cross-sections A-C, that are used when making the mesh for the base case. The cross-sections refer to:

A: The inlet of the computational domain, where measurements are available.

B: The inlet of the expansion.

C: The outlet of the expansion, and the outlet of the computational domain.

The number of cells in the z-direction between each cross-section is specified in the m4 file using parameters zABnumberOfCells (for the number of cells between cross-sections A and B), and zBCnumberOfCells (for the number of cells between cross-sections B and C). The grid spacing in the z-direction is uniform.

ERCOFTACdiffuser planes Case0.jpg

Figure Case0.2. Planes used in the parametrization of Case0. The radius is here according to the ERCOFTAC description.

Figure Case0.3 shows the parameters used for defining the O-grid throughout the domain. The figure is an example of the grid plane at cross-section A, but the parametrization at other planes are defined with parameters where 'A' is exchanged with the letter of the other cross-section. The number of cells in the radial direction in the O-grid is specified using parameter rNumberOfCells, and the number of cells in the tangential direction is specified using parameter tNumberOfCells (these must be integers!). The center block will thus get tNumberOfCells in both directions. These numbers are the same for all cross-sections. The grid point distribution of the center block, and thus in the tangential direction of the O-grid is uniform. The grid point distribution in the radial direction in the O-grid is defined using parameter rGrading, which is the same at all cross-sections. rGrading is the ratio between the size of the radially innermost cell in the O-grid to that of the outermost cell. That is how blockMesh generates non-uniform meshes.

The location of cross-section A in the z-direction is specified using parameter zA. The outer radius of cross-section A is specified using parameter rA. The radius of the vertices of the center block, relative to rA, is specified using the parameter rRelA, which should be between 0 and 1. In other words, the radius of the vertices may be anything from 0 (rRelA = 0, but that would make no sense) to rA (rRelA = 1). The radius of the center point of each edge of the center block is specified relative to the radius of the vertices of the center block. The edge between two vertices is thus an arc with a center radius of rRelAc * rRelA * rA. rRelAc should be between 0 and 1, where 1 gives a center block with circular edges. These definitions make it easy to modify the O-grid thickness relative to the outer radius, while keeping a high quality shape of the O-grid.

ERCOFTAC base case o-grid.jpg

Figure Case0.3. O-grid used in the parametrization of the base case.

3.2.2 Case0, how to run the case

In the constant/polyMesh directory, type:

 
m4 -P blockMeshDict.m4 > blockMeshDict

Generate the grid by typing:

 
blockMesh $FOAM_RUN Case0

Work in progress ...

3.3 Case1: Extended base case set-up

This case is similar to Case0, but with extensions before and after the diffuser.

3.3.1 Case1, parametrization

Figure Case1.1 shows the definitions of the parameters rIn, diffuserLength, extensionLength and openingAngle. It is thus easy to modify the geometry in terms of these parameters.

ERCOFTAC base case 2dView.jpg

Figure Case1.1. 2D view of the ERCOFTAC conical diffuser base case. The radius is here doubled for visualization reasons.

Figure Case1.2 shows cross-sections A-F, that are used when making the mesh for the base case. The cross-sections refer to:

A: The end of the honeycomb, and the inlet of the computational domain.

B: The edge of a rotating part of the wall.

C: A measurement plane (the one used as inlet in Case0).

D: The inlet of the expansion.

E: The outlet of the expansion.

F: The outlet of the artificial extension, and the outlet of the computational domain.

ERCOFTACdiffuser planes Case1.jpg

Figure Case1.2. Planes used in the parametrization of the base case. The radius is here according to the ERCOFTAC description.

3.3.2 Case1, how to run the case

In the constant/polyMesh directory, type:

 
m4 -P blockMeshDict.m4 > blockMeshDict

Generate the grid by typing:

 
blockMesh $FOAM_RUN Case1

Make sure that there is a 0 directory. An original 0 directory is named 0_orig, and it is a good idea to keep this untouched. If there is no 0 directory, or if the 0 directory has been modified, type:

 
rm -r 0
cp -r 0_orig 0

Compile the addSwirlAndRotation utility, which is located in the attached OpenFOAM directory.

Set the swirl and rotation at the inlet and at the rotating walls, and initialize the internal field by typing:

 
addSwirlAndRotation $FOAM_RUN Case1

Note that addSwirlAndRotation ADDS the swirls and rotation, so if you run it again on the same time directory you will ADD again!

Run the case by typing

 
simpleFoam $FOAM_RUN Case1

3.4 Case1.1: Case1 in a rotating coordinate system

Same settings as Case1, but computed in a rotating coordinate system.

3.5 Case1.2: Case1 with sliding grid / GGI

Same as Case1, but with a rotating domain in the region of the swirl generator, and a sliding grid or General Grid Interface (GGI) between that and the rest of the stationary domain.

Not yet developed.

3.6 Case1.3: Case1 with Multiple Frames of Reference

Same as Case1, but with a rotating domain in the region of the swirl generator and a stationary domain in the rest of the geometry.

Not yet developed.

3.7 Case4: Body force honeycomb

Extend the inlet even further and add the honeycomb as a body force.

Not yet developed.


3.8 Contributed cases

Here you can add sections with case definitions that are of general interest, or that is needed for discussions in the sections below. Keep the Wiki nice and tidy! Co-organize your case definitions with those from other contributors!


3.9 References

[1] P.D. Clausen, S.G. Koh and D.H. Wood. Measurements of a swirling turbulent boundary layer developing in a conical diffuser. Experimental Thermal and Fluid Science, 6:39-48, 1993.

[2]: W.Rodi, J.-C. Bonnin and T.Buchal (organizers), ERCOFTAC Workshop on Data Bases and Testing of Calculation Methods for Turbulent Flows. Karlsruhe, Germany, April 3-7, 1995.

[3]: M.Page, A.-M.Giroux and B.Massé. Turbulent swirling flow computation in a conical diffuser with two commercial codes. CFD'96, Fourth Annual Conference of the CFD Society of Canada, Ottawa, Canada, June 2-6, 1996.

[4]: M.Page, B.Massé and A.-M.Giroux. Turbulent swirling flow computations in a conical diffuser. FIDAP User's Meeting, Burlington, USA, June 17-19, 1997.

[5]: M.Page and M.Beaudoin. Adapting OpenFOAM for Turbomachinery Applications. Second OpenFOAM Workshop, Zagreb, Croatia, June 7-9, 2007 (slides).

[6] W. Gyllenram and H. Nilsson. Very Large Eddy Simulation of Draft Tube Flow. In Proceedings of 23rd IAHR Symposium, Yokohama, 2006.

Please add more relevant references!

4 Specific studies

Here you can add your conclusions from your own studies of this case. Keep the Wiki nice and tidy! Co-organize your conclusions with those from other contributors!

4.1 Geometry and grid generation

Recommended settings of the parametrization. Recommended geometry. Discussions about the artificial extension, and how to treat the outlet into open air.

4.2 Validation

Validations against measurements. Development of implementations for automatic extraction and plotting.

4.3 Visualization

Development of implementations for automatic visualization of the results.

4.4 Boundary conditions

Discussions on different boundary conditions and different implementations. Comparisons, verifications, validations.

4.4.1 Inlet

4.4.2 Walls

4.4.2.1 Stationary
4.4.2.2 Rotating

4.4.3 Outlet

4.4.4 Implementations

4.4.4.1 addSwirlAndRotation

Usage: addSwirlAndRotation <root> <case> [-parallel]

This utility adds solid body swirl/rotation at patches listed in the constant/swirlAndRotationProperties dictionary. This means that you first set the non-swirling/rotating component in the time directory U file, and that the tangential component is ADDED. If you run the utility twice the tangential component will be added twice etc. The utility can thus be used both on swirling inlets (only solid body swirl, but any axial component profile) and rotating walls. In the current implementation it is assumed that this solid body swirl should be added at the inlet (the inlet must still be in the list), so the swirl is added also to the internal nodes in order to have a reasonably good initial velocity field. Other variables than the velocity field are unaffected, and those values should be set in the time directory as usual. The utility reads and modifies the U file in the time directory specified by the startFrom/startTime entries in the controlDict.

In the swirlAndRotationProperties dictionary you also specify the swirl/rotation in terms of the omega[radians per second] vector and the center of rotation vector. The switches modifyBoundaries and modifyInterior can be modified to control if both the boundaries and the interior should be modified, or only one of them.

An example of the swirlAndRotationProperties dictionary can be found in Case1.

4.5 Turbulence models

4.6 Solver settings for fast computations

It is always of interest to increase the computational speed, and the stability of the simulations... But it is of also of interest that the different settings give accurate results.

4.7 Parallel efficiency

Comparisons using different hardware configurations.

Scripts for automatic scaling tests.

4.8 Discretization schemes

Studies of the influence of different discretization schemes

4.9 Rotating frame of reference

Do you get the same results in a rotating frame of reference?

4.10 Multiple frames of reference

Even if it is not necessary for ths case, it is possible to verify the concept of Multiple Frames of Reference assuming that some parts of the domain is rotating while other aren't.

4.11 Sliding grid

See above

4.12 GGI interface

See above

4.13 Other

Please come with more ideas...

Back to Sig Turbomachinery