Rajesh Munirathinam

Dorothée Laurenti

Denis Uzio
email: denis.uzio@ifpen.fr

Gerhard D Pirngruber
email: gerhard.pirngruber@ifpen.fr

Do happy catalyst supports work better? Surface coating of silica and titania supports with (poly)dopamine and their application in hydrotreating

Keywords: Carbon coating, Hydrodesulfurization, Hydrotreating reactions, Polydopamine, Silica, Titania Highlights

In order to meet the demand for cleaner fuels, it is necessary to develop high performing hydrotreating catalysts. Although organic additives are often used to improve the performances of hydrotreating catalysts, bio-polymer additives have not yet been thoroughly investigated. We recently showed that dopamine, a neurotransmitter molecule, which is also frequently found in adhesive bio-polymers, efficiently coats the surface of an alumina carrier material and modifies the interaction with active components of hydrotreating catalysts, i.e. cobalt and molybdenum. The catalytic performance of the CoMoS/Al 2 O 3 catalysts could, thus, be improved. In the present paper we extend the strategy to other carrier materials (silica and titania). The catalysts prepared on (poly)dopamine (Pdop) coated silica showed enhanced activity for the hydrogenation of toluene reaction and the selective HDS of FCC gasoline model feed. Pdop coating lowers the MoS 2 nanocrystallites' stacking on silica, thereby improving the accessibility of active edge sites. The origin of this increase in catalytic activity may be found in the higher capacity of Pdop's functional groups to interact with metallic precursors leading to a better dispersion of the active phase. On the contrary, when the interaction between the dopamine and the support is too strong (as observed for TiO 2 ), the functional groups of Pdop are not available for interaction with Co and Mo species, resulting in decreased catalytic activity.

Introduction

Environmental regulations are continuously strengthened to limit the emission of pollutants from fossil fuels combustion [1]. In addition, natural resources supplying the metal sources for hydrotreating catalysts are limited whereas liquid fuel demand is expected to grow by 48% between 2012 and 2040 (source: International Energy Outlook 2016). These constraints drive the need to develop highly active and efficient hydrotreating catalysts. Industrial hydrotreating catalysts contain Mo (and/or W) as the active metal usually promoted by Co (and/or Ni) and supported on Al 2 O 3 , SiO 2 or TiO 2 [START_REF] Toulhoat | Catalysis by transition metal sulphides: From molecular theory to industrial application[END_REF]. In order to improve their performances, different strategies have been explored such as the use of polyoxometalates [START_REF] Wang | [END_REF], or different kinds of organic additives, namely, organic chelating [4][5][6] or non-chelating (e.g. glycols) agents [7,8].

The support effect is an important field of investigation in hydrotreating catalysis. Indeed, metal-support interactions are known to influence various characteristics of the active phase such as its morphology, slabs orientation, or electronic properties [9][10][11][12]. Acid or basic sites on the support surface can also intervene directly in the catalytic cycle and enhance the formation of the desired products, but in many cases also promote the formation of undesired side products [13]. Silica is an interesting option when acid catalyzed reactions (olefin polymerization, coke formation, etc.) are detrimental, or when low metal support interactions are required to limit the formation of refractory phases [14,15]. However, silica-supported catalysts generally show lower activity than alumina counterparts due to the relatively inert surface making it difficult to form the highly dispersed and promoted sulfide phase, especially at high loadings. In order to circumvent such limitations, coating the surface of silica with a polymer that contains different functional groups able to interact with metallic precursors is one of the suitable option to improve surface reactivity and dispersion [16].

Titania is also a very interesting support material. Non-promoted MoS 2 /TiO 2 catalysts are four to five times more active than their alumina counterparts [17]. The high activity was explained either by electronic effects, or by the epitaxial relationship between anatase and MoS 2 , which leads to edge-bonded slabs that mainly expose M-edges. Yet, the promotion effect of Co on titania supported MoS 2 is weaker than the one observed on -Al 2 O 3 for instance, because only a small fraction of Co is incorporated into the mixed CoMoS phase [9].

In a recent study from our group, we have successfully modified the surface properties of alumina carriers, by coating with the bio-molecule dopamine. Under soft conditions, a polydopamine-coated alumina was obtained [18]. The choice of dopamine monomer is (bio-)inspired from the properties of mussel adhesive proteins, on the basis of the strong interfacial binding property of embedded catechol groups [19]. Dopamine polymerizes under mild basic reactions conditions and invariably coat almost all kinds of materials such as metals, metal oxides, polymers, etc [20]. In addition, the chemical structure of polydopamine (Pdop) includes various functional groups such as catechol, quinone, amine and imine that are useful to bind many transition metal ions [21,22]. In the case of Al 2 O 3 , the Pdop coating of the surface prevented the direct interaction of cobalt and molybdenum species with the alumina surface (which leads to the formation of refractory species), while providing a higher number of binding sites for molybdenum precursors, leading in fine to an improved dispersion of the MoS 2 slabs, in particular at high surface densities of molybdenum. The combination of both effects led to an improved activity of the CoMoS/Pdop/Al 2 O 3 in the hydrogenation of toluene and also in the hydrotreating of gasoil.

In contrast to alumina, silica has a fairly weak interaction with molybdenum species. The fact that the Pdop coating provides binding sites for molybdenum is therefore a particularly interesting strategy to improve the dispersion of MoS 2 slabs on the silica surface. In the case of titania, the effect of the Pdop coating is difficult to predict, because of the very specific interaction between MoS 2 slabs and the titania surface.

In the present work, we show how SiO 2 and TiO 2 carriers can be coated by Pdop. The coated supports were characterized in detail and then used for preparation of hydrotreating catalysts, via classical incipient wetness impregnation of molybdenum and cobalt species. The performance of the sulfide catalysts in toluene hydrogenation and selective hydrodesulfurization (HDS) of 3-methylthiophene was assessed and discussed in relation with characterization results.

Experimental Section

Materials

All the chemicals were purchased from Sigma Aldrich and used as received unless specified. Silica and titania (anatase) supports were provided by Saint-Gobain and Huntsman, respectively. The shaping of the titania supports was done in-house.

Support modification

SiO 2 support (1.6 mm diameter cylindrical extrudates, V p = 1.10 cm 3 g -1 , S BET = 233 m 2 g -1 , d p = 12.9 nm) was coated with Pdop by incipient wetness impregnation. The desired amount of dopamine-hydrochloride was dissolved in water and impregnated onto SiO 2 . Impregnation was followed by a maturation step in a water saturated atmosphere, for overnight at room temperature. Then, a drying step was performed for 20 h at 90°C which yielded Pdop coated silica (Pdop/SiO 2 ). The drying step helps in polymerizing dopamine [23] partially, as observed by the change in color of the support from white to brown. A similar approach was used to coat titania (1.6 mm diameter trilobe extrudates, V p = 0.63 cm 3 g -1 , S BET = 173 m 2 g -1 , d p = 17.2 nm) with Pdop to obtain Pdop/TiO 2 . Pdop coated TiO 2 is an orange solid. Pdop/SiO 2 and Pdop/TiO 2 supports used for the catalyst preparation contain Pdop loading of 13.8 wt% on SiO 2 and 6.4 wt% on TiO 2 .

Catalyst preparation

Series of CoMo/Pdop/SiO 2 and CoMo/SiO 2 catalysts with 10 or 20 wt% loading of MoO 3 (with respect to the oxide form of the catalysts) and Co/(Co+Mo) molar ratio of 0.3 were prepared by incipient wetness impregnation method and labelled as 10(20)%CoMo/Pdop/SiO 2 and 10(20)%CoMo/SiO 2 . Phosphomolybdic acid (H 3 PMo 12 O 40 .30H 2 O) and Co(NO 3 ) 2 .6H 2 O were used as precursors dissolved in ethanol. The solution containing the metal precursors was impregnated and left for maturation in an ethanol saturated atmosphere, at room temperature overnight. Then, the catalysts were dried in a rotary evaporator under reduced pressure (∼50 mbar) for 2 h at 40°C which yielded CoMo/Pdop/SiO 2 or CoMo/SiO 2. 10%CoMo/Pdop/TiO 2 and 10%CoMo/TiO 2 catalysts were also prepared using the same method described above. The catalysts were sulfided in gas-phase at atmospheric pressure before characterization. For sulfidation, catalysts were introduced in a glass reactor and heated from room temperature to 350°C with a ramp of 5°C min -1 with a plateau of 2 h, under a 15:85 v/v H 2 S/H 2 flow of 1.8 L g - 1 catalyst h -1 . At the end of the plateau, the reactor was cooled down to 50°C and the H 2 S/H 2 mixture was replaced by argon and the reactor was flushed for 15 min. Finally, the reactor was evacuated (∼1 mbar) and the cell was sealed. The sulfided catalysts are henceforth denoted as CoMoS/Pdop/(TiO 2 )SiO 2 and CoMoS/(TiO 2 )SiO 2 .

