Corina Mihut

Claude Descorme

Daniel Duprez

Michael D Amiridis
email: amiridis@engr.sc.edu.

Kinetic and spectroscopic characterization of cluster-derived supported Pt-Au catalysts

Keywords: platinum, gold, synthesis, organometallic clusters, CO adsorption, NO x reduction, propylene oxidation, homoexchange reaction

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Supported bimetallic Pt-Au catalysts are primarily synthesized by impregnation, co-impregnation, and deposition-precipitation methods from individual Pt and Au salts. Phase separation of the two metals and inhomogeneous composition of the resulting bimetallic particles are common problems with this type of catalyst due to the large miscibility gap in the bulk phase between Pt and Au (i.e., between 18 and 97 wt% Pt) (1). Furthermore, the low melting point of Au and, therefore, the increased mobility of the Au atoms at high temperatures results in broad Au particle size distributions and difficulties in stabilizing Au in a small cluster form when these conventional preparation methods are used (2). Such segregation problems can be resolved, at least in principle, by the use of preformed bimetallic cluster precursors, frequently stabilized by organic ligands. Carbonyl-ligated clusters are preferred precursors for heterogeneous catalysts because of the advantage of the easy removal of the carbonyl groups by thermal treatment (3,4). However, there are no known bimetallic Pt-Au clusters exclusively ligated by carbonyl groups. In contrast, there are a few examples of phosphine stabilized bimetallic Au-containing clusters (i.e., [Pt(Au(PPh 3 ) 8 ](NO 3 ) 2 , [Pt(PPh 3 )(AuPPh 3 ) 6 ](NO 3 ) 2 , and [Pt(AuPPh 3 ) 2 (PPh 3 ) 2 ](NO 3 ) 2 ) that have been immobilized and thermally activated on solid supports (5,6). These clusters have high Au content, and the presence of phosphorous in the ligands represents a potential poison for several reactions. Recently, Chandler et al. (7)(8)(9)(10) reported the preparation of a supported Pt-Au catalyst from a cluster precursor that exclusively contains acetylide ligands and they concluded that true bimetallic Pt-Au particles can be formed via this synthetic route. These ligands are easily removable at high temperatures.

In this paper, we followed the same synthetic approach and we compared the cluster-derived catalysts to catalysts having the same nominal composition, which were prepared by incipient wetness impregnation from hexachloroplatinic and tetrachloroauric acids. The structure of these catalysts was characterized by transmission electron microscopy (TEM), hydrogen chemisorption, and Fourier transform infrared spectroscopy of adsorbed 12 CO/ 13 CO mixtures. The chemical activity was probed by kinetic studies of the selective catalytic reduction of NO by propylene, the oxidation of propylene in the absence of NO, and the 16 O/ 18 O homoexchange reaction.

EXPERIMENTAL METHODS

Catalyst Preparation

Monometallic Pt/SiO 2 and Au/SiO 2 catalysts with Pt loadings of 1 or 0.15 wt% and Au loadings of 2 or 0.3% were prepared by incipient wetness impregnation of the SiO 2 support (Davison Syloid 74; calcined overnight at 500 • C prior to impregnation; BET surface area 300 m 2 /g) with aqueous solutions of hexachloroplatinic (H 2 PtCl 6 • xH 2 O, Aldrich) and tetrachloroauric acids (HAuCl 4 • 3H 2 O, Aldrich). Additionally, bimetallic catalysts containing 1 wt% Pt-2 wt% Au or 0.15 wt% Pt-0.3 wt% Au were prepared by co-impregnation (i.e., in this case both precursors were added in the same impregnation solution) using the same support material and precursors. Following impregnation, these catalysts were dried in vacuum for2hat 120 • C and calcined in air for5hat500 • C.

Cluster-derived catalysts were prepared via a wetimpregnation technique by adsorption of the organometallic Pt 2 Au 4 (C≡C t Bu) 8 cluster precursor (11) from hexane solution onto the SiO 2 support (Aldrich Davisil SiO 2 ; calcined overnight at 500 • C prior to impregnation; BET surface area 360 m 2 /g) following the same procedure outlined in previous literature reports (7). The concentration of the cluster solution was adjusted so that the final metal loadings of the bimetallic catalysts obtained were approximately the same as those of the catalysts obtained by co-impregnation. Following impregnation, these catalysts were dried in vac-uumfor2hat60 • C, oxidized at 300 • C (temperature ramp 10 • C/min) in a flowing 5% O 2 /He mixture for 2 h, and finally reduced at 200 • C (same temperature ramp) for1hin a5%H 2 /He mixture. The different activation protocol was chosen in this case to assure mild removal of the acetylide ligands. The metal loadings of all catalysts used in this study were confirmed with elemental analysis via ICP (Galbraith Laboratories).

Transmission Electron Microscopy Measurements

In preparation for TEM imaging approximately 15 mg of each sample were finely crushed and dispersed in 3 ml deionized water by ultrasonification for 30 min. A drop of this fine dispersion was deposited on a Cu grid and then dried at 40 • C for 5-10 min until the excess water was removed. Samples were then examined using a Hitachi 200-kV microscope. Digital images were recorded at magnifications of approximately 200,000. Particle size distributions were obtained by measuring 200 particles for each sample analyzed, using at least three different micrographs.

Hydrogen Chemisorption Studies

Pt dispersions were obtained via hydrogen chemisorption at room temperature (Autosorb AS-1 gas sorption system). Prior to these measurements, the samples were reduced in situ in flowing H 2 at a temperature of 300 • C for 3 h, followed by evacuation at the same temperature for 2 h. The samples were then cooled to 40 • C and exposed to H 2 at different pressures. Preselected amounts of H 2 were added to the sample and the volumetric uptake of hydro-gen at different pressures was recorded as a function of the equilibrium pressure up to monolayer coverage. The monolayer coverage was determined based on the "extrapolation to zero pressure" method, which accounts for and subtracts the amount of physisorbed hydrogen. Measurements performed with the 2% Au sample and with the bare silica support indicated no H 2 uptake in these cases. A stoichiometry of one adsorbed hydrogen atom per Pt surface atom was assumed in the calculations.

Transmission Fourier-Transform Infrared Spectroscopy (FTIR) of Adsorbed CO

Transmission FTIR spectra were collected in the singlebeam mode with a resolution of 2 cm -1 using a Nicolet 740 FTIR spectrometer equipped with an MCT-B detector. A 10-cm-long stainless steel IR cell, with NaCl windows cooled by flowing water, was used to collect in situ spectra. A heating element wrapped around the cell allowed spectra collection at elevated temperatures. The cell temperature was monitored by a thermocouple placed in close proximity to the catalyst sample. Reference spectra of the clean surfaces in He, 5% H 2 /He or 5% O 2 /He mixtures were collected at different temperatures as needed. Difference spectra between the samples and the corresponding reference are shown in this paper. Catalyst samples were selfsupported wafers with a diameter of 12 mm and a thickness of approximately 20 mg/cm 2 .

Two sets of experiments, each with different activation protocols, were conducted with each catalyst sample. In the first set (i.e., "oxidized" samples) the catalysts were exposed for2hi naflowing 5% O 2 /He mixture at 300 • C (cluster-derived samples) or 400 • C (all other samples). In the second set (i.e., "reduced" samples) the catalysts were exposed for 2 h in a flowing 5% H 2 /He mixture at 300 • C. Following these pretreatments the samples were cooled in either O 2 /He or H 2 /He mixtures to 100 • C, flushed with He, and cooled in He to room temperature. At room temperature a flowing CO/He mixture (CO concentrations of 3000 ppm and 3%) was introduced to the cell and spectra were collected at different time intervals until steady state was reached (usually after 20 min). Helium was then purged through the cell and spectra were collected at different time intervals and elevated temperatures until the entire amount of adsorbed CO was removed from the surface.

Experiments were also conducted at room temperature with mixtures of 12 CO and 13 CO at a total flow rate of 5 ml/min and at different ratios (35% 12 CO-65% 13 CO, 50% 12 CO-50% 13 CO, 65% 12 CO-35% 13 CO). The CO in this case was diluted in 95 ml/min of He and was flowed over the catalyst pellet for 30 min to allow equilibration of the surface. The gas-phase spectra of the 12 CO- 13 CO mixtures were subtracted from the spectra shown in this paper. 2 2.5. Activity Measurements 2.5.1. 16 O/ 18 O homoexchange reaction. Activity measurements for the 16 O/ 18 O homoexchange reaction were carried out on 20-mg samples in a batch recirculation reactor described in detail elsewhere (12). Prior to reaction, the samples were oxidized at 400 • C (10 • C/min) in pure 16 O 2 for 15 min, outgassed under vacuum at 400 • C for 15 min, reduced at the same temperature for 15 min in pure H 2 , and finally outgassed again at 400 • C under vacuum for 30 min. Following this pretreatment the samples were cooled to the reaction temperature and an equimolar mixture of 18 The homoexchange reaction rate (V q ), expressed in oxygen atoms exchanged per hour per surface Pt site was calculated as follows:

V q = 2 • MW Pt m • x(wt) • D • R • V r T r + V c T c • dP o 18 O 16 O dt [1]
where MW Pt is the atomic weight of Pt (g/mol), m is the sample mass (g), x(wt) is the Pt loading of the sample, D is the Pt dispersion, R is the ideal gas constant (8.314 J K -1 mol -1 ), V r and V c are the reactor and loop volumes (cm 3 ), T r and T c are the reactor and loop temperatures (K), and

dP o 18 O 16 O dt
is the initial rate of formation of 18 O 16 O.

Selective catalytic reduction of NO by C 3 H 6 .

Steady-state activity measurements of the selective catalytic reduction of NO by C 3 H 6 (HC-SCR) were conducted in a quartz single-pass fixed-bed flow reactor. Prior to the activity measurements all catalyst samples were oxidized in situ at 500 • Ci na5 %O 2 /He mixture for 2 h. Certified mixtures of 1.00% NO in He, 1.03% C 3 H 6 in He, 9.80% O 2 in He, and a 99.999% He carrier gas, provided and certified by National Specialty Gases, were used to prepare the reacting gas mixture. Typical gas concentrations used were 1000 ppm v NO, 1000 ppm v C 3 H 6 ,1 %O 2 , and balance helium. Inlet and outlet gas streams were analyzed by the use of a gas chromatograph (Hewlett-Packard 5890) equipped with a thermal conductivity detector and three chromatographic columns: Molecular Sieve 5A (for the analysis of N 2 ), Porapak Q (for the analysis of N 2 O and CO 2 ), and Graphpac GC (for the analysis of C 3 H 6 ) connected in parallel. The reaction temperature was varied between 200 and 500 • C and was monitored by a thermocouple placed in the catalyst bed.

Measurements with samples containing 1% Pt and/or 2% Au used 100 mg of the catalyst in the form of 60/80 mesh particles. The total volumetric flow rate of the reactant mix-ture was held at 200 cm 3 /min (1 atm, 25 • C) with a corresponding gas hourly space velocity (GHSV) of 120,000 cm 3 / gm/hr. Measurements with samples containing 0.15 wt% Pt and/or 0.3 wt% Au used 300 mg of catalyst and a total flow rate of 100 cm 3 /min, so that the overall space velocity was decreased proportionally to the Pt loading and similar overall NO conversions were obtained with both sets of samples. The percentage NO reduction was calculated from the amounts of N 2 and N 2 O formed, while the selectivity toward N 2 and N 2 O was defined as the amount of N 2 formed divided by the total N 2 and N 2 O formed. The only reaction products observed from the oxidation of C 3 H 6 were CO 2 and H 2 O, and the carbon mass balance was closed within ±5%.

RESULTS

TEM Measurements and H 2 Chemisorption

Number-average metal particle sizes, as well as the results of the hydrogen uptake measurements for different fresh and "used" (i.e., exposed to HC-SCR conditions) samples are summarized in Table 1. Furthermore, metal particle size distributions for the 1Pt and the 1Pt-2Au samples prepared by impregnation, and the cluster-derived 0.5Pt 2 Au 4 sample are shown in Fig. 1. The results indicate similar metal particle size averages for the monometallic 1Pt and the coimpregnated 1Pt-2Au samples. In contrast, a smaller average metal particle size (3.4 versus 4.6 nm) and a more narrow distribution are observed with the cluster-derived 0.5Pt 2 Au 4 sample. Evidence that mild sintering is taking place as a result of exposure to HC-SCR reaction conditions becomes apparent when the average metal particle sizes of the used samples are compared to the corresponding averages for the fresh samples (Table 1). The observed changes, however, are similar for all three samples and indicate that the cluster-derived 0.5Pt 2 Au 4 catalyst maintains a smaller average metal particle size than the other two samples during exposure to temperatures up to 500 • C in the presence of O 2 (i.e., HC-SCR conditions). Finally, Pt dispersions estimated based on hydrogen uptake measurements (Table 1) are consistent with the TEM measurements, indicating a higher uptake for the cluster-derived 0.5Pt 2 Au 4 sample and mild sintering for the used samples.

FTIR Spectroscopy of Adsorbed CO

FTIR studies of adsorbed CO were performed on both reduced and oxidized samples, in an attempt to understand the effect of the Au presence on the structure and properties of Pt. Spectra collected at room temperature on reduced catalyst samples following exposure to 3.3 kPa of CO are shown in Fig. 2. A strong peak at 2070 cm -1 (Fig. 2, spectrum b) is observed in the spectrum of the monometallic 1Pt sample, in agreement with literature reports (13). This peak was assigned to CO linearly adsorbed on fully reduced Pt sites. The addition of Au via co-impregnation, as in the 1Pt-2Au sample, did not affect the CO adsorption (Fig. 2, spectrum c), consistent with previous literature reports (7,13,14). Furthermore, no peak assignable to CO adsorbed on Au was observed for the 2Au sample (Fig. 2,spectrum d).

In contrast, some significant differences can be noticed in the spectra of the 0.5Pt 2 Au 4 catalyst (Fig. 2, spectrum a) in agreement with similar results reported by Chandler et al. (7) for the adsorption of CO on cluster-derived Pt-Au catalysts. In particular, a red shift from 2070 to 2064 cm -1 is observed in the position of the peak assigned to CO linearly bound to Pt, and a new peak is observed at 2117 cm -1 assigned to CO bound to finely dispersed Au. Furthermore, a weak shoulder and substantial asymmetric tailing in the low-frequency region can be observed in the CO-Pt peak of Fig. 2, spectrum a. Similarly, substantial asymmetric tail-ing in the high-frequency region can be observed in the CO-Au peak of the same spectrum. These features are more pronounced than the corresponding asymmetric tailing observed in the spectra of the monometallic Pt/SiO 2 and the co-impregnated Pt-Au/SiO 2 samples (Spectra 2c and 2b) and suggest that the cluster-derived catalyst contains a broader distribution of CO adsorption sites of different adsorption strengths. Indeed, attempts to deconvolute these peaks using different software packages, yielded results indicating that a number of smaller intensity peaks is needed in order to fit the asymmetric tailing shown in Fig. 2, spectrum a.

Purging the CO-saturated 0.5Pt 2 Au 4 sample with an inert atmosphere results in the complete removal of the Aubound CO (Fig. 3) after approximately 40 min. At the same time, the peak at 2064 cm -1 assigned to Pt-bound CO decreases slightly in intensity at room temperature and is completely eliminated at temperatures around 150 • C. These results are in agreement with results from previous studies on supported Au and Pt-Au catalysts, where outgassing at room temperature completely depletes the band associated with CO bound to Au (15)(16)(17).

Spectra of adsorbed CO on a "used" catalyst following a reduction treatment at 300 • C are shown in Fig. 4. Even after exposure to reaction conditions the two distinctive IR features (namely, the red shift in the CO-Pt peak and the appearance of the CO-Au peak) are still present. This result is consistent with the kinetic results, indicating no catalyst deactivation or change in the selectivity toward N 2 even after prolonged exposure of the 0.5Pt 2 Au 4 catalyst to the reaction conditions. Similar to the fresh Similar results to the ones obtained with the reduced samples were also observed with samples pretreated in oxygen. In this case, however, the CO stretching frequencies occur consistently at higher wave numbers. This could be due to either a compression of the CO layer caused by co-adsorbed oxygen, which predictably leads to higher frequencies than the ones obtained on reduced surfaces, or to an electronic effect associated with a weakening of the surface CO bond under these conditions (18). Spectra of the oxidized samples after exposure to CO at room temperature are shown in Fig. 5. Once again, a red shift of the Pt-CO peak and a new peak at 2123 cm -1 characteristic of Au-bound CO are evident in the spectrum of the 0.5Pt 2 Au 4 sample (Fig. 5, spectrum a). Furthermore, a new peak is identified in Fig. 5 (spectrum a) at 1844 cm -1 and can be assigned to bridge-bonded CO on Pt (19,20).

FTIR studies of adsorbed CO were also conducted with the prereduced 1Pt, 1Pt-2Au, and 0.5Pt 2 Au 4 samples at elevated temperatures. Results of these studies are shown in Figs. 6 (for 1Pt) and 7 (for 0.5Pt 2 Au 4 ). The results obtained for the 1Pt-2Au are identical to those obtained with 1Pt and have not been included for brevity. In all cases, when the temperature was increased in the presence of gas-phase CO while the surface was allowed to equilibrate, the vibration frequency of adsorbed CO was noticeably decreased. It was also noticed that total CO desorption from Pt sites in the cluster-derived 0.5Pt 2 Au 4 catalyst occurs at higher temperatures than from the monometallic 1Pt sample. This suggests that on the average the CO-Pt bond is stronger in the cluster-derived catalyst (i.e., the fraction of lower coordination Pt sites is higher in this sample). This result is consistent with the substantial asymmetric tailing in the low-frequency region of the CO-Pt peak, which was discussed in a previous paragraph. Furthermore, the results of Figs. 6 and 7 suggest that the observed red shift at room temperature (i.e., full coverage) between CO adsorbed on Pt sites on 1Pt (or 1Pt-2Au) and 0.5Pt 2 Au 4 may be related to differences in the singleton frequency of the adsorbed CO on these samples, since at the corresponding highest temperatures (i.e., lowest CO coverage) this red shift is further enhanced (from 2063 cm -1 for 1Pt and 1Pt-2Au to 2049 cm -1 for 0.5Pt 2 Au 4 ). Finally, no significant shift was observed at elevated temperatures with the CO-Au band, indicating minimal coverage effects in this case. The clear difference in the magnitude of the shifts of the CO-Au and CO-Pt bands is another indication that the two bands are uncoupled and belong to different species. It is worth noting that previous room-temperature studies of the adsorption of CO on monometallic Au/SiO 2 catalysts indicate a blue shift with decreasing CO pressure (15,(21)(22)(23).

These results appear to suggest that the role of Au in the cluster-derived catalyst is beyond that of simply breaking up large Pt ensembles, and that Au may be electronically modifying the properties of Pt. However, due to the possibility of islands of CO formation even at low surface coverages (24), in which situation the dipole-dipole coupling is not completely eliminated, this hypothesis was further verified by collecting spectra of adsorbed 12 CO/ 13 CO mixtures at different ratios between the two isotopes. The dilution of one isotope in the other and the subsequent extrapolation of the observed frequencies to zero coverage yields another estimate of the singleton frequency. The frequency of 13 CO-Pt was used in these calculations, because of interference between the frequency of 12 CO-Pt and that of 13 CO-Au (at approximately 2064 cm -1 ) in the 0.5Pt 2 Au 4 sample.

The IR spectra collected with different mixtures of adsorbed 12 CO/ 13 CO on pre-reduced 1Pt are shown in Fig. 8. The intensities associated with the two bands do not necessarily correspond to the ratio of the two isotopes in the mixture, since a transfer of intensity from one band to the other is possible, as was discussed previously by Toolenaar et al. (25) for Pt-Cu alloys. For the same reason, spectra collection at molar fractions above 4 : 1 or below 1 : 4 was virtually impossible. The spectra were deconvoluted using curve-fitting software packages, and peak FIG. 8. RT spectra of mixtures of 12 CO/ 13 CO adsorbed on prereduced 1Pt: (a) 100% 13 CO, (b) 35% 12 CO/65% 13 CO, (c) 50% 12 CO/50% 13 CO, (d) 65% 12 CO/35% 13 CO, and (e) 100% 12 CO. ) FIG. 9. RT stretching frequency of Pt-bound 13 CO adsorbed on different Pt and Pt-Au catalysts as a function of the molar fraction of 13 CO in the 12 CO/ 13 CO mixture: ᭜, 1Pt; ᭹, 1Pt-2Au; , 0.5Pt 2 Au 4 . positions of 13 CO were thus extracted. Plots of the frequency of adsorbed 13 CO on Pt obtained from this deconvolution procedure versus the 13 CO mole fraction in the 12 CO/ 13 CO mixture for the three catalysts examined are shown in Fig. 9. Extrapolation to zero concentration of 13 CO in the gas phase yields the 13 CO singleton frequency at full coverage, eliminating the dipole-dipole interactions between neighboring adsorbate molecules. These frequencies are shown in Table 2. Similar values were obtained for 1Pt and 1Pt-2Au (2008 and 2014 cm -1 , respectively), while a lower singleton frequency (1990 cm -1 ) was obtained for the cluster-derived 0.5Pt 2 Au 4 sample, consistent with the results of the studies conducted at elevated temperatures. The combination of the two results suggests that in the case of the cluster-derived catalyst the electronic properties of Pt have been modified by the presence of Au.

Kinetic Results

Selective catalytic reduction of NO by propylene.

The NO reduction and propylene oxidation versus temperature curves for catalysts containing approximately 1 wt% Pt and for 2 wt% Au loadings are shown in Fig. 10. Identical results were obtained with the 1Pt and 1Pt-2Au samples. , balance He, GHSV = 120,000 ml h -1 g -1 ).

