Proceedings of ASME-JSME-KSME Joint Fluids Engineering Conference 2011AJK2011-FED

July 24-29, 2011, Hamamatsu, Shizuoka, JAPAN

Paper No. AJK2011-05015

OpenFOAM TURBO TOOLS: FROM GENERAL PURPOSE CFD TOTURBOMACHINERY SIMULATIONS

Hrvoje JasakWikki Ltd. London, United KingdomFSB, University of Zagreb, Croatia

Martin BeaudoinInstitut de recherche d’Hydro-Quebec (IREQ)

Montreal, Quebec, Canada

Key Words: OpenFOAM, Open source CFD, turbomachinery, GGI, mixing plane, C++, object orienta-tion

ABSTRACT

OpenFOAM is an established object-oriented li-brary for Computational Continuum Mechanics,with emphasis on CFD. It implements physicalmodels of fluid flow, structural analysis, heat andmass transfer using equation mimicking, with un-structured polyhedral mesh support and massiveparallelism in domain decomposition mode.

In order to use OpenFOAM in turbomachineryCFD, its “general purpose” capabilities are en-hanced with turbo-specific features, related tophysics of rotating regions and rotor-stator in-terfaces. Handling for geometric simplificationsof multi-blade and multi-stage rotating machinesare implemented, including simple stage inter-faces, non-equal pitch of blade passages, pitch-wisecyclicity and mixing plane averaging.

In this paper we describe the implementation ofturbomachinery-specific features in OpenFOAM,in the spirit of object orientation and C++. Empha-sis is given to the basic functionality of turbo tools,software layout in OpenFOAM, numerical formu-lation of stage interfaces and their place in overallcode design.

The paper is concluded with examples of turboma-chinery simulations, illustrating the capability ofturbo tools on industrial cases of incompressibleand compressible turbomachinery flows.

INTRODUCTION

Turbomachinery simulation represents a signifi-cant portion of contemporary Computational FluidDynamics (CFD). Simulation of multi-bladed ma-chines brings challenges beyond those encounteredin standard external aerodynamics CFD, HVACsimulations or studies of simple wall-bounded tur-bulent flows. Firstly, geometrical complexity ofmulti-bladed, multi-stage rotating equipment cou-ples to physical complexity of unsteady rotatingflow and wake-to-blade interaction. Secondly, per-formance prediction of a rotating machine requiresaccurate simulation of attached or detached turbu-lent boundary layers, sometimes in presence of ad-verse pressure gradients. This in turn implies theneed for very fine mesh resolution. Thirdly, rota-tion makes it necessary to account for relative mo-tion of multiple rotors and stators, either by directtopological changes in the mesh or by geometricalsimplification. Fourthly, performance of turboma-chines is of interest under quasi-stationary (engi-neering) conditions, even in the presence of clearlytime-dependent effects. Finally, for practical engi-neering use the cost of simulation (in terms of turn-over time) needs to be sufficiently low to allow de-tailed studies of off-design conditions, geometricshape optimisation, robust design studiesetc.

Mesh resolution requirements for turbomachineryflows are high, even if one considers a single-passage simulation of steady turbulent flows: pres-ence of boundary layers in adverse conditions,

1

shock-to-boundary-layer interaction and transientwake effects results in a challenging environment.To complicate things further, practical design ofrotating machinery involves non-matching bladepitch in consecutive blade rows, removing the pos-sibility of simplifying the geometry by impositionof symmetry constraints.

In response to this, a number of simplifications tothe flow model and geometry handling is regularlyapplied: we shall refer to them asturbo tools.

Rotation can be handled in several ways:

• In moving mesh calculations, a rotating com-ponent mesh is transformed in solid bodymotion by vertex motion and presence of ro-tation appears in equations via the relativevelocity term. No further intervention is re-quired, either in mesh handling or opera-tor discretisation; however, this is appropriateonly for transient flow simulations;