Catalysts characterization

Fourier transform infrared spectroscopy (FTIR), thermogravimetric analysis (TGA), textural, elemental (XRF and CHNS), in-situ XRD, electron probe microprobe analysis (EPMA), transmission electron microscopy (TEM), and X-ray photoelectron spectroscopy (XPS) analysis were performed as described before [18]. The results of elementary analysis are presented in Table 1. Targeted MoO 3 loadings were based on the oxide form of the bare support.

Solid state UV analysis

A double-beam Lambda 35 UV-Vis spectrophotometer from Perkin-Elmer equipped with an integrating Lab sphere RSA-PE-20 recording the spectra over 200-1000 nm range was used with a data interval of 2 nm. The spectra were recorded in reflectance mode. The parameters used were 4 nm s -1 as scan speed and 2 nm as slit width. Spectralon was used as a reference. Samples were prepared by mixing 10 mg of pure sample with 190 mg of BaSO 4 .

Catalytic tests 2.5.1 Hydrogenation of Toluene

The sulfided catalysts were evaluated in toluene hydrogenation (HYD) reaction in a fixed bed unit reactor Flowrence (Avantium), containing 16 parallel reactors, filled with 450 µL µL of the catalyst, as described before [18]. Briefly, the feed was composed of dimethyldisulfide (DMDS, 5.8 wt%) and toluene (20 wt%) in cyclohexane (74.2 wt%). The hydrogen to feed ratio (H 2 /HC) was 450 NL/L during the test and the in-situ presulfidation step, which was performed at 350°C with a liquid hourly space velocity (LHSV) of 4 h -1 and a total pressure of 60 bar for 2 h. After this presulfidation step, LHSV was reduced to 2 h -1 . The first order rate constant (k, h -1 ) was calculated by the following expression (1):

(1)

x is the percentage conversion of toluene (HYD) in the feed. LHSV is the liquid hourly space velocity (h -1 ). k (cm 3 mol Mo -1 h -1 ) is obtained by normalizing k with the number of moles of Mo present in the catalyst loaded in the test.

HDS of 3-methylthiophene (3-MT) and hydrogenation (HYD) of 2,3-dimethyl-2butene (2,3-DM2B): Model FCC gasoline feed test

The catalysts were also evaluated in selective HDS of model FCC gasoline test in the Flowrence unit from Avantium, using circa 300 µL of catalyst in each fixed bed reactor. The presulfidation of the catalysts was performed using a feed composed of DMDS (4 wt%) in nheptane (96 wt%), at a LHSV of 3 h -1 , at a total pressure of 15 bar, for 2 h, and with a hydrogen to feed ratio (H 2 /HC) of 300 NL/L. The temperature was increased from room temperature to 350°C with a ramp of 2°C min -1 . After the sulfidation step, the temperature was decreased to 190°C. The catalytic test was carried out with a feed composed of 2,3-DM2B (10 wt%), and 3-MT (0.3 wt%) dissolved in n-heptane (89.7 wt%), at a LHSV of 6 h -1 , with total pressure of 15 bar, and the hydrogen to feed ratio (H 2 /HC) of 300 NL/L. Later, the temperature was increased from 190 to 220°C with an increment of 10°C. The liquid products of the reaction were analyzed by gas chromatography using a DB1 column. The first order rate constant (k, h -1 ) was calculated by the following expression (2):

(2)

x is the conversion of 3-MT (HDS) or the hydrogenation of 2,3-DM2B (HYD). As previously described, k (cm 3 mol Mo -1 h -1 ) is obtained by normalizing k with the number of moles of loaded Mo.

Results and Discussion

Coating of silica support with Pdop

Fourier Transform Infrared Spectroscopy (FTIR)

FTIR spectra of the SiO 2 and Pdop/SiO 2 supports prepared by impregnating the carrier with 6.4 or 13.8 wt% of dopamine-hydrochloride are shown in Fig. 1. The sharp peak at 3747 cm -1 corresponds to stretching vibrations of the isolated surface silanol (SiOH) groups on silica support [24]. This signal drops when Pdop loading increases, and at 13.8 wt% of Pdop, the majority of the free OH groups on SiO 2 has disappeared (Fig. 1c). Infrared bands between 1650 and 1400 cm -1 represent the vibration modes of aromatic rings indicative of the presence of single or condensed aromatic rings [25]. The band corresponding to ammonium ion (~1612 cm -1 ) stretching from dopamine-hydrochloride salt (Fig. 1d) has almost disappeared on Pdop/SiO 2 (Fig. 1b and1c), indicating the transformation of the salt form of dopamine. Further, drying conditions (90°C for 20 h) helped to polymerize dopamine at least partially [23], as witnessed from the transformation of color from white to brown.

Thermogravimetric and Solid-state UV analysis

The thermal degradation profiles of 6.4 wt%Pdop/SiO 2 and 13.8 wt%Pdop/SiO 2 are depicted in Fig. 2. The free dopamine-hydrochloride decomposes at about 330°C (Fig. S1), whereas 6.4 wt%Pdop/SiO 2 and 13.8 wt%Pdop/SiO 2 decomposes only partially at 330°C. The partial decomposition at 330°C reveals the presence of free or unpolymerized dopamine. However, the decomposition behavior continues up to 700°C. This is a clear indication of the presence of polymerized/oligomerized dopamine, which undergoes thermal degradation at temperatures higher than 330°C. Further, solid-state UV analysis of the Pdop/SiO 2 support (Fig. S2) showed an absorbance band at about 280 nm corresponding to catechol groups of dopamine [19]. In addition, an increase in absorbance in the region of 400-800 nm which is characteristic for the polymerization of dopamine, arising from different functional groups in Pdop was also observed [26].

Textural Analysis

Nitrogen physisorption isotherms of SiO 2 and 13.8 wt%Pdop/SiO 2 supports are displayed in Fig. 3 (while usual BET surface area, pore volume and pore diameter are presented in Table S1). The amount of adsorbed N 2 , normalized by the volume of the support [27] (obtained by multiplying the grain density with the weight of the carrier), does not change much when SiO 2 is coated with 13.8 wt%Pdop. This indicates that the dopamine coating does not reduce the pore volume. The shape of the isotherm is preserved, corresponding to type IV with H1 hysteresis before and after Pdop coating. The N 2 isotherms suggests that we obtain a homogeneous coating of the surface, with no pore blocking effect.

CoMo supported on Pdop coated SiO 2

Both the pure and Pdop modified silica supports were impregnated with Mo and Co precursors using ethanol as the solvent as described in the experimental section. These catalysts were characterized by electron probe microanalysis to analyze the distribution of metal precursors within the extrudates. Distribution profiles of Mo, Co, and P in the cross section of 20%CoMo/Pdop/SiO 2 and 20%CoMo/SiO 2 extrudates (Figs. S3-S4) in the oxide form of the catalysts showed that all the elements were homogeneously distributed. CHNS analysis results (Table 1) obtained on the CoMoS/13.8 wt%Pdop/SiO 2 catalysts showed that part of the carbon from Pdop (2.4 to 5.3 wt%) is still present after sulfidation. N 2 physisorption measurements on 20%CoMoS/SiO 2 and 20%CoMoS/Pdop/SiO 2 sulfided catalysts displayed no significant difference for the adsorbed N 2 volume (Figs. S5-6, See Table S1 for usual BET surface area, pore volume and pore diameter). It is important to note that despite of the presence of carbonaceous deposit after sulfidation, no pore blocking effect is detected in this study, in contrast to other studies on carbon coated supports reported in literature [28,29].