In both cases, the NO reduction and propylene oxidation curves closely match each other up to the temperature of maximum NO reduction. At higher temperatures, the reduction of NO decreases, while the propylene oxidation reaches 100% and remains constant at this level. The selectivity toward N 2 in both cases ranges from 45 to 55%, consistent with what was previously observed with similar catalysts (26,27).

A significantly different behavior was observed for the cluster-derived catalyst (0.5Pt 2 Au 4 ). In this case, a temperature delay of approximately 150 • C was observed in both the NO reduction and propylene oxidation curves. In addition, a slight separation of the C 3 H 6 oxidation and NO reduction curves was observed, with C 3 H 6 oxidation preceding the NO reduction by approximately 10 • C. Furthermore, the selectivity toward N 2 in this case was in the range of 70 to 80%, which is significantly higher than what was observed with the previous samples. Finally, the monometallic 2Au catalyst prepared by impregnation showed no activity toward NO reduction and only minor oxidation activity at temperatures above 450 • C under the conditions studied.

A similar behavior was also observed for the oxidation of propylene in the absence of NO. Results of these studies are shown in Fig. 11. Once again, the performance of 1Pt and 1Pt-2Au was very similar with only a minor temperature delay of approximately 10 • C observed in the light-off curve of the 1Pt-2Au sample. A significant shift of 150 • C toward higher temperatures was observed with the clusterderived catalyst, and the 2Au catalyst was only active at 7 temperatures above 400 • C. These results are consistent with our previous mechanistic conclusions regarding the kinetic significance of the hydrocarbon activation during HC-SCR at temperatures below the temperature of maximum NO reduction (28). In fact, the light-off curves of Fig. 11 indicate that the observed shift in the NO reduction profile for the cluster-derived catalyst under HC-SCR conditions can be directly attributed to the lower propylene oxidation activity of this catalyst. In contrast, the presence of Au in the co-impregnated sample does not have such an effect.

