Calcolo Scientifico

Swiss Center for

Centro Svizzero di

Scientific Computing

CSC

S

SC

SC

A Visualization Systemfor Turbomachinery FlowMartin Roth

TECHNICAL REPORTTR-96-05 April 1996

OTHER PUBLICATIONS BY CSCS/SCSCAnnual Report: yearly review of activities and projectsCrosSCutS (triannually): newsletter featuring announcements relevant to our users aswell as research highlights in the eld of high-performancecomputingSpeedup Journal (biannually): proceedings of the SPEEDUP Workshops on Vector andParallel Computing, published on behalf of the SPEEDUPSocietyUser's Guide: manual to hardware and software at CSCS/SCSCTo receive one or more of these publications, please send your full name and complete addressto: LibraryCSCS/SCSCvia CantonaleCH-6928 MannoSwitzerlandFax: +41 (91) 610 8282E-mail: library@cscs.chTechnical Reports are also available from:http://www.cscs.ch/Official/Publications.htmlA list of former IPS Research Reports is available from:http://www.cscs.ch/Official/IPSreports.html

A Visualization Systemfor Turbomachinery FlowMartin Roth1April 1996Abstract. Fluid ow visualization for turbomachinery has been a major project atthe SCSC visualization lab for the last few years. In this report, we introduce to theapplication area, state its special requirements regarding visualization and describea system to meet them. This text assumes basic knowledge in ow visualizationand discusses additional features and improvements of standard algorithms.The results have been implemented in the visualization program Flux for SiliconGraphics machines (using C, GL, Forms) for interactive visualization of turboma-chinery ows and video animations. Key elements are also implemented as a set ofAVS modules.

Keywords. turbomachinery CFD, ow visualization, streamline calculation, particle traces,hydraulic turbines1 Swiss Center for Scientic Computing, ETH Zurich, CH-8092 Zurich, Switzerlandroth@scsc.ethz.chCSCS/SCSC Technical Report 1

2

Table of Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Turbomachinery and Hydraulic Machines . . . . . . . . . 5

2.1 Introduction .................................................................................. 5

2.2 Structural Elements of a Hydraulic Turbine................................. 6

2.3 Turbulence, Vortices, Reversed Flow and Cavitation.................. 9

2.4 Design of Water Turbines .......................................................... 10

2.5 Role of CFD in the Design Process ............................................ 11

3 Visualization of Turbomachinery Flow. . . . . . . . . . . 13

3.1 Basic CFD Flow Visualization Techniques ............................... 13

3.2 Turbomachinery CFD Issues ...................................................... 14

3.3 Overview of a Flow Visualization System................................. 16

4 Technical Issues of CFD Visualization . . . . . . . . . . . 19

4.1 Particle Traces and Streamlines.................................................. 19

4.2 Stream Surfaces .......................................................................... 22

4.3 Finding Points in Computational Space ..................................... 23

4.4 Smooth Keyframe Camera Animation ....................................... 24

4.5 Texture Mapping for Pseudocoloring......................................... 24

4.6 Drawing Polygon Borders .......................................................... 25

4.7 Other Implemented Features ...................................................... 26

4.8 Conclusions ................................................................................ 27

5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 Turbomachinery and Hydraulic Machines ................................. 28

5.2 CFD Flow Visualization............................................................. 28

5.3 Software...................................................................................... 28

5.4 Color Figures .............................................................................. 28

3

1 Introduction

Fluid flow visualization for turbomachinery has been a major project at the Visualization Lab of

SCSC (Swiss Center for Supercomputing) at ETH Zurich (Federal Institute of Technology) in recent

years. In collaboration with our industry partner Sulzer Hydro Zurich (Escher-Wyss), a system was

developed to meet the specific requirements of turbomachinery flow visualization.

This report is intended for readers with some knowledge in Visualization of CFD (Computational

Fluid Dynamics) flows. It serves two different purposes: the first is to provide an introduction to the

field of application and list special requirements of a CFD visualization system for turbomachinery

design. Second, it contains some of the methods used, together with comments and motivations for

the solutions chosen.

In the following chapter, we will establish the most important concepts and terminology of turboma-

chinery and introduce the main application for our visualization program, namely the design of

hydraulic machines (water turbines, pumps and pump-turbines). We will explain the basic process of

hydraulic design and the role CFD plays in this process.

In the third chapter, we look closer at how visualization is used routinely to support hydraulic designs.

We will point out special requirements for turbomachinery visualization as compared to other appli-

cations of CFD like aerodynamics. A brief overview of a visualization system for turbomachinery

flow concludes this section.

The fourth chapter will then provide some important building blocks of this visualization software,

specific information about the methods chosen, algorithms used or point out features which are not

common in other visualization systems. This section is an attempt to write down all the small algo-

rithmic details, thoughts and minor improvements as implemented in our current system.

This technical report intends to wrap up the previous work of developing a flow visualization program

adapted to the needs of turbomachinery design and using the basic flow visualization techniques

(streamlines, particle paths). It describes the system now serving as a foundation of our current

research project, which aims at automatic recognition of features in turbomachinery fluid flow.

4

Figure 1: Hydraulic turbine installation and powerhouse.

5

2 Turbomachinery and Hydraulic Machines

2.1 Introduction

A turbomachine is a device transferring mechanical energy from a rotating part called runner into a

fluid or vice versa. If energy is taken from the fluid, the machine is called a turbine, if it is added to

the fluid (in form of higher pressure), it is called a pump. In case of gas flow, a pump with a very small

difference in pressure between inlet and outlet is a fan, whereas a device for building a very high pres-

sure difference is a compressor.

Turbomachines are the major part of jet engines, which contain both a compressor and a turbine with

several stages; modern ones additionally feature a large fan. In the following text however, we will

focus on hydraulic machines, that is, turbomachines which operate on water (or other liquids).

Hydraulic turbines are designed for service at hydroelectric power plants, driving electric generators.

