dataesr/scientific-paragraphs-categorization huggingface dataset:
Fully revealing causation is a long path that stretches beyond the aims of this study. One perspective to gain a grasp on causation from the kind of data dealt with in this study would be to use the three-way marginal correlation results amongst DNA, gene expression and phenotype variations and check the extent to which they fit in with coherently. Our new co-expression omnigenic network model is the first step towards a coherent integration of the terminologies used so far to define particular gene roles in the context of phenotype determinism. Our integrative approach combining predictive and explanatory functions fits well with the omnigenic theory, even when the gene network topology is not traitcentered but self-built with co-expression. It is the case within our Poplar dataset, leading us to think that this theory may be easily generalizable to contrasting biological models, further away from humans and disease-centered traits.
After evaluation, they were pruned again for a new growth cycle. At their fourth year of growth of this third cycle (2015), 241 genotypes present in two blocks of the French site were selected to perform sampling for RNA sequencing. In the end, we obtained transcriptomic data from 459 samples, 218 genotypes duplicated in the two blocks and 23 genotypes available from only one block. These 241 genotypes were representative of the natural west European range of P. nigra through 11 river catchments in 4 countries (Table  S3 ). We described 14 of the 17 phenotypic traits in previous work  (Gebreselassie et al. , 2017). Briefly, these traits can be divided into two categories, growth traits and biochemical traits which were all evaluated on up to 6 clonal replicates by genotype at each site after two years of growth in the second cycle.
Transcriptome data generation We sampled stem sections of approximately 80 cm long starting at 20 cm above ground and up to 1 meter in June 2015. The bark was detached from the trunk in order to scratch young differentiating xylem and cambium tissues using a scalpel. The tissues were immediately immersed in liquid nitrogen and crudely ground before storage at -80 • C pending milling and RNA extraction. Prior to RNA extraction, the samples were finely milled with a swing mill (Retsch, Germany) and tungsten beads under cryogenic conditions with liquid nitrogen during 25 seconds (frequency 25 cps/sec). About 100 mg of milled tissue was used to isolate separately total RNA from xylem and cambium of each tree with RNeasy Plant kit (Qiagen, France), according to manufacturer's recommendations. Treatment with DNase I (Qiagen, France) to ensure elimination of genomic DNA was made during this purification step.
RNA was eluted in RNAse-DNAse free water and quantified with a Nanodrop spectrophotometer. RNA from xylem and cambium of the same tree were pooled in an equimolar extract (250 ng/µL) before sending to the sequencing platform. RNAseq experiment was carried out at the platform POPS (transcriptOmic Platform of Institute of Plant Sciences -Paris-Saclay) thanks to IG-CNS Illumina Hiseq2000. RNAseq libraries were constructed using TruSeq Stranded mRNA SamplePrep Guide 150 31047 D protocol (Illumina R , California, U. S. A. ). The RNAseq samples have been sequenced in singleend reads (SR) with an insert library size of 260 bp and a read length of 100 bases. Images from the instruments were processed using the manufacturer's pipeline software to generate FASTQ sequence files. Ten samples by lane of Hiseq2000 using individually barcoded adapters gave approximately 20 million of SR per sample.
We mapped the reads on the Populus trichocarpa v3. 0 transcriptome with bowtie2 (Langmead and Salzberg, 2012) and obtained the read counts for each of the 41,335 transcripts by in-house scripts (17 million of reads were mapped per sample in median, with a minimum of 6 and a maximum of 42 million). Initially, we considered using the genotype mean to reduce our data volume. However, differences between replicates were not normally distributed, because of variation in gene expression due to plasticity. We thus could not summarize our data with their mean, as it would have removed this information and finally we chose to keep replicates as separate data samples.
Filtering the non-expressed genes, normalization and variance stabilization As the sampling ran along 2 weeks, we expected environmental variables to blur the signal. To understand how our data were impacted, we ran the first analysis, containing a step identifying the impact of each cofactor and a step correcting confounding effects, with mixed linear models implemented in the R package breedR  (Muñoz and Sanchez, 2017). However, while it was properly correcting the covariables that seemed to impact our data (environmental effects) when controlling on PCA spaces, it was also erasing useful information from the data, yielding less accurate prediction models than without any correction. We thus chose not to perform this correction, and use raw uncorrected data. We started cleaning our raw counts data by removing the transcripts with 0 counts for all individuals.
This also computes module eigengenes. To sort the traits, we clustered their scaled values with the pvclust R packages  (Suzuki and Shimodaira, 2015) , the Ward agglomerative method ("Ward. D2") on correlations (Figure  1B , 1C, Figure  S3 ). The clustering on euclidean distance results in the exact same hierarchical tree. Correlations between traits and gene expression or module eigengenes were computed as Spearman's rank correlations (Figure  1B, 1C ). We also performed a k-means clustering with the R package coseq  (Rau and Maugis-Rabusseau, 2017)  considering 10 initial runs, 1000 iterations, without any other data transformation, and for a number of clusters (K) between 2 and 20. At first, it identified a K without strong agreement between the two evaluation algorithms included in coseq.
Models Both additive linear model (ridge regression) and interactive neural networks models were computed by the R package h2o  (LeDell et al. , 2019). They both used the gene expression sets as predictors and one phenotypic trait at a time as a response. Gene sets were split by the function h2o. splitFrame into 3 sets, a training set, a validation set and a test set, with the respective proportions of 60%, 20%, 20%. We checked that the split preserves the distribution of samples within populations. The training set was used to train the models, the validation set was used to validate and improve the models, while the test set was used to compute and report prediction accuracies as R 2 between observed and predicted values within this set and using the function R2 of the R package compositions  (van den Boogaart et al.
Z b and Z w are known incidence matrices between and within populations, relating observations to random effects b and w. is the residual component of gene expression, following a normal distribution centered around 0, of variance σ 2 I, where σ 2 is the residual variance and I is an identity matrix. From the between and within population variance components, we computed heritability (h 2 ) and population differentiation estimates (Q ST ) for each gene as follows: h 2 = σ 2 b + σ 2 w σ 2 b + σ 2 w + σ 2 (2) Q ST = σ 2 b σ 2 b + 2σ 2 w (3) To compute them, we used the function remlf90 from the R package breedR  (Muñoz and Sanchez, 2017) , with the Expectation-Maximization method followed by one round with Average-Information algorithm to compute the standard deviations. We computed the genetic variation coefficient (CV g) by dividing sums of σ 2 b and σ 2 w by expression mean, per gene.
Other population statistics We further used a previously developed bioinformatics pipeline to call SNPs within our RNA sequences  (Rogier et al. , 2018). Briefly, this pipeline involves classical cleaning and quality control steps, mapping on the Populus trichocarpa v3. 0 reference genome, and SNP calling using the combination of four different callers. We ended up with a set of 874,923 SNPs having less than 50% of missing values per genotype. The missing values were further imputed with the software FImpute  (Sargolzaei et al. , 2014) ). We validated our genotyping by RNAseq approach by comparing the genotype calls with genotyping previously obtained with an SNP chip on the same individuals  (Faivre-Rampant et al. , 2016) ). Genotyping accuracy based on 3,841 common positions was very high, with a mean value of 0.
96 and a median value of 0. 99. The imputed set of SNP was then annotated using Annovar  (Wang et al. , 2010)  in order to group the SNPs per gene model of P. trichocarpa reference genome. For each SNP, we computed the overall genetic diversity statistic (Ht) with the hierfstat R package (  (Goudet and Jombart, 2015)  and this statistic was then averaged by gene model in order to get information on the extent of diversity. We further computed ScoreP Cadapt with the pcadapt R package  (Luu et al. , 2017)  with 8 retained principal components. Here again, ScoreP Cadapt were then summarized (averaged) by gene model in order to get information about their potential involvement in adaptation. Based on the principal component analysis, PCadapt is more powerful to perform genome scans for selection in next-generation sequencing data than approaches based on F ST outliers detection  (Luu et al.
Data Access This RNAseq project has been submitted to the international repository Gene Expression Omnibus (GEO) from NCBI (accession number: GSE128482). All steps of the experiment, from growth conditions to bioinformatic analyses are detailed in CATdb  (Gagnot et al. , 2007)  according to the MINSEQE "minimum information about a high-throughput sequencing experiment". Raw sequences (FASTQ) are being deposited in the Sequence Read Archive (SRA) from NCBI. Information on the studied genotypes is available in the GnpIS Information System  (Steinbach et al. , 2013). q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q -200 -100 ADEJ MCL NB Xylem scraper q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q -200 -100 q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q -200 -100 0 100 200 -200 -100 0 100 200 Dim1 (11%) Dim2 (6.
Acknowledgements The authors gratefully acknowledge the staff of the  INRA GBFOR experimental unit  for the establishment and management of the poplar experimental design in Orléans, the collection of wood samples in each site, and their contribution to phenotypic measurements on poplars in Orléans;  Alasia Franco Vivai  staff for management of the poplar experimental plantation in Savigliano, and  M. Sabatti  and  F. Fabbrini  for their contribution to phenotypic measurements on poplars in Savigliano. We acknowledge the staff of  BioForA  for their contribution to RNA collection in the field. We are grateful to the genotoul bioinformatics platform  Toulouse Midi-Pyrennées  for providing computing and storage resources. We would also like to thank  M. Nordborg  for useful discussions on this work and  J.
Funding Establishment and management of the experimental sites were carried out with financial support from the  NOVELTREE project  ( EU-FP7-211868 ). RNA collection, extraction, and sequencing were supported by the  SYBIOPOP  project ( ANR-13-JSV6-0001 ) funded by the  French National Research Agency (ANR). The platform POPS benefits from the support of the  LabEx Saclay Plant Sciences-SPS  ( ANR-10-LABX-0040-SPS ).
Predictions scores on test sets (R 2 on the y-axis) for the LM Ridge algorithm for each phenotypic trait (on the x-axis). The color of each bar represents the size of the peripheral gene set that has been used for the predictions (in percent of the full set). 0. 2 0. 4 0. 6 0. 2 0. 4 0. 6 Figure S10: 0. 0 Prediction R 2 Prediction R 2 Full Core 10% Random 20% Peripheral 30% 40% Boruta 0. 0 Full MeanDiameter CIRC. Orl Core CIRC. Sav Random Peripheral S. G. Orl S. G. Sav Glucose. Orl Glucose. Sav Boruta Infraden dataset C5. C6. Orl Full C5. C6. Sav H. G. Orl Core H. G. Sav Random Peripheral Lignin. Orl Lignin. Sav Extractives. Orl Boruta Extractives. Sav Date3Doy Phenotype 29 30.
Computational Fluid Dynamics (CFD) is widely used in manufacturing and engineering from product design to testing. CFD requires intensive computational power and typically needs high performance computing to reduce potentially long experimentation times. Dedicated high performance computing systems are often expensive for small-to-medium enterprises (SMEs). Cloud computing claims to enable low cost access to high performance computing without the need for capital investment. The CloudSME Simulation Platform aims to provide a flexible and easy to use cloud-based Platform-as-a-Service (PaaS) technology that can enable SMEs to realize the benefits of high performance computing. Our Platform incorporates workflow management and multi-cloud implementation across various cloud resources. Here we present the components of our technology and experiences in using it to create a cloudbased version of the TransAT CFD software.
Companies with access to high speed computing clusters can therefore expect faster CFD analysis and the opportunity to create better designs and solutions  [4]. There are many examples where approaches to CFD parallelization have been investigated, particularly using MPI  [5]. For example, Shang  [6]  discusses the parallelization performance of different meshing methods by using Code Saturne, a CFD software with MPI parallelization functions and concludes that the mesh partitioning method affects the performance of the parallelized simulation both in terms of latency and efficiency. The behavior of different partitioning approaches impacts performance. Multi-core computing facilities, such as those provided by super computer centers are being used to support the processing of huge CFD applications  [7].
As noted by Runchal  [9] , from a CFD simulation software perspective, cloud computing is very attractive as it could support the creation of a new generation of high speed, payper-use CFD applications that are composed of interoperating sets of simulation software services. For example, the data for a CFD experiment can be stored in a cloud-based database that is connected to a cloud-based CFD solver. The simulation is run on multi-CPU instances that support the processing requirements of parallelized CFD. Results can be analyzed and visualized by a cloud-based post-simulation tool. He also supports the view that for those who do not have access to these facilities, cloud computing has the potential for cost-effective access to CFD applications that utilize such architectures, though on a smaller scale.
II. THE CLOUDSME SIMULATION PLATFORM ARCHITECTURE Fig. 1  shows the CloudSME Simulation Platform architecture. The AppCenter and Platform Application Programming Interfaces (APIs) form the Simulation Applications Layer, WS-PGRADE/gUSE and CloudBroker form the Cloud Platform Layer and the various cloud infrastructures that the Platform and applications access are made available in the Cloud Resources Layer. Conceptually, to use the platform software requiring cloud deployment and/or cloud-based high performance computing is redeveloped as a Software-as-a-Service at the Simulation Applications Layer, hosted by the Cloud Platform Layer (Platform-as-a-Service) and uses cloud resources made available through the Cloud Resources Layer. The CloudSME Simulation Platform has been used to implement eleven commercial simulation products across a wide range of industrial applications (see http://www.
cloudsmeapps. com/practical-examples/ for examples of CFD, process simulation and computer aided design). The technical details of the integration of the Platform's technologies are presented in  [19]. We now describe the functionality of the components of the Platform. End-users can then access and execute these applications directly from the AppCenter and are charged for their utilization based on software provider defined pricing policies (e. g. subscription-based pricing, resource consumption-based pricing, fixed charge for each simulation run, or even free of charge execution). The advantage of this solution is that the AppCenter provides easily customizable options to set up various pricing models and it is also responsible for accounting and billing. Users simply need to add credit to their account and can then execute simulation applications on all cloud resources supported by the selected application.
The complexity of multi-cloud execution and billing is handled by the Platform. Desktop Applications extend desktop software with cloud execution support using one of the Platform APIs to redirect computation intensive simulations to cloud. Users download the package from the AppCenter, install it on their own machine, and then utilize its cloud extended capabilities. This solution enables vendors to keep the user interface (with minor modifications) of their original product and to use the accounting and billing functionality of the AppCenter accessed through their product. Web-based Applications are simply linked to the AppCenter. The web application can provide a complete custom portal-based user interface and can utilize capabilities of the Platform and the AppCenter accounting and billing mechanisms via suitable APIs.
To enable the development of applications that are directly deployed in the AppCenter or the extension of desktop applications with cloud support either the CloudBroker Java Client Library API or REST API, or the WS-PGRADE/gUSE Remote API can be used. Using the CloudBroker APIs bypasses WS-PGRADE/gUSE and provides direct access from the application to the multi-cloud resources supported by CloudBroker (i. e. when workflow is not required). Using the Remote API of WS-PGRADE/gUSE enables developers to execute complex application workflows linking multiple application components together on multiple clouds. For web-based applications, either the ASM (Application Specific Module) API of WS-PGRADE/gUSE is used that enables the rapid development of a custom portal/gateway in the form of customised Liferay Portlets, or a completely custom web interface can be developed embedding either CloudBroker API or gUSE Remote API calls.
C. CloudBroker A typical cloud implementation involves software being developed for one cloud (e. g. Amazon). Different clouds offer different functionality and costs. The concept behind the CloudBroker part of the CloudSME Simulation Platform is that it presents a cloud platform that developers can use to manage their implementations across multiple clouds. This means that once an application has been deployed on different clouds CloudBroker can help developers deliver a flexible service that enables cloud-based applications to be easily managed (and charged) across product offerings based on different cloud infrastructures. The CloudBroker environment is a web-based application store for the deployment and execution of compute-intensive applications on a cloud and widely automates user, software, resource, job, and invoice management.
It is suitable for any kind of batch-oriented command line software, both Linux-and Windows-based, and both serial or parallel processing (via MPI for example). It can be accessed through any web browser and through different APIs. To help developers create cloud-based applications across a variety of clouds, CloudBroker implements a range of cloud adapters. Once a cloud adapter has been implemented for a given cloud, CloudBroker effectively provides a common API for users to develop their applications (and so reduce the time taken to learn how to deploy to a different cloud). A user therefore develops their application for the CloudBroker APIs to create an application pattern for their software and cloud variant (typically distinguished by operating system requirements rather than specific cloud middleware).
III. CLOUD-BASED TRANSAT ASCOMP's TransAT consists of a GUI (front end) and a CFD solver (back end). The front end is used to setup the simulation, to define a mesh decomposition and to preprocess the required input parameters. This is then passed to the back end which compiles and then executes the simulation using the CFD solver. Once the simulation is finished, the results are visualized using post-processing software such as Paraview (www. paraview. org) or Tecplot (www. tecplot. com). The back end simulation execution can take a few seconds or a few weeks depending on the complexity of the experiment and computational capabilities. TransAT implements high performance computing parallel execution by using Open-MPI (www. open-mpi. org). From the TransAT GUI, a user can specify how many CPUs of a compute cluster to use.
The three development options were considered. Direct deployment into the AppCenter and Web-based implementations would have required a significant redevelopment of TransAT's front end into a Web-based version. The desktop alternative was therefore more attractive as only minor modifications were required. Setting up a download area on the AppCenter meant that users could download the package from the Web-based AppCenter, install it on their own machine, and then run their simulations on cloud through the TransAT front end. Prior to running, a user would set up an account on the AppCenter. The user would then login into TransAT and run their simulation. TransAT would synchronize with to the AppCenter to bill the user for cloud use. No workflow would be required as TransAT only ran one simulation at a time.
First an Application Pattern was created to enable the deployment of the TransAT back end on cloud. This consisted of an installation package containing an installation script, the zipped TransAT solver and a licence key. The TransAT Application Pattern uploaded to CloudBroker using the CloudBroker Web-based system. TransAT's front end was then modified to allow users to login into the AppCenter, to select from a list of available clouds and cloud instances (uploaded from CloudBroker at runtime) and to run and monitor their simulation. An AppCenter entry was created for TransAT that allowed users to create an account (and add credit) and.
Background: Transposable elements (TEs) constitute the most common repeated sequences in eukaryotic genomes. Recent studies demonstrated their deep impact on species diversity, adaptation to the environment and diseases. Although there are many conventional bioinformatics algorithms for detecting and classifying TEs, none have achieved reliable results on different types of TEs. Machine learning (ML) techniques can automatically extract hidden patterns and novel information from labeled or non-labeled data and have been applied to solving several scientific problems. Methodology: We followed the Systematic Literature Review (SLR) process, applying the six stages of the review protocol from it, but added a previous stage, which aims to detect the need for a review. Then search equations were formulated and executed in several literature databases.