ASME Turbo Expo 2006: Power for Land, Sea and Air May 8-11, 2006, Barcelona, Spain

Proceedings of GT2006 ASME Turbo Expo 2006: Power for Land, Sea and Air Proceedings of GT2006 May 8-11, 2006, Barcelona, Spain

GT2006-90339

GT-2006-90339
GAS TURBINE ENGINE PERFORMANCE MODEL APPLICATIONS USING AN OBJECTORIENTED SIMULATION TOOL
A. Alexiou Research Associate Email: a.alexiou@ltt.ntua.gr K. Mathioudakis Professor Email: kmathiou@ntua.central.gr

Laboratory of Thermal Turbomachines National Technical University of Athens PO BOX 64069, Athens 15710, Greece ABSTRACT Engine performance models are used throughout the life cycle of an engine from conceptual design to testing, certification and maintenance. The objective of this paper is to demonstrate the use and advantages of an engine performance model, developed using an object-oriented simulation tool, for the following applications: Building an engine model from existing engine components and running steady state and transient calculations Development and integration of a new cooled turbine component in the existing engine model Accessing the engine model from an external application Using an external legacy routine in the engine model Keywords: simulation Object-oriented, gas turbine, performance, The purpose of this paper is to present, through specific applications, the use and advantages of general purpose, object-oriented simulation tools that are capable of covering the needs of these different types of users. The first application is relevant to users who create an engine model from existing components and run simulations; the procedure of building an engine model and obtaining the results is presented. The next application shows how to develop a new component and its integration to an existing engine model. A cooled turbine is used as an example in order to highlight the effects of using different turbine efficiency definitions on engine performance, according to the method of accounting for the cooling air. This application is relevant to users creating engine components. The third application shows how lower level users could benefit from such simulation tools; the engine model is accessed from an external application that hides the details of building and running a model. Finally, in the last application, the issue of using existing, tested and trusted legacy codes in new generation simulation environments is addressed. A specific such tool [2, 3] is used herein for implementing the applications described above. The advantages of object oriented methods for gas turbine modelling and the main features of the tool are presented in [4]. The applications presented in this paper use the library of gas turbine engine components and the civil two-spool turbofan engine model reported in [4]. NOMENCLATURE BPR Engine By-Pass Ratio P Total Pressure (Pa) SE Efficiency Modification Factor SW Flow Modification Factor T Total Temperature (K) W Mass Flow Rate (kg/s)

INTRODUCTION Computer models simulating the operation and performance of gas turbine engines are used by a variety of workers including the engine manufacturers, the engine users and the academic community. The nature and level of complexity of these models depend on the part of the engine life cycle considered by each group of users. For example, the engine manufacturer requires a basic model during the preliminary design phase while an engine operator may need a very accurate one, for health monitoring purposes. Since their needs are different, they make, use and maintain their own specific engine models. In any case though, they are all looking for a reliable, robust, flexible and user-friendly model. Several examples of performance modelling approaches and engine simulation environments are presented in [1].

Copyright 2006 by ASME

WF XNHP XNLP

Fuel Flow Rate (Kg/s) High Pressure Spool Speed (rpm) Low Pressure Spool Speed (rpm) Map Auxiliary Coordinate

BUILDING & RUNNING AN ENGINE MODEL At the preliminary design stage of an engine development programme, different engine configurations may be deemed appropriate for a given specification. Performance models are required to assess the relative merits of the various alternatives against set targets (e.g. fuel consumption, thrust, etc). A quick decision must be reached at this stage to keep timescales and costs at competitive levels. A simulation environment that allows for rapid engine model implementation and evaluation of results is clearly advantageous. A commercial such tool was presented in [4] and its use is further demonstrated here. For this application, it is assumed that the 'library' of gas turbine engine components, described in [4], is available. Every engine component in this library is represented by an icon allowing the user to create an engine model graphically (instead of writing code) as shown in Fig. 1. To add a component to an engine layout, the appropriate icon is 'dragged' from the palette (library) on the left hand side and 'dropped' onto the 'canvas' on the right. The attributes of a component can be accessed by double-clicking on the icon. A data editor appears and allows manipulation of component parameters, for example the data editor for a combustion chamber is shown in Fig. 2. Components communicate with each other through their ports. Ports are linked with connector lines. Connecting ports of different type is not allowed (e.g. a gas port to a shaft port connection is not valid).