A diagram of a turbine installation is shown in Fig. 2, a real powerhouse in Fig. 1.Water is directed

from the headwater via a pressure conduit to the turbine and is finally discharged into the tailwater.

In the turbine, fluid energy is converted to a large part into mechanical energy of the rotating shaft,

which in turn drives the generator.

The two most characteristic figures of a turbine installation are its head and flow rate. The (static)

head is the difference in elevation between the head- and the tailwater, measured in meters. The flow

rate (or discharge) in m3/s describes the amount of fluid volume passing through the turbine each sec-

ond. Depending on the values of head and flow rate, turbines take a variety of shapes. Two examples

are shown here. A Francis turbine (Fig. 3) is used for installations with relatively high head (approx.

Figure 2: diagram of hydraulic turbine installation

headwater

tailwater

static

generator

shaft

electric power

penstockturbine

drafttube

head

6

40 to 800 m) and relatively small flow rates. It is mainly used for (often artificial) lakes several hun-

dred meters above the power station. A Francis turbine can be reversed, i.e. it can be operated as a

pump. This allows to build pump-turbines, which are designed to operate both in pump and turbine

mode. With such machines, cheap excess electricity at night can be used to pump water up, whereas

the same machine operates as a turbine at peak hours during the day, when electricity can be sold at

a higher price.

Another example is a Kaplan turbine, show in Fig. 4. It is installed usually in river power plants, which

have a very small head (a few meters to about 60 m) and a large flow rate. This is an axial turbine (the

fluid flows along the axis in the runner), whereas the Francis turbine is called radial or mixed-flow

(since the inflow is radial, whereas the outflow is axial). A speciality of Kaplan turbines is that the

runner can contain a gear to make the runner blades turn, allowing to optimize blade angles for dif-

ferent flow rates during operation; these turbines are called adjustable.

2.2 Structural Elements of a Hydraulic Turbine

Whatever the type of turbine, we can identify several identical elements in each of the designs. We

will follow the flow downward for a turbine and name the essential structures; see also Fig. 3 and 4.

The water from the headwater flows through intake and penstock, which are both not considered here.

It then enters the actual machine and has to be distributed uniformly over the entire periphery of the

turbine entry, which is the task of a spiral casing (element A in Fig. 3 and 4; top view Fig. 5). It is

built either of steel (for high heads, Fig. 3) or reinforced concrete (Fig. 4). The shape often is not a

smooth spiral, but built from many sections of straight cone segments as in Fig. 5. The main design

Figure 3: Francis turbine (model). A: spiral casing, B: stay vanes, C: guide vanes (wicket gate),D: runner blades, E: crown, F: shaft, G: (cone of) draft tube, H: band

A ABB C CDD

G

F

E E

H

H

7

goal for the spiral is to provide a uniform inflow for the actual turbine by distributing the mass flow

even around the turbine and achieve a constant inflow angle.

The main purpose of the stay vanes (element B in Fig. 3 and 4) is not connected with the water flow,

but simply to serve as a stuctural support for the weight of the machinery. They are usually built such

as to interfere with the flow as little as possible.

The guide vanes (also called wicket gate, element C in Fig. 3 and 4) are a ring of blades which can be

rotated around a vertical axis. They can be turned so as to completely close the passage (hence the

name gate). During operation, the guide vanes are the main element to regulate the mass flow. Note

that the inflow angle for the runner increases as the guide vanes are opened for more mass flow. For

runners which are not adjustable, this implies that the runner has to be optimized for a certain mass

Figure 4: Kaplan turbine. A: spiral casing, B: stay vanes, C: guide vanes (wicket gate),D: runner blades, E: hub, F: shaft, G: (cone of) draft tube

A ABCCB

D D

E

F

G

8

flow and resulting angle; a decrease in efficiency occurs if the flow rate deviates from this design

point.

The rotating part of the machine comprises the runner (D and E; for pumps usually called impeller),

the rotor of the generator and the shaft (F) transmitting the rotation. The runner blades (D) are

designed to convey the energy from the fluid as efficiently as possible into rotational torque. The part

mounted on the end of the shaft and holding the blades is called the crown or hub (E). For Francis

machines, the band (or shroud, element H in Fig. 3) is connected to the runner blades as well and is

part of the runner, rotating with the blades and the crown. For Kaplan machines, the blades are only

mounted at one end (on the hub) and the casing does not rotate; this requires a small gap between the

tip of the blades and the casing (generating turbulent leak flow and gap cavitation in the tip clearance).

The combination of stator and rotor blades is often called a stage. Unlike water turbines, turboma-

chines in gas turbines and pumps for very high pressure differences such as in jet engines contain sev-

eral stages (alternating rows of stator and rotor blades, the rotor blades all connected to the same

shaft).

After passing the runner, the water flows through the draft tube (G) to be discharged into the pool of

tailwater. For machines mounted with the shaft vertically (as shown in the figures), the draft tube con-

tains a bend; all draft tubes have a significant increase in cross-section area in direction of downflow.

For axial flow machines with a horizontal axis (Bulb type turbines, Straflo (straight flow) turbines),

the shape is roughly conical. For vertical axis turbines, elbow type draft tubes are used, typically

shaped as sketched in Fig. 2. Often, there is also a gradual change from the round draft tube inflow to

a rectangular shape towards the exit.

Because of the increasing cross-section area, the draft tube slows down the flow speed. This also

results in a lower pressure at the inlet then at the exit. Decreased pressure at the runner outlet contrib-

utes to a higher pressure difference for the runner (as compared to a simple straight pipe instead of the

draft tube), and thus adds to the static head. For the design of new power plants, the draft tube is very

important, since it determines shape, size and maximal depth of the lower part of the installation;

because of cavitation, the turbine often has to be mounted below the tailwater level.

A good reference for more information about hydraulic machines is [1]. Some typical flow phenom-

ena in such machines are described in [2].

Figure 5: scroll-shaped spiral casing (steel)

9

2.3 Turbulence, Vortices, Reversed Flow and Cavitation