Similar experiments were also conducted over a series of catalysts with a nominal Pt loading of 0.15 wt%. As explained in the experimental section, the experiments in these cases were conducted at a proportionally lower space velocity (20,000 ml h -1 g -1 ) to facilitate comparisons among different catalyst samples. A small temperature delay (i.e., 20-25 • C) in both the NO reduction and C 3 H 6 oxidation curves was observed with the co-impregnated 0.15Pt-0.3Au sample compared to the monometallic 0.15Pt sample at temperatures below the temperature of the maximum NO reduction (Fig. 12). The selectivity toward N 2 was approximately 50%, and the magnitude of the maximum NO reduction was comparable in both cases. Once again, the 0.075Pt 2 Au 4 cluster-derived catalyst exhibited a significant shift toward higher temperatures in both the NO reduction and the C 3 H 6 oxidation profiles. As with the 0.5Pt 2 Au 4 cluster-derived sample, the selectivity toward N 2 was also in the range of 70 to 80% in this case. A similar temperature shift was observed with the propylene oxidation in the absence of NO. Finally, we should point out that the results of kinetic studies conducted with a monometallic 0.15Pt catalyst prepared using an organometallic tert-butyl ligated Pt cluster (10) indicate that the catalytic behavior of this material is identical to that of the monometallic 1Pt sample.

Previous studies have led to the conclusion that the oxidation of hydrocarbons over Pt is a structure-sensitive reaction. Carballo and Wolf (29), for example, reported that propylene oxidation over alumina-supported Pt proceeds at a significantly lower rate on smaller Pt particles. In that study, differences of 10 nm in particle size (i.e., for 1 to 11 nm) resulted in a ten-fold increase in the turnover frequency. Similar results were also reported by Garetto and Apesteguia for the oxidation of cyclopentane, methane, and benzene (30,31). A similar Pt particle size effect has also been reported for the selective reduction of NO by hydrocarbons. Lower turnover frequencies over smaller Pt crystallites have been observed, for example, for the reduction of NO by either propylene (32,33) or octane (34). Furthermore, previous attempts to promote the catalytic activity of Pt for the selective catalytic reduction of NO by propylene by the addition of Au appear at first to have had contradictory results. Bimetallic Pt-Au catalysts prepared by incipient wetness impregnation from individual metal salts (35) or by redox techniques (36) have similar activity with the monometallic Pt only catalysts, in agreement with the results of this study. In contrast, reports from the patent literature indicate a promoting effect when the Au was added by ion exchange or deposition methods (37).

In light of these reports, the results obtained in our study suggest the possibility of similar Pt particle or ensemble (in the case of the bimetallic catalysts) sizes for the monometallic Pt/SiO 2 and the co-impregnated Pt-Au/SiO 2 samples, and a significantly smaller Pt particle or ensemble size for the cluster-derived Pt 2 Au 4 /SiO 2 catalysts. 16 O/ 18 O exchange reaction. Arrhenius plots (utilizing TOFs) for the 16 O/ 18 O exchange reaction over 1Pt, 1Pt-2Au, and 0.5Pt 2 Au 4 catalysts are shown in Fig. 13. The results indicate that the cluster-derived 0.5Pt 2 Au 4 sample is less active for the homoexchange reaction than the 1Pt or the 1Pt-2Au catalysts. The 1Pt and 1Pt-2Au samples exhibited similar activities. Finally, the 2Au sample was found to be completely inactive for this reaction, consistent with the idea that oxygen cannot be activated by gold. Apparent activation energies for the 16 O/ 18 O exchange reaction were calculated for the different samples from the slopes of the respective curves and the results are summarized in Table 3. A significantly higher apparent activation energy was observed over the cluster-derived sample. It was previously shown that the 16 O/ 18 O homoexchange reaction over supported Pt catalysts is a structure-sensitive reaction favored over larger Pt particles or ensembles (38)(39)(40). In light of this previous work, our results suggest that in the case of the cluster-derived 0.5Pt 2 Au 4 catalyst the Pt ensembles are smaller than in the case of the 1Pt or the 1Pt-2Au samples prepared by impregnation. The 1Pt and 1Pt-2Au samples appear to have similar Pt particle or ensemble sizes. From this point of view, the results from the 16 O/ 18 O exchange reaction are in complete agreement with the results of the selective catalytic reduction of NO by propylene described in the previous section.

3.3.2.

DISCUSSION

Kinetic results obtained for the selective catalytic reduction of NO by propylene, the oxidation of propylene in the absence of NO, and the 16 O/ 18 O homoexchange reaction indicate significant differences in the behavior of the various SiO 2 -supported Pt and Pt-Au catalysts examined in this study. In particular, the cluster-derived 0.5Pt 2 Au 4 catalyst shows a significantly lower activity for all three reactions, which is manifested in the case of the HC-SCR and the propylene oxidation as a shift of the conversiontemperature curves toward higher temperatures. In addition, a higher selectivity for N 2 is observed with this catalyst during HC-SCR. In contrast, the 1Pt-2Au catalyst prepared by co-impregnation from individual precursors of Pt and Au exhibits behavior which is almost identical to that of the monometallic 1Pt catalyst. Corroborated with the fact that the monometallic 2Au catalyst prepared by impregnation is inactive for all three reactions, these results demonstrate that while Pt and Au do not affect each other in the 1Pt-2Au system, the presence of Au has a strong effect on the catalytic behavior of Pt in the cluster-derived 0.5Pt 2 Au 4 catalyst.

During the presentation of the results it was indicated that both the oxidation of hydrocarbons and the 16 O/ 18 O homoexchange reactions are known to be structure sensitive over supported platinum catalysts. In fact, the origin of the structure sensitivity is the same in both cases and is associated with the higher rate of the activation of molecular oxygen over larger Pt ensembles. Our previous work in the HC-SCR area has concluded that the activation of propylene by molecular oxygen is the rate-determining step of this reaction at temperatures below the temperature of maximum NO conversion (28,41). Consequently, it is not surprising for HC-SCR to exhibit the same type of structure sensitivity as well. In fact, there are published literature reports that have experimentally demonstrated such a structured sensitivity effect over supported Pt catalysts with different Pt particle sizes (33,34). Hence, in light of these reports, it is reasonable to attempt to attribute the differences in the kinetic results obtained in this study to differences in Pt ensemble sizes and, in particular, to a smaller Pt ensemble size in the case of the cluster-derived 0.5Pt 2 Au 4 catalyst.