Figure 2: Combustion Chamber Data Editor The next step is to define the mathematical model (called Partition) of this composite component. Internal mathematical algorithms analyse the model's system of differential-algebraic equations and, through wizards (Fig. 3), suggest appropriate boundary conditions, detect non-linear algebraic loops and suggest variables for initialisation, resolve inconsistencies and redundancies and finally sort the equations for efficient calculation. Many Partitions can be defined for the same component (e.g. there can be a Partition for each of the following engine parameters: fuel flow rate, thrust, compressor delivery pressure or temperature, turbine entry temperature, engine pressure ratio, rotational speed, etc.). For our example, the mixed flow turbofan engine, and with the fuel flow rate as a boundary condition, a non-linear algebraic loop is formed and initial values for the following variables are provided: the auxiliary map coordinate (beta) for each of the turbomachinery components, the by-pass ratio and the engine inlet mass flow. During component programming it is possible to 'flag' the boundary conditions and algebraic loop 'tearing' variables so that they appear already selected in the Wizard. Otherwise the ones suggested by the Wizard may not be the optimal ones (e.g. in terms of convergence) and an experience user with physical knowledge of the system modelled could choose better alternatives.

Edit Area

Ports

Components Library Icons Connector Line

Figure 1: Graphical Engine Model Creation When the engine schematic diagram is completed, it must be saved in the appropriate library and compiled. This creates a new library component corresponding to this engine layout. The mixed flow turbofan model used as an example here consists of the following 23 components: an atmosphere, an inlet, two fans (inner and outer), a compressor, a burner, two turbines (low and high pressure), a mixer, a nozzle, four ducts, three bleeds, four returns, a fuel meter and a performance monitor.

Figure 3: Mathematical Model Wizards The simulation tool allows for non-causal modelling; the order and form of equations does not matter. An option exists ('Mathematical View') to allow the user to see how the program has arranged all component equations, once the partition is created. For an aggregate component, such as an

Copyright 2006 by ASME

engine, the system of equations consists of the equations of all the individual components that make up the engine. For the turbofan model, the following statistics are produced in the 'Mathematical View': 406 equations, 2 linear and 1 non-linear coupled equation subsystems, 1 boundary condition, 20 state variables, 491 unknown variables, 95 data variables, 37 constants and 7 algebraic tearing variables. The equation subsystems result from various constraints such as the laws of conservation of mass and energy between components. The final step is to create one or more simulation cases (Experiments) for the Partition defined. Within the Experiment window and using the object-oriented language EL (Fig. 4), one can initialise variables, set the values of boundary condition variables, run single and multiple steady state simulations, integrate the model over time (transient operation) and generate reports (write results to file or screen). With the help of internal (EL) or external (C, C++, FORTRAN) functions it is possible to create very complicated simulations.

Figure 5: Graphical Output from Simulation Summarising, it is possible to develop and run an engine model in just 3 steps: Build the engine layout graphically and set the engine component properties Use the Mathematical Wizards to define a Partition Create and run an Experiment to view the results This separation between a component and its Experiments greatly facilitates the configuration control, reusability and validation of the component. For example, different versions of the same component can be stored in a library (allowing the component development history to be traced) and compared against the same Experiments for validation purposes or used in any number of other aggregate components without any modifications. DEVELOPING & USING A NEW COMPONENT During the detailed engine design phase, information coming from rig testing or in depth analysis of individual engine components must be fed back to the performance model in the form of correction factors, empirical correlations or completely new mathematical modelling. These component changes call for a flexible and user-friendly engine performance modelling tool. The simulation tool presented here uses the high-level, object-oriented language EL to create components. This offers all the benefits of this type of programming: encapsulation, inheritance, aggregation, abstraction, polymorphism, etc. These features are demonstrated by firstly presenting the general syntax of a component and then an implementation example for the case of a cooled turbine component. Component Definition Figure 6 shows an extract from the modelling of a compressor. This example will now be used to describe the general syntax for defining components.

Figure 4: Experiment Definition The Experiment can run either in batch mode or graphically. An example of the latter is depicted in Fig. 5 that shows some results for the case of a mixed flow turbofan engine running in transient mode in the presence of a fuel spike. Time evolution of fuel flow rate, specific fuel capacity, thrust, turbine inlet temperature, high pressure compressor pressure ratio and high pressure spool speed is shown. It is possible to plot the variation of any model variable against time or another parameter, in single or multiple graphs. Additionally, the values of any user-selected variables can be displayed in numerical format.

Copyright 2006 by ASME

spool turbofan engine. It does not refer to a specific commercial turbofan engine in service, but its structure reflects fully the principles and the technology of contemporary turbofan engines in civil aviation.

