dataesr/scientific-paragraphs-categorization huggingface dataset:
The activation sigmoid layer allows to compute the score between 0 and 1 of a sequence to be an active G4 region. In the third step (Fig 2C ), we used DeepG4 to predict the G4 region activity (score between 0 and 1) for a novel DNA sequence and its corresponding chromatin accessibility. We split the sequence set (set of positive and negative sequences) from HaCaT cell line (from GEO GSE76688 accession) into a training set to learn model parameters, a validation set to optimize hyper-parameters by Bayesian optimization and a testing set to assess model prediction accuracy. For this purpose, we computed the receiver operating characteristic (ROC) curve and the area under the ROC (AUROC), as well as the precision-recall (PR) curve and the area under the PR (AUPR). DeepG4 motifs are extracted from the convolutional layer.
G4 predictions with DeepG4 We then evaluated the prediction performance of DeepG4. In term of AUROC, DeepG4 obtained excellent predictions of active G4 regions from HaCaT cells on the testing set (Fig  3A ; AUROC = 0. 988). On an independent ChIP-seq experiment done with the same cell line (from GEO GSE99205 accession), prediction performance of DeepG4 also showed very high accuracy (AUC = 0. 986; Fig  3A ). We then evaluated the ability of DeepG4 trained on one cell line (HaCaT) to predict G4s in another cell line (e. g. K562). We first browsed the genome where G4 regions were mapped by ChIP-seq as active in K562. For instance, we looked around the oncogene KRAS known to be regulated by a G4 in its promoter (Fig  3B ). ChIP-seq mapped one active G4 region in the promoter of KRAS, which was also predicted with high score by DeepG4 (score > 0.
Identification of important motifs from DeepG4 The first layer of DeepG4 convolutional neural network encapsulated kernels that encoded DNA motifs predictive of active G4s. Hence, we extracted from the first layer the kernels and converted them to DNA motif PWMs to better understand which motifs were the best predictors of G4 activity. DeepG4 identified 900 motifs, many of them were redundant. To remove redundancy, we clustered the motifs using RSAT matrix-clustering program and kept the cluster motifs (also called root motifs in the program) for subsequent analyses. Cluster motifs could be divided into two groups: a group of de novo motifs and a group of motifs that resembled known TFBS motifs. To distinguish between these two groups, we used TomTom program (MEME suite) which mapped the cluster motifs to JASPAR database.
Second, DeepG4 does not process the DNA sequence in a strand-specific manner, thus a given motif could be redundantly encoded in both strands within the convolutional layer. However, post-processing of DeepG4 motifs using methods such as matrix-clustering alleviates such problem by mapping complementary motifs (same motifs on different strands) to each other to merge them into cluster motifs. Third, the prediction performance of DeepG4 strongly depends on existing datasets that are limited, potentially inaccurate and biased, especially regarding in vivo mapping. Once more techniques for in vivo G4 mapping will be developped, DeepG4 will need to be retrained in order to improve prediction accuracy. Moreover, since DeepG4 was trained based on human data, predictions on non-mammalian genomes are expected to be less accurate.
The Stellar Mass For the DustPedia sample, we adopt the stellar masses of  Nersesian et al. (2019). Theses masses were derived from UV-to-mm SED fitting, using the code CIGALE  (Boquien et al. 2019) , with two stellar populations. For the DGS, the stellar masses are given by  Madden et al. (2014)   1955 ) IMF, therefore limiting potential biases between the two samples. Other potential biases, such as the form of the assumed star formation history, should not be an issue with our sample. For instance, both  Mitchell et al. (2013)  and  Laigle et al. (2019)  tested the reliability of stellar mass estimates using numerical simulations of galaxies, and showed that they gave consistent results at low redshift. We use M to denote the stellar mass. Nanni et al. (2020, hereafter N20)  have reestimated the stellar masses of the DGS, with CIGALE.
6  compares M dust to our reference run. We notice, as expected, the same systematic shift, here by a factor 0. 7, as for the fixed-β MBB (Table  3 ). et al. (2019)  have modelled the DustPedia sample, using the code CIGALE  (Boquien et al. 2019) , which fits the dust SED with: (i) the THEMIS grain properties; (ii) the DL07 ISRF distribution; and (iii) a non-hierarchical Bayesian method. Panel (c) of Fig. 6  shows its comparison to our reference run. As expected, it is very similar to the DL07 ISRF distribution test in panel (b) of the same figure. In particular, the mass is shifted by the same 0. 7 factor (Table  3 ). Note that  Nersesian et al. (2019)  did not analyze the sources from the DGS, which are mostly the scattered values (in blue) at low M ref dust. Concerning the fraction of small a-C(:H), the values of  Nersesian et al.
6mm observations, when available. When CO data was not available, the molecular gas mass was estimated from a scaling relation. (e) Resolved interferometric [H i] 21 cm observations of 20 of the lowest metallicity objects were used in order to extract the gas mass corresponding exactly to the IR photometric aperture. 2. We have performed a hierarchical Bayesian dust SED fit of the 798 galaxies, using the code HerBIE (G18) with the THEMIS grain properties  (Jones et al. 2017 ). (a) This allowed us to infer the dust mass, M dust , mean starlight intensity, U , and the mass fraction of aromatic-feature-emitting grains, q AF , in each galaxy (Sect. 3. 2). The inferred parameters are given in Table H. 1. (b) We have compared our inferred parameters to a series of additional runs, as well as to independent literature studies, in order to demonstrate the influence of the different assumptions of our model and assess the robustness of our results (Sects.
4. 2), as well as resolving ETGs to quantify the grain sputtering timescale (Sect. 4. 1. 2). Numerous spatially resolved dust studies have already been published (e. g. Galliano et al. 2011; Mattsson & Andersen 2012; Draine & Hensley 2013; Hunt et al. 2015; Roman-Duval et al. 2017; Aniano et al. 2020). We are currently preparing several papers of a resolved subsample, with the same consistent approach as employed in the present manuscript  (Roychowdhury et al. ; Casasola et al. , in prep. ). The main observational challenge in order to address these degeneracies is however to obtain spatial resolution in ELMGs, at far-IR wavelengths. The data are currently very limited, because the sensitivity of Herschel was not high enough. SPICA (van der Tak et al. 2018) was the only observatory on the horizon to have the sensitivity to produce resolved far-IR maps of ELMGs.
20) and for the variance: V(X) = N × |u i |<1 (x i -l x ) 2 (1 -u 2 i ) 4 |u i |<1 (1 -u 2 i )(1 -5u 2 i ) |u i |<1 (1 -u 2 i )(1 -5u 2 i ) -1. (F. 21) Considering a second sample Y = {y i } i=1. N , an M-estimator of the covariance is presented by  Mosteller & Tukey (1977). Posing v i = (y il y )/(c × s y ), the covariance can be estimated as: V(X, Y) = N × |u i |<1,|v i |<1 (x i -l x )(1 -u 2 i ) 2 (y i -l y )(1 -v 2 i ) 2 |u i |<1 (1 -u 2 i )(1 -5u 2 i ) |v i |<1 (1 -v 2 i )(1 -5v 2 i ). (F. 22) These estimators are implemented in the Python astropy module  (Astropy Collaboration et al. 2013 , 2018). We have designed our own skewness W-estimator: γ(X) = |u i |<1 u 3 i (1 -u 2 i ) 2 |u i |<1 (1 -u 2 i ) 2. (F. 23) We have also slightly improved astropy's implementation by iterating on Eqs.
Acknowledgements. We thank  Marc-Antoine Miville-Deschênes  for useful discussions about SED fitting, and about Planck and IRAS data,  Albrecht Poglitsch  for discussions about PACS calibration, and  Joana Frontera-Pons  for her exper-tise about M-estimators. We also thank  Vianney Lebouteiller  and  Julia Roman-Duval  for insightful interpretations of absorption line measurements in DLA systems. Finally, we thank the referee,  Denis Burgarella , for his numerous comments that helped clarify the text of this article and strengthen the reliability of our stellar mass estimates. DustPedia is a collaborative focused research project supported by the  European Union  under the  Seventh Framework Programme  (2007Programme ( -2013) ) call (proposal no. 606847, PI J. I. Davies). The data used in this work is publicly available at http://dustpedia.
astro. noa. gr. This work was supported by the  Programme National "Physique et Chimie du Milieu Interstellaire" (PCMI)  of  CNRS/INSU  with  INC/INP  co-funded by  CEA  and  CNES (France). It has also been supported by the  Programme National de Cosmologie et Galaxies (PNCG) CNRS/INSU  with  INC/IN2P3  co-funded by  CEA  and  CNES (France). Simone Bianchi  and  Viviana Casasola  acknowledge funding from the  INAF   mainstream 2018 program  " Gas-DustPedia: A definitive view of the ISM in the Local Universe ". Ilse De Looze acknowledges support from  European Research Council (ERC)   Starting Grant 851622 DustOrigin. Maud Galametz  has received funding from the  European Research Council (ERC)  under the  European Union   Horizon 2020 research and innovation programme (MagneticYSOs project , grant agreement No  679937 , PI: Maury).
Aleksandr Mosenkov  acknowledges financial support from the  Russian Science Foundation  (grant no. 20-72-10052 ). This work has made extensive use of the HDF5 library, developed by The HDF Group and by the  National Center for Supercomputing Applications  at the  University of Illinois at Urbana-Champaign. This research has made use of the NASA/IPAC Extragalactic Database (NED), which is operated by the  Jet Propulsion Laboratory, California Institute of Technology , under contract with the  National Aeronautics and Space Administration. This research has made use of the VizieR catalogue access tool, CDS, Strasbourg, France (DOI: 10. 26093/cds/vizier). The original description of the VizieR service was published in Ochsenbein et al. (2000).
, 2010). Multiple computational paradigms can be used for the design and execution of workflows, e. g. , shell and Python scripts  (Marozzo, Talia & Trunfio, 2013) , Big Data frameworks (e. g. , Hadoop and Spark)  (Guedes et al. , 2020b) , but they are usually managed by complex engines named Workflow Management Systems (WfMS). A key feature that a WfMS must address is the efficient and automatic management of parallel processing activities in High Performance Computing (HPC) environments  (Ogasawara et al. , 2011). Besides managing the execution of the workflow in HPC environments, WfMSs are also responsible for capturing, structuring and recording metadata associated to all the data generated during the execution: input data, intermediate data, and the final results. These metadata is well-known as provenance  (Freire et al.
If a non-expert scientist wants to execute the same workflow with a new set of parameter values and input data, but does not know how to set the values of some of the parameters, one can benefit from parameter values used on previous executions of the same (or similar) workflow. The advantage of the WfMS is provenance data already contains the parameter values used on previous (successful) executions and can be a rich resource to be used for recommendation. Thus, this article hypothesis is that by adopting an approach to recommend the parameters values of workflows in a WfMS, we can increase the probability that the execution of workflow will be completed. As a consequence, the financial cost associated with execution failures is reduced. In this article, we propose a method named FReeP-Feature Recommender From Preferences, which aims at recommending values for parameters of workflow activities.
We evaluated FReeP using real workflow traces (considered as benchmarks): Montage  (Hoffa et al. , 2008)  from astronomy domain and SciPhy  (Ocaña et al. , 2011)  from bioinformatics domain. Results indicate the potential of the proposed approach. This article is an extension of the conference paper "FReeP: towards parameter recommendation in scientific workflows using preference learning"  (Silva Junior et al. , 2018)  published in the Proceedings of the 2018 Brazilian Symposium on Databases (SBBD). This extended version provides new empirical shreds of evidence regarding several workflow case studies as well as a broader discussion on related work and experiments. This article is organized in five sections besides this introduction. "Background" section details the theoretical concepts used in the proposal development.
, 2006) , Pegasus  (Deelman et al. , 2005)  and SciCumulus  (De Oliveira et al. , 2010b)  emerged. In special, SciCumulus is a key component of the proposed approach since it provides a framework for parallel workflows to benefit from FReeP. Also, data used in the experiments presented in this article are retrieved from previous executions of several workflows in SciCumulus. It is worth noticing that other WfMSs such as Pegasus and Kepler could also benefit from FReeP as long as they provide necessary provenance data for recommendation. SciCumulus architecture is modularized to foster maintainability and ease the development of new features. SciCumulus is open-source and can be obtained at https://github. com/UFFeScience/SciCumulus/. The system is developed using MPI library (a de facto standard library specification for message-passing), so SciCumulus is a distributed application, i.
e. , each SciCumulus module has multiple instances created on the machines of the distributed environment (which are different processes and each process has multiple threads) that communicate, triggering functions for sending and receiving messages between these processes. According to  Guerine et al. (2019) , SciCumulus has four main modules: (i) SCSetup, (ii) SCStarter, (iii) SCCore, and (iv) SCQP (SciCumulus Query Processor). The first step towards executing a workflow in SciCumulus is to define the workflow specification and the parameters values to be consumed. This is performed using the SCSetup module. The user has to inform the structure of the workflow, which programs are associated to which activities, etc. When the metadata related to the experiment is loaded into the SciCumulus database, the user can start executing the workflow.
Since SciCumulus was developed focusing on supporting the execution of workflows in clouds, instantiating the environment was a top priority. The SCSetup module queries the provenance database to retrieve prospective provenance and creates the virtual machines (in the cloud) or reserve machines (in a cluster). The SCStarter copies and invokes an instance of SCCore in each machine of the environment, and since SCCore is a MPI-based application it runs in all machines simultaneously and follows a Master/Worker architecture (similar to Hadoop and Spark). The SCCore-Master (SCCore 0 ) schedules the activations for several workers and each worker has a specific ID (SCCore 1 , SCCore 2 , etc. ). When a worker is idle, it sends a message for the SCCore 0 (Master) and request more activations to execute.
The SCCore 0 defines at runtime the best activation to send following a specific cost model. The SCQP component allows for users to submit queries to the provenance database for runtime or post-mortem analysis. For more information about SciCumulus please refer to  (De Oliveira et al. , 2012; De Oliveira et al. , 2010a; Guerine et al. , 2019; Silva et al. , 2020; Guedes et al. , 2020a; De Oliveira et al. , 2013). An workflow activation has input data, and generates intermediate and output data. WfMS has to collect all metadata associated to the execution in order to foster reproducibility. This metadata is called provenance  (Freire et al. , 2008). According to  Goble (2002) , the provenance must verify data quality, path audit, assignment verification, and information querying. Data quality check is also related to verifying the reliability of workflow generated data.
It allows for verifying what caused an activation to fail or generated an unexpected result, or in the case of success, what were the steps and parameters used until the result. Another advantage of provenance is the reproducibility of an experiment, which is essential for the validation of the results obtained by third parties. Considering the provenance benefits in scientific experiments, it was necessary to define a model of representation of provenance  (Bose, Foster & Moreau, 2006). The standard W3C model is PROV  (Gil et al. , 2013). PROV is a generic data model and is based on three basic components and their links, being the components: Entity, Agent and Activity. The provenance and provenance data model are essential concepts because FReeP operation relies on provenance to recommend parameter values.
In object ranking an instance is not related to a class. This task's objective is, given a subset of items referring to the total set of items, to produce a ranking of the objects in that subset-for example, the ranking of web pages by a search engine. Pairwise Label Ranking  (Fürnkranz & Hüllermeier, 2003; Hüllermeier et al. , 2008)  (PLR) relates each instance with a preference type a > b, representing that a is preferable to b. Then, a binary classification task is assembled where each example a, b is annotated with a is a is preferable over b and 0, otherwise. Then, a classifier M a, b is trained over such dataset to learn how to make the preference predictions which returns 1 as a prediction that a is preferable to b and 0 otherwise. Instead of using a single classifier that makes predictions between m classes, given a set L of m classes, there will be m(m -1)/2 binary classifiers, where a classifier M i, j only predicts between classes i, j in L.
Discrete domain parameter value recommendation Given a provenance database D, a parameter y ∈ Y, where Y is the workflow parameters set, and a preferences or restrictions set P defined by the user, where p i ∈ P (y i , val k ), FReeP one parameter approach aims at solving the problem of recommending a r value for y, so that the P preferences together with the r recommendation to y maximize the chances of the workflow activation to run to the end. Figure  4  presents an architecture overview of FReeP's naive version. The algorithm receives as input the provenance database, a target workflow and user preferences. User preferences are also input as this article assumes that the user already has a subset of parameters for which has already defined values to use. In this naive version, the user preferences are only allowed in the form a = b, where a is a parameter, and b is a desired value to a.
Based on the user's preferences, it would be possible to query the provenance database from which the experiment came from to retrieve records that could assist in the search for other parameters values that had no preferences defined. However, FReeP is based on a model generation that generalizes the provenance database, removing the user's need to perform this query yet providing results that the query would not be able to return. To obtain a recommendation from FReeP's naive version, seven steps are required: partitions generation, horizontal filter, vertical filter, hypothesis generation, predictions, aggregation, and, finally election-based recommendation. Algorithm 1 shows the proposed algorithm to perform the parameter recommendation, considering the preferences for a subset or all other workflow execution parameters.
The algorithm input data are: target parameter for which the algorithm should make the recommendation, y; user preferences set, such as a list of key-values, where the key is a workflow parameter and value is the user's preference for that parameter, P; provenance database, D. The storage of provenance data for an experiment may vary from one WfMS to another. For example, SciCumulus, which uses a provenance representation derived from PROV, stores provenance in a relational database. Using SciCumulus example, it is trivial for the user responsible for the experiment to elaborate a SQL query that returns the provenance data related to the parameters used in each activity in a key-value representation. The key-value representation can be easily stored in a csv format file, which is the required format expected as provenance dataset in FReeP implementation.
num_aligns After the partitions generation and horizontal and vertical filters are discovered, there is a filtered data set that follows part of the user's preferences. These provenance data that will generate the Machine Learning model have numerical and categorical domain parameters. However, traditional Machine Learning models generally work with numerical data because the generation of these models, in most cases, involves many numerical calculations. Therefore, it is necessary to codify these categorical parameters to a numerical representation. The technique used here to encode categorical domain parameters to numerical representation is One-Hot encoding  (Coates & Ng, 2011). This technique consists of creating a new binary attribute, that is, the domain of this new attribute is 0 or 1, for each different attribute value present in dataset.
Thus, there may be parameters p ∈ PV | p ∉ PP, and for those parameters p, there are no values defined a priori. This enhanced version of the proposal allows the user's preferences to be expressed in a more relaxed way, demanding to create the instances used in the step recommendation that include a range (or set of values). To handle this isse, all possible instances from preference values combinations were generated. In case the preference is related to a numerical domain parameter and is defined in terms of values range, like a ≤ 10. 5, FReeP uses all values present in the source provenance database that follows the preference restriction. It is important to note that for both numerical and categorical parameters, the combination of possible values are those present in the provenance database and that respect the user's preferences.
Then, predictions are made for a set of instances using the model learned during the training phase. Regarding problem 2, the provenance database, in general, present attributes with numerical and categorical domains. It is FReeP responsibility to convert categorical values into numerical representation due to restrictions related to the nature of the training algorithms of the Machine Learning models, e. g. , Support Vector Machines (SVM)  (Wang, 2005). This pre-processing step was included in Algorithm 2 as classes_preprocessing step. The preprocessing consists in exchanging each distinct categorical value for a distinct integer. Note that the encoding of the parameter used as a class variable in the model generation is different from the encoding applied to the parameters used as attributes represented by the step preprocessing.
Concerning problem 3, by using classifiers to handle a continuous domain class variable degrades the performance results. Performance degradation happens because the numerical class variables are considered as categorical. For continuous numerical domain class variables, the Machine Learning models suggested are Regressors  (Myers & Myers, 1990). In this way, the Enhanced FReeP checks the parameter y domain, which is the recommendation target parameter, represented as model_select step in Algorithm 2. To analyze problem 4, it is important to note that after converting categorical attributes One-Hot encoding in preprocessing step, the provenance database will have a considerable increase in the number of attributes. Also, after categorical attributes encoding in preprocessing step, the parameters extracted from the user's preferences, are also encoded for partitions_generation step.