Turbulence is a small and highfrequent fluctuation of flow speed, flow direction and pressure. Zones

of high turbulence develop mainly in boundary zones associated with solid surfaces, but turbulence

is also transported along with the flow and dissipated. Usually, the actual flow is modeled as an aver-

age flow component plus a chaotic turbulent flow component. For pressure, this can be seen in Fig. 6

(left): the instantaneous pressure can be decomposed into an average pressure pa plus pressure fluc-

tuations in the order of p.

The most important (unwanted) flow features occurring in hydraulic machines are vortices, regions

of reversed flow and cavitation. A vortex is a structure of swirling flow. Unfortunately, there is no

precise definition of a vortex available. Because of the strongly curved channels and large pressure

gradients occurring in turbomachines, vortices can not sufficiently be isolated by setting a threshold

of vorticity or magnitude of curl. A project attempting to automatically extract such structures from

flow data are currently underway at ETH Zrich/SCSC. Of course, the swirling motion contains

energy which cannot be used in a turbine, and thus vortices lead to loss in efficiency. Furthermore,

low pressure and high flow velocity often associated with a vortex centers may cause cavitation.

In off-design operation, such as when a turbine is run at a reduced flow rate, regions can appear where

the flow is opposite to the intended direction, associated with vortices or high turbulence. To avoid

such condition, it is important to see where such regions of reverse flow begin to form and how they

develop with varying conditions of operation.

When water is subject to a pressure below that of saturated water vapor, it starts to develop cavities

filled with vapor instead of liquid water. The pressure of saturated water vapor pw.v depends on tem-

perature and is around 2 kPa at 18 C. In its early phase, incipient cavitation shows up as small bub-

Figure 6: Left, typical turbulent variation of pressure over time. Right, cavitation bubbles.In the area of collapsing bubbles, high erosion takes place.

10

bles, originating at points where the instantaneous pressure drops below vapor pressure (Fig. 6, right).

These bubbles are transported downstream until they enter a region where the instantaneous pressure

is again higher than pw.v, where the bubbles collapse. The problem of cavitation is that the sudden

collapse (implosion) of these bubbles cause very high instantaneous pressure at the center of the col-

lapsing bubble, leading to shock waves in the water. When bubbles implode near solid surfaces, the

constant high frequency hammers cause erosion of the surface and lead to severe cavitation damages.

2.4 Design of Water Turbines

To understand the field of application for our flow visualization projects in collaboration with Sulzer

Hydro, Ltd. (formerly Escher Wyss), we will have to explain some basics of the process of designing

water turbines and pumps. The significance of CFD simulations for this process will be explained in

the next section.

Water turbines are very large units manufactured and designed individually. To get an idea of the size,

one can look at Fig. 1 and 8, or at the measurements (in mm) in Fig. 4 and 5: the runner of the Kaplan

Figure 7: Typical contour plot of efficiency versus flow rate Q (horizontal) and head H (vertical)for a certain turbine (diameter 6.3 m, rotation speed 88.3 rpm).

11

turbine shown in Fig. 4 has a diameter of 5.8 m and the shaft measures 16 m; the spiral casing in Fig.

5 is 16 m by 18 m. These large machines can be made fairly efficient: today, efficiencies for water

turbines exceed the level of 93% (see Fig. 7). Since any increase in efficiency is directly proportional

to an increase in profit that can be made with the machine, it is still an important issue to improve

hydraulic performances of the machine. A typical hill chart (contour plot) of efficiency levels can be

seen in Fig. 7: isolines of efficiency () are plotted against head and discharge for a certain turbine.

Limiting lines (with shading) occur because of the maximal opening of the guide vane (limit towards

lower right) and maximal rating of the generator (limit towards upper right).

Often as important as achieving a high efficiency under the most often used operating conditions (in

the vicinity of the design point) is to keep the efficiency as high as possible when deviating from the

design conditions. Whereas the head is usually given and does not vary that much, some turbines

might often be used with a lower (or sometimes higher) flow rate than the one specified as the design

point.

Cavitation near solid surfaces leads to high erosion as described above and therefore has to be

avoided. This can be achieved easily by mounting the turbine far below the level of tailwater and thus

increasing the overall pressure in the machine (while the head stays the same, of course). However,

every meter the turbine must be lowered into the ground adds substantial costs while building the

power plant, so that designers are forced to place the machine as high as possible.

The main task of the designers of turbines is to find a design that best fulfills the customers expecta-

tions. The design process is not simply a straightforward calculation leading to an optimal design, but

a best compromise between the various design goals must be found. This is a process that can not

be automated and relies mainly on know-how and experience of the designers. For this task the

designers have physical laws, model experiments and computer simulations at hand to try to predict

flow and compare designs.

2.5 Role of CFD in the Design Process

During the design phase of a turbine, a scaled model (diameter of the runner around 30 cm) is usually

built and measured on a test stand. However, these model tests are fairly expensive and time consum-

ing. Computer simulations are not actually done to replace the model test stands completely, although

in the last years, more and more designs have been carried out without model tests, relying solely on

CFD. However, the CFD simulations are always used to test several alternatives and select the best

one before an actual machine or model is built.

This process allows for some (necessary) simplifications in the CFD models, since not everything

needs to be determined by the computer simulation. An example is a parameter called runaway speed,

the rotation speed the turbine will take on when under emergency conditions, the load suddenly drops

to zero (i.e. generator cut from the power grid). This number is important for the mechanical design

of all rotating parts, which must withhold that maximum speed. The runaway speed can easily be

tested on a model, but would be extremely difficult and unreliable to predict with a CFD simulation.

The type of CFD model is, with exception of some research projects, a steady-state solution of the

Reynolds-averaged Navier-Stokes equations. As a study by Sulzer Hydro has shown, the flow close

to the design point can be fairly well predicted with the even simpler (and thus less time-consuming)

model of the Euler equations (not taking into account the effect of viscosity); for simulations of oper-

