dataesr/scientific-paragraphs-categorization huggingface dataset:
We also describe one implementation of TOGGLE in a complete analysis pipeline designed for SNP discovery for large sets of genomic data, ready to use in different environments (from a single machine to HPC clusters). Conclusion: TOGGLE speeds up the creation of robust pipelines with reliable log tracking and data flow, for a large range of analyses. Moreover, it enables Biologists to concentrate on the biological relevance of results, and change the experimental conditions easily. The whole code and test data are available at https://github. com/ SouthGreenPlatform/TOGGLE.
Bioinformaticians have developed dedicated pipelines for specific experiments, using those bioinformatics softwares, as well as combinations of home-made filters (using conditional if ) and loops (using the classical while)  [3, 4]. However, those scripts are generally monolithic, in the sense that they cannot easily be transferred from one installation to another, or from one experimental subject to the following (different species, different conditions, etc. ). Moreover, even if some flexibility is offered to the user by modification of several options before launching, these modifications are generally not trivial, requiring either a long list in the command line, or provision of a complex option file. In addition, writing a new pipeline from scratch is labor-intensive and time-consuming, especially if all safeguards for file format, software execution, or file transfer are implemented each time.
The TOGGLE suite (for TOolbox for Generic nGs anaLysEs) was developed to optimize the creation of new NGS analysis workflows. What we propose here is a set of packages designed for fast implementation of robust and reliable pipelines. Each package represents either a NGS software manipulation or a set of dedicated tools (see Table  1 ). These packages are written in Perl, with unitary modules the most generic possible. TOGGLE is able to manage hundreds of samples at once, and is not limited to one application. It can be used on DNAseq, RNA-Seq, smallRNA, GBS, and any other sequence data. It can be installed on a variety of infrastructure, from a simple laptop computer to a large HPC cluster. Finally, the TOGGLE assays and options are based on a unique configuration file, that can be easily changed and adapted to each run.
Packages and modules We designed TOGGLE in a suite of more than 10 packages, gathering more than 60 different modules (functions or calling), which can be used independantly to quickly implement pipelines for NGS analyses. Each package represents either the use of a software suite (such as bwa  [5]  or Genome Analysis ToolKit GATK  [6] ), or a set of tools dedicated to a given operation or more general tools. Modules are Perl code wrappers for a central command or function, with a validation system for the entry file format, running command, and output (if any). Each module starts generally by calling the file format validation modules from the toolbox. pm package (for FASTQ, SAM and others), and then by sending a specific command line to the toolbox::run module. This module launches the command through the UNIX system, and will return either a given value for correct execution, a warning, or an error.
The toolbox. pm package gathers general tools and functionalities. This package will, among other things, read the software. config. txt file, manage printing of log files printing (see below) and the system command for all modules (Fig. 1 ). The software. config. txt file can be used to manage the options for the different softwares and modules of TOGGLE. This file is constructed in a basic layout, as shown in Fig. 2 , using the option representation specific for each software. If no specific parameters for a given software or module are provided in this file, the default values of the software/module will be used. The software. config. txt file (see Fig. 2 ) was developed with Biologist users in mind: this file is the only one to change for any option of any step of a given pipeline. The local-Config.
pm package will inform of the different softwares paths (for bwa e. g. ) on the user's local machine or server. Users can adapt the paths in this package, and can also test different versions or installations of the same software without having to change the whole pipeline code. Only those three packages/files are mandatory when creating a new script using TOGGLE. A large part of the coding effort was to produce a logging system that can be scaled for hundreds of individual analyses run in parallel (Fig. 3 ). The dedicated toolbox::exportLog module will recover the value transmitted by other modules to generate log information: (i) the module call succeeded; (ii) the module call started correctly but finished incorrectly; (iii) the module was not able to execute the command. The last two types of information will be recovered in the error log file (".
Example of implementation All the modules can be arranged to easily generate robust pipelines for NGS analyses. As an example, we provide two functional pipelines: an RNAseq data one (not detailed here) and a DNAseq pipeline for single and paired-end Illumina genomic data for SNP and InDel detection in any eukaryotic diploid species. This latter, that we describe here in details, is based on four scripts: pairAnalysis. pl, singleAnalysis. pl, mergeAnalysis. pl and globalAnalysis. pl (Fig. 4 ). The first three can be launched independently, while the last, globalAnalysis. pl, is a turnkey pipeline which launches and manages the three others (see Additional file 1). Both start with FASTQ format validation (purple boxes in Fig. 4 ), followed by a quality control using the FastQC software (yellow boxes in Fig.
4 )  [7] , and a cleaning step performed by the CutAdapt software  [8]  (sand boxes). For pairAnalysis. pl, an additional "repairing" stage (red boxes in Fig. 4 ) re-associates the paired-end reads and exports the single-end reads (which may be produced by the cleaning step) to the singleAnalysis. pl script independently from CutAdapt. This step may be excluded when using the last version of CutAdapt and its pair-end mode, but this is not yet implemented in TOGGLE. After cleaning, both scripts follow the same stages again, with specific parameters: mapping using bwa aln (blue boxes; bwa MEM module is also available)  [5] ; sorting, cleaning and indexing of the BAM files using PicardTools  [9]  and SAMtools  [10]  (brown and green boxes, respectively); local realignment with the GATK (orange boxes)  [6] ; and finally removal of duplicates using PicardTools (brown boxes).
The mapping is performed here using the bwa aln/sampe/samse back-track version. It is possible to switch to the bwa mem version by changing the code, as this module is already provided in the bwa. pm package. However, we decided to remain on the back-track version in this pipeline, as it is used in our labs and allows comparison with older In order to automate these steps for multiple samples, we created the globalAnalysis. pl script (in currently two versions: one linear and the second one parallelized for SGE type architecture). This script will also organize the data into different directories with a specific tree structure (Fig. 3 ) defined to facilitate access to intermediate files. The globalAnalysis. pl script will deal with a unique directory where the whole raw FASTQ data are stored, without correspondance of names between the two paired files (the forward can be named Ulysse and the reverse Enterprise).
The script will use the pairing::pairRecognition. pm module (red boxes in Fig. 4 ) to associate files of paired-end data. The first sequence ID (specific for each run) is used to create the pairs, and we validated this association step of more than 150 paired and single files. It creates independent folders for each sample/individual, on which pairAnalysis. pl or singleAnalysis. pl will be launched according to the data type. After these analyses, globalAnalysis. pl will recover the final BAM file and its index for each sample, and will execute the mergeAnalysis. pl script as described earlier (see Fig. 4 ). All those scripts are associated with an indicator file, individuSoft. txt, which inform which step of the analysis has been launched. This indicator file also permits to create the various logs files.
Indeed we constructed different level of log files: at global level (GLOBAL_ANALYSIS_date on Fig. 3 ); at sample/individuals level (indX_global_log on Fig. 3 ), and at package per individual level (indX_package_log on Fig. 3 ). This pipeline is a classical one for DNAseq analyses from FASTQ sequences to BAM files then VCF files, but with a lot of control regarding file structure and format, and is easy to manage in terms of specific and global options through the software. config. txt file. Moreover, it can be used with any reference genome (provided as Fig. 2  Softwares configuration file. The lines starting with "$" correspond to the name of the current module called (e. g. bwa aln). The lines just after list the option(s) associated with this call; the list of options is finished with an empty line.
Parallelization TOGGLE can manage parallelized jobs, and may be implemented on HPC cluster machines. Concurrent jobs can be launched using the globalAnalysisSGE. pl script for example, which will launch all individual pairAnalysis. pl (or singleAnalysis. pl) instances in different jobs. The specific SGE parameters for all individual jobs can be specified in the option file. For the moment, the main level of the paralellization is based on the sample level (each individual) only. We are conscious this is a main drawback compared to system such as HugeSeq  [4]  or Churchill  [3]  (see below). However, TOGGLE was designed to requested a very limited number of mandatory softwares/configuration outside of bioinformatics one. Thus it could be deployed on any kind of infrastructure. Nevertheless, in future versions we plan to develop a finer approach using a MapReduce/embarrassingly parallel approach, splitting each sample in multiples subsamples at the different levels (FASTQ, SAM/BAM, VCF), in a similar way to Churchill  [3].
Comparison with already available pipeline tools Different pipelines or pipeline development tools exist for NGS data. The graphical systems (such as Galaxy  [12] , Taverna  [13] , Tavaxy  [14] ) are limited in their options or the available tools, and are generally not able to reach the scale of thousands of samples. The command-line based systems are more versatile (see Table  2 ), but harder to use. GATK-Queue  [6]  is a scripting framework for the Genome Analysis ToolKit, which treats SAM/BAM or VCF files using GATK tools. GATK-Queue is based on the Scala language, and can create simple scripts. However, it is limited to GATK tools and will start only after mapping. The HugeSeq pipeline  [4]  uses a MapReduce-like approach on HPC clusters to optimize the calculation of genomic variants from a set of a few already cleaned FASTQ data.
The scripts are fixed, and parameters can be changed only in hard code modifications or through an extensive and complex command-line. Moreover, a lot of external commands have to be performed before analyses (e. g. creation of reference index and dictionary). Churchill  [3]  also uses an embarassingly parallel approach in order to achieve MapReduce performance. It is dedicated mainly to identification of genomic variants, and scripts are hard coded and can not be modified. It is possible to switch between different mappers and variant callers using a dedicated option file. However, the index and dictionaries for the references have to be created independently, and pair recognition is based only on file names. The whole path for all FASTQ files must be provided, and not all options are available for all softwares.
Finally, Churchill is freely available for academic purposes, as the other ones, but is not open-source. GotCloud  [15]  is a set of pipelines dedicated to massive NGS analyses, from already cleaned sequence data to association results. It is dedicated to detection of genomics variations, and can switch between mappers or callers. The options system is also based on a single file, but requires that the user knows the GotCloud version for each software option. Moreover, it runs only on clusters or in the Cloud (an Amazon EC2 instance is possible), and the name of all FASTQ files has to be provided. The bcbio-nextgen framework  [16] , written in Python, is highly modular, and is similar to TOGGLE. Different mappers and callers are already available, and others can be add easily. The framework can be used for germline variants, somatic variants and RNA-Seq, as for TOGGLE.
However, the reference sequences are limitated to a fixed set, and even if it is possible to add new items, the system requests those references to be listed. Compared to the similar frameworks currently available, the current implementations of TOGGLE scripts work on DNA and RNA, and begin with a set of raw FASTQ in a given folder. It will automate all steps, from identification of pairs (if any), creation of indexes and dictionaries for the reference, data cleaning and so on. The end-users only have to modify the basic option file software. config. txt, in which the very same options as for the command line softwares need to be written. TOGGLE can be extended easily for new bricks and software plugins, and new scripts for dedicated analyses can be assembled quickly. Moreover, TOGGLE can be installed in the user space (without admin rights) as well as at the system level, from a simple laptop to a HPC cluster or in the Cloud.
Installation Power users can install TOGGLE following the manual provided on GitHub https://github. com/ SouthGreenPlatform/TOGGLE. We are aware that installing all dependencies and working versions of a such large number of softwares is generally problematic and complex. Therefore, we provide alternative methods for installation, a Docker image (available at http://bioinfo- N N N N Y a Reference indexing Y N N N N Y a FASTQ to final Data Y N Y Y Y Y Multiple Samples Calling Y Y Y Y Y Y Modularity Y Y N N Y Y Between Sample Paralellization Y Y Y Y Y Y Within Sample Parallelization Y/N b Y b Y Y Y Y Structural Variant Analysis N N N Y Y N Annotation Y a Y N Y Y Y Scalability Y Y N Y Y Y Evolutivity Y Y Y Y Y Y Y signals that a feature is present, N is absent. Evolutivity means the possibility to add future module or functions to the system a Available as separated steps b Depending the considered step web.
mpl. ird. fr/toggle/toggle. tgz) and a bash script (available on the GitHub and at http://bioinfo-web. mpl. ird. fr/toggle/TOGGLEinstall. sh). The Docker image, based on the basic Ubuntu 14. 04 image from Docker Hub, is ready to run Out of the box any NGS data transferred in the container. The bash script can be run at user space level and will download all the versions that work with the current version of TOGGLE, and will adapt the different paths for TOGGLE to work. Nevertheless, for an optimized and stable installation, we recommend a more precise installation as detailed on GitHub.
Conclusion TOGGLE is a combination of tools for large-scale NGS analyses of DNA and RNAseq data. Users can easily modify the different options of the numerous softwares using the software. config. txt file, without going through the code for each step. Users who want to use the general scripts provided in the suite just have to launch the globalAnalysis. pl pipeline on the raw FASTQ files (in a single folder) and wait to get the BAM and VCF files. The efficient log files provide information and statistics on the data and pipeline progress quickly, as well as on potential errors or warnings. Thus, users can concentrate on the biological relevance of the results rather than on technical aspects, even if using a huge amount of data. Bioinformaticians can rapidly write new packages and modules useful for Biologists using a highly reliable system.
Acknowledgements Authors want to thank  Ndomassi Tando  for his great help for various software installations, the different β-testers that perform the first true data tests, the other members of the SouthGreen platform (http://www. southgreen. fr/)for their help, and  Dr Tomas Harrop  for his input in manuscript correction. We would like also to greatly thanks our reviewers for their very helpful comments in improving the mansucript. CM was supported by a grant from the  French National Research Agency ANR  ( AfriCrop  project  ANR-13-BSV7-0017 ). AK was supported by a grant from the  Agropolis Fondation  (This project is supported by AgropolisFondationunder the reference ID  1403-026  through the  « Investissementsd'avenir » programme(LabexAgro : ANR-10-LABX-0001-01 )). MA was supported by a " FloriPalm" Specific Research Agreement between CIRAD  and a  FASSB and "PalMarkers" research contract between CIRAD and PalmElit SAS.
Availability and requirement • Project name: TOGGLE • Project home page: https://github. com/ SouthGreenPlatform/TOGGLE • Operating system: Linux • Programming Language: Perl • Other requirements: Java 1. 7, bwa 0. 7. 2 or higher, SAMtools 0. 1. 18 or higher, CutAdapt 1. 2. 1 or higher, FastqC 0. 11. 1 or higher, PicardTools 1. 124 or higher, GATK 3. 3x or higher, Perl modules: Data::Dumper, Data::Translate, Test:More, Test::Deep, Capture::Tiny. • License: GNU GPLv3/CeCill-C.
Data inputs The cohort size of 12 year olds was set equal to the size (n = 400,000) used in previous economic analyses of HPV vaccination in Germany  [6]. Evidence from the literature was obtained in order to simulate the age-and gender-specific mortality associated with each of the HPV-related cancers. Age-specific incidences were obtained from the literature  [12] [13] [14]. In the absence of age-specific mortality data for all HPV-related cancers, except for cervical cancer, age-specific mortality was modeled as a percentage of the annual incident cases dying. The case fatality rates by disease were obtained from the GLOBOCAN IARC database for Germany  [12]. The epidemiological inputs in the model are described in the Additional file 1: Technical appendix. Vaccine efficacy was obtained from the clinical trials of the quadrivalent HPV vaccine (Gardasil SmPC).
The efficacy of the vaccine was weighted for the mortality and morbidity attributable to the HPV serotypes included in the vaccine i. e. HPV6/11/16/18 (Table  1 ). The cost for the two doses of the quadrivalent HPV vaccination was modeled at €244 VAT excluded (2 doses × €135. 75 minus 19 % VAT + €15. 10 administration cost) with a coverage rate of 55 % consistent with published economic analysis in Germany  [6]. Cost per case estimates for GW, CIN and HPV-related cancers were also obtained from the literature  [6, 2, 4, 5]. Vaccine efficacy and cost data are illustrated in Table  1. To conduct the aforementioned economic analyses, labor market lifetime outcomes based on expected norms were obtained. Age-specific wages and age and gender specific unemployment rates for the German male and female population were quantified annually in the model based from published sources  [10].
1  Cumulative incremental net discounted tax of the combined cohort over time. NPV: net present value Fig. 2  One-way sensitivity and scenario analyses for the fiscal BCR and, in this respect, is not different than any other funding or policy decisions made by governments. In addition, the modelled mortality and morbidity data in this study, do not take into account socio-economic status which may influence HPV incidence and mortality and treatment seeking patterns that, in turn, may affect labour productivity and tax revenue loss as measured by the human capital and generational accounting methods, respectively. Moreover, with the exception of cervical cancer, case-fatality rates were used to estimate agespecific mortality. It should also be noted that the results presented in this study are specific to the German macroeconomic setting.
The objective function (Eq. 1 to 3) formalizes these assumptions. Hydrological processes are represented as follows. The sub-river basins are represented as a flow network of 11 nodes interconnected though arcs representing river reaches (Figure  8 ). It is built up on the same database as the one used for the precedent cost-effectiveness analysis. At each node, a mass conservation equation is computed at a monthly time step equalling the total inflow to the node (the runoff of the sub-basin, the river flow coming from the upstream part of the total river basin, the return flows from the supplied Urban and Agricultural Demand Units (UDUs and ADUs respectively) to the total outflow (water supplied to the UDU and ADU, environmental flow, and the remaining additional discharge if any). In the nodes corresponding to a reservoir, the mass balance equation takes into account the seepage and evaporation losses, incorporating constraints on the maximum storage capacity (considering active capacity and flood protection rules).
Acknowledgments This paper is based on work conducted as part of several projects over more than 6 years. It benefited from the financial and technical support of the  Agence de l'Eau Rhône Méditeranée et Corse ;  Conseil Général de l'Hérault; Conseil Régional du Languedoc Roussillon et ONEMA. Funding was partly provided by the  IMPADAPT  project  /CGL2013-48424-C2-1-R ) from the  Spanish ministry MINECO (Ministerio de Economía y Competitividad)  and  European FEDER funds. Corentin Girard  is supported by a grant from the  University Lecturer Training Programme  ( FPU12/03803 ) of the  Ministry of Education, Culture and Sports of Spain. We are very grateful to  Y. Caballero  ( BRGM), S. Chazot (BRLi ),  E. Vier  and  F. Aigoui  (GINGERGROUP) and  L. Rippert  and his team from the SMVOL for their help during the project and for the data provided.
Small-angle X-ray scattering (SAXS) is a powerful methodology for the structural and dynamic characterization of biomolecules at low resolution  (6) (7) (8) (9). Recent advances in SAXS instrumentation and the development of software for the comprehensive interpretation of SAXS data in terms of structure make this technique an optimal tool to address the structural characterization of the interactome. Methods based on rigid-body modeling of SAXS data, such as SASREF  (10) , can generate structural models for protein-protein complexes by simultaneously fitting multiple SAXS/SANS data using simulated annealing algorithm. However, given that these methods rely exclusively on the SAS data, the resulting models display an inherent degeneracy. In addition, these techniques miss the highresolution information reporting on the details of intermolecular interactions.
Therefore, other strategies are necessary to incorporate the interacting surfaces of the partners to enrich the quality of the resulting models. One such strategy is the use of SAXS data in combination with advanced computational approaches, such as protein-protein dock-ing, to generate meaningful models of biomolecular assemblies. Several docking methods for structural prediction of protein-protein interactions have been reported. These methods are mostly based on rigid-body (or semi-flexible) sampling of the interacting molecules, followed by scoring and/or energy minimization  (11) (12) (13) (14) (15). Completely automatic docking can provide good models for specific proteinprotein interactions  (16) (17) (18) (19) (20). However, the recent CAPRI experiments (http://www. ebi. ac. uk/msd-srv/capri/)  (21) (22) (23) (24) (25)  have highlighted the limitations of current docking approaches and the necessity of using experimental information to help to identify the correct docking models  (20, 26).