User Manual Fine Turbo V6.2-9

p t1 is p t2

p t1 Turbines p t2

0 α<0 V RPM (<0) z FIGURE 12.5.1-12 Coordinate system and reference for flow angles and speed of rotation In a 2D case, if the ZTR coordinate system is used, the radius does not have to be specified in the blade geometry input file. The number of columns can be 2 or 3, the third column being not read by the solver (the radius is automatically set to the value given in the streamsurface data input file).
The suction side is by convention located above the pressure side in the θ-direction Figure 12.5.1-12. It does not necessarily have to be the physical suction side. 12-5.2 Output Files Several output files are generated by the blade-to-blade module: 12-5.2.1 Geometry Files a) ’project_computationname.geoini’ and ’project_computationname.geo’ These files contain the blade shape in the (m,θ) plane. The ’.geoini’ file contains the initial blade shape as given in the input files (or resulting from the 3D interpolation process in a 3D case), whereas the ’.geo’ file contains the blade discretization points used in the computation. These files can be read and plotted by the NUMECA MonitorTurbo (Blade profile menu). b) ’project_computationname.merdat’, ’project_computationname.mer.ori’ and ’project_computationname.mer’ These files contain respectively the hub and shroud walls and the streamtube projection onto the meridional plane. The ’.merdat’ file contains the hub and shroud walls (3D case only), whereas the ’.mer’ and ’.mer.ori’ files contain the streamtube. These files can be read and plotted by the NUMECA MonitorTurbo (Blade profile menu). c) ’project_computationname.ps.ori’ & ’project_computationname.ss.ori’ These files contain respectively the pressure side and the suction side of the blade. FINE™ 12-15 File Formats used by Blade-to-Blade Module Blade to Blade Module d) ’project_computationname.split.ps.ori’ & ’project_computationname.split.ss.ori’ (if splitter blades) These files contain respectively the pressure side and the suction side of the splitter blade. 12-5.2.2 Quantity Files a) ’project_computationname.cgns’ This file contains the results of the calculation, i.e. the five flow variables (density, x-y-z components of the relative velocity and the static pressure) at all the mesh cell centers (including the dummy cells generated by the boundary conditions). It also contains all output variables to be displayed by CFView™. b) ’project_computationname.mf’ This file is a summary file containing the averaged flow quantities at the inlet and the outlet boundaries. c) ’project_computationname.mfedge’ This file is a summary file containing the averaged flow quantities at the leading and trailing edge planes. d) ’project_computationname.2d.cfv’ & ’project_computationname.3d.cfv’ The blade-to-blade module automatically creates all the files required by the NUMECA CFView™ post-processing tool. Two projects are created, the first one being named ’***.3d.cfv’, allowing a 3D visualization of the case, the second one being named ’***.2d.cfv’, allowing a 2D visualization in the (m,θ) plane. e) ’project_computationname.velini’ & ’project_computationname.vel’ These files contain the isentropic Mach number and the pressure coefficient distributions along the blade surfaces. The two quantities are plotted along the curvilinear abscissae measured along the blade surface (non-dimensionalized by the blade chord). The isentropic Mach number is calculated (for compressible flows only) using the inlet relative total temperature and pressure, which are not necessarily imposed (depending on the choice of the inlet boundary condition). In case the total conditions are not imposed, the values are the ones resulting from the calculation (average along the inlet boundary). Mis = ⎛ p 2 ----------- ⎜ ⎛ ----0-⎞ ⎜ ⎝ γ – 1 p⎠ γ–1 ----------γ ⎝ ⎞ – 1⎟ , ⎟ ⎠ (12-2) where p is the local static pressure, and p0 is the local relative total pressure calculated assuming a constant rothalpy and a constant entropy in the field. The pressure coefficient is defined by: p – p exit Cp = ------------------- , p exit (12-3) where pexit is the exit static pressure, and p is the local static pressure. 12-16 FINE™ File Formats used by Blade-to-Blade Module Blade to Blade Module These files can be read and plotted by the NUMECA MonitorTurbo (Loading diagram menu). The ’.velini’ file contains the initial distributions, whereas the ’.vel’ contains the actual ones, and is iteratively updated during the resolution process. f) ’project_computationname.split.velini’ & ’project_computationname.split.vel’ (if splitter blades) These files contain the isentropic Mach number and the pressure coefficient distributions along the splitter blades. These files can be read and plotted by the NUMECA MonitorTurbo (Loading diagram menu). g) The ’project_computationname.loadini’ & ’project_computationname.load’ Provided that the parameter ISQUEL specified in the ’.run’ file is different from 0, these files are automatically generated, and contain the distributions of the suction-to-pressure side Mach number and pressure coefficient difference and average. These distributions can be superimposed to the suction and pressure side distributions. These files can be read and plotted by the NUMECA MonitorTurbo provided with the FINE™ user interface (Loading diagram menu). The ’.loadini’ file contains the initial distributions, whereas the ’.load’ contains the actual ones, and is iteratively updated during the resolution process. h) ’project_computationname.split.loadini’ & ’project_computationname.split.load’ (if splitter blades) These files contain the same results as the ’.load’ and ’.loadini’ files along the splitter blades. These files can be read and plotted by the NUMECA MonitorTurbo provided with the FINE™ user interface (Loading diagram menu). 12-5.2.3 Numerical Control Files a) ’project_computationname.log’ & project_computationname.std’ These files contain all the informations written by the solver during its execution. When the solver fails for any accidental reason, the explanation can usually be found in these files. b) ’project_computationname.res’ This file contains the evolution of the mean and maximum residuals and of the inlet and outlet mass flows. This file can be read and plotted by the NUMECA MonitorTurbo (Convergence history menu). FINE™ 12-17 Blade to Blade Module 12-18 File Formats used by Blade-to-Blade Module FINE™ CHAPTER 13:Design 2D Module 13-1 Overview This chapter describes the new quasi-three-dimensional FINE™/Design 2D Module for turbomachinery cascade inverse design. This module is associated with the FINE™/Design 2D Blade-toBlade module presented in Chapter 12. In addition to the mesh generator and the flow solver, the FINE™/Design 2D module includes one of the latest inverse methods for the redesign of the blades with improved performance. Such a method permits to redesign the blade shape for a target pressure distribution along the blade surfaces. The use of the design method requires a license for bladeto-blade simulation. The FINE™/Design 2D module can be used (and acquired) independently from the other NUMECA tools. In the near future NUMECA intends to extend the FINE™/Design 2D environment to other types of applications and to other design techniques. This first version is limited to the inverse design of turbomachinery cascades, and has therefore been integrated with the Blade-to-Blade method in the FINE™/Design 2D user environment. Both analysis and design modules are based on the assumption that the flow in the turbomachinery cascade remains on an axisymmetric streamsurface. The geometrical inputs required from the user to perform an inverse design are not different from the ones required to perform an analysis (as described in Chapter 12). For more information about the Blade-to-Blade method, see the description provided in the Chapter 12. In the next section the interface is described in detail including advice for use of the inverse design method. The theoretical background for the inverse method is described in section 13-3. Finally, the Design 2D Module requires geometrical data files and generates output as detailed in section 13-4. FINE™ 13-1 Inverse Design in the FINE™ Interface Design 2D Module 13-2 Inverse Design in the FINE™ Interface The Blade Design module is proposed under the new NUMECA FINE™/Design 2D environment presented in Chapter 12, which permits a very rapid, easy and interactive use of the solvers. All the parameters can be selected interactively by means of this user interface, which automatically creates the input files and permits to launch the analysis and inverse solvers. A graphical control software, called MonitorTurbo, is provided. It permits to observe the evolution of the convergence history, of the pressure distribution along the blade surface, and of the blade geometry (case of an inverse design). It also permits to create the target pressure distribution interactively. The results can be analysed with the NUMECA CFView™ post-processing software, whose connection with the blade-to-blade module is automatically provided. The geometrical data are specified in ASCII input files, whereas the definition of the flow solver parameters and of the boundary conditions are specified via the interface. This section describes the creation of the inverse design input files using the interactive menus provided in FINE™/Design 2D. Further details concerning the input and output files are provided in section 13-4. The next sections provide information concerning: • The starting of a new or an existing blade-to-blade project. • The creation of the solver input files required for a flow analysis. • The launching of a blade-to-blade flow analysis. 13-2.1 Start New or Open Existing Design 2D Project To start the FINE™/Design 2D module from the FINE™ interface select the menu item Modules/ Design 2D. When launching the FINE™ interface a Project Selection window allows to Create a New Project or to Open an Existing Project. To create a new Blade-to-Blade project: 1. Click on the button Create a New Project. 2. Browse to the directory in which the new project directory needs to be created and enter a name for the project. 3. Close the Grid File Selection window since no grid file is associated to a Design 2D project. 4. Switch to the Design 2D module through the menu Modules/Design 2D. When an existing Design 2D project should be opened click on the button Open an Existing Project in the Project Selection window and select the project in the File Chooser window. The most recently used projects can also be selected from the list of recent projects. If the selected project was saved in the Design 2D module, the FINE™ interface is automatically switched to this module showing the interface as in Figure 12.2.1-1.
It is not possible to have Design 2D and three-dimensional computations in one project. A project is either a FINE™/Design 2D project or a FINE™/Turbo project. The type of the project is determined by the module in which it is saved. The interface in the Design 2D module is described in Chapter 12. The only difference with a blade-to-blade analysis computation is the use of the Inverse Design page. This page is described in more detail in the next sections. 13-2 FINE™ Inverse Design in the FINE™ Interface Design 2D Module 13-2.2 Creation of Inverse Design Input Files An inverse design calculation should always start from the converged flow analysis of the initial geometry. Once a converged flow solution for the blade-to-blade analysis has been obtained, the user can proceed with a modification of the blade using the inverse method. For this purpose the two input files "project_computationname.req" and "project_computationname.run" have to be prepared, in addition to the files required for the analysis ("project_computationname.run" and the geometrical input files). 13-2.2.1 Recommendations It is often useful to save the results obtained after the analysis computation. Therefore it is recommended to perform the inverse design in a new computation. With the analysis computation selected in the Computations area on the top left of the FINE™ interface click on the New button. A new computation is created with the same parameters as the initial computation. The Rename button may be used to rename the new computation. analysis inverse design FIGURE 13.2.2-2 Computations area The expert integer parameter IATFRZ is usually set to 2 during the inverse design procedure in order to freeze the computation of the turbulent viscosity. The consequence of this is to drastically reduce the computational time per inverse design iteration. 13-2.2.3 The Input File "project_computationname.req" The ’project_computationname.req’ file has exactly the same format as the ".vel" or ".load" output files automatically generated by the blade-to-blade analysis module. The most appropriate way to generate this file is to modify the ’projectname.b2b.vel’ or ’projectname.b2b.load’ file resulting from the flow analysis of the initial geometry, using the MonitorTurbo. In order to create a target with the MonitorTurbo, the following operations should be made: FINE™ 1. Start the ’MonitorTurbo’. 2. Select the "Loading diagram" menu. 3. Open the ’project_computationname.vel’ or ’project_computationname.load’ file. 4. Choose between the ’Mis’ or ’Cp’ distributions (in case the inlet total conditions are not imposed as boundary conditions, the inverse problem has to be formulated in terms of Cp). The definition of Mis and Cp are provided in Eq. 13-1 and Eq. 13-2 presented in section 13-4. 5. Activate the ’Markers’ to distinguish the discretization points. 6. Activate the Edit a curve button. 7. Choose the suction or the pressure side curve, by placing the cursor on the corresponding legend, and typing to select. The activated curve changes color. 13-3 Inverse Design in the FINE™ Interface Design 2D Module 8. Modify the curve using the middle button of the mouse: a. Choose the left point where the modification will start (click on the middle button). b. Choose the right point where the modification will end (click on the middle button). c. Choose control points between the left and the right points (click on the middle button). d. Displace the control points. — Select the control point by placing the cursor on the point. — Press on the keyboard, and displace the point vertically. The exact position of the point can be specified by pressing the right button of the mouse. e. Save the new curve by clicking on the Save button, and giving the name of the new curve, or cancel the modifications by clicking on the Cancel button.
At any moment, a zoom of the curves can be obtained by defining a new rectangular window, using the left button of the mouse. The previous unzoomed view can be retrieved by pressing the right button of the mouse. 13-2.2.4 Input File "project_computationname.run" The "project_computationname.run" input file is created via the Inverse design page included in the FINE™/Design 2D interface (Figure 13.2.2-1). One of the three possible inverse formulations should be chosen: • Pressure and suction side distributions or classical formulation: both suction and pressure sides of the blade are modified for an imposed pressure distribution along the whole blade contour. If this formulation is used the profile closure constraint has to be activated. • Suction side distribution or mixed formulation: only the suction side is modified for a prescribed suction side pressure distribution. The profile closure conditions should also be activated, so that the pressure side follows the suction side modifications. • Blade loading or loading formulation: the camber line of the blade is modified for a prescribed loading (suction-to-pressure side pressure difference) distribution from the leading to the trailing edge. The blade thickness distribution is maintained constant and therefore the profile closure condition does not need to be used. The target of the inverse design computation may either be constructed in terms of isentropic Mach number (Mis) or pressure coefficient (Cp) (see Eq. 13-1 and Eq. 13-2 in section 13-4). The isentropic Mach number formulation is limited to compressible flows. Control of the leading and trailing edges is provided. The inverse method permits to maintain some parts of the blade unchanged, such as the leading and trailing edge regions. The number of frozen points along the suction and the pressure sides should be specified for each edge by the user. The default value is 1. However in many cases it is recommended to freeze the leading edge region where no modification is imposed. At the trailing edge it is highly recommended to freeze the regions where a flow separation appears in the analysis of the initial blade. Two relaxation factors are available: • The first relaxation factor (default value = 1.0) permits to consider an intermediate target between the one present in the ".req" file and the initial distribution present in the ".vel" file. This factor is not often used. • The second relaxation factor (default value = 0.05) permits to under-relax the geometry modifications. The range of variation of this factor is from 0.01 to 0.1. Higher values than 0.1 are not recommended for reasons of stability, whereas lower values than 0.01 usually mean that the inverse problem can not be treated. 13-4 FINE™ Inverse Design in the FINE™ Interface Design 2D Module The following geometry constraints are available: • the profile closure constraint should always be used, unless: — the blade thickness is automatically controlled ("loading" formulation). — the trailing edge of the blade is blunt, and the trailing edge thickness does not need to be maintained. • Constant stagger angle is not often used. • Constant blade chord: this constraint permits to maintain the blade chord (measured on the transformed m-θ plane). This constraint should not be used together with the constant radius option, as the two constraints are contradictory. • Constant radius: this option is recommended for radial machines, as it permits to guarantee an unchanged meridional position of the leading and trailing edges. The points are displaced along the circumferential direction. This option is not recommended for large rounded leading edges. • Reference point: the fixed reference point can be either the leading edge (by default) or the trailing edge (if the corresponding button is selected). FIGURE 13.2.2-1 Inverse design page Finally, the number of iterations performed for the inverse design calculation. 13-2.3 Initial Solution Menu An inverse design calculation should always start from the converged flow analysis of the initial geometry. Once a converged flow solution for the blade-to-blade analysis has been obtained, the user can proceed with a modification of the blade using the inverse method. (Figure 13.2.3-2) FINE™ 13-5 Inverse Design in the FINE™ Interface Design 2D Module FIGURE 13.2.3-2 Initial solution page 13-2.4 Launch or Restart Inverse Design Calculation Once the ’.req’ and ’.run’ input files have been correctly created, an inverse design can be started, by selecting the Inverse design option in the "run type" parameter included in the Control Variables page, and by pressing the Start button in the Solver menu. FIGURE 13.2.4-3 Run