XRD analysis: In-situ sulfidation of CoMo catalysts supported on SiO 2 and Pdop/SiO 2

The sulfidation of Mo and Co supported on SiO 2 and Pdop/SiO 2 (20 wt% of targeted MoO 3 loading) was analyzed in-situ by XRD, to follow the formation of MoS 2 and Co 9 S 8 crystalline phases with the increase in temperature (Fig. 4). The formation of a crystalline MoS 2 phase begins gradually on both supports above 200°C. The increase in the intensity of the XRD reflections with temperature follows a similar trend for both supports, showing that the Pdop coating does not modify significantly the formation and growth of sulfide crystals, despite the complexation of Mo ions with catechol groups in Pdop (Figs. 4a and4b) [30]. The height of the (002) peak calculated from Debye-Scherrer equation for crystalline MoS 2 was used to get information about the stacking of MoS 2 slabs on both supports [31]. The (002) peak of MoS 2 is broader and has a lower intensity on Pdop/SiO 2 (Fig. 4a) than on pure SiO 2 (Fig. 4b), i.e. the MoS 2 stacking on the Pdop/SiO 2 support is lower (Fig. S7, considering the Mo-Mo d-spacing of (002) crystal plane as 6.5 Å for a single MoS 2 layer [32]). Since stacking and dispersion are generally anti-correlated, MoS

TEM results

The mean slab length and stacking of MoS 2 nanocrystallites were determined from a statistical treatment of the TEM images. At both low and high Mo loadings, the stacking of the MoS 2 slabs on Pdop/SiO 2 is significantly lower than on the corresponding bare SiO 2 supports (See Figs. 5 and6, and Table 2) in agreement with previous XRD results. The representative TEM micrographs reveal that, on pure SiO 2 , more aggregation/clusters of MoS 2 slabs are observed (dark zones on representative images at low and high magnifications, Figs. 5a-b), compared to the Pdop-coated support (representative images, Figs. 5c-d). The impact of dopamine on the average slab length is less obvious since it slightly decreases at low Mo loading, but marginally increases at high Mo loading (Table 2).

XPS results on CoMoS catalysts supported on SiO 2 and Pdop/SiO 2

The binding energies of Mo and Co ions in the sulfided (CoMoS) catalysts with/without Pdop were evaluated by XPS. In the case of Mo, the XPS spectra allow distinguishing MoS 2 , MoO 3 and a species with an intermediate binding energy, a Mo-oxysulfide. Results from XPS (Table 3) do not show any observable difference in the degree of sulfidation of Mo ions for all the catalysts (both at low and high Mo loadings). However, at 10% MoO 3 loading, the amount of Co 9 S 8 phase is much lower on Pdop/SiO 2 when compared to that on pure SiO 2 , consequently, increasing the decoration ratio of MoS 2 slabs by Co, i.e. the CoMoS phase (+ 57%). On the contrary, at high Mo loading, there is no significant difference in the distribution of Co ions present on pure SiO 2 and Pdop/SiO 2 .

Hydrogenation of toluene

