dataesr/scientific-paragraphs-categorization huggingface dataset:
However, as illustrated in the Use Case 3-2, it is possible to keep track of these false negatives by implementing a workflow that annotates and counts viral reads before the de novo contig assembly steps. We developed Metavisitor in Galaxy in order to benefit from a well supported framework allowing execution of computational tools and workflows through a user-friendly web interface. In addition, the advanced Galaxy functionalities ensure the highest levels of computational analyses, through rigorous recording of the produced data and metadata and of the used parameters as well as the ability to share, publish and reproduce these analyses (see Metavisitor availability section in Experimental Procedures). Another major benefit is that, as any Galaxy workflow, the Metavisitor workflows may be modified or extended by users.
If they are already available in a Galaxy tool shed, integration of new tools in a workflow is straightforward, thanks to the Galaxy workflow editor. Although it requires coding skills, any other freely available software can be adapted to the Galaxy framework and used in a Metavisitor workflow. Through use cases, we have shown that Metavisitor is adaptable: short or longer reads from small RNAseq, RNAseq or DNAseq can be used as input data with or without adapter clipping; read datasets can be used as is, or compressed using reads-to-sequences or normalization by median procedures  [27] ; a variety of alignment and de novo assembly tools can be used, provided that they have been adapted for their execution in the Galaxy framework; finally, although we provide the vir1 nucleotide and protein references to identify sequences of viral origin users are free to upload and work with their own viral references.
Thus, Metavisitor provides biologists and clinicians with an accessible framework for detection, reconstruction or discovery of viruses. Viral sequences reconstructed by Metavisitor can be used in a large range of subsequent analyses, including phylogenetic or genetic drift analyses in contexts of epidemics or virus surveillance in field insect vectors, animal or human populations, or systematic identification of viruses for evaluation of their morbidity. In Use Cases 3-1 to 3-3, we have shown that Metavisitor allows analysis of numerous datasets in batch with consistent tracking of individual samples. Thus, we are confident that Metavisitor is scalable to large epidemiological studies or to clinical diagnosis in hospital environments. For instance, it could be used to analyse RNAseq data from Zika infected patients  [32, 33].
Finally, we wish to stress that Metavisitor has the potential for integrating detection or diagnosis of non-viral, microbial components in biological samples. Eukaryotic parasites or symbionts and bacteria are mostly detectable in sequencing datasets from their abundant ribosomal RNAs whose sequences are strongly conserved in the main kingdoms. This raises specific issues for their accurate identification and their taxonomic resolution that are not currently addressed by Metavisitor. However, many tools and databases  [34]  addressing these metagenomics challenges can be adapted, when not already, to the Galaxy framework. For instance, Qiime  [35]  and the SILVA database of ribosomal RNAs  [36]  can be used within Galaxy and could thus be integrated in future Metavisitor workflows aiming at detection and discovery of non virus organisms in deep sequence datasets.
The sequence of this Anopheles C Virus is deposited to the NCBI nucleotide database under accession number KU169878. As expected, when realigned to this genome (S12 Fig), the ERP012577 small RNA reads now show a typical alignment profile all along the AnCV genome sequence with a size distribution peaking at the 21nt length of viral show the abundance of 18-30-nucleotide (nt) small RNA sequence reads matching the genome sequences and histograms (middle) show length distributions of these reads. Positive and negative values correspond to sense and antisense reads, respectively. Total read counts are indicated to the right hand side. doi:10. 1371/journal. pone. 0168397. g002.
[28]Method section for a description of the columns. Both these workflows were equally able to assemble the genome KU169878 of the Anopheles C Virus (S13 File). Taken together, the Metavisitor Use Cases 2-1 and 2-2 illustrate that when short read datasets do not provide enough sequencing information, an adapted Metavisitor workflow (S11 Fig) is able to exploit long reads of RNA sequencing datasets, if available, to assemble a complete viral genome[28].
Acknowledgments We thank the  Galaxy community  for their support,  Juliana Pegoraro ,  Eugeni Belda  and  Emmanuel Bischoff  for helpful discussions and  Julie Reveillaud  for critical reading of the manuscript. GC, MvdB and CA conceived the project. CA and MvdB developed and implemented tools in the Galaxy framework. GC, MvdB and CA performed bioinformatics analysis. GC, MvdB, KV and CA wrote the manuscript. CA and KV provided funding. All authors read and approved the final manuscript.
This work received financial support to CA from the  Agence Nationale de la Recherche  grant  ANR-13-BSV2-0007  « Plastisipi » and from the  Institut Universitaire d' Ingenierie en SanteIUIS grant  " ARTiMED " and to KDV from the  European Research Council  (http://erc. europa. eu/fundingand-grants). Support for frontier research, Advanced Grant # 323173  AnoPath;  European Commission  (http://ec. europa. eu/research/fp7), FP7 Infrastructures #228421 Infravec ; and  French Laboratoire d'Excellence  (http://www. enseignementsup-recherche. gouv. fr/cid55551/investissements-d-avenir-projets-laboratoires-dexcellence-par-region-et-domaine. html)," Integrative Biology of Emerging Infectious Diseases " # ANR-10-LABX-62-IBEID. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
All data, codes and workflows are currently fully accessible in public repositories: https://toolshed. g2. bx. psu. edu/, https://github. com/ARTbio/tools-artbio, https:// artbio. github. io/Metavisitor-manual/, https:// mississippi. snv. jussieu. fr/, https://dx. doi. org/10. 6084/m9. figshare. 3179026. v1, http://www. myexperiment. org/users/65016/workflows.
reads in NGS datasets Metavisitor Virus detection Coverage of complete viral genome (%) Mean blast bit score Read mapping to vir1 using bowtie2 ENA-RUN SRR453487 SRR453437 SRR453443, SRR453458 SRR453430 SRR453491 SRR453499 SRR453484 SRR453464 SRR453506 SRR453417 SRR453490 SRR453478 SRR453465, SRR453480 SRR453489, SRR453505 SRR453498 SRR453446 SRR453427, SRR453440 SRR453438 SRR453450 (Continued) No Significant alignments 49 Human_herpesvirus_6 6154 reads Hepatitis_A_virus 38 Human_herpesvirus_4 58 reads Circovirus-like_NI/2007-376 Torque teno virus 66 reads Circovirus-like_NI/2007-3 29 Human_herpesvirus_6128 Torque teno mini virus 4 No Significant alignments 159 Dengue_virus_465 Circovirus- like_NI/2007 184 Human_herpesvirus_6 24 Torque teno virus 772 Torque teno virus 14 reads Stealth_virus_1_clone_C16130_T324 reads Dengue virus 2 5 reads Circovirus-like_NI/2007-312 reads Dengue virus 2 208 reads Circovirus-like_NI/2007-3 10 reads Circovirus-like_NI/2007-317 reads Dengue virus 2 22 reads Dengue virus 2 651 reads Dengue virus 2 1436 reads Dengue virus 2 - 239.
65 1852. 3 39. 19 302. 0 -- 39. 30 496. 8 55. 85 389. 4 -- 1. 26 185. 0 -- -- -- 2. 89 242. 0 88. 14 339. 0 31. 01 314. 7 0. 18 263. 0 -- Metavisitor Virus detection none none Dengue virus 2 Dengue virus 2 none Dengue virus 2 Torque teno virus (SEN virus) none GB virus C none none none Human parvovirus B19 Uncultured virus DNA Torque_teno_virus Human herpesvirus 6 none Patient # virus # initial Fraction Yozwiak et al. # reads in ID reads reads virus Virus NGS reads detection datasets 274 27 1. 20E 2. 30E-05 Dengue virus 1 6. 24E+05 +06 270 28 1. 20E 2. 33E-05 Human 6. 76E+05 +06 herpesvirus 6 266 135749 4. 80E 2. 80E-02 Dengue virus 2 3. 36E+06 +06 263 ND ND ND TTV (virochip) 3142332 193 56 1. 60E 3. 50E-05 Torque teno 9. 13E+05 +06 mini virus 2 187 4280 1. 10E 3. 90E-03 Dengue virus 2 5. 55E+05 +06 Torque teno 1.
Virus BioProject BioSample id SRX number SRR number Sample ID BAM file name Source Data Type, Selection Figure, Table from Matranga et al. Metavisitor detection (Trinity) + + + + + + + + + + + - Table 1 Table 1 Table 1 Table 1 Table 1 Table 1 Table 1 Table 1 Table 1 Table 1 ND, manually added to the original sup file 3 ND, manually added to the original sup file 3 Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection Hybrid Selection cDNA cDNA Mastomys Human Human Human Human Human Human Human Human Human Mastomys Mastomys Z002_HS G090_HS G771_HS G2230_HS ISTH0073_HS ISTH1137_HS ISTH2020_HS ISTH2025_HS ISTH2050_HS ISTH0230_HS LM032_Depleted LM032_Standard Z002 G090 G771 G2230 ISTH0073 ISTH1137 ISTH2020 ISTH2025 ISTH2050 ISTH0230 LM032 LM032 LASV PRJNA254017 SAMN03099732 SRX733678 SRR1613400 LASV PRJNA254017 SAMN03099733 SRX733679 SRR1613401 LASV PRJNA254017 SAMN02927477 SRX733682 SRR1613404 LASV PRJNA254017 SAMN02927399 SRX733680 SRR1613402 LASV PRJNA254017 SAMN02927483 SRX733683 SRR1613405 LASV PRJNA254017 SAMN02927500 SRX733685 SRR1613407 LASV PRJNA254017 SAMN02927503 SRX733686 SRR1613408 LASV PRJNA254017 SAMN02927504 SRX733687 SRR1613409 LASV PRJNA254017 SAMN02927510 SRX733688 SRR1613410 LASV PRJNA254017 SAMN02927484 SRX733684 SRR1613406 LASV PRJNA254017 SAMN02927592 SRX733689 SRR1613411 LASV PRJNA254017 SAMN02927592 SRX733691 SRR1613413 doi:10.
This paper describes the CMS trigger system and its performance during Run 1 of the LHC. The trigger system consists of two levels designed to select events of potential physics interest from a GHz (MHz) interaction rate of proton-proton (heavy ion) collisions. The first level of the trigger is implemented in hardware, and selects events containing detector signals consistent with an electron, photon, muon, τ lepton, jet, or missing transverse energy. A programmable menu of up to 128 object-based algorithms is used to select events for subsequent processing. The trigger thresholds are adjusted to the LHC instantaneous luminosity during data taking in order to restrict the output rate to 100 kHz, the upper limit imposed by the CMS readout electronics. The second level, implemented in software, further refines the purity of the output stream, selecting an average rate of 400 Hz for offline event storage.
The first level (L1) of the CMS trigger is implemented in custom hardware, and selects events containing candidate objects, e. g. , ionization deposits consistent with a muon, or energy clusters consistent with an electron, photon, τ lepton, missing transverse energy (E miss T ), or jet. Collisions with possibly large momentum transfer can be selected by, e. g. , using the scalar sum of the jet transverse momenta (H T ). The final event selection is based on a programmable menu where, by means of up to 128 algorithms utilizing those candidate objects, events are passed to the second level (high-level trigger, HLT). The thresholds of the first level are adjusted during data taking in response to the value of the LHC instantaneous luminosity so as to restrict the output rate to 100 kHz  [3] , the upper limit imposed by the CMS readout electronics.
The HLT, implemented in software, further refines the purity of the physics objects, and selects an average rate of 400 Hz for offline storage. The overall output rate of the L1 trigger and HLT can be adjusted by prescaling the number of events that pass the selection criteria of specific algorithms. In addition to collecting collision data, the trigger and data acquisition systems record information for the monitoring of the detector. After commissioning periods at 0. 9 and 2. 36  TeV in 2009, the first long running periods were at a center-of-mass energy of 7 TeV in 2010 and 2011, and 8 TeV in 2012. These proton-proton data, together with the first ion running periods (PbPb at 2. 76 TeV, and pPb at 5. 02 TeV), are referred to collectively as Run 1. During this period, the CMS trigger system selected interesting pp physics events at maximum instantaneous luminosities of 2.
The information from the GCT and GMT is combined in a global trigger (GT), which makes the final trigger decision. This decision is sent to the tracker (TRK), ECAL, HCAL or muon systems (MU) via the trigger, timing and control (TTC) system. The data acquisition system (DAQ) reads data from various subsystems for offline storage. MIP stands for minimum-ionizing particle. Each of the three muon detector systems in CMS participates in the L1 muon trigger to ensure good coverage and redundancy. For the DT and CSC systems (|η| < 1. 2 and |η| > 0. 9, respectively), the front-end trigger electronics identifies track segments from the hit information registered in multiple detector planes of a single measurement station. These segments are collected and then transmitted via optical fibers to regional track finders in the electronics service cavern, which then applies pattern recognition algorithms that identifies muon candidates and measure their momenta from the amount they bend in the magnetic field of the flux-return yoke of the solenoid.
Sources of deadtime can be subsystems asserting "not ready" via the trigger throttling system  [3] , the suppression of physics triggers for calibration cycles, or the trigger rules described above. The GT system logs all trigger rates and deadtimes in a database to allow for the correct extraction of absolute trigger cross sections from data. The trigger cross section is defined as σ = R/L, where R is the trigger rate and L is the instantaneous luminosity. Over the years of CMS running, the GT system has proved to be a highly flexible tool: the trigger logic implemented in the firmware of two ALTERA FPGAs (the L1 menu) was frequently updated to adapt to changing beam conditions, increasing data rates, and modified physics requirements (details in Section 5). Additional subsystems (e. g. , the TOTEM detector  [36] ) have also been configured as a part of the L1 trigger system.
Trigger monitoring and operations During data taking the angular distributions of objects satisfying the trigger and the trigger rates were monitored. As these two kinds of information are produced using two different software tools, they provide complementary information about the behavior of the trigger system that are useful in diagnosing problems. We use the central CMS data quality monitoring (DQM) tools  [81]  to monitor the angular distributions. The DQM tools process a small subset of events selected by the HLT and produce plots of η and φ of the trigger objects. The distributions are monitored for regions with abnormal appearances of either too many or too few events. The rates of each HLT path are monitored in each node of the HLT computing cluster, where the CMS data acquisition software records how many times each trigger path was successful.
The path information is summed over all nodes to give the total rate of each path. The summation occurs at every fixed integrated luminosity, and the results are written into a database. The HLT group has developed customized software to extract the rates from the database and compare them to expectations. The expected rate behavior is defined by fitting the trigger rates as a function of instantaneous luminosity using previously recorded data certified as good. Uncertainties from the fit provide an envelope of expected rate variations which sets the threshold for displaying warnings in the control room. A selected set of approximately 20 different representative triggers, out of the 400 of the HLT menu, is used for regular online monitoring. The selected HLT paths have either a large rate or an important physics signature.
The HLT resources and optimization As described in Section 2. 6, the HLT runs on an EVF consisting of three different types of machines. Two complementary methods are used to monitor the usage of this farm by the HLT menu. The first method directly measures the time taken by the HLT selection and reconstruction steps for each event during data taking. The second method rapidly samples every CPU in the farm to determine its state, and the time per event is calculated based on the frequency of finding the CPU in a non-idle state. The two methods give consistent results. Using the second method, the total busy fraction of the EVF can also be determined. To estimate the CPU usage of an HLT menu at a future (higher) instantaneous luminosity value, the average busy fraction over the course of an LHC fill is measured, and a fit is performed as a function of instantaneous luminosity, as shown in Fig.
74. An exponential function is found to give a good description of the data over a wide range of instantaneous luminosity and allows extrapolation to higher luminosities. In addition, we also measure the time per event for each type of machine used in the filter farm as shown in Fig. 75. The time per event is observed to be approximately linear as a function of luminosity on the Intel Xeon E5430 CPUs. The other two types of CPUs employ Intel's hyper-threading to run twice as many concurrent processes as there are physical cores by using parts of the CPU that would otherwise be idle. As a result, the time per event for these hyper-threaded CPUs increases faster than linearly as the CPU is saturated with increasing luminosity and input rate. Using this information, it is possible to calculate the maximum time per event of the HLT menu for a given L1 input rate, and also the instantaneous luminosity at which this limit would be reached.
The figure of merit used is the time per event for an Intel Xeon E5430 CPU. The filter farm configuration used during 2012 data taking was able to sustain an average processing time per event of approximately 200 ms for an L1 input rate of 100 kHz. In addition to the online monitoring of the HLT menus, each menu is validated in an offline environment before being used for online data taking. Each new version of the menu is compared to a previous version on a single machine to ensure that the CPU consumption does not exceed expectations. The menus are tested by running the HLT once with each menu over the same sample of previously collected events. The measurement is done using a machine with similar core architecture to the Intel Xeon E5430 CPU, and is performed using the direct timing measurement described above.
The HLT operations Following offline validation, HLT menus are validated in an online environment using the HLT online ("HiLTOn") test stand. In order to be as close as possible to the online environment, the HiLTOn is operated using the same run control interface as the CMS DAQ system. The HiLTOn hardware consists of 30 Dell PE 1950 machines with dual quad-core 2. 66 GHz CPUs and 16 GB of RAM. The test stand system is subdivided into three groups of ten machines. The first group is always kept identical to the PE 1950 machines used for data taking operations and thus can be used to validate menus on the current online software environment. The second group of machines may additionally be used to validate the performance of software updates, and HLT menus that depend on the updates, in an online environment.
Finally, the third subdivision of the HiLTOn is used to evaluate changes made to the HiLTOn itself. Two machines of each group are dedicated to the building of new online software releases. A third machine is always used to collect the output of the HLT and save events to disk. The remaining seven machines in each group are able to process events via seven instances of the HLT per machine, although only four machines are used for typical menu validation. The HLT validation is designed to maximize the performance and stability of HLT algorithms. As every event satisfying L1 trigger requirements is examined by the HLT, and several HLT decisions are based on analysis-quality physics objects reconstructed using information from all CMS subdetectors, HLT reliability is critical to the success of the experiment.
On rare occasions, typically below a few events per month during data taking, one or more HLT algorithms will experience a processing error while examining a collision event. These events are stored locally for later analysis and are used to improve the reliability of the HLT software. Roughly 0. 5% of the downtime during collision data taking operations from 2009 until 2012 (including all proton-proton and heavy ion collision operations at any center-of-mass energy) was due to problems with the HLT; 95% of this downtime was due to a single incident when corrupt detector input resulted in the HLT failure for every incoming collision event. Prior and subsequent data taking using the same HLT menu resulted in no loss of data. Ignoring this incident, the HLT was responsible for a negligible loss of collision data.
Summary The CMS trigger system consists of two levels: an L1 custom hardware trigger, and an HLT system with custom C++ software routines running on commodity CPUs. The L1 trigger takes input from the calorimeters and the muon system to select the events of physics interest. To do this, it uses identified leptons, photons, and jet candidates, as well as event-level information such as missing transverse energy. Trigger primitives are generated on the front-ends of the subdetectors and then processed in several steps before a final decision is rendered in the global trigger. The L1 calorimeter trigger comprises two stages, a regional calorimeter trigger (RCT) and a global calorimeter trigger (GCT). The RCT processes the regional information in parallel and sends as output e/γ candidates and regional E T sums.
The global trigger implements the menu of selection requirements applied to all objects. A maximum of 128 separate selections can be implemented simultaneously. Overall, the L1 decision is rendered within 4 µs after the collision. At most 100 kHz of events are sent to the HLT for processing. The HLT is implemented in software, and further refines the purity of the physics objects. Events are selected for offline storage at an average rate of 400 Hz. The HLT event selection is performed in a similar way to that used in the offline processing. For each event, objects such as leptons, photons, and jets are reconstructed and identification criteria are applied in order to select only those events which are of possible interest for data analysis. The HLT hardware consists of a processor farm using commodity PCs running Scientific Linux.
The subunits are called builder and filter units. In the builder units, event fragments are assembled to complete events. Filter units then unpack the raw data and perform event reconstruction and trigger filtering. Both the L1 triggers and HLT include prescaling of events passing defined selection criteria. The performance of the CMS trigger system has been evaluated in two stages. First, the performance of the L1 and HLT systems has been evaluated for individual trigger objects such as electrons, muons, photons, or jets, using tag-and-probe techniques. Most of the measurements considered come from the 2012 CMS data set, where data have been collected at √ s = 8 TeV. Performance has been evaluated in terms of efficiency with respect to offline quantities and to the appropriate trigger rate.