type page of the information area Exactly as in the case of the restart of a flow analysis the user has to specify the name of the initial solution file. It is recommended to save the results of the flow analysis under a different name, so that several inverse design calculations can be performed successively, starting from the same initial solution. An interrupted inverse design calculation can be "restarted". For this purpose the user should set the expert parameter INVMOD to 1 instead of 0. This implies that in addition to the correct flow solution file, the actual blade geometry will be read by the solver and considered as the initial one. 13-2.5 Expert Parameters 13-2.5.1 Using a Parametrised Target Distribution Using a parametrised target distribution is possible through the two expert parameters IADAPT and RADAPT, that can be accessed via the Control variables page. The expert mode must be activated in the top right corner of the interface. The integer variable IADAPT contains 6 values: • Type of parametrisation — 0: parametrised distribution is not used — 1: suction side (or loading) distribution is parametrised — 2: pressure side distribution is parametrised. 13-6 FINE™ Theory Design 2D Module • Number of iterations after which the adaptation process will start. • Index of starting (left) point of the parametrised target. The user specifies the position with respect to the leading edge (typically about 10 points). • Index of the ending (right) point of the parametrised target. The user specifies its position with respect to the trailing edge (typically about 10 points). • Turning angle is imposed value (0) or the change of swirl RVθ between inlet and outlet (1). • Imposed turning or swirl is taken from the analysis solution (0) or set by the user (1). The real variable RADAPT contains 4 values: • Reduced curvilinear position of the free parameter between 0. (left point) and 1.0 (right point (default: 0.5). • Relaxation factor governing the amplitude of successive updates of the parameter (default: 0.25) • Range of variation of the free parameter (in isentropic Mach number or pressure coefficient, depending on previous choice of the user) (default: 0.2). • User imposed value of the turning angle (in deg.) or swirl RVθ (m2/s) (used if the last integer of IADAPT is set to 1). INVMOD: set this parameter from 0 to 1 to allow the restart of an inverse design computation. 13-2.5.2 Splitter Blades Design Centrifugal compressors with splitters can be redesigned with FINE™/Design 2D. It is possible to modify either the main blades or the splitter blades. The choice is made through the expert variable INVSPL (accessed in the "Computation Steering" menu of the FINE™ interface): • INVSPL= 1: main blades are modified • INVSPL= 2: splitter blades are modified The target should be constructed from the ’project_computationname.vel’ or ’project_computationname.load’ files if the main blades are modified, or from the ’project_computationname.split.vel’ or ’project_computationname.split.load’ files if the splitter blades are modified. 13-3 Theory The purpose of an inverse method is to redesign the blade shape in order to obtain a prescribed pressure distribution along the blade surfaces. This provides a detailed control of the boundary layer behaviour, by limiting the amount of diffusion and by eliminating the eventual spurious acceleration and deceleration detected along the initial blade profile. Such a method also offers an indirect control of the secondary losses, as a control of the blade loading distribution can be obtained. The inverse design method adopted in FINE™/Design 2D consists of modifying iteratively the blade geometry, until a target pressure distribution is reached on the blade surfaces. The geometry modification algorithm is based on the permeable wall concept. Each iteration of the process is composed of 2 separate steps, respectively related to the geometry and to the flow field updates. Both viscous and inviscid problems can be treated with this approach. Three formulations of the inverse problem are possible: FINE™ 13-7 Design 2D Module File Formats used for 2D Inverse Design • the classical formulation, in which both suction and pressure sides are redesigned in order to obtain a pressure distribution prescribed along the whole blade surface. • the mixed formulation, in which the suction side is redesigned in order to obtain a pressure distribution specified along the suction side only. This formulation is for instance interesting for rotor blades on which strict mechanical constraints are imposed. In those cases the classical inverse formulation may be less efficient because the blade thickness is a result of the calculation, and it is often difficult and time consuming to find an appropriate target leading to a blade with an acceptable thickness distribution. • the loading formulation, in which the distribution of blade loading (pressure-to-suction side pressure difference) from the leading to the trailing edge is prescribed, and in which the camber line of the blade is redesigned (the blade thickness distribution being kept unchanged). This approach is interesting especially for radial machines. This is due to the fact that in radial machines, the average velocity level in the blade channel is mainly controlled by the shape of the hub and shroud endwalls, and therefore a modification of the blade shape mainly influences the loading distribution. The "loading" formulation is therefore more appropriate and efficient for radial machines. However no general rule can be set, and improvements can be reached in many cases using the second formulation. Several geometrical constraints and options have been implemented, to increase the flexibility of the method: • Control of the leading and trailing edges: several points can be kept unchanged in the leading/ trailing edge regions. • Constant blade chord. • Specification of the fixed reference point (leading or trailing edge). • Inverse problem formulated in terms of isentropic Mach number or of pressure coefficient. • Constant meridional position of leading and trailing edges (recommended for radial machines): with this option, the points are displaced along the circumferential direction, which guarantees that their meridional position is unchanged. An important advantage of the present method is the possibility to control the outlet flow angle or swirl. A major drawback of most inverse methods is the lack of control of the turning angle or work exchange in the cascade. The user does not have the guarantee that the specified target pressure distribution will lead to an unchanged turning angle. This implies that several iterations are sometimes required before finding the target leading to an acceptable design. FINE™/Design 2D offers a unique solution to that problem, allowing the control of the turning angle or of the change of swirl from inlet to outlet. A degree of freedom is introduced in the target pressure distribution, that is automatically modified in order to respect the outlet flow angle constraint. A part of the target pressure distribution is defined using a fourth order polynomial curve. The parameter defines the vertical position of a point of this polynomial curve. A smooth transition is ensured between the fixed part of the target and variable one. The parameter is iteratively and automatically adjusted in order to respect the outlet flow angle or the outlet swirl RVθ. 13-4 File Formats used for 2D Inverse Design 13-4.1 Input Files The input files required to run a blade-to-blade study can be split into 3 categories: 13-8 FINE™ File Formats used for 2D Inverse Design Design 2D Module • The geometrical input files, defining the blade geometry. • The solver input files, which define the solver parameters and the fluid and flow conditions. • The inverse design input files, which permit to define an inverse problem. The geometrical and solver input files have been described in Chapter 12. The inverse design input files can be interactively created with the FINE™ environment, and are described in this section. 13-4.1.1 Inverse Design Input Files In order to perform an inverse design problem, 2 additional input files are required: — The ’project_computationname.req’ file, which defines the target pressure distribution. This file can be interactively created using the MonitorTurbo. — The ’project_computationname.run’ file, which specifies the parameters for the inverse design (automatically written by the user interface when saving the ’.run’ file). It should be mentioned that an inverse design always starts from a converged analysis of the initial geometry. The target pressure distribution can be generated by modifying the pressure distribution resulting from the analysis of the initial geometry. 13-4.2 Output Files Several output files are generated by the blade-to-blade module, which have been described in Chapter 12. The inverse design method produces additional output files which are presented in this section. 13-4.2.1 Geometry Files a) ’project_computationname.geoini’ & ’project_computationname.geo’ These files contain the blade shape in the (m,θ) plane. The ’.geoini’ file contains the initial blade shape, whereas the ’.geo’ file contains the actual one. These files can be read and plotted with the NUMECA MonitorTurbo (Blade profile menu). In the case of an inverse design the visualization of the two files permits to compare the initial and the new geometry. b) ’project_computationname.split.geoini’ & ’projectname_computationname.split.geo’ (if splitter blades) These files contain the splitter blade shape in the (m,θ) plane. The ’.geoini’ file contains the initial blade shape, whereas the ’.geo’ file contains the actual one. These files can be read and plotted with the NUMECA MonitorTurbo (Blade profile menu). In the case of an inverse design the visualization of the two files permits to compare the initial and the new geometry. c) ’projectname_computationname.ss.ori’ ,’projectname_computationname.ps.ori’ & ’projectname_computationname.mer.ori’ These three files are automatically generated at the beginning of the solver execution, and contain respectively the suction side, the pressure side and the axisymmetric streamsurface on which the calculation is performed. These files are especially interesting in a 3D input type, with which this blade section results from the 3D interpolation procedure between the 3D blade and the streamsurface. These files have the same format as the blade geometry and streamsurface data input files. The coordinate system for the blade data is always XYZ, which makes these files compatible with IGG™ or AutoGrid. The coordinate system for the streamsurface is always ZRB (B is the streamtube thickness). FINE™ 13-9 File Formats used for 2D Inverse Design Design 2D Module The coordinates are given in the same unit length chosen by the user for the input data. d) ’project_computationname.ss.new’ & ’project_computationname.ps.new’ After an inverse design stage, these two files are automatically generated, and contain the new suction and pressure sides. These files have the same format as the blade geometry data input files. The coordinate system is always XYZ, which makes them compatible with IGG™ or AutoGrid. The coordinates are given in the same length unit chosen by the user in the input. In the default configuration of the solver the points included in these files are the mesh points along the blade walls. The number of points can be different and controlled by the user through the expert parameter NPTB2B. If this parameter is set to a value N different from 0, the number of points describing both suction and pressure sides will be N. 13-4.2.2 Quantities Files a) ’project_computationname.velini’ & ’project_computationname.vel’ These files contain the isentropic Mach number and the pressure coefficient distributions along the blade surfaces. The two quantities are plotted along the curvilinear coordinate measured along the blade surface (non-dimensionalized by the blade chord). The ’.velini’ file contains the initial distribution, whereas the ’.vel’ file contains the actual one. The isentropic Mach number is calculated using the inlet relative total temperature and pressure, which are not necessarily imposed (depending on the choice of the inlet boundary condition). In case the total conditions are not imposed, the values are the ones resulting from the calculation (average along the inlet boundary). The isentropic Mach number is defined by: Mis = ⎛ p 2 ----------- ⎜ ⎛ ----0-⎞ γ – 1⎜⎝ p ⎠ γ---------– 1γ ⎝ ⎞ – 1⎟ ⎟ ⎠ (13-1) where p is the local static pressure, and p0 is the local relative total pressure calculated assuming a constant rothalpy and a constant entropy in the field. The pressure coefficient is defined by: p – p exit Cp = -----------------p exit (13-2) where pexit is the exit static pressure and p is the local static pressure.
These files can be read and plotted by the NUMECA MonitorTurbo (Loading diagram menu). In the case of an inverse design the visualization of the two files permits to compare the initial and the new pressure distributions. b) ’project_computationname.loadini’ & ’projectname_computationname.load’ Provided that the parameter ISQUEL specified in the ’.run’ file is different from 0, these files are automatically generated and contain the distributions of the suction-to-pressure side Mach number and pressure coefficient difference and average. These distributions are useful when the ’loading’ 13-10 FINE™ File Formats used for 2D Inverse Design Design 2D Module formulation of the inverse design method is selected. The ’.loadini’ file contains the initial distribution, whereas the ’.load’ file contains the actual one.
These files can be read and plotted by the NUMECA MonitorTurbo (Loading diagram menu). In the case of an inverse design the visualization of the two files permits to compare the initial and the new distributions. c) ’project_computationname.split.loadini’ & ’project_computationname.split.load’ (if splitter blades) Provided that the parameter ISQUEL specified in the ’.run’ file is different from 0, these files are automatically generated and contain the same quantities as the ’.load’ and ’.loadini’ files calculated along the splitter blades (Loading diagram menu). d) ’project_computationname.tarini’ & ’project_computationname.tar’ The inverse solver automatically generates these two output files, which contain respectively the initial and actual target pressure (or loading) distributions.
FINE™ These files can be read and plotted by the NUMECA MonitorTurbo (Loading diagram menu). The comparison of the .tarini and ’.velini’ (or ’.loadini’) permits to observe the inverse problem to be solved, whereas the comparison of the ’.tar’ and ’.vel’ (or ’.load’) files permits to verify the correct convergence of the inverse design. 13-11 Design 2D Module 13-12 File Formats used for 2D Inverse Design FINE™ CHAPTER 14:The Task Manager 14-1 Overview Using the Solver menu in FINE™/Turbo computations can be started, suspended or killed. For basic task management these menu items are sufficient. The Task Manager provides more advanced features for the management of (multiple) tasks. It allows to manage tasks on different machines on a network, to define parallel computations or to delay tasks to a given date and time. Before using the Task Manager for the first time it is important to read the next section first. This section provides important information for getting started with the Task Manager. Read this section carefully to fully benefit of the capabilities of the Task Manager. From FINE™/Turbo the Task Manager can be accessed by the Modules/Task Manager menu item. The interface as shown in Figure 14.3.1-1 will appear. In section 14-3 the Task Manager interface is described in detail including a description of all capabilities. The current limitations of the Task Manager are listed in section section 14-6. To manage tasks through the use of scripts is also possible and has the benefit that it is not necessary to stay logged in on the machine on which the tasks are launched. See section 14-5 for more detail on the scripts to use to launch NUMECA software. 14-2 Getting Started 14-2.1 The PVM Daemons The Task Manager is based on the PVM library. It allows FINE™ to control processes and communication between processes on all the machines available by the user. PVM works with a virtual machine managed through a pvm daemon. In this section the way PVM daemons are working and its limitations under Windows are described. FINE 14-1 The Task Manager Getting Started 14-2.1.1 What PVM Daemons Do. If a user starts the FINE™ interface on a given computer where no PVM daemon is running, FINE™ will start the process pvmd on this machine that becomes the virtual machine server for the user. When adding a host in the Task Manager (on the Hosts definition page) a pvmd is started on the remote computer that is added to the virtual machine. If after that the user logs on the second computer and starts the FINE™ interface this second computer belongs also to the virtual machine whose server is the first pvmd started. If after that the user logs on a third computer on which no pvmd is running and starts the FINE™ interface, FINE™ will start a pvmd that becomes the server of a new virtual machine. When trying to add a host belonging the first virtual machine (containing the two first computers), he will see the a warning message that he cannot connect to the virtual machine because a pvmd is already running. If the user wants to have the three computers in the same virtual machine, one of the virtual machines must be shut down (on the Hosts definition page) and add the corresponding computers from the second one. 14-2.1.2 Limitation under Windows On windows only one pvmd can run and hence, only one single user can connect to the virtual machine. If an other user wants to use the NUMECA software on the PC as server (FINE™) or as client (EuranusTurbo), the first one needs to shut down the pvm daemons on this machine. To shut down go to the Hosts definition page and click on Shutdown. This will close the interface and removes all the pvm daemons on the machine. Remove the files pvml. and pvmd. from the directory defined by the PVM_TMP (by default C:\tmp). 14-2.2 Multiple FINE™ Sessions During a FINE™ session all the tasks defined by the user are stored in the tasks file in the NUMECA tmp directory. This directory is in the .numeca/tmp directory below the home directory. On UNIX the home directory corresponds to the HOME environment variable. This is also true on Windows if this variable is defined and, if it is not the case, it is set to the concatenation of HOMEDRIVE and HOMEPATH environment variables. When FINE™ is started more than once at the same time, a warning indicates to the user that FINE™ is already running and can enter in conflicts with the other FINE™ sessions. Indeed, the user can define tasks in both interfaces but the task definitions saved when exiting FINE™ will be overwritten by the other sessions. Therefore, it is not advised to open multiple FINE™ sessions when the Task Manager must be used. 14-2.3 Machine Connection from UNIX/LINUX Platforms The Task Manager allows the user to control processes on all the machines connected to the network. The rsh command is used by the PVM library to access the machines. Before using the Task Manager, the following actions must be done: 1. 14-2 Modify the .rhosts file in the home directory by introducing all the machines which can be used by the Task Manager. i.e.: if the machines machine1 and machine2 will be used by the user’s tasks, the .rhosts file must be modified as follows: line1: machine1 line2: machine2 where machine1 and machine2 are the host names. FINE Getting Started The Task Manager login1 and login2 are optional. They must be set if the login on remote host is different from the login on the local host. The .rhosts file needs to be ended by a blank line. The .rhosts file permission must be set to ’rw’ (chmod 600 ~/.rhosts). 2. Test the rsh command on the desired machine: an external check that the .rhosts file is set correctly is to enter the following command line: % rsh remote_host ls where remote_host is the name of the machine to connect to. If the login on the remote host is not the same, ensure that the .rhosts file contains the line: remote_host local_login and in this case the command line is: % rsh remote_host -l local_login ls If the .rhosts is set up correctly, a listing of the files is shown on the remote host.
1. Log on the machine where the connection must be established. 2. Start FINE™ and open the Task Manager through Modules/Task Manager and use the button Shutdown of the page Hosts definition. The button Shutdown can be used to switch off all the PVM daemons of all the machines connected to FINE™. This action will stop all the daemons on all the machines connected, kill all the tasks and finally exit FINE™. 3. On UNIX: remove all the /tmp/pvmd. and /tmp/pvml. files. Under Windows these files should be removed from the directory defined by PVM_TMP (by default this directory is C:\tmp). 4. Repeat this operation for all the machines on which the problems appear.
5. The operations 2 and 3 can be done automatically using the script NUMECA_INSTALLATION_DIRECTORY/COMMON/cleanpvmd provided with the NUMECA software. If PVM still has a problem to get the connection, it will print an error message either to the screen, or in the log file /tmp/pvml. (on UNIX) or in the directory defined by the environment variable PVM_TMP (by default C:\tmp) in the log file called: pvml.. Please send this log file to NUMECA support team ([email protected]).