(a) Figure 6: Component Syntax Example When a component does not represent a physical component, it is declared as ABSTRACT. Such components are used to define the interface and/or the methods (equations) that can be shared by multiple components. Abstract components cannot be instantiated. Inheritance is declared using the IS_A keyword meaning, for the example of Fig. 6, that Component AbsCompressor is derived from component GasTurbo. Multiple inheritance is also possible. PORTS and DATA form the public part of the component i.e. information accessible from outside the component while the rest of the variables and methods are private (local) to the component. In PORTS the direction (IN or OUT), type (e.g. Gas, Shaft, etc.) and name of Ports the components uses to communicate with other components are declared. The DATA block holds the values of known component variables (e.g. a pressure loss constant or a table of discharge coefficient values). These variables appear in the Attributes Editor (see Fig. 2) and the user can alter their values before starting a simulation. All the local variables used in the component modelling are declared in the DECLS block. The components comprising an aggregate component (such as an engine model) and the way they are connected to each other are declared under the TOPOLOGY heading. This is created automatically when an engine schematic is compiled. A default connection path can also be defined. In the INIT block it is possible to execute a series of sequential instructions in order to assign initial values to any component variables that require one before the start of a simulation. In the DISCRETE block the conditions and effects of discrete events are described. When an event is detected the continuous part halts and the associated sequence of actions is executed. When there are no more events, the system returns back to the continuous part. Finally, the CONTINUOUS block is where the differential-algebraic equations, describing the continuous behaviour of the component, are inserted. All the above blocks are optional. The Cooled Turbine Component The cooled turbine is used as an example of building and incorporating a new component into an existing engine model. The engine model used here and presented in [4] is based on the real time model described in [5]. The model is considered to represent current modelling practices for a typical civil two-

(b) Figure 7: Cooled Turbine Component in an Engine Model (a) cooling flows return before and after the turbine component (b) cooling flows return directly to the turbine component In this engine model, the air bled from the high pressure compressor is returned back to the main flow, for cooling the blades and vanes of the high and low pressure turbines, as shown schematically in Fig. 7a. Each turbine is modelled as an equivalent single stage turbine [6, 7]; depending on whether a cooling flow is considered to do work or not in a turbine stage it is mixed before or after it, respectively. According to [6], this reflects industry standard practice. The return component (RET) simulates the mixing process and hence, three components (e.g. RET41, HPT & RET45) are used to model a cooled turbine. This modelling approach is 'inherited' from the original FORTRAN model described in [5]. Other drawbacks of this method are that the work potential of each cooling flow is effectively specified at the bleed location and not at the turbine and a separate bleed port is needed from every bleed location, for each return component. Additionally, it is not possible to calculate the true stator outlet temperature (SOT), as more than just the NGV cooling air is mixed with the mainstream flow upstream of the first rotor. Finally, in the present cooled turbine model it is not possible to use or calculate the isentropic thermodynamic turbine efficiency definition [7, 8]. In this definition, the various secondary air streams undergo an expansion from their individual total pressure to the turbine exit total pressure. The two efficiency definitions (thermodynamic and equivalent single stage) produce different answers and as different departments within the same company (e.g. turbine design and performance departments) or different partners in a collaborative engine

Copyright 2006 by ASME

development project may use one or the other it is desirable to calculate both. In order to overcome these modelling limitations, a new turbine component is created by modifying the existing one as follows: For a cooled turbine with an arbitrary number of cooling flows, an array of inlet Gas Ports is added in the PORTS block. In this way the component's control volume resembles the physical boundaries of the actual component. The following are defined as DATA and can be accessed by the user through the component's editor (highlighted in Fig. 8): o a switch for selecting which definition of isentropic efficiency (thermodynamic or equivalent single stage) will be used in the calculations o the work potential of each cooling flow o the fraction of each cooling flow used for NGV cooling o the fraction of each cooling flow used for rotor blade cooling and the rotor mean blade diameter. Both used when accounting for the pumping power in the thermodynamic efficiency definition o a switch to select the station to use when reading the turbine map (turbine inlet, stator exit or equivalent rotor inlet)