Indeed, the results of the TEM and hydrogen chemisorption measurements suggest that the cluster-derived catalyst has a slightly smaller metal particle size (on the order of 1 nm) and a higher Pt dispersion than either the monometallic 1Pt or the co-impregnated 1Pt-2Au systems. However, given the magnitude of the structure sensitivity effects reported previously for the reactions examined (33,34,39,40), it becomes clear that these differences in metal particle size are not sufficient to justify the observed differences in catalytic behavior. As mentioned in the previous paragraph, the kinetic results suggest that the active Pt ensemble size in the cluster-derived 0.5Pt 2 Au 4 catalyst is significantly smaller than the active Pt ensemble size in the monometallic 1Pt and the co-impregnated 1Pt-2Au systems. Since identical kinetic results were obtained with the monometallic Pt catalysts irrespective of the precursor used (salt-derived or cluster-derived) as was discussed in section 3.3.1, the smaller Pt ensemble sizes in the former case can be attributed to the presence of Au. In turn, this can be interpreted as the first indication of the formation of Pt-Au bimetallic particles in the 0.5Pt 2 Au 4 catalyst. The presence of Au in the surface of such particles is expected to "break down" large Pt ensembles and result in an average Pt ensemble size, which is significantly smaller than the average metal particle size. In addition, it is possible that the presence of Au in such bimetallic particles also results in a modification of the electronic, and hence catalytic, properties of Pt.

Further evidence for the formation of Pt-Au bimetallic particles in the 0.5Pt 2 Au 4 catalyst can be found in the results of the CO adsorption experiments conducted in this study. The FTIR spectra of this catalyst collected at room temperature and full CO coverage indicate the presence of a new Au-bound weakly adsorbed surface CO species and a red shift in the frequency of the Pt-bound CO. Previous literature reports indicate that only finely dispersed Au crystallites lower than 5 nm in diameter can adsorb CO. Therefore, the FTIR results suggest that Au is finely dispersed in this sample. The red shift observed in the same FTIR spectra in the frequency of the Pt-bound CO can be associated with either a geometric or an electronic effect. In the first case, the geometric ("dilution") effect is the result of Au breaking up the large Pt ensembles, thus creating a weaker lateral interaction between adsorbed CO molecules (i.e., decreased dipole-dipole coupling in the adlayer). In the second case, electronic donation from one metal to the other can increase the back donation in the 2π * antibonding orbitals of adsorbed CO molecules, and consequently cause the observed red shift. The estimation of the singleton frequency (i.e., the frequency of a single CO molecule adsorbed on one metal site) can help to dis-cern between dipole-dipole coupling shifts and shifts due to changes in the electronic state of the surface metal site. Such estimates were obtained by two different approaches: surface equilibration with gas-phase CO at elevated temperatures (i.e., equilibrated low surface coverages of CO) and use of 12 CO/ 13 CO mixtures at full coverage. Although at first it appears that both approaches provide the same result, in reality two different values of the singleton frequency can be obtained. The high-temperature experiments reveal the frequency of a single CO molecule adsorbed on a practically empty surface, while the experiments utilizing mixtures of the two isotopes reveal the frequency of an uncoupled 12 CO (or 13 CO) molecule adsorbed on a surface saturated with 13 CO (or 12 CO) molecules.

The important point from the perspective of this paper is that both approaches demonstrated differences of about 15-20 cm -1 in the singleton frequency of adsorbed CO on the cluster-derived 0.5Pt 2 Au 4 catalyst, compared to the monometallic 1Pt catalyst or the 1Pt-2Au catalyst prepared by co-impregnation from individual precursors of Pt and Au. These differences are a clear indication that in the cluster-derived catalyst not only the Pt ensemble size has been affected, but also the electronic properties of Pt have been modified by the presence of Au. Hence, the combination of kinetic and spectroscopic evidence leads to the conclusion that in the cluster-derived catalyst Pt and Au are intimately mixed in the form of bimetallic Pt-Au particles. These particles are much larger than the original six metal atom clusters and, therefore, agglomeration is taking place during the ligand-removal process. However, it appears that during this agglomeration no significant segregation of Pt and Au takes place.

The formation of bimetallic particles is greatly dependent on the precursors used. In contrast to the cluster-derived catalyst, the 1Pt-2Au catalyst prepared by co-impregnation from individual precursors of Pt and Au exhibits both catalytic and spectroscopic properties that are very similar to those of the monometallic 1Pt sample. This material appears to follow a model in which Pt and Au are segregated, which would be expected based on the miscibility gap between the two metals. Furthermore, Au in this material appears to be in the form of larger crystallites since the FTIR studies did not reveal any CO adsorption. In fact, it is reasonable to assume that the majority of Au is in the form of the larger particles observed in the tail end of the metal particle size distribution of this catalyst (Fig. 1).

Finally, we should point out that although the use of the organometallic Pt-Au cluster precursors appears to prevent the segregation of the two metals into separate particles, metal mobility within these particles and the subsequent surface-enrichment effect cannot be ruled out. Thermodynamic arguments indicate that the surface of the bimetallic particles is expected to be enriched with the element having the lowest surface tension. In the Pt-Au pair, Au exhibits the lowest surface tension and therefore a Au enrichment of the surface is possible. However, a lower hydrogen uptake would be expected if the surface was enriched in Au, and no such trend was observed in the data of Table 1. This may be due to the nanoscale dimension of the bimetallic particles involved in this study. At this scale, metal behavior may differ significantly from "bulk" behavior observed with larger particles.

CONCLUSIONS

The use of an acetylide-ligated organometallic Pt-Au cluster as a precursor has led to the synthesis of supported Pt-Au catalysts containing bimetallic Pt-Au particles. In contrast, a conventional synthesis approach utilizing incipient wetness impregnation of individual Pt and Au precursors results in catalysts containing segregated Pt and Au catalysts. Catalysts prepared using the cluster route exhibited significantly different catalytic behavior for a series of test reactions, in addition to different adsorption properties for CO. These differences are the result of the presence of finely dispersed Au, smaller Pt ensembles, and modification of the electronic properties of Pt by Au in the Pt-Au bimetallic particles. These particles appear to be fairly stable and retain their properties and composition even after prolonged exposure to HC-SCR conditions (i.e., oxidative atmosphere and temperatures up to 500 • C).

FIG. 1 .

 1 FIG. 1.TEM histograms of the fresh co-impregnated and clusterderived catalysts ( , 0.5Pt 2 Au 4 fresh sample; , 1Pt fresh sample; ᮀ, 1Pt-2Au fresh sample).

FIG. 2 .

 2 FIG. 2. IR spectra of adsorbed CO at room temperature (30 • C) on reduced SiO 2 -supported Pt and Pt-Au catalysts. Spectra were collected immediately following the removal of gas-phase CO: (a) 0.5Pt 2 Au 4 , (b) 1Pt, (c) 1Pt-2Au, (d) 2Au.

FIG. 3 .

 3 FIG. 3. IR spectra of adsorbed CO on reduced 0.5Pt 2 Au 4 catalyst. Spectra were collected following exposure to 0.3 kPa CO for 1 h at room temperature (RT) and He purge: (a) immediately following CO gas-phase removal at RT, (b) for 5 min at RT, (c) for 70 min at RT, (d) for 230 min at RT, (e) for 10 min at 50 • C, (f) for 10 min at 75 • C, (g) for 10 min at 100 • C, and (h) for 10 min at 150 • C.

FIG. 5 .

 5 FIG. 5. IR spectra of adsorbed CO at RT (30 • C) over SiO 2 -supported oxidized Pt and Pt-Au catalysts. Spectra were collected immediately following removal of the gas-phase CO: (a) 0.5Pt 2 Au 4 , (b) 1Pt, (c) 1Pt-2Au.

FIG. 6 .

 6 FIG. 6. FTIR spectra of adsorbed CO on reduced 1Pt collected in the presence of gas-phase CO at different temperatures: (a) RT, (b) 70 • C, (c) 105 • C, (d) 145 • C, (e) 175 • C, (f) 204 • C, (g) 220 • C, and (h) 245 • C.

FIG. 7 .

 7 FIG. 7. FTIR spectra of adsorbed CO on reduced 0.5Pt 2 Au 4 collected in the presence of gas-phase CO at different temperatures: (a) RT, (b) 60 • C, (c) 70 • C, (d) 85 • C, (e) 110 • C, (f) 249 • C, and (g) 275 • C.

FIG. 11 .

 11 FIG. 11.C 3 H 6 oxidation in the absence of NO vs. temperature over different SiO 2 -supported Pt and Pt-Au catalysts: ᭺, 1Pt; ᮀ, 1Pt-2Au; ᭝, 0.5Pt 2 Au 4 ; ᭛, 2Au (1000 ppm C 3 H 6 ,1 %O 2 , balance He, GHSV = 120,000 ml h -1 g -1 ).

FIG. 12 .

 12 FIG.12. NO reduction and C 3 H 6 oxidation vs. temperature over different SiO 2 -supported Pt and Pt-Au catalysts: ᭺, ᭹, 0.15Pt; ᮀ, , 0.15Pt-0.3Au; ᭝, , 0.075Pt 2 Au 4 ; open symbols: C 3 H 6 oxidation; closed symbols: NO reduction (1000 ppm NO, 1000 ppm C 3 H 6 ,1%O 2 , balance He, GHSV = 20,000 ml h -1 g -1 ).

1 )FIG. 13 .

 113 FIG. 13.Arrhenius plot for the16 O/18 O homoexchange reaction: , 1Pt; ᭹, 1Pt-2Au; , 0.5Pt 2 Au 4 .

TABLE 1 Properties of Different Catalysts Used in this Study

 1

				Average metal	Hydrogen uptake
		Loading (%)	particle size (nm)	(moles H 2 /mole Pt)
	Catalyst	Pt	Au	Fresh	Used	Fresh	Used
	1Pt	1.04	-	4.7	5.3	0.158	0.108
	1Pt-2Au	0.79	1.81	4.6	5.6	0.153	0.101
	0.5Pt 2 Au 4	0.77	1.54	3.4	4.0	0.223	0.2

