dataesr/scientific-paragraphs-categorization huggingface dataset:
APOGEE In this paper, we release both DR11 and DR12 versions of the APOGEE outputs, with considerably more stars (see Table  1 ) in the latter. The APOGEE release is described in detail in  Holtzman et al. (2015). The DR11 parameters and abundances use the same version of the APOGEE Stellar Parameters and Chemical Abundances Pipeline (ASPCAP; A. E. García  Pérez et al. 2015, in preparation)  as in DR10. The DR12 version of ASP-CAP is a major upgrade, in which abundances are determined for 15 individual elements. In addition, the DR12 ASPCAP code incorporated a number of technical improvements: multiple searches to avoid local minima in parameter space, new model atmospheres with updated solar reference abundances and non-solar Carbonand α-element-to-Iron abundance ratios  (Mészáros et al. 2012) , the use of a Gauss-Hermite function instead of a Gaussian to represent the instrumental point-spread function, and upgrades to the atomic and molecular line lists.
Scope and Summary 142 SDSS data processing software is publicly available at http: //www. sdss. org/dr12/software/products/ The APOGEE DR11 data include twice as many stars and spectra as DR10 (53,000 more stars and 200,000 more spectra), analyzed with the same pipeline. The APOGEE DR11 data have been used in several papers, including a determination of distances to and chemical abundances of red-clump stars  (Bovy et al. 2014; Nidever et al. 2014) , mapping of the Galactic interstellar medium using diffuse interstellar bands measured along the line of sight to APOGEE stars  (Zasowski et al. 2015) , and an identification of new Be stars and their H-band line profiles  (Chojnowski et al. 2015). APOGEE DR12 represents a further year of data and thus includes another 46,000 stars and 240,000 spectra over DR11.
In addition, two previous ancillary programs were expanded in DR12. The IN-SYNC ancillary program (APOGEE TARGET2=13) to study young stellar objects in the Perseus molecular cloud (see  Cottaar et al. 2014 and Foster et al. 2015  for more details) was expanded in DR12 to observe 2,634 stars in the Orion A molecular cloud. The APOGEE ancillary program to observe Kepler stars for asteroseismology and stellar parameter calibration (APOGEE TARGET1=27) proved extraordinarily useful (e. g. ,  Epstein et al. 2014)  and was folded into the main APOGEE target selection for DR12.
DATA DISTRIBUTION The data for DR11 and DR12 are distributed through the same mechanisms available in DR10, with some URL modifications to accommodate the ongoing transition to SDSS-IV and an associated unification of the SDSS web presence under the sdss. org domain. Raw and processed image and spectroscopic data are available through the Science Archive Server 144   (Neilsen 2008)  and through an interactive web application. 145 he catalogs of photometric, spectroscopic, and derived quantities are available through the Catalog Archive Server 146   (Thakar et al. 2008; Thakar 2008a ). More advanced and extensive querying capabilities are available through "CasJobs", which allows time-consuming queries to be run in the background 147   (Li & Thakar 2008). GUI-driven queries of the database are also available through SkyServer.
Many of the BOSS ancillary programs described in Appendix A are exploratory or pilot studies to test aspects of eBOSS target selection. SDSS-I/II established our understanding of galaxies in the z ∼ 0. 1 Universe. The SDSS-IV Mapping Nearby Galaxies at APO (MaNGA) program (Bundy et al. 2015) will revisit 10,000 of these galaxies in far greater detail using integral-field fiber bundles to study spatiallyresolved galaxy properties, star formation, and evolution. As Figure  7  makes clear, APOGEE has sampled only a fraction of the Milky Way, and has missed the Southern skies completely. The APOGEE exploration of the Milky Way will continue with SDSS-IV. APOGEE-2 will use the existing spectrograph on the 2. 5-m Sloan Foundation Telescope. In addition, a second APOGEE instrument will be built and installed on the 2.
CMASS and LOWZ galaxies that were not observed in the main BOSS survey due to fiber collisions with other primary targets were added to ancillary target plates 6373-6398 (North Galactic Cap), 6780-6782 (on Stripe 82), 6369 and 6717. Fibers were also assigned to CMASS and LOWZ targets that suffered redshift failures (ZWARNING NOQSO>0; Bolton et al. 2012) in previous observations in the data reduction pipeline. These objects are identified with the CMASS or LOWZ target flags in the database; unlike all other objects discussed in this Appendix, they are not assigned a target class in ANCILLARY TARGET2. This program significantly increases the completeness of these galaxy samples in the region covered by these plates and provides a useful dataset for testing the fiber-collision correction methods that are currently used in BOSS clustering analyses (e.
g. ,  Guo et al. 2012). A total of 1282 targets were included in this program. These data have been used in an analysis of velocity bias in close pairs of galaxies by  Guo et al. (2015). Quantifying BOSS Galaxy Incompleteness with a WISE-Selected Sample: The CMASS sample is designed to select red galaxies of high stellar mass (M stellar > 10 11 M ). This program (target class WISE COMPLETE) aimed to explore a broader range of galaxy colors in the CMASS redshift range (0. 45 < z < 0. 7), using optical-IR cuts by combining SDSS and WISE. The sample criteria are 17. 5 < i < 19. 9, (r-W1) > 4. 165, and i fib2 < 21. 7 (the latter uncorrected for Galactic extinction). Various quality flag cuts were imposed to limit spurious sources. Stars were eliminated using the SDSS morphological classifications for blue objects and a color-color cut in (r -i, r -W1) space for red objects.
1995 ). An object is flagged QSO BOSS TARGET if it has been previously observed by BOSS and does not have either LITTLE COVERAGE or UNPLUGGED set in the ZWARNING bitmask (see Table  3  of  Bolton et al. 2012). Similarly, an object from SDSS DR8 is flagged QSO SDSS TARGET if it is included in the SDSS DR8 spectroscopic database, and similarly has neither of those flags set in ZWARNING. We separately flagged those quasars with QSO KNOWN whose spectra had been visually confirmed, as listed in the SDSS sample used to define known objects in BOSS (see  Ross et al. 2012) , and a preliminary version of the DR12 BOSS quasar catalog of I. Paris et. al. (2015, in preparation). As part of SEQUELS, we also re-observed a number of high-redshift (z > 2. 15) quasars that had low SNR spectroscopy in SDSS DR7 or BOSS, to improve the measurement of the Lyα forest.
A. 3. 4. TDSS targets within the SEQUELS program The TDSS program targeted variable objects matched between imaging in both Pan-STARRS1 and SDSS. There are two classes of TDSS targets: single-epoch spectroscopy (SES) and few-epoch spectroscopy (FES). Single-epoch spectroscopy: These targets comprise the main body of TDSS targets and are flagged with target class TDSS A. We match SDSS point sources with 16 < i psf < 21 to the PS1 "uberCal" database of 2013 September, restricting to objects with more than 10 detections across the PS1 griz bands. We also eliminate sources with a g < 22 neighbor within 5 or an i < 12 neighbor within 30 to avoid problems with deblending issues. To identify variables within this subsample, we use a three-dimensional Kernel Density Estimator. We train our algorithm on known variables, using the Stripe 82 variable catalog from  Ivezić et al.
(2012 Ak et al. ( , 2013)). A. 3. 5. Other Target Classes in SEQUELS Galaxies from the main BOSS target selection, both LOWZ and CMASS, that were not assigned fibers due to fiber collisions were observed in SEQUELS and given the target class SEQUELS COLLIDED. Observing these galaxies in SEQUELS creates large contiguous areas that have 100% spectroscopic completeness in the final BOSS data sample. A similar sample was described in Section A. 2. Variable targets selected from the PTF survey are targeted with the SEQUELS PTF VAR target class in three classes: hosts of supernovae detected in the PTF supernova program, RR Lyrae stars, and additional sources whose light-curve built from PTF data show variations by 0. 4 magnitude or more. Emission-line galaxy candidates tend to have blue colors and thus are relatively bright in the u band.
The participation of the  Osservatorio Astronomico di Torino  is supported by the  Italian Council for Research in Astronomy. Additional support is provided by  European Southern Observatory, Space Telescope European Coordinating Facility , the  International   GEMINI  project and the  European Space Agency Astrophysics Division. SDSS-III Data Release 12 selected a significant number of BOSS ancillary targets based on data products from the  Wide-field Infrared Survey Explorer , which is a joint project of the  University of California, Los Angeles , and the  Jet Propulsion Laboratory/California Institute of Technology , funded by the  National Aeronautics and Space Administration. SDSS-III Data Release 12 made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration et al.
2013). SDSS-III Data Release 12 made use of the Exoplanet Orbit Database and the Exoplanet Data Explorer at exoplanets. org. SDSS-III Data Release 12 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. SDSS-III Data Release 12 made use of data from Pan-STARRS1. The Pan-STARRS1 Surveys (PS1) have been made possible through contributions by the  Institute for Astronomy , the  University of Hawaii , the Pan- STARRS  Project Office, the  Max-Planck Society  and its participating institutes, the  Max Planck Institute for Astronomy, Heidelberg  and the  Max Planck Institute for Extraterrestrial Physics, Garching , The  Johns Hopkins University, Durham University , the  University of Edinburgh , the  Queen's University Belfast , the  Harvard-Smithsonian Center for Astrophysics , the  Las Cumbres Observatory Global Telescope Network Incorporated , the  National Central University of Taiwan , the  Space Telescope Science Institute , and the  National Aeronautics and Space Administration  under Grant No.
THE DEDICATED PLASTICITY CORE APPROACH The previous implementations of plasticity are not limited by the SpiNNaker hardware, but rather by their software implementation. Therefore, we present an alternative approach: instead of having a single core evaluating neural dynamics and plasticity, we divide the job into two parallel processes. One core performs the neural updates and spike integration, while the second core deals with plasticity (see Figures  2C, D ). Plasticity operates as a slower process in the background. It processes the whole synaptic block in SDRAM and the information about spike timing, and modifies the weights according to the chosen plasticity mechanism. The proposed approach takes inspiration from previous work where plasticity effects are accumulated and evaluated periodically  (Izhikevich, 2006; Nageswaran et al.
This leverages the reprogrammability of the general processors used by SpiNNaker and the generality of the event-driven API presented in  Sharp et al. (2011). The general infrastructure for the framework is presented in Appendix A. While it is worth noting that the difference between neural and the plasticity processes is only in the software running on the ARM cores, they can be thought of as hardware threads. The SpiNNaker software infrastructure does not support threads. If software threads were available, besides the costs related to thread switching, the neural and synaptic update threads would need to split between them the limited local memory (DTCM) and the processor cycles. In SpiNNaker, clock cycles are also limited in order to meet real-time targets. The proposed solution, on the other hand, uses hardware threads (cores), one for neural update and one for synaptic update, with each thread owning all of its local resources.
PERFORMANCE ANALYSIS AND DISCUSSION In  Diehl and Cook (2014) , the authors describe an STDP variation of the DED which follows the strategy proposed in  Morrison et al. (2008)  by storing traces in SDRAM, rather than performing spike pairing as proposed in  Jin et al. (2010b). The authors evaluate the performance of their implementation as well as the one present in the stable release of the SpiNNaker software package 1  in terms of synaptic events processed per second, as done in  Sharp and Furber (2013)  and  Stromatias et al. (2013). They do so by feeding a leaky integrate-and-fire population of 50 neurons with a neural population of variable size that produces spikes at ≈250 Hz, according to a Poisson process, with a 20% connection probability. They report that their implementation of plasticity is capable of handling around 500K synaptic events per second per core (using 150 input neurons), while the original SpiNNaker implementation is limited to 50K events.
, 2012). SpiNNaker has proven to be a well-suited platform for massively parallel large-scale simulations of spiking neural networks, and is flexible enough to let researchers implement and test their own computational models in standard programming languages. The previous Deferred Event Driven Model of handling events in SpiNNaker has made it difficult to implement plasticity rules with arbitrary triggering events (pre-, or post-synaptic, or at regular time intervals), rules which depend on third factors available only at the postsynaptic neuron, or plasticity in networks with variable axonal delays. We have presented here a framework which uses the modular architecture of SpiNNaker and delegates weight updates to dedicated plasticity cores, while the network simulation operates on the remaining neural cores.
g. , the computation of rates in an otherwise spike-based simulation. The architecture can be configured easily, using PyNN scripts. This standard, high-level neural language makes it easy to integrate and explore new learning rules into the SpiNNaker architecture. The approach presented in this paper is tailored to SpiNNaker and to its specific architecture, design and constraints. Nonetheless the same principles could be applied to other digitalanalog hybrid architectures, where efficient neural simulation could be realized on one neuromorphic chip, whereas complex plasticity rules could be realized off-chip on computers or FPGAs. Regarding GPUs it appears to be more favorable to let each kernel perform the same operation following the SIMD paradigm. Fidjeland et al. (2009)  sequentially use two different kernels, one for neural updates and one for applying plasticity updates.
Arbitrary fixed cut-offs (1-2%) are currently used, below which minor variants are discarded, but the errors generated during ultra-deep pyrosequencing are sequence-dependant rather than random, notably in homopolymeric regions  37. We have developed an automated position-specific processing of V3 env ultra-deep pyrosequencing data for rapidly inferring HIV-1 tropism with improved detection of minor variants (PyroVir software). It uses a sequence of logic rules based on the V3 sequence to discard artifactual or non-functional sequences with frame shifts or stop codons (biological filters), followed by a position-specific matrix based on Poisson distribution (statistical filter) to discard sequences with artifactual point mutations at V3 positions of interest. A particular attention had also been paid to provide a representative description of the virus quasispecies by limiting sampling and amplification bias prior to ultra-deep pyrosequencing.
Automated data cleaning of errors occurring during the ultra-deep pyrosequencing process. Ultra-deep pyrosequencing can generate errors that are sequence-dependant, notably in homopolymeric regions, rather than random. Our automated approach distinguishes authentic variants from artifactual ones resulting from errors arising during PCR amplification and ultra-deep pyrosequencing. Biological filters to discard non-functional V3 sequences. The sequences from the 454 ultra-deep pyrosequencing data were first processed with GS Amplicon Variant Analyzer (AVA) software (Roche). We did not use the AVA software cleaning filters that discard sequences under a fixed cut-off. Instead, the AVA alignments were extracted, truncated to the V3 env region, and gaps were removed. Reads with undetermined bases were discarded.
e. those having no criteria of the combined 11/25 and net charge rule) was based on the global error rate of the whole V3 region (μ = 0. 00742), as defined above. PyroVir software. This biological and statistical data cleaning strategy has been integrated in a program (PyroVir, IDDN FR. 001. 160011. 000. S. P. 2012. 000. 31230, Inserm-Transfert) that provides a fast, automated position-specific process for inferring HIV-1 tropism from V3 env 454 ultra-deep pyrosequencing data with improved detection of minor variants. The genotypic rule used to predict CXCR4-usage can be changed depending on the virus subtype, particularly for subtypes D and CRF01-AE for which we have developed specific algorithms  38, 39. An example of HIV-1 quasispecies coreceptor usage prediction by PyroVir is shown in Fig.
Ultra-deep pyrosequencing of HIV-1 V3 env allows to detect low levels of CXCR4-using variants that current genotypic approaches miss. However, the extremely large data sets produced pose challenging computational problems, particularly the need to clean up the sequences by removing artifactual errors generated during amplification and pyrosequencing. Our PyroVir software rapidly and reliably predicts HIV-1 coreceptor usage from 454 ultra-deep pyrosequencing data. It has two modules. The first, biological The least pejorative threshold between those of positions 11, and 25, and those required for a net charge of + 6 is used. filters, discard artifactual and non-functional sequences, particularly those due to frame-shifts generated by insertions or deletions of nucleotides in homopolymeric regions or stop codons.
Previous studies reported cases of virological failure under CCR5 antagonists due to minor variants < 1%  24  , while other found that a 2% cut-off optimally predicted the clinical response  34. Most of the data on the relevance of minor variants in HIV drug resistance have been reported in studies of non-nucleoside reverse transcriptase inhibitors (NNRTIs). Minor variants at frequencies of < 0. 5% have been demonstrated to have a clinical impact on the virological response  45. It has also been suggested that absolute numbers of resistant viruses are more clinically relevant than their frequencies for assessing the risk of subsequent virological failure. The measured frequency of viruses harboring a mutation associated with drug resistance should thus be multiplied by the plasma virus load to determine the absolute numbers of resistant viruses per mL of plasma.
Amplification steps. A 1009-bp nucleotide fragment encompassing the V1-V3 env region of HIV-1 RNA was amplified by RT-PCR. The linearity of the PCR amplification process was checked by comparing the proportions of X4 (LAI, GenBank accession no. K02013. 1) and R5 (JR-CSF, GenBank accession no. M38429. 1) clones in the pyrosequencing output with the input of X4:R5 virus clones mixed in proportions of 0:100, 0. 5:99. 5, 1:99, 5:95, 20:80, 50:50, 75:25, and 100:0, adjusted to a total input of 2,000-3,000 copies of RNA, and submitted to multiple parallel PCR amplifications with various numbers of cycles. The resulting optimized process used the SuperScript III One-Step RT-PCR System (Invitrogen) for RT-PCR with the following conditions: 60 min at 55 °C; 2 min at 94 °C; 30 s at 94 °C, 30 s at 55 °C, and 1 min 30 s at 68 °C for 10 cycles; the annealing temperature was then increased to 58 °C for the next 24 cycles, without a final extension step.
Genotypic prediction of HIV-1 coreceptor usage from V3 ultra-deep pyrosequencing data. The sequences of the V3 env regions were first processed using GS Amplicon Variant Analyzer (AVA) software, version 2. 5 p1 (Roche). This software extracts sequences from the standard flowgram format (SFF) files generated after pyrosequencing and automatically assigns each read to the proper sample by looking for the MIDs located at both ends of V3. Only sequences with an average phred equivalent quality score > Q30 were conserved. Moreover, only sequences that had been read in both senses were used for further analyses. The MIDs and primer sequences within the read have also to be complete without mismatch. Moreover, the reads have to match the full-length amplicon The sequence reads were aligned with the BaL consensus sequence (GenBank accession no.
001. Sensitivities of phenotyping and ultra-deep pyrosequencing for detecting and quantifying minor CXCR4-using variants. We assessed the capacity of ultra-deep pyrosequencing to detect and correctly quantify minor CXCR4-using variants in a virus population of CCR5-using variants using artificial mixtures of X4 and R5 virus clones that were phenotyped in parallel using the ultrasensitive TTT phenotypic assay  8. Three artificial mixtures of X4 and R5 virus clones were used: LAI (GenBank accession no. K02013. 1, X4 phenotype) and JR-CSF (GenBank accession no. , R5 phenotype); AFG04 (GenBank accession no. DQ136796. 1, X4 phenotype) and AFG01 (GenBank accession no. DQ136807. 1, R5 phenotype); CHS02 (GenBank accession no. DQ136867. 1, X4 phenotype) and CHS11 (GenBank accession no. DQ136859. 1, R5 phenotype).
CASTOR (the CERN Advanced STORage system) is used to store the custodial copy of all of the physics data collected from the CERN experiments, both past and present. CASTOR is a hierarchical storage management system that has a disk-based front-end and a tape-based back-end. The software responsible for controlling the tape back-end has been redesigned and redeveloped over the last year and was put in production at the beginning of 2015. This paper summarises the motives behind the redesign, describes in detail the redevelopment work and concludes with the short and long-term benefits.
Introduction The CERN Advanced STORage manager (CASTOR)  [1]  is used to archive to tape the physics data of past and present physics experiments. CASTOR currently holds about 100 PB of data. The tape transfer system is expected to face increasing challenges in the medium term-future, with the increasing amount of data recording from LHC experiments. This data flow increase is augmented by the periodic repacking of all data from one tape generation to the next  [2]   [3]. The CASTOR tape system is composed of a set of database-backed scheduling daemons for queueing file-transfer jobs and a set of disk and tape servers for carrying out those transfers. The jobs are either called migrations (to tape) or recalls (from tape) depending on their direction. This article describes the reimplementation of the software stack running on the tape servers.
A legacy software stack The previous tape server software stack initially evolved from the SHIFT  [4]  system, the predecessor of CASTOR. The daemons and utilities of SHIFT were left mostly intact, with additional daemons from CASTOR running on top of them. Those daemons implemented a hierarchical storage management (HSM) system by adding a namespace and a staging area. The daemons from SHIFT and CASTOR were initially developed in C including the tape server software stack re-written by this C++ project. This layering of processes created many interprocess interfaces, either through command line parameters or TCP connections. Those interfaces and the long modification history rendered software maintenance and extensions of the tape server software complicated and costly. The software also reached its performance ceiling, and provided only limited information for monitoring.