ating conditions at excess or partial load however, taking into account the viscous effect is essential.

12

In the process of designing a new turbine, CFD is thus mainly used to do more of the optimization

prior to building a model. Also, the experience of the engineers and company history usually provides

a good starting point for a new design. In recent years however, projects for uprating [3] of existing

machines have become more important. Machines which were designed at the beginning of the cen-

tury often can be significantly improved with todays knowledge by redesigning only a part, usually

the runner, of a machine.

These upgrade projects are more difficult to design, since many constraints of the existing machines

are given. Changes to the large structures (spiral casing, draft tube) are not possible, yet they have an

important influence on the flow conditions for the runner and the overall performance of the machine.

For these projects, it has become even more important to run a variety of CFD design tests to find one

that provides best performance.

Figure 8: Photograph of a Francis runner.

13

3 Visualization of Turbomachinery Flow

3.1 Basic CFD Flow Visualization Techniques

In this report, we will entirely focus on visualization of CFD flows, as a subset of Scientific Visual-

ization, itself a field of Computer Graphics. It should be noted that people working with real flow

experiments use the term Visualization often for any process that makes the physical flow visible

(such as adding smoke or dye). However, we will not discuss any visualization of real experimental

flow here.

The engineers working at the numerical test stand [4] at Sulzer Hydro first of all rely on a long-

established, standardized scheme for the visualization of simulated flows simply called post-

processing. It runs entirely in batch mode and creates a number of pages with 2D arrow plots on the

solid surfaces (hub/crown, band, blades), pressure distributions and some 1D function plots. From the

pressure distributions on the runner blades the moment of the rotor and thus the power and efficiency

of the machine is calculated. An example page generated by this standard visualization postprocessing

can be seen in Fig. 9.

Figure 9: Typical post processing visualization output: 2D arrow plot of (relative) velocityat the band (left), in the middle of the channel (center) and at the crown (right).

14

Although these techniques may look rather simple from a point of view of someone familiar with

recent advances of Scientific Visualization and 3D graphics, these 2D plots allow a quick estimation

of the design and provide the essential numbers (such as efficiency) immediately. Regions of reversed

flow are readily apparent in the arrow plots. Since the whole set of plots is standardized, it simplifies

comparison between different designs and projects.

However, more advanced 3D flow visualization is needed for optimization details in new designs, to

understand problems and possible improvements in uprating projects. Furthermore, it is often used

as a medium of communication, for example by producing a video animation to be handed out to the

customer with the report. The visualization described in this report only deals with showing the flow

interactively in 3D.

Although the CFD simulations have to be simplified (i.e. time-averaged), and thus have significant

disadvantages and less reliability than a model test, CFD simulation and visualization offer some

major benefits as well, apart from being more cost-efficient. For example, CFD visualization allows

to look at details from any viewing angle while pieces of geometry obscuring the sight can be made

invisible or rendered translucent. This may permit improved understanding of the flow patterns and

their shape and distribution in 3D space, which is difficult to obtain from experimental techniques. As

turbomachinery continues to improve and efficiency approaches the feasible maximum, it will be of

increasing importance to understand the development of flow phenomena in 3D space. Flow visual-

ization as described in this reports aims mainly at providing tools to study complex flow patterns in

their spatial relation to the machine geometry.

The main technique to look at a flow field in 3D is to calculate streamlines (i.e. lines everywhere tan-

gent to the flow) from some start points. For time-dependent flows, it is important do discern stream-

lines from streak lines and path lines, but for steady flows as used for this application, all these three

coincide. We thus speak of streamlines, even though they are usually interpreted as particle paths

(path lines or traces). The program Flux for 3D turbomachinery flow visualization relies mainly on

traces and is outlined in section 3.3; technical key aspects are explained in chapter 4.

3.2 Turbomachinery CFD Issues

In this section, we will point out the properties of turbomachinery CFD data. Compared with other

CFD data, e.g. from aerodynamics, this field of application has some necessities which are often not

addressed by standard CFD visualization packages. This lack of support for turbomachinery data was

the reason for us to write a specialized visualization software, Flux.

The meshes used for turbomachinery CFD are, like in various other applications, structured meshed

shaped to fit the space in which the flow is calculated. In the terminology used by AVS, these fields

are irregular, 3D, 3-space, structured fields. However, the mesh typically fills only one channel (i.e.

the space between two blades). Since the flow is calculated as a steady flow (only varying in time due

to turbulence), it is safe to assume that the (time-averaged) flow is the same in all channels. Thus, only

one channel is actually modeled, which of course saves a lot of computation time. Depending on the

part of the machine, there are from around seven blades (for a runner) to more than 20 blades (stay

vanes). An example of how the grid is fitted to the geometry of a channel can be seen in Fig. 10.

Besides open (inflow, outflow) and solid boundaries, this introduces a new type of boundary condi-

tions, periodic boundaries. Flow that leaves the channel at these boundaries immediately enters again

at the boundary on the opposite side for the calculation to model the behavior of flow to and from

15

neighboring channels. For visualization, traces have to be tracked across channels. Although this is

relatively simple to do (calculation of traces will be detailed in section 4.1), hardly any CFD visual-

ization software offers this feature.

On each node of these meshes, a vector to represent direction and speed of flow and the pressure is

given. Furthermore, each node is assigned a point in space to describe the shape of the mesh. For cal-

culations taking into account the effects of viscosity, a turbulence model is used (k-), which adds two

scalars at each node. Due to the near incompressibility of water and its large temperature coefficient,

temperature and density of the flow is assumed constant (unlike CFD for air flow).

Each part of a turbine, like spiral casing or stay vanes, is simulated separately; but outflow conditions

from the spiral casing calculation is used as inflow for the stay vanes, for example. If the elements are

moving with respect to each other, such as in the simulation of a complete stage (stator and rotor), the

outflow field is averaged in tangential direction to yield a reasonable steady inflow for the next ele-

ment.