TABLE 2 Singleton Frequencies Obtained from 12 CO/ 13 CO Experiments

 2 NO reduction and C 3 H 6 oxidation vs. temperature over different SiO 2 -supported Pt and Pt-Au catalysts: ᭺, ᭹, 1Pt; ᮀ, , 1Pt-2Au; ᭝, , 0.5Pt 2 Au 4 ; ᭛, ᭜, 2Au. Open symbols: C 3 H 6 oxidation; closed symbols: NO reduction (1000 ppm NO, 1000 ppm C 3 H 6 ,1%O

	Catalyst sample	Singleton frequency (cm -1 )
	1%Pt/SiO 2	2008
	0.8%Pt-1.8%Au/SiO 2	2014
	0.4%Pt 2 Au 4 /SiO 2	1990

FIG. 10.

  2

TABLE 3 Apparent Activation Energy for the 16 O/ 18 O Homoexchange Reaction over Different SiO 2 -Supported Pt and Pt-Au Samples

 3

	Catalyst sample	E a (kJ/mol)
	1Pt	90
	1Pt-2Au	122
	0.5Pt 2 Au 4	148

ACKNOWLEDGMENTS

The authors express their gratitude to the U.S. Department of Energy (DE-FG02-96ER14666) for financial support of this work. M. D. A. also acknowledges support from an international supplement from the National Science Foundation (CTS-9624433). Finally, Bert D. Chandler is acknowledged for the preparation of the organometallic clusters used as precursors and for his useful suggestions during this work.


Olivier Aumage
email: olivier.aumage@inria.fr

Julien Bigot
email: julien.bigot@cea.fr

Hélène Coullon
email: helene.coullon@inria.fr

Christian Pérez
email: christian.perez@inria.fr

Jérôme Richard
email: jerome.richard@inria.fr

Combining Both a Component Model and a Task-based Model for HPC Applications: a Feasibility Study on GYSELA

Keywords: HPC, Software Component Model, Task-Based Model, Task scheduling, Multi-cores, Shared-memory

This paper studies the feasibility of efficiently combining both a software component model and a taskbased model. Task based models are known to enable efficient executions on recent HPC computing nodes while component models ease the separation of concerns of application and thus improve their modularity and adaptability. This paper describes a prototype version of the COMET programming model combining concepts of task-based and component models, and a preliminary version of the COMET runtime built on top of StarPU and L2C. Evaluations of the approach have been conducted on a real-world use-case analysis of a subpart of the production application GYSELA. Results show that the approach is feasible and that it enables easy composition of independent software codes without introducing overheads. Performance results are equivalent to those obtained with a plain OpenMP based implementation.

I. INTRODUCTION

High-performance architectures are now massively multicore or even many-core. They may also feature heterogeneous technologies such as those with GPGPU accelerators in additions to the CPUs. Efficient use of these platforms requires hand-tailoring algorithms for the hardware. It requires a good understanding of both the target platform and the application itself. Moreover, codes must be continuously tweaked to adapt to new architectures. In numerical simulation domain, another important source of code variation stems from using improved mathematical schemes or taking into account new discoveries in the simulated domain. This process has a major cost in term of development time during the lifespan of the application. Without special attention to software engineering aspects, this cost can explode, for example, due to duplication of efforts, multiplication of concerns in the same code, etc. Developers therefore have to take maintainability into account when designing a code. Otherwise, the code could become obsolete, in the worse case even before it becomes feature-rich enough to be useful. Maintainability concerns do however often conflict with performance requirements. HPC code developers are therefore faced with a fundamental dilemma between maintainability and performance, and have to make a difficult choice regarding the best compromise.

A solution on the software engineering side of the dilemma is brought by component-based software engineering (CBSE) [START_REF] Mcilroy | Mass-produced Software Components[END_REF], [START_REF] Szyperski | Component Software: Beyond Object-Oriented Programming[END_REF]. CBSE proposes to build applications by assembling independent software building blocks (components) with well-defined interfaces. Components are instantiated and their interfaces connected to form an assembly. This enables easy reuse of (potentially third-party) components and architectural-level modifications of applications through their assembly. Thus CBSE highly improves application maintainability and adaptability. Component models with low overheads have been proposed for high-performance computing, such as CCA [START_REF] Allan | A Component Architecture for High-Performance Scientific Computing[END_REF] or L 2 C [START_REF] Bigot | A low level component model easing performance portability of HPC applications[END_REF].

Existing HPC component models do however not solve the fundamental trade-off between maintainability and performance. Indeed, while splitting an algorithm into two independent components improves code adaptability, it typically constraints the way their execution can be interleaved and can hinder performance at runtime. HPC task-based scheduling runtime systems [START_REF] Slaughter | Regent: a high-productivity programming language for hpc with logical regions[END_REF], [START_REF] Wu | Hierarchical dag scheduling for hybrid distributed systems[END_REF], [START_REF] Bueno | Productive programming of gpu clusters with ompss[END_REF], [START_REF] Augonnet | StarPU: A Unified Platform for Task Scheduling on Heterogeneous Multicore Architectures[END_REF] have been designed to ease reaching high performance on complex hardware such as those with many-cores or GPUs (by constantly feeding processing units while hiding synchronizations and data transfers) as well as performance portability (by separating the description of the work from how it is performed on available resources). In this approach applications are described as graphs of tasks with ordering constraints, called dependencies. Different runtime systems exist proposing different scheduling policies and techniques. Task granularity should be small enough such that the runtime scheduling algorithm can leverage this flexibility to make efficient choices for the available hardware. This does however mean that tasks are not the right model for handling multiple coarse-grain algorithmic variants, since a whole subset of tasks (i.e., a subgraph) may need to be modified to replace a single algorithm.

Combining both approaches appears as a compelling way to improve the development of HPC applications. Software components ease algorithm composition and replacement, while tasks and runtime scheduling ease performance portability over a wide range of architectures. However, to our knowledge, existing HPC models do not unify component and task models in a coherent way. This paper presents a feasibility study of COMET, an approach aiming to combine both models. COMET is composed of two elements. First, the COMET programming model extends existing component model concepts with a new way of interacting between components specified by dataflows. We demonstrate that this enables the separation of concerns in distinct components while retaining high-performance thanks to the COMET underlying execution model.

Second, the COMET runtime maps the programming model concepts to an execution model, while retaining extensibility for new concepts in the programming model. This feasibility study targets the shared-memory intra-node scale since this is the level at which fine-grain execution interleaving is critical. Inter-node interactions are left for future work. We apply and evaluate the COMET approach on a use-case from the large-scale production code GYSELA.

Section II presents the GYSELA application. Section III deals with related works. Section IV describes the COMET model and runtime and how the use-case has been implemented using it. Section V evaluates the approach both in terms of software-engineering capabilities and performance. Section VI concludes the paper and gives some perspectives.

II. THE 2D (r, θ) ADVECTION IN GYSELA A. GYSELA Overview

GYSELA is an application that simulates the electrostatic branch of the ion temperature gradient turbulence in tokamak plasmas [START_REF] Grandgirard | A 5D gyrokinetic full-f global semi-Lagrangian code for flux-driven ion turbulence simulations[END_REF], [START_REF] Bigot | Scaling GYSELA code beyond 32K-cores on Blue Gene/Q[END_REF]. The code consists of around 60,000 source lines of code, 95% Fortran and 5% C. It uses a hybrid MPI and OpenMP parallelization and has run on up to 1.8 M threads on the Juqueen Blue Gene/Q (Jülich, Germany) with 91% relative efficiency in weak scaling [START_REF] Grandgirard | High-Q club: Highest scaling codes on JUQUEEN -GYSELA: GYrokinetic SEmi-LAgrangian code for plasma turbulence simulations[END_REF]. Two solvers are self-consistently coupled at the heart of GYSELA. A Vlasov solver computes the particles advection while a Poisson solver computes the magnetic fields.

The main data manipulated in the Vlasov solver is a 5D particle distribution function in phase space (r, θ, ϕ, v , µ), where (r, θ, ϕ) are the space coordinates and (v , µ) the velocity coordinates. The advection part consists in moving the particles in this 5D space according to the electromagnetic field provided by the Poisson solver. In GYSELA, this is computed thanks to a semi-lagrangian scheme with a Strang splitting. As a result, the 5D problem is implemented by successive 1D and 2D advections.

This paper focuses on the 2D advection in the (r, θ) dimension that is the most computational intensive in GY-SELA. This 2D-advection solves an independent problem for each (r, θ) plane of the 5D field. It takes two fields as input: a 2D plane of the 5D field corresponding to the particles density and another 2D field corresponding the electromagnetic field in (r, θ). The result (wherein the particles have been moved) is computed in-place in the particle density 5D array.

B. 2D Advection Overview

The 2D advection can be split into two distinct parts: the computation of four displacement fields from the electromagnetic field and the actual semi-lagrangian advection computing the new particle density. The computation of each displacement field is independent and can be done in parallel. The semi-lagrangian scheme then uses these displacement fields to determine for each point of the density function the origin of the displacement where the density value was the same at the previous time-step. Since this point was most likely not a grid point, an interpolation is used to evaluate the value there based on surrounding grid points. Two interpolation schemes often used in the community are splines and Lagrange polynomials. According to the chosen method, the dataflow of the algorithm differs slightly.

The actual semi-lagrangian advection is composed of three sequential sub-steps, whatever the chosen interpolation scheme. First, data buffers (such as the input buffer or the displacement buffers) are copied into larger ones with boundary values, where each cell can be computed independently (except for the boundary values of the spline interpolation). Second, field derivatives are computed, using different ways according to the chosen interpolation method. The spline interpolation first computes 2D spline coefficients as two successive 1D computations: independent computations on each line, followed by independent computations on each column of the previous sub-step results. It then uses a stencil where the computation of each output cell accesses neighbor cells in the input buffers. The Lagrange interpolation only uses a sequence of multiple stencils. Third, the actual interpolation is computed, where each output cell can be computed independently, but requires the entire two-dimensional input sub-domain due to a valuedriven indirection.

The whole algorithm is applied for each 2D plane independently, providing coarse-grain parallelism (data parallelism). Finer-grained parallelism inside each 2D plane could also be used. However, this would require a task-parallel model since some kernels require the full 2D plane. As a result, this is not implemented in the reference GYSELA code and thus not evaluated here.

C. Analysis

The current state of the 2D advection code is a monolithic package wherein the two main algorithms (displacement field computation and interpolation) are tightly and manually coupled using nested functions. Tightly coupling of algorithms is required at runtime to be efficient: it enables better temporal and data locality as well as higher computational intensity. However, coupling algorithms using nested functions is difficult due to the increasing number of concerns in the same code as well as conflicting requirements from software engineering (maintainability) and performance. Indeed, replacing or providing alternative implementations of the interpolation scheme while keeping an efficient code is hard because it requires changing low-level functions in the heart of GYSELA. This is especially so when the granularity or the access pattern of alternative algorithms differs, requiring significant changes. Since alternative algorithms may be devised to provide more accurate or efficient methods, maintaining the application while keeping high-performance is an important concern.

The 2D advection uses multiple kinds of optimizations to achieve high-performance. These are hidden deep in the heart of the code and thus difficult to tell apart from the actual semantic. They are also specialized for a specific use and guided by the best practices regarding hardware generally accepted at the time of implementation. Since hardware evolves continuously, the code has to be adapted to handle new architectures. Moreover, high-level optimizations such as the parallelization method and low-level optimization such as tiling and vectorization are mixed together in the same code. Consequently, understanding and adapting the code for a new specific use (e.g., adapting the computational method, supporting new architectures) requires advanced skills from the programmer.

Based on this example, we can identify five properties a programming model should provide to improve the situation: i) algorithmic substitution should be made easy, it should be possible to reuse as much application code as possible, and it should not require advanced skills from the programmer; ii) the programming model should map to an efficient execution model leveraging available resources (with a high scalability), and avoiding unnecessary overheads; iii) expression of both task and data parallelism should be possible (without manually setting any arbitrary optimization choice first); iv) optimizations should be described separately or even be done automatically; v) finally, high-level architectural level optimizations (parallelization method tuning, computational method tuning, etc.) and low-level optimizations (tiling, vectorization, etc.) should be clearly separated.