FINE Due to a limitation of the PVM library, FINE™ can not be connected to a machine where FINE™ has already been started. When PVM tries to establish the connection, it detects that a server FINE™ is already running and/or pvm daemons are still running and finally refuses the connection with a warning. To solve this problem, the PVM daemons must be stopped on the machine on which FINE™ must be connected: All these operations apply only to the user’s daemons and user’s files. Multiple users can use the Task Manager simultaneously. No interaction appears between PVM daemons and PVM log files of different users. The Task Manager does not allow to launch processes from a UNIX platform to a Windows platform. 14-3 Getting Started The Task Manager 14-2.4 Machine Connection from Windows Platforms When a user stops the pvmd on a remote host (using Remove Host button on the Hosts definition page) and immediately try to restart it (using the Add Host... button), a message will appear stating that it is not possible to connect. This problem does not occur in general since there is no need to remove a host and add it immediately after. When it occurs the only solution is to wait until the host is available again (after 5 to 10 minutes).
From time to time, when a user tries to connect on a remote host, an error message can appear very briefly: "Can not connect to RSH Port!!!" This may happen on Windows connecting to a host, disconnecting, and trying to reconnect again to the same host. It has the inconvenience to stop the interface FINE™. There is a socket release time parameter which keeps the connection for some time. 14-2.5 Remote Copy Features on UNIX/LINUX All the tasks defined by the user are associated with files used or created by the NUMECA’s software. When the files are not visible from the machine on which the task must be launched (i.e. the files are on the local disk of the host where FINE™ is running), the user can use the remote copy feature proposed in the Task Manager. All the files needed by the tasks will be transferred into a directory (specified by the user) of the remote machine and at the end all the created or modified files are transferred back to the host machine from which the task has been launched. By default, the available remote directories are "/tmp". The user can also specify any other directory, as long as it is visible from the remote host and has writing permission. This feature uses the rcp UNIX command. Before using the remote copy feature, it is advised to first check if the rcp command works correctly between the machines: — First try the rsh.exe command (see section 14-2.3). — Type the command: touch test;rcp -p -r test destination_machine:/tmp/test. If no error is returned by the system, the remote copy works between the local host and the destination_machine. Errors may appear if the .cshrc file contains an stty command. In order to be able to use the remote copy feature, remove all the stty commands from the .cshrc file. — If the login on the local host is different from the login on the remote host, type the command: touch test;rcp -p -r test remote_login@destination_machine:/tmp/test. 14-2.6 Remote Copy Features on Windows As files located on the local disk are not visible from a UNIX machine, this feature is proposed to be able to launch tasks on remote UNIX platforms. The principle is the same as the one described in the previous section: local files are copied in the remote directory specified by the user, then the task starts. When it terminates, all results files are transferred in the original directory. This feature uses rcp.exe windows command. Before using the remote copy feature, it is advised to first check if this command works properly: — First try the rsh.exe command (see section 14-2.3). — Create a file test, then type the command: rcp -b test destination_machine:/tmp/test. If no error is returned by the system, the remote copy works between the local host and the destination_machine. Errors may appear if the .cshrc file contains an stty command. In order to be able to use the remote copy feature, remove all the stty commands from the .cshrc file. — If the login on Windows is different from the login on the remote host, type the command: 14-4 FINE The Task Manager Interface The Task Manager rcp -b test destination_machine.remote_login:/tmp/test rcp.exe is provided with FINE™ and is located in the same directory as rsh.exe. 14-3 The Task Manager Interface 14-3.1 Hosts Definition On the Hosts definition page hosts in the virtual machine, the operating system of the machine and their connection status are visualized. For an explanation of the virtual machine see section 142.1.1. If the connection is not OK, it means that the corresponding computer is no more in the virtual machine. This may occur for example if the computer has been rebooted. FIGURE 14.3.1-1Hosts definition page 14-3.1.1 Add Host When the user clicks on the Add Host... button, the interface asks for a host name and a login name. The login name is optional. It is needed only if the user login on the local host and the one on the remote host are different. When the user accepts (Accept), the host name appears in the host list, with type of operating system and its connection status. At this point, the host is in the virtual machine, and is ready to receive a task.
FINE if the connection can not be established, check for more detail in section 14-2.1, sec- 14-5 The Task Manager Interface The Task Manager tion 14-2.3 and section 14-2.4. 14-3.1.2 Remove Host When the user clicks on Remove Host button, the selected host is removed from the list, and is not in the virtual machine any more. This operation is not allowed when a task is running on the host to be removed, or when the selected host is the local one. 14-3.1.3 Shutdown When the user clicks on Shutdown button, all hosts in the virtual machine are removed. FINE™ exits and the virtual machine halts. All running tasks are killed. This option is useful when the user wants to change the machine on which FINE™ is running. See section 14-2.1.1 for more detail on virtual machines and when to change this. 14-3.2 Tasks Definition A task is a collection of subtask where a subtask is one of the program with its arguments (’.run’ file for EURANUS and Design3D, template ’.trb’, geometry ’geomTurbo’ and mesh ’.igg’ files for AutoGrid and macro file .py and ’.run’ file for CFView™). The different subtasks of a given task can be run simultaneously if the output of one subtask is not needed by other ones (for example: several CFView™ subtasks with different macro ’.py’ files or several EURANUS subtasks with different ’.run’ files started on different computer). If the output of one subtask is needed by other ones, it must be run sequentially. For example: AutoGrid generates the mesh that is used for starting an EURANUS computation whose output is used for starting CFView™. 14-3.2.1 Task List In this section, the user can visualize the defined tasks and their status. To create a task, just click on New Task button. The defaults task name can be modified by clicking on Rename Task button. The selected task can be removed by clicking on Remove Task button. Once a task is created and defined (see following section), it can be started or stopped just by clicking respectively on the Start, or Stop button. A task can be delayed: click on Delay button and enter the date and time for the moment the task needs to be launched in the dialog box. The delayed task can be disabled using the button Cancel. When the user validates the data, a little watch in the task list indicates that the task is scheduled: FIGURE 14.3.2-2Task
14-6 List with Delay window to start a task at a later moment When exiting FINE™, all the delayed tasks are automatically started and stay in sleep mode until their starting dates are reached. When starting FINE™ again, all the task FINE The Task Manager Interface The Task Manager manager related to the delayed tasks still in sleep mode are killed and FINE™ Task Manger gets back the control of these tasks. 14-3.2.2 Task Definition In this section the subtasks of the selected task of the Task List are listed. A subtask is defined by its type (euranusTurbo, AutoGrid, CFView™ or Design3D), their status and the host on which they are launched. To add a subtask click on the New Subtask. Select the executable name (EURANUS, AutoGrid, CFView™ or Design3D) and the host on which the process should be started in the two lists. The host name list contains the hosts that are in the virtual machine. They are set in the Host definition page. 14-3.2.3 Subtask Arguments a) Definition of Input and Output Once a subtask is created, input and/or output files must be defined in the Subtask arguments section: — The flow solver EURANUS and Design3D requires one argument file: the name of the runfile. This files is created using the menu File/Save Run Files in the FINE™/Turbo module. — The mesh generation system AutoGrid requires three files as arguments: the trb file, the geomTurbo file and as output the grid file name (see the AutoGrid manual for more details) FINE 14-7 The Task Manager Interface The Task Manager — The flow visualization system CFView™ requires two files: the run file and a macro file (see CFView™ manual for more details) The run file is automatically opened by CFView™ before starting the macro. The macro file may open other ’.run’ files to perform flow comparisons (see CFView™ manual for more information about the macro ’.py’ file). b) Simultaneous or Sequential Mode Moreover, a process can be executed simultaneously with the other subtasks (by selecting Run Simultaneously with Previous Subtask) or sequential (by selecting Run After Previous Subtask). In this last case, the process waits the previous subtask to be finished before starting. This is only available for AutoGrid, Design3D and EURANUS subtasks. Only a certain amount of tasks can be performed at the same time depending on the available licenses. The subtasks related to postprocessing with CFView™ are always executed in sequential mode. c) Remote Copy The Remote copy to button allows the user to specify that the files are not visible from the remote machine and must be transferred. This is only available for AutoGrid, Design3D and EURANUS. d) Parallel Computations. d.1) MPI system The flow solver euranusTurbo has integrated multiprocessor machine concept. The button Parallel Computation can be activated to specify that the parallel version of the flow solver can be used for this computation. The button Flow solver parallel settings gives access to the dialog box used to set up a parallel computation. When the dialog box is opened, the block list displayed all the block of the mesh. The user can defined new processes on all the available machines and defined manually or automatically the load balancing (using the Automatic Load Balancing button).
The parallel processing can only be used on multiprocessor machine (shared memory mode) or on machines with the same operating systems (homogenous distributed memory mode) See section 14-4 for more detailed information on parallel computations. 14-8 FINE The Task Manager Interface The Task Manager Processes list with the load balancing of the cells Buttons used to remove or add new processes on the specified machine List of the block in the associated mesh Default block distribution Button used to link the selected block with a process d.2) SGE system Within the Task Manager provided in FINE™/Turbo v6.2-7, the parallel process can be set using the SGE (Sun Grid Engine) batch system. This last sytem includes the possibility to add a SGE type host and to define arguments needed to launch the computation within the Task Manager. Host Definition In the page Hosts definition the user needs to add host. When adding the host, automatic checks are performed: 1. it will detect if the "sge_qmaster" is running on the platform. If not, it means that the platform does not have SGE capabilities or the platform is not the SGE master processor. 2. it will detect all parallel environment defined in SGE. 3. it will detect all parallel environment that the user is allowed to use. If no parallel environment could be accessed by the user, his login should be added to the user list by the SGE administrator. When all checks are successfull, the SGE capability of the added host is activated and the user can see if the host added is a SGE paltform within the Task Manager GUI (Figure 14.3.1-1). Task Definition In the page Tasks definition, if the user select a SGE platform when launching an EURANUS task in parallel, he has the access to the MPI system or the SGE system (Figure 14.3.2-3). When the SGE system is used, the number of processor and the SGE environment have to be specified. Depending on the number of processor, an automatic load balancing is performed to update the block distribution and the process needs only to be started by the user. FINE 14-9 The Task Manager Interface The Task Manager FIGURE 14.3.2-3Tasks Definition - SGE inputs Process Management Once the process is starting, the ".run" file is modified automatically depending of the number of processor. Then a script file ".sge" is created at the same time as the ".p4pg" file when using MPI system.
The name of the SGE job is limited to 8 characters and the following format is thus chosen "comp#000" where 000 stands for a any number depending of the number of SGE jobs already running under the same environment. To test if a computation is running, because there are no communication with the task manager since EURANUS has not been launched using PVM daemon, the "qstat" command with the job-ID number of the SGE job is used. To suspend the SGE job, the user could use the Suspend function of the Task Manager. It will create automatically a ".stop" file in the running computation directory that will enable EURANUS to suspend after saving the solution at the next iteration or after the full multigrid initialization. To kill the SGE job, the user could use the Stop function. The Task Manager will then use the SGE’s function "qdel" to kill the computation without saving the solution.
To kill EURANUS properly, the SGE’s "execd parameters" variable should be set to "NOTIFY_KILL=TERM" and the "notify time" variable of nodes should be set to a sufficient value to allow EURANUS to exit properly. We invite the user to ask the SGE administrator to check these variables. e) Message Window When a task is started, a Task Manager process is launched to take care about the task management: process communication, automatic launching of the sequential and parallel subtasks. A message window linked to the Task Manager is opened. In this window the user can follow the evolution of the status of all the subtasks of the current task. In case of flow solver computations the iterations are also displayed in this window as shown in Figure 14.3.2-4. At the bottom of the Task Manager window a Refresh Rate can be chosen. This rate determines how frequently the Task Manager window is updated. A higher refresh rate will update the information in the window more frequently but will use more of the available CPU. 14-10 FINE Parallel Computations The Task Manager FIGURE 14.3.2-4Task
Manager information window If the user quits FINE™, all the message windows will stay open and the tasks will continue. Closing a message window will immediately kill all the subtasks of the corresponding task. 14-4 Parallel Computations 14-4.1 Introduction Parallel computations can be defined through the FINE™ interface as described in section 14-3.2.3. Parallel processing relies on the distribution of independent tasks among several processors using communication protocols to transfer data from one processor to another whenever this is necessary. This induces of course an acceleration of the computation itself but it also makes possible very large computations that would not fit on a single processor. The present parallel processing relies on the block structure of the flow solver EURANUS. Each process is assigned a given number of blocks. As a consequence, the number of processors cannot exceed the number of blocks. Boundary data are exchanged between processors each time an update of the flow solution is required. The parallel version makes use of MPI (Message Passing Interface) libraries. MPI was chosen among other tools such as PVM or Open MP for its high communication performances (high bandwidth, low latencies). Although Open MP has better performance on shared memory configurations, i.e. on a given computer with single global memory and several processors, it is not designed for distributed memory configurations (several computers with their own memory). The parallel version is implemented for UNIX, LINUX and Windows platforms. FINE 14-11 Parallel Computations The Task Manager The present MPI implementation is based on a host/node approach. One host process is dedicated to input/output management. The host reads the mesh and input files, sends the data to the computation processes (the nodes), receives the computation results from the nodes and writes the output files. Figure 14.4.1-5 shows the task distribution on a 4 processors configuration. Note that the host/ node implementation will be replaced progressively as parallel MPI input/output functionalities are now available. Input data base reading Node 1 Host Node 2 boundary conditions FIGURE 14.4.1-5Tasks writing Output data base Node 3 boundary conditions in a parallel computation 14-4.2 Modules Implemented in the Parallel Version The following flow solver functionalities are already available in the parallel version: • All turbomachine boundary conditions (including Phase-lagged). These include rotor/stator interfaces, non matching boundaries and the fully conservative non matching boundary treatment (FNMB), • Turbomachinery initial solution, • Baldwin-Lomax, Spalart-Allmaras and k-ε turbulence models, • Real gases, • Preconditioning (low Mach number and incompressible fluids), • Cooling holes, • Outputs including pitchwise averaged output. No solid data nor surface averaged outputs are available yet.
The lagrangian module is not available for parallel computations. 14-4.3 Management of Inter-block Communication The block structure of the solver allows to distribute blocks across processors or computers (in case of a cluster). Each processor will handle an integer number of blocks. The treatment of the boundary condition will be replaced by message passing between the processors or remote computers. Communication optimization The parallel version of the flow solver is optimized in order to minimize duplicated data as well as the number and the volume of exchanged messages. A significant improvement of the code performance was obtained by grouping small messages into larger buffers: the information contained in small messages is usually shared by a large number of blocks, leading to frequent messages of 14-12 FINE Parallel Computations The Task Manager that type. This is the case for block edges data that are exchanged several times during each iteration. Significant latency times are induced by these communication processes and message grouping highly reduces the number of such messages. Large message limitation Very large messages are usually exchanged during initialization and at the end of the computation between the nodes and the host. These also need to be avoided as they can cause important memory needs and eventually lead to system failure. Messages are split into buffers of maximum size MXBFSZ (see section 14-4.4) in order to avoid excessive MPI memory requests. 14-4.4 How to Run a Parallel Computation The setting of a parallel run using the FINE™ interface is described in section 14-3.2.3. The user selects the number of nodes, making sure it is smaller than the number of blocks. A balanced distribution of the blocks among the various processes is automatically performed by the FINE™ interface but the user can also define its own load balancing, i.e. process distribution. Memory allocation Memory allocation is performed as follows: • The integer data structure is duplicated for all processes. Since the integer data structure size is about a tenth of the real data structure, this does not lead to high memory overload when the number of processes is less than 10. • The real memory allocation is performed for each process. It should be set to the minimal amount of memory necessary to hold the data structure on the process that has most grid points. When the load is well balanced, the real memory overload is due to face and edge data structures. These data need indeed to be duplicated when two processors are involved in the same block connection. The total memory need Mtotal for a parallel computation involving n ( n ≥ 2 ) processors can be estimated as: n M total = M real ⋅ 1, 2 ⋅ ------------ + M integer ⋅ n n–1 where Mreal and Minteger are the real and integer memory needed for the same computation in sequential mode. From a practical point of view, the user does not specify the total memory needed but the integer M real and real memory required per processor. This can be estimated as --------------- ⋅ 1, 2 for the real mem- n ory and Minteger for the integer memory.
FINE In case of parallel calculation the estimated number of real memory displayed by FINE™ on the page Control Variables shall not be followed but the formula shown above shall be respected. 14-13 Task Management Using Scripts The Task Manager The following table states the total memory need for a parallel computation using respectively 4 and 6 and 8 processors. The values of Mreal and Minteger are set to 10 Mb and 1 Mb respectively. The equivalent memory request on a single processor is thus 11Mb. n Mtotal (Mb) Parallel overhead (Mb) 4 20 9 6 20.4 9.4 8 21.7 10.7 TABLE 14-1 Parallel memory request In the present implementation, the presence of the host processor increases the global memory request. It also reduces the overall speed-up of the computation as it is mainly dedicated to I/O management and no computation is affected to it. Future versions of EURANUS will optimize this aspect by removing gradually the need of a host processor. Message size limitation During initialization and final steps, large messages are usually exchanged between the nodes and the host process. In order to avoid any system failure, messages are split into buffers of maximum size. This size is set to 100000 by default but the user can eventually tune this value through the expert parameter MXBFSZ. 14-4.5 Troubleshooting If the computation is interrupted for an unknown reason, more detailed information is provided in the ’.std’ and ’.log’ computation files. The file contains all relevant informations including MPI error messages and should be sent to the NUMECA support team. 14-4.6 Limitations • The distributed memory mode is restricted to homogeneous (i.e. with the same operating system) clusters. • The number of processors should not exceed the number of blocks. 14-5 Task Management Using Scripts This section provides all available information to launch installed NUMECA Software from a shell, without using IGG™, AutoGrid, FINE™ or CFView™ interfaces. Every time a task is started a script file is automatically created. On UNIX the name of this file has the extension .batch and under Windows the extension is .bat. Such files contain text lines with the commands to launch the software with the appropriate command arguments. To launch a task from a shell simply execute the automatically generated file by typing its name in a shell. In the next sections the available commands to launch NUMECA software are described in more detail.
14-14 Please notice that the capability to launch in batch is currently not supported for EURANUS in Parallel Mode on PC. FINE Task Management Using Scripts The Task Manager 14-5.1 Launch IGG™ Using Scripts 14-5.1.1 How to Launch IGG™ on UNIX To launch IGG™ without use of the interface the commands to perform must be written in a macro script file. To create such a file: 1. Create a script file *.py. For more details on the commands that can be included in such a script file see the IGG™ manual. 2. Set permission for execution for the script by using the command: "chmod 755 *.py". 3. Launch the macro script in a shell by typing: igg -script /user/script.py -batch -niversion 62_7 The command line to start the grid generator IGG™ contains its name, the full path name of the script "*.py" file to launch and the IGG™ release that will be used. The "-batch" option avoids the display of the IGG™ graphical user interface. "igg SCRIPT_PATH/script.py -batch -niversion " 14-5.1.2 How to Launch IGG™ under Windows 1. Create script file "*.py". For more detailed information on the commands to include in a macro script see the IGG™ manual. 2. Set permission for execution of the file *.py Launch the macro script *.py by typing in a shell: d:\NUMECA_SOFTWARE\fine62_7\bin\igg.exe -script d:\user\test.py -batch 3. The command line to start the grid generator IGG™ contains its full path name and the full path name of the script "*.py" file to launch. The "-script" & "-batch" options respectively permits to launch the script and avoids to display the IGG™ graphical user interface. "IGG_PATH\igg.exe -script SCRIPT_PATH\script.py -batch" REMARKS: • The full path name of the executable (igg.exe) has to be specified. • The full path name of the script has to be specified. • If there is a segmentation fault at exit (due to an incontrollable "opengl" problem), it is possible to avoid it by adding -driver msw option: d:\NUMECA_SOFTWARE\fine62_7\bin\igg.exe -script d:\test.py -batch -driver msw 14-5.2 Launch AutoGrid using Scripts 14-5.2.1 How to Launch AutoGrid on UNIX 1. Create a template and geometry files (*.trb and *.geomTurbo) using the AutoGrid interface. Start AutoGrid to create a mesh from these files by typing: igg -batch -autoGrid /user/test.trb /user/test.geomTurbo /user/test.igg -niversion 62_7 2. The command line to start the grid generator AutoGrid contains its name, the full path name of the template, of the geometry files, the full path name of the mesh that will be saved and the IGG™ release that will be used. The "-batch" option avoids the display of the IGG™ graphical user interface. FINE 14-15 The Task Manager Task Management Using Scripts 14-5.2.2 How to Launch AutoGrid under Windows 1. Create a template and geometry files (*.trb and *.geomTurbo) using the AutoGrid interface. Start AutoGrid to create a mesh from these files by typing on one line: d:\NUMECA_SOFTWARE\fine62_7\bin\igg.exe -batch -autoGrid c:\users\template.trb c:\users\template.geomTurbo c:\users\mesh.igg 2. The command line to start the grid generator AutoGrid contains its full path name, the full path name of the template, of the geometry files and the full path name of the mesh that will be saved. The "-batch" option avoids the display of the IGG™ graphical user interface. 14-5.3 Launch EURANUS in Sequential using Scripts 14-5.3.1 How to Launch EURANUS in Sequential on UNIX 1. Create a script file (for example, with the name ’batch.sh’). Such a script file (e.g. ’batch.sh’) must be created with permission for execution to launch a series of computations. An example of a ’batch.sh’ file for a series of computations on UNIX: #! /bin/csh euranusTurbo /users/project/project_computation_1/project_computation_1.run -niversion 62_7 euranusTurbo /users/project/project_computation_2/project_computation_2.run -niversion 62_7 The script is started in a C-shell that is obtained by having as its first line: " #! /bin/csh". The command line, to start the flow solver EURANUS, contains its name, the full path name of the ’.run’ file to launch and the FINE™ release that will be used: "euranusTurbo COMPUTATION_PATH/computation.run -niversion " 2. Set Permission for execution for the script file ’batch.sh’ by typing the command: "chmod 755 batch.sh". 3. Create an input file (’.run’) for each computation. To create those files through the FINE™ interface, click on the File/Save Run Files menu in order to save the ’.run’ file of the activated computation, after opening the corresponding project. 4. Launch the script ’batch.sh’ by typing the script file name: ’./batch.sh’.
When saving the ’.run’ file of the computation (File/Save Run Files) and launching the computation (Solver/Start...) killed just afterwards (Solver/Kill...), a new script ’.bat’ on WINDOWS (’.batch’ on UNIX) is created in the corresponding computation subfolder that enables the user to launch the same computation in batch. 14-5.3.2 How to Launch EURANUS in Sequential under Windows 1. Create Script File ’.bat’. An example of ’.bat’ file for a series of computations on Windows: C:\NUMECA_SOFTWARE\fine62_7\bin\euranus.exe C:\users\project\project_computation_1\project_computation_1.run -seq \\ C:\NUMECA_SOFTWARE\fine62_7\bin\euranus.exe \\ C:\users\project\project_computation_3\project_computation_3.run -seq 14-16 FINE Task Management Using Scripts The Task Manager C:\NUMECA_SOFTWARE\fine62_7\bin\euranus.exe \\ C:\users\project\project_computation_2\project_computation_2.run -seq The command line, to start the flow solver EURANUS, contains its full path name, the full path name of the ’.run’ file to launch and the sequential mode selection: INSTALLATION_DIRECTORY\fine62_7\bin\euranus.exe COMPUTATION_PATH\project_computation_1.run -seq \\ 2. Set Permission for Execution ’.bat’ 3. Create an input file (’.run’) for each computation. To create those files through the FINE™ interface, click on the File/Save Run Files menu in order to save the ’.run’ file of the activated computation, after opening the corresponding project. 4. Launch the script ’.bat’ by typing the script file name: ’.bat’ in a shell or double click on the ’*.bat’ file from the Windows Explorer.
When saving the ’.run’ file of the computation (File/Save Run Files) and launching the computation (Solver/Start...) killed just afterwards (Solver/Kill...), a new script ’.bat’ on WINDOWS (’.batch’ on UNIX) is created in the corresponding computation subfolder that enables the user to launch the same computation in batch. 14-5.4 Launch EURANUS in Parallel using Scripts 14-5.4.1 How to Launch EURANUS in Parallel using MPI on UNIX 1. Create a script file ’batch.sh’ with permission for execution. An example of a ’batch.sh’ file for a parallel computation on UNIX: #! /bin/csh euranusTurbo_parallel /users/project/computation/computation.run -niversion 62_7 -p4pg / users/project/hosts.p4pg The script is started in a C-shell that is obtained by having as its first line: " #! /bin/csh". The command line, to start the flow solver EURANUS in parallel, contains the script name that enables parallel computation, the full path name of the ’.run’ file to launch, the FINE™ release and the full path name of the file ’hosts.p4pg’ containing the definition of the machines that will be used to launch the computation in parallel: "euranusTurbo_parallel COMPUTATION_PATH/computation.run -niversion -p4pg HOST_PATH/hosts.p4pg"
2. The name of the executable is different from the one for sequential computations. Create Hosts Definition File ’hosts.p4pg’. A file needs to be created to define the hosts (e.g. ’hosts.p4pg’). This file specifies the machine information regarding the various processes. An example of a ’hosts.p4pg’ file: Example 1: Hostname1 4 euranusTurbo62_7(master host on Hostname1 and 4 processes on Hostname1) Hostname2 2 euranusTurbo62_7(2 processes on Hostname2) FINE 14-17 Task Management Using Scripts The Task Manager Example 2: Hostname1 0 euranusTurbo62_7 (master host on Hostname1 and no other process on Hostname1) Hostname2 2 euranusTurbo62_7 (2 processes on Hostname2) For each machine, a line must be added consisting of the machine name (the machine hostname), the number of processes to run on the machine, the name of the executable and the FINE™ release: "hostname 4 euranusTurbo" If additional machines are to be used, subsequent lines are required for each one. If the number of processors is set to 0 for the first machine (first line of the ’hosts.p4pg’ file), only the master host process will run on that machine while the nodes will run on the next machines declared in the following lines.

