Joëlle Bailly

Biel Ortun
email: biel.ortun@onera.fr

Yves Delrieux
email: yves.delrieux@onera.fr

Hugues Mercier

Des Rochettes

Recent Advances in Rotor Aerodynamic Optimization

Keywords:

come

underperforms the reference. Also, higher blade-vortex interaction noise levels occur in descent flight. Next, as a step to evolve towards increasingly feasible optimized designs, a method to update blade structural properties as a function of variations in blade shape is proposed. The method is first evaluated between two real blades of known properties. Secondly the method is implemented in a shape optimization loop and assessed for two optimization cases. It is shown that accounting for structural data modifications smoothes the optimal shape and produces more realistic designs, albeit at a cost of smaller margin in power reduction.

Nomenclature

Introduction

The design of helicopter rotor blades has significantly evolved during these last decades, especially due to the improvement of optimization algorithms, the advances in simulation methods, and the increase of computational capabilities, in all the disciplines in which the helicopter is concerned. The helicopter rotor design process is multidisciplinary in nature and involves a merging of several disciplines including aerodynamics, dynamics, acoustics and structures. The quality of the new designs of helicopter rotor blades largely depends on the accuracy of the codes used to simulate the helicopter behavior, the efficiency of the sensitivity analysis techniques, and the availability of suitable approximate analysis (Ref. 1).

The search of new designs by passive optimization of blade planform and/or airfoils can be carried out to improve one single objective function (performance improvement, reduction of vibration, reduction of blade-vortex interaction noise level) or multiobjective optimization. A major difficulty for designers is to find the best compromise solution, without degrading the performance of the optimized rotor on other disciplines, and/or other flight conditions than those chosen for the optimization point, while observing realistic technological constraints.

The design of new industrial optimized rotors follows this approach. Since the early 1990's, ONERA has performed several design studies, in the framework of single optimization programs, such as the ORPHEE and B2005 for aerodynamics (Refs. [2][START_REF] Pape | Numerical Optimization of Helicopter Rotor Aerodynamic Performance in Hover[END_REF][START_REF] Pape | Numerical aerodynamic optimization of helicopter rotors: multiobjective optimization in hover and forward flight conditions[END_REF] and for dynamics (Ref. [START_REF] Zibi | Helicopter Rotor Aerodynamic and Dynamic Optimization Methods[END_REF]) and ERATO for acoustics (Ref. [START_REF] Delrieux | The ONERA-DLR Aeroacoustic Rotor Optimisation Programme ERATO: Methodology and Achievements[END_REF]). These efforts contributed to the new Airbus Helicopters' Blue Edge TM This procedure provided better design than a single-level optimization, as a consistent set of structural properties was found.

The quality of the optimized design depends on the accuracy of the numerical optimizers. Some of the optimizers require the calculation of the gradients (or even the Hessian) of objective functions and constraints when they exist (for example, the Kuhn-Tucker conditions are used for the feasible direction methods). Many of the studies mentioned above used the CONMIN optimizer (Ref. 12), a gradient-based method based on the feasible direction, for which the gradients are obtained numerically. Sensitivities The gradient-based methods can not always be ensured to reach the global optimum.

An alternative to these methods is the use of stochastic or genetic algorithms, which began to be used during the 90's. These algorithms require a large number of evaluations of the objective function (and eventually the constraints). The computational cost should be as limited as possible, by performing either low fidelity simulations, or by using surrogate based optimization methods (SBO). Recent studies show the effectiveness of surrogate models used in an optimization procedure to evaluate the objective function, in order to reduce vibration levels (Ref. [START_REF] Glaz | Surrogate Based Optimization of Helicopter Rotor Blades for Vibration Reduction in forward Flight[END_REF] or to improve the aerodynamic performance of a helicopter blade (Refs. [START_REF] Collins | Application of Low and High Fidelity Simulation Tools to Helicopter Rotor Blade Optimization[END_REF][START_REF] Wilke | Multi-Objective Optimizations in Rotor Aerodynamics using Variable Fidelity Simulations[END_REF][START_REF] Roca | Concurrent Aerodynamic Optimization of Rotor Blades Using a Nash Game Method[END_REF]. These methods have the advantage of reducing the CPU cost of complex numerical simulations (such as loose CFD/CSD coupling), and offer a global search of the design space. Concerning vibration level reductions in forward flight, it has been shown that a Kriging surrogate model is very efficient to determine an optimal design, despite some local errors. The same conclusions are drawn in a recent multi-point optimization (for hover and forward flight configurations) using the Nash game theory, to improve the performance of a helicopter rotor blade (Ref. [START_REF] Roca | Concurrent Aerodynamic Optimization of Rotor Blades Using a Nash Game Method[END_REF]). Some of the above references clearly show that an optimum solution found from an aerodynamic design can present some unrealistic shape when additional structural and/or flight mechanics constraints are not taken into account in the optimization procedure.

Modifying the structural data consistently with complex geometry blade planforms becomes an important step. In Ref. 20, structural data is scaled following the variation in size of the cross-section. In Ref. [START_REF] Lim | Consideration of Structural Constraints in Passive Rotor Blade Design for Improved Performance[END_REF], updates to the blade structural properties (using parametric equations) in the design variables allow accurate evaluation of performance objectives and realistic structural constraints.