• Geometries under solid body rotation andsteady conditions may be simulated by con-verting the equation set into thesingle rotat-ing frame of reference represented on a staticcomputational mesh. Here, the velocity fieldappearing in equations is the relative velocityurel, and rotation is accounted for by addi-tion of centrifugal and Coriolis force sourceterms in the momentum equation;

• For multi-stage simulations,multiple rotatingframe (MRF) of reference approach is used,again represented on a static mesh. Rotationis accounted for in a region-wise manner,with the condition that the external bound-ary of each rotating region forms a surfaceof rotation. Momentum equation may be for-mulated either in terms of absolute or relativevelocity; the latter requires a transformationof the velocity field at the rotor-stator inter-face, which complicates the model.

At the interface between stationary and rotatingparts, further problems arise. For transient simu-lations with topological changes, interface may behandled using a sliding mesh technique [1]. Inter-face handling techniques that allow (but are not lim-ited to) steady-state are specific to turbomachineryCFD and are listed below. This will be the main fo-cus of the work presented here.

• The simplest manner of handling a rotor-stator interface is thefrozen rotor technique,where a section of a stator and a rotor aresimulated in a prescribed relative positionand in steady-state, using the MRF approach.Transient behaviour of the machine is theninferred (at a certain level of approxima-tion from a steady flow result. For increasedfidelity, a frozen rotor simulation may berepeated several times, varying the relativeposition of components. In implementationterms, it is sufficient to couple the non-matching rotor and stator patches at the in-terface;

• A General Grid Interface (GGI) accounts forthe coupling of the two in an implicit cou-pled manner without the need to topologi-cally change the mesh. This is achieved viaa direct intervention at discretisation level;

• In simulations of steady flow in single pas-sages at high mesh resolution, cyclic bound-aries are used. Imposing cyclicity in meshstructure is both tedious and limiting in termsof quality. A cyclic GGI interface is used toestablish accurate and implicit handling ofnon-matching periodic boundaries.

• Another geometric generalisation of a GGIallows one to simulate geometrically non-matching sections of a rotor and a stator, as-suming periodicity of each component sepa-rately. Sections at either side of the interfaceare coupled by rotational repetition (of vari-able pitch), using apartial overlap interface;

• For a steady-state simplification of the above,one may apply the multiple rotating referenceframe approach and perform circumferentialaveraging of the solution at the rotor-statorinterface via amixing plane interpolator.

The features above make a distinction between ageneral-purpose and turbomachinery-capable CFDcode and will be described in more detail. Clearly,this is not an exhaustive list: further capability en-hancements, such as turbo-specific post-processingand the harmonic balance model are likely to be asubject of future work.

The remainder of the paper shall be organisedas follows. We shall start with a brief review

2

of object-oriented design and software layout ofOpenFOAM. This will be followed by a descrip-tion of stage interfaces implemented in this study.All stage interfaces are based on GGI interpolation,with the addition of appropriate coordinate trans-formation or averaging. Features and details of theirimplementation, including the software design con-sistent withe the OpenFOAM framework and dis-cretisation methodology will be given. The papershall be completed by three examples of turboma-chinery CFD with OpenFOAM and a brief sum-mary.

OBJECT ORIENTATION IN NUMERICALSIMULATION SOFTWARE

Traditionally, high-performance numerical simula-tion software such as commercial CFD and struc-tural analysis tools have been written using aproce-dural programming paradigm. Here, a set of func-tions operates on globally shared data in a sequen-tial manner, making it simple to understand andeasy to optimise for efficiency. Unfortunately, in-creasing number of features complicates the sourcecode to the level where further development grindsto a halt: bulk of development time is spend re-moving software defects that result from complexmodel-to-model interaction.

Complexity of monolithic functional softwarestems from its data organisation model: globallyaccessible data is operated on by a set of func-tions. Here, each added feature interacts with allother parts of the code, potentially introducing newdefects (bugs) – with growing software size, datamanagement and code validation issues necessarilygrow out of control. This implies a software releasecycle of approx. 18 months, with 6 months of de-velopment time and 12 months consolidation, bugfixing and validation.

In 1980s, a programming technique calledobjectorientation attempts to resolve the complexity ina “divide and conquer” approach. The idea is torecognise self-contained objects in the problem andplace parts of implementation into self-containedtypes (classes) to be used in building the complex-ity. In C++, aclass (object) consists of:

• A public interface, providing the capabilityto the user;

• Private data, needed to provide functionalityand managed by the public interface.

As an example, consider a sparse matrix class. Itstores matrix coefficients in its preferred layout(private data) and provides manipulation functions,e.g. matrix transpose, matrix algebra (addition, sub-traction, multiplication by a scalar, vector-matrix,matrix-matrix products and ultimately linear equa-tion solvers). Each of these operates on private datain a controlled manner but its internal implemen-tation details are formally independent of its inter-face. Classes introduce new user-defined types intoproblem description, allowing the programmer tocreate a “look and feel” of the high-level code, ide-ally as close to the problem as possible. Crucially,data access and protection is handled at class leveland protected by a public interface.

Object orientation brings new challenges in numeri-cally intensive applications, such as scientific com-puting. OpenFOAM [2, 3], with its beginnings inearly 1990s illustrates how a careful use of objectorientation and evolutionary code development re-sults in an efficient and versatile numerical simula-tion tool-set. Main ingredients of its design are:

• Expressive and versatile syntax, allowingeasy implementation of complex physicalmodel by equation mimicking;

• Extensive capabilities, including wealth ofphysical models, accurate and robust discreti-sation and complex geometry handling;

• Open architecture and open source develop-ment paradigm, where complete source codeis available to all users for customisation andextension at no cost.

EQUATION MIMICKING

A natural language for physical models in contin-uum mechanics already exists: it is the languageof partial differential equations (PDEs). Attempt-ing to represent PDEs in their natural language insoftware, based on established discretisation tech-niques of the Finite Volume (FV) and the Finite El-ement (FE) method, is our stated goal.

Consider a turbulence kinetic energy equation en-countered in Reynolds Averaged Navier-Stokes

3

(RANS) models:

∂k

∂t+ ∇•(u k) −∇•[(ν + νt)∇k] =

νt

[

1

2(∇u + ∇u

T )

]

2

−ǫo

ko

k,

(1)

one can readily recognise the main objects that formthe equation: fields,k, u, νt; and operators∂.

∂t, ∇•.,

∇ etc. Lower-level objects, such as the computa-tional mesh, a time-advancement scheme, boundaryconditions and others support the above.

Within the object-oriented framework, we shall fol-low the path from Eqn. (1) to its encoded version inOpenFOAM, reading:

solve(

fvm::ddt(k)+ fvm::div(phi, k)- fvm::laplacian(nu() + nut, k)== nut*magSqr(symm(fvc::grad(U)))- fvm::Sp(epsilon/k, k));

Correspondence between Eqn. (1) and the code isclear, even with limited programming knowledgeand without reference to object-orientation or C++.

DISCRETISATION SUPPORT

Salient parts of object hierarchy in code snippetabove are outlined below. Some basic types, likescalar, vector, tensor, List, word etc.underpin the system and need not be reviewed indetail.

Space and Time. In computational terms, thetemporal dimension is split into a finite number oftime-steps. Formally, it is sufficient to track the timestep count and time increment∆t. A set of databaseoperations associated with time-marching finds itsnatural home in theTime class, including simu-lation data output everyn time-steps orx secondsof computational time and general time-related datahandling,e.g. book-keeping for old-time level fielddata handling needed in temporal discretisation op-erators.

OpenFOAM implementspolyhedral mesh han-dling, where acell is described as a list of faces

closing its volume, aface is an ordered list ofpoint labels and points are gathered into an or-dered list of(x, y, z) vectors. Low-level imple-mentation is discretisation-independent, where thepolyMesh class provides connectivity informa-tion and mesh metrics as well as operations likemesh deformation, topological changes or adaptiverefinement. For convenient use with discretisation,basic mesh information is wrapped. ThefvMeshclass, for example, supports the Finite VolumeMethod (FVM), while thetetFemMesh supportsthe Finite Element (FE) solver. In both cases, basicmesh structure and functionality is shared: a sin-gle mesh can simultaneously support the FVM andFEM solver without duplication of data and func-tionality.

Field Variable. Continuum mechanics operateson fields, discretised as a list of typed values at pre-defined locations in the mesh. This is implementedin three layers. AvectorField class consists alist of vectors and vector field operations: addition,subtraction, scalar multiplication, magnitude, dot-and cross-productsetc. Arbitrary rank tensors andfields are defined byVectorSpace expansion inthe same manner.

Boundary conditions, encoded as patch fields, carrybehaviour in addition to face values. For exam-ple, a fixedValue field carries values whichdo not change on assignment. Other types, like afixedGradient field class “evaluate” boundaryvalues given internal field and a surface-normal gra-dient. Patch fields constitute a family of relatedclasses: each calculates its boundary value, but doesso in its own specific way.

Grouping the field data with its spatial depen-dence (reference to a mesh), boundary condi-tions and a dimension set creates a self con-tained Geometric Field object. Example are thevolScalarField k orvolVectorField Uin the code snippet above.

Matrix, Linear System and Linear Solver. Asparse matrix[A] and linear system[A][x] = [b]hold the result of discretisation and provide the ma-chinery for its solution. It suffices to say that codeorganisation as presented above allows the FE andFV discretisation to share sparse matrix implemen-

4

tation and linear solver technology, resulting in sub-stantial code re-use.

Discretisation Method. Discretisation operatorsassemble an implicit or explicit representation ofoperators, based on the following three operations.

Interpolation, which evaluates field variable be-tween computational points, based on prescribedspatial and temporal variation (shape function),e.g.cell-to-face interpolation.

Differentiation, where calculus operations are per-formed on fields to create new fields. For example,the following code:

volVectorField gP = fvc::grad(p);

creates a new FV vector field of pressure gradientgiven a pressure fieldp. Calculus operators carrythefvc:: prefix.

Discretisation operates on differential operators(rate of change, convection, diffusion), and createsa discrete counterpart of the operator in sparse ma-trix form. Discretisation operators carry thefvm::prefix.

PHYSICAL MODELLING

Physical Modelling Library. Taking object ori-entation further, one can recognise object familiesat the physics modelling level. For example, allRANS turbulence models answer to the same inter-face: evaluate the Reynolds stress termu

′u′ in the

momentum equation based on the mean flow ve-locity u. Grouping them together guarantees inter-changeability and decouples their implementationfrom the rest of the flow solver. A turbulence modelcontributes a discretisation matrix to the momen-tum equation, usually consisting of a diffusion termand explicit correction and no special knowledge ofa particular turbulence model is needed at the toplevel.

Physics Solver. The components described so faract as a numerical tool-kit used to assemble vari-ous physics solvers. Each flow solver is a stand-alone tool, and handles only a narrow set of physics,eg. turbulent flow with LES, or partially premixed

combustion. Capability of such solvers is under-pinned by a combination of complex geometry sup-port and massive parallelisation.

OpenFOAM TURBO TOOLS

The “general purpose” CFD capability of Open-FOAM brings us close to practical turbomachin-ery simulations, but not sufficiently so. First suc-cessful attempts relied ondynamic mesh handling[1, 4] and automatic mesh motion [5, 6]. Here, com-ponents in relative motion are connected using asliding interface which, relying on polyhedral meshsupport, re-connect two parts into a single domain.A sliding interface operates by projecting the pair ofsliding surface onto each other and replacing orig-inal faces with facets, thus defining a singly con-nected polyhedral mesh, Fig. 1. In cases of dynamicmesh motion, face cutting is repeated for each topo-logically new relative position of two sides.

rotor side

stator side

rotor side

stator side

������������������������������������������������������

������������������������������������������������������

������������������

������������������

��������������������������������

��������������������������������

Figure 1: SLIDING INTERFACE AND GGI INACTION: FACETS REPLACING A FACE.

The beauty of a sliding interface and other topolog-ical changes is that no further intervention in thecode is necessary: equation discretisation handles

5

the topology change as a moving mesh, without theneed for solution mapping.

While a sliding interface is appropriate for caseswhere the complete sliding rotor-stator interface ismodelled, Fig. 2, single-passage simulations, Fig.3, cannot be easily performed. Furthermore, cost oftransient simulations with topological change oc-curing at every time-step is about 20% higher thanin static mesh simulations.

To mitigate this, we shall develop non-intrusive in-terface handling techniques operating at discretisa-tion level (as opposed to topological mesh changes)and generalise them for various interface types.

Figure 2: ERCOFTAC CENTRIFUGAL PUMP.

Figure 3: SINGLE PASSAGE SIMULATION,PARTIAL OVERLAP AND CYCLIC GGI.

General Grid Interface (GGI). Referring to Fig.1 one can establish that a cell left of the interfacecommunicates with a number of cells on the right,depending on relative face overlap. It is possible tointerpret the effect of facets by a facet-area-basedinterpolation scheme across the interface, whichacts on discretisation identically as a sliding inter-face. Interpolation stencil is established by geomet-rical consideration and weighting factors are calcu-lated as area ratio of the facet and the complete face,

[7]. With careful discretisation, implicitness of thecoupling, second order of accuracy and strict massconservation across the interface is preserved.

In practice, mesh sliding with a GGI interface oper-ates in the manner identical to a topologically slid-ing mesh, but changes are contained in weightingfactor calculation.

Cyclic GGI. A non-intrusive technique such asGGI allows us to easily handle cases where themesh does not match across the pitch, Fig. 4. Flexi-bility of the code in handling non-matching cyclic-ity greatly facilitates mesh generation for morecomplex blade shape.

Figure 4: NON-MATCHING CYCLIC GGI.

In terms of implementation, the GGI interpola-tion is combined with a coordinate transformationacross the patch. The slave side of a cyclic GGIis transformed to fall on top of the master andweights evaluation is used without change. For cou-pled boundary update (implicit or explicit), field

6

data next to the cyclic boundary will undergo a co-ordinate transformation to account fore.g. anglespan. Basic numerics and implicit coupling is iden-tical to the GGI interface above.

Figure 5: PARTIAL OVERLAP GGI INTER-FACES IN A MULTI-STAGE COMPRESSOR.

Figure 6: PARTIAL OVERLAP INTERFACE INROTATION.

Partial Overlap Interface. In a partial overlapinterface, Fig. 5, one chooses to simulate non-matching pairs of rotor-stator interfaces, assumingrotational symmetry. It is assumed that the uncov-ered part of the interface corresponds to a copy ofexisting geometry, transformed by the cyclic angle.Depending on user specification, the “upstream”

and “downstream” mesh may include either a singleor multiple blade passages, possibly allowing for acertain degree of passage-to-passage flow variation.

Simulations of this kind may be performed as tran-sient moving mesh cases, Fig. 6, or in a steady-statemode, using MRF.

In terms of implementation, partial overlap inter-face is a variant of GGI where patches are expandedto create a complete mapping surface. Once a pairof mapping surfaces is established, field data istransformed accordingly and a GGI interpolator isused. For field updates, only a part of mapping sur-face is sampled, depending on the relative positionof two sides.

Figure 7: A STEADY-STATE SIMULATION OF AHYDRO-TURBINE ASSEMBLY USING A MIX-ING PLANE AND MRF.

7

Mixing Plane Interface. The final variant of astage interface incorporates surface averaging to re-move unsteadiness caused by passage-to-passageflow variation and blade wakes from the solutionat the shadow side, both upstream and downstream.

While a mixing plane filter causes a one-time lossassociated with mixing, it is extremely useful inpractical simulations because it allows a funda-mentally transient problem to be studied in steady-state, with the help of MRF. Example assembly of asteady-state turbine problem, with a section of inletvane (blue), a rotor section (green) and a full drafttube geometry (red) is shown in Fig. 7.

Figure 8: MESH AT A MIXING PLANE.

At the mixing plane, meshes do not match and donot offer full coverage Fig. 8.

A mixing plane interface defines a set of oriented

ribbons at the coupled boundary over which the so-lution is averaged, schematically shown in Fig. 9.

Figure 9: MIXING PLANE INTERPOLATOR.

Size distribution of mixing plane ribbons, denotedas G in Fig. 9, [8]. is established automatically fromthe upstream and downstream patch, marked as Uand D, respectively. Each side will see the solutionat its shadow as a set of averaged values for eachribbon. Clearly, ribbons of the mixing plane may bedefined in an arbitrary coordinate system and orien-tation, which in turn defines the manner of filtering.

Based on the above, implementation of a mixingplane interface is straightforward. When the 1-Dribbon profile is established, ribbons are expandedspanwise. Two GGI interpolators are set up, withthe ribbon patch acting as master in both. On datatransfer, fields from patches U and D are trans-formed into the reference position at the ribbonand interpolated onto the master. Geometrical struc-ture of mixing plane ribbons with respect to origi-nal patches will implicitly perform averaging. Theshadow side uses the second GGI interpolator to ex-pand the ribbon data onto the complete patch. Mix-ing plane averaging takes place naturally within twoGGI interpolations, as a consequence of shape ofthe mixing patch and facet area-based assembly ofGGI weights [7].

IMPLEMENTATION LAYOUT

In what follows, some details of implementation ofturbo tools in OpenFOAM shall be given.

Rotating Frames of Reference. Single rotatingreference frame simulations are achieved throughreformulation of the momentum equation in termsof relative velocity, with addition of centrifugal andCoriolis forces to the source terms. Looking at ex-amples of code implementation, this is a straight-forward task. In order to facilitate user interaction,boundary conditions forurel are extended to allow

8

the user to specify a boundary velocity either in arotating or in a stationary frame of reference.

For multiple rotating frames, rotation-relatedsources are only present in parts of the domain. Inthe absolute velocity formulation, u is used as theworking variable and the MRF model assembles theCoriolis source term from regions rotating at dif-ferent speeds. Volumetric face flux is calculated di-rectly for the fictitious moving mesh velocity, basedon ω × r for the rotating coordinate system. In therelative velocity formulation, urel is chosen as theworking variable and forces resulting from rotationare added to the momentum equation in the rotatingreference frame. For consistency, jump conditionsin urel are required at stage interfaces.

The absolute velocity formulation, is preferred: itdoes not require a transformation of the velocityvector at the interface between rotating zones, mak-ing the code easier to handle.

Coupled Boundaries. All stage interfaces de-scribed in this paper full under the interface ofa coupled boundary condition in OpenFOAM andshare a number of desirable properties:

• Interpolation operator is symmetric in allcases and no further information is required,e.g. on flow direction at the interface or inte-gral variable adjustments;

• Data transfer is localised to the cell layer nextto the interface and may be accompanied bycoordinate transformation depending on in-terface type;

• GGI weights calculation algorithm is sharedbetween different types of interfaces. GGIinterpolation operator based on geometricweights assembly [7] has proven to be strictlyconservative in the context of FV discretisa-tion.

OpenFOAM handles coupled implicit interfacesthrough a set of virtual function updates, occur-ing at patch field evaluation and matrix-vector op-erations which represent a basis of linear equationsolvers. Other places in the code are served by geo-metric interpolation coefficients and face area vec-tors. When a coordinate transformation is requiredin data exchange across the interface, it is served

through a virtual function interface, fetching andtransforming information from the shadow side.

Examples of implicit coupled interface in Open-FOAM include a cyclic or processor boundary.All new boundary conditions adhere to the sameinterface: as a result, no further changes are re-quired anywhere in the software and all imple-mented physical models can readily use the turbotools functionality.

EXAMPLES OF TURBOMACHINERYSIMULATIONS

In what follows, we shall illustrate the performanceof OpenFOAM flow solvers utilising turbo tools.

The ERCOFTAC Centrifugal Pump. A de-tailed study of the ERCOFTAC centrifugal pumpwith a vaned diffuser has been presented by Pe-tit et al. [9]. Fig. 2 shows the mesh with the rotorcoloured in blue; a mesh detail shows that the rotor-stator interface does not match at and stage of thesimulation.

Figure 10: ERCOFTAC CENTRIFUGAL PUMP,VELOCITY FIELD.

Due to full coverage between the rotor and stator,both dynamic mesh and GGI may be used. Simu-lation has been performed in transient mode usinga GGI interface. Fig. 10 shows a snapshot of thevelocity field magnitude. The rotor-stator interfaceis invisible in the solution, indicating no problemswith the performance of GGI. Substantial passage-to-passage flow variation has been observed. For

9

further details of case setup, flow conditions andexperimental comparison of simulation results, thereader is referred to [9].

Simulation of Marine Propulsors. Kim et al.[10, 11] report a series of simulations on predictionof cavitation and performance of marine propellersand axial flow water-jer propulsors. For the water-jet, the case setup is schematically identical to Fig.2, with a single fully covered GGI interface. Sim-ulations of propellers in open water utilises the ge-ometry of a single blade passage and a steady-statesimulation in a single rotating frame of reference.For such meshes, a cyclic GGI is used to handlepitch-wise non-matching mesh. Fig. 11 shows thepressure distribution on the blade and a mesh struc-ture of cyclic GGI patch.

Figure 11: SINGLE PROPELLER BLADE WITHA CYCLIC GGI INTERFACE.

Mixing plane simulation of a Francis Turbine.Beaudoinet al. [8] report a steady-state simulationof a Francis turbine, using the MFR model and twomixing plane interfaces. A 195-MW Francis tur-bine is shown schematically in Fig. 7. Details ofthe mesh at the interface between the single pas-sage mesh for the Francis runner and the completegeometry of the draft tube are shown in Fig. 8.The mesh for the complete geometry consists of 2.2million cells, Fig. 12. Simulations have been per-formed at part load, maximum efficiency and max-imum power.

Fig. 13 shows the pressure distribution at distributormid-height for the stator and runner at three oper-ating conditions, illustrating the performance of themixing plane.

Figure 12: FRANCIS TURBINE MESH ASSEM-BLY WITH TWO MIXING PLANES.

Figure 13: PRESSURE DISTRIBUTION AT DIS-TRIBUTOR MID-HEIGHT.

The most notable difference in flow structure is vis-ible in the draft tube. Under part-load conditions,the vortical flow is not well organised and showssubstantial transient effects, while at optimum effi-ciency and single large-scale vortex is formed in-stead. FOr further details, the reader is referred to[8].

10

Figure 14: FLOW FIELD IN DRAFT TUBE.

Figure 15: SIMULATED AND MEASURED EF-FICIENCY OF A FRANCIS TURBINE.

For the chosen geometry, on-site efficiency mea-surements are available for low head and nominalhead. Losses and efficiency predicted by CFD sim-ulations can be compared to on-site experimentalmeasurements in shown in Fig. 15. Agreement atthis stage is not perfect, with some of the blame at-

tributed to lack of mesh resolution in critical partsof the domain, simplification of flow conditions atthe mixing plane and choice of turbulence model.

SUMMARY

This paper describes the formulation and imple-mentation of turbo tools in OpenFOAM, designedto enable the code to deal with typical techniquesfor CFD simulations of rotating machinery. Object-oriented design allows us to deploy the handlingfor rotor-stator interfaces and simulation in rotat-ing frames of reference with minimal interventionin existing source code.

Implemented features include handling for single-amd multiple rotating frames of reference and asuite of rotor-stator interface handling techniques.A General Grid Interface (GGI) mimics the opera-tion of a topological sliding interface by direct in-tervention at discretisation level. Interpolation sten-cil and weighting factors in GGI are calculatedfrom geometric considerations and are proven to bestrictly conservative. Other interfaces re-use the ba-sic interpolation functionality, accompanied by ap-propriate coordinate transformation or averaging.

With turbo tools, capabilities of OpenFOAM inturbomachinery simulations are significantly im-proved, aiming towards a truly versatile and effi-cient open source CFD solution.

ACKNOWLEDGEMENT

Authors would like to acknowledge the contribu-tion of partners and industrial sponsors support-ing this work in OpenFOAM, in particular ourcolleagues in the Turbomachinery Special InterestGroup.

BIBLIOGRAPHY

[1] Jasak, H: “Dynamic Mesh Handling in Open-FOAM”: 48th AIAA Aerospace SciencesMeeting, AIAA Paper, January 2009: Or-lando, FL.

[2] Weller, H.G., Tabor, G., Jasak, H., and Fureby,C.: “A tensorial approach to computationalcontinuum mechanics using object orientatedtechniques”,Computers in Physics, 12(6):620– 631, 1998.

11

[3] Jasak, H.: “Multi-Physics Simulations in Con-tinuum Mechanics”, InProceedings of 5th In-ternational Conference of Croatian Society ofMechanics, Trogir, page ?? Croatian Societyof Mechanics, September 2006.

[4] Jasak, H. and Tukovic, Z: “Dynamic MeshHandling in OpenFOAM Applied to Fluid-Structure Interaction Simulations”, In Pereira,J. C. F. and Sequeira, A., editors,ECCOMASCFD 2010, June 2010.

[5] Jasak, H. and Tukovic, Z.: “Automatic MeshMotion for the Unstructured Finite VolumeMethod”,Transactions of FAMENA, 30(2):1–18, 2007.

[6] Lucchini, T., D’Errico, G., Jasak, H., andTukovic, Z.: “Automatic mesh motion withtopological changes for engine simulation”:SAE Technical Paper 2007-01-0170, 2007.

[7] Beaudouin, M. and Jasak, H.: “Develop-ment of a General Gid Interface for tur-bomachinery simulations with OpenFOAM”:Open Source CFD International Conference,November 2008.

[8] Page, M., Beaudoin, M., and Giroux, A.-M.:“Steady-state Capabilities for Hydroturbineswith OpenFOAM”,Int. J. of Fluid Machineryand Systems, 4(1):160–170, Jan-Mar 2011.

[9] Petit, O., Page, M., Beaudoin, M., and Nils-son, H.: “The ERCOFTAC Centrifugal PumpOpenFOAM Case-Study”, In3rd IAHR Inter-national Meeting of the Workgroup of Cavita-tion and Dynamic Problems in Hydraulic Ma-chinery and Systems, pages 523–532, Brno,Czech Republic, October 2009.

[10] Kim, S.-E., Scroeder, S., and Jasak, H.: “AMulti-Phase CFD Framework for Predict-ing Performance of Marine Propulsors”, InThe Thirteenth International Symposium onTransport Phenomena and Dynamics of Ro-tating Machinery (ISROMAC-13), Honolulu,Hawaii, April 2010.

[11] Schroeder, S., Kim, S.E., and Jasak, H.:“Toward Predicting Performance of an Ax-ial Flow Waterjet Including the Effectsof Cavitation and Thrust Breakdown”, InFirst International Symposium on MarinePropulsors , Trondheim, Norway, June 2009:http://www.marinepropulsors.com/.

12