At both low and high Mo loadings, the conversion of toluene using the Pdop/SiO 2 support increases by 30-40% when compared with the catalysts supported on pure SiO 2 (Fig. 9). Consequently, the corresponding first order rate constants normalized per mole of Mo loaded in the reactor (k') increased by a factor of about 1.5 to nearly 2 showing a large increase of the intrinsic activity. At high Mo loading, k' decreases on both Pdop/SiO 2 and pure SiO 2 , indicating that the active catalytic sites does not increase proportionally with the Mo content.

HDS of 3-methylthiophene (3-MT) versus HYD of 2,3-dimethyl-2-butene (2,3-DM2B)

Selective removal of sulfur from (benzo)thiophene derivatives while avoiding the hydrogenation of olefins (HYD), is a key requirement in the selective FCC gasoline hydrotreating. The competitive conversion of 3-MT (HDS) versus HYD of 2,3-DM2B is used as a test reaction to evaluate the different CoMoS catalysts. At both low and high Mo loading, CoMoS catalysts supported on 13.8 wt%Pdop/SiO 2 showed an increase in the conversion by a factor of about two for both HDS and HYD reactions compared to their counterparts supported on pure SiO 2 . For both low and high Mo loadings, the first order rate constants (k', Table 4) for 3-MT conversion using CoMoS supported on Pdop/SiO 2 increased by a factor of about 2 when compared to that of CoMoS on pure SiO 2 . The k' for HYD of 2,3-DM2B increased by a factor of about 2.5 to 3 (Table 4). Selectivity graph for the conversions of 3-MT and HYD of 2,3-DM2B is presented in Fig. 10. The selectivity for 3-MT conversion is slightly decreased at low Mo loading, whereas, at high Mo loading the selectivity is intact. That means Pdop allows to increase the activity without any significant loss of selectivity which is quite unusual.

Table 4

First order rate constants normalized by moles of Mo in the catalyst (k') for HDS of 3-MT and 2,3-DM2B for the CoMoS catalysts supported on SiO 2 and Pdop/SiO 2 .

Catalysts

k' (HDS) (cm 3 mol (Mo) -1 h -1 ) k' (HYD) (cm 3 mol (Mo) -1 h -1 )
------20%CoMoS/SiO 2  20%CoMoS/Pdop/SiO 2

CoMo supported on Pdop coated titania and its catalytic activity

Pdop/TiO 2 was prepared by impregnating the carrier with 6.4 wt% of dopaminehydrochloride. The FTIR spectrum showed that the peak around 3600 cm -1 corresponding to stretching vibrations of the hydroxyl groups on TiO 2 support [33] considerably decreased upon Pdop coating (Fig. S8), evidencing the modification of titania surface by Pdop. The results from thermogravimetric analysis showed partial polymerization of dopamine (Fig. S9), similar to that on Pdop/SiO 2 (Fig. S1). In addition, Pdop/TiO 2 appeared in orange color, in contrast to the black or dark brown color (typical color for Pdop) for Pdop/Al 2 O 3 and Pdop/SiO 2 . It is well documented in literature that titania binds strongly with the catechol groups of dopamine in a bidentate geometry [34]. The solid-state UV analysis of the Pdop/TiO 2 support showed the ligand-to-metal charge transfer complex formation between TiO 2 and catechol groups [35] extended the absorption into the visible light region as apparently indicated by the color change (Fig. S10).

As previously described, the Pdop/TiO 2 and bare TiO 2 supports were impregnated with Mo and Co precursors (10 wt% of targeted MoO 3 loading) using ethanol as the solvent. TEM analysis (Figs. S11-12 and Table S2) revealed that the dopamine-coating increases the mean slab length of MoS 2 nanocrystallites (from 3.1 nm on bare TiO 2 to 3.7 nm on Pdop/TiO 2 ). The stacking of MoS 2 slabs (~1.6) was similar on both supports. It can be concluded from TEM results that the number of exposed edge atoms of MoS 2 decreases with the addition of Pdop. XPS study (Table S3) showed that the degree of sulfidation of Mo ions on Pdop/TiO 2 (77 %) is slightly better when compared that on bare TiO 2 (68 %). However, the percentage of catalytically inactive Co 9 S 8 phase is somewhat higher on Pdop/TiO 2 (11%) when compared to pure TiO 2 (4%).

The conversion of toluene using CoMoS catalysts with Pdop was lower than the catalysts on pure TiO 2 and, the corresponding first order rate constants normalized per mole of Mo loaded in the reactor (k') were reduced by 20-30% (Fig. 11). Dopamine polymerizes easily on Al 2 O 3 , since the point of zero charge (PZC) of this amphoteric support is about pH 9. Al 2 O 3 surface hydroxyls act as basic groups when contacting with the slightly acidic dopamine solution, raising the pH to mild basic conditions required for dopamine polymerization. As a result, Pdop covers the surface of Al 2 O 3 , further preventing the interaction of metallic precursors with surface OH groups [18]. In the case of SiO 2 , dopamine is not expected to polymerize as it was observed in the case of Al 2 O 3 , because the PZC of SiO 2 is about pH 3 far from the basic conditions required for total polymerization. Nevertheless, it has been shown by FTIR that dopamine moieties cover the surface silanol groups. Further, TGA and UV-Vis measurements showed a partial polymerization, likely to occur during drying step in the presence of oxygen from air [23]. The degree of polymerization of dopamine is lower on silica than on alumina as evidenced from TGA and UV-Vis analysis (Fig. S2). A similar behavior is observed for TiO 2 , even though its PZC is in the range of pH 5-6.

When Mo precursors are added to Pdop coated Al 2 O 3 or SiO 2 , the catechol groups present in Pdop form a complex with the Mo ions [30]. Consequently, Mo is distributed evenly on the Pdop coated surface of the support. However, in the case of TiO 2 , there is a strong bidentate complex formation between the catechol groups of dopamine and Ti +IV [34]. This strong complexation is much less pronounced for Al 2 O 3 and SiO 2 supports. Hence, Pdop functional groups are available to interact with metallic precursor helping the dispersion. On the other hand, on TiO 2 due to strong complexation with Ti +IV , these groups are no longer able to stabilize Mo precursors leading to sintering of MoS 2 crystallites. Further, from FTIR spectra of Al 2 O 3 , SiO 2 , and TiO 2 at similar Pdop loading (6.4 wt%), it was observed that the contribution from catechol (OH) groups above 3300 cm -1 is considerably lower on TiO 2 when compared than on Al 2 O 3 and SiO 2 (Fig. S13), in agreement with the above hypothesis. Convincingly, the nature of the interaction between the support and the Pdop functional groups plays a decisive in improving the dispersion of the MoS 2 crystallites.

Effect of Pdop coating on catalytic activity

CoMoS catalysts supported on Pdop/SiO 2 were systematically more active in the hydrogenation of toluene and FCC gasoline model molecules than the catalysts supported on bare SiO 2 . The higher activities of the catalysts supported on Pdop/SiO 2 could arise from different factors, which are discussed in the following.

In our previous study, CoMoS supported on Pdop/Al 2 O 3 also showed enhancement in catalytic activity mainly due to the better dispersion of MoS 2 slabs and the prevention of direct detrimental metal support interaction, owing to the presence of carbon adlayer between the support and metal [18]. Comprehensively, a similar explanation holds true in the case of CoMoS/Pdop/SiO 2 . The low metal-support interactions of SiO 2 favor the stacking of MoS 2 sheets [36]. The Pdop coating significantly reduced the stacking (revealed by in-situ XRD and TEM measurements), at both low and high Mo loadings (Table 2). This behavior is quite unusual. Carbon-coated supports generally show higher stacking number when compared to the bare support due to the poor interaction of the carbon interface and the metal precursors [37]. With a Pdop coating, the stacking effect has been circumvented: thanks to the presence of Pdop functional groups, MoS 2 slabs are more regularly distributed on the surface of silica support converting a poor dispersing oxide surface into a highly dispersing carbonaceous deposit. Though the degree of polymerization is lower on silica than on alumina, the catalytic activity is consistently higher on both silica and alumina, indicating polymerization is not a critical factor in improving the catalytic efficiency. We presume that the better dispersion on the support surface is the main reason for the observed increase in catalytic activity.

The presence of carbon in the sulfided CoMo on Pdop/SiO 2 could also lead to enhancement in catalytic activity. On Pdop coated SiO 2 , Mo ions complexes with catechol groups present in Pdop [30]. Upon sulfidation though the complex decomposes, but still leaves carbonaceous deposit in the catalyst (at least 40% of carbon from the initial carbon content in Pdop) even after sulfidation step, with no pore blocking effect and keeping textural properties intact. This carbon is most probably present as an adlayer on SiO 2 , thereby avoiding direct contact of MoS 2 nanocrystallites with SiO 2 . Consequently, now MoS 2 is most possibly present on carbon like support. CoMoS phase on carbon supports generally belongs to type-II [16,38], which is characterized by weak van der Waals' interactions between the active sulfide and the support and a high intrinsic activity.

There was no direct evidence observed for an increase of Co-promoted edge sites [39] (CoMoS from XPS) on Pdop/Al 2 O 3 , which would contribute to the increase in catalytic inactivity. At low Mo loading, the MoS 2 slab length was reduced (TEM results, Table 2) and the degree of promotion was enhanced on Pdop/SiO 2 leading to an increase in CoMoS (+ 57%) sites (XPS results, Table 3) compared to pure SiO 2 . However, these features were not observed on Pdop/SiO 2 with high Mo loading. Therefore, it is not expected to be the primary reason for the increase in catalytic activity.

The poor performance of catalysts supported on Pdop/TiO 2 could be attributed to the following factors: (i) catechol groups on dopamine form strong bonds with Ti and that causes change in the electronic properties of TiO 2 , owing to the direct catechol-to-TiO 2 charge transfer [40], (ii) as catechol groups binds to titania, the number of binding sites for Mo decreases that led to the sintering of MoS 2 nanocrystallites, (iii) results from TEM showed that the MoS 2 slab length strongly increases on Pdop/TiO 2 , which eventually decreases the active phase on the edge sites of MoS 2 slabs, and (iv) XPS results showed that percentage of Co 9 S 8 phase on Pdop/TiO 2 is higher, as a result, the number of Co ions decorating the edge sites of MoS 2 slabs is smaller.

Conclusion

In conclusion, we have demonstrated a bio-inspired, facile method to coat SiO 2 and TiO 2 with Pdop. The nature of the interaction between the support and the Pdop functional groups plays a key role in the dispersion of the MoS 2 crystallites. On Pdop/SiO 2 , as there is no strong interaction between the support and Pdop, functional groups on Pdop helps in dispersing metal precursors. In-situ XRD measurements and TEM analysis confirmed that majority of MoS 2 slabs are present in the catalysts as single or double slabs resulting in better repartition on Pdop/SiO 2 than on pure SiO 2 . Despite of the presence of carbon residues in the sulfided catalysts, textural properties were intact, indicating the homogeneous deposition on the surface of the support. The CoMoS catalyst on Pdop coating increases the first order rate constants (k') for toluene hydrogenation, conversions of 3-MT, and HYD of 2,3-DM2B by a factor of about 2 than its counterpart on pure SiO 2 . The improved activity is attributed to the decreased aggregation of MoS 2 nanocrystallites leading to increase in edge site accessibility, and to the presence of carbonaceous adlayer between the active phase and the support limiting the direct interaction of metal precursors with the support. This coating strategy was less successful on TiO 2 owing to the stronger interaction of Pdop with titania decreasing its ability to disperse Mo active phase, consequently, decrease in catalytic activity. This point highlights the need for the appropriate interactions of the (oxidic carrier/Pdop/metallic precursors) system which have to be tuned in order to improve the final catalytic performances.

Fig. 1 .

 1 Fig. 1. FTIR spectra of (a) SiO 2 , (b) 6.4 wt%Pdop/SiO 2 , (c) 13.8 wt%Pdop/SiO 2 , and (d) dopaminehydrochloride after activating the samples at 90°C for 2 h.

Fig. 2 .

 2 Fig. 2. Thermogravimetric analysis of (a) 6.4 wt%Pdop/SiO 2 , and (b) 13.8 wt%Pdop/SiO 2 supports under H 2 gas.

Fig. 3 .

 3 Fig. 3. N 2 physisorption isotherms of SiO 2 and 13.8 wt%Pdop/SiO 2 .

2 Fig. 4 .

 24 Fig. 4. XRD diffraction patterns of MoS 2 and Co 9 S 8 phases on (a) Pdop/SiO 2 and (b) pure SiO 2 obtained during in-situ sulfidation of the oxide catalysts.

Fig. 5 .Fig. 6 .

 56 Fig. 5. TEM images of sulfided catalysts: a-b) 20%CoMoS/SiO 2 and c-d) 20%CoMoS/Pdop/SiO 2 .

2 

 2 10%CoMo/Pdop/SiO 2  20%CoMoS/SiO 2  20%CoMoS/Pdop/SiO 2

Fig. 9 .

 9 Fig. 9. (a) Conversion and (b) first-order rate constants (k') normalized by the moles of Mo in the catalysts for toluene hydrogenation at 350, 370 and 390°C using 10 and 20 wt% of targeted MoO 3 loading on Pdop/SiO 2 and SiO 2 .

2 

 2 10%CoMoS/Pdop/SiO 2 ------20%CoMoS/SiO 2  20%CoMoS/Pdop/SiO 2

Fig. 10 .

 10 Fig. 10. Conversion in HYD of 2,3-dimethyl-2-butene versus conversion of 3-methylthiophene at 190, 200, 210 and 220°C using a) 10 wt% and b) 20 wt% of targeted loading on Pdop/SiO 2 and SiO 2 .

Fig. 11 . 1

 111 Fig.11. First-order rate constants (k') normalized by the moles of Mo in the catalysts for toluene hydrogenation at 350, 370 and 390°C using 10 wt% of targeted loading of MoO 3 .

Table 1

 1 %wt of (i) Mo and Co in the catalyst before sulfidation from XRF analysis, and (ii) C and S in the sulfide catalysts from CHNS analysis. MoO 3 and CoO contents of these catalysts are from the sulfided catalysts. n.d. not detected.

	Catalysts	Targeted MoO 3 wt%	Mo wt%	Actual MoO 3 wt%	a	Co wt%	S wt%	C wt%
	10%CoMo/SiO 2	10	5.7	8.5		1.5	5.9	n.d.
	10%CoMo/Pdop/SiO 2	10	6.0 	9.0 		1.6 	5.5	5.3
	20%CoMo/SiO 2	20	10.6	15.8		2.8	11.0	n.d.
	20%CoMo/Pdop/SiO 2	20	11.9 	17.8 		3.1 	10.4	2.4
	10%CoMo/TiO 2	10	5.4	8.1		1.8	7.2	n.d.
	10%CoMo/Pdop/TiO 2	10	4.8	7.1		1.5	6.4	0.9
	 a MoO 3 wt%
	was calculated from the measured Mo wt% from XRF.

  2 slabs are expected to be more dispersed on Pdop/SiO 2 than on pure SiO 2 . The formation of a crystalline Co 9 S 8 phase starts above 400°C, and follows a similar trend for both pure SiO 2 and Pdop/SiO 2 . Above 400°C, it is most likely that the Co ions present in the CoMoS starts to segregate from the sintering MoS 2 slabs (which reduces the amount of Co that can decorate the edges of the slabs) and form the thermodynamically stable Co 8 S 9 phase.

		300 350		400 °C 600 °C 500 °C		(a)		(440)	(110) MoS 2
	(a.u) Intensity	100 150 250	(002) MoS 2	300 °C 200 °C 100 °C 25 °C	(311) Co 9 S 8	(100/101) MoS 2	(103) MoS 2	Co 9 S 8
		50
		0
		10		20		30	40	50	60	70
						2-Theta (°)
		350
		300		600 °C 500 °C			(b)		(110) MoS 2
	Intensity (a.u.)	150 200 250	(002) MoS 2 400 °C 300 °C 200 °C 100 °C 25 °C	(331) Co 9 S 8	(100/101) MoS 2	(103) MoS 2	(440) Co 9 S 8
		50
		0
		10		20		30	40	50	60	70
						2-Theta (°)

Table 2

 2 Average slab length and stacking CoMoS catalysts supported on SiO 2 and Pdop/SiO 2 determined by TEM. The ± interval indicates the width of the distribution and not the uncertainty of the average slab length and stacking.

	Catalysts	Slab length (nm)	Average Stacking
	10%CoMoS/SiO 2	4.7 ± 2.2	2.5 ± 1.1
	10%CoMoS/Pdop/SiO 2	3.8 ± 1.5	1.4 ± 0.6
	20%CoMoS/SiO 2	3.7 ±	2.9 ± 1.1
	20%CoMoS/Pdop/SiO 2	4.2 ± 1.7	2.1 ± 0.9

Table 3

 3 Metal distribution for cobalt and molybdenum species present at the surface of sulfided CoMoS supported on SiO 2 and 6.4 wt%Pdop/SiO 2 obtained from XPS analysis.

	Atomic

Ratio Mo species (% relative) Co species (% relative) S species (% relative) Atomic ratio Catalyst Co:Mo Slabs MoS 2 MoO x S y Mo +VI Co 9 S 8 CoO CoMoS S Sulf S Ox Co:Mo total

	10%CoMoS/ SiO 2	0.17	77	13	10	52	25	23	84	16	0.58
	10%CoMoS/ Pdop/SiO 2	0.28	78	13	9	38	26	36	86	14	0.61
	20%CoMoS/ SiO 2	0.34	78	13	9	24	31	45	88	12	0.59
	20%CoMoS/ Pdop/SiO 2	0.29	78	13	9	25	29	46	87	13	0.49
	3.3

Catalytic tests on SiO 2 -and Pdop/SiO 2 -supported catalysts.

Acknowledgements

Anne Boffo is thanked for the technical help in the laboratory. Sylvain Carbonneaux, Mickaël Rivallan, Anne-Sophie Gay, Christèle Legens and their technical teams are acknowledged for XRF, FTIR, XRD, TEM, and XPS measurements. We are grateful for Mathieu Vidalie for his support in performing catalytic tests. We express our gratitude to Eric Puzenat for his assistance with solid state UV-VIS analysis.

Supplementary Material

Click here to download Supplementary Material: SI-Applied Catal. A_latest version.docx


Vitaly Buravlev
email: vitaly.buravlev@imtlucca.it

Rocco De Nicola
email: rocco.denicola@imtlucca.it

Claudio Antares Mezzina
email: claudio.mezzina@imtlucca.it

Tuple spaces implementations and their efficiency

Among the paradigms for parallel and distributed computing, the one popularized with Linda and based on tuple spaces is the least used one, despite the fact of being intuitive, easy to understand and to use. A tuple space is a repository of tuples, where process can add, withdraw or read tuples by means of atomic operations. Tuples may contain different values, and processes can inspect the content of a tuple via pattern matching. The lack of a reference implementations for this paradigm has prevented its widespread. In this paper, first we do an extensive analysis on what are the state of the art implementations and summarise their characteristics. Then we select three implementations of the tuple space paradigm and compare their performances on three different case studies that aim at stressing different aspects of computing such as communication, data manipulation, and cpu usage. After reasoning on strengths and weaknesses of the three implementations, we conclude with some recommendations for future work towards building an effective implementation of the tuple space paradigm.

Introduction

Distributed computing is getting increasingly pervasive, with demands from various applications domains and highly diverse underlying architectures from the multitude of tiny things to the very large cloud-based systems. Several paradigms for programming parallel and distributed computing have been proposed so far. Among them we can list: distributed shared memory, message passing, actors, distributed objects and tuple spaces. Nowadays, the most used paradigm seems to be message passing, with MPI [START_REF] Barker | Message Passing Interface (MPI)[END_REF] being its latest incarnation, while the least popular one seems to be the one based on tuple space that was proposed by David Gelernter for the Linda coordination model [START_REF] Gelernter | Generative communication in Linda[END_REF].

As the name suggests, message passing provides coordination abstractions based on the exchange of messages between distributed processes, where message delivery is often mediated via brokers and messages consist of a header and a body. In its simplest incarnation, message-passing provides a rather lowlevel programming abstraction for building distributed systems. Linda, instead provides a higher level of abstraction by defining operations for synchronization and exchange of values between different programs that can share information by accessing common repositories named tuple spaces.

The key ingredients of Linda are few basic operations which can be embedded into different programming languages. These are atomic operations used for writing (out), withdrawing (in), reading (rd) tuples into/from a tuple space. The operations for reading and withdrawing select tuples via pattern-matching. Another operation eval is used to spawn new processes. The figure above illustrates an example of tuples space with different, structured, values. For example tuple "goofy", 4, 10.4 is produced by a process via the out( "goofy", 4, 10.4 ) operation, and it is read by the operation rd("goofy", , ) after pattern-matching: that is the process reads any tuple of three elements whose first one is exactly the string "goofy". Moreover, tuple 10, . . . is consumed (atomically retracted) by operation in (10, x) which consumes a tuple whose first element is 10 and binds its second element (whatever it is) to the variable x. Patterns are sometimes referred as templates.

The simplicity of this coordination model makes it very intuitive and easy to use. Some synchronization primitives, e.g. semaphores, barrier synchronization, can be implemented easily in Linda (cf. [START_REF] Carriero | How to write parallel programs -a first course[END_REF], Chapter 3). Unfortunately Linda's implementations of tuple space have turned out to be quite inefficient, and this has led researchers to opt for different approaches such Open MP or MPI, which are nowadays offered, as libraries, for many programming languages. When considering distributed applications, the limited use of Linda coordination model is also due to the need of keeping tuple spaces consistent. In fact, in this case, control mechanisms that can affect scalability are needed [START_REF] Ceriotti | Data sharing vs. message passing: Synergy or incompatibility? an implementation-driven case study[END_REF].

In our view, tuple spaces can be effectively exploited as a basis for the broad range of the distributed applications with different domains (from lightweight applications to large cloud based systems). However, in order to be effective, we need to take into account that performances of a tuple space system may vary depending on the system architecture and the type of interaction between its components. The aim of this paper is to examine the state of the art implementations of tuple spaces, and to find out strengths and weaknesses.

We start by cataloguing the existing implementations according to their features, and then we focus on the most recent Linda based systems that are still maintained, while paying specific attention to those featuring decentralized tuples space. For the selected systems, we compare their performances on three different case studies that aim at stressing different aspects of computing such as communication, data manipulation, and cpu usage. After reasoning on strength and weakness of the three implementations, we conclude with some recommendation for future work towards building effective implementation of the tuple space paradigm.

Tuple space systems

In this Section, first we review several existing tuple space systems by briefly describing each of them, and single out the main features of their implementations, then we summarise these features in Table 1. Later, we focus on the implementations that enjoy the characteristics we consider important for a tuple space implementation: code mobility, distribution of tuples and flexible tuples manipulation.

JavaSpaces. JavaSpaces [START_REF] Microsystems | JS -JavaSpaces Service Specification[END_REF] is one of the first implementations of the tuple space developed by Sun Microsystems. It is based on a number of Java technologies (Jini, RMI). As a commercial system, JavaSpaces supports transactions and mechanism of tuple leases. A tuple, called entry in JavaSpaces, is an instance of a Java class and its fields are the public fields of the class. This means that tuples are restricted to contain only objects but not primitive values. The tuple space is implemented by using a simple Java collection. Pattern matching is performed on the byte level, and the byte level comparison of data supports object-oriented polymorphism.

TSpaces. TSpaces [START_REF] Lehman | Tspaces: The next wave[END_REF] is an implementation of the Linda model at the IBM Almaden Research Center. It combines asynchronous messaging with database features. Like JavaSpaces, TSpaces provides transactional support and mechanism of tuple leases. Moreover, the embedded mechanism for access control to tuple spaces is based on access permission. It checks whether a client is able to perform specific operations in the specific tuples space. Pattern matching is performed using either standard equals method or compareTo method. Patter matching uses SQL-like queries, allowing to match tuples regardless of their structure (e.g. the order in which fields are stored). [START_REF]Concepts -XAP 9.0 Documentation -GigaSpaces Documentation Wiki[END_REF] is a contemporary commercial implementation of tuple space. Nowadays, the core of that system is GigaSpaces XAP, a scale-out application server and any user application should interact with it for creating and manipulating its own tuple space. The main areas where GigaSpaces can be applied are concerned with big data analythics. GigaSpaces main features are: linear scalability, optimization of RAM usage, synchronization with databases and several database-like operations such as complex queries, transactions and replication.

GigaSpaces. GigaSpaces

Tupleware. Tupleware [START_REF] Atkinson | Tupleware: A Distributed Tuple Space for the Development and Execution of Array-based Applications in a Cluster Computing Environment[END_REF] is specially designed for array-based applications in which an array is decomposed into several parts each of which can be processed in parallel. It aims at developing a scalable distributed tuple space with good performance on a computing cluster and provides clear and simple programming facilities for dealing with distributed tuple space as well as with centralized one. The tuple space is implemented as a hashtable, containing pairs consisting of a key and a vector of tuples. Due to the nature of Jave hashtable, it is possible to access concurrently several elements of the hashtable, since synchonisation is at the level of hashtable element. To speed up the search in the distributed tuple space, an algorithm based on the history of communication is used. Its main aim is to minimize the number of communications between nodes for tuples retrieval. The algorithm uses success factor, a real number between 0 and 1, expressing the likelihood of the fact that a node can find a tuple in the tuple space of other nodes. Each instance of Tupleware calculates success factor on the basis of past attempts to get information from other nodes and tuples are first searched in nodes with greater success factor. Grinda. Grinda [START_REF] Capizzi | A Tuple Space Implementation for Large-Scale Infrastructures[END_REF] is a distributed tuple space which was designed for large scale infrastructures. It combines Linda coordination model with grid architecture aiming at improving performance of distributed tuple space, especially with a large amount of tuples. To boost the search of tuples, Grinda utilizes spatial indexing schemes (X-Tree, Pyramid) which are usually used in spatial databases and Geographical Information Systems. Distribution of tuple spaces is based on the grid architecture and implemented using structured P2P network (based on Content Addressable Network and tree based).

Blossom. Blossom [START_REF] Van Der Goot | High Performance Linda Using a Class Library[END_REF] is a C++ implementation of Linda which was developed to achieve high performance and correctness of the programs using Linda model. In Blossom all tuple spaces are homogeneous with predefined structure, and this allows spending less time for type comparison during the search. To improve scalability, Blossom uses distributed tuple spaces and each processor is assigned a particular tuple space by considering tuple values. The technique of prefetching allows a process to send a request for some tuples to the tuple space and to continue its work while the search continues. When the process needs the requested tuples, it receives them without waiting and spending time for their search which have been already done.

DTuples. DTuples [START_REF] Jiang | Dtuples: A distributed hash table based tuple space service for distributed coordination[END_REF] is designed for peer-to-peer networks and based on distributed hash table (DHT), a scalable and efficient approach. Key points of DHT are autonomy and decentralization. There is no central server and each node of DHT is in charge of storing a part of hash table and of keeping routing information about other nodes. As the basis of the DTH's implementation DTuples uses FreePastry1 . DTuples also supports transactions and guarantees fault-tolerance via replication mechanisms. DTuples supports multi tuple spaces and distinguishes public and subject tuple spaces. Public tuple space is a space shared among all the processes and all of them can perform any operation on it. Subject tuple space is a private space accessible only by the processes that are bound to it. Any subject space can be bound to several processes and can be removed if no process is bound to it. Due to the two types of tuple spaces, pattern matching is specific for each of them. Templates in the subject tuple space can match tuples in the same subject tuple space and in the common tuple space. However, the templates in the common tuple space cannot match the tuple in the subject tuple spaces. [START_REF] Leal | Luats a reactive event-driven tuple space[END_REF] is a reactive event-driven tuple space system written in Lua. Its main features are associative mechanism of tuple retrieving, fully asynchronous operations and support of code mobility. LuaTS provides centralized management of the tuple space which can be logically partitioned into several parts using indexing. LuaTS combines Linda model with event-driven programming paradigm. This paradigm was chosen to simplify program development which allows avoiding the use of synchronization mechanisms for tuple retrieval and makes more transparent programming and debugging of multi-thread program. Tuples can contain any data which can be serialized in Lua, including strings with function code. In order to obtain a more flexible and intelligent search, function code can be sent to the server and once executed it can returns the matched tuples. Reactive tuple space is implemented as a hashtable, in which along with data also information supporting the reactive nature of that tuple space (templates, client addresses, ids of callback and so on) is stored.

LuaTS. LuaTS

Klaim. Klaim [START_REF] Bettini | The klaim project: Theory and practice[END_REF] (the Kernel Language for Agents Interaction and Mobility) is an extension of Linda supporting processes migration. The emphasis of Klaim is on process mobility, which means that processes as any data can be moved from one locality to another and they can be executed in any localities. Klava is a Java implementation of Klaim [START_REF] Bettini | Implementing mobile and distributed applications in X-Klaim[END_REF]. Klaim supports multiple tuple spaces and operates with explicit localities where processes and tuples are allocated. In this way, several tuples can be grouped and stored in one locality. Moreover, all the operations on tuple spaces are parametric to localities. Emphasis is put also on access control which is important for mobile applications. For this reason Klaim introduces type system which allows checking whether a process can perform an operation at specific localities.

In order to compare the implementations we have discussed so far, we have singled out the following criteria: Distributed tuple space This criterion denotes whether tuple spaces are stored in one single node of the distributed network or they are spread across the network. Decentralized management Distributed systems rely on a node that controls the others or the control is shared among several nodes. Usually, systems with the centralized control have bottlenecks which limit their performance. Tuples clustering This criterion determines whether some tuples are grouped by particular parameters that can be used to determine where to store them in the network. Domain specificity Many of implementations have specific area in which they can be used. If the implementation is domain specific it can be good because it is more suitable for it and has an advantage over other ones. On another side, this feature could be considered a limitation if one aims at generality. Scalability This criterion implies that system based on particular Linda implementation can cope with the increasing amount of data and nodes while maintaining acceptable performance. Security This criterion specifies whether an implementation has security features or not. eval operation This criterion denotes whether the tuple space system has implemented the eval operation.

Table 1 summarises the result of our comparison:

means that the implementation enjoys the property and ? means that we were not able to provide an answer, since the source code was not available.

An extra requirement to be able to compare implementations (especially in terms of time) is that they have to be written in the same language. We have chosen Java, since nowadays it is the most used language. Moreover, using a single programming language allows us to develop case studies as skeletons: the code remains the same for all the implementations, only the invocations of different library methods do change. This choice, guarantees also the possibility of performing better comparisons of the time performances exhibited by the different tuple systems which could be significantly depend the chosen language.

After considering the results in Table 1, to perform our detailed experiments we have chosen: Tupleware which enjoys most of the selected features; Klaim since it offers distribution, clustering of tuple spaces and code mobility. Finally, we have chosen GigaSpaces because it is the most modern among the commercial systems; it will be used as a yardstick to compare the performance of Tupleware and Klaim. We would like to add that DTuples has not been considered for the more detailed comparison because we have not been able to obtain its libraries or source code, and that Grinda has been dropped because it seems to be the less maintained one.

In all our implementations of the case studies, we have structured the systems by assigning each process a local tuple space. Because GigaSpaces is a centralized tuple space, in order to satisfy this rule we do not use it as centralized one, but as distributed: each process is assigned its own tuple space in the GigaSpaces server.

Experiments

Case studies

In order to compare different tuple space systems we have chosen 3 case studies: Password search, Sorting and Ocean model. The first case study is a communication intensive task where the number of tuples is large and it requires doing many reading and writing operations. The second case study is computation intensive, since each node spends more time for sorting elements than for communicating with the other nodes. This case study has been considered because it needs structured tuples that contains both basic values (with primitive type) and complex data structures that impact on the speed of the inter-process communication. The third case has been taken into account since it introduces particular dependencies among nodes, which if exploited can improve the application performances. This was considered to check whether adapting a tuple space system to the specific inter-process interaction pattern of a specific class of the applications could lead to significative performance improvements. All the case studies are implemented using master-worker paradigm [START_REF] Carriero | How to write parallel programs -a first course[END_REF]. Now we briefly describe them.

Password search. The main aim of the distributed application for password search is to find a password using its hashed value in the predefined distributed database. We have generated that database in the form of the files containing pairs of password and hashed value, for each password. The application creates a master process and several worker processes: the master keeps asking to the workers passwords corresponding to a specific hashed values, by issuing tuples of the form: "search task", dd157c03313e452ae4a7a5b72407b3a9

Each worker first loads its part of the distributed database, and after, it obtains from the master a task to look for the password corresponding to a hash value.

Once it has found the password, it sends the result back to the master process, with a tuple of the form: "found password", dd157c03313e452ae4a7a5b72407b3a9, 7723567 For multi tuple spaces implementations it is necessary to start searching in one local tuple space and then to check the tuple spaces of other workers. The application terminates its execution when all the tasks have been processed and the master has received all results.

Sorting. This distributed application consists of sorting arrays of integers. The master is responsible for loading initial data and for collecting the final sorted data, while workers are directly responsible for the sorting. At the beginning, the master loads predefined initial data to be sorted and sends them to one worker to start the sorting process. Afterwards, the master waits for the sorted arrays from the workers: when any sub-array is sorted the master receives it and builds the whole sorted sequence when all sub-arrays are collected. The behavior of workers is different; when they are instantiated, each of them starts searching for the unsorted data in local and remote tuple spaces. When a worker finds a tuple with data, it checks whether it is possible to sort these data (the size of the data is less than particular threshold). If it is possible to sort them, the worker does the computation, sends the result to the master and starts searching for other unsorted data. Otherwise, the worker splits the array into two parts: one part is stored into its local tuple space while the other is processed.

Ocean model. The ocean model is a simulation of the enclosed body of water. The core of that case study was given in [START_REF] Atkinson | Tupleware: A Distributed Tuple Space for the Development and Execution of Array-based Applications in a Cluster Computing Environment[END_REF]. The two-dimensional surface of water in the model is represented as a 2-D grid and each cell of the grid represents one point. The parameters of the model are current velocity and surface elevation which are based on a given wind velocity and bathymetry. In order to parallelize the computation, the whole grid is divided into vertical panels, and each worker owns one panel in order to compute its parameters. The aim of the case study is to simulate the body of water during several time-steps. At each time-step, in order to compute the new panel parameters, each worker has to take into account its neighbouring panels.

The mission of the master and workers are similar to the previous case studies. In the application the master instantiates the whole grids, divides it into parts and sends them to the workers. After all iterations, it receives all parts of the grid. Each worker receives its share of the grid and at each iteration it communicates with workers which have adjacent grid parts in order to update and recompute the parameters of its model; in the end it sends its data to the master.

Implementing case studies. Since we have chosen Java-based tuple space systems, all case studies are implemented in Java. Implementations of the three case studies require the use of synchronization to avoid conflicts while accessing to the same tuple space. GigaSpaces and Tupleware have built in synchronization mechanisms, while Klaim does not. To cope with it, for Klaim we implemented synchronizations, using standard Java synchronized blocks [START_REF]The Java Tutorials[END_REF], at the node/process level instead of modifying the source code of the core operation and applied it to local tuple space.

There is a difference in the implementation of the search among distributed tuple spaces. Tupleware has a built in operation with notification mechanism: it searches in local and remote tuple spaces once and then waits for the notification that the wanted tuple appears in one of the tuple spaces. The implementation of this operation for Klaim and GigaSpaces requires to continuously check each tuple space until the wanted tuple is found.

Methodology

All the conducted experiments are parametric with respect to two parameters. The first one is the number of workers taken into account with values 1, 5, 10, 15 and it tests how the different implementations scale up with concurrency. The second parameter is application specific, but its meaning is the same: testing the implementation when the workload increases. For the case study Password search we vary the number of the entries in the database (10000, 1000000 and 1 million passwords) where it is necessary to search the password. This parameter directly affects the number of local entries each worker has. Moreover, for this case study the number of password to find was fixed to 100. For the Sorting case, the second parameter is the number of elements in an array to be sorted (100000, 1 million, 10 million elements). In this case the number of elements does not correspond to the number of tuples because parts of array are transferred also as arrays of smaller size. For the case study Ocean model the second parameter is the grid size (300, 600 and 1200) which is related with computational size of the initial task.

Remark 1 (Execution environment). Our test were conducted on a server with 4 processors Intel Xeon E5620 (4 cores, 12M Cache, 2.40GHz, Hyper-Threading Technology ) with 32 threads in total, 40 GB RAM and installed Ubuntu 14.04.3. All applications are programmed in Java 8 (1.8.0). Measured metrics. For measurement of metrics Clarkware Profiler2 is used. We use manual method of profiling and insert methods Profiler.begin(label) and Profiler.end(label) surrounding parts of the code we are interested into program code in order to begin and stop counting time respectively. This sequence of the actions can be repeated many times and in the end we receive report which includes the number of calls, overall and average time. For each metrics the label is different and it is possible to use several of them simultaneously. Each set of experiments was conducted 10 times with randomly generated input and average values of each metrics were computed. To extensively compare the different implementations, we have chosen the following measures:

Local writing time: required time to write one tuple into local tuple space. Local reading time: required time to read or take one tuple from local tuple space using template. The parameter checks how fast pattern matching works. Remote writing time: time of the writing to the tuple space plus the time of communication with process associated with tuple space. Remote reading time: similarly to the previous one, this time is a sum of the time of the search in tuple space and the time of the communication with it. Search time: when the application has several workers we introduce the time which is required to find a tuple in a several separated tuple spaces. Total time: total execution time. This time does not include initial creation of tuple spaces or starting tuple space server as in the case of GigaSpaces. Number of visited nodes: number of visited before a necessary tuple was found.

Please notice that, all plots used in the paper report results of our experiments in a logarithmic scale. When describing the outcome, we have only used those plots which are more relevant to evidence the difference between the three tuple space systems 3

Results

Password search As shown in figure 1 GigaSpaces exhibits better performances than the other two tuple space systems.

Figure 2 depicts the local writing time for each implementation, with different numbers of workers. As we can see, by increasing the number of workers (which implies reducing the amount of local data to consider), the local writing time decreases. This is more evident in Tupleware, which really suffers when a big number of tuples (e.g. 1 million) is stored in a single local tuple space. The writing time of Klaim is the lowest among other systems and does not change significantly during any variation in the experiments. Local reading time is shown in Figure 3 and Klaim is the one that exhibits the worst performance for searching in local space. Indeed, if there is just one worker, the local reading time is 10 times greater than Tupleware. We conjecture that the pattern matching mechanism of Klaim is less effective than others. By increasing the number of workers the difference becomes less evident, even if it remains four times bigger than Tupleware. Since this case study requires little synchronization among workers, performance improves when the level of parallelism (the number of workers) increases.

Search time is similar to local reading time, but takes into account searching in remote tuple spaces. When considering just one worker, the search time is the same as the reading time in local tuple space, however, when the number of workers increases the search time of Tupleware and Klaim grows faster than the time of GigaSpaces. Figure 4 shows that GigaSpaces is more sensitive to the number of tuples than to the number of accesses to the tuple space.

It is worth to remark that the local tuple spaces of the three systems exhibit different performances depending on the operation on them: the writing time of Klaim is always significantly smaller than the others, while the pattern matching mechanism of Tupleware allows faster local searching.

Sorting Figure 5 shows that GigaSpaces exhibits significantly better execution time when the number of elements to sort is 1 million. When 10 million elements This case study is computation intensive but requires also exchange of structured data and, although in the experiments a considerable part of the time is spent for sorting, we have that performances do not significantly improve when the number of workers increases.

The performance of Klaim is visibly worse than others even for one worker. In this case, the profiling of the Klaim application showed that a considerable amount of time was spent to transmit initial data from the master to the worker. Inefficient implementation of data transmission seems to be the reason the total time of Klaim differs from the total time of Tupleware.

By comparing Figures 2 and6, we see that, when the number of workers increases, GigaSpaces and Klaim suffer more from synchronization in the current case study than in the previous one; there no other operation was performed in parallel to writing and thus no conflict handling was required.

In addition to experimenting with case studies, we measured the time required by reading and writing operations on remote tuple space for all three systems. For Klaim and Tupleware these times were similar and significantly greater than those of GigaSpaces. Klaim and Tupleware communications rely on TCP and to handle any remote tuple space one needs to use exact addresses and ports. GigaSpaces, that has a centralized implementation, most As shown in Figure 7, search time directly depends on the number of the workers and grows with it. Taking into account that Klaim and Tupleware spend more time accessing remote tuple space, GigaSpaces suffers more because of synchronization. Klaim has the same problem, but its inefficiency is hampered by data transmission cost.

Ocean model This case study was chosen to examine behavior of tuple systems when specific patterns of interactions are used. Out of the three considered systems, only Tupleware has a method for reducing the number of visited nodes during search operation which helps in lowering search time. Figure 8 depicts the number of visited nodes for different grid size and different number of workers. The curve depends only weakly on the size of the grid for all systems, and much more on the number of workers. Indeed, from Figure 8 we can appreciate that Tupleware performs a smaller number of nodes visits, and that when the number of workers increases the difference is even more evident4 . The difference in the number of visited nodes does not affect significantly the total time of execution (Figure 9) mostly because the case study requires many read operations from remote tuple spaces (Figure 10). But, as it was mentioned before, GigaSpaces implements read operation differently from Tupleware and Klaim and it is more effective when working on a single computer.

Figure 9 provides evidence of the effectiveness of Tupleware when its total execution time is compared with the Klaim one. Indeed, Klaim visits more nodes and spends more time for each read operation, and the difference increases when the grid size grows and more data have to be transmitted.

This case study suggests that devising an appropriate mechanism for taking advantage of the underlying communication pattern can make cooperative work of distributed tuple spaces more effective. considered GigaSpaces, because it is one of the few currently used commercial products, Klaim, because it guarantees code mobility and flexible manipulation of tuple spaces, and Tupleware, because it is the one that turned out to be the best in our initial evaluation. We have then compared the three system by evaluating their performances over three case studies: a communication-intensive one, a computational-intensive one, and one with a specific communication pattern.

Our work follows the lines of [START_REF] Wells | Linda implementations in java for concurrent systems[END_REF] but we have chosen more recent implementations and conducted more extensive experiments.

The commercial system GigaSpaces differs from the other two systems for the use of a memory based interprocess communication for data exchange, that guarantees considerably smaller access time to data. Therefore, using this mechanism in the scope of one machine can increase effectiveness of work when different tuple spaces are needed. When working with networked machines, it is not possible to use that mechanism and we need to use approaches to reduce the number of inter-machine communication (e.g. Tupleware approach) and to make that communication effective. Another issue to which we need to pay to attention is related to the implementation of local tuple spaces including pattern matching algorithms and mechanisms to prevent conflicts when accessing the spaces.

Performances of a tuple space system vary depending on the chosen system architectures and on the type of interaction between their components. We did not consider different architectures but we noted problems (data transmission, synchronization, etc.) which may occur in different systems for different types of interaction. We plan to use the results of this work as the basis to design an efficient tuple space system which offers programmer the possibility of selecting (e.g. via a dashboard) the desired features of the tuple space according to the specific application. In this way, one could envisage a distributed middleware with different tuple spaces implementations each of them devised with the best characteristic, in terms of efficiency, to perform the required tasks.

  (JSP), TSpaces (TSP), GigaSpaces (GSP), Tupleware (TW), Grinda (GR), Blossom (BL), DTuples (DTP), LuaTS (LTS), Klaim (KL)

Fig. 1 :Fig. 2 :

 12 Fig. 1: Password search. Local total time

Fig. 3 :Fig. 4 :

 34 Fig. 3: Password search. Local reading time (1 million passwords)

Fig. 5 :Fig. 6 :

 56 Fig. 5: Sorting. Total time

Fig. 7 :Fig. 8 :

 78 Fig. 7: Sorting. Search time (10 million elements)

Fig. 9 :Fig. 10 :

 910 Fig. 9: Ocean model. Total time

Table 1 :

 1 Results of the comparison

FreePastry is an open-source implementation of Pastry, a substrate for peer-to-peer applications (http://www.freepastry.org/FreePastry/).

The profiler was written by Mike Clark; source code is available in GitHub.com: https://github.com/akatkinson/Tupleware/tree/master/src/com/clarkware/ profiler.

Plots with more detailed (numeric) information are reported as bar charts at http: //sysma.imtlucca.it/coord16_appendix/.

Figure 8, the curves for Klaim and GigaSpaces are overlapping and purple wins over blue.

ConclusionsDistributed computing is getting increasingly pervasive, with demands from various applications domains and highly diverse underlying architectures from the multitude of tiny things to the very large cloud-based systems. Tuple spaces certainly feature valuable characteristics to help develop scalable distributed applications/systems. This paper has first surveyed and evaluated a number of tuple space systems, then it has analyzed more closely three different systems. We