III. RELATED-WORK

Amongst component models, the Common Component Architecture (CCA) [START_REF] Allan | A Component Architecture for High-Performance Scientific Computing[END_REF] and the Low-Level Component (L 2 C) [START_REF] Bigot | A low level component model easing performance portability of HPC applications[END_REF] both target to improve maintainability and adaptability for HPC applications with low overhead and support for MPI. In these two models, components can expose services (i.e., a set of functions) using provide ports and can require services provided by other components through use ports. An assembly is a set of component instances whose use ports are connected to provide ports, enabling the first one to calls functions of the second one. Such composition aims to significantly ease code reuse as well as code coupling. However, being able to simultaneously express task and data parallelism without hindering efficiency using these two models is not currently supported. Indeed, when an algorithm is split into multiple independent components, L 2 C and CCA provide no simple way to efficiently compose, or interleave, the parallel execution of the different parts. In fact, this burden is up to application developers.

On the other hand, task-based approaches aim to enable this interleaving of algorithm execution without requiring developers to specify the exact execution order. Task-based runtime systems such as Parsec [START_REF] Wu | Hierarchical dag scheduling for hybrid distributed systems[END_REF], Legion [START_REF] Bauer | Legion: Expressing locality and independence with logical regions[END_REF], OmpSs [START_REF] Bueno | Productive programming of gpu clusters with ompss[END_REF], XKaapi [START_REF] Gautier | XKaapi: A Runtime System for Data-Flow Task Programming on Heterogeneous Architectures[END_REF], StarPU [START_REF] Augonnet | StarPU: A Unified Platform for Task Scheduling on Heterogeneous Multicore Architectures[END_REF] and Peppher [START_REF] Benkner | The PEPPHER approach to programmability and performance portability for heterogeneous many-core architectures[END_REF] enable to efficiently execute computational parts of HPC applications. This is achieved by scheduling computation units called tasks over the available resources. Tasks usually require data as input and produce output data. In most models, task outputs are connected to task inputs using data dependencies (temporal dependencies), so as to form a directed acyclic graph (DAG). In a such DAG, the nodes are tasks and the edges represent (data) dependencies between tasks. The DAG is then scheduled by a runtime, targeting an efficient execution over a wide range of hardware. However, being runtimes, these tools only focus on execution-time matters. The software engineering aspects such as code composition or maintainability depend on the programming model or API used to describe the task-graph.

Approaches such as Regent [START_REF] Slaughter | Regent: a high-productivity programming language for hpc with logical regions[END_REF], Swift [START_REF] Espinosa | Parallel scripting for applications at the petascale and beyond[END_REF] and OpenMP [START_REF]OpenMP Application Programming Interface Version 4[END_REF] offer models to describe applications taskgraphs using either a dedicated language or annotations respectively. Regent [START_REF] Slaughter | Regent: a high-productivity programming language for hpc with logical regions[END_REF] and Swift [START_REF] Espinosa | Parallel scripting for applications at the petascale and beyond[END_REF] are programming languages for implicit dataflow parallelism. A high-level task-based imperative language offers end-users a way to implicitly (i.e., in a transparent way) build their task graph using constructs such as loops, conditionals, etc. Actually, function calls or specific code constructs are transparently replaced during execution by submitting tasks to a taskbased runtime. While proposing high-level abstraction to end-users, low-level data-based composition can naturally be expressed using Regent thanks to two given abstractions: tasks, and logical regions (i.e., collections of structured objects that can recursively be partitioned). However, highlevel coupling of independent code is not handled in Regent. Moreover, the use of an imperative language to implicitly create the task DAG does not improve application structure understanding, separation of concerns into independent software parts, or ease of replacement and maintainability like component models do through the concept of assembly.

OpenMP [START_REF]OpenMP Application Programming Interface Version 4[END_REF] is a well-known framework that supports shared memory multiprocessing programming. It provides means to easily incorporate parallelism into sequential applications, at a relatively high-level through the use of code annotations. It supports both task and data parallelism.

While OpenMP helps to easily parallelize HPC applications, it does not change the underlying programming paradigm of the annotated language (i.e. imperative programming). Supporting such an approach for component models, where parallelization aspects could be specified by a dedicated language in the assembly, would be a very interesting feature. However, as of now, the authors are not aware of any such work. OpenMP can be used in C, C++ or Fortran component implementations but is not available at the assembly level. The approach proposed in this paper can be seen as a first step into this direction.

Data-driven workflows such as Gwendia [START_REF] Montagnat | A data-driven workflow language for grids based on array programming principles[END_REF] and dataflow-based models such as FlowVR [START_REF] Allard | FlowVR: a middleware for large scale virtual reality applications[END_REF], FastFlow [START_REF] Aldinucci | Fastflow: high-level and efficient streaming on multi-core[END_REF], or the model proposed by Lau and al. [START_REF] Lau | A component model that is both control-driven and data-driven[END_REF], emphasize easing the composition of software codes and also provide a higher abstraction than task-based runtime systems. All of them share the ability to compose algorithms through data-based composition where components of the models expose data ports which, once connected, enable components to produce data consumed by other ones. The use of such composition is a convenient way to describe many HPC applications and could be useful to describe the 2D advection. However, these models are mainly designed for heavy-grained taskbased composition. As a result, coupling HPC codes with fine-grain task parallelism using these models would be detrimental to the maintainability, because it would require codes to be split into many independent parts, reducing the cohesion of coupled codes.

Finally, the Spatio-Temporal Component Model [START_REF] Bouziane | A software component model with spatial and temporal compositions for grid infrastructures[END_REF] (STCM) unifies features from both component models and data-driven workflow models. The model provides composition units called component-tasks (merging tasks and components). Such units can be composed into assemblies through both use-provide and data connections. However, the model does no target fine-grain intra-node parallelism for HPC applications. Components and tasks are merged together, which would result in high overhead if used for fine-grained task decomposition of HPC applications, due to component instantiation and connection overheads.

To summarize, some existing approaches improve software engineering while others support task-based highperformance computing. However, no single model combines both advantages. Thus, end-users have to face a tradeoff between maintainability and performance on modern HPC architectures. None of the proposed models are satisfactory as they do not enable the writing of independent modules efficiently coupled at runtime. The next section presents the COMET model, a proof of concept aiming to handle both component programming models and task-based high-performance runtimes.

IV. THE COMET MODEL

This section gives an overview of the COMET programming model as well as the COMET runtime. The COMET programming model is based on the L 2 C model, since it is a minimalist HPC-oriented component model [START_REF] Bigot | A low level component model easing performance portability of HPC applications[END_REF]. COMET extends it with a dataflow-based form of interactions between components enabling the creation of a task graph. It also enables component connections with fine-grain execution to interleave in a controlled manner, as described in the assembly. The COMET compiler and runtime map these concepts to plain L 2 C components that make use of the StarPU task graph scheduling [START_REF] Augonnet | StarPU: A Unified Platform for Task Scheduling on Heterogeneous Multicore Architectures[END_REF]. The COMET runtime distinguishes three types of components: a) components written by the user in the programming model, b) components generated during the compilation phase, and c) components written by experts that make the runtime easily extensible to add more flexibility in the programming model.

A. The COMET Programming Model

Let us note that, in this work, only a subset of the COMET programming model has fully been defined. The choices have been guided to support the 2D advection use-case. In particular, this paper only deals with intra-node assemblies and local C++ function calls between components.

The two main elements of the COMET programming models are components and dataflow sections. These are instantiated and connected in an assembly describing the application architecture. COMET components are L 2 C components extended with new data ports that enable components to interact with dataflow sections.

