dataesr/scientific-paragraphs-categorization huggingface dataset:
The data used in this study come from the DustPedia archive 3. The archive was developed within the framework of the DustPedia project (an FP7 funded EU project) providing access to multi-wavelength imagery and photometry for 875 nearby galaxies. In addition to the imagery and the aperture-matched photometry that was applied to all available maps  (Clark et al. 2018) , additional data such as redshift-independent distances, HI masses  (De Vis et al. 2019 ), H 2 masses  (Casasola et al. 2019, in preparation) , optical line and metallicity measurements  (De Vis et al. 2019)  as well as information based on 2D photometric fitting such as Sérsic indices, effective radii, inclination angles, etc. (Mosenkov et al. 2019)  are also available in the DustPedia archive. The paper is structured as follows.
The Sample In our study we make use of multi-wavelength observations of galaxies available in the DustPedia archive  (Davies et al. 2017; Clark et al. 2018). The DustPedia sample consists of 875 nearby galaxies (recessional velocities of < 3000 km s -1 ) with Herschel  (Pilbratt et al. 2010 ) detection and angular sizes of D 25 > 1. The photometry in the DustPedia datasets was carried out in a uniform and consistent way for all observations (up to 41 bands from the FUV to the submm wavelengths) utilizing aperturematched techniques and robust cross-compatible uncertainty calculations for all bands. For the full description of our photometry pipeline we refer the reader to  Clark et al. (2018). The SED fitting routines that we present in the next section require the average flux densities over the filter's relative spectral response function (RSRF) as input.
In most cases, the correction is smaller than a few percent, with the exception of the WISE 12 µm band (whose DustPedia flux densities must be multiplied by 1. 05), MIPS bands (an increase by factors 1. 03 and 1. 07 at 24 and 70 µm, respectively) and IRAS 60 µm (a correction of 0. 95). Before using this photometric dataset we applied several rejection criteria following the guidelines and flagging codes given in  Clark et al. (2018)  to ensure that only good quality measurements are fed into our modelling. First, we used all bands from GALEX-FUV up to Planck-850 µm, excluding all photometric measurements flagged as contaminated from a nearby galactic or extragalactic source, determined upon visual inspection by  Clark et al. (2018). We furthermore excluded all photometric entries with significant artefacts in the imagery or insufficient sky coverage (leading to a poor background estimate).
Since this is only a small fraction (∼ 2%) of the DustPedia galaxies we did not use AGN templates in our modelling (in the plots that follow, though, we mark these galaxies with an 'X' symbol). Furthermore, we searched for jet-dominated radio galaxies in our sample since synchrotron and free-free emission can be the dominant component in the FIR-submm region of the spectrum. Four such galaxies  (NGC 1399, NGC 4261, NGC 4374, and NGC 4486)  were found by cross-matching the DustPedia galaxies with the all-sky catalog of radio-galaxies in the local Universe  (van Velzen et al. 2012)  and marked with an '+' in subsequent plots. In the characteristic case of NGC 4486 (M87), the FIR-submm SED is completely dominated by synchrotron emission  (Baes et al. 2010). Throughout the paper we parameterize the galaxy morphology by the Hubble stage (T ), the values of which have been retrieved from the HyperLEDA database  (Makarov et al.
SED fitting For the purpose of this work, we make use of the SED fitting code CIGALE to model and interpret the SEDs of the DustPedia galaxies. The code fits the multi-wavelength spectrum of each galaxy in order to derive global properties such as the SFR, the stellar mass M star , the lower cutoff of the ISRF intensity U min and the dust mass M CIGALE dust. Furthermore, the stellar component is described by providing the relative contribution of both the young and the old stellar components to the total SED of the galaxy. Complementary to CIGALE we approximate the FIRsubmm spectrum of the galaxies with the traditionally used MBB approach with the dust grain properties accordingly scaled to match the THEMIS dust properties. This provides us with an independent estimate of the total dust mass and dust temperature for each galaxy.
2015; Fanciullo et al. 2015). Within the DustPedia framework, we modified CIGALE accordingly to include THEMIS as a separate module for the dust emission parameters. Our approach to generate the template files is similar to the DL14 model  (Draine & Li 2007; Draine et al. 2014) , i. e. , we compute the moments of the average starlight intensity U, by using a delta function component and a power-law distribution:  (Draine & Li 2007) , where γ is the fraction of the dust heated in photo-dissociation regions (PDR). We created a library of templates based on 3 parameters: (1) the mass fraction of aromatic feature emitting grains, q hac (i. e. , a-C(:H) smaller than 1. 5 nm), (2) the minimum intensity value of the stellar radiation field that heats the dust, U min , and (3) the power-law index, α.
2009). For each parameter, a probability distribution function (PDF) analysis is carried out. Given the observed SED of a galaxy, CIGALE derives the posterior probability distribution of the physical parameters. The posterior probability is simply the dot product of the prior, i. e. , the probability of a model being used before fitting the data, and the likelihood that the data match the model created by the parameter grid. The result of the analysis is the likelihood-weighted mean value of the PDF while the associated error is the likelihood-weighted standard deviation  (Boquien et al. 2019). We adopted a similar parameter grid as the one used by  Hunt et al. (2018)  to fit the SEDs of 61 galaxies from the KINGFISH sample  (Kennicutt et al. 2011). In Table  1  we give the parameter space used by CIGALE to calculate the SED templates to be fitted to the actual datasets.
Quality of the fit With the current set up of CIGALE we can derive estimates of several parameters such as the SFR, the FUV attenuation (A FUV ), the minimum ISRF intensity (U min ), the stellar mass (M star ), the bolometric luminosity (L bolo ), the dust mass and luminosity (M CIGALE dust and L dust respectively), the mass fraction of hydrocarbon solids (q hac ; the PAH abundance q PAH in the case of DL14), and the fraction of the dust luminosity coming from PDRs (γ), to name a few. To examine how well these param-eters can be constrained from the multi-wavelength SED fitting that CIGALE performs, as well as the accuracy and precision expected for each parameter, we made use of the CIGALE module that performs a mock analysis. This module creates a mock SED for each galaxy, based on the best fitted parameters, allowing the fluxes to vary within their measured uncertainties.
As in the case of CIGALE, a 10% uncertainty was added quadratically to the measured flux uncertainties (see Sect. 3. 1. 2). The fit was made using standard χ 2 minimization techniques (Levenberg-Marquardt) allowing the dust temperature (T MBB dust ) to range between 10 and 40 K. The SED of the MBB was convolved to each filter's RSRF. In the case of the SPIRE bands the RSRF for extended emission was used. An estimate of the uncertainty on the derived parameters is provided by performing a bootstrap analysis to our datasets by fitting 1000 SEDs for each galaxy. The mock fluxes are randomly drawn from a Gaussian distribution centered on the observed flux and with a standard-deviation identical to those observed. The uncertainty assigned to each of the two parame-ters (T MBB dust and M MBB dust ) is then defined as the standard-deviation of the 1000 values derived from this procedure.
This is evident in the dust masses (left panel of Fig. 5 ), with most of the deviant cases showing MBB dust masses higher than those derived by CIGALE, but it becomes more prominent in the dust temperatures (right panel of Fig. 5 ) with CIGALE systematically estimating higher values compared to MBB for these galaxies. Some of the galaxies identified as AGNs and strong radio-sources are amongst the outliers indicating that the models could not adequately fit the observations, though these are only a few cases. For the majority of the most deviant cases, a visual inspection of the SEDs reveals that this is, mainly, due to a combination of two effects. First, the FIR-submm measurements, especially for the ETGs, come with large uncertainties due to the low level of emission. This allows CIGALE, which is constrained from a large multi-wavelength dataset, for a larger 'flexibility' in fitting this part of the SED, in most cases 'over-weighting' MIR and FIR against submm measurements.
1. The results of the CIGALE and the MBB modelling, presented in this study, are provided in the DustPedia archive for every galaxy modelled. x-axis) and the mock parameters (fitted values; y-axis) estimated from the CIGALE fitted PDFs for each parameter (SFR, A FUV , q hac , M star , L bolo , U min , M CIGALE dust , L dust , and γ, from top to bottom). For each galaxy the probability-weighted mean value along with the associated standard-deviation of the mock values (error bars) are plotted on the yaxis. In the cases of q hac , U min , and γ, the average standard-deviation is plotted in the bottom-right corner of each panel, in order to avoid confusion. The data are colour-coded with the number of observations available for each galaxy (see the inset of the panel in the middle for the explanation of the colours).
Acknowledgements We would like to thank the anonymous referee for providing comments and suggestions that helped to improve the quality of the manuscript. DustPedia is a collaborative focused research project supported by the  European Union  under the  Seventh Framework Programme  (2007)(2008)(2009)(2010)(2011)(2012)(2013) call (proposal no. 606847 ). The participating institutions are:  Cardiff University, UK ;  National Observatory of Athens, Greece ;  Ghent University, Belgium ;  Université Paris Sud , France;  National Institute for Astrophysics, Italy  and  CEA, France. This research is co-financed by Greece and the  European Union (European Social Fund-ESF)  through the  Operational Programme «Human Resources Development, Education  and  Lifelong Learning » in the context of the project " Strengthening Human Resources Research Potential via Doctorate Research " ( MIS-5000432 ), implemented by the  State Scholarships Foundation (IKY).
This paper demonstrates how OpenMP 4. 5 tasks can be used to efficiently overlap computations and MPI communications based on a case-study conducted on multi-core and many-core architectures. It focuses on task granularity, dependencies and priorities, and also identifies some limitations of OpenMP. Results on 64 Skylake nodes show that while 64% of the wall-clock time is spent in MPI communications, 60% of the cores are busy in computations, which is a good result. Indeed, the chosen dataset is small enough to be a challenging case in terms of overlap and thus useful to assess worst-case scenarios in future simulations. Two key features were identified: by using task priority we improved the performance by 5. 7% (mainly due to an improved overlap), and with recursive tasks we shortened the execution time by 9.
Distributed Algorithm and Data Structures Algorithms Algorithm 1 presents one timestep of the application. It is divided in two parts: the solving of the Poisson equation (lines 1-2) and the Vlasov solver (lines 4-10). The Vlasov solver operates on a 2D regular mesh with ghost areas (data structures are presented in the next paragraph). In the following, we will denote by ∆t the time step, by ρ n = ρ(n ∆t, x) the ionic density at time step n (the superscript notation. n will be used also for E and f ). Ghost exchange is done through MPI isend/irecv between surrounding processes so they can be available for the next iteration. The number of ghost cells in both direction is denoted G. In the upcoming Section 4 we will set G = 8. Algorithm 1: One timestep Input : f n , ρ n loc Output: f n+1 , ρ n+1 loc 1 ρ n = AllReduce(ρ n loc ) 2 E n = Field solver(ρ n ) 3 Perform diagnostics & outputs (E n , ρ n ) 4 Launch all isend/irecv for ghost zones f n 5 2D advections for interior points (Algo.
0. 1 and IntelMPI 2018. 1. 163  11. The used OpenMP runtime is KOMP  [5]  (commit 32781b6), a fork of the LLVM/Intel OpenMP runtime. This runtime helps us to produce and visualize runtime traces in order to finely profile and track performance problems and behaviors. It also implements tasks priorities and provides good performance with fine-grained tasks  [9]. Method The median completion time is retrieved from a set of 10 runs. Each run performs 1000 iterations for the scaling and granularity experiments and 100 for the trace-based results (to reduce the trace size). Unless explicitly stated, each run works with a (small) tile size of 64x64 over a 2D dataset of 8192x8192. We choose a quite-small dataset for practical reasons: it exhibit issues that usually occur with much more nodes on bigger datasets, but actually takes less time and energy.
On the other hand, a small tile size on a few nodes (overdecomposition) introduces prohibitive runtime costs due to the number of tasks to schedule proportionally to the overall execution time (top-left of the Figure). Thus, the most efficient tile size is related to the number of nodes. Strategies to set the tile size We can emphasize that the cost of an underdecomposition of the domain causes more problems than an over-decomposition. Thus, it is better to perform a slight over-decomposition, it provides more flexibility to the runtime to ensure a decent load balance. Finally, choosing 64x64 tiles (see Section 4. 1) is not always the best but is an adequate trade-off to ensure the scalability of this code up to 128 nodes. Discussion on the granularity The tile size, and more generally the granularity of tasks is a matter of concerns to reach good performances.
Some task-based runtimes that support OpenMP also support extension relative to MPI. StarPU  [1] , for example, supports asynchronous and task-based send/receive point-to-point communications, and more recently MPI collectives. The runtime is based on a pooling thread to handle the asynchronous MPI communications. It provides two main APIs: a C extension based on pragma directives and a low-level C API. The first targets only GCC, and as far as we know, it does not support MPI-related features. The last is flexible, but also more intrusive as a lot of code is needed to submit and manage tasks. OmpSs  [6]  is another runtime supporting MPI in a similar way. It extends OpenMP with new directives so it can be used by end-users. However, OmpSs relies on its own compiler. These approaches can be a good starting point to create a standard interface between OpenMP and MPI or even an OpenMP extension that could be supported by multiple runtimes as well as MPI implementations.
The above gap was closed by introducing a BP execution environment that supports the cross-level and cloud adaptive BP provisioning. This environment was developed in the context of the CloudSocket project 2  [59] , providing support to all lifecycle phases of a BP  [33] , which needs or was moved to the Cloud, by introducing phase-specific environments. The proposed environment covers the execution phase by including innovative components which support: (a) the cross-cloud and -level orchestration of cloud services for BP execution; (b) the cross-cloud and cross-level BP monitoring and coordinated adaptation. It also relies on the existence of CAMEL 3  [1, 52] , a multi-domain-specific language (multi-DSL) which supports the management of multi-cloud applications. CAMEL has been extended in the CloudSocket project to support the specification of both the cross-level allocation of a BP as well as the cross-level BP adaptation via the use of sophisticated adaptation rules.
Such rules map event patterns to an adaptation workflow which orchestrates adaptation actions that can be performed in multiple abstraction levels. The proposed BP execution environment has been validated through its application on a CloudSocket's use-case (see "Validation" section). The validation shows the suitability of the environment and its main benefits, which 2 www. cloudsocket. eu 3 www. camel-dsl. org include the automated and adaptive provisioning of a BP driven by a rule-based approach. We should highlight that this article focuses on BPs that can be moved to the cloud. These can correspond to any kind of BP, whose functionality can be realised by SaaS services and whose internal software components can be deployed via using PaaS or IaaS services. Such BPs can be designed by using BP Design Environments like the one offered in CloudSocket  [22, 28]  and might be examined in terms of their cloud readiness via the use of assessment tools, like CloudSocket's Cloud Transformation Framework  [40].
The latter tools can be used by business experts to evaluate whether a whole BP or some of its parts can be moved to the cloud along with the level of effort needed to support this migration. However, we do not enter into further details on these subjects as both BP assessment and design is out of scope of this article. The rest of the article is structured as follows. "Related work" section analyses the related work. The extended CAMEL language is detailed in "CAMEL" section. "Business process execution environment architecture" section analyses the BP execution environment's architecture. The application of that environment on a CloudSocket's use case is elaborated in "Validation" section. Finally, the last section concludes the article and draws directions for further research.
oasis-open. org/committees/tosca/ 14 https://github. com/OpenTOSCA 15 http://ariatosca. incubator. apache. org/ for the models@runtime paradigm. OCCI and CIMI suffer from a poor adoption. Anyway, adopting a language not widely used comes with the risk that the orchestration tool built on top of it might also become not very appealing. As such, it is better to not explicitly base a Cloud orchestration tool on a certain language. An internal representation model can be adopted which can be targeted by a model transformation approach focusing on supporting not only one but possibly multiple standardised languages. Tools: Cloud Orchestration Tools Cloud orchestration tools need to not only rely on Cloud abstraction APIs but to also handle both the application deployment based on a certain topology as well as the whole lifecycle management of the resources involved  [9].
The latter two aspects are usually covered by a DSL not always corresponding to one of the mentioned standards. Besides the application deployment, orchestration tools may also exhibit monitoring and adaptation features. During the evolution of cloud computing a variety of scientific and industry driven COTs have been established  [63]. A taxonomy and comprehensive analysis framework for these COTs is presented in  [63]. Apache Brooklyn  16  is a framework for application modelling, monitoring, and management via blueprints that define an application using a declarative YAML syntax, complying with the CAMP  17  standard and exposing many of the CAMP REST API endpoints. An non-official extension has also been developed to manage TOSCA blueprints. Cloudify  18  is an orchestration tool using a TOSCAaligned modelling language for describing the topology of the application which is then deployed to allocated VMs in the Cloud.
Current approaches in this respect split the functionalities of Cloud orchestration tools and focus on partial issues. The Cloud Native Foundation provides a landscape  21  of such tools online. A requirement analysis of COTS is detailed and applied for Apache Brooklyn, Apache Stratos 22 and Cloudify in  [9]. Apache Brooklyn uses jclouds and is, therefore, stuck to the aforementioned limitations. Cloudify comes with plugins supporting a majority of private and public clouds but lacks an abstraction layer as each model must explicitly reference cloud provider-specific features. Therefore, this work tackles those shortcomings by applying an advanced Cloud orchestration tool, described in detail in "Cloud provider engine" section. Scientic approaches, such as the orchestrator conversation  [53] , propose a novel approach to orchestrate cloud applications based on a hierarchical collection of independent software agents that collectively manage them.
Tools and Methods The event-based, non-intrusive monitoring approach in  [4] , developed in the Astro project  26  , extends ActiveBPEL and defines RTML, an executable language targeting the monitoring of servicebased application (SBA) properties. Event composition is accomplished by using past-time temporal logics and statistical functions. Monitoring is performed in parallel to BPEL process execution by focusing on the mapping of input and output messages sent or received by that process to monitoring terms (e. g. , metrics). The approach in  [44]  extends WS-Agreement to support the non-intrusive monitoring of both functional and non-functional properties. The EC-Assertion language is introduced, based on Event Calculus, to complement WS-Agreement with the specification of service guarantees in terms of different event types.
The system architecture is peer-to-peer thus catering for scalability while offering a set of aggregation levels for the gathered monitoring data. However, such an aggregation cannot be changed dynamically at run-time. A scalable and elastic cloud monitoring system also depends on the applied storage backend. With the evolution of NoSQL databases to offer a suitable performance and scalability level  [37] , various monitoring solutions have started to rely on them  [11]. Yet, the selection of a concrete NoSQL database needs to be carefully evaluated as significant differences in their scalability, elasticity and availability levels exist  [56] [57] [58]. Due to this pattern of adoption, a more monitoringcentric database type has recently evolved, called a timeseries database (TSDB), over NoSQL databases.
This type expands NoSQL databases with further monitoring capabilities including the evaluation of statistics-based queries, the measurement aggregation and a monitoring optimised data structure  [26]. KairosDB 29  , InfluxDB  30  and Druid 31  are well-adopted open source TSDBs. Tower4Clouds  32  , developed in the MODAClouds project  33  , is a monitoring platform for multi-cloud applications. This platform relies on a rule-based approach where cloud-provider independent monitoring rules are specified and considered by the centralised Data Analyzer which takes care of measurement aggregation and rule evaluation based on the measurements collected by Data Collectors. An interesting advantage of this platform is that it can monitor the response time, throughput and availability (another extension introduced by the SeaClouds project) of PaaS applications.
CAMEL As highlighted in the previous sections, there is a need to support the adaptive, cross cloud and level BPaaS provisioning. This must be achieved in accordance to BPaaS requirements and should require the least possible input and cloud-specific expertise from the BPaaS modeller. Model-driven engineering promises to automate the tasks involved in such provisioning. It embraces models as its core citizens which encapsulate all required information to support the respective BPaaS lifecycle tasks. Models can be specified via a language which supplies the right syntax and structure for them. As advocated in "IaaS service orchestration" section, most existing cloud modelling DSLs are insufficient to cover the whole BPaaS lifecycle in terms of the information that they convey. However, there is one language, called CAMEL  [1, 52] , which is almost rich enough and remains at an appropriate, high abstraction level which is cloud (provider) independent.