3. The first machine (hostname) specified in the file ’hosts.p4pg’ should be the one from which the script will be launched. The total number of processes defined in the file ’hosts.p4pg’ should be equal to the number of nodes running. Set permission for execution ’batch.sh’ by using the command: "chmod 755 batch.sh" Create input files ’.run’ to launch the computation. The parallel settings of the computational file (’.run’) are managed by the Task Manager. Therefore before launching the parallel computation script, the following steps must be performed through the FINE™ interface: 4. Create computational file (’.run’) by activating the corresponding computation and clicking on the File/ Save Run Files menu in the interface. 5. To set the final parallel settings: — — — — 6. create a task in the Task Manager, define the parallel settings of EURANUS subtask (parallel computation), launch the task through the Task Manager by clicking on Start, kill the task when EURANUS flow solver starts by clicking on Stop. This operation is mandatory in order to have all the parallel settings correctly imposed in the computation file (’.run’). Launch the script ’batch.sh’ by typing the script file name: "./batch.sh".
When saving the ’.run’ file of the computation (File/Save Run Files) and launching the computation in parallel as explained in step 5 through the Task Manager (Modules/Task Manager) and killed it just afterwards, a new script ’.batch’ and a file ’.p4pg’ are created in the corresponding computation subfolder that enable the user to launch the same computation in batch and in parallel. 14-5.4.2 How to Launch EURANUS in Parallel using MPI on Windows 1. Create a script file ’batch.bat’ with permission for execution. An example of a ’batch.bat’ file for a parallel computation on Windows: D:\NUMECA_SOFTWARE\Fine62_7\bin\mpirun.exe "D:\test\test_computation_1\test_computation_1.p4pg" "D:\test\test_computation_1\test_computation_1.run" / / The command line, to start the flow solver EURANUS in parallel, contains the script name that enables parallel computation, the full path name of the ’.run’ file to launch and the full path name of the file ’.p4pg’ containing the definition of the machines that will be used to launch the computation in parallel: 14-18 FINE Task Management Using Scripts The Task Manager "NUMECA_RELEASE_PATH/mpirun.exe HOST_PATH/hosts.p4pg COMPUTATION_PATH/computation.run " 2. Create Hosts Definition File ’.p4pg’. A file needs to be created to define the hosts (e.g. ’hosts.p4pg’). This file specifies the machine information regarding the various processes. An example of a ’hosts.p4pg’ file: Example 1: Hostname1 5 D:\NUMECA_SOFTWARE\Fine62_7\bin\euranus.exe (master host on Hostname1 and 4 processes on Hostname1) Hostname2 2 D:\NUMECA_SOFTWARE\Fine62_7\bin\euranus.exe(2 processes on Hostname2) Example 2: Hostname1 1 D:\NUMECA_SOFTWARE\Fine62_7\bin\euranus.exe (master host on Hostname1 and no other process on Hostname1) Hostname2 2 D:\NUMECA_SOFTWARE\Fine62_7\bin\euranus.exe (2 processes on Hostname2) For each machine, a line must be added consisting of the machine name (the machine hostname), the number of processes to run on the machine, the name of the executable and the FINE™ release: "hostname 4 NUMECA_RELEASE_PATH\bin\euranus.exe" If additional machines are to be used, subsequent lines are required for each one. If the number of processors is set to 1 for the first machine (first line of the ’.p4pg’ file), only the master host process will run on that machine while the nodes will run on the next machines declared in the following lines.

