Validation

For the validation of this script, we will implement the RAE-2822 airfoil test case as specified in the AGARD report in [80]. This test case was done on an airfoil at M_∞ 0.6-0.7, with some experimental scenarios showing transonic shocks. The scenario that we are going to use has an angle of attack of 2.57 degrees and M_∞ of 0.6 and no shocks are present. The angle of attack is imposed by rotating

Figure 4.55: Initial mesh given in [101].

Figure 4.56: Initial mesh ob- tained from the script.

Figure 4.57: Final mesh given in [101]. Velocity vector plot.

Figure 4.58: Final mesh ob- tained from the script.

Figure 4.59: Pressure given in [101]. Figure 4.60: Pressure obtained from the script.

Table 4.7: Different mesh cases used for validation of the solver and the element sizes defined at the boundaries of different zones of the domain. Element size is given relative to the chord. Element quality interval and average is given at the last two columns

Airfoil Near Field Mid Field Far field γinterval γaverage

Coarse 0.02 N/A 0.02 2.0 [0.7228,1.0000] 0.9905

Normal 0.01 N/A 0.01 2.0 [0.6560,1.0000] 0.9941

Fine 0.005 N/A 0.005 2.0 [0.6357,1.0000] 0.9973

Very Fine 0.0025 0.0025 0.005 2.0 [0.6357,1.0000] 0.9933

Figure 4.61: Density given in [101]. Figure 4.62: Density obtained from the script.

the airfoil geometry: the inbound farfield velocity is always horizontal. For the shape of the airfoil, we have used a spline interpolation of the design points (not the experimentally measured ones) supplied by the report, and we chose a unit chord (rather than the 0.61 m specified in the report). This choice was numerical in nature. Since there is no physical viscosity, uniformly scaling up or down the airfoil should not affect the obtained results. However using a unit chord seriously simplifies the post-treatment of data, as there is no need to transform data from xto x/c. For the atmospheric conditions, we have chosen ISA conditions at 0 m of altitude with no correction: p_∞is 101325 Pa,ρ_∞ is 1.225kg/m³ and the perfect gas ratio γ was 1.4. For the discretization, we have chosen GMSH for meshing, as the mesher in FreeFem++ tends to produce very fine elements near the corners, producing strong element size variations that may locally affect the results (see figure 4.56 for an example). We have chosen a circular domain with a radius of 50.5 chords that was partitioned in 2 concentric zones by an ellipse with a major radius of 2 chords. This ellipse, the outer boundary and the airfoil are referenced in table 4.7 as Mid Field, Far field and Airfoil, respectively, and it was at these lines that we have input the element size (as given in the table) to the mesher. For the Very Fine mesh case another ellipse was defined with a major radius of 1.25 chords, partitioning the whole domain into three concentric zones. This additional ellipse is referenced to as ”Near Field” in table 4.7. The point of defining these additional lines is to ensure, to the best of our abilities, a smooth transition in element size and a superior element quality, to avoid misjudging the solver due to a low quality mesh. All meshes were created using the Frontal algorithm of GMSH followed by 10 mesh smoothing steps. An overview of the quality of the mesh is also given in table 4.7. The element quality criterion used is defined as [115] : γ= ^r_r^ci

cc, whererciis the incircle radius andr_ccis the radius of the circumcircle. γ= 1for an equilateral triangle andγ= 0for a triangle distorted into a line. The worst element quality found in table 4.7 was found for all mesh cases at the transition between the Mid Field and the Far field. Still, the vast majority of elements have near perfect quality, which explains the averageγ near 1. Concerning the solver in the script itself, the time

step was modified so as to ensure a constant Courant numberCo, in other words, we ensured that:

u_∞ ∆t

pSmin/2 =constant=Co (4.19)