Although simulation is done separately for each element with coupling only over the inflow/outflow

boundary conditions, visualization should be able to display several elements together and track par-

ticles across the block boundaries.

Other CFD calculation techniques, such as multi-zone grids or i-blanking (undefined values for

grids not aligned with the geometry) are not used for industrial turbomachinery simulation and not

Figure 10: Typical mesh fitted into a channel of a Francis runner.

16

implemented in Flux. Also, handling of time-dependent simulations is not possible with the current

system. Except for few research projects though, only steady (time-independent) simulations are done

in this industrial context.

3.3 Overview of a Flow Visualization System

To address the issues of turbomachinery flow visualization raised in the previous section, Flux was

developed at ETH/SCSC in collaboration with Sulzer Hydro. In the following, you will find a brief

overview of the visualization system, whereas important features and algorithms used are outlined in

chapter 4.

Flux is written entirely in C, using IRIS GL [9] for all graphics operations (the project started before

OpenGL was available) and the public-domain library Forms [10] as the user interface kit. It fea-

tures one main window showing the 3D graphics and several smaller windows containing the buttons,

sliders and texts for user interaction. A typical screenshot is shown in Fig. 12, more examples in Fig.

13. Internally, Flux consists of a library handling user interaction, materials, lights, animation and

such, and a part which contains all application-specific parts (data structures for turbine data,

traces...). The library is used to create an additional abstract layer above the GL and Forms library,

allowing the application for example to allow simple definition of a 2D mesh surface; in this case the

application only supplies the coordinates (and possibly scalar data to be mapped as color onto the sur-

face). The library maintains all user interaction for materials, visibility and such, buffers the surface

in a display list (IRIS GL object) and even calculates the normals if not supplied by the application.

Parameters that can be changed with the user interface, such as material colors or light and camera

positions, can all be stored in files. Flux divides these parameters into three sets, which can be loaded

or stored separately: the view parameters contain only the things associated with the current view in

the graphics window (camera position, clipping planes and such). A set of rend (rendering) parame-

ters contain all the lights, materials, object visibility and similar settings. Both these settings store

state information from the intermediate library and are independent of the actual application. The fset

file stores settings of the actual application program Flux, which contain settings such as for example

the step size for trace integration. The possibility of storing and loading materials and views allows

to easily set the same view for different data sets, which is important when comparing different

designs or various points of operation.

Start points for traces (displayed as streamlines or moving particles) are specified externally in a file.

Points can be given in physical space or in computational space. With additional keywords, it is pos-

Figure 11: Streamlines displayed as ribbons (left) or candy-striped arrows (right)to enhance depth perception and depict local rotation along the streamline.

17

sible to start a whole rake or grid of traces at once. External small programs exist to generate random

but uniformly distributed traces on a plane or a cylinder surface, which are used to simulate a large

number of particles for video animation. Upon reading in a trace file, streamlines are calculated and

stored in memory, and can then be drawn in different styles (Fig. 11).

Color can be used to display a scalar value, either one supplied with the simulation data, such as pres-

sure, or calculated (e.g. specific total energy of the fluid, or flow speed). A colormap can also be read

from a file for this purpose. Some notable features are mentioned in the next chapter.

In parallel to the Flux application, the same main functionality was also built into a number of modules

for the AVS visualization system [11] used in-house at ETH/SCSC for visualization research. These

modules offer a different, open way to work with Flux data, using the same data files and sharing

important routines with the stand-alone applications (e.g. trace integration, point location, surface def-

initions).

Figure 12: Typical screenshot of Flux, showing a Kaplan turbine anda few streamlines (relative flow).

18

Figure 13: Flow in spiral casing (top) and in a Kaplan turbine (lower left);Flow detachment at a stay vane leading edge (lower right).

19

4 Technical Issues of CFD Visualization

This chapter will discuss some technical aspects of the Flux visualization system (also paralleled by

a set of AVS modules) developed at ETH/SCSC. We assume the reader is familiar with the basics such

as the various methods for calculating streamlines and will only discuss which methods we picked for

this application and why. Furthermore, we will point out important issues or refinements of methods

as implemented.

4.1 Particle Traces and Streamlines

For calculating traces, our basic decision was to use a second-order Runge-Kutta method in compu-

tational space with fixed spatial step size [5]. To understand this decision, we have to look at the basic

choice given. A comparison between some integration methods can be found in [6]. Various sources

of errors in CFD visualization are analyzed in [7].

The computation intensive part of the calculation for physical space is the point location, i.e. finding

the computational coordinates of a point given in physical space, to then obtain the flow vector at that

location. The vector itself can be simply interpolated from the data given on the grid once the position

in computational space is known.

On the other hand, for methods stepping in computational space, the physical coordinates can easily

be interpolated from the cell corners, but the compute intensive part is to determine the flow vector

with respect to computational space.

The two methods seem roughly equivalent when comparing execution speed. Sometimes it is argued

that for the computational space method, the velocities at all grid points can be precomputed once,

which would give that method a potential advantage in speed. However, when done correctly as

explained in the next paragraph, there is need to store eight Jacobian matrices for each cells, or 72

additional floats per node (except at borders). Since it is typically not possible to allocate that many

times the memory required for the vector field itself, precalculation of the computational space vector

field is not an option.

Some care has to be taken for the calculation of flow vectors in computational space. We need the

correct Jacobian (of the coordinates) to transform vectors between the two spaces. To get the Jacobian

at the grid points, derivatives have to be approximated by differences. In principle, several choices

can be made for each corner: forward, backward or central differences. However, in order to get a con-

sistent transformation for each cell, the only possibility is to use the coordinates of that cell exclu-

sively; sometimes, this scheme is called forward/backward difference. This leads directly to the eight

different Jacobians per node, since there are eight cells bordering each node, and thus eight different

selections of differences depending on which cell you want to get a transformation for.

The process can be simplified by, instead of interpolating the Jacobian from each corner, calculating

only a vector in each corner and interpolating those; however, some accuracy is lost. Further simpli-