Dataflow sections contain metatasks connected to data buffers with dataflow-based interactions. The data partitioning function determines data fragments that are the minimal unit used by a task. For example, the current implementation supports block partitioning of multidimensional arrays. Hence, given a 2D array A(N, M ), a 2D block partition of size (n, m) generates N n * M m fragments. A metatask represents a set of tasks that is created at runtime. They expose a list of data ports defining the memory buffers used by the tasks. Each task has dependencies over fragments of the data buffers connected to data ports. The dependencies are defined by an expression in the assembly specifying alignment between data buffers. Currently, the proposed alignment language is very simple but enough for the 2D advection use-case: only perfect alignment between arrays can be defined, i.e., for two arrays A and B of the same size, a(i, j) and b(i, j) are guaranteed to be proceeded by the same task receiving fragments of A and B as inputs.

The task implementation is provided by a use port of the metatask that is connected to a component instance outside any dataflow section. Hence, metatasks do not contain userlevel code; they only enable the implicit description of task sets; the actual implementation is delegated to components.

Four types of data ports are defined in the model, depending on whether the entity (component or metatask) exposing the port generates information through the port and whether it uses the information accessible through it. Out ports are only used when the entity writes data, in ports mean it only reads it, inout ports mean it does both, and scratch represent temporary read/write memory buffers, whose content is neither provided from outside the task nor meaningful after its execution. Each port is associated with a partition type and a data type.

Data buffers are instances of multidimensional arrays typed by a rank (array dimension), a size for each dimension and the type of the contained data. There are two kinds of data buffers: permanent data buffers that aim to hold a user reference to pre-allocated data, and temporary data buffers that control data life-cycle and allocate them if necessary. Each data buffer instance is associated with a list of partition instances. As already stated, the current implementation only supports block partitioning.

The application is described in an assembly containing component instances, dataflow sections, and connections between them. Component instances can be connected through use-provide connections that enable the instance exposing the use ports to call functions implemented by the instance exposing the provide port. Component instances can also interact through dataflow sections by connecting the data ports of the components to those of the dataflow sections. Dataflow sections are started and managed through a management oriented provide port exposed by each section.

B. The COMET Programming Model on 2D Advection 1) Representation: Figure 1 proposes a description of the 2D advection use-case using the COMET programming model. Component instances (2D-Advection, IO-Manager, etc.) are represented as simple edged rounded boxes and the dataflow section as a large double edged rectangle. Metatask instances (Grad and Spline Interpolation) are displayed as double edged rounded boxes, and data instances as squares (D i for permanent data buffer instances and T i for temporary data buffer instances). Partition instances that are exposed by their associated data buffer instance are displayed as P i annotations on data ports. The figure only contains instance names. For clarity, other information (i.e., instance attributes) such as data size for data buffer instances or block size for block partition instances are not represented.

Provide ports are represented as a full dark circle. They are connecting to use ports without any specific representation. Data connectors are lines connecting data ports and data buffer instances. They are used to describe the flow of data in the dataflow section.

2) Description: The 2D-Advection component controls the use-case execution: first, it obtains data from the IO-Manager component that deals with files in our case. Second, it sends this data to inout ports of the dataflow section to compute the result of one 2D-advection step. Third, it starts the dataflow section computation using the management dataflow section port. The current model does not deal with the automatic start of the dataflow section, since it requires defining a precise semantics when multiple components submit data. This is left for future work if the current model is proved to be able to achieve highperformance.

The Constants component, initialized by IO-Manager, deals with providing some constant data to the dataflow.

The two distinct parts of the dataflow section of the 2D advection computation described in Section II (i.e., displacement fields and interpolation) are expressed by two interconnected metatasks: the Grad metatask (for displacement fields) and Interpolation metatask (for the actual interpolation).

Metatasks delegate the actual computation on data fragments using their use port connected to the provide port of the respectively Grad-Task-Impl and Spline-Task-Impl component instances. Because the interpolation metatask requires temporary data buffers to compute data fragments, it is connected to many temporary data instances.

The actual dataflow is quite straightforward: data are sent from the component 2D-Advection to the dataflow section, where they are partitioned into fragments using block partitioning and perfect alignment of fragments of the various arrays. Those fragments are used to generate tasks from the metatask Grad; the output fragments of this metatask are used for the tasks of the metatask Spline. Then, fragments are gathered to form non-partitioned data sent back to the component 2D-Advection.

3) From spline to Lagrange Interpolation: Switching the interpolation method from spline to Lagrange has required replacing the Interpolation metatask and its used task implementation (green area with dotted edges on Figure 1). Moreover, as the Spline Interpolation and Lagrange Interpolation metatasks have different temporary data needs, the number of scratch ports and their type have also been modified.

C. The COMET Runtime

The COMET runtime deals with low-level components and tasks. It is built on top of both L 2 C and StarPU [START_REF] Augonnet | StarPU: A Unified Platform for Task Scheduling on Heterogeneous Multicore Architectures[END_REF]. Components have use and provide ports as well as attributes. StarPU is used to submit and manage tasks.

The COMET runtime is a L 2 C assembly with three types of components: user level components (coming from the COMET programming model), expert components, and glue components. This L 2 C assembly is made of all components (including their use-provide connections) but the dataflow section of a COMET assembly. An assembly pattern (cf. further) is used to transform all COMET dataflow sections into subsets of this L 2 C assembly (called task sections).

The management related to tasks (such as task submission to the scheduler, data management, data partitioning) is done inside specialized components. Such components are divided into two main categories: expert components and glue components. Expert components are expected to be written by experts; an example of such a component is the runtime component that deals with block partitioning. Glue components are components generated by the compiler presented in Section IV-D, typically to deal with the management of task sections. Only such components expose StarPU-specific interfaces so the COMET runtime may use another compatible tasking runtime without involving users.

Task sections conform to the assembly pattern shown in Figure 2. Components can be instantiated more than once (e.g., the TaskGen component is instantiated as many times as there are metatasks in a dataflow section). Components may expose a variable number of use or provide ports. Cardinalities are used to indicate the number of ports: A cardinality of 1 means that there is a single port, while a cardinality of many ( * in Figure 2) means that this generic port is instantiated as multiple ports. Cardinalities do not give any information about the actual connections (e.g., multiple use ports connected to a provide port). Let us detail a little more these components.

TaskGen: Using StarPU, this glue component is responsible for submitting a group of independent tasks that work on a set of partitioned data buffers. The task submission is done when a call is received from the go provide port. When tasks are executed, they perform a call on the compute use port. Because the task submission requires defining the input/output data fragment of each task, this component needs to access the actual dependencies using the mapping use port and to retrieve the actual data fragment through the partInfoDF use port.

Task: This user component contains the code of a task. This code is provided through the compute port.

DataflowGen: This glue component coordinates the submission of task groups (through the use port go), the data partitioning (through the use port partition), and the interactions with external components (those providing or requiring data via the control, state, inData and outData provide ports) by doing calls on other component interfaces of the task section. It also manages the interactions between this section and the user components outside the section: input data are gathered using use ports (using inData ports); output data are retrieved using provide ports (when the computation ends, using outData provide ports); the port control enables the submission of all the kernel tasks; the state provide port enables access to the section running state.

Partition: This expert component is responsible for data partitioning. Because tasks are submitted on data fragments, and data can have several partitioning during their life cycle, this component is responsible for the partitioning and the unpartitioning. This is controlled via its partition provide port. This component also exposes the partInfo and partInfoDF provide ports to get information about data partitioning (e.g., the number of data fragments) or specific data fragment information (e.g., type, shape, location inside a data partition, etc.). Currently, there is only a block partitioning component implemented.

Data: This expert component manages the life cycle of data inside the task section (when data comes in/out of the task section, or whenever a data buffer is partitioned). In particular, it ensures the compliance of task dependencies over multiple partitions of a given data buffer (i.e., sequential consistency), preventing tasks to work on invalid data fragments. This component also defines the type of data buffers. Those services are provided via its data and part ports.

Map: This expert component provides the set of dependencies between the tasks and the data fragments of a given task group (i.e., alignment) through its mapping provide port. Because alignment often requires information about involved data partitions, this component retrieves them via its multiple partInfo use ports. Currently, there is just a simple map component that only supports a perfect alignment.

D. The COMET Compiler

The COMET compiler is currently a straightforward Python code: from a COMET assembly, it generates the runtime L 2 C assemly by copying COMET component instances into L 2 C component instances and by translating metatasks and dataflow sections of the COMET programming model into L 2 C components and assemblies according to the pattern described in Figure 2. COMET data ports are transformed in use-provide ports into the runtime assembly.

The partition and mapping information are partially taken into account: for the partitioning, the block size (per dimension) is used whereas nothing is used from the alignment but its type as only a perfect alignment (without any parameter) is currently supported. Nevertheless, we believe it is not currently critical as our goal is to study the feasibility and the performance of mixing components and tasks. For both cases, the corresponding L 2 C expert component is selected by the compiler and inserted in the runtime assembly.

V. EVALUATION

This section evaluates the COMET approach (i.e., both the programming model and the runtime) on the 2D advection use-case. It first studies the software engineering properties of the programming model by analyzing COMET assemblies of the 2D advection use-case; then it focuses on the performance of the runtime by evaluating the performance of generated assemblies.

For comparison, the 2D advection spline and Lagrange variants have been implemented in two versions each. The reference implementation is directly extracted from GY-SELA, but rewritten as a standalone C++ prototype. It is a pure OpenMP fork-join version using a parallel for to iterate over plans of the five-dimensional data buffers. The COMET implementation makes use of both components and metatasks of the COMET model.

A. Software Engineering Evaluation

The software engineering properties of the programming model are analyzed with respect to the expected features defined at the end of Section II-C.

1) Algorithmic substitution: The COMET programming model enables algorithmic substitution through components (including metatasks) and their composition. Indeed, component interfaces are well defined and thus component (i.e., subparts of the application algorithm) can be easily replaced by other components providing (at least) the same interfaces. In the case of the 2D advection, Figure 1 shows that the interpolation metatask can be easily replaced by another metatask in order to substitute the interpolation method.