Hereu_∞is the farfield velocity,∆tis the solver timestep,Smin is the minimum element area. We used the minimum element area because of the high-quality of the elements in the finer zones (meaning that we have near-perfect equilateral triangles) and because of how easy it is to obtain such data directly in FreeFem++. The number of iterations was accordingly modified so as to have a constant pseudo-time interval. Nothing else was changed, and we use the same 1st order Finite Elements used by the original author (this also avoids the need to recalculate the Courant number, as changing the element order changes the stability properties of the model). We have additionally computed the same problem with the exactly same meshes and boundary conditions by using SU2 ([76]), the solver presented earlier in this chapter where extensive validation tests have been done by the creators. This was done to give us an idea of what to expect for a ”true” inviscid solution, and to be able further criticize the validity of the solver. For the SU2 computations, we modified the ”Quick-Start” file that comes with the software suite to fit our needs. This file ran a Compressible Euler computation on a NACA-0012. It uses an Implicit-Euler time marching scheme, a Jameson-Schmidt-Turkel flux, a Venkatakrishnan limiter and a 3-level multi-grid method. Care was taken to match the non-dimensionalization length used by the solver with the airfoil length used for the RAE-2822 mesh. Again the angle of attack is imposed by rotating the geometry, whilst the incoming flow remains horizontal, and exactly the same atmospheric and boundary conditions were imposed as for the FreeFem++ script. The FreeFem++ solver seems to slowly converge to the experimental result, as evidenced by the table 4.8 and the C_p plots in 4.63, but even with the very fine mesh it shows a non-negligible deviation both in the lifting coefficients and in the obtained Cp. What is more, despite being an inviscid solver, the FreeFem++ calculates a drag coefficient bigger than what is observed experimentally. We can see that the FreeFem++ solver generates a numerical boundary layer and wake by observing the vorticity and Mach plots provided in figures 4.69 and 4.67, which might explain the anomalous drag. The drag does decrease the further we refine the mesh but it seems that the solution itself converges very slowly with the degree of refinement of the mesh. The solution provide by SU(2) seems to rapidly converge with the degree of mesh refinement: though the C_L might still vary in table 4.8, the Cp plot itself varies little with the used mesh 4.64. We also obtain a drag coefficient smaller than what observed experimentally, specially for the Fine mesh. Besides that, we seem to overestimate the magnitude of the real Cp, whereas the FreeFem++ underestimates it. Furthermore upon analyzing the Mach plot in figure 4.68 we see no numerical boundary layer nor wake. However, the computed solution seems to indicate that we are on the verge of the critical point, as evidenced by figures 4.68 and 4.66, which is not the case nor for the FreeFem++ solver (see figure 4.65) nor for the experimental data in [80]. Due to the very fast convergence of the Cp with the refinement of the mesh, we felt that it was not necessary to compute the Very Fine case with SU(2). In conclusion we would say that though the FreeFem++ solver seems to converge very slowly towards the physics we are trying to simulate, but this convergence is too slow and the computational times too great: on the

Table 4.8: NumericalC_L andC_D data, with residue data for the FreeFem++ solver. The experimental AGARD data givesC_L= 0.522 andC_D= 0.0101.

Case CL CD ResCL ResCD

Coarse 0.212 0.0571 1.46e-4 3.13e-6 Normal 0.339 0.0579 1.88e-4 3.92e-6 Fine 0.440 0.0481 4.70e-5 8.22e-6 Very Fine 0.480 0.0357 2.35e-5 4.39e-6

(a) FreeFem++

Case C_L C_D

Coarse 0.605 0.0168 Normal 0.677 0.0067 Fine 0.722 0.0018

(b) SU(2)

same machine, the Fine mesh took 13 hours to compute with FreeFem++ whilst SU(2) took 7 minutes.

The Very Fine mesh took 2 days to compute in the same machine. This means that this model could not produce high-fidelity results as quickly as other solvers, and we are therefore inclined to label this model as a low to medium-fidelity model. The FreeFem++ model uses the characteristics method for treating the advection terms of the Euler equation, as stated in [101]. Since we are dealing with subsonic speeds and thus with problems elliptic in space, this method should handle the advection terms with low diffusion and dispersion, according to the authors of FreeFem++ (see [100] for a discussion linking the type of problem to be solved with the methods available in FreeFem++ and a study of the accuracy of the characteristics-method on a 2-dimensional linear advection problem). It could be that with higher-order elements or the use of parallel computing could speed-up both the convergence and the calculation of the solution, but when attempting to use the parallel MUMPS or Pastix solvers as specified in the manual [100] the results exploded, and using higher-order elements would require searching for a new Courant number that guarantees the stability of the model. We quickly step into the creation of high- fidelity models, which is outside of the scope of this thesis. Hence, given that this thesis concerns itself with model reduction and the deviations of ROMs relative to the models they reduce, we will still use the FreeFem++ solver as a test bed our model reduction methods, as it does seem to incorporate the physics present in compressible flows (albeit with error), and it is a time-marching non-linear model. Doing this will allow us to understand what sort of deviations to expect when using ROMs on higher-fidelity solvers that are also non-linear and time-marching.