fication can be done by averaging the eight corner velocities, but this leads to significant loss of accu-

racy. In comparisons between physical and computational space methods, these inaccuracy stemming

20

Figure 14: Variants of computational space integration methods for a test mesh withfour cells and constant vertical motion in physical space. Lines with different gray

value and line width show resulting streamlines with three different methods.

Physical Space

Computational Space

Legend:

8 Jacobians/cell

8 velocities/cell

1 velocity/node

21

from the inconsistent choice of differences for the Jacobians or wrong interpolation sometimes are

attributed to the computational space method in general, which is not the case though. When calcu-

lating a parameter space vector, first the eight jacobians from the corners have to be interpolated to

the desired location, and then the physical vector at that location (also interpolated from the data at

the corners) can be computed. If implemented that way, the method for integration in computational

space is equivalent to integration in physical space using trilinear interpolation.

It is important to realize that the flow field, although assumed to be continuous in physical space, can

be highly noncontinuous in computational space in places where two neighboring cells in the grid are

very different in shape or size. The flow field in computational space is only continuous inside a cell,

but may jump when crossing cell boundaries. Its these discontinuities that lead to large errors when

computational vectors are averaged by using central differences as described previously.

Fig. 14 shows a comparison for streamlines in an especially critical mesh, consisting of four cells and

having constant vertical motion at all vertices. The thin black line, corresponding to the method with

interpolation of eight Jacobians shows the correct result. An error is introduced by precalculating

eight parameter space vectors at the cell corners and interpolating them (middle gray, middle line

width). Further simplification to just one averaged vector in computational space leads to a large error

(light gray, wide line).

For the same reasons, its important during each step of the integration of streamlines, that only vec-

tors from the current cell are used inside this cell. We solved this problem by using an integration loop

that steps either a fixed length in computational space (typically about one fifth of a cell), or to the

next cell boundary, whichever is shorter. As observed in other implementations, computational vec-

tors calculated for one cell are sometimes used to step into the next cell over the noncontinuous

boundary, which results in large errors (seemingly random kinks in the streamlines).

Having explained the details to consider for implementing a computational space method correctly,

we still didnt give any reason why we preferred this method over the physical space method. Both

seem to produce equally accurate traces. For turbomachinery however, the grids are adapted to the

geometry not only in shape, but also in resolution. Near the solid surfaces, near leading and trailing

edges of the blades and at other places where large gradients are expected in the flow, the resolution

of the mesh is significantly better than for example in the center of a channel, where usually no rapid

changes appear in the flow.

In physical space, a fixed step size would have to be chosen very small to accommodate for the places

with the best resolution. Alternatively, a method using adaptive step size could be used, but these

methods are more complicated. Using fixed step in computational space on the other hand gives nice

small steps where the resolution of the mesh is good and larger ones where the mesh is coarse. Also,

from a point of view of information usage, it makes a lot of sense to sample the velocities from a small

cell about as often as the ones from a big cell.

On the whole, we believe that at least for turbomachinery problems, where meshes are highly adapted

to the flow geometry and have large differences in resolution, a properly implemented method with

fixed step in computational space is comparable with an adaptive step method in physical space. Since

the latter is more complex and expensive in computation time, we chose the parameter space method.

Several additions and improvements have been made in response to the issues raised by the turboma-

chinery application as laid out in Section 3.2. Two different kinds of continuation of a particle traces

when reaching a boundary surface are needed. To trace particles across several channels, the trace has

22

to be continued when leaving the channel at a periodic boundary. The trace calculation is continued

at the opposing boundary in the same mesh, but the channel has to be stored for each trace segment

to display the trace appropriately. The implementation of these periodic boundaries is general enough

to allow even for more complicated structures such as a C-mesh enclosing a blade, as long as the grid

points on both sides of the boundary surface coincide. The new start point in parameter space can be

found in all these cases by applying an integer transformation matrix.

A different kind of continuation of a trace is necessary to track a particle across several parts of a tur-

bine, as for example runner and draft tube. When a particle leaves the runner, the exact place in phys-

ical space and time can be used to find the entry point in the draft tube. This makes use of the point

location routine described in Section 4.3.

Another improvement is the calculation of a Frenet frame moved along with each particle. This allows

to display the local rotation along a streamline. Besides drawing a simple line for a streamline or a

sphere for a particle, Flux also implements ribbons (rectangular cross-section) and candy-striped tubes

instead of the lines to depict information about the local rotation (see Fig. 11).

4.2 Stream Surfaces

Based on the routine to calculate streamlines, stream surfaces have been added. The implementation

follows [8] in the coarse ideas. A front of particles is advanced synchronously. Whenever two of the

particles diverge too far from each other, additional particles are inserted in between. When there is

too much divergence (i.e. because at the leading edge, one particle flows right of a blade and its neigh-

bor left), the surface tears. Both local refinement and tearing is shown in Fig. 15.

Figure 15: Stream surface (flowing from left to right). Local refinement is visible byinsertion of triangles and occurs in regions where streamlines diverge too far.Tearing in two separate parts is necessary where the surface meets the blade.

23

Since we wanted to preserve the time information for animation of a growing stream surface, our

stream surfaces are usually stored on multiples of a fixed time interval. Since this leads to long and

narrow triangulation in regions of highly sheared flow (fast flow next to slow movement), we also

implemented the fixed space step as suggested in [8]. This results in smoother triangulation of the

stream surface in regions of high shear, but does not allow to animate the growth of the surface pro-

portionally with time.

4.3 Finding Points in Computational Space

Since the trace integration implemented in Flux works in computational space, the transformation of

points from physical to computational coordinates is needed only in two occasions. The first occurs

of course if the coordinate system for a trace start point specified by the user is physical space.

Although it is often more convenient to use computational coordinates directly when moving around

a streamline interactively for probing, it is desirable to use physical space for example to start a large

number of particles uniformly distributed in physical space. The other occasion the point location rou-

