dataesr/scientific-paragraphs-categorization huggingface dataset:
INTRODUCTION Advances in Next-Generation Sequencing (NGS) technologies have provided a cost-effective approach to unravel many biological questions, and revolutionized our understanding of Biology. Nowadays, any laboratories can be involved in large-scale sequencing projects, delivering astonishing volumes of sequence data. Although NGS are powerful technologies, they have produced a paradigm shift from data acquisition to data management, storage and in fine biological analyses. This has intensified the need for robust and easy-to-use pipelines to perform high-performance automated analyses. However, most pipelines depend on the sequencing method used to generate raw data and on the type of analyses to perform (variant calling, GWAS, differential gene expression,. )  (1, 2, 3, 4). To enable processing of large datasets, numerous pipelines frameworks are available, either web-based or command-lines based.
The formers, Galaxy  (5, 6)  or Taverna  (7)  for instance, can be easily understood by lab biologists as it is accessible via a graphical interface. Accessible to non-programmers, they allow adding additional workflows, picking up various prepacked software, but with limited access to their options. In addition, managing more than a dozen of samples, or having access to different versions of the same software, are not possible without having a high-level access level to the host servers. Thus, they are generally used for small-scale analyses, prototyping or training  (8). The second type of frameworks such as Snakemake  (9) , Bpipe  (10) , Ruffus  (11) , ClusterFlow  (12)  targets programmers and expert users. Many of theses tools rely on non-standard, adapted programming languages (e. g.
derived either from Python, Bash or Make). Even if bioinformaticians can write complex pipelines using those frameworks, they require high-level skills in programming and are not suitable for lab biologists. c 2017 The Author(s) This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons. org/licenses/ by-nc/2. 0/uk/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited. TOGGLe (Toolbox for Generic NGS Analyses) is an alternate solution mixing advantages from the two kinds of workflow managers, offering a robust and scalable bioinformatic framework for a wide range of NGS applications. Compared to the previous version (version 2 (13)), the current TOGGLe (version 3) is a framework based on command-line, and no more hard-coded pipelines, targeting both biologists and bioinformaticians.
Workflows are now designed through a simple text file specified by the user. TOGGLe is also highly flexible on the data type, working on sequencing raw data (Illumina, 454 or Pacific Biosciences), as well as on various other formats (e. g. SAM, BAM, VCF). Carrying out analyses does not require any programming skills, but only basic Linux ones. With TOGGLe, scientists can create robust, customizable, reproducible and complex pipelines, through an user-friendly approach, specifying the software versions as well as parameters. It thus offers access to a vast landscape of external bioinformatics software (Figure  1 ).
If no software parameter is provided, the default ones are used. TOGGLe will handle itself the input and output files as well as the references (if needed). The user can also use a software not included in TOGGLe with the generic tag followed by the command-line. Compressing or removing intermediate data Analyses generating a large amount of data, we included the possibility to gzip compress or to remove some intermediate data ($compress and $cleaner tags), as specified by the user in the configuration file (see manual). Setting jobs scheduler When analyzing large amounts of samples, TOGGLe workflows support parallel processing on high performance computing (HPC) systems. They run seamlessly on a workstation or clusters with either LSF, MPRUN, SLURM or SGE jobs schedulers. When the configuration file contains a tag composed of the symbol $ followed by one of the jobs scheduler name cited above, TOGGLe pipelines will be submitted as background parallel jobs; otherwise they will run in "local" linear mode.
The parameters provided through the configuration file (i. e. queue name, number of processors allocated) will be transmitted to the job submission scheduler. The jobs (one per sample) will be submitted as bash scripts automatically generated. In addition, the $env tag can be used to provide specific environment variables to be transferred to the scheduler via these bash scripts (such as the paths or modules to be loaded). Finally, node data transfer is automatically managed by TOGGLe when requested by user ($scp tag).
Workflows Management The core of TOGGLe is the toggleGenerator. pl script which (i) parses the configuration file, (ii) generates the pipeline scripts, and then (iii) executes them as parallel or global analyses (see Figure  4 ). Basically, toggleGenerator. pl compiles blocks of code (themselves allowing the launching of the different tools) to create the requested pipeline. It allows the developer to easily add any new tool without having to modify the main code.
Platforms, Installation and Customization TOGGLe currently runs on any recent GNU/Linux system (Debian Lenny and more, Ubuntu 12. 04 and more, and CentOS 6 and more were tested). TOGGLe was developed to be straightforward to install in several ways : manually (git clone), through a bash script, or using a Docker machine (available as a pre-packed machine as well as a DockerFile). A unique file (localConfig. pm) needs to be filled at installation to ensure the integration of the whole software list (path and version), allowing TOGGLe to run. However, the whole set of integrated tools is not required to run TOGGLe: one can use it only with SAMtools for instance, and does not need to install the other tools. More detailed information on the different installation procedures can be found at the TOGGLe website (http://toggle.
A tool targeting both biologists and bioinformaticians Ease of use TOGGLe drastically simplifies NGS analyses (such as SNP calling, differential expression for RNA, in silico assembly). Workflows can be easily set up in a few minutes through a unique configuration file, and can be executed through a short command line. In addition, TOGGLe offers access to all parameters without restrictions (or name change) proposed by each software. Finally, users can provide any reference files, without any additional step to add them, at the opposite of ClusterFlow  (12)  for instance. As prototyping optimized workflows (software order and parameters) requires a good knowledge of the tools to be used, numerous pre-defined validated configuration files are available on our website (http://toggle. southgreen.
fr/) for various type of analyses. In addition, the effective output files naming convention used by TOGGLe as the well-organized file tree make it easy for the user to identify the different dataset produced (see Supplementary Figure  1 ). Ease of development and evolution: Simpler is Clever TOGGLe is designed as a set of separated modules/functions and blocks of code, simplifying code integration and evolution. Each module is written either to run bioinformatic software (topHat2. pm, GATK. pm, for instance) or to ensure functionalities for a specific purpose (such as checking input file formats). The block files are composed of codes implementing a single function at a time. These blocks are then concatenated together following the user pipeline specifications by toggleGenerator. pl, to provide a dedicated script pipeline.
This code modularity as well as testing and development processes adopted in TOGGLe prevents the regressions and bugs, facilitating maintenance in a collaborative environment. Production and development versions, and speed of releasing Two versions of TOGGLe are available, the production one and the development version. The former (http://toggle. southgreen. fr) is validated on a large set of test data before any release, while the latter (http://github. com/SouthGreenPlatform/TOGGLE-DEV/), more up-to-date, is not completely validated and may provoke errors. Nevertheless, the development version is merged to the production version on a monthly basis, after unitary and pipeline tests and true data validation.
Reproducibility and traceability TOGGLe ensures that all experimental results are reproducible, documented as well as ready to be retrieved and shared. Indeed, results are organized in a structured tree of directories: all outputs are sorted into separate directories grouped by analyses type (sample or global analyses) and by workflow step (see supplementary figure  1 ). All parameters, commands executed as well as software versions are kept in logs and reports. Files such as the pipeline configuration or the input data used (reference file e. g. ) are duplicated in the output folder, in which are also produced the specific scripts used for the analyses. The original input files, at the opposite to reference and configuration files, are not duplicated to reduce disk usage. Finally, a PDF report for the whole analysis is produced, providing global and visual informations for each sample at each step of the workflow.
Large numbers of sample analyzed There is no true limits to the number of samples or the sequencing depth of a project that TOGGLe can take in charge. TOGGLe was already used on hundreds of samples jointly, from different types of assays (RNAseq, GBS, WGS,. ), different analyses (polymorphism detection, read count), and on different models (Table  3 ). The only observed current limits are the data storage and the computing capacities available. HPC and parallel execution TOGGLe supports different job scheduling systems and can be efficiently run either on a distributed computing system or on a single server (default behavior). According to the configuration file, TOGGLe can perform parallel analyses simultaneously, at the sample level. In addition, TOGGLe can transfer data on calculation nodes instead of working through NFS/network filesystem, in order to improve computation time and to reduce latency.
DISCUSSION & PERSPECTIVES Nowadays, data preprocessing and analyses are the main bottleneck of scientific projects based on the high-throughput sequencing technologies. To deal with this issue, various workflow managers have been proposed, with different philosophies. GUI tools (such as Galaxy) provides a graphical user interface to easily and quickly design workflows. They have been developed especially for users without any programming knowledge. While very useful for prototyping pipelines with a limited data set and for performing smallscale analyses, they are less suitable to carry out large scale analyses or to create highly flexible pipelines (e. g. access to the whole set of software options). In contrast, many of the recent published workflow managers are aimed at bioinformaticians (e.
g. Bpipe  (10) ), based on an extension of a programming language, allowing to design highly customizable and complex workflows through a command line interface. This efficiency comes at the expense of the ease of use. TOGGLe is an alternate solution taking advantages of these two kinds of tools. Based on a command line interface, it is suitable for bioinformaticians as well as biologists. Through a unique text file, it offers a simple way to build highly complex and completely customizable workflows for a broad range of NGS applications, from raw initial data to high-quality postanalyses ones. This ease of use allows to greatly reduce handson time spent on technical aspects and to focus on the analyses themselves. Thus, to improve user experience, TOGGLe performs, in a transparent way, different actions requested to ensure the success of the analysis: automatic reference indexing, data format checking, workflow structure validation, and so on.
Moreover, the current version of the configuration file is not exportable to another workflow system using CWL (Common Workflow Language), and it would be interesting to also provide in TOGGLe a translator to CWL. Finally, the current grain of parallelization is the sample level (as for ClusterFlow or Bpipe), and a lot of computation time can also be saved at that point. We are exploring the way to use embarrassingly-parallel approaches (splitting samples in numerous subsamples), in order to launch pipelines optimized on highly distributed infrastructures. As NGS analyses and sequencing technologies are continuously evolving, the modularity and the ease of development of our tool is a true advantage to stay up-todate. For instance, the two-year old previous version of our software, TOGGLe v2 (13), integrated only 50 tools and was hard-coded.
By now, more than 120 tools are available with TOGGLe v3, the pipeline creation system is much more flexible and robust, and new tools are under integration on a monthly basis to widen the scope of analyses possible using TOGGLe (metagenomics, pangenomics). • Project home page: http://toggle. southgreen. fr • Code repository: https://github. com/SouthGreenPlatform/TOGGLE • Operating system: GNU/Linux (CentOS, Debian, Ubuntu) • Programming Language: Perl 5. 16 of higher (5. 24 recommended) • License: GNU GPLv3/CeCill-C FUNDINGS CM was supported by grants from ANR (AfriCrop project #ANR-13-BSV7-0017) and NUMEV Labex (LandPanToggle #2015-1-030-LARMANDE). All authors are supported by their respective institutes.
Type of analyses Software names Data Preprocessing FastQC (15), FASTX-Toolkit  (16) , Cutadapt  (17) , Atropos  (18) , checkFormat tools * Demultiplexing Stacks (19) Mapping BWA  (20, 21) , TopHat  (22) , Bowtie  (23) , Bowtie2  (24) , CRAC (25) Assembly Trinity  (26) , TgiCl  (27) , Trans-Abyss (28) SAM/BAM Management and analysis Picard-Tools (29), SAMtools  (30, 31) , GATK  (32, 33, 34) , NGSutils  (35).
AVAILABILITY The source code is freely available at http://toggle. southgreen. fr, under the double license GNU GPLv3/CeCiLL-C. The TOGGLe website comprises a comprehensive step-by-step tutorial to guide the users to install and run the software. An online issue request is also available under GitHub of the South Green platform  (14)  (http://github. com/SouthGreenPlatform/TOGGLE/issues/) to report bugs and troubleshooting.
Participants Data came from the NYC Low-Income Housing, Neighborhoods and Health Study (N=120)  (Duncan et al. , 2014). Low-income housing residents in NYC were recruited through outreach activities, such as handing out flyers around public housing developments in NYC, circulating flyers through community-based organizations, or via social networks. Eligibility criteria to participate in the present study included: i) residing in public housing or a low-income residence in NYC; ii) 18 years or older; iii) reading and speaking English; iv) not being pregnant; v) no walking limitations; and vi) willing to carry a GPS unit for one week. The majority (80%) of our participants resided in public housing. Prior to data collection, we obtained informed consent from all participants. We collected the data in June through July 2014.
After downloading the GPS data using a Qstarz software program, we created a geodatabase to manage and visualize the GPS data; we then stored the data using ArcGIS (ESRI Redlands, CA). We removed implausible GPS data (i. e. geographically isolated points) and data with date time-stamp errors, and with duplicated time-stamps, resulting in removal of five participants. Six out of 120 participants did not have GPS data because of battery problems, user error, or failure to return the device. Two participants lacked sufficient data  (Duncan et al. , 2014). Five participants travelled outside NYC and had the device with them for the majority of the time outside of NYC, and so were not included in the total sample. Thus, the total sample in this study comprised 102 participants. There are no statistically significant differences in the participants' characteristics between the current (n=102) and the par- ticipants who were removed (n=18).
Food environments We created five objective food environment variables using ArcGIS 10. 4 software (ESRI, Redland, CA). We used the data on all restaurants' locations (i. e. fast-food restaurants [national chain/non-chain outlets, defined as fast food with no indication of wait service] and wait-service restaurants [table service, and chain/non-chain outlets indicating any types of wait service outlet]) from the NYC Department of Health and Mental Hygiene Restaurant Grading data. Each restaurant or food outlet was in business by the end of 2014. All other food outlets' locations (i. e. corner stores [bodegas/convenience stores with less than 2,000 square feet], grocery stores [small/large groceries between 2,000 and 5,999 square feet], and supermarkets [classified as chain or independent supermarkets]) came from the New York State Department of Agriculture and Markets, Licensing and Inspection data.
Statistical analysis We used ordinary least square to investigate relationships between GIS-measured food environment attributes (i. e. densities of fast-food restaurants, wait-service restaurants, corner stores, grocery stores, and supermarkets) and BMI and systolic and diastolic BP, clustered by census block group with robust standard errors, using PROC SURVEYREG in SAS version 9. 4 (Cary, NC, USA). All the analyses were controlled for clustering effect at the census block group with clustered robust standard errors. Further, we tested for non-linearity of the relationships by adding a quadratic term in the models. These associations were separately investigated for each 200 m and 400 m residential circular and network buffers around respondents' home addresses with respect to each food out-let type, as well as for each 200 m and 400 m GPS-defined activity space.
Data Analysis for Interferometry and Real-Time Tomography The Wollaston interferometry set-up introduced in the previous section can be used to measure phase projections along the propagation direction of the interferometry laser. An optically transmitting object that has a refractive index close to 1 (e. g. a gas jet) can be characterised. If the studied object can be assumed to be rotationally symmetric around a central axis, an Abel inversion yields the 3D density distribution from a single phase projection, i. e. a 2D projection obtained in one single observation direction, which is perpendicular to the axis of symmetry. In order to obtain the 3D density distribution of an object without such symmetry (e. g. a gas jet   with a shock front) several projections along different angles are needed.
The time required to reconstruct the density for N a = 7 projections is below 2 s. In order to create the parallel implementation of the algorithm, the TomoPy package for Python  [21]  together with the Astra toolbox  [22]  was used. TomoPy is a Python based framework for tomographic image reconstruction and data processing tasks developed at the Advanced Photon Source of Argonne National Laboratory. TomoPy includes many functions to perform preprocessing and image reconstruction using different algorithms  [21]. The Astra toolbox is an opensource project developed at the University of Antwerp. The toolbox provides tomographic image reconstruction of 2D and 3D data sets. The toolbox uses CUDA to offload the reconstruction algorithms to the NVIDIA GPUs, but most of the 2D algorithms can also be executed on the CPU  [22].
Using the TomoPy toolbox the algorithm described in section 3. 2. 1 is implemented in Python to perform the image reconstruction. Additionally, the Astra toolbox is used in order to target the GPU platform. The GPU platform is mostly targeted in order to evaluate the potential to perform real-time 3D image reconstruction as for the 2D reconstruction the power of the CPU is mostly sufficient. Reconstruction times of the algorithm are shown in the figure  12. The figure shows reconstruction times using 1, 4, and 8 CPU cores as well as reconstruction offloaded to the GPU. The hardware used in the reconstruction was 2x Intel Xeon E5-2609 v2 CPUs and 1x NVIDIA Tesla K40c. The time represented in the figure shows only the reconstruction time without input and output operations, which are constant for all the implementations.
Conclusion A simple single beam Wollaston interferometer has been described. The interferometer was used to measure gas densities in electron beam monitors for the free electron laser and to characterise shock fronts in a LWFA. Convergence and error studies of the used ML-EM algorithm show adequate accuracy of the presented problems. The use of parallel computation and GPU technology reduces the computational time below the data taking time. In that sense this represents real time density computation. The presented set-up is limited by the slow rotational stage and the low frequency of the gas jet due to the weak vacuum pump. These technical limits can be easily overcome, hence the time for a full 3D density reconstruction is estimated to be less than 10 s. We plan to explore the possibility of interleaving the measurement with the operation of the LWFA.
During the 2014 GEOVIDE transect, seawater samples were collected for dissolved Pb and Pb isotope analysis. 15 These samples provide a high resolution "snapshot" of the source regions for the present Pb distribution in the North Atlantic Ocean. Some of these stations were previously occupied for Pb from as early as 1981, and we compare the 2014 data with these older data some of which are reported here for the first time. Lead concentrations were highest in subsurface Mediterranean Water (MW) near the coast of Portugal, which agrees well with other recent observations by the U. S. GEOTRACES program (Noble et al. , 2015). The recently formed Labrador Sea Water 20 (LSW) between Greenland and Nova Scotia is much lower in Pb concentration than the older LSW found in the Western European Basin due to decreases in Pb emissions into the atmosphere during the past 20 years.
Westerly winds (30° -60° N), this produced the most visible oceanic contamination in the North Atlantic Ocean. Of relevance to this study (Figure  1 ), surface Pb concentrations  ([Pb] ) were measured in 1981  (TTO, Weiss et al. , 2003 ), 1989 (Atlantis II 123, this work; JGOFS, Martin et al. , 1993 ), 1993 (IOC-2, Veron et al. , 1999 ), and 1999 10 (Endeavor 328, Noble et al. , 2015 and this work). More recent campaigns through the GEOTRACES program have occurred in 2010 (GA02, The GEOTRACES Group, 2015) and 2010/2011 (GA-03,  Noble et al. , 2015). In the western North Atlantic, repeat sampling of time series locations have documented the reduction in oceanic  [Pb]  and changes in sources with time. At BATS (Bermuda Atlantic Time Series) in the 1970s and 1980s, 15 concentrations were 80 -160 pmol kg -1 near the surface but 25 pmol kg -1 at depth  (Boyle et al.
Sample Collection The GEOVIDE cruise track began in Lisbon, Portugal on 15 May 2014 and followed the OVIDE section from the Iberian upwelling system to the subpolar North Atlantic region up to the Greenland margin before continuing on to the Labrador Sea at the Canadian margin, finishing on 30 June 2014. One liter Nalgene HDPE sample storage bottles were acid cleaned and stored, double-bagged as previously described  (Noble et al. , 2015). Trace metal clean 35 seawater samples were collected using the French GEOTRACES clean rosette (General Oceanics Inc. Model 1018 Biogeosciences Discuss. , https://doi. org/10. 5194/bg-2018-29 Manuscript under review for journal Biogeosciences Discussion started: 2 February 2018 c Author(s) 2018. CC BY 4. 0 License. Intelligent Rosette), equipped with new, cleaned 12L GO-FLO bottles  (Cutter and Bruland, 2012).