3. The first machine (hostname) specified in the file ’.p4pg’ should be the one from which the script will be launched. The total number of processes defined in the file ’.p4pg’ should be equal to the number of nodes running. Set permission for execution ’batch.bat’ Create input files ’.run’ to launch the computation. The parallel settings of the computational file (’.run’) are managed by the Task Manager. Therefore before launching the parallel computation script, the following steps must be performed through the FINE™ interface: 4. Create computational file (’.run’) by activating the corresponding computation and clicking on the File/ Save Run Files menu in the interface. 5. To set the final parallel settings: — — — — 6. create a task in the Task Manager, define the parallel settings of EURANUS subtask (parallel computation), launch the task through the Task Manager by clicking on Start, kill the task when EURANUS flow solver starts by clicking on Stop. This operation is mandatory in order to have all the parallel settings correctly imposed in the computation file (’.run’). Launch the script ’batch.bat’ by typing the script file name: "./batch.bat" in a DOS-shell.
FINE When saving the ’.run’ file of the computation (File/Save Run Files) and launching the computation in parallel as explained in step 5 through the Task Manager (Modules/Task Manager) and killed it just afterwards, a new script ’.bat’ and a file ’.p4pg’ are created in the corresponding computation subfolder that enable the user to launch the same computation in batch and in parallel. 14-19 The Task Manager Task Management Using Scripts 14-5.4.3 How to Launch EURANUS in Parallel using SGE on UNIX 1. Create a script file ’batch.sge’ with permission for execution. An example of a ’batch.sge’ file for a parallel computation on UNIX: #! /bin/csh #$ -S /bin/sh #$ -o /home/sgeuser/parallel_sge/parallel_sge_computation_1/ parallel_sge_computation_1.std -j y #$ -N comput1 #$ -pe numecampi 3 #$ -notify P4_GLOBMEMSIZE=15000000 Export P4_GLOBMEMSIZE NI_VERSIONS_DIR=/usr/numeca MPIR_HOME=$NI_VERSIONS_DIR/_mpi cd /home/sgeuser/parallel_sge/parallel_sge_computation_1 $MPIR_HOME/bin/mpirun -np $NSLOTS -machinefile $TMPDIR/machines \ $NI_VERSIONS_DIR/bin/euranusTurbo62_7 \ /home/sgeuser/parallel_sge/parallel_sge_computation_1/parallel_sge_computation_1.run where: #$ -S /bin/sh requires Bourne shell to be used by SGE for job submission and hence, only the .profile file of the user is executed if exists on each computation host. There is nothing specific to Numeca software that must be written . the .profile file. #$ -o /home/sgeuser/parallel_sge/parallel_sge_computation_1/ parallel_sge_computation_1.std -j y tells SGE system that the standard output has to be redirected in the ".std" in the computation directory, the option "-j y" indicates that the standard error is redirected into the same file. #$ -N comput1 is the name of the job given to SGE and that will be seen when monitoring the job with the graphical monitoring utility qmon (Job Control button ) or with the qstat SGE command. SGE has a limitation of 8 characters for the job name. #$ -pe numecampi 3 requests 3 slots (processors) to the SGE system for executing the job using the numecampi parallel environment described in chapter 2.1. This must correspond to NTASK +1 where NTASK is the number of computation processes in the ".run" file, the "+1" being the host process that manages inputs/outputs. #$ -notify gives a delay between the send of the SIGKILL signal and SIGUSR2 signal. The delay is defined in the SGE interface. P4_GLOBMEMSIZE=15000000 Export P4_GLOBMEMSIZE NI_VERSIONS_DIR=NUMECA_RELEASE_PATH MPIR_HOME=$NI_VERSIONS_DIR/_mpi are the environment variables indicating respectively the Numeca software installation directory and the mpi directory that are used in the following command: 14-20 FINE Task Management Using Scripts The Task Manager $NSLOTS is the number of slots (processors) that have been allocated by SGE for the job, $TMPDIR is generated by SGE for providing the machines file used by the mpirun script. $NI_VERSIONS_DIR/bin/euranusTurbo is a symbolic link to the numeca_start startup script for all Numeca softwares and 62_7 is the version of the code that will be used and requires that it is installed under /NUMECA_RELEASE_PATH/fine62_7. /home/sgeuser/parallel_sge/parallel_sge_computation_1/parallel_sge_computation_1.run is the argument to the euranusTurbo executable.
2. For sequential runs, the line "#$ -pe numecampi 3" must be removed and the final command must be: $NI_VERSIONS_DIR/bin/euranusTurbo62_7 \ /home/sgeuser/ parallel_sge/parallel_sge_computation_1/parallel_sge_computation_1.run -seq Set permission for execution ’batch.sge’ by using the command: "chmod 755 batch.sge" Create input files ’.run’ to launch the computation. The parallel settings of the computational file (’.run’) are managed by the Task Manager. Therefore before launching the parallel computation script, the following steps must be performed through the FINE™ interface: 3. Create computational file (’.run’) by activating the corresponding computation and clicking on the File/Save Run Files menu in the interface. 4. To set the final parallel settings: — — — — 5. create a task in the Task Manager, define the parallel settings of EURANUS subtask (parallel computation), launch the task through the Task Manager by clicking on Start, kill the task when EURANUS flow solver starts by clicking on Stop. This operation is mandatory in order to have all the parallel settings correctly imposed in the computation file (’.run’). Launch the script ’batch.sge’ by typing the script file name: "./batch.sge".
When saving the ’.run’ file of the computation (File/Save Run Files) and launching the computation in parallel as explained in step 4 through the Task Manager (Modules/ Task Manager) and killed it just afterwards, a new script ’.sge’ is created in the corresponding computation subfolder that enables the user to launch the same computation in batch and in parallel. 14-5.5 Launch CFView™ Using Scripts 14-5.5.1 How to Launch CFView™ on UNIX 1. Create a macro file ’.py’. For more details see the CFView™ for more detailed information on the format of a macro file and the commands that can be included in a macro file. 2. Launch the macro ’.py’ by typing: cfview -macro /user/test.py -batch -niversion 62_7 The command line to start CFView™ contains its name, the full path name of the macro ’.py’ file to launch and the CFView™ release that will be used. The ’-batch’ option avoids the display of the CFView™ graphical user interface. "cfview -macro MACRO_PATH/macro.py -batch -niversion " 14-5.5.2 How to Launch CFView™ on PC under Windows 1. FINE Create a macro file ’.py’. For more details see the CFView™ for more detailed information on the format of a macro file and the commands that can be included in a macro file. 14-21 The Task Manager Limitations Launch the macro ’.py’ by typing: d:\NUMECA_SOFTWARE\fine62_7\bin\cfview.exe -macro \user\test.py -batch 2. The command line to start CFView™ contains its full path name and the full path name of the macro ’.py’ file to launch. The ’-batch’ option avoids the display of the CFView™ graphical user interface. 14-5.5.3 Command Line Arguments The command cfview may be followed by a set of command line arguments. Those command line arguments allow to override some system defaults (used driver, display, double-buffering and update abort options) or to specify files to be loaded immediately (project, macro, defaults settings, macro module). The supported command line arguments are: -help prints a summary of the command line arguments, -version prints the CFView™ version number, -date prints the CFView™ version date, -defaults starts CFView™ with the default settings from the specified file, -project starts CFView™ and opens immediately the specified project, -macro starts CFView™ and execute the specified macro script, -macromodule starts CFView™ and load the specified macro module, -display starts CFView™ on the specified display device, -doublebuffering on (off) activates (disables) double buffering, -updateabort on (off) activates (disable) update aborting (see the CFView™ manual for more detail on this option), -driver starts CFView™ with the specified graphics accelerator, -reversevideo on (off) starts CFView™ with black (white) background color (see the CFView™ manual for more detail on this option), -facedisplacement starts CFView™ with the specified face displacement (see the CFView™ manual for more detail on this option), -loaddata all (none, ask) when opening a project the quantities fields are loaded in the computed memory (are not loaded, a specific dialog box is raised where the user choose the field variables to be loaded). The defaults is to load all field quantities. (see the CFView™ manual for a description of the data management facility and of the associated dialog box), -batch on (off) starts CFView™ without graphical user interface. This mode can be used in combination with the -macro command line option in order to perform the execution of a macro script without user interaction, -hoops_relinquish_memory off this option disables the hoops garbage collection feature that is activated when CFView™ is idle during a long period of time. 14-6 Limitations The task manager have some limitations due to the current PVM and MPI libraries: 14-22 FINE Limitations The Task Manager • UNIX to PC connections are not allowed. • The remote copy works only if there is enough disk space on the remote machine. Currently, no check is performed to identify the available disk space and the flow solver crashes with "undifined reason". • Parallel computation with distributed memory are only available on homogenous UNIX/Windows platforms. • When a user launches FINE™ on different machines, the connection between these machines is not allowed as described in section 14-2.1.1. FINE 14-23 The Task Manager 14-24 Limitations FINE CHAPTER 15:Computation Steering and Monitoring 15-1 Overview This chapter describes the Computation Steering pages and the additional tool MonitorTurbo. First section 15-2 describes the Computation Steering/Control Variables page. Furthermore this chapter is completely dedicated to the monitoring tools available in FINE™ to monitor the global solution during and after a computation: • Computation Steering/Convergence History and Task Manager/Convergence History, see section 15-3 and • MonitorTurbo, see section 15-4. In section 15-5 advice is provided on how to use the monitoring tools in analysing the progress of a computation. 15-2 Control Variables The Computation Steering/Control Variables page allows to define some global parameters for the selected computation: • the Maximum Number Of Iterations on the finest grid level (i.e. not including the iterations performed during coarse grid initialization). • the Convergence Criteria corresponding to the (negative) number of orders of magnitude the norm of the residuals must decrease before stopping the calculation. If this criterium is not reached the calculation proceeds until the maximum number of iterations is performed. • The frequency for saving output (Save Solution Every): every x iterations the solver saves the flow solution and creates the output files to be read in CFView™(where x is the number of iterations defined in the FINE™ interface). • When the option Mimimum output is selected the solution is only saved at the last iteration. • the Memory Requirements for the computation. By default an estimation is given for the required memory. Depending on the parameters defining the computation additional memory may be needed. For example, more memory is required when full non-matching connections FINE™ 15-1 Convergence History Computation Steering and Monitoring or a k-ε turbulence model is used. Also the amount of selected output may require more memory. To allocate more memory for the computation select the button Set the requested memory. This will allow to define the amount of memory in Mb used for reals and integers.
For unsteady computations the Control Variables page is updated to give access to additional parameters as described in section 4-2.1 and section 4-2.3. Furthermore this page contains in expert mode two lists of expert parameters. Only the expert parameters that are described in the manual are supported. Use of the other parameters is not recommended. For a summary of all supported expert parameters see Appendix C. 15-3 Convergence History The Computation Steering/Convergence History or Task Manager/Convergence History page allows the user to define quantities to be followed during the convergence process of the flow solver EURANUS. This pages is divided in 5 areas as shown in Figure 15.3.0-1: 1. The steering files selection (Select Computations) and the curves export (Export Curves To File...) only available in Task Manager/Convergence History page. 2. The available variables (Available Variables). 3. The parameters (Parameters type). 4. The selected variables (Selected Variables). 5. The graphics view (Convergence History). (3) (2) (4) (1) (5) FIGURE 15.3.0-1The 15-2 five areas of the Convergence History page FINE™ Convergence History Computation Steering and Monitoring When the flow solver EURANUS is invoked, a communication is automatically established with FINE™ allowing the user to follow the selected quantities. Two representations of the quantities are currently available: the convergence curves displayed in the area 5 and the quantity value at the last iteration in the area 4. All these data are stored in files with extension .steering and .steering.binary. These files are created and managed automatically by FINE™
If the communication between the flow solver and FINE™ is interrupted (i.e.: network problem), parts of the convergence curves can be lost. 15-3.1 Steering Files Selection and Curves Export Different mode exists for the selection of the current steering results stored in the steering files: 1. When a project is opened, the active computation steering files is automatically selected and appears in the Add or select computations window (a) appearing when clicking on Select Computations button. Each time a new computation is selected, the associated steering file is automatically loaded and becomes the active one. (a) (b) (c) FIGURE 15.3.1-2Steering (d) files selection area 2. All the steering files already loaded can be selected by -leftclick and -leftclick in the list of available computations. 3. The file can also be loaded manually using the button Add Computation (c). A file chooser prompts the user to select the file. 4. The button Remove Computation allows the user to remove from the memory the selected computation (the file is not removed and remains available for selection). 5. Additionally, when a task is started, the steering files of the flow solver computation called in the task are automatically loaded and become available through the list (b). The Export Curves To File... button enables the user to save in an ASCII file ’.cvh’ all the curves plotted in the Graphics View. 15-3.2 Available Quantities Selection The available quantities selected by default are linked to the type of computation. For example, when launching a turbomachinery computation, the global residual, the inlet and outlet mass flow, the efficiency, the pressure ratio, the axial thrust and the Torque are computed during the convergence process. The Available Quantities list (b) allows the user to select and add (c) new quantities to the computed list FINE™ 15-3 Convergence History Computation Steering and Monitoring . (a) (b) (c) FIGURE 15.3.2-3Available
quantities selection area All the quantities can be added before or during the computation. When a quantities has been added, it appears in the selection list and becomes the selected quantity. If the flow solver is running, the value and the convergence curve of the new quantities is displayed after a few seconds. The convergence curve begins at the iteration corresponding to the moment when the new quantity has been added in the Selected Variables list. When a quantity is added for selection it appears in the selection list with a number behind the name. This number is only added to avoid to have two times the same variable name in the list. This is especially necessary when, for example, the static pressure is monitored at two different points in the domain. 15-3.3 New Quantity Parameters Definition When a new quantity has been added, it becomes available for selection in the Selected Variables list (area 4 in Figure 15.3.0-1). The user can select the way the flow solver computes the quantity through the parameter type area (area 2 in Figure 15.3.0-1). Several types of parameters can be chosen through the parameter type list box (a in Figure 15.3.3-4). The available types of parameters that can be defined to computed the selected quantities: 1. global: the computed variable is averaged over all the domain. 2. local 3d grid point: the user specify the grid point indices (I,J,K) and the block index (block id) where the quantity must be computed. (a) FIGURE 15.3.3-4Parameter
type definition Care should be taken when using the steering of a parameter on a local 3d grid point. It should be carried out in the following way: - select the parameter (relative velocity u, static pressure...). - add for selection. It becomes available for the selected variables. 15-4 FINE™ Convergence History Computation Steering and Monitoring - set the block id and the I,J,K indices of the grid point on which the evolution of the selected parameter will be visualized.
All the user modifications (I,J,K indices...) can also be done (and modified) during the computation run. 15-3.4 Quantity Selection Area When a quantity has been added, it becomes available for selection in the Selected Variables list. The list is divided in 3 columns as shown in Figure 15.3.4-5: the variable name (a) which can be changed using the button rename (d) , the quantity value (b) which displays the last computed value and the units (c) of the variable. The button remove (e) is used to remove the first selected variable. . (b) (a) (c) (d) (e) FIGURE 15.3.4-5Selected
variables area When a quantity is not yet computed, the value indicated is undefined. Selecting a quantity will show its history in the graphics view as described in the next paragraph. To select multiple quantities click on them (with the left mouse button) in the list while holding the or key. To select quantities that are next to each other in the list simply click on the first one and keep the mouse button pressed while moving to the last variable. 15-3.5 Definition of Global Residual The residuals are computed by EURANUS as a flux balance (the sum of the fluxes on all the faces of each cell): RES = ∑ fluxes . (15-1) The root mean square of the residuals is computed with the following formula: RES RMS RES = log ⎛ RMS ⎛ -----------------------------⎞ ⎞ , ⎝ ⎝ cellvolume⎠ ⎠ (15-2) and the maximum of the residuals in the same way: RES MAXRES = log MAX ⎛ -----------------------------⎞ , ⎝ cellvolume⎠ FINE™ (15-3) 15-5 Convergence History Computation Steering and Monitoring with log the logarithm to the base ten. On the Computation Steering/Convergence History or Task Manager/Convergence History page, the global root mean square of the residuals normalized by its value at the first iteration is shown. These values are stored in the file with extension .steering.binary. Additionally the global residuals are shown in numerical values in the Task Manager window (3rd column). The RMS value listed in the Task Manager window is the global root mean square normalized by its value at the first iteration: RMSRES-(RMSRES)it=1. The maximum value (4th column) is the maximum residual at a certain iteration normalized by the RMS residual at the first iteration: MAXRES-(RMSRES)it=1. FIGURE 15.3.5-6Task Manager window 15-3.6 The Graphics View (a) (b) FIGURE 15.3.6-7Graphics 15-6 view area in Computation Steering/Convergence History page FINE™ MonitorTurbo Computation Steering and Monitoring The convergence history of the selected curves are displayed inside the graphics view. In the Computation Steering/Convergence History page, the color of the curves is different (up to 8 selected quantities). The automatic chosen curves colors are also used for the displayed value (a). Additionally, the error between the two first selected quantities is also indicated (b). This is especially important for checking the difference between the mass flow at inlet and outlet (Figure 15.3.6-7). In the Task Manager/Convergence History page, the color of the curves is the same (but with different markers) if related to the same computation and is different for each curves if related to different computations (up to 10 selected quantities). FIGURE 15.3.6-8Graphics view area in Task Manager/Convergence History page 15-4 MonitorTurbo 15-4.1 Introduction The MonitorTurbo can be launched independently from FINE™ in order to facilitate the batch mode control. It is a separate graphic control window in which the user can visually monitor: • the convergence history of one or several computations (Convergence history), • the blade loading distribution (Loading diagram available with FINE™/Design 2D only), • the blade profile (Blade profile available with FINE™/Design 2D only). The two last displays are only available under the FINE™/Design 2D environments, as described in Chapter 12 and Chapter 13. This section only describes the functionalities of the convergence history display. FINE™ 15-7 MonitorTurbo Computation Steering and Monitoring On UNIX and LINUX platforms type: monitorTurbo -print
When multiple versions of FINE™ are installed the installation note should be consulted for advice on how to start FINE™ in a multi-version environment. On Windows click on the Monitor icon in Start/Programs/NUMECA software/fine#. Alternatively FINE™ can be launched from a dos shell by typing: \fine#\bin\monitor FINE™ allows multi-process analyses. Therefore, the convergence histories of multiple (running) projects can be visualized at the same time. It is also possible to compare the convergence history associated with different computational parameters for the same project. The monitored variables are displayed as a x-y graph in the upper part of the window (a). The xaxis represents the number of multigrid cycles or work units (see section 15-4.3.3 and Section B4.3) achieved by the flow solver. The y-axis is a logarithmic axis representing the power of ten of the residual values. The user can choose the residual of any of the equations solved and some global parameters using the buttons visible in the lower right part of the graphic control window (b) as shown in Figure 15.4.1-9. The lower part of the graphic control window contains four boxes. The small box (c) located on the left side contains a Print button (which allows to save the current graph as a postscript file) and a Quit button (which allows to close the MonitorTurbo window). The three other boxes are described in the next sections. . (a) (c) (b) FIGURE 15.4.1-9The 15-8 monitorTurbo window FINE™ MonitorTurbo Computation Steering and Monitoring 15-4.2 The Residual File Box Three buttons are provided in this box to Add, Remove or Activate residual files through a file chooser. The residual files describe the iteration process of previous or current computations. They contain the history for internal flow of the axial thrust, mass flow, torque, efficiency, pressure ratio (lift, drag and momentum coefficients if external flow) and the residuals of five (seven or six if respectively the k-ε or the Spalart-Allmaras turbulence model is used) physical variables. The activation of a part of the residual files ’.res’ has the effect of deactivating the other loaded residual files. When a residual file is deactivated, its associated convergence history is not displayed. The selective activation of residual files allows thus to display only the convergence histories of some of the loaded residual files ’.res’. The input boxes File and Block, visible just below the three buttons Add, Remove and Activate, allow to select for which file and block the choice of the monitored variables performed in the Quantities to display menu should be applied. 15-4.3 Quantities to Display 15-4.3.1 Residuals Buttons are provided to select the type of residuals: rms or maximum as shown in Figure 15.4.1-9 on the right. The residuals relative to all transport equations of the problem are available: these are the continuity, the momentum, the energy, and eventually the turbulent kinetic energy k and the turbulent dissipation ε (if the turbulent computation is using a k-epsilon model, e.g. not for Baldwin Lomax), and the turbulent kinematic viscosity nu (if the Spalart-Allmaras model is used) or the blade force for a throughflow application. While the Computation Steering/Convergence history or Task Manager/Convergence History page displays only the global residual, the MonitorTurbo gives the RMS and maximum values per block. Computation of the RMSRES and MAXRES values is done according to Eq. 15-1 to Eq. 15-3. The values shown in the MonitorTurbo for the RMS are normalized by the value of RMSRES at the first iteration: RMSRES-(RMSRES)it=1. The values shown for the maximum residuals are normalized by the maximum residual at the first iteration: MAXRES-(MAXRES)it=1.
Since the RMS and maximum residuals are normalized differently it may occur that the RMS value shown in the MonitorTurbo is higher than the maximum residual. 15-4.3.2 Global Quantities Several buttons are provided to visualize the additional global quantities available under the environment FINE™/Turbo: • Internal flow problems (expert parameter IINT=1): The axial thrust, the (inlet and outlet) mass flows, torque, pressure ratio, and efficiency. • External flow problems (expert parameter IINT=0): The drag, the lift and the momentum coefficients. The user has to specify the axis that has to be taken into account for these global quantities as described in section 11-3. If several computations are performed at the same time, the curves associated with the different projects are drawn in different colors. The buttons of the present box act only on the curves of the file and block selected through the File and Block menu. FINE™ 15-9 Computation Steering and Monitoring Best Practice for Computation Monitoring 15-4.3.3 Display Options The Legend button is used to display which files are currently activated. In addition, if the mass flow button is activated, the relative errors between the inlet and the outlet are indicated. The Work Unit button is provided to set the type of unit used on the horizontal axis in the MonitorTurbo window: multigrid cycles or work units. If Cycles option is chosen (Work Unit button deactivate), the abscissa will show the number of iterations, Work Unit option will adapt the values on the horizontal axis with respect to the grid levels (if 3 grid levels are used, one iteration on 222 and 111 is taking respectively 1/64s and 1/8s considering that one iteration on 000 is taking 1s. The Update now button updates the graph for the active residual file and the selected block. The Auto update button can be switched on to follow the iteration processes automatically. It is however a rather time-consuming option and this button is not active by default. 15-4.3.4 Zooming Option This option allows to interactively zoom in and out: 1. In the drawing window, press the left mouse button to initiate a zooming operation, 2. Then drag the mouse to the left or to the right to zoom in, the zooming window number is displayed on the screen, 3. Click again on the left button when finished, 4. To zoom out, click on the right button of the mouse. 15-5 Best Practice for Computation Monitoring 15-5.1 Introduction Several tools are available in the FINE™/Turbo package to follow the evolution of a calculation: • the Convergence History page available in FINE™/Turbo and in the Task Manager module, which allows to follow the evolution of a calculation easily and to compare globally the evolution of multiple computations. • Another useful tool is the MonitorTurbo to compare per equation the evolution of multiple computations and per block in the domain. • CFView™ to enter even into more detail. Each of them has its own specific features, but they are very complementary. This section describes how to use those tools to monitor a computation. For a detailed description of the use of CFView™ see the separate CFView™ user’s guide. When a computation has just been launched for the first time, and initialization steps have been properly passed, the solver writes a first solution file. In fact it is not yet a solution but only the result of the initialization. Still this first output is interesting to check if all boundaries conditions have been set correctly. Especially think to have a look at the rotating elements of the machine, the profiles of velocities at inlet and at outlet. This operation aims to detect a user mistake, which could cause a loss of time, like for example, a forgotten patch. To check this first output use CFView™. To check the rotating part of the machine, select the rotating walls (hub or shroud for rotating walls) using the menu item Geometry/Select Surfaces and select for the quantity the velocity. Using the 15-10 FINE™ Best Practice for Computation Monitoring Computation Steering and Monitoring Representation menu the velocity will be displayed on the selected patches and this will be the rotation speed everywhere. 15-5.2 Convergence History The global residual on the Convergence History page allows to see quickly whether the computation is iterating properly. The residuals should go down first on the coarser grid levels of the Full Multigrid strategy as shown in Figure 15.5.2-10. See Chapter 9 for more detail on Full Multigrid. When going to a finer grid level the global residual increases suddenly to decrease immediately after. When the computation reaches the finest grid, the curve of the global residual should normally decrease gradually. In general a fall of 3 orders with a stabilization of this curve is considered as a good convergence. But it is important to check if other global quantities like mass flow, efficiency, pressure ratio are also stabilized and to compare the differences between massflow at inlet and outlet (in general a difference of less than 5% is acceptable). FIGURE 15.5.2-10Example of convergence history for global residuals 15-5.3 MonitorTurbo The MonitorTurbo follows the same quantities as the Convergence History, but its main interest is to offer the possibility to follow the convergence block by block. Thus, one can localize problems and, if necessary, modify the mesh in the region associated to the block, or change a boundary condition. Finally, coming back to the Task Manager, it is possible to get a deeper control, locally, by adding control points (local 3d grid point). These points allow to track in important parts of the domain, the speed, the pressure and turbulent quantities, which could be a requested information sometimes. In the case of steady computations, the values associated to these points should converge to a constant value. One additional advice is to use CFView™ during the computation with intermediate and non-converged solutions. When having convergence problems for example CFView™ may be used to look for the zones were the residuals have too high values compared to other regions or an incorrect turbulence field. To know in which block(s) the residuals start to increase first in case of divergence problem, the MonitorTurbo may already give an indication. Combining the information from the FINE™ 15-11 Computation Steering and Monitoring Best Practice for Computation Monitoring MonitorTurbo and CFView™ allows to find the cause of convergence problems in the computations. 15-5.4 Analysis of Residuals In some cases it may occur that the MonitorTurbo shows high RMS and maximum values of the residuals in a certain block while CFView™ shows high residuals in a different block. This difference between the two tools is caused by the different ways of representing the residuals. In CFView™ the absolute values of the residuals resulting from the flux balance are directly plotted for each cell. In CFView™ the residuals are not scaled with the cell volumes and no normalization with values at the first iteration is applied. This explains why some high maximum residuals in scaled mode can be invisible in CFView™ because they occur in small cells. Also the fact that the residuals are computed on the cell centers in the solver and shown in CFView™ on the cell corners may lead to some, minor, interpolation differences. 15-12 FINE™ APPENDIX A:Governing Equations A-1 Overview The flow solver integrated into the FINE™ user environment is named EURANUS ("EURopean Aerodynamic NUmerical Simulator"). EURANUS is a multipurpose code for 2D and 3D flows in complex geometries, using the latest numerical developments in CFD. A structured mesh is required and complex geometries can be easily handled through a flexible multiblock meshing procedure. This appendix describes the basic governing equations solved in EURANUS. For more detailed information on the different aspects like turbulence, fluid modeling, multi grid strategy etc., see the related chapters in this manual. A-2 Reynolds-Averaged Navier-Stokes Equations A-2.1 General Navier-Stokes Equations The general Navier-Stokes equations written in a Cartesian frame can be expressed as: ∂ U + ∇F I + ∇F V = Q , ∂t (A-1) where U is the vector of the conservative variables: ρ U = ρv , ρE (A-2) F I and F V are respectively the inviscid and viscous flux vectors: FINE™ A-1 Reynolds-Averaged Navier-Stokes Equations Governing Equations ρv i ρv 1 v i + pδ 1i F li = ρv 2 v i + pδ 2i and – F vi = 0 τ i1 τ i2 ρv 3 v i + pδ 3i τ i2 ( ρE + p )v i q i + v j τ ij , (A-3) where the stress and the heat flux components are given by: ∂w˜ ∂w˜ τ ij = ( µ + µ t ) --------i + --------j – 2 --- ( ∇w )δ ij ∂x j ∂x i 3 and q i = ( κ + κ t ) (A-4) ∂ ˜ T. ∂xi (A-5) Q contains the source terms: 0 Q = ρf e , Wf (A-6) with f e expressing the effects of external forces and W f the work performed by those external forces: W f = ρf e ⋅ v . Other source terms are possible, like gravity, depending on the chosen functionalities. A-2.2 Time Averaging of Quantities The Navier-Stokes equations are averaged in time. The density and the pressure are time averaged related to the instantenous value through: q = q + q' (A-7) where where q is the time averaged value and q' the fluctuating part and q' = 0 (A-8) The energy, velocity components and temperature are density weighted averages defined as: ρq q˜ = -----ρ (A-9) A-2.3 Treatment of Turbulence in the Equations Except for the non-linear k-ε turbulence model, a first-order closure model based on Boussinesq's assumption, is used: – ρw i ″w j ″ = µ t A-2 ∂w˜ i ∂w˜ j 2 2 + – --- ( ∇w˜ )δ ij – --- ρkδ ij ∂ xj ∂ x i 3 3 (A-10) FINE™ Formulation in Rotating Frame for the Absolute Velocity Governing Equations with w i the xi component of the relative velocity. In this equation k is the turbulent kinetic energy and is defined as: 1 k = --- ρw i ″w i ″ ⁄ ρ . 2 (A-11) In contrast to the laminar case, both the static pressure and the total energy contain contributions from the turbulent kinetic energy k and are defined as: 2 p* = p + --- ρk , 3 (A-12) 1 ˜ E˜ = e˜ + --- w˜ i w i+k 2 (A-13) Note that Eq. A-13 does not contain a term in the angular velocity. This term is accounted for in the source term, and assuming stationary flow, corresponds to the last term of Eq. A-15. A-2.4 Formulation in Rotating Frame for the Relative Velocity The resulting time averaged Navier-Stokes equations for the relative velocities in the rotating frame of reference become: ρw˜ i ρ ρw˜ 1 p*δ 1i + ρw˜ i w˜ 1 U = ρw˜ 2 F Ii = p*δ 2i + ρw˜ i w˜ 2 ρw˜ 3 p*δ 3i + ρw˜ i w˜ 3 ρE˜ ( ρE˜ + p* )w˜ i 0 τ i1 – F vi = τ i2 (A-14) τ i3 q i + w˜ j τ ij where the shorthand notation , i, in the Fvi expression, is used to denote derivatives with respect to x i . The source term vector Q contains contributions of Coriolis and centrifugal forces and is given by: 0 Q = ( – ρ ) [ 2ω × w + ( ω × ( ω × r ) ) ] (A-15) 2 2 ρw∇ ( 0.5ω r ) with ω the angular velocity of the relative frame of reference. A-3 Formulation in Rotating Frame for the Absolute Velocity Although the governing equations for rotating systems are usually formulated in the relative system and solved for the relative velocity components, the formulation retained for ship propeller applications or ventilators are often expressed in the relative frame of reference for the absolute velocity FINE™ A-3 Formulation in Rotating Frame for the Absolute Velocity Governing Equations components. This formulation is different from the one generally used to solve internal turbomachinery problems, where the equations are solved for the relative velocity. The two formulations should lead to the same flow solution. However, experience shows that the solution can be different, especially in the far field region. For propeller problems, the formulation based on relative velocities has the disadvantage that the far field relative velocity can reach high values. This induces an excess of artificial dissipation leading to a non physical rotational flow in the far field region, this dissipation being based on the computed variables.

This formulation is controlled by the expert parameter IVELSY=0. This formulation is valid only if all boundary conditions are uniform in the azimuthal direction. If the flow field boundary conditions are not uniform in the azimuthal direction, the boundary conditions expressed in this formulation must be unsteady. In this case, the formulation for the relative velocity is suggested. Except for the non-linear k-ε turbulence model, first-order closure, based on Boussinesq's assumption, is used for the Reynolds stress: – ρv i ″v j ″ = µ t ∂v˜ i ∂v˜ j 2 2 + – --- ( ∇v˜ )δ ij – --- ρkδ ij 3 ∂ xi ∂ xi 3 (A-16) with v i the xi component of the absolute velocity. The flux vectors are decomposed into Cartesian components: F I = f I1 1 x + f I2 1 y + f I3 1 z (A-17) F v = f v1 1 x + f v2 1 y + f v3 1 z and ρw˜ i ρ ρv˜ 1 p*δ 1i + ρw˜ i v˜ 1 U = ρv˜ 2 F Ii = p*δ 2i + ρw˜ i v˜ 2 ρv˜ 3 p*δ 3i + ρw˜ i v˜ 3 ρE˜ ρE˜ w˜ i + p*v˜ i 0 τ i1 – F vi = τ i2 (A-18) τ i3 q i + v˜ j τ ij where the shorthand notation , i, in the Fvi expression, is used to denote derivatives with respect to x i . The velocity w i is the xi component of the relative velocity. This formulation envolves thus both the absolute and the relative velocity components. The source term vector Q is given by: 0 Q = –ρ( ω × v ) , (A-19) 0 with ω the angular velocity of the relative frame of reference. Other source terms are possible, like gravity, depending on the chosen functionalities. A-4 FINE™ Formulation in Rotating Frame for the Absolute Velocity Governing Equations The averaged Navier-Stokes equations are obtained by the Favre averaging as described in section A-2.2. In contrast to the laminar case, both the static pressure and the total energy contain contributions from the turbulent kinetic energy k and are defined as: 2 p* = p + --- ρk , 3 (A-20) 1 E˜ = e˜ + --- w˜ i w˜ i + k . 2 (A-21) The stress and the heat flux components are given by: ∂v˜ ∂v˜ τ ij = ( µ + µ t ) -------i + -------j – 2 --- ( ∇v )δ ij ∂x j ∂x i 3 and q i = ( κ + κ t ) FINE™ ∂ ˜ T, ∂ xi (A-22) (A-23) A-5 Governing Equations A-6 Formulation in Rotating Frame for the Absolute Velocity FINE™ APPENDIX B:File Formats B-1 Overview This Appendix describes the files used by FINE™ and the flow solver EURANUS. It is divided in two parts. The first one gives the file format information needed to use FINE™, while the second one describes the format of the files used and produced by EURANUS. As FINE™ is intended to handle the file treatment for the user, knowing the exact format of all the files used in a simulation process is not required. This Appendix is therefore written for advanced users. In the following description, it is assumed that all the files are related to a generic project called 'project'. The chapter is divided in five sections: • files produced by IGG™, • files produced and used by FINE™, • files produced and used by the flow solver EURANUS, • files used as data profile, • resource files used to control the layout and which contain default values and reference information. To simplify the notations, it is assumed that the related mesh has a topology of one block. B-2 Files Produced by IGG™ This section describes the files produced by the grid generator IGG™ and used by FINE™: • the identification file project.igg, • the binary file project.cgns, • the boundary conditions file project.bcs, • the geometry file project.geom. FINE™ B-1 Files Produced by FINE™ File Formats B-2.1 The Identification File: project.igg This file contains all the mesh geometric and topologic information. It is used by FINE™ to identify the mesh topology. A complete description of this file is given in the IGG™ User’s Guide. B-2.2 The Binary File: project.cgns When the mesh is created and saved in IGG™, the binary file project.cgns containing the grid point coordinates is created. Later on, the solver will store the wall distances used for the different turbulence models in the same file. B-2.3 The Geometry File: project.geom When the mesh is created and saved in IGG™, the geometry file project.geom containing the whole geometry (curves, surfaces and cartesian points) is created. B-2.4 The Boundary Condition File: project.bcs As described in Chapter 8, the settings of the boundary condition type have to be set inside IGG™ while the physical boundary condition parameters are set in FINE™. The settings of IGG™ are stored in the file project.bcs. This files is used by FINE™ to initialize the boundary condition types for each patch. They are updated each time the boundary condition type is changed inside IGG™. B-3 Files Produced by FINE™ This section describes the files produced and used by FINE™ (or used by the flow solver EURANUS launched from FINE™). Please note that FINE™ acts as a file manager between different software systems. Therefore, it is important that the read, write and execute permissions are set properly for all the files and directories used by FINE™.
B-3.1 Manual modification of these files is not supported since it may corrupt the file or provide incorrect results. Such a modification should only be done on explicit advice of NUMECA support team ([email protected]). The Project File: project.iec This file contains all the information related to the project. It is used by FINE™ to save and recover all the user settings. This file is subdivided into several blocks. Each block contains data and/or other blocks. The beginning of the blocks is identified by the key word NI_BEGIN and by a name and the end of the block is identified by the key word NI_END and by the name of the block. a) File Header The file always has the following header containing the version number and the project type: NUMECA_PROJECT_FILE VERSION 5.0 PROJECT_TYPE STRUCTURED After the header, 3 new lines are used to store the name of the files linked to the project: B-2 FINE™ Files Produced by the Flow Solver EURANUS File Formats GRID_FILE /usr/_turnkey_tutorials/_rotor37/rotor37/_mesh/rotor37.igg TRB_FILE /usr/_turnkey_tutorials/_rotor37/rotor37/rotor37.trb GEOMETRY_FILE /usr/_turnkey_tutorials/_rotor37/rotor37.geomTurbo These are respectively the mesh, the template and the geometry files. The template and the geometry files are not used by FINE™/Turbo and are only there for backward compatibility reasons. b) The Computation Block The project file contains the settings of all the computations defined by the user. Each computation block is identified by the following keywords: NI_BEGIN computation ... NI_END computation The computation block contains the following subblocks: • The Solver Parameters Section block containing all the parameters of the solver EURANUS. • The Initial Solution & Boundary Condition Section block containing the initial solution and the boundary conditions. • The Blade-to-Blade Parameters Section block containing all the parameters of the blade-toblade module. • The Grid Parameters Section block containing the topology of the mesh. • The Fluid Properties Section block containing the fluid properties. B-3.2 The Computation File: project_computationName.run When the solver is started, FINE™ creates a new directory using the name of the active computation. A subproject file (’.run’ extension) containing the settings of the active computation is saved into this new directory. This file is used as input by the flow solver EURANUS and by the flow visualization system CFView™.
B-4 The menu File/Save Run Files enables to save the ’.run’ file without starting the solver EURANUS. Files Produced by the Flow Solver EURANUS This section describes the files produced and used by the flow solver EURANUS. The flow solver uses most of the files described above and produces the following files: B-4.1 The cgns file: project_computationName.cgns This binary file contains the flow solution. It is used to restart the solver and also by CFView™ to visualize the flow field. The data structure is the following: 1. For block i= 1 to n: The primitive flow variables: density, velocity components, pressure. These are computed at cell centers and are used for restart. Depending on the type of computation, temperature or turbulent quantities such as k, ε or µt are also stored. FINE™ B-3 Files Produced by the Flow Solver EURANUS File Formats 2. For block i= 1 to n: The grid point coordinates and the 3D output flow variables as selected by the user through FINE™ (see Chapter 11). This data will be read by CFView™. Flow quantities are interpolated at mesh nodes by the flow solver as required by CFView™ (see section 11-4 for mathematical details). If the user selected solid data output, azimuthal averaged output or surface averaged output (see Chapter 11), the corresponding mesh coordinates and computed quantities are added to the corresponding ’.cgns’ file. B-4.2 The mf file: project_computationName.mf This ASCII file contains averaged quantities over the inlet, outlet and rotor-stator sections. It is generated only if both inlet and outlet boundary conditions are present. B-4.3 The res file: project_computationName.res This file contains the residual values for all blocks for each iteration of a computation as described in section 15-4.3.1. It is continuously updated during the computation. It is used by the MonitorTurbo to visualize the convergence history. The format of this file is the following: • line 1: Version line. • line 2: Number of blocks. • line 3: 3D or 2D. • line 4: NO-K-EPS or K-EPS or SPL-ALM. • line 5: Number of chemistry species (not used, for backward compatibility only). • line 6: STEADY or UNSTEADY. • line 7: TURBO (not used, for backward compatibility reasons only). • For iteration i=1 to itmax Iteration number, Total iteration number (for unsteady computations only), Work unit, CPU time, Physical time (for unsteady computations only), Lift, Drag, Torque, Qmax, Tmax, Mass flow in and out. For block j = 1 to n: RMS residual for the density ρ, the 3 momentum components (ρvx, ρvy, ρvz), the energy e, the turbulent variables k, ε and υ, and the same data for the maximum residual. Where: Iteration number = the number of iterations. For unsteady computations it includes the number of iterations performed in stationary mode to initialize the unsteady computation. Total iteration number = the total number of iterations including the dual-time step sub-iterations and the initial stationary iterations. Work unit: for single grid computations, one work unit is equal to one iteration, while in multigrid, the work unit corresponds to the computing effort of the multigrid run to the single grid run. For 3D cases it is computed as follow: WU = 1 + n2(1/2)3 + n3(1/2)6 +... While for 2D: WU = 1 + n2(1/2)2 + n3(1/2)4 +... where nx is the number of iteration done on the xth multigrid level B-4 FINE™ Files Produced by the Flow Solver EURANUS File Formats Σ R es --------------------- (see section 15-4.3). 2 RMS is the root mean square of the residual, defined by n Physical time = the physical time step. Lift, Drag and Torque are scalar values corresponding respectively to the projection of the force vector along a lift direction (IDCLP), a drag direction (IDCDP) and a torque direction (IDCMP). These directions are controlled by the real expert parameters "IDCLP", "IDCDP", "IDCMP" in FINE™ (on the Computation Steering/Control Variables page in expert mode) as described in section 11-2.5.1 and section 11-3.2. For internal flows (expert parameter IINT=1): • Qmax = efficiency between inlet and outlet, • Tmax = total pressure ratio between inlet and outlet. For external flows (expert parameter IINT=0): • Qmax = maximum heat flux on surface = k*Grad T*n, • Tmax = maximum static temperature. Mass flow in/out = total mass flow for both inlet and outlet boundaries. When no inlet or outlet is present in the computation, the corresponding mass flow is set to zero. Finally, the ".res" file is given with the CPU time included. In case of parallel computations the wall clock time will be given instead of the CPU time. B-4.4 The log file: project_computationName.log This ASCII file contains all the information related to the current computation. It contains a summary of the computation variable as well as warnings and error messages. If the flow solver encounters a problem, the latter is described in the ’.log’ file. This file is for support purposes only. When a problem appears please send this file together with a detailed problem description to NUMECA support team at [email protected]. B-4.5 The std file: project_computationName.std This ASCII file contains all the information related to the current computation. It contains the whole content of the Task Manager window as well as warnings and error messages. If the flow solver encounters a problem, the latter is described in the ’.std’ file. This file is for support purposes only. When a problem appears please send this file together with a detailed problem description to NUMECA support team at [email protected]. B-4.6 The wall file: project_computationName.wall This self-explained ASCII file gives information about forces and torques on the patches for which the Compute force and torque button is activated on the Boundary Conditions page in the Solid thumbnail (see section 8-2.4). FINE™ B-5 Files Produced by the Flow Solver EURANUS File Formats B-4.7 The aqsi file: project_computationName.aqsi This ASCII temporary file is created and read by the code to ensure a smooth restart in the presence of quasi-steady rotor-stator interfaces. B-4.8 The Plot3D files The Plot3D output module of EURANUS creates 4 files. • The project_computationName.g file contains the grid data. • The project_computationName.q file contains the conservative variables. • The project_computationName.f file contains additional variables. • The project_computationName.name file contains the names of the additional variables. The first 3 files can be written in ASCII or binary format, the binary format being the Fortran unformatted format. The .name file is always written in ASCII.
When the "Unformatted file (binary)" FORTRAN format is selected in FINE™: the user has to make sure that the file format is also correctly defined in CFView™. When opening the Plot3D project in CFView™ through the menu File/Open Plot3D Project... , click on the File Format... button and select Unformatted. Do not select Binary as it corresponds to binary files generated by C programs. Once this is done, the user also needs to check the "binary low endian" or "binary big endian" format on the same page. On PC platforms (Windows or LINUX) make sure to use "binary low endian" format whereas "binary big endian" is mandatory on all other platforms. 1. The project_computationName.g file format: • Line1: number of blocks, • Line2: the 3 dimensions of each block, • for each block, the coordinates of the mesh points. 2. The project_computationName.q file format: • Line1: number of blocks, • Line2: the 3 dimensions of each block, • for each block: the free stream mach number, the flow angle, the Reynolds number and the time, the 5 conservative unknowns: density, the 3 momentum components and energy. 3. The project_computationName.f file format: • Line1: number of blocks, • Line2: for each block, the 3 dimensions and the number of additional variables selected by the user, • for each block: the additional flow variables. 4. The project_computationName.name file format: This file contains the names of the additional variables stored in the ’.f’ file, one name per line. If the quantity is a vector, it will be written on 3 different lines like in the following example: B-6 FINE™ Files Used as Data Profile File Formats Velocity-X Velocity-Y Velocity-Z B-4.9 The me.cfv file: project_computationName.me.cfv This ASCII file contains data required for the visualization of the meridional averaged output under CFView™. It is created whenever the user specifies variables in the Outputs/Azimuthal Averaged Variables page of the FINE™ interface. B-5 Files Used as Data Profile This section describes the files created by the user and used as input data for the boundary conditions and for the fluid model. Once these files are read by the interface, they are imported in the ’.iec’ file described in section B-3. The flow solver does not read these files, it retrieves the profiles from the computation definition file with extension ’.run’. Profiles may also be specified by entering the coordinates directly into the profile viewer, as described in section 2-12.
The imported values will be interpreted in the current project units. These values would change (in the database) if the user changes the corresponding units. Therefore all values will be converted for the flow solver EURANUS in SI system units (in radians for the angles). The values for 1D profiles should be given in increasing order of the x-coordinate. For example, when entering a profile of temperature as a function of R, FINE™ checks whether the two first points are in increasing order. If this is not the case, the profile will be inverted automatically in order to ensure compatibility with the flow solver. The next time the Profile Manager ( opened, the profile will be shown in increasing order, contrary to what was initially entered. ) is For 2D profiles there is no such constraint except for profiles as a function of r-θ (see section 42.3.2). B-5.1 Boundary Conditions Data When defining the inlet (or outlet) boundary condition parameters, the user has the option of specifying one or several input files containing each a data profile. These profiles are used to compute by interpolation the corresponding physical variables at the inlet (or outlet). The file containing the profile must be created by the user and its name must possess the ’.p’ extension. The values of the physical variable stored in this file can come from any source: experiments, previous computations, etc. The format used to create this file contains: • Line 1: • Line 2: Two strings defining the name of the coordinate axes. Type of interpolation and number of points of the profile curve. The types are: 0 for data given at each cell centre 1,2,3,4 and 5 for 1D interpolation respectively along x, y, z, r and θ. 51 for 2D interpolation along x and y. 52 for 2D interpolation along x and z. FINE™ B-7 Files Used as Data Profile File Formats 53 for 2D interpolation along y and z. 54 for 2D interpolation along r and θ. 55 for 2D interpolation along r and z. 56 for 2D interpolation along θ and z.
The theta angle is defined as θ = arctg (y/x). The θ profile should cover the patch geometry, so it may take negative values. For unsteady calculations with profile rotation the θ profile must be given form 0 to 2π (see section 4-2.3.2).
For time dependant profiles the interpolation type is 100. • The next lines contain the coordinate(s) of each point with the associated physical value. Example 1: r pressure 45 0.5 101000 0.6 102000 0.6 103000 0.7 102000 0.8 101000 This example is related to the interpolation of the pressure along the radius. There are 5 point coordinates in the file. This is a space profile. FINE™ uses the same file formats to import space, time, and space and time profiles. Thus if there is only one profile in the file, it will be interpreted as a space profile, if a second profile exists, FINE™ will recognize it as a time profile. Following is an example of a space and time profile: Example 2: R Pt 46 .3 95600.13 .251765 98913.46 .248412 100909.6 .24445 101527.6 .240182 101740.4 .23622 101811.4 100 10 .216713 101811.4 .210922 101872.1 .205435 101872.1 .199644 101872.1 .195682 101872.1 .191414 101872.1 .187452 101872.1 .18349 101740.4 .179222 99946.98 .1 99946.98 B-8 FINE™ Files Used as Data Profile File Formats The two profiles are separated by an empty line. The interpolation type in time is specified as 100. If this file is imported with the profile viewer invoked as "fct(space)"- only the first part will be taken into account. If "fct(time)" is specified - only the second part will be read by the flow solver. Both profiles will be imported if "fct(space-time)" is specified for the variable type. If there are less coordinates supplied than the number of points specified, FINE™ will put zero for the missing coordinates. B-5.2 Fluid Properties Fluid properties like Cp or Gamma or the viscosity can be input in the solver as constant but can also be input as variables in function of the temperature. The format used is the following: • Line 1: Two strings: "T" and the name of quantity considered ("P" and "Density" for barotropic law). • Line 2: Contains two integers: — the first number is the type of interpolation: 11 for Temperature and 12 for Pressure (barotropic profiles only), — the second one defines the number of points on the profile curve. • The next lines list the data of each point: temperature and the fluid property. Example 1: T Mu 11 5 270 6e-5 275 3e-5 280 2e-5 290 1.5e-5 300 0.9e-5
It is recommended to cover the whole temperature range of the problem. The format for the Cp and Gamma profiles is slightly different because the two profiles are specified in the same file (with extension .heat_capacity). It is as shown in the example below: Example 2: T Cp 11 4 295 1004.9 298 1005.3 301 1010.8 318 1011.0 11 3 296 1.31 298 1.34 303 1.36 FINE™ B-9 Resource Files File Formats The first set of points is for the Cp profile, the second is for the Gamma profile as functions of the temperature. B-6 Resource Files All the resource files are located in the same directory, which is ~/COMMON under UNIX and ~\bin under Windows. It is not possible to start FINE™ if any of these files is missing. B-6.1 Boundary Conditions Resource File euranus_bc.def This file contains the default values for all parameters of the available boundary conditions. The same file is also used to create the graphical layout of the page Boundary Conditions in FINE™. FINE™ only reads from this file so this file is not modified while using FINE™. B-6.2 Fluids Database File euranus.flb This file contains all the data relative to the fluids created by the users in the page Configuration/ Fluid Model. This file is overwritten each time a user quits FINE™ after modifying the fluids database (add, remove, or modify a fluid). All the users should have read and write permissions for this file. It is not recommended to modify this file manually. B-6.3 Units Systems Resource File euranus.uni This file contains the conversion factors for all physical quantities used in FINE™ for all possible combinations between existing systems of units. To add a new units system the user should add the corresponding conversion factors following the existing format shown in the extract below: ... # new units can be added by respecting the format # for UNITS NAMES AND CONVERSION FACTORS # NOTE: VALUE_UNITS_NAME value should NOT begin with capital letter ! # ----------------------------------------------------------------------# ----------------------------------------------------------------------# these are the names of the systems # used to change all the quantities at the same time DEFAULT_SYSTEM SI DEFAULT_SYSTEM Default DEFAULT_SYSTEM American 1 DEFAULT_SYSTEM American 2 # ----------------------------------------------------------------------# ----------------------------------------------------------------------- B-10 FINE™ Resource Files File Formats # this is the system that will be taken as default # when creating a new project NEW_PROJECT_DEFAULT_SYSTEM Default # ----------------------------------------------------------------------- # --------------------- UNITS NAMES AND CONVERSION FACTORS --------------NI_BEGIN UNITS_RECORD NUMBER_OF_SYSTEMS 4 VALUE_UNITS_NAME length UNITS_NAME 1 [m] CONV_FACTOR 1 2 1. CONV_FACTOR 1 3 3.280839895 CONV_FACTOR 1 4 39.37007874 UNITS_NAME 2 [m] CONV_FACTOR 2 1 1. CONV_FACTOR 2 3 3.280839895 CONV_FACTOR 2 4 39.37007874 UNITS_NAME 3 [ft] CONV_FACTOR 3 1 0.3048 CONV_FACTOR 3 2 0.3048 CONV_FACTOR 3 4 12. UNITS_NAME 4 [in] CONV_FACTOR 4 1 0.0254 CONV_FACTOR 4 2 0.0254 CONV_FACTOR 4 3 0.08333333333 NI_END UNITS_RECORD NI_BEGIN UNITS_RECORD NUMBER_OF_SYSTEMS 4 VALUE_UNITS_NAME mass UNITS_NAME 1 [kg] CONV_FACTOR 1 2 1. CONV_FACTOR 1 3 0.06852176586 CONV_FACTOR 1 4 0.005710147155 UNITS_NAME 2 [kg] CONV_FACTOR 2 1 1. CONV_FACTOR 2 3 0.06852176586 CONV_FACTOR 2 4 0.005710147155 UNITS_NAME 3 [lbf s2/ft] FINE™ B-11 File Formats Resource Files CONV_FACTOR 3 1 14.59390294 CONV_FACTOR 3 2 14.59390294 CONV_FACTOR 3 4 0.08333333333 UNITS_NAME 4 [lbf s2/in] CONV_FACTOR 4 1 175.1268352 CONV_FACTOR 4 2 175.1268352 CONV_FACTOR 4 3 12. NI_END UNITS_RECORD ...... If, for example, a new system is added on the fifth position, the user should supply the factors to convert the physical quantities from all the existing systems (1, 2, 3, and 4) to the fifth, and back from the fifth to all the others as shown below: NI_BEGIN UNITS_RECORD NUMBER_OF_SYSTEMS 5 VALUE_UNITS_NAME length UNITS_NAME 1 [m] CONV_FACTOR 1 2 1. CONV_FACTOR 1 3 3.280839895 CONV_FACTOR 1 4 39.37007874 CONV_FACTOR 1 5 new_factor_value_from_1_to_5 UNITS_NAME 2 [m] CONV_FACTOR 2 1 1. CONV_FACTOR 2 3 3.280839895 CONV_FACTOR 2 4 39.37007874 CONV_FACTOR 2 5 new_factor_value_from_2_to_5 UNITS_NAME 3 [ft] CONV_FACTOR 3 1 0.3048 CONV_FACTOR 3 2 0.3048 CONV_FACTOR 3 4 12. CONV_FACTOR 3 5 new_factor_value_from_3_to_5 UNITS_NAME 4 [in] CONV_FACTOR 4 1 0.0254 CONV_FACTOR 4 2 0.0254 CONV_FACTOR 4 3 0.08333333333 CONV_FACTOR 4 5 new_factor_value_from_4_to_5 UNITS_NAME 5 [new_units_name] CONV_FACTOR 5 1 new_factor_value_from_5_to_1 CONV_FACTOR 5 2 new_factor_value_from_5_to_2 CONV_FACTOR 5 3 new_factor_value_from_5_to_3 CONV_FACTOR 5 4 new_factor_value_from_5_to_4 NI_END UNITS_RECORD B-12 FINE™ Resource Files File Formats The default units sytem can be changed by modifying the line NEW_PROJECT_DEFAULT_SYSTEM Default with the name of the desired system.
FINE™ The first (SI) and the second (default) systems are identical except for the rotational speed units (RPM vs. radian). B-13 File Formats B-14 Resource Files FINE™ APPENDIX C:List of Expert Parameters C-1 Overview On the Control Variables page under Expert Mode a list of non-interfaced expert parameters is available. As stated in the interface these parameters should not be used unless explicitly stated in this manual. This chapter contains a list of all non-interfaced expert parameters that are described in this manual. For each parameter a reference is given to the corresponding section. If more information is desired on another parameters please contact NUMECA support at [email protected]. C-2 List of Integer Expert Parameters CLASID: COOLFL: EFFDEF: I2DLAG: IADAPT: IATFRZ: IBOTH: IBOUND: ICODKE: ICOPKE: ICYOUT: IFACE: IFNMB: IFNMFI: IFRCTO: IHXINL: IINT: IKELED: IKENC: IMASFL: IMTFIL: INEWKE: FINE™ class of particles for CFView™ output select cooling/bleed through external file and version efficiency definition simplification of Lagrangian module parametrised target distribution mutligrid parameter for Baldwin Lomax time discretization reflection treatment of particles on solid wall activation of compressible dissipation pressure gradient velocity model solution overwritten every NOFROT timesteps spatial discretization transform PERNM boundaries in FNMB reading full non-matching data from file activate partial torque output inlet boundary condition for condensable fluid internal or external flow activation of LED scalar scheme for k-ε non-conservative approach for k-ε mass flow extrapolation at inlet instead of velocity initial solution for k-ε definition of high Reynolds k-ε model section 7-2.5 section 7-4.3 section 11-3.2 section 7-2.5 section 13-2.5 section 4-3.4 section 9-3.2 section 7.2-2 section 4-3.4 section 4-3.4 section 4-2.2 section 9-3.2 section 4-2.2 section 5-4.3.4 section 8-2.4.3 section 3-2.9 section 11-3.2 section 4-3.4 section 4-3.4 section 8-3.2 section 10-4.3 section 4-3.4 C-1 List of Expert Parameters INIKE: INVMOD: INVSPL: IOPTKE: IPROLO: IRESTR: IRGCON: IROEAV: IRSMCH: IRSNEW: IRSVFL: ISIDAT: ITFRZ: ITHVZM: ITRWKI: ITYSTO: IUPWTE: IVELSY: IWAVVI: IWRIT: IYAP: KEGRID: KOUTPT: LIPROD: LMAX: MAXNBS: MGRSTR: MGSIMP: MXBFSZ: NIBOUND: NCLASS: NPERBC: NQSTDY: NREPET: NSUBM: NTUPTC: OUTTYP: THINI: VISNUL: ZMNMX: List of Float Expert Parameters initial solution for k-ε restart of inverse design inverse design of splitter blades optimized implementation for k-ε multigrid prolongation order multigrid restriction order real gas modelling upwind discretization residual smoothing rotor-stator interaction viscous fluxes treatment at R/S interface rotor-stator connectivity structure freezing of turbulent viscosity definition of flow angle in throughflow wake induced transition through AGS model storage of the energy upwind discretization for turbulence equations relative frame of reference spatial discretization writing of global performance data Yap’s modification for turbulent length scale switch from Baldwin-Lomax to k-epsilon model particles trajectories output linear production term maximum number of segments in Lagrangian module maximum number of injection sectors multigrid strategy multigrid strategy maximum buffer size reflection treatment of particles on solid wall maximum nuber of classes inlet/outlet signal periodicity update rotor-stator boundary condition calculation of the wall distance number of subdomains in calculation of wall distance number of patches in calculation of wall distance select type of output throughflow under-relaxation central discretization indication of injector positions in cooling/bleed section 10-4.3 section 13-2.5 section 13-2.5 section 4-3.4 section 9-3.2 section 9-3.2 section 3-2.9 section 9-3.2 section 9-3.2 section 5-4 section 5-5.4 section 5-4 section 4-3.4 section 6-4 section 7-5.3 section 3-2.9 section 4.3.4 section A-3 section 9-3.2 section 11-3.2 section 4-3.4 section 4.3.4 section 7-2.5 section 4-3.5 section 7-2.5 section 7.4-3 section 9-3.2 section 9-3.2 section 14-4.4 section 7-2.5 section 7-2.5 section 4.2-2 section 5-4 section 4-3.4 section 4-3.4 section 4-3.4 section 11-3.2 section 6-4 section 9-3.2 section 7-4.3 C-3 List of Float Expert Parameters ALF: ALPHAP: ANGREL: C3: CDIDTE: CE1: CE2: C-2 constant for compressible dissipation preconditioning parameter relative angles for the inlet boundary conditions constant for k-ε model central discretization constant for k-ε model constant for k-ε model section 4-3.4 section 4-3.8 section 8-3 section 4-3.4 section 9-3.2 section 4-3.4 section 4-3.4 FINE™ List of Float Expert Parameters CMU: COOLRT: CP1: CREF: DDIMAX: DIAMR: EKCLIP: ENTRFX: EPCLIP: EXPMAR: FTRAST: GAMMAT: IDCDP: IDCLP: IDCMP: IRKCO: ISWV: IXMP: LTMAX: MAVREM: MAVRES: MUCLIP: NUTFRE: PRCLIP: PRT: RADAPT: RELAXP: RELPHL: RESFRZ: RGCST: RSMPAR: RTOL: SIGE: SIGK: SIGRO: SMCOR: SREF: TEDAMP: THFREL: VELSCA: VIS2: VIS2KE: VIS4: VIS4KE: FINE™ List of Expert Parameters constant for k-ε model section 4-3.4 reduction of mass flow in cooling holes section 7-4.3 constant for compressible dissipation section 4-3.4 reference chord for non-dimensionalizing section 11-3 tolerance factor for Lagrangian module section 7-2.5 diameter ratio for Lagrangian module section 7-2.5 clipping value for turbulent kinetic energy section 4-3.4 upwind discretization section 9-3.2 clipping value for turbulent kinetic dissipation section 4-3.4 central discretization section 9-3.2 forbid transition before FTRAST*chord with AGS model section 7-5.3 turbulence time scale section 4-3.4 direction of drag or axial thrust section 11-3.2 direction of lift section 11-3.2 direction of moment or torque section 11-3.2 Runge-Kutta coefficients section 9-3.2 Runge-Kutta dissipative residuals section 9-3.2 definition of point for moment or torque section 11-3.2 maximum turbulent length scale section 4-3.4 control of multigrid correction for k and ε section 4-3.4 update control of k and ε section 4-3.4 clipping value for Mut/Mu for k and ε and Spalart-Allmaras section 4-3.4 initial value of turbulent viscosity for Spalart Allmaras section 4-3.3 turbulence parameter section 4-3.4 turbulent Prandtl number section 4-3.4 parametrised target distribution section 13-2.5 under-relaxation for mass flow imposed at outlet section 8-3 relaxation factor for Phase-Lagged section 4.2.2 freeze turbulent viscosity field section 4-3.4 value of the gas constant section 3-2.9 residual smoothing parameter section 9-3.2 maximum angle for normals in calculation wall distance section 4-3.4 constant for k-ε model section 4-3.4 constant for k-ε model section 4-3.4 constant for k-ε model section 4-3.4 residual smoothing section 9-3.2 reference surface to non-dimensionalize coefficients section 11-3 damping for k-e model section 4-3.4 throughflow under-relaxation section 6-4 maximum value allowed for velocity scaling section 8-3 central discretization section 9-3.2 central discretization section 9-3.2 central discretization section 9-3.2 central discretization section 9-3.2 C-3 List of Expert Parameters C-4 List of Float Expert Parameters FINE™ Characteristics of Water (steam) Tables APPENDIX D: D-1 Overview As described in section section 3-2.3.4, the Condensable Fluid module aims at the modelling of the real thermodynamic properties of a given fluid by means of interpolation of the variables from dedicated tables. The approach that has been adopted in EURANUS consists of using a series of thermodynamic tables, one table being required each time a thermodynamic variable must be deduced from two other ones. This implies the creation of many tables as input, but presents the advantage that no iterative inversion of the tables is done in the solver, with as a consequence a very small additional CPU time. Information related to • the range of variation of admissible values for thermodynamic variables • the discretization of the grid • the nature of the interpolation algorithm selected • the relative mean error (mean and maximum) on thermodynamic variables • the size of the table is discussed here below for water (steam) tables. D-2 Main Characteristics Water (steam) tables come in the form of 11 tables, described as follows: TER: PER: RPT: EPT: SHP: PHS: FINE™ interpolates static temperature as a function of internal energy and density interpolates static pressure as a function of internal energy and density interpolates density as a function of static pressure and temperature interpolates internal energy as a function of pressure and static temperature interpolates entropy as a function of total enthalpy and static pressure interpolates static pressure as a function of entropy and total enthalpy D-1 Main Characteristics Characteristics of Water (steam) Tables RHS: HSP: MER: KER: PSA: interpolates static pressure over density as a function of entropy and total enthalpy interpolates total enthalpy as a function of entropy and static pressure interpolates dynamic viscosity as a function of internal energy and density interpolates thermal conductivity as a function of internal energy and density defines the saturation line Tables Variables Minimum Maximum TER / PER Energy [J/kg] 500,000 4,000,000 Density [kg/m3] 0.001 1,020 Pressure [bars] 0.0003 26,600 Temperature [K] 237 1,630 Pressure [bars] 0.002 24,000 Temperature [K] 250 1,350 Density [kg/m3] 0.00032 1,432 Energy [J/Kg] -187,568 4,212,000 Enthalpy [J/kg] -99,726 5,500,000 Enthalpy [J/kg] 1,500,000 4,500,000 Pressure [bars] 0.002 24,000 Entropy [J/kg/K] -1,582 12,733 Enthalpy [J/kg] 1,850,000 4,500,000 Entropy [J/kg/K] 2,000 10,500 Pressure [bars] 0.00021 46,700 Enthalpy [J/kg] -1,655 50,000,000 Entropy [J/kg/K] 0 13,000 Pressure [bars] 0.002 24,000 Energy [J/Kg] 500,000 4,000,000 0.001 500 Viscosity [Pa.s] 0.0000085 0.00013 Conductivity [W/m/K] 0.015 0.58 RPT / EPT SHP PHS / RHS HSP MER / KER Density [kg/m TABLE 1. Admissible 3] range of variations for thermodynamic variables Table 1 on page 2 lists the range of admissible variations for the thermodynamic variables, in the different tables proposed. Ranges have been extended from the default tables proposed up to FINE™ /Turbo v6.2-7, especially at low pressures (< 1000 Pa). Significant improvements, both in terms of robustness and accuracy, are expected in that area. D-2 FINE™ Main Characteristics Characteristics of Water (steam) Tables Tables Grid Interpolation Error RMS [%] Error Maximum [%] Size [Mb] PER 71 x 71 bi-cubic (double precision) 0.02 80.7 3.2 TER 71 x 71 bi-cubic (double precision) 0.014 1.7 3.2 RPT 101 x 101 bi-cubic (single precision) - < 0.1 3.3 EPT 101 x 101 bi-cubic (single precision) - < 0.1 3.3 SHP 41 x 41 bi-cubic (single precision) 0.0015 0.008 0.5 PHS 81 x 81 bi-cubic (single precision) 0.005 5.8 2.1 RHS 81 x 81 bi-cubic (double precision) 0.026 9.7 4.2 HSP 81 x 81 bi-cubic (single precision) 0.0003 0.01 2.1 MER 41 x 61 bi-cubic (double precision) 0.126 8.7 1.6 KER 41 x 61 bi-cubic (double precision) 2.02 27.2 1.6 PSA 120 cubic - - 0.1 TABLE 2. Main characteristics of water (steam) thermodynamic tables Both RMS (root mean square) and maximum errors should be interpreted as relative errors. RMS error does not exceed 2%, while in most tables it is ranging from 0.0001% to 0.1%. Maximum relative errors are located nearby the saturation line, where the interpolation naturally degrades despite the use of bi-cubic double precision algorithms. Tables RPT and EPT have been tuned so as to guarantee maximum accuracy in the vapor phase (< 0.1% at maximum). However, run performed in the liquid phase are consequently prohibited since they would lead to large relative errors (> 100%) in that area. A dedicated set covering RPT and EPT tables balancing maximum relative errors both on vapor and liquid phases can however be obtained upon request. Please take direct contact at [email protected] for any question on this purpose. FINE™ D-3 Characteristics of Water (steam) Tables D-4 Main Characteristics FINE™ Index INDEX A Abu-Grannam-Shaw Model 7-41 Add Fluid 3-3 ANSYS Outputs 11-10 AutoBlade 2-3, 2-10 AutoGrid 1-2, 2-3, 2-5, 2-10 Axial Thrust 8-11, 11-15 Azimuthal Averaged Output 11-9 B Background Color 1-7 Barotropic Liquid, see Fluid, Barotropic Liquid Benedict-Webb-Rubin 3-13 Blade To Blade 12-1–?? Boundary Conditions 12-8 File Formats 12-13–12-17 Flow Solver 12-12 Geometrical Data 12-3 Initial Solution 12-10, 13-5 Input Files 12-13–12-15 Inverse Design 12-8 Mesh Generator 12-6, 12-11 New Project 12-2 Numerical Model 12-10 Open Project 12-2 Output Files 12-15–12-17 Stream Surface Data 12-4 Theory 12-11 Bleed flow Data file 7-33 Flow Parameters 7-29 Outputs 7-31 Positioning 7-18 Visualization 7-30 Wizard 7-16 Block Conjugate Heat Transfer 7-12 Throughflow 6-2–6-3 Boundary Conditions 8-1 Blade To Blade 12-8 Lagrangian Module 7-4, 7-4–7-6 Rotor/Stator 5-17–5-19 Throughflow 6-7–6-8 Turbulence 4-16 Unsteady 4-2 Boussinesq 4-47 FINE™ C CFD Governing equations A-1 Introduction 1-1 CFL Number 7-12, 9-2, 9-17 CFView™ 1-3–1-4, 2-10 CGNS B-3 Characteristic Values, see Reference Values Computation Definition Area 2-12 Condensable fluid Boundary conditions 8-20 Outputs 11-4 Condensable Fluid, see Fluid, Condensable Conductivity 3-3–3-5 Laminar 3-10 Turbulent 3-10 Turbulent, Condensable Fluid 3-15 Conjugate Heat Transfer 7-11–7-15 Blocks Types 7-12 Theory 7-13–7-15 Control Variables 15-1 Unsteady 4-4 Convention 1-5 Convergence History 10-4 Cooling Theory 7-32, 7-33 Cooling flow Bleed flow 7-15 Data file 7-33 Flow Parameters 7-29 Outputs 7-31 Positioning 7-18 Visualization 7-30 Wizard 7-16 Create Grid File 2-3 Project 2-2, 2-4, 12-2, 13-2 Run Files 2-6 D Delete Fluid 3-7 Design 2D 2-10, 13-1–?? Formulation 13-4, 13-7 Input Files 13-3, 13-8 Interface 13-2 Output Files 13-9 Start 13-6 Theory 13-7–13-8 Design 3D 1-2, 2-3, 2-10 i Index INDEX Discretization Central Scheme 9-9–9-10 Limiters 9-12 Spatial 9-4, 9-7–9-13 Temporal 9-4 Time 9-17–9-21 Upwind Scheme 9-10–9-13 Drag 8-11 Drag Coefficient 11-19 Driver 1-6 Dryness Fraction 3-15 Duplicate Active Project 2-6 E Edit Fluid 3-7 Efficiency 11-16 Enthalpy 3-11, 3-15 Entropy 3-14 Euler 4-15 2D 6-1 Equations 6-13 EURANUS 1-3 EuranusTurbo Parallel Computation 14-8, 14-17 Expert Mode 2-12 Expert Parameters C-1, D-1 External Boundary Condition 8-13 F File Chooser 2-19 File Format 6-9, B-1 File Management 1-3 File Menu 2-4 File Names, Limitations 2-7 Fluid Add 3-3 Condensable 3-13–3-16 Delete 3-7 Edit 3-7 Incompressible 5-18 Interface 3-2 Liquid 3-12 List 3-2 Models 3-1–3-16 Perfect Gas 3-10 Real Gas 3-11 Fluid-Particle Interaction. See Lagrangian Module. Force 8-11 ii Blade 6-14 Friction 6-15 Forced Transition 7-38, 7-40 Formula Editor 3-6 Full Non-matching 5-20 Fully Laminar 7-40 Fully Turbulent 7-40 G Gauss Theorem 9-8 Global Layout 2-7 Global Performance 11-15, B-4 Graphics 1-6 Graphics Area 2-16 Gravity 3-5, 4-41 Grid Create Grid File 2-3 Grid Generation 1-2–1-4 Units 2-4, 2-8 Group Block Rotation 5-2 Boundary Conditions 8-2 Rotor/Stator 5-3 H Hand Symbol 1-5 Host Definition 14-5 Hybrid Analysis 6-3 I Icon Bar 2-10 IGG™ 1-3, 2-3, 2-5, 2-10 Incompressible Fluid Model, see Fluid Model, Incompressible Local Conservative Coupling 5-18 Initial Solution 10-1–10-8 Blade To Blade 12-10, 13-5 Block Dependent 10-1–10-3 Coarse Grid 9-3 Constant Values 10-3 File 10-4–10-5 Full Multigrid Strategy 9-16 Throughflow 6-8–6-9, 10-7–10-8 Turbomachinery 10-6–10-7 Turbulence 4-16 Unsteady 10-5 Initialization Full Multigrid Strategy 10-1 Unsteady 4-4 FINE™ Index INDEX Installation 1-6 Interface 1-7 General Description of FINE™ Interface 2-1–2-19 L Lagrangian Module Boundary Conditions 7-4, 7-4–7-6 Global Strategy 7-3 Interaction With Turbulence 7-10 Outputs 7-6 Particles Traces 7-7 Theory 7-9–7-11 Laminar 4-15 Layout 2-7 License 1-8 Lift 8-11 Lift Coefficient 11-19 Light Bulb 1-5 Limitations 2-7, 2-8 Limiter Lacor 9-12 Minmod 9-12 Superbee 9-12 Van Albada 9-12 Van Leer 9-12 Linearization 4-27 LIPROD 4-27 Liquid, see Fluid, Liquid Local Conservative Coupling 5-17–?? Loss Coefficient 6-6 Low Speed Flow 4-42 M Mach Number Absolute 11-5 Condensable Fluid 3-15 Isentropic 13-4, 13-10 Relative 11-5 Mathematical Model 4-15 Menu File 2-4 Menu Bar 2-4 Mesh 2-8 Modules 2-10 Solver 2-9 Merge Merge Mesh Topology 2-11 Patch For Azimuthal View 11-9 Mesh 1-2–1-4 FINE™ Information 2-15 Properties 2-8 Selection 2-11 Toggles 2-14 View 2-8, 2-16–2-18 View Area 2-13 Modules 2-10 Moment 8-11 Momentum 11-19 Monitor Convergence History 15-11 Display 15-10 Quantities 15-3 Residual File Box 15-9 Solution 15-1–15-12 Steering File 15-3 Zoom 15-10 MonitorTurbo 15-7 MSW Driver 1-6 Multigrid 9-2 Full 9-16 Prolongation 9-16 Strategy 9-3, 9-13–9-17 N New Project 2-4, 12-2, 13-2 Numerical Model 9-1 Blade To Blade 12-10 O Open Project 2-3, 2-5 OPENGL Driver 1-6 Outputs 3-15, 11-1–11-24 3D Quantity 11-2–11-7, 11-20 Azimuthal Averaged 11-9, 11-18, 11-21–11-23 Lagrangian Module 7-6 mf File 11-15, 11-18 Particle Traces 7-7 Surface Averaged 11-8, 11-21 Theory 11-20–11-24 P Pair of Scissors 1-5 Parallel Computation 14-13 Parameter Button 2-13 Parameters Area 2-2 Particles 7-1 Perfect Gas, see Fluid, Perfect Gas iii Index INDEX Performance 11-15, B-4 Periodic Boundaries 6-7, 8-9 Phase Lagged 4-3, 4-13 Plot3D 11-17, B-6 Post Processing 1-3–1-4 Prandtl Number 3-10 Preconditioning 4-42 Parameters 4-45, 9-3 Preferences 2-6 Profile Manager 2-19, 3-3–3-6 File Formats B-7 Project Configuration 2-4 Creation 2-2 Duplicate 2-6 Management 1-3 New 2-4 Open 2-3, 2-5 Save 2-6 Units 2-6 Properties Fluid 3-1 Mesh 2-8 PVM Daemons 14-1–14-5 Q Quit 2-7 R Real Gas, see Fluid, Real Gas Reference Density 3-9, 4-47 Length 4-47 Pressure 3-5, 4-45 Reference Values 4-47 Temperature 3-5, 3-9, 4-45 Velocity 4-45, 4-47 Residual 11-6, 15-5, B-4 Implicit Smoothing 9-20 Radespiel & Rossow 9-20 Swanson & Turkel 9-21 Vasta 9-21 Restart 2-10 Design 2D 13-6 Unsteady 4-5 Reynolds Number 4-47 Rotation Blocks 5-2–5-3 iv Rotor/Stator Domain Scaling 5-11–5-12, 5-21–5-24 FNMB Mixing Plane Coupling 5-19–5-21 Frozen Rotor 5-9–5-10, 5-24 Initial Solution 10-6 Interface 5-3–5-5 Local Conservative Coupling 5-17–5-18 Mixing Plane Coupling 5-5–5-8, 5-16–5-21 Phase Lagged 5-13 Pitchwise Rows Coupling 5-18–5-19 Steady 5-5–5-8, 5-9–5-10, 5-16–5-21, 5-24 Theory 5-15–5-24 Unsteady 5-11–5-12, 5-13, 5-21–5-24 Rough Wall 4-35 Run File 1-3, 2-6 Runge-Kutta Scheme 9-17 S Save Intermediate Solution 2-9 Project 2-6 Scripts 14-14 Second Order Restart 4-5 SI System 2-6 Smooth Wall 4-35 Solid Data 11-6 Solver Menu 2-9 Specific Heat 3-10–3-12, 3-15 Standard Mode 2-12 Start Flow Solver 2-9 Stator Rotor/Stator Interface. See Rotor/Stator. Steady Rotor/Stator 5-5–5-8, 5-9–5-10, 5-16–5-21, 5-24 Stop Flow Solver 2-9 Surface Averaged Output 11-7 Suspend Flow Solver 2-9 Sutherland 3-9 Sutherland Law 3-9 T Task Definition 14-6 Taskmanager 14-1–14-23 Add Host 14-5 Delay 14-6 Limitations 14-22 Parallel Computation 14-8 PVM 14-1–14-5 FINE™ Index INDEX Remove Host 14-6 Scripts 14-14–14-22 Shutdown 14-6 Subtask 14-7–14-11 Task Definition 14-6–14-11 Tear-off Graphics 2-8 Temperature Reference 3-9 Sutherland 3-9 Thermal Connections 7-12 Thermodynamic Tables 3-13 Throat Control 6-3 Throughflow Analysis Mode 6-3 Blade Geometry 6-3–6-5 Block Type 6-2 Boundary Conditions 6-7–6-8 Expert Parameters 6-12 File Format 6-9–6-11 Flow Angle/Tangential Velocity 6-5–6-6 Global Parameters 6-2 Initial Solution 6-8–6-9, 10-7–10-8 Loss Coefficient 6-6 Mesh 6-6 Model 6-1–6-15 Theory 6-13–6-15 Time Configuration 4-2 Time Step Global Time 9-4 Local Time 9-4 Physical 4-14 Torque 8-11, 11-15 Transition Model 7-37 Abu-Grannam-Shaw Model 7-41 Forced Transition 7-38, 7-40 Fully Laminar 7-40 Fully Turbulent 7-40 Turbulence Boundary Condition 4-16 Initial Solution 4-16 Linearization 4-27 Output 11-7 Turbulence Models Baldwin-Lomax 4-28 k-epsilon 4-31 Non Linear k-epsilon 4-33 Spalart-Allmaras 4-29 TVD 9-11 FINE™ U Units Grid 2-4, 2-8 Project 2-6 Unload Mesh 2-8 Unsteady 4-2 Boundary Conditions 4-2, 4-6, 4-12 Control Variables 4-4 Create 4-6 Initial Solution 10-5 Initialization of 4-7 Phase Lagged 4-3 Rotor/Stator 5-11–5-12, 5-21–5-24 Rotor/Stator Phase Lagged 5-13 Second Order in Time 4-5 Turbomachinery 4-12 User Mode 2-12 V Vander Waals 3-13 Velocity Absolute 11-5 Friction 4-21 Local Scaling 4-46 Projections 11-5 Reference 4-47 Relative 11-5 Relative Projections 11-5 View Area 2-13 View Manipulation 2-16 View On/Off 2-8, 2-13 Viscosity Inviscid Flux 9-8 Laminar 3-9 Turbulent 3-10, 4-39 Viscous Flux 9-8 Vorticity 11-5 W Wall Rough 4-35 Smooth 4-35 Work Unit B-4 X X11 Driver 1-6 Z Zoom In/Out/Region 2-18 v