tine is used is when a trace ending at an exit surface of one grid should be continued in an other grid,

as described at the end of Section 4.1.

Point location is a quite computationally expensive operation since the transformation defined by cell-

wise trilinear interpolation can not easily be reversed. An iterative method is needed to find a physical

position inside a certain cell. Once a cell is selected, Flux uses a few Newton steps to locate the point.

Three iterations proved sufficient to achieve reasonable accuracy in all cases. However, the method

only works once the appropriate cell is known.

If the initially point is in the wrong cell, Newton iteration will leave the current cell, and calculation

has to start again in a neighboring cell. For the parts of a turbine consisting of several rotated channels,

the same point has to be searched in each channel, which is easier be done by rotating the point and

searching again in the same mesh.

Figure 16: Successive bounding boxes of sections of the grid to speed up point location.Shown are the overall bounding box and the bounding boxes of the first subdivision.

24

To speed this search up, the actual Newton stepping for each cell was preceded by a simple test against

the cells bounding box. To reduce the number of cells to be searched, an octree structure (see Fig.

16) is build in parameter space, storing the bounding box of groups of cells down to a given depth. If

the test against this bounding box fails, all cells in this group can be discarded as candidates.

Using this octree pre-calculated at program start, the time for location of the start point is very small

compared to the calculation of the streamline.

4.4 Smooth Keyframe Camera Animation

Flux allows for a simple camera animation based on keyframes. Each of the components stored in the

keyframe (e.g. x, y and z coordinate of the camera) is interpolated using a Hermite interpolation

scheme of degree three. After experimenting with some other methods to interpolate animated camera

positions, an interpolation of C1 continuity seems necessary. To avoid the typical overshooting of

cubic interpolation before a constant segment, segments between keyframes can also be marked as

linear. For the parts immediately before and after a linear part, a condition is introduced to the inter-

polation that the end of the cubic part must match the slope of the following linear part. This condition

fits nicely into the Hermite scheme, which can be expressed as an interpolation between two points,

where value and slope are given.

Since this appears to be a useful interpolation for animation purposes, we list the formulas here. We

assume is the cubic function you want to interpolate between the points and . The values

at these points are given as

where, except at the borders, the slopes and are calculated from the central differences of their

neighbors. The interpolation is then calculated as

where

and the are the basis functions:

4.5 Texture Mapping for Pseudocoloring

Hardware support for texture mapping has been available for a while in high-end graphics computers

and will become more widely distributed with the advent of next generation graphics support even on

smaller systems. A lot of commercial visualization packages however do not make good use of this

additional features of (as of now) high-end machines. A nice example of the use of texture mapping

for visualization is better quality pseudocoloring.

f x( ) t1 t2

f t1( ) x1=

f t2( ) x2=

f ' t1( ) v1=

f ' t2( ) v2=

v1 v2

f t( ) x1 b1 q( ) x2 b2 q( ) v1 b3 q( ) v2 b4 q( )+ + +=

qt t1( )

t2 t1( )-------------------=

bi

b0 2t3

3t2

1+=

b1 2t3

3t2

+=

b2 t3

2t2

t+=

b3 t3

t2

=

25

The colormap is loaded as an 1D image into a texture. Now the program can, with each corner of a

polygon to be rendered, also indicate one texture coordinate, which is simply any scalar value to be

mapped as color onto the surface. The range used for the colormap simply has to be transformed to

the interval of [0...1], since all texture coordinates are normalized. Without further programming, the

texture mapping then generates a lighted and colormapped geometry. As compared to simply chang-

ing material color in each polygon corner and have the geometry hardware Gouraud shade the poly-

gon, the texture mapped version produces much better quality, especially if there are high gradients

present or if the colormap contains incontinuities.

4.6 Drawing Polygon Borders

To indicate the shape and density of the grid used for calculation on the surfaces, turbomachinery

engineers like the possibility to draw the grid along with the polygons on the solid geometry, as in

Fig. 18. Since Z-buffer graphics show randomly stitched lines when simply drawing lines coincid-

ing with the polygon borders because of finite Z-buffer resolution, the following procedure can be

used to draw each polygon with its borders:

1. disable Z-buffer for writing

2. draw polygon filled as usual

3. draw outline of polygon in a different color

Figure 17: Comparing pseudocoloring by evaluating color at each edge and interpolateby Gouraud shading (left), and by using texture mapping (right) for a grayscalemap with ten discrete shades. Usually, color hue is used instead of gray values.Divisions between values appear blurred on the left, but sharp on the right. The

printing process may not show these differences very well.

26

4. enable Z-buffer writing, but disable normal frame buffer writing

5. draw filled polygon again to fill Z-buffer correctly

6. re-enable frame buffer for writing

Although this procedure is relatively expensive since it requires three redraws of each polygon, it is

a simple method to generate correct borders for example to depict the grid used for a surface. The

same method can also be used to produce a hidden line grid image by using the background color for

the filled polygon.

4.7 Other Implemented Features

A variety of other features were implemented in Flux, of which we will just mention a few here.

Two graphics redraw modes are provided. For a quicker redraw during interactive manipulations, a

simplified version of the geometry is drawn. As soon as there are no more user events pending, the

normal (slower but more accurate) model is used in an additional redraw.

Figure 18: Drawing polygon borders to indicate underlaying grid.

27

A special draw mode allows to write the current view directly to a source file for rayshade, a public-

domain raytracing program. Thus, high quality picture can be directly generated from Flux or our

AVS environment without much handwork.

In order to obtain more realistic (and impressive) graphics mainly for the customer videos, reflection

mapping is implemented to provide shiny metallic surfaces. We observed that reflection mapping can

help to recognize the three-dimensional shape of a surface correctly, especially if the camera is mov-

ing.

4.8 Conclusions

We hope this report has provided some insight into the specific problems of turbomachinery flow

visualization and explained our basic approaches. Maybe there are some ideas for other projects to be

taken from the explanations in this chapter.