o the other efficiency definition The simplicity of integrating this new turbine component in the existing engine model is exemplified in Fig. 7b; the three components representing each turbine in Fig. 7a are deleted and replaced by the new turbine component (shown by a new icon). The compressor mid-stage bleed is connected directly to LPT (no extra bleed component required) while the compressor exit bleed component has only one bleed port, connected directly to HPT. By setting the component data values as shown in Fig. 8, the same results are obtained as with the previous model. Hence, using this tool, the creation and integration of a new turbine component in an engine model was simply the addition and/or modification of some data values and equations in an existing component and the manipulation of a few icons in a schematic diagram. The same task in the original engine model, developed in FORTRAN, would require a detailed knowledge of the entire model, as changes in a single component would mean modifications in a number of locations within the programme structure, as this kind of programming languages lack the flexibility, user-friendly interface, extensibility, maintainability and input/output capabilities of modern object-oriented simulation environments. The possibility of easy replacement of components within an engine model makes this type of modelling very flexible for performing comparative studies of different modelling approaches. For the example of the cooled turbine component, the use of different component models may have a nonnegligible impact on simulation results. The importance of using a consistent turbine efficiency definition is highlighted in Fig. 9. Here a 'square' cycle is simulated in which the fuel mass flow rate is varied as shown on the top-middle insert of the figure. The simulation is performed for two cases: (a) both low and high pressure turbines use the equivalent single stage efficiency definition and the equivalent rotor inlet conditions for map evaluation and (b) they both use the thermodynamic efficiency definition and the turbine inlet conditions for map evaluation. The resulting percentage difference between the HPT turbine efficiencies of the two cases over the whole cycle is shown on the top-right insert. This difference affects other performance parameters as shown in the main graph where the variation of specific fuel consumption with thrust, for each simulation, is plotted.
4 3 Fuel Flow Rate

Figure 8: Turbine Data Editor

Equivalent Single Stage
% difference

2 1 0 -1 0 -2

In its CONTINUOUS part the component calculates: o the stator exit conditions from mixing the inlet main flow and the NGV cooling flows o the equivalent rotor inlet conditions from mixing the main inlet flow with the appropriate fraction of each cooling flow according to its work potential o the power required to pump the rotor blade cooling flow according to the rotor mean blade diameter and the rotor blade cooling mass flows o the turbine power and exit flow conditions according to the user selected efficiency definition

Specific Fuel Consumption

30

60

90

120

Time (s) 0 30 60 90 120

-3

Time (s)

Thermodynamic

Net Thrust

Figure 9: Effect of Isentropic Efficiency Definition on Performance Parameters

Copyright 2006 by ASME

The application considered in this section clearly demonstrates the ease of modifying and integrating a component in an engine model. The encapsulation principle and the tool's clear interface definition (using PORTS and DATA), allows a component to evolve without affecting the other components in a model. Provided the interface remains the same, a component can also be represented at different levels of detail e.g. 1-D instead of 0-D. ACCESSING A MODEL FROM AN EXTERNAL APPLICATION When an engine enters into service, a model is required to allow the operator to monitor its performance and obtain diagnostic information when a fault occurs. Based on the model results, critical decisions regarding safety and costs are made and hence the model must be accurate, reliable and provide the information to the engine technician in a clear and effective manner. Although the simulation tool described here allows an engineer to build and run an engine model quickly, it will not appear very user-friendly to a technician. The solution is to hide all the simulation details behind an appropriate Graphical User Interface (GUI). The modelling environment presented here incorporates ActiveX (a set of technologies developed by Microsoft for sharing information among different applications) which provides the necessary tools to enable interaction between the model Experiments and an interface. Any application that can access ActiveX objects, such as Visual Basic, Visual C++, Delphi as well as Microsoft Office (Excel, Access, etc.) can be used to create a user interface from which to execute Experiments, modify variables and display results. It is not necessary to install the simulation tool in the user's computer (only the ActiveX DLL is required).

Figure 10 shows a simple GUI, developed in Visual Basic, for what could be considered as a basic engine condition monitoring system. The Experiment corresponds to a turbofan engine model working in adaptive mode [see 4 and 9]. The program first 'loads' the Experiment's DLL (generated automatically when running an Experiment). The inputs required are the operating conditions (fuel flow rate, altitude, flight Mach number and relative humidity) and 10 engine measurements corresponding to the 10 health factors (flow and efficiency for each turbomachinery component). When the model runs, the percentage deviation of each of these factors are displayed in a graph. The process could be fully automated by including a data acquisition module such as the one described in [10]. This will allow the user to concentrate on monitoring the engine's condition, without the need to come in contact with the actual model itself.