This paper is composed of two parts. The first one summarizes a recent rotor blade shape optimization exercise with an emphasis on the risk of off-design performance degradation. The optimization procedure is based on the coupling between a low fidelity comprehensive analysis (HOST code based on lifting line theory, Ref. [START_REF] Benoit | HOST, a General Helicopter Simulation Tool for Germany and France[END_REF]) and an evolutionary optimizer (CMA-ES; Refs. [START_REF] Hansen | Evaluating the CMA Evolution Strategy on Multimodal Test Functions[END_REF][START_REF] Moens | Multi-Point Optimization of Shapes and Settings of High-Lift System by Means of Evolutionary Algorithm and Navier-Stokes Equations[END_REF], chosen to avoid the risk to obtain a local optimum. After optimizing the blade shape with respect to rotor power in a high speed and high-load forward flight condition, benchmarks against the reference blade were performed on acoustics in descent flight and aerodynamic performance in hover.

Then, in the second part, as a step to evolve towards increasingly feasible optimized designs, a method to update blade structural properties within a shape optimization loop is proposed and evaluated. The primary contribution of this article is the proposal, implementation and evaluation of a method to update the structural properties of a blade as a function of variations in its shape that prevents the aerodynamic optimization from producing unrealistic designs.

Blade Shape Optimization

In the framework of the European CleanSky Green Rotorcraft project, DLR (Ref. [START_REF] Imiela | Passive Blade Optimization and Evaluation in Off-Design Conditions[END_REF] and ONERA (Ref. 26) conducted optimization studies in order to deliver to Airbus Helicopters Deutschland characteristics of an optimized full-scale rotor blade for performance improvement, which is planned to be tested in a whirl-tower. More specifically, ONERA worked on the twist distribution and anhedral of a reference blade, at a single-point condition at high speed (V h =140kts, µ=0.36), and high load (C T /σ=0.09).

Reference Rotor Definition

The reference rotor is 5-bladed and full scale, with an aspect ratio of 18.6. The blade planform is presented in Fig. 1.

The blade is rectangular on a large extent of the span, and then, at the blade tip, the leading edge follows a parabolic evolution. The blade is equipped with the two airfoils OA312 and OA309. Linear interpolation is performed in the area between these airfoils.

A linear geometric twist is defined, and no anhedral is applied at the blade tip.

Optimization Procedure

The objective of this study is to define an optimized static twist law, and then an anhedral law to reduce the shaft power consumed by the main rotor. The objective function is the minimization of the main rotor shaft power. The design variables are firstly the twist law, discretized on 9 Bezier poles distributed along the blade span, and then the anhedral law, discretized on 2 Bezier poles, on the outboard 5% of the span. No constraint is applied on the objective function. The design variables are bounded between -10° and +10° for the twist angle, and between -2º and +2º for the anhedral angle. 950 evaluations were performed to reach convergence of the optimization procedure. Since the comprehensive code used in this study uses a lifting-line approach which is not time consuming, the large number of optimizer calls is not prejudicial.

Numerical Tools

The objective function is the minimization of the power consumed by the main rotor.

The goal function is evaluated with the HOST comprehensive analysis (CA) (Ref. consists of taking into account a prescribed wake helical geometry.

HOST modeling of blade dynamics is achieved through a simple beam model with 3 degrees of freedom, which are the chordwise and flapwise bendings, and the torsion angle. In order to reduce the number of unknowns, each degree of freedom is projected on a modal basis. The blade is represented as an assembly of rigid segments connected by virtual joints and distributed along a straight axis, assumed to be collinear with the pitch axis. Center of gravity and elastic axis offsets are enabled.

The effects of the optimized twist and anhedral laws are analyzed in forward flight and in hover by a CA/CFD loose coupling method, which is more accurate than pure comprehensive analysis for the evaluation of three-dimensional effects of the flowfield. Table 1 summarizes the different numerical tools used in this study, on the one hand for the optimization procedures and on the other hand for the aerodynamic and acoustic analysis of the optimization results.

Optimization results

The search of optimized twist and anhedral laws is performed for the following forward flight configuration, at rather high values of thrust and velocity: C T /σ=0.09, V h =140kts, Ω=347.21 rpm (µ=0.36), (CxS) f /Sσ=0.15. The isolated rotor is trimmed by the HOST comprehensive code, following a 3-variables law, prescribing these values for the rotor thrust (C T /σ), the propulsive force (CxS) f /Sσ, and the rolling moment Mx (at 0 Nm). Prescribing the propulsive force allows a constant value of the fuselage power for the reference and the optimized rotors to be simulated.

The radial evolutions of the optimized twist and anhedral laws, obtained by the optimization procedure to improve the aerodynamic performance of the main rotor, are plotted in Fig. 2.

The optimization procedure provides a moderate decrease of the twist angle in the inner part of the blade, and then an increase of the twist in the outer part of the blade.

Concerning the anhedral optimization, the best compromise leads to a negative linear deflection, corresponding to an angle of -4.7° at the blade tip.

The effect of these two optimized laws is analyzed in detail from the aerodynamic, vibration and acoustic points of view.

Aerodynamic evaluation in forward flight by comprehensive analysis

Comprehensive analysis with the HOST code has shown its capability to correctly predict the hierarchy between different rotors (ORPHEE, ERATO, B2005 programs).

Comparisons with numerical results from other comprehensive analyses performed in the framework of international cooperations (HART-II; Ref. 37) are largely satisfactory.

The power reductions predicted by HOST comprehensive analysis, at the nominal optimization point, for the twist optimized rotor on one hand, and the optimized twist and anhedral rotor on the other hand, with respect to the reference are summarized in Table 2.

It is reminded that shaft power can be split into different terms: induced power (linked to the lifting loads), profile power (linked to the drag of the airfoils), and parasite power (linked to the drag of the fuselage). Since trim is done to ensure a constant propulsive force, only induced and profile power are addressed next.

Significant reduction of the shaft power is predicted by the comprehensive computations (about 4%), mainly due to a decrease of the induced power. The main origin of the shaft power reduction comes from the optimized twist law. The addition of the optimized anhedral law on the optimized twisted rotor provides a further power reduction of only 0.1%.

The rotor disk distributions of the difference of the induced power and the profile power between the optimized twist and anhedral rotor and the reference are plotted in Fig. 3.

The decrease of the induced power for the optimized rotor is located in the inner part of the advancing side of the rotor (blue area). This reduction of the induced power is directly linked to the decrease of the optimized twist law in the inner part of the blade, leading to smaller values of incidence angles, and consequently of aerodynamic loads. A limited increase in profile power is generated at the retreating blade tip. This effect of the optimized twist law on the profile power (and so on the drag coefficient) can lead to predict a behavior more sensitive to stall. Actually, the flight domain for an advancing speed of 140 kts, predicted by comprehensive computations for the reference and the two optimized rotors, shown in Fig. 4, illustrates this trend for the highest thrust coefficients.

For instance, for the thrust coefficient of C T /σ of 0.1, the power reduction falls to 2%.

The slope of the curve of the thrust coefficient versus the total power becomes lower for the twist optimized rotor at the highest loads. It can be noticed that the effect of the anhedral law is more important for low thrust levels.

Aerodynamic analysis in forward flight by CSD/CFD loose coupling

The power consumed by the main rotor is evaluated by a comprehensive analysis during the optimization procedure as the large number of evaluations (~1000) to determine the optimized point requires a fast evaluation. It is now interesting to check a posteriori the power prediction of the reference and the optimized rotors by a higher fidelity computational tool, taking into account the three-dimensional effects of the flow.

This is achieved by a loose coupling between the HOST comprehensive code and the

elsA CFD code (Ref. 29).
The CFD simulations are based on a structured, overset grids approach composed of a fixed Cartesian background grid and rotating, deformable, near-body blade grids (Ref. Both low and high fidelity simulations (respectively by HOST and HOST/elsA codes) predict significant power reduction for the optimized rotor with respect to the reference, respectively of -3.8% and -2.7%. Even if the flow is assumed to be fully turbulent in the CFD calculations, the local aerodynamic loadings are more accurately predicted by high fidelity simulations than by comprehensive analysis, as it can be shown in previous studies (Ref. [START_REF] Potsdam | Rotor Airloads Prediction Using Loose Aerodynamic/Structural Coupling[END_REF]). The positive effects of the optimized twist law on the lift coefficient occur in the two types of calculations (Fig. 5): vanishing of the negative peak at the tip of the advancing blade (between 90º and 180° of azimuth) while reducing the lift in the inner part of the blade. As previously explained, these effects are directly associated to the reduction of the optimized twist in the inner part of the blade, leading to smaller values of angle of incidence, and so reducing the lifting loads. These effects are beneficial for the induced power level.

The reduction of the lift on the advancing side of the optimized rotor is balanced by an increase of the lift on the aft part of the rotor (ψ=0°), to ensure the same total rotor thrust. This trend is particularly pronounced with the HOST/elsA loose coupling calculation. This over-loaded area is supposed to be partly responsible for an increase of the (induced) power consumed by the optimized rotor in this area, predicted by the loose coupling calculations, leading to a moderation of the total power reduction with respect to comprehensive simulations.

Aerodynamics analysis in hover

In hover, performance of the reference and the optimized rotors is predicted using the loose coupling methodology between the HOST comprehensive code and the elsA CFD code. The multi-block grid generated for the reference blade is deformed with respect to the optimized twist and anhedral laws (following Bezier curves deformations). The nearbody grids are then immersed in a cylindrical background grid, using the Chimera technique. Only one sector of the 5-bladed rotor is modeled and periodicity boundary conditions are applied on the azimuthal boundaries of the computation domain.

The evolution of the figure of merit with respect to the rotor thrust is plotted in Fig. 6 for the reference and the two optimized rotors. The plotted points confirm the expectations, namely that optimization in forward flight tends to degrade hover performance.

At the highest thrust coefficient solved (C T /σ=0.095), figure of merit is decreased by 2.7 points for the optimized twist rotor, and by 1.8 points for the optimized twist and anhedral rotor with respect to the reference, which is quite significant. Like in forward flight, the optimized rotors' performance declines faster than the reference at the higher loadings. The effect of anhedral is noticeable, with an improvement of the figure of merit, when the thrust is increased. This improvement can be explained by a reduction of the lifting airloads at the blade tip. This reduction of the loads is directly linked to the reduction of the intensity of the tip vortex. This anhedral effect is illustrated in Fig. 7 by comparing, without (Optim Twist) and with anhedral (Optim Twist + Optim Anhedral), a vorticity contour on a vertical plane upstream of a blade revealing the vortex shed by the previous blade tip.

Acoustic analysis in descent flight

Even though the main objective of this study is to improve the aerodynamic performance of the reference rotor by optimizing its twist and anhedral laws, it is interesting to evaluate a posteriori the blade-vortex interaction (BVI) noise levels of the resulting aerodynamically optimized rotors.

The aero-acoustic computational chain HMMAP is used to evaluate the BVI noise.

The flight configurations are the following: C T /σ=0.0845, V h =65kts, Ω=347.21 rpm (µ=0.17), the descent angle α d varying from 0 to 12°.

The isolated rotor is trimmed with the no-flapping law. The thrust and the propulsive loads to be reached are determined with respect to the value of the descent angle. The maximum BVI noise levels (determined 115m beneath the rotor disk, and filtered between the 6 th and 40 th blade passage frequencies) detected on the advancing side of the rotor are plotted in Fig. 8. It clearly appears that the optimized rotors are noisier than the reference, especially when the descent angle is steeper. The anhedral tends to slightly increase the BVI noise level with respect to the optimized twisted rotor, especially provided by a decrease of the downwards convection of the wake, which moves closer to the blade tip (Ref. [START_REF] Lim | Consideration of Structural Constraints in Passive Rotor Blade Design for Improved Performance[END_REF].

Updating blade structural data during a shape optimization loop

The main idea of this investigation is to develop a fast method to estimate the variations in structural properties of a blade following a change in its shape. The objective is to include this new structural update capability in an aerodynamic shape optimization loop. Thus, the potential performance gain of any new blade shape will be more realistically assessed, provided the aerodynamic cost function is evaluated through a coupled aeromechanic approach.

This section is structured in four parts: first it presents the beam structural model in the comprehensive rotorcraft code HOST, because the developed method for structural update was adapted to HOST, although it should be valid for any general beam representation. Then the approach for developing the structural update is described.

Thirdly, a validation exercise is carried out comparing against real blades of known properties. Finally, the method is assessed through two optimization exercises.

Development of a method for estimation of structural properties

In the current study, structural data estimations are inferred from a parametric study based on finite element computations, as described next. The approach for developing this innovative method was based on two steps. A set of polynomial functions for sectional mechanical properties such as flap bending stiffness, lag bending stiffness, torsion stiffness, mass, etc were produced by conducting a parametric study with a finite element model of a typical blade cross-section structure and varying its chord and thickness. The selected approach assumes an internal structure of the cross-section of the blade, representative of a typical sandwich construction of rotor blade. While the structural layout of the cross-section remains constant, it is its scaling (e.g., chord variations, which will also affect thickness if the airfoil relative thickness is to be maintained) that will modify the mechanical properties.

In the shape optimization loop, for each new shape to evaluate, blade structural properties are modified accordingly before evaluating the rotor power through an aeromechanic simulation. These data modifications include both spanwise stiffness information and geometrical information concerning the location of the centre of gravity with respect to the blade pitch axis. Blade planform variations, like sweep, will not modify the stiffness of the blade, but will change the offsets of the elastic axis and sectional centre of gravity with respect to the blade pitch axis, so they are taken into account as well. The update of stiffness, mass and inertia data relies on the functions obtained in the first step. Geometrical data on offsets between the different airfoil centres (gravity, shear, tension) and the blade pitch axis are estimated analytically from the above mentioned assumption that the internal structure of the blade cross-sections remains constant (i.e., the position of the centres relative to the chord and thickness of the crosssection does not vary).

The method needs three inputs: (1) the structural properties of the original blade; (2) the shape of the original blade; and (3) the new shape. The output is a modified set of structural data according to the variations between the original and the new geometries.

Stiffness, linear mass and inertia are updated as follows:

New value = original value x (new estimated value)/(original estimated value)

where 'estimated' means that the structural value has been recomputed, with the polynomial functions, from the cross-section chord and thickness. In addition, polar inertia must be corrected by the Steiner parallel axis theorem whenever a change in sweep or dihedral translates the cross-section with respect to the rotation axis for polar inertia, which in this study is the blade pitch axis. This is achieved by adding to the above expression the term md 2 , where m is the section linear mass (freshly updated) and d the distance between the two parallel axes.

Validation by comparison against two real blades of known properties

This validation stands on two real blades of known properties. These blades are ONERA's 7A and 7AD scale model blades, tested in ONERA's S1MA wind tunnel in 1991. They only differ in the outboard 5% of the blade: 7A has a rectangular blade tip, whereas 7AD has a parabolically swept leading edge, as schematized in Fig. 9. Although not apparent in the figure, 7AD tip features also some anhedral. In the actual model both tips could be clipped on a common truncated blade.

The structural update method is used to estimate 7AD's structural properties, having as input the geometry of both blades and the structural properties of the 7A blade. for flap bending stiffness, with a relative error of -6.3%. The highest error is on the linear mass, which is overestimated by 127% at the blade tip. This in turn increases the error in the polar inertia due to the Steiner term md 2 . If the actual 7AD linear mass is imposed in the polar inertia estimation, then polar inertia relative error is reduced from current 64.3% to -27.3%.

Although relative errors in this validation exercise are often double-digit, the error would be much larger if structural data were not updated at all, as can be seen by looking at the original 7A data.

To validate further this estimation of 7AD structural properties, three comprehensive analyses of the 7AD rotor in forward flight, at advance ratio 0.4 and C T /σ=0.080, were carried out, the first one with the actual 7AD properties, the second one with 7A

properties and the third one, with the estimated 7AD properties. Total power differences are negligible, probably because only the 5% outboard blade structural properties differ.

However, maximal blade elastic torsion (which happens at the advancing blade tip, azimuth=90 deg) is more revealing. The 7AD comprehensive analysis with original 7AD data predicts a nose-down twist equal to -2.83 deg. With 7A structural data, nose-down twist is smaller, -2.59 deg, consistently with a larger tip chord and thus greater torsional stiffness. With estimated 7AD data, elastic twist is -2.87 deg, which is much closer to the true 7AD results. Had the structural properties differed over a greater outboard span, differences in elastic twist would have likely had an impact on rotor performance.

The least accurate assumption in the new method probably lies in the estimation of the position of the tension center (where axial forces can be applied without inducing any bending, and which is assumed to be colinear with the elastic center (where shear forces can be applied without inducing any torsion)). The method simply shifts the position of the tension center by as much as the variation in sweep and/or anhedral. While this is known to be inaccurate, an accurate estimation of the tension center position would require an effort beyond the fast and computationally inexpensive capability of this method.

Assessing the influence of the structural update on two aerodynamic shape optimization exercises

The new tool for structural data update has been tested on two optimization cases: an optimization of chord distribution and an optimization of sweep distribution. Twist is not tested because the method of estimation of structural properties does not model the effect of twist variations on blade stiffness (e.g. transfer of flapping stiffness into lag stiffness and vice versa). That is why the twist optimization performed in the first part of this investigation would not benefit from the structural data update.

The two examples compare the outputs of optimizations in forward flight (V h =140kts, C T /σ=0.09) using an evolutionary algorithm (CMA-ES) and evaluating the cost function (shaft power) through comprehensive analysis, with and without the structural update option. Comprehensive analysis takes into account the elasticity of the blade and therefore, the aerodynamic performance depends on the mechanical properties of the blade.

Chord optimization with structural data update

The parametrization is defined by 10 Bezier poles spread from r/R=0.30 to r/R=1.0.

Thrust-weighted iso-solidity is maintained. Fig. 11 shows a planform view of the reference blade and the optimized blades with and without updating the structural properties. The optimization without structural update reduces rotor power by 1.56% and features a 40% chord reduction around r/R=0.50. If structural stiffness update is considered for such a chord reduction, the result is a decrease of torsional stiffness GJ as shown in Fig. 12. A torsionally softer than designed blade turns into greater elastic twist than intended, which in turn drives aerodynamic angles of attack off-design. As a result, aerodynamic performance is degraded. When the optimized-without-update blade is evaluated with an updated structure, rotor power increases by 11.8% with respect to reference. Maximum elastic twist of this rotor surges to -14.7deg (nose down) at azimuth 225deg, whereas the rotor without structural update had a maximum elastic twist of -4.88deg at azimuth 175deg. This explains why, when the structural update is activated in the optimization, the optimal chord distribution (Fig. 11) is closer to the reference chord than when not considering structural update. However, the reduction in rotor power of the chord optimization with structural update is smaller: 0.22%, compared to the 1.56% of the optimization without structural update.

Rigid blade comprehensive calculations predict a rotor power reduction of +1.3% for both optimized rotors with respect to the reference rotor in rigid blade modelling. This

shows that a part of the power reduction is exclusively due to aerodynamic shape.

An alternative solution could be to optimize the blade twist simultaneously with the chord distribution, which is actually a means to link the blade deflected shape to its jig shape. This would allow investigating a larger design space for chord distribution while using the structural data update.

Sweep optimization with structural data update

The parametrization is defined by 6 Spline 1 control points spread from r/R=0.50 to r/R=1.0. Fig. 13 compares the obtained blade planforms depending on whether the structural update was activated or not during the evolutionary optimization. Like in the case of the chord optimization, the update of the structural data has resulted in an optimal planform which has a smoother shape than the optimal planform without structural update. In terms of power, the optimization without structural update reduces power by 4.2%, whereas with structural update power is reduced by 3.3%.

It was attempted to evaluate by comprehensive analysis the sweep distribution obtained after an optimization without structural update, although estimating the structural properties corresponding to the new optimum shape. The comprehensive code 1 Splines are here preferred to Bezier because, as opposed to chord parametrisation where chord variations are defined as positive fractions of a reference chord, sweep may combine positive and negative values. In that case, Bezier control points may take large values (which must be then allowed in the design space), whereas splines pass through the control points that are the optimization parameters.

failed to converge for the soft blade computation. However, rigid blade computations predicted identical power for the reference rotor and optimum without structural update rotor. This reveals that the reductions in rotor power are not achieved due to compressible flow alleviation by sweep, but rather to aeroelastic effects; displacing the blade forward contributes to displacing the aerodynamic lift forward of the pitch axis, which contributes to cancelling the nose-down elastic twist. Thus, both optimized planforms undergo smaller torsion amplitudes than the reference blade, which allows them to keep an actual twist distribution closer to the reference geometric twist.

An aeroelastic stability analysis would have probably ruled out forward-swept blades because forward sweep favors static divergence, but stability has not been considered here. As a step towards more feasible blade shape designs, a fast, low-cost, method for structural data update has been developed and implemented in a shape optimization procedure. This method is based on functions obtained by polynomial fitting on the results of a 2D finite-element model of a typical, sandwich technology, blade crosssection, which was solved for several relative thicknesses. Accounting for changes in structural properties helps eliminate those optimization specimens that are structurally unrealistic. Optimal shapes tend to be smoothened compared to the optimal shapes obtained without structural update.

Conclusions

The method has proved its capacity to provide useful estimations of structural properties on a validation exercise using two real blades of known properties. Future

  blade, based on a double-swept blade planform (Ref. 7). In the same way, since 1975, the different phases of the British Experimental Rotor Programme (BERP (Refs. 8, 9)) led to the design of an optimized rotor blade (especially the blade tip) with increased hover and forward flight performance and reduced vibration. Successive technologies based on materials selection and structural and manufacturing constraints were successfully demonstrated on AgustaWestland helicopters. Several works on optimization methodologies for helicopter rotor blade planforms have been performed at NASA since the 1980's, dealing with multi-objective optimization procedures, relative to the aerodynamics, dynamics, and structure disciplines (Ref. 10). For instance, an integrated aerodynamic/dynamic/structural procedure (Ref. 11) has been developed, split into two level analysis, with the upper level concerning the blade design on performance, dynamic and global structural measures, and the lower level concerning the structure optimization through the required stiffness.

  can also be obtained analytically, because of the linearization of the differential equations (Euler, Navier-Stokes) modeling the flow. The formulation of the discrete steady adjoint of the Reynolds-Averaged Navier-Stokes (RANS) equations has allowed efficient use of gradient based algorithms and high fidelity models to obtain an aerodynamic shape design of a helicopter rotor blade in hover (Ref.[START_REF] Dumont | Aerodynamic Shape Optimization of Hovering Rotors Using a Discrete Adjoint of the Reynolds-Averaged Navier-Stokes Equations[END_REF]). In the field of civil aircraft wing optimization, an aero-structural adjoint method has been developed, allowing the improvement of both aerodynamic (planform parameters) and structural functions (internal structural element thicknesses and structural characteristics flexibility) in the same design space (Ref. 14). The adjoint formulations become more complex for optimization in forward flight. These formulations require either considering the problem as periodic, or solving the unsteady adjoint equation backwards in time. Moreover, aerodynamics and structural dynamics are largely coupled in forward flight, and fluidstructure interactions need to be taken into account (Ref. 15).

  [START_REF] Benoit | HOST, a General Helicopter Simulation Tool for Germany and France[END_REF], developed by Airbus Helicopters. The aerodynamics of HOST is based on a lifting line approach based on airfoil look-up tables. Different options and corrections (sweep effect, stall correction, unsteady Theodorsen pitching moment coefficient, curvature effect ...) can be activated to improve the aerodynamic calculation. Different inflow velocities models are available in the HOST code. In particular, the METAR code (Ref.[START_REF] Arnaud | Validation of R85/METAR on the Puma RAE Flight Tests[END_REF]

The

  CFD elsA code (Ref.[START_REF] Cambier | The Onera elsA CFD software: input from research and feedback from industry[END_REF]), developed at ONERA, solves the three-dimensional URANS (Unsteady Reynolds-Averaged Navier-Stokes) equations for both background Cartesian grids and blade curvilinear grids. The spatial discretization of the equations is performed with Jameson's cell-centered second order scheme, using 2 nd and 4 th order coefficients of artificial viscosity. The unsteady algorithm corresponds to a backward Euler scheme, with an implicit Gear scheme for the 2 nd -order time integration. The time step is equivalent to 1.2° of blade rotation. Turbulence is taken into account by the Kok k-ω model, with SST corrections (Ref. 30) and Zheng limiter (Ref. 31). The flow is modeled as be fully turbulent. In the 1990's, ONERA developed an aeroacoustic computational chain, called HMMAP, to predict the radiation noise emitted by a helicopter, especially in descent flight, for Blade Vortex Interaction (BVI) noise prediction. This tool has been successfully used for the definition of an optimized aero-acoustic rotor, in the ERATO program (Ref. 6), and validated by wind-tunnel experimental data. In this study, the HMMAP chain is used to analyze the effects, in descent flight, of the optimized twist and anhedral laws (designed for a level flight condition) on the prediction of blade-vortex interaction noise level. This computational chain is divided into 5 steps (Ref. 32). After the trim calculation by HOST, a full-span free-wake model developed in the MESIR code (Ref. 33) is used to compute the velocities induced by all trailed and shed vortex lattices at each discretisation point of the wake using the Biot -Savart law. Then, the following acoustic steps are performed with the roll-up model performed by the MENTHE code (Ref. 34), the blade pressure computed by the unsteady singularity-based potential theory method ARHIS (Ref. 35), and the noise radiation performed by the PARIS code (Ref. 36) based on the Ffowcs Williams and Hawkings equations.

38 ).

 38 The near-body multiblock curvilinear O-grids are built around each blade.. The total number of cells is equal to 1.7 million per blade. A Cartesian grid is automatically generated around the near-body grids with 5 levels of refinement. The finest grid extent is 3R in the radial and in the normal directions. The grid size of the finest grid is equal to 14% of chord length. The Cartesian grid contains a total of 13 million cells. Chimera technique is then involved in order to interpolate the solution between blade and Cartesian overlapping grids.The performance of the reference and the twist optimized rotors are evaluated with the HOST and the coupled HOST/elsA codes, for the following flight configuration: C T /σ=0.075, V h =140kts, Ω=347.21 rpm (µ=0.36), (CxS) f /Sσ=0.15.

Fig. 10 compares

 10 Fig. 10 compares some of 7AD's actual structural properties (labelled 'Data 7AD')

  Recent optimization work performed at ONERA, in the framework of the European Research Program Clean Sky, as part of the Integrated Technology Demonstrator "Green Rotorcraft 1 -Innovative Rotor Blades", has been presented in this paper. The first topic concerns the aerodynamic and aero-acoustic evaluations of the reference and shape optimized rotors in twist and anhedral. The objective is the minimization of the shaft power consumed by the main rotor, evaluated during the optimization procedure by a comprehensive code (low CPU cost), at a single-point forward flight configuration. Significant power reduction is predicted in forward flight, at the end of the optimization procedure and by a posteriori computations: (a) around 4% predicted by comprehensive analysis and (b) around 3% predicted by CFD-CSD loose coupling. In both types of computations, the main origin of the power reduction comes from a large reduction of the lifting loads in the inner part of the advancing part of the rotor. It would be interesting in future studies to take into account the effect of three-dimensional unsteady effects of the flow through multi-fidelity surrogate models. Then, a posteriori computations have been conducted to predict the performance in hover, and the level of blade-vortex interaction noise in descent flight. It clearly appears that the twist law, optimized for a forward flight configuration, is not well adapted either to hover or to descent flight: (a) 2.7 points on the maximum figure of merit in hover and (b) up to +8 dB in descent flight. This study clearly shows the interest to perform multi-point optimization procedures, to take into account different aerodynamic, and/or acoustic or aero-elastic behaviors of the blade.

12 .Fig. 1 .Fig. 2 .

 1212 Fig. 1. Planform of the reference blade

Fig. 3 .

 3 Fig. 3. Distribution of the difference of induced and profile powers between the

Fig. 4 .Fig. 5 .Fig. 6 .Fig. 7 .Fig. 8 .Fig. 9 .

 456789 Fig. 4. Flight domain of the reference and the optimized rotors predicted at V h =140kts

Fig. 10 .

 10 Fig. 10. Estimated vs. actual structural properties of 7AD blade.

Fig. 11 .

 11 Fig. 11. Comparison of the output of a chord distribution optimization when the structural update

Fig. 12 .

 12 Fig. 12. Blade torsional stiffness. Blue solid line: original blade property. Red dotted line: torsional stiffness that would be deduced from the chord obtained in the optimization without structural update.

Fig. 13 .

 13 Fig. 13. Comparison of the output of a sweep distribution optimization when the structural update is considered.

Acknowledgments

The authors would like to acknowledge the European Commission for partly funding this work through the Clean Sky Joint Technology Initiative.


Houssem Chihoub
email: houssem.chihoub@imag.fr

Christine Collet
email: christine.collet@grenoble-inp.fr

iBig Hybrid Architecture for Energy IoT: When the power of Indexing meets Big Data Processing!

Nowadays, IoT data come from multiple sources and a large number of devices. To manage them, IoT frameworks rely on Big Data ecosystems hosted in the cloud to provide scalable storage systems and to achieve scalable processing. Although these ecosystems scale well to process large sizes of data, in many cases this is done naively. Many datasets, such as IoT Energy measurement data, consist, even partially, of attributes that can be indexed to avoid unnecessary and costly data scan at these scales. In this work, we propose the iBig architecture that provides secondary indexing to Big Data processing for energy IoT datasets. Indexes are considered as metadata stored in a separate component integrated in the ecosystem. Subsequently, MapReduce-based and MPP (massively parallel processing)based processing leverage indexing to handle only relevant data in a given dataset. Our experimental evaluation on the Grid5000 cloud testbed demonstrates that performance gains can exceed 98% for the MapReduce-based Spark and 81% for the MPPbased Drill for Energy IoT Data. Furthermore, we provide comparison insights about the Spark and Drill frameworks when processing the whole dataset or only with relevant data.

I. INTRODUCTION

In the digital world we live today, the number of connected devices is exploding. Gartner says that 8.4 Billion connected things will be in use in 2017, which is 31% increase from 2016 [START_REF]Gartner says 8.4 billion connected "things[END_REF]. A typical case of large-scale IoT application can be found within energy utilities. In their efforts to transform power grids into smart grids, utilities rely on massive deployments of sensors and smart meters at the scale of a country or even a continent. For instance, in France Enedis has an on-going plan to deploy 35 million smart meters by the year 2021 [START_REF]Linky, le compteur communicant d'erdf[END_REF]. In this context, more and more IoT data are collected providing fine grain insights about client consumption profiles and the behavior of the power grid. These IoT data are critical towards more efficient management of energy resources and provides new levels of efficiency for business applications. However, the frequency in which data are generated and collected from millions of sensors and smart meters makes the task of data management and processing very complex. This complexity is due to the huge volumes of data collected and stored over long periods of time, as well as the performance requirements on accessing and processing them.

In order to deal with tremendous volumes of IoT data and cope with its challenges, energy utilities have started to rely on Big Data ecosystems for scalable storage and processing.

In these ecosystems, data are stored, typically, under almost any formats, structured, semi-structured, and unstructured on a distributed file system or a cloud storage system. In contrast, data processing is based primarily on the MapReduce programming model [START_REF] Dean | Mapreduce: Simplified data processing on large clusters[END_REF]. Since early MapReduce frameworks [START_REF] Dean | Mapreduce: Simplified data processing on large clusters[END_REF] [START_REF]Apache hadoop[END_REF], remarkable efforts were carried out to provide an even more scalable and efficient data processing. Recently, a new generation of faster in-memory processing frameworks with richer programming APIs have emerged, such as Spark [START_REF]Apache spark[END_REF] and Flink [START_REF]Apache flink[END_REF]. More recently, in an attempt to lower analytical processing latency, Massively Parallel Processing (MPP) models -that favor independent processisng where computation are moved to data rather than the opposite-were revisited in this context. Subsequently, a new class of Big Data processing engines such as Apache Drill [START_REF]Apache drill[END_REF], Google Dremel/BigQuery [START_REF] Melnik | Dremel: Interactive analysis of web-scale datasets[END_REF], and Presto [START_REF]Presto: Distributed sql query engine for big data[END_REF] have been rising to challenge MapReduce systems.

Most of the aforementioned Big Data processing frameworks scale out with large datasets stored on distributed file systems, specifically with exploratory analytics that need to scan the entire data. In contrast, data search and scan can be extremely costly over large datasets, in particular if it is not necessary. For instance, we consider the case of IoT measurement data. Many queries over measurement data are selective where only a subset of data is needed for processing. However, within todays' frameworks all the files or objects in a given dataset need to be scanned to filter data, hence incurring significant delays considering Big Data sizes. In this work, we propose the new iBig hybrid architecture. The primary goal is to provide secondary indexing to energy IoT Big Data processing. To this end, we introduce a new architecture managed exclusively by a new component where the indexing metadata is separated from storage and processing. Upon request, the indexing component provides a relevant selection of files that can be used to push down filtering prior to data processing and thus, reduce data scan cost. Furthermore, we provide an efficiency study of indexing in the proposed architecture for various distributed processing models.

The following is a summary of our contributions.

• Design of the new iBig hybrid architecture that combines Big Data processing frameworks with indexing for Energy IoT data management. Indexing is provided as metadata stored in an independent component added to the ecosystem. • Study of indexing efficiency in the proposed architecture. This is a very important step to understand when to use indexing and to provide scale-out properties. • Thorough experimental evaluation to measure the new architecture gains for an energy IoT benchmark. • Fair experimental comparison of a Map Reduce system and an MPP system where both share the same underlying storage environment. The remaining of this paper will be is organized as follows. Section II introduces the iBig architecture and Section III details its main aspects. Section IV presents the methodology we develop. The evaluation of our architectures is extensively discussed in Section V. Sections VI and VII give an overview of related work and sum up our conclusions respectively.

II. IBIG ARCHITECTURE DESIGN

Figure 1 demonstrates the general design of our architecture. Datasets are, generally, stored in files under directories in a distributed file system (HDFS in this particular setup). Data processing can be carried on either Spark, a next-generation of MapReduce computation framework or Apache Drill an MPP framework. Both processing frameworks can operate on the same dataset stored in HDFS. This configuration is current within many organizations. In our iBig architecture, we introduce a new component that provides indexes as metadata about datasets. For both Spark and Drill, a new library is designed to allow users and developers to specify filters on indexed attributes in the dataset prior to loading and processing data in either framework. The library calls result in a subset of files (file selection) that contain at least an element of relevant data needed for further processing, whereas the other files are filtered out. This in turn, reduces the wasted efforts of scanning and processing the latters. The indexes on selected attributes are built in B-Trees [START_REF] Bayer | Organization and maintenance of large ordered indexes[END_REF] that provide a search complexity of log(N) with N being the size of the dataset. Henceforth, providing the opportunity for important gains considering that sizes in the era of Big Data are very "Big". For instance, searching measurements in log(N) time from trillions of energy IoT measurements can reduce processing times by order of magnitude for selective queries.

The indexing component hosts index data along a map that determines which data belongs to which file. Upon request the index is scanned in order to build a file selection to return to the processing component. The file selection is further used either within Spark or Drill for processing. In our architecture we do not store the split index of attributes inside files to preserve the efficiency of indexing in the architecture as demonstrated in Section III-C. The component that provides file selection based on index data is built using MongoDB [START_REF]Mongodb[END_REF]. This choice was motivated by the fact that MongoDB provides built-in indexes (including secondary and spatial ones), has a flexible document data model, and scales-out with data sharding supported at the system level with local indexing.

MapReduce Vs. MPP

The efficiency of indexing in the proposed architecture is reliant on the big data processing model and distribution among other factors. In recent years, two paradigms of Big Data processing have gained large merits: MapReduce and Massively parallel processing (MPP). MapReduce was rediscovered at Google as an efficient programming model to distributed Big Data processing [START_REF] Dean | Mapreduce: Simplified data processing on large clusters[END_REF]. Inspired by divide and conquer, it consists of defining a Map phase to decompose a big problem into a set of small sub problems and a Reduce phase to address the small subproblems. In between, a Shuffle phase to redistribute data to their respective mappers is performed. The Shuffle relies, generally on a sort algorithm or a hash algorithm and can be costly in terms of performance due to random data transfer. Thanks to the Hadoop implementation [START_REF]Apache hadoop[END_REF], the MapReduce model has been widely adopted. Lately, Spark [START_REF] Zaharia | Spark: Cluster computing with working sets[END_REF], a new generation of in-memory MapReduce processing with richer and friendlier programming API, has emerged to be the most popular framework.

More recently, many efforts to provide low-latency SQLlike processing of Big Data have revisited the Massively Parallel Processing (MPP) model. This latter has written the success story of shared-nothing distributed database management systems. In contrast to MapReduce, MPP consists of moving computation to data rather than data to CPU thus, enhancing data locality. This is achieved relying partly on costbased opitmizations implemented with MPP systems. This way, many processors can process data locally, transferring their intermediate results only when necessary. Nowadays, many systems such as Apache Drill [START_REF]Apache drill[END_REF] and Presto [START_REF]Presto: Distributed sql query engine for big data[END_REF] adopt MPP and are integrated efficiently into the Hadoop ecosystem.

In many aspects, MapReduce and MPP share the same approach consisting of divide and conquer to provide scalable processing of large and voluminous datasets. However, these two paradigms diverge on how to divide the initial problem. MapReduce frameworks fully focus on exploiting the computation and CPU power of the underlying infrastructure even if it implies redistributing data at the cost of additional delays. In contrast, MPP frameworks focus on data locality (to amortize the delay impact of redistributing data) where in many type of processing the load is not fully balanced and the CPU power is not leveraged to its fullest. As a result, the efficiency of indexing in the iBig architecture can vary according to the processing model and the impact of either data transfer or load unbalancing, as it will be demonstrated later on.

III. IBIG COMPONENTS AND EFFICIENCY

A. Data Processing

Our iBig architecture supports two processing models: MapReduce provided by Spark and MPP provided by Drill.

Spark: Spark is implemented in the Scala language and provides a rich programming API to users. Within this API, operations are divided into a set of transformations, which are specific Map functions and a set of actions that are specific Reduce functions. Spark API in addition, is very powerful to express iterative operations. To facilitate data manipulation, Spark introduces the abstraction of resilient distributed datasets (RDDs), an in-memory read-only collections of objects partitioned across a set of machines that can be recovered in case of failures. Data must be loaded to RDDs prior to processing. Within Spark, the Spark SQL [START_REF] Armbrust | Spark sql: Relational data processing in spark[END_REF] module provides an SQL query engine that generates Spark tasks for SQL statements. Spark SQL relies on the introduced DataFrame API to store data in a columnar layout in memory and perform relational operations on both external data sources and spark built-in collections.

Drill: Apache Drill [START_REF]Apache drill[END_REF] is an open-source Big Data SQL query engine that is open-source and can be integrated in the Hadoop ecosystem. It was partly inspired by Google Dremel [START_REF] Melnik | Dremel: Interactive analysis of web-scale datasets[END_REF]. It implements an MPP model to process data coming from different datastores including file systems (with various file formats), NoSQL datastores, and relational systems. Drill supports nested document data model, and like Google Dremel converts nested data into flatten columnar formats for in-memory internal execution. Moreover, Drill relies on cost-based and rule-based optimizations to generate optimal locality-aware execution plans. Although, Drill provides SQL query processing as the only language support, it allows developers to write User Defined Functions (UDFs) in order to customize and develop their own specific functions and computations.

B. Data Indexing

Our indexing component is hosted entirely on MongoDB. MongoDB: MongoDB [START_REF]Mongodb[END_REF] is an open-source document datastore. It stores data in a BSON (JSON-Like) document data model to provide flexibility and easier evolution of data structure. MongoDB is a distributed system by design and supports built-in data sharding to provide scale-out properties. Moreover, MongoDB supports a wide range of indexes for a faster data search. The achieved performance and scalability together with secondary indexes support makes MongoDB the ideal candidate to host our indexing component. Indexed attributes are stored in a document collection with their mapped file names and if necessary the row key from the dataset. Secondary indexes are then built within MongoDB on corresponding attributes (fields in MongoDB). With sharding in MongoDB, indexes are local to shards. This allows a parallel scan of indexes, which can improve efficiency as shown in the next section. This latter property is key to provide efficient indexing in a scale-out architecture.

When new files are to be ingested into HDFS, updating the index data on them is necessary before it is possible to use indexing. Data ingestion processes rely generally on either streaming or loading batches that put data in immutable files in a data lake or an OLAP system (unlike transnational systems). Until new data files are indexed, queries must scan all data.

C. Indexing Efficiency

Indexing data in our architecture can potentially provide large gains, as with IoT data for instance. However, relying on indexing has an overhead. The overhead for some types of processing can be so important and results in worse performance. A typical case would be for queries that need to process the whole data. For instance, aggregations on the entire dataset. In such a case, the execution time would consist of the indexing overhead in addition to the original execution time of the query (without indexing). To study the efficiency of indexing in the iBig architecture, we model its potential gains. To this end, we consider a dataset S with a size |S|. Since the same type of processing is applied with or without indexing, the main difference relies within scanning and filtering data. Accordingly, we define the efficiency in Formula 1 as proportional to the fraction of the response time of index scan added to the resulting filtered data scan, and the response time of scanning of all data.

Ef f = 1 - T scan (Index) + T scan (F ilteredData) T scan (AllData) (1)
The scan time is proportional to both the data size and the number of nodes that data are distributed across. In the following, we assume an uniform distribution and partitioning of data across nodes in the cluster. Subsequently, we define the efficiency in Formula 2 where N idx is the number of nodes on which index data are distributed (a.k.a MongoDB). Similarly, N proc is the number of nodes on which the dataset is distributed that is the number of datanodes in HDFS. Moreover, S sel is the set of selected data after indexing, i.e. the data to be scanned in the indexing component in order to build the file selection. Finally, F sel is the file selection that results from indexing and |f | is the average size of files. It is noteworthy to observe that |F sel | × |f | ≥ |S sel | and that these two sizes that determine the most the efficiency of indexing.

Ef f = 1 - log( S N idx ) + |S sel | N idx + |F sel |×|f | Nproc |S| Nproc (2)
After simplification, the result is shown in Formula 3.

Ef f = 1 - Nproc × log( S N idx ) + Nproc×|S sel | N idx + |F sel | × |f | |S| (3)
The Efficiency metric Ef f can determine whether the query would benefit from indexing or not. If Ef f < 0, then indexing should not be used because it would result in a slower

Ef f = 1 - Tscan(Index + F ilteredData) + Tpartition(F ilteredData) + Tmscan(F ilteredData) Tscan(AllData) + Tpartition(AllData) + Tmscan(AllData) (4)
Ef f = 1 -

Tscan(log( S N idx ) + |S sel | N idx + |F sel |×|f | Nproc ) + Tpartition(|F sel | × |f |) + Tmscan( |F sel |×|f | Nproc ) Tscan( |S| Nproc ) + Tpartition(|S|) + Tmscan( |S| Nproc ) (5)
execution time. Efficiency estimation can be computed relying on collected statistics about the dataset. These statistics can be stored in histograms to provide estimated values of the parameters described above for a given query at runtime. Efficiency with Spark. The previous efficiency estimation is applicable with general architectures where data are fetched from the filesystem, then filtered before in-memory internal execution. This is true for Apache Drill as well. However, with Spark the approach is quite different and the efficiency estimation is more complicated. In fact, in Spark processing, the dataset is first uploaded to an RDD, a DataFrame, or DataSet, which are all in-memory collections of data. Upon loading time, data are partitioned across the Spark nodes, then processing starts from this point further, including particularly data filtering. For this reason, data indexing has even greater potential. With indexing in our architecture, much of data filtering is done prior to loading data to spark. Therefore, the effort needed to partition data in spark is reduced accordingly along with data scan from memory. As a result, the Efficiency is given by Formula 4 where T scan is the data scan time from the filesystem, T partition the time needed to partition data in spark, and T mscan is the scan time from memory.

Furthermore, the efficiency metric, given by Formula 5, can be computed based on estimating sizes of filtered data.

To further simplify the previous formula, an estimation of the cost of partitioning data in spark should be developed. It should include the implied data transfer and data scan in distributed memory as opposed to disks from the filesystem. The main difficulty resides in the fact it is difficult to provide a relative cost between scanning data from disk, scanning data from memory, and transferring data.

IV. EXPERIMENTAL METHODOLOGY

A. iBig Implementation

We have designed a Python-based tool to integrate our indexing component with the data processing frameworks Spark and Drill. In this context, a library that allows users to specify filters on indexed attributes is available. Based on this filter, MongoDB is solicited relying on the PyMongo driver to provide the file selection of relevant data to be loaded to a Spark DataFrame. For this purpose, we use PySpark to execute queries. With Drill, our approach is different. Drill SQL-based syntax considers a file name or a file directory as a table name. Hence, providing multiple file names does not comply with its syntax. To overcome this issue, we use Drill RESTful API to generate physical plans for our queries. We thereafter, inject the indexed file selection into the JSON representation of the physical plan. The plan is then submitted for execution.

B. Data Generation

For privacy reasons, it has not been possible for us to get real smart meter and IoT data from energy utilities. Fortunately, it was possible to generate realistic datasets that illustrate meter data as described in [START_REF] Liu | Benchmarking smart meter data analytics[END_REF]. In a previous work [START_REF] Chihoub | A scalability comparison study of data management approaches for smart metering systems[END_REF], we have used the authors approach to create our meter dataset. Accordingly, We generate meter data for 50000 meters over a period of one year with a measurement every one hour and a total of 438 million measurements.

C. Benchmarking

Meter data are used for multiple purposes in the smart (power) grid: bill computations, consumption analysis, power generation forecasting, fraud detection etc. Most of these services and applications exhibit three types of meter data processing queries as shown in [START_REF]Using the hp vertica analytics platform to manage massive volumes of smart meter data[END_REF]: aggregation queries, selection and filtering based on some predicates (e.g. to filter based on a consumption threshold), and bill computation queries that exhibit the most complex processing for meter data management systems [START_REF]Using the hp vertica analytics platform to manage massive volumes of smart meter data[END_REF]. In this context, we introduce seven [START_REF]Apache drill[END_REF] queries that illustrate processing types on meter data. The queries are summarized in Table I.

D. Setup

We run our experiments on Grid5000 cloud and grid testbed [START_REF] Jégou | Grid'5000: a large scale and highly reconfigurable experimental grid testbed[END_REF] in France. We use up to 16 nodes in the Parasilo cluster located in the Rennes site. All nodes are equipped with 2 Intel Xeon E5 CPUs having 8 cores each and 2.4GHz speed. Every node has memory size of 128GB and a Hard Drive Disk of 600GB used in our experiments. The nodes are interconnected relying on two 10 Gigabit Ethernet links. Our deployments rely on HDFS within Cloudera CDH-5.2.3 distribution, Spark-2.1.0, Apache Drill-1.9, and MongoDB-3.2.11. MongoDB is deployed on only one node co-located with HDFS datanode, and either a Spark Slave or a Drillbit (drill processor). In our dataset, two attributes are indexed: the measurement attribute, a measurement value about client consumption read from a meter, and the meter id attribute, which is a unique id for a given smart meter. Beforehand, indexes data are loaded to MongoDB. Thereafter, the BTree-based secondary indexes on both measurement and meter id are built in approximately 1350 seconds for the first, and 880 seconds for the second.

Query Description

Query1 Sum of all measurements (consumption of all meters) for a range of 300 meters (over 1 year data) Query2 same as Query1 but for a range of 1200 meters Query3 Sum of measurements for a range of 300 meters in a 2-month time interval Query4 Selection of rows based on a highly restrictive consumption threshold, sorted by their meter ids Query5 Selection of rows based on a wider consumption threshold for a range of 2000 meters, all sorted by their meter ids Query6 Compute the bill for a given client (meter) following the tarif blue billing rules of EDF (power vendor) Query7 Compute the bill for 300 clients (meters) following the tarif blue billing rules of EDF(power vendor) In Figure 2, we show the response time for both Spark and Drill with and without indexing in the iBig architecture. As depicted, our indexing solution reduces considerably the response time achieving high levels of efficiency, in particular for Spark. In fact, Spark with indexing exhibits comparable latency to Drill (with and without indexing), which is due to large gains in our architecture. Furthermore, with bill queries, Query6 and Query7 (Figures 2f and2f respectively) indexing makes Spark extremely fast. However, with Query4 (depicted in Figure 2d), even indexing can not make Spark at the same level as Drill. In fact, data transfer both at partitioning time and in intermediate phases, in particular with the sort clause, introduces important delays with regard to the file selection of relevant data at input. Another observation is that Drill can rapidly become faster than indexing with added nodes in the cluster, and that when queries have wide filters on the indexed attribute. This is true for instance, with Query2 (in Figure 2b) when the number of nodes increases beyond 8 nodes because of the wide data selection of its filter. Obviously, one solution is to increase the number of nodes for the indexing component for higher efficiency as shown in Section III-C.

An additional important result, is the exhibited performance of Spark in comparison to Drill. For all queries, Drill is order of magnitude faster (e.g. 97% faster with Query5). Both systems are written in Java and implement an optimized columnar in-memory execution (with DataFrames in Spark) and vectorization. Drill is much faster, since it is data localityaware with its MPP model, which in turn, reduces significantly data transfer in intermediate phases. Furthermore, data transfer delay dominates the gained CPU power in Spark. Prior to processing, data are first uploaded to a DataFrame, an inmemory distributed and structured collection of data. When reading data from files, the entire dataset is uploaded and then partitioned across Spark nodes, which can incur significant and unnecessary data transfer along with the useless data scan.

Zoom on indexing gain: In this section, we further zoom on the efficiency of indexing in our architecture and the gains obtained with both Spark and Drill. Figure 3 depicts the gains with the aggregation queries Query1 and Query4. Spark gains for Query1 exceed 98% no matter the number of nodes in the cluster. Such extraordinary efficiency is due to the fact that with indexing, most of irrelevant data are filtered out before loading data to memory. As a result, the data scan and partitioning time in Spark is negligible with selected data compared to the entire dataset. The data size to be scanned in memory is also significantly reduced. Gains are less important with Drill because it was already fast and filters data at source before loading them to memory. Despite this, indexing with Drill in our architecture, has allowed Query1 to save from 12% of processing time when the number of nodes is 16 to 79% when the number of nodes is 4 as demonstrated in Figure 3a.

The gains exhibited with Query4 are quite different. Query4 is a selection and filtering query with a sort clause that leverages indexing in our architecture on the measurement attribute. Indexing with Spark achieves between 41% and 49% gains. With Drill however, the gains are 31% and 21% when the number of nodes is 4 and 8 respectively. Indexing with Drill becomes inefficient beyond this number of nodes in this setup. The cause for Spark Gains drop in this case, lies within the measurement attribute. Measurement values are not unique and are not ordered. This implies that values in a given range have a great probability to be contained in a large number of files. Therefore, the file selection (files that contains at least one element necessary for processing) can be bigger than other attributes such as meter id. This in turn, reduces the gains. Within iBig, we can make Drill (that is already fast) more efficient with 12 and 16 nodes by adding more nodes to the indexing component hosted on MongoDB.

For Bill queries Query6 and Query7 shown in Figure 4, the gains are huge with Spark mainly because the selected data after indexing are very small compared to the entire dataset. Furthermore, Bill queries are scheduled as two spark jobs executed sequentially. This can be very costly when scanning the entire dataset. In turn, with indexing, the gains are multiplied since only the small selected data are scanned and processed. It is noteworthy also, to observe that index time is quite small for Query6 (shown in Figures 4a and4b) since the query computes the bill for only one given client indexed on the meter id attribute. In contrast, the gains with Drill are less important, in particular when the number of nodes in the cluster increases. For instance, the gains are 41% and 43% when nodes number is 4 for Query6 and Query7, whereas only 11% gains are observed with Query6. Indexing becomes inefficient with Query7 beyond 16 nodes. The exhibited behavior of these queries is because Drill scales out well in this setup with the entire data, in particular, with the current distribution of the dataset across HDFS datanodes but not with the filtered data. Bill queries are CPU-intensive and require minimal data transfer. Drill however processes data locally, and therefore will use CPUs only in the nodes that contains data. This results of load unbalancing with filtered data that are not usually uniformly distributed across the cluster depending on filtering conditions.

B. Indexed Spark vs. Indexed Drill

In Figure 5, we focus on the response time exhibited by both Spark and Drill and this only for the set of files that contain relevant data for the respective processing (i.e. after index-based filtering but without accounting for index scan). Compared to the result demonstrated in the previous Section, the first observation is that spark response time is close to that of Drill and in many times even faster. This is due to minimizing the impact of scanning the whole data and partitioning them in-memory. For aggregation queries Query1, Query2, and Query3 (Figures 5a,5b, and 5c respectively), Spark outperforms Drill in most cases, but not by much. For instance, Spark is 76% faster with Query1 when the number of nodes is 16, but only 1% faster with Query3 for 8 nodessized cluster and even 6 % slower with Query2 for 16 nodessized cluster. Two reasons cause this behavior: First, Drill relies on cost-based optimization, which can take hundreds to thousands milliseconds. With such fast response time with filtered data, the overhead introduces noticeable overweight. Secondly, unlike Spark that partitions data before processing to achieve load balancing, Drill is locality-aware and processes data on the node it stores it. Subsequently, this can unbalance the processing load between nodes because filtered data at input is located on a subset of nodes (since data are ordered and partitioned into files on the meter id attribute in this case). This latter reason explains as well why Drill does not scale out with filtered data as it did with the entire dataset. In fact, increasing the number of Drill processors increases the coordination overhead while the added processing power is not really needed. The most interesting results however, are demonstrated by the selection and filtering queries with a sort clause (Query4 and Query5 shown in Figures 5d and5e respectively), which are queries that incur heavy data transfer, and the Bill queries (Query6 and Query7 shown in Figures 5f and5g respectively), which are CPU-intensive queries with very little need for data transfer. The results clearly show that spark excels with the CPU-intensive Bill computation whereas Drill is similarly suited for data transfer-heavy processing. Drill is up to 90% faster than Spark with Query4 and up to 76% faster with Query5. In contrast, Spark can outperform Drill by 98% with Query6 and 84% with Query7. Spark is more suited to CPU-intensive queries because it partitions data in memory across the cluster nodes. This would allow better load balancing, which in turn exploits the computing power in Fig. 5: indexed Spark Vs indexed Drill the cluster to its fullest, but at the cost of data transfer, thus exposing data processing to the network latency. In contrast, Drill, with its MPP model, favors locality-aware processing where computations are sent to data, rather than the opposite. When data does not span across the entire cluster however, computing power is under used, which can prove costly with CPU-intensive processing. We argue that a lot of improvement can be achieved in this area to provide the most relevant model according to the nature of processing and queries.

VI. RELATED WORK

Although indexing structures have been around for many years, in particular to speed up data access in relational database systems, it is only recently they started to be integrated in Big Data Ecosystems. Hadoop vendors have integrated search services within their Hadoop distributions mostly to search and index text. Their solutions are based on either Elasticsearch [START_REF]Elasticsearch[END_REF] or Solr [START_REF]Apache solr[END_REF]. Additional file text and split indexing approaches for Hadoop are proposed in [START_REF] Li | Leveraging a scalable row store to build a distributed text index[END_REF] and [START_REF] Eltabakh | Eagle-eyed elephant: Split-oriented indexing in hadoop[END_REF]. In [START_REF] Abouzeid | Hadoopdb: An architectural hybrid of mapreduce and dbms technologies for analytical workloads[END_REF], HadoopDB a hybrid architecture that consists of Hive with its SQL-like query execution engine over Hadoop MapReduce and Relational DBMS was introduced. Although indexing is supported within RDBMS, It is used for data within relational tables. In [START_REF] Gankidi | Indexing hdfs data in pdw: Splitting the data from the index[END_REF], the authors propose a hybrid architecture that consists of an RDBMS in addition to Hadoop. They use split indexes per file in HDFS, which might be costly in terms of scan, thus impacting the efficiency of indexing, in particular when the number of processors is large. The architecture is also reliant on the job tracker of the former version of Hadoop MapReduce and is not implemented with Spark. In [START_REF] Guo | Efficient indexing and query processing of model-view sensor data in the cloud[END_REF] and [START_REF] Liu | Dgfindex: A hive multidimensional range index for smart meter big data[END_REF], indexing approaches are proposed for IoT sensors data. The work in [START_REF] Guo | Efficient indexing and query processing of model-view sensor data in the cloud[END_REF], provides novel indexes for key/value stores in the cloud while the work in [START_REF] Liu | Dgfindex: A hive multidimensional range index for smart meter big data[END_REF] proposes an index structure for Apache Hive. The indexing efficiency of most of the aforementioned solutions is limited and hardly discussed. In fact, the amount of information stored for a given index (split indexes) is not negligible. Therefore, index scan can result in important delays for large datasets, which jeopardizes the overall efficiency. Additionally, in these studies horizontal scalability is not considered although it is a very important aspect of Big Data processing. In a different direction, studies in [START_REF] Doan | Evaluating the impact of data placement to spark and scidb with an earth science use case[END_REF] and [START_REF] Chihoub | A scalability comparison study of data management approaches for smart metering systems[END_REF], demonstrate the impact of different underlying storage systems, that adopt different approaches to storing, partitioning, and searching data, on Big Data processing.

Many efforts were dedicated to compare MapReduce against parallel database management systems (PDBMS) that adopt MPP type of processing [START_REF] Stonebraker | Mapreduce and parallel dbmss: Friends or foes?[END_REF], [START_REF] Pavlo | A comparison of approaches to large-scale data analysis[END_REF], [START_REF] Mcclean | A comparison of mapreduce and parallel database management systems[END_REF]. However, those efforts focused mostly on early MapReduce implementations and can be considered as unfair since in MapReduce systems, data storage and data processing are separated, unlike PDBMS. Henceforth, more often than not it is storage optimization that favors PDBMS. In our study however, MapReduce and MPP frameworks are evaluated in the same ecosystem with the same underlying storage architecture, which makes them on par for a fair comparison.

VII. CONCLUSION

Today's Energy IoT platforms rely on Big Data ecosystems to manage and process large datasets of multiple origins. These ecosystems scale very well to large volumes but rely on blind data search and scan from underlying file systems. As a result, all elements in a given dataset are scanned no matter how useful they are. This can be very costly when scanning irrelevant data for selective data processing. In this work, we have introduced the new iBig hybrid Big Data architecture to provide attribute indexing capabilities to IoT Big Data processing through an additional component in the ecosystem. We have demonstrated, through our experimental evaluation on the Grid5000 cloud and grid testbed, the potential of indexing in our architecture where performance gains for Energy IoT data processing can exceed 98% for few of the selective queries. In addition, in this paper, we have provided an extensive comparison between MapReduce and MPP models illustrated by Spark and Drill respectively. Unlike many related work that attempted this comparison in the past, we have relied on fair comparison conditions where both processing models rely on the same storage layout and environment. In a future work, we plan to enrich the indexing component with a wider selection of indexing structures and other kind of datastores and data processing models.

Fig. 1 :

 1 Fig. 1: iBig Hybrid Architecture

Fig. 2 :

 2 Fig. 2: Evaluation of queries in iBig

Fig. 3 :

 3 Fig. 3: Gains with Aggregation Queries

  Fig. 4: Gains with Bill Queries

TABLE I :

 I Processing Queries on meter data

	response time (ms)	50000.00 1.00×10 5 1.50×10 5			Spark Indexed-Spark Dril Indexed-Drill	response time (ms)	1.50×10 5 50000.00 1.00×10 5				Spark Indexed-Spark Dril Indexed-Drill	response time (ms)	3.00×10 5 1.00×10 5 2.00×10 5	Spark Indexed-Spark Dril Indexed-Drill	response time (ms)	3.00×10 5 1.00×10 5 2.00×10 5	Spark Indexed-Spark Dril Indexed-Drill
		0.00							0.00							0.00	0.00
		4	8	1 2	1 6				4	8		1 2	1 6				4	8	1 2	1 6	4	8	1 2	1 6
			number of nodes						number of nodes					number of nodes	number of nodes
			(a) Query 1					(b) Query 2					(c) Query 3	(d) Query 4
			response time (ms)	1.00×10 5 2.00×10 5 3.00×10 5					Spark Indexed-Spark Dril Indexed-Drill	response time (ms)	6.00×10 5 2.00×10 5 4.00×10 5					Spark Indexed-Spark Dril Indexed-Drill	response time (ms)	6.00×10 5 2.00×10 5 4.00×10 5	Spark Indexed-Spark Dril Indexed-Drill
				0.00								0.00					0.00
					4	8	1 2	1 6				4	8	1 2	1 6	4	8	1 2	1 6
						number of nodes						number of nodes	number of nodes
						(e) Query 5						(f) Query 6	(g) Query 7

2.00×10 5 number of nodes response time (ms)

													Spark
													Drill
													(d) Query 4
	response time (ms)	5000.00 10000.00 15000.00	Spark Drill		response time (ms)	25000.00 5000.00 10000.00 15000.00 20000.00			Spark Drill	response time (ms)	30000.00 10000.00 20000.00		Spark Drill
		0.00				0.00					0.00
		4	8	1 2	1 6	4	8	1 2	1 6		4	8	1 2	1 6
			number of nodes			number of nodes				number of nodes
		(e) Query 5			(f) Query 6				(g) Query 7

ACKNOWLEDGMENT

This work has been funded through the Industrial Research Chair Enedis (*) in Smart Grids