While the solutions presented in this report are just small additions or adaptations of already known

methods and algorithms, we are currently working on a research project aimed at extracting important

features such as vortices directly from the results of numerical simulation and try to classify them by

methods stemming from the field of computer vision.

28

5 References

5.1 Turbomachinery and Hydraulic Machines

[1] Grigori I. Krivchenko: Hydraulic machines: turbines and pumps. 2nd ed., ISBN 1-56670-001-

9, CRC Press, 1994.

[2] Andreas Sebestyen and Ronald Peikert: Simulation of turbomachinery secondary flow phe-

nomena. In Proceedings of European Simulation Multiconference, pages 590--594, Panum

Institute, Copenhagen, Denmark, June 1991.

[3] A. Sebestyen and H. Keck: Uprating of ultra-low head Francis units based on numerical flow

analysis. In Proceedings of Water Power Conference on Uprating and Refurbishing Hydro

Powerplants, Nice, France, October 1995.

[4] H. Keck, E. Goede, and A. Sebestyen: Dreidimensionale Stroemungsberechnungen in Pump-

turbinen (3D flow calculations in pump turbines; in german). VDI-Kolloquium Wasserkraftan-

lagen, Dresten, Germany, June 1994.

5.2 CFD Flow Visualization

[5] Ronald Peikert: Stromlinien in Ren und Flux - die Integrationsmethode. (in german). IPS

Supercomputing (SCSC), ETH Zurich, October 1993.

[6] Ari Sadarjoen, Theo van Walsum, Andrea J. S. Hin and Frits H. Post: Particle tracing algo-

rithms for 3D curvilinear grids. Research Report 94-80, TU Delft, 1994. Available from http://

www.tudelft.nl.

[7] Pieter G. Buning: Sources of error in the graphical analysis of CFD results. Journal of Scien-

tific Computing, 3(2):149--164, 1988.

[8] J. P. M. Hultquist: Constructing stream surfaces in steady 3D vector fields. In Proceedings of

Visualization 92, pages 171--178, Boston, MA, October 1992.

5.3 Software

[9] Silicon Graphics, Inc.: IRIS GL. 3D graphics library and API. See http://www.sgi.com.

[10] Mark Overmars: Forms. Library and builder for user interface elements and event handling.

Available from ftp.cs.ruu.nl.

[11] Advanced Visual Systems, Inc.: AVS. Interactive visualization and visual programming pack-

age based on a dataflow model. See http://www.avs.com.

5.4 Color Figures

Some of the images in this report for which color is important can be found on the Web at

www.scsc.ethz.ch/~roth/turbo/fluxtr.html.

Recent CSCS/SCSC Technical Reports1994TR-94-08 A. Muller and R. Ruhl: Extending High Performance Fortran for theSupport of Unstructured Computations. (November 1994)TR-94-09 C. Clemencon, J. Fritscher and R. Ruhl: Visualization, ExecutionControl and Replay of Massively Parallel Programs within Annai's DebuggingTool. (November 1994)TR-94-10 E. Gerteisen: Implementation of Finite Volume Fluid Solvers into the PE2ARDatabase Environment. (December 1994)TR-94-11 E. Gerteisen: A Generic Data Structure for the Communication of ArbitraryDomain Splitted Mesh Topologies. (December 1994)1995TR-95-01 C. Clemencon, J. Fritscher, M. Meehan, and R. Ruhl: AnImplementation of Race Detection and Deterministic Replay with MPI.(January 1995)TR-95-02 K. Decker and S. Focardi: Technology Overview: A Report on DataMining. (February 1994)TR-95-03 C. Clemencon, K. Decker, V. Deshpande, A. Endo, J. Fritscher, N.Masuda, A. Muller, R. Ruhl, W. Sawyer, B. J. N. Wylie, and F.Zimmermann: Tool-Supported Development of Parallel Application Kernels.(April 1995)TR-95-04 Y. Seo, T. Kamachi, K. Suehiro, M. Tamura (NEC Central ResearchLab., Kawasaki, Tokyo) and A. Muller, R. Ruhl (CSCS): Kemari: aPortable HPF System for Distributed Memory Parallel Machines. (June 1995)TR-95-05 A. Endo and B. J. N. Wylie: Annai/PMA Instrumentation IntrusionManagement of Parallel Program Proling. (November 1995)TR-95-06 P. Ackermann and U. Meyer: Prototypes for Audio and Video Processingin a Scientic Visualization Environment based on the MET++ MultimediaApplication Framework. (June 1995)TR-95-07 M. Guggisberg, I. Pontiggia and U. Meyer: Parallel Fractal ImageCompression Using Iterated Function Systems. (May 1995)1996TR-96-01 W. P. Petersen: A General Implicit Splitting for Stabilizing NumericalSimulations of Langevin Equations. (February 1996)TR-96-02 C. Clemencon, K. M. Decker, V. R. Deshpande, A. Endo,J. Fritscher, P. A. R. Lorenzo, N. Masuda, A. Muller, R. Ruhl,W. Sawyer, B. J. N. Wylie, F. Zimmermann: Tools-supported HPF andMPI Parallelization of the NAS Parallel Benchmarks. (April 1996)TR-96-03 B. J. N. Wylie and A. Endo: Annai/PMA Multi-level Hierarchical ParallelProgram Performance Engineering. (April 1996)TR-96-04 C. Clemencon, A. Endo, J. Fritscher, A. Muller, and B. J. N. Wylie:Annai Scalable Run-time Support for Interactive Debugging and PerformanceAnalysis of Large-scale Parallel Programs. (April 1996)

CSCS/SCSC Via Cantonale CH-6928 Manno Switzerland

Tel: +41 (91) 610 8211 Fax: +41 (91) 610 8282

CSCS/SCSC ETH Zentrum, RZ CH-8092 Zurich Switzerland

Tel: +41 (1) 632 5574 Fax: +41 (1) 632 1104

CSCS/SCSC WWW Server: http://www.cscs.ch/