S

C Centro Svizzero di
S Calcolo Scientifico
C
Swiss Center for C
Scientific Computing S
C
S

A Visualization System
for Turbomachinery Flow
Martin Roth

TECHNICAL REPORT
TR-96-05 April 1996
OTHER PUBLICATIONS BY CSCS/SCSC
Annual Report: yearly review of activities and projects
CrosSCutS (triannually): newsletter featuring announcements relevant to our users as
well as research highlights in the eld of high-performance
computing
Speedup Journal (biannually): proceedings of the SPEEDUP Workshops on Vector and
Parallel Computing, published on behalf of the SPEEDUP
Society
User's Guide: manual to hardware and software at CSCS/SCSC
To receive one or more of these publications, please send your full name and complete address
to:
Library
CSCS/SCSC
via Cantonale
CH-6928 Manno
Switzerland
Fax: +41 (91) 610 8282
E-mail: [email protected]

Technical Reports are also available from:

http://www.cscs.ch/Official/Publications.html
A list of former IPS Research Reports is available from:
http://www.cscs.ch/Official/IPSreports.html
 A Visualization System
for Turbomachinery Flow
Martin Roth 1

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

Keywords. turbomachinery CFD, ow visualization, streamline calculation, particle traces,

hydraulic turbines
1 Swiss Center for Scientic Computing, ETH Zurich, CH-8092 Zurich, Switzerland
[email protected]

CSCS/SCSC Technical Report 1

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

2
 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.

3
 Figure 1: Hydraulic turbine installation and powerhouse.

4
 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.

headwater

electric power
generator

shaft static
head
penstock tailwater
turbine

draft
tube

Figure 2: diagram of hydraulic turbine installation

5
 F
A B C E E C B
A
D D
H
H

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

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

6
 F

A B C C B A

D D
E

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

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

7
 Figure 5: scroll-shaped spiral casing (steel)

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].

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

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 Zürich/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-

9
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).

10
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 customer’s 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.

11
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 today’s 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.

12
 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) velocity
at the band (left), in the middle of the channel (center) and at the crown (right).

13
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

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

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

15
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.

16
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 and

a few streamlines (relative flow).

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

18
 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

19
 Physical Space

Legend:
8 Jacobians/cell
8 velocities/cell
1 velocity/node

Computational Space
Figure 14: Variants of computational space integration methods for a test mesh with
four cells and constant vertical motion in physical space. Lines with different gray
value and line width show resulting streamlines with three different methods.

20
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. It’s 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, it’s 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 didn’t 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

21
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 by
insertion of triangles and occurs in regions where streamlines diverge too far.
Tearing in two separate parts is necessary where the surface meets the blade.

22
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.

23
To speed this search up, the actual Newton stepping for each cell was preceded by a simple test against
the cell’s 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 f ( x ) is the cubic function you want to interpolate between the points t 1 and t 2 . The values
at these points are given as

f ( t 1 ) = x1 f ' ( t 1 ) = v1
f ( t 2 ) = x2 f ' ( t 2 ) = v2

where, except at the borders, the slopes v 1 and v 2 are calculated from the central differences of their
neighbors. The interpolation is then calculated as

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

(t – t1)
q = ------------------
-
(t2 – t1)

and the b i are the basis functions:

3 2 3 2
b 0 = 2t – 3t + 1 b 2 = t – 2t + t
3 2 3 2
b 1 = – 2t + 3t b3 = t – t

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.

24
 Figure 17: Comparing pseudocoloring by evaluating color at each edge and interpolate
by Gouraud shading (left), and by using texture mapping (right) for a grayscale
map 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.

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

25
 Figure 18: Drawing polygon borders to indicate underlaying grid.

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.

26
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.

27
 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.

28
 Recent CSCS/SCSC Technical Reports

1994

TR-94-08 A. Muller and R. Ruhl: Extending High Performance Fortran for the
Support of Unstructured Computations. (November 1994)
TR-94-09 C. Clemencon, J. Fritscher and R. Ruhl: Visualization, Execution
Control and Replay of Massively Parallel Programs within Annai's Debugging
Tool. (November 1994)
TR-94-10 E. Gerteisen: Implementation of Finite Volume Fluid Solvers into the PE2AR
Database Environment. (December 1994)
TR-94-11 E. Gerteisen: A Generic Data Structure for the Communication of Arbitrary
Domain Splitted Mesh Topologies. (December 1994)
1995

TR-95-01 C. Clemencon, J. Fritscher, M. Meehan, and R. Ruhl: An

Implementation of Race Detection and Deterministic Replay with MPI.
(January 1995)
TR-95-02 K. Decker and S. Focardi: Technology Overview: A Report on Data
Mining. (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 Research
Lab., Kawasaki, Tokyo) and A. Muller, R. Ruhl (CSCS): Kemari: a
Portable HPF System for Distributed Memory Parallel Machines. (June 1995)
TR-95-05 A. Endo and B. J. N. Wylie: Annai/PMA Instrumentation Intrusion
Management of Parallel Program Proling. (November 1995)
TR-95-06 P. Ackermann and U. Meyer: Prototypes for Audio and Video Processing
in a Scientic Visualization Environment based on the MET++ Multimedia
Application Framework. (June 1995)
TR-95-07 M. Guggisberg, I. Pontiggia and U. Meyer: Parallel Fractal Image
Compression Using Iterated Function Systems. (May 1995)
1996

TR-96-01 W. P. Petersen: A General Implicit Splitting for Stabilizing Numerical

Simulations 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 and
MPI Parallelization of the NAS Parallel Benchmarks. (April 1996)
TR-96-03 B. J. N. Wylie and A. Endo: Annai/PMA Multi-level Hierarchical Parallel
Program 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 Performance
Analysis 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 Zürich — Switzerland

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

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