Figure 11: Toolbar for Handling ObjectOriented Models in Microsoft Excel The simulation tool also provides a connection to Microsoft Excel through the toolbar shown in Fig. 11. Using the buttons in this toolbar the user can, in a familiar environment, open, save and close Experiments, assign or delete model variables to selected cells, play, pause, stop and reset an Experiment, carry out a new integration or steady state calculation, save and restore a snapshot of the simulation values and clean the results file. Having registered the toolbar, the only file required is the Experiment's DLL. When the Experiment is loaded, a window also appears that produces messages (warnings, errors, etc) related to the loading and running of the simulation.

Figure 12: Engine Simulation in Microsoft Excel Figure 12 shows a sample application suitable for a gas turbine engine related course for engineering students or for training personnel involved with gas turbine operation. It

Figure 10: GUI for Engine Condition Monitoring

Copyright 2006 by ASME

simulates the transient operation of a turbofan engine. It shows the calculated values of mass flow rate, total pressure and temperature at various engine locations as well as the shaft speeds and engine by-pass ratio for a time-varying fuel flow rate (boundary condition) and constant values of altitude, Mach number, relative humidity and temperature difference from standard atmosphere (data). The user can change only the values of data cells. Cells are automatically coloured depending on the type of variable (boundary condition, data or unknown) assigned to them. Using Excel's graph capabilities, it is possible to view the variation of any parameter with time, as the Experiment is executed. Plots of fuel flow rate, specific fuel consumption and net thrust are depicted in Fig. 12. A graph, showing the operating points on a compressor map, is also included. The effects of faulty or degraded turbomachinery components on engine performance can also be simulated by adjusting the values (data) of the appropriate health factors (right hand side of the picture). The values of all the parameters displayed in the simulation sheet are stored in a different sheet for further processing. Finally, the capability of the tool to automatically generate C++ code, allows a model to be easily integrated in a variety of other applications and simulation environments such as Matlab / Simulink. USING EXTERNAL CODE IN AN ENGINE MODEL Many numerical simulation codes in science and engineering have been, and still are, developed in FORTRAN and more recently in languages such as C or C++. The effort invested in writing and validating these codes and their successful use in critical and/or day-to-day tasks mean that it is unlikely they will be scraped just to be re-implemented in a modern simulation environment. A strong incentive to migrate to such an environment would then be its ability to integrate these well-tested and stable legacy pieces of code, without any modifications. EL allows the re-use of functions written in FORTRAN, C or C++, expanding its power with a wide range of both in-house and commercially available libraries of mathematical and other routines. Two simple steps are required before such functions can be used within a Component or an Experiment: (a) declare their interface and (b) specify the directory of the object or library in which these functions reside. The example below shows the definition in EL of a Newton-Raphson solver developed in FORTRAN:
"FORTRAN" FUNCTION NO_TYPE NewtonRaphson ( FUNC_PTR fcn, -- Function Pointer IN INTEGER n, -- No of Independent Vars IN INTEGER imax, -- Max No of Iterations IN REAL tol, -- Required Tolerance IN REAL eps, -- Machine EPS OUT REAL x[], -- Independent Vars Array OUT INTEGER ierror -- Flag ) IN "USER_LIBS\NTUA\ExternalObjects\NR.obj"

Figure 13: Specifying the Location of External Objects Using the Newton-Raphson function defined above, an Experiment is created that adapts an engine model, using appropriate modification factors, to measurements according to the scheme shown in Fig. 14.

Independent Variables
SW2, SE2, SW12, SE12, SW26, SE26, SW41, SE41 SW49, SE49

Engine Model
Boundary Condition: WF Tearing Vars: BPR, W1 & for all turbomachines External Newton-Raphson Function

Objective Variables
P13, T13, P26, T26, P3, T3, P42, T5, XNHP, XNLP

Figure 14: Optimisation Scheme for Engine Model Adaptation to Measurement Data Although this calculation is possible using the Design Partition concept described in [4], this approach is more preferable since it can be carried out using the same mathematical model (Partition) as for a "straight" simulation. In the Design Partition approach the independent variables would be declared as unknowns and the objective variables as boundary conditions requiring the equations to be re-arranged accordingly, with the associated risk of creating an unstable or unsolvable equation system. In the body of the Experiment the user must specify the values of the objective variables, provide an initial guess for the independent variables and then call the Newton-Raphson function as follows:
. . NewtonRaphson(fcn,10,itermax,tol,eps,x,ierror) . .

Using the modifiers IN and OUT it is possible to force variables to be passed by reference or by value. C or C++ functions are declared using "C" or "C++" instead of "FORTRAN". The location of the external library or object can also be specified through the GUI as shown in Fig. 13.

