dataesr/scientific-paragraphs-categorization huggingface dataset:
This analysis allowed searching for sequence similarity-based homology between legume species providing an alternative approach to finding correspondence between linkage groups. QTL analysis for rust resistance was conducted using composite interval mapping (CIM) and multiple interval mapping (MIM) in MapQTL 6. 0 package  (Van Ooijen, 2011). Markers to be used as cofactors for CIM were selected by forward-backward stepwise regression. Significance thresholds of log of odds (LOD) corresponding to a genome-wide confidence level of P < 0. 05 were determined for each trait using the permutation test of MapQTL 6. 0 with 1000 iterations, according to  Barilli et al. (2010). Skewness and Kurtosis coefficients were calculated following  Lynch and Walsh (1997). The coefficient of determination (R 2 ) for the marker most tightly linked to a QTL was used to estimate the proportion of the total phenotypic variation explained by the QTL.
Genotyping and Linkage Mapping A total of 9,569 high-quality SilicoDArT and 8,514 SNPs markers were identified. Of these, a set of 8,538 SilicoDArT markers (89. 2%) and 3,483 SNPs markers (40. 9%) were selected for mapping after quality filtering. Thirty-five of the set of 46 SSRs markers previously described for P. sativum by  Loridon et al. (2005)  amplified in P. fulvum, which corresponded to a potential transferability rate of 76% for this marker type. However, only 12 markers were polymorphic. This meant that only 26. 1% of the SSR markers tested showed utility for mapping in our population. The remaining 21 yielded non-specific amplification and were excluded from further analysis. The mapping dataset was complemented with 20 of the 26 SNP markers (76. 9%) developed using the BeadXpress Primer Design (Illumina, San Diego, CA, USA)  (Deulvot et al.
Objective: bPeaks is a peak calling program to detect protein DNA-binding sites from ChIPseq data in small eukaryotic genomes. The simplicity of the bPeaks method is well appreciated by users, but its use via an R package is challenging and time-consuming for people without programming skills. In addition, user feedback has highlighted the lack of a convenient way to carefully explore bPeaks result files. In this context, the development of a web user interface represents an important added value for expanding the bPeaks user community.
Introduction ChIP-seq, i. e. chromatin immunoprecipitation sequencing, is an experimental approach to analyze protein interactions with DNA  [1]. Peak detection (also referred as "peak calling") consists of identifying all the genomic regions in which a significant enrichment of DNA sequences (or reads) in a ChIP sample is observed compared to a control sample. These regions are expected to represent DNA-binding sites for the studied protein  [2]. A considerable number of peak calling software packages have been developed (for instance  [3, 4] , etc. ) and choosing the appropriate software, optimized for a specific biological system of interest, is a prerequisite for successful ChIP-seq data interpretation. In this context, we proposed a methodology to identify "basic Peaks" (bPeaks) in small eukaryotic genomes  [5].
The general idea was to take advantage of simpler peak calling for species with small genome sizes (< 20 Mb). The program bPeaks thus performs an exploration of ChIP-seq results at the nucleotide scale. It uses a sliding window, which compares the read distributions between the immunoprecipitation (IP) sample and a control sample. We implemented the bPeaks program with the R language and the associated package is available at the CRAN website  [6]. Since its original publication, the bPeaks R package has been downloaded more than 11,360 times (July 2018) and successfully used to identify DNA-binding sites for different proteins in several yeast species  [7] [8] [9] [10]. Our colleagues, essentially experimental biologists, appreciate the simplicity of the bPeaks methodology. The program uses a combination of only four thresholds to mimic "good peak" properties, as described by investigators who visually inspect ChIP-seq results on a genome browser  [5].
However, they highlighted several difficulties. First, working with an R program is a challenging task for people with only limited bioinformatic skills. Initial installation of the necessary software and libraries, importing of the ChIP-seq data in R, and running a bPeaks search can be excessively difficult for simply technical reasons and may thus be an obstacle to the in-depth analysis of the results. Also, bPeaks generates a large number of output files (several dozen), which are all automatically written and stored in a single operating system (OS) folder. These files were meant to be helpful for further investigation (for example, detection of regulatory motifs), but feedback from users brought to our attention the need for their better organization and documentation. Finally, the bPeaks R package only comprises pre-registered annotations of genes for yeast species because our group's research activities are focused on functional genomics in yeast.
This is an important limitation for researchers interested in other organisms. We developed a new application to overcome these limitations. Referred hereafter as the "bPeaks App" (bPeaks application), it is used via a web browser and makes it possible to perform all the analysis steps required to identify protein DNA-binding sites with ChIP-seq results in a few mouse clicks. We developed new functionalities in the bPeaks App, relative to the original R package, to (i) evaluate the overall quality of the analyzed ChIP-seq data (Lorenz curve and PBC calculation), (ii) facilitate the exploration of output files (with a user-interactive genome browser), and (iii) upload annotation files to compare the location of the detected peaks with particular genomic elements of interest to the user, in any organism.
General overview The bPeaks App is a web application which uses the original bPeaks R package  [6]. The backend of the application is based on three mainstream open source technologies: Github  [12] , Docker  [13] , and PostgresSQL  [14]  (see Fig. 1a ). The frontend solutions of the application were chosen to provide users a particularly easy-to-use experience using Shiny, the Web Application Framework for R  [15]. The Plotly R package  [16]  a b was used to obtain dynamic graphical representations, together with Google chart  [17]. The application requires a database to control user access. The solution proposed by Shiny requires payment. Thus, we preferred another approach, based on a PostgreSQL database. Put very simply, the database is comprised of three tables: one to manage user information, one to manage an information dashboard and one for gene annotations (Fig.
Strategy for versioning the application Two complementary axes were considered to ensure appropriate versioning of the bPeaks App: (i) R package dependencies and (ii) OS dependencies. The package manager packrat  [19]  was used to precisely follow the latest versions of all the packages used for development of the bPeaks App. It saves libraries locally and generates a packrat. lock file. This file lists the detailed package versions that were used, including all dependencies. The bPeaks App was built on a containerization paradigm (see Fig. 1a ) with Docker, since R software is also dependent on the OS. Our objective was to entirely pack the application and its dependencies in a virtual container. Thus, it was possible to build images that contain everything required for the bPeaks App to function.
Installation The bPeaks App was meant to be installed either on a personal workstation or a laboratory web server. The application can manage several users and multiple simultaneous connections. The bPeaks App can be deployed on Linux, MacOS X, or Windows 10. Detailed information to deploy the bPeaks App can be found in Github README  [22]. Minimal requirements are: • 64 bits OS. • Docker community edition > v18 (with a minimum of 3 GB of RAM allocated). • Access to the internet (required for Docker image download). For deployment on a local workstation, installation scripts are available to create a launcher script to facilitate the use of the bPeaks App. This launcher starts all the components needed to run the application without entering a single command line.
Results bPeaks App With the new bPeaks App, our aim was to (1) simplify the use of the bPeaks peak calling method for those with no bioinformatics skills, (2) add several ChIP-seq data representations to assess the overall quality of the initial experiment, and (3) facilitate the exploration of peak calling results. Also, we wanted to guarantee the reproducibility of any results obtained with bPeaks App, systematically tracing all the analysis steps and computational tool versions. We decided to divide the application into two parts referred hereafter as "bPeaks analyzer" and "bPeaks explorer". bPeaks analyzer focuses solely on the peak calling step. Output files are automatically renamed and reorganized in different OS folders. These files represent the starting point for the bPeaks explorer part, which allows dynamic and user-interactive visualization of the detected peaks, as well as peak localization relative to particular genomic elements (coding or promoter sequences, DNA repeated regions, etc.
Discussion The objective of the bPeaks App is to empower the use of bPeaks, an efficient peak-caller in small eukaryotic genomes. With its docker, there is no need to worry about installing R and the necessary packages. Indeed, all packages and their dependencies are installed in the image available on Docker Hub. We used a package manager to allow reproducibility of the results. Thus, it is possible to reproduce an analysis with the same packages. Through the use of Shiny, the user does not need any computer or programming skills. The user is guided to enter the various parameters. To help him, information bubbles are available at each step. We provide quality controls (Lorenz curve, PBC, etc. ) to validate the experimental part. Thus, the user will know whether the analyses are of good quality or not before exploration.
Availability of data and materials Datasets. Example datasets for bPeaks App are available in the Github repository (data folder: https ://githu b. com/thoma sdene cker/bPeak s-appli catio n/ tree/v1. 0. 0/Data and database folder: https ://githu b. com/thoma sdene cker/ bPeak s-appli catio n/tree/v1. 0. 0/Datab ase). Raw sequencing data files (FASTQ files) associated to the ChIP-seq analyses of Pdr1 transcription factor (detailed in Additional file 3) in S. cerevisiae are available in SRA (https ://www. ncbi. nlm. nih. gov/sra) under accession SRX1441673 and SRX1441642. Detailed information regarding the ChIPseq data processing can be found in the original bPeaks article (see https ://doi. org/10. 1002/yea. 3031). Software. Project name: bPeaks Application; Project home page: https :// githu b.
This enabled neutron capture on chlorine, which has a higher capture cross section and produces a higher-energy signal more easily distinguished from backgrounds. In Phase III, a neutral current detection (NCD) array of 3 He-filled proportional counters was deployed in the detector. These counters provided an independent measure of the NC event rate. To evaluate the behavior of these signals in the SNO detector, we developed a highly detailed microphysical simulation of the detector, called SNOMAN  [1]. This software was used to simulate data to reflect exactly experimental conditions at any particular time (for example, the trigger thresholds during a particular run). Samples of Monte Carlo simulations of the various signal and background events generated with statistics equivalent to many years of livetime were used extensively in this analysis.
The data on the radial distribution of 8 B production and the electron number density in the Sun, taken from  [16] , are shown in Fig. 3. For each SNO 8 B Monte Carlo event, we randomly sampled a solar origin point and used this to calculate its survival probability for any choice of the mixing parameters. Templates for the changes to the reconstructed 8 B CC and ES energy spectrum for a fixed value of the mixing parameters (as defined in Table  I ) and for a Lorentzviolating coefficient c ð4Þ SNO ¼ 10 GeV -2 are shown in Fig. 4. These templates are meant only for illustration, and are not used explicitly in the final fit. The fit instead uses probability density functions (PDFs) for solar events which include both the standard model and Lorentz violating effects together. In the fit, the details of the standard solar model are included.
VII. CONCLUSION No evidence of Lorentz symmetry violations was found in an analysis of the data from all phases of SNO. Limits were established on all minimal, Dirac-type Lorentz violating operators in the neutrino sector; of these, 38 were previously unconstrained by experiment, and improved limits were set on 16 additional parmeters. The extensive coverage of the analysis is a consequence of the use of solar neutrinos, whose flavor changes in the Sun, due to the matter effect, make them sensitive to effects in all flavor components. Since the limits are roughly at the level expected from new physics at the Planck scale, they provide strong constraints on the possible kinds of beyond standard model physics that can be predicted by future theories.
ACKNOWLEDGMENTS This research was supported by  Canada: Natural Sciences and Engineering Research Council, Industry Canada, National Research Council, Northern Ontario Heritage Fund ,  Atomic Energy of Canada, Ltd. , Ontario Power Generation, High Performance Computing Virtual Laboratory ,  Canada Foundation for Innovation ,  Canada  Research Chairs program; US:  Department of Energy Office of Nuclear Physics, National Energy Research Scientific Computing Center, Alfred P. Sloan Foundation ,  National Science Foundation , the  Queen's Breakthrough Fund, Department of Energy National Nuclear Security Administration  through the  Nuclear Science and Security Consortium ;  United Kingdom: Science and Technology Facilities Council (formerly Particle Physics and Astronomy Research Council) ; Portugal: Fundação para a Ciência e a Tecnologia.
e. , Virtual Machines (VMs) and containers  (Al-Dhuraibi et al. , 2017b). Cloud elasticity can be accomplished by horizontal or vertical scaling. Horizontal elasticity consists in adding or removing instances of computing resources associated to an application  (Coutinho et al. , 2015). Vertical elasticity consists in increasing or decreasing characteristics of computing resources, such as CPU, memory, etc. (Lakew et al. , 2014). VMs and containers are the main computing re-source units in cloud computing. VMs are the traditional core virtualization construct of clouds. Containers are a new competitor, yet complementary virtualization technology to VMs. In this paper, we use Docker containers. Docker 1  , a recent container technology, is a system-level virtualization solution that allows packaging an application with all of its dependencies into standardized units for software deployment.
, 2017a). CRIU is a Linux functionality that allows to checkpoint/restore processes, e. g. , Docker containers. CRIU has the ability to save the state of a running process so that it can later resume its execution from the time of the checkpoint. We take many pre-dumps of the container while it is running, then a final dump for the memory page changes after the last pre-dump is taken (this time the Docker container freezes). While an efficient mechanism is used to transfer Docker containers, there is still downtime due to the migration when the container process is frozen. Table  1  shows migration down time for two small size applications (nginx, httpd). Network traffic overhead is not considered. Container migration is also risky for stateful applications such RTPM media applications to lose sessions.
Monitoring Component The monitoring component of Docker controller collects periodically current resource utilization and acquisition of every container on the host. The collected data can be (i) the resource utilization metrics such as CPU or memory current usage or (ii) the acquired resources such as memory size or CPU cores. This information is collected from the Docker daemon via its RESTful API and from the container cgroups filesystem directly. Our container controller monitors these cgroups each 4 seconds on an interval of 16 seconds, then the average values are reported. This monitoring data will be used in the reactive model in the elastic Docker controller to make elastic actions. Similarly, the host machine resource utilization and the amount of acquired resources are monitored periodically as shown in Table  2.
Experimental Setup We evaluated our work using RUBiS (OW2, 2008), a well-known Internet application that has been modeled after the internet auction website eBay. Our deployment of RUBiS uses two tiers: application tier, a scalable pool of JBoss application servers that run Java Servlets, and a MySQL database to store users and their transactions. We performed all our experiments on Scalair 2  infrastructure. Scalair is a private cloud provider company. We developed the experiments using the following technologies: (a) KVM version 1. 5. 3-105. el7 2. 7 (x86 64), libvirt version 1. 2. 17, virt-manager 1. 2. 1, the number of VMs used and their characteristics will be described in the specific experiment subsections because we have used different configurations based on the objective of the experiment.
Evaluation Results We describe each experiment and analyze the results in response to the RQs. RQ#1. In this experiment, we configure two VMs, each with Ubuntu Server 16. 04. 2 LTS. Initially, VM1 has 2 vCPUs with 2GB of RAM. We deploy RU-BiS application inside two containers on VM1. The ab benchmark is installed on VM2, then we generate a workload to the RUBiS application (i. e. , 600K requests, concurrency rate 200). The workload' requests query RUBiS database to retrieve lists of products, categories, items, etc of the auction website. The difference between workloads is the intensity and concurrency levels. We let the default policy for Docker containers which allow to use all the available resources. The VM controller is enabled, we register the response time when the workload requests are finished, it was 588.
We enabled the elastic container controller (which will allow to use the resources available on the hosting VM) and it is named Elas-ticDocker controller. We measure the total execution time and the mean response time of concurrent requests for each workload as shown in Figure  2. In scenario 2 , we deploy RUBiS application on one VM (VM2) and its database in another VM (VM3). The VMs have 1 vCPU and 1GB of RAM each. We enabled the vertical VM controller to adjust resources according to workload demand and then register the total execution time and the mean response time of concurrent requests for each workload as shown in Figure  2. In scenario 3 , we use the same configuration as in scenario 1 , except that we enabled our coordinating controller which controls elasticity of containers on the VM, and if there are no enough resources, it will add resources to the VM level.
This demonstrates that the equation V cont. V vm > V vm ⊕V cont is true. RQ#4. The aim of this experiment is to provide a comparison between horizontal elasticity of containers and our coordinating vertical elasticity of VMs and containers. We use Kubernetes horizontal elasticity. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. To achieve the experiment, we use Kubernetes version v1. 5. 2. Our deployment of RUBiS on Kubernetes uses three tiers: a loadbalancer (we use Kubernetes service to perform this role), a scalable pool of JBoss application servers, and a MySQL database. Kubernetes platform is deployed on 3 nodes running CentOS Linux 7. 2. RUBiS is deployed in two containers, in addition to a load balancer. Then, we set the Kubernetes Horizontal Pod Autoscaling (HPA) to scale RUBiS containers based on rule-based thresholds.
CRISPR databases Bioinformatics and their capabilities can accelerate molecular epidemiologic investigations in post genomics era. In this regard, several special CRISPR databases and tools have been developed during recent years. There are two general categories of CRISPR database: 1) Gene Editing based databases, and 2) Genotyping based databases. The second group (Genotyping based databases) is a database that deposits CRISPR sequences and their annotations. CRISPR Finder  [63]  and CRISPRdb  [48]  are the best examples of Genotyping based databases that are specific resources for deposition of CRISPR loci and spacers in some prokaryotic genome. But, since Genotyping based databases do not cover all bacterial genomes, a flowchart designed here as (Fig. 2 ) could be used for discovering CRISPR regions in bacterial and archeal complete genomes  [48].
CRISPR Tools Despite the presence of several various bioinformatic tools for identifying direct repeats in the genome, due to the importance and nature of CRISPR composition, specific software applications have been developed for discovering them in prokaryotic genomes and metagenomes including CRISPR Finder, CRISPR Recognition tool (CRT), PILER-CR, and CRISPI. Among them, the CRISPR Finder is freely accessible at http://crispr. u-psud. fr/crispr/, a user-friendly web service that contains information about CRISPR systems in several bacterial genomes which can identify and extract CRISPR array and spacers. This program can find the largest number of possible CRISPRs, especially the shortest ones that only contain one or two spacers  [63].
Conclusion: The CRISPR loci have potential for broad genotyping of bacterial strains and could be further used in an epidemiological survey  [41]. CRISPR features can, moreover, be used for host-virus environmental studies, offering a specific immunity against undesirable genetic elements, and increasing viral resistance in domesticated microbes  [57]. By use of CRISPR loci as a template for genotyping, we retrieve information more precisely to define the epidemic strains, because the spacers inserted in a polarized manner at the leader end of CRISPR loci can lead to provide a genetic basis for the detection of historical path of a strain, share ancestry between strains and establish phylogenetic relationships. So, these hypervariable loci of the CRISPR with novel Bioinformatics tools for processing of highthroughput sequencing data, and the visualization of complex datasets are broadly useful for epidemiological surveys.
Photobleaching parameters were controlled by iLAS2 module (Roper Scientifics, Trenton, USA). The whole system was driven by MetaMorph software (Molecular Devices, San Jose, USA). Images were recorded with a CoolSNAP HQ2 CCD camera (Photometrics, Tucson, USA). Blue (491 nm Cobolt Calypso DPSS, 100 mW; Cobolt, Solna, Sweden) laser was used for excitation of the GFP and photobleaching. For super resolution STED microscopy on living plants, we used a DMi 6000 TCS SP8Xgated STED (LEICA, Wetzlar, Allemagne) microscope equipped with a HCX PL APO 100×/1. 40 STED oil immersion objective and a continuous 592 nm depletion laser. To obtain STED and confocal acquisitions of the same field of view, we used the sequential mode. During STED first sequence, a 592 nm depletion laser was combined with a 491 nm excitation wavelength.
FT-IR 4-day-old etiolated plants were used for FT-IR acquisitions. Seedlings were fixed in 70% v/v ethanol solution overnight and transferred in water overnight the day before data acquisition. The rehydrated seedlings were then laid down on gold-coated microscope slides and left to dry for 20 min at 37°C. The zone targeted for the acquisition of spectra was the top (below the hook), middle and bottom of the hypocotyl. Spectra were collected using a Nicolet iN10 MX FT-IR Microscope (Thermo Scientific). Eight interferograms were collected in the reflection mode with 8 cm -1 resolution and co-added to improve the signal-to-noise ratio of the spectrum.