Expression of algorithms is made possible through the two kinds of component composition (i.e., both data and service sharing based composition) brought by the COMET programming model. Data dependency based composition enables to compose metatasks inside the dataflow, while service sharing based composition provides a way to share code between metatasks of the dataflow, thanks to a use port connected to a component that sets the task implementation. This enables reusing code between the implementation of metatasks as well as relatively fine-grained composition in task implementation [START_REF] Coullon | Feasibility Study of a Runtime Component-based Model Integrating Task Graph Concept on a 1D Advection Case Study[END_REF]. Indeed, from the 3,246 lines of code of all the user components of both the spline and the Lagrange variants (excluding expert components that contain altogether 798 lines of code shared between the two variants), 1,576 are shared between the both variants, 1,182 are specific to the spline variant and 488 are specific to the Lagrange variant (49% of all the user code can be fully reused). By comparison, in GYSELA, the two variants are currently developed in separated branches.

2) Expression of both task and data parallelism: The expression of task parallelism is achieved through to the composition of metatasks of dataflow sections, while data parallelism is expressed inside metatask using data partitioning and alignment expressions. In the case of the 2D advection, the two main metatasks are composed together to complete one time-step. At runtime, metatasks produce fine-grained tasks to deal with data parallelism according to the data alignment rule (defined in both metatasks). Consequently, the implementation of the two main parts of the 2D advection can be defined separately and executed simultaneously (data streaming), without any artificial synchronizations between the two units, since task can be scheduled regardless of the submission order. Finer-grained decomposition could even be achieved (especially for the independent field computations of the Grad metatask), but was not applied to remain close to the reference version of GYSELA to make comparison meaningful. Thus, expression of both task and data parallelism is possible without manually setting any arbitrary optimization choice, only granularity has to be tuned to get high-performance.

Parallelism expressiveness of the current COMET approach is limited to the fine-grained composition of multiple interdependent bags of tasks (produced by metatasks). Parallel patterns such as reduction or scan for example are not yet supported. This is due to the fact that the current set of features has been chosen to validate the approach on the 2D advection use-case. The addition of such features is left for future work that, in addition, could study the extensible properties of the COMET programming model and its runtime.

3) Optimizations: Optimizations of the 2D advection can be described separately in the COMET programming model, thanks to components and assemblies. Indeed, optimizing partitions and their parameters (e.g., block size and shape) is just a matter of replacing partition components and tuning component attributes. Adapting metatask granularity can be mostly done by tuning assemblies, whenever possible: multiple metatasks can be aggregated to reduce the size of the scheduled DAG and the use of temporary data buffers, then task composition can be replaced by new simple components to make static calls on the finer-grained task implementation components. Moreover, new task scheduling strategies can be implemented to schedule more efficiently the task DAG produced by dataflow sections over the available resources.

4) High Level architecture: The COMET programming model ensures the separation between high-level architectural level optimizations and low-level optimizations by setting the first one inside assemblies and the second one inside components. Indeed, in the 2D advection, high-level architectural level optimizations such as the parallelization method are only described in the assembly while low leveloptimizations only lie inside the code of components.

B. Performance Evaluation

This section deals with the performance evaluation of COMET on the 2D advection use case, including the spline and Lagrange variants.

Performance and scalability are evaluated up to 16 cores on a shared memory node of the MdlS-Poincare cluster (IDRIS, France). Each node contains 2 sockets of 8 cores Intel Xeon E5-2670 (2.60GHz).

Each experiment has been done 20 times and the median is displayed. Most of the figure use logarithmic scales. Error bars on plots correspond to the first and last quartile. The compiler used is Intel ICC 15.0.0 (the latest version available on the machine) and the OpenMP runtime used is the one proposed by the compiler. Performance results are only those of the computation kernel. They do not include the initialization phase that includes loading data from disk.

1) Strong Scaling Performance: Figures 3 and4 display the completion time of the strong scalability of the reference and COMET implementation on the respective spline and Lagrange variants. They also show the completion time of an intermediate version to understand the gap between the reference and the COMET version. This intermediate version is very close to the COMET version in term of dataflow but it uses a static OpenMP fork-join scheduling instead of a dynamic task-based one. This intermediate version is completely monolithic and sacrifices maintainability for performances as it does neither split code using subroutines as in the reference case nor using COMET features (it uses a sequences of nested loops calling single functions that work are the finest granularity to expose data dependencies between computational parts).

Sequential completion time of the reference implementation is 16% slower than the COMET version on the spline variant and 12% faster than COMET on the Lagrange variant. On 16 cores, the COMET version is respectively 18% faster and 21% slower than the reference implementation on the spline and Lagrange variants. Completion time of both the intermediate and COMET version are close (less than 1% in sequential and up to 6% 8% on 16 core) on the both variants. All versions scale relatively well until 16 cores both on the spline and the Lagrange variants: they are from 12.7 to 13.8 times faster than the sequential completion time on the both the spline and Lagrange variants. The gap between the reference and the intermediate version is huge compared to the gap between the intermediate and the COMET version. This is due to the change of programming paradigm: by focusing more on the flow of data in the code, compiler optimizations differ providing a code more efficient on the spline variant but less efficient on the Lagrange variant (due to pointer aliasing). However, the gap comes mainly from sequential optimizations, which are not the concern of this paper. Let us focus on the differences between the intermediate and the COMET implementation.

2) Overhead Analysis: variants (less than 1% slower). But, as the number of cores grows, the overhead of the COMET version is becoming higher, reaching a peak of 8% on 16 cores for the spline variant and 6% for the Lagrange version. As this overhead is not negligible, its source has been deeply analyzed on the Lagrange variant.

The source of this overhead lies in the tasking thread of the COMET runtime, responsible for the registration of data to StarPU, the data partitioning as well as the submission of tasks to the scheduler. This thread is not bound to a specific core, resulting in a higher overhead when it overloads too much the cores used to complete the scheduled tasks.

Figure 6 breaks down the amount of time taken by each concern of the tasking thread of the COMET runtime on 16 cores. This thread takes 240 ms to complete his work, which is much compared to the 1.76 s taken to complete the whole 2D advection computation. The major part of the overhead is due to the abnormally slow task submission. It is caused by the many temporary data fragment allocations done during task submissions. These are used to handle data transfers between the Grad and the Interpolation metatasks.

However, this overhead can be reduced by allocating the whole data buffers rather than doing per fragment allocations. Figure 6 also displays the effect of the two allocation policies (per fragment allocations vs per buffer allocations) over the time taken by all the concerns of the tasking thread. The time taken by the task submission falls down to 14 ms when one allocation per temporary buffer is used, causing the tasking thread completion time to drop from 240 ms to 37 ms.

3) Temporary Data Allocation Overhead: In COMET, temporary buffers are used to ensure the communication between the bags of tasks generated from metatasks at runtime: when a bag of tasks writes into a data buffer read by another bag of tasks, data fragments have to be temporary stored, waiting to be read, according to the chosen task scheduling policy. The use of such temporary buffers comes from task scheduling. Indeed, task scheduling is performed at runtime and the scheduler can choose either to execute first all the tasks of the writing bag and then the other tasks or to interleave the execution of the tasks of the two bags.

Figure 7 shows the relative completion time of the COMET version over the intermediate one over the number of cores using three different allocation in the cases of the spline and Lagrange variants. The new policy called TCMalloc reuses exactly the code of the many allocation policy, but it replaces the default GNU C library malloc implementation by the Google Performance Tools TCMalloc library1 one at runtime. The one allocation policy outperforms the many allocation policy whatever the number of core used on the both spline and Lagrange variants. Moreover, it does not suffer from the scalability problems of the many allocation policy. However, since the whole temporary data buffers are quite big (around 1 GB), it causes a high memory consumption that may be unacceptable.

The TCMalloc policy solves this by allocating chunks of fragments on demand and by reusing them. On 16 cores, the COMET version with this policy is only about 1% slower than the intermediate version on both the two variants. Finally, when using 16 cores, the COMET version using the TCMalloc allocation policy is 28% faster than the reference implementation on the spline variant and 16% slower on the Lagrange variant due to the performance gap between the reference version and the intermediate one, mainly coming from sequential compiler optimizations.

The TCMalloc policy is a good trade off between the two other policies as it provides performance similar to the intermediate version while reducing memory consumption. Thus, the use of the COMET model does not add a significant overhead compared to the intermediate version when using an adequate temporary buffer allocation policy.

VI. CONCLUSION AND FUTURE WORK

To harness today supercomputer computing power while easing maintainability of HPC applications, this paper has studied the feasibility of efficiently combining both a software component model and a task-based model. Through the COMET approach, this paper has described how the models can be combined into a programming model and a runtime model. The evaluation has been made on a real-world usecase extracted from the GYSELA application.

Evaluations demonstrate the applicability of the approach. Experimental results show that independent software codes can be easily composed and replaced while being efficiently executed at runtime: performance results are equivalent as those obtain with the reference implementation. However, specific care must be taken for the temporary data management to achieve high-performance.

Future works include the support of more complex partitioning and alignment functions, and the support of parallel patterns such as scan or reduction. The support of accelerators such as GPGPU needs also to be investigated as well as the integration of parallel languages, including the tasking model of OpenMP.

Figure 1 :

 1 Figure 1: The 2D advection assembly using COMET.

Figure 2 :

 2 Figure 2: Generic COMET runtime assembly associated to a task section.

Figure 3 :

 3 Figure 3: Completion time (left) and strong scalability (right) of the three versions of the spline variant.

Figure 4 :

 4 Figure 4: Completion time (left) and strong scalability (right) of the three versions of the Lagrange variant.

Figure 5 Figure 5 :

 55 Figure 5: COMET relative performance over the intermediate implementation on the spline and Lagrange variants.

Figure 6 :

 6 Figure 6: Comet overhead source on the Lagrange variant.

Figure 7 :

 7 Figure 7: COMET relative performance over the intermediate version on the spline variant (top) and on the Lagrange variant (bottom) using various allocation policies.

cf. https://github.com/gperftools/gperftools

ACKNOWLEDGMENT

The authors wish to thank Guillaume Latu for his contribution to explaining us the 2D advection part of Gysela. This work has partially been supported by the PIA ELCI project of the FSN.