where fcn is a function written in EL that runs the model and calculates the residuals. Table 1 shows sample results from the execution of a model adaptation Experiment, namely the values of the reference engine parameters and the modification factors evaluated from the measured ones.

Copyright 2006 by ASME

Table 1: Engine Adaptation Results

Parameter P13 T13 P26 T26 P3 T3 P42 T5 XNHP XNLP Reference 163879.8 335.7 234298.5 378.1 2665660.8 798.5 588067.5 785.7 12416.5 4122.2 Measured 160320.6 334.0 239497.0 381.3 2349953.1 777.8 563083.5 829.9 12256.8 4069.4 Modification Factors 0.985 SW2 0.988 SE2 0.990 SW12 0.990 SE12 0.977 SW26 0.986 SE26 1.080 SW41 0.984 SE41 1.000 SW49 0.987 SE49

International for supplying the software and providing technical support. The assistance of J. Roumeliotis and Ph. Kamboukos in parts of the work is also acknowledged. REFERENCES 1. Research and Technology Organisation, 2002, Performance Prediction and Simulation of Gas Turbine Engine Operation, RTO-TR-044 2. E.A. International, 2004, EcosimPro: User Manual 3. EcosimPro Website: www.ecosimpro.com 4. Alexiou, A. and Mathioudakis, K., 2005, 'Development of Gas Turbine Performance Models Using a Generic Simulation Tool', ASME GT-2005-68678 5. Stamatis, A., Mathioudakis, K., Ruiz, J. And Curnock, B., 2001, Real Time Engine Model Implementation for Adaptive Control & Performance Monitoring of Large Civil Turbofans, ASME 2001-GT-362 6. Walsh, P.P. and Fletcher, p., 2004, Gas Turbine Performance, 2nd Edition, Blackwell Science, Oxford 7. Kurzke, J., 2002, 'Performance Modelling Methodology: Efficiency Definitions for Cooled Single and Multistage Turbines', GT-2002-30497 8. Lakshminarayana, B., 1995, 'Fluid Dynamics and Heat Transfer of Turbomachinery', Wiley Interscience 9. Stamatis A., Mathioudakis K., Papailiou K., 1990, 'Adaptive Simulation of Gas Turbine Performance', J. of Engineering for Gas Turbines and Power, 112, pp. 168175 10. Tsalavoutas, A., Aretakis, N., Mathioudakis, K. and Stamatis, A., 2000, 'Combining Advanced Data Analysis Methods for the Constitution of an Integrated Gas Turbine Condition Monitoring and Diagnostic System', ASME 2000-GT-0034 11. http://www.vivaceproject.com/

Similarly, external functions can be used inside components, offering the possibility to include higher fidelity codes or other disciplines in a 0-D aero-thermodynamic engine performance model. CONCLUSIONS The advantages of generic, object-oriented simulation environments, for developing various engine performance modelling applications, are demonstrated using a specific commercial tool. These applications are representative of the needs of a very diverse group of model makers and users. Firstly, the speed and ease of building and running models is presented using an advanced graphical user interface for creating the engine layout, wizards for defining the mathematical model, an object-oriented language for setting up simulations and integrated post-processing capabilities for viewing the results. Next, the flexibility of developing/modifying and integrating new components is exemplified through the creation and use of a cooled turbine component, taking advantage of all the benefits offered by an object-oriented programming environment. Connectivity with other popular applications is then demonstrated, allowing nonsimulation experts to study gas turbine performance through a familiar and user-friendly interface. Finally, compatibility with established and commonly used programming languages permits the use of legacy codes in the tool, expanding its capabilities and saving resources, development and validation time. On the other hand, what could be considered as a drawback of such tools is that users must change their programming philosophy and engine performance modelling approach from what they are currently used to with linear codes and this maybe neither easy nor desirable. Nevertheless, recognizing the potential of such a simulation environment, a European consortium of gas turbine engine manufactures, research institutes, universities and software developers, within the framework of the EU integrated programme VIVACE [11], are currently creating an advanced tool (PROOSIS) based on the same simulation philosophy but dedicated to gas turbine engine modelling. ACKNOWLEDGEMENTS The work described in this paper has been carried out as part of the Integrated Project VIVACE (AIP3-CT-2003502917) and financial support of the European Union Commission is gratefully acknowledged. The authors would like also to express their thanks to the partners involved in Work Package 2.4 of VIVACE for development of the PROOSIS simulation environment and especially EA

Copyright 2006 by ASME