dataesr/scientific-paragraphs-categorization huggingface dataset:
As mentioned in Section 3, the JMR in simulation is corrected by 1. 07 ± 0. 12 to match the measured difference between data and MC simulation for the mass of W boson jets in lepton+jets tt events  [52]. The JMS in MC simulation approaches unity for larger jet p T and masses. Deviations from unity are included directly in the response matrix, as described in Section 3. The pileup uncertainty is estimated by reweighting the pileup distribution of the MC simulation up and down, assuming a change of the minimum bias cross section by 2. 7%  [53]. For the absolute cross section, the luminosity uncertainty of 2. 7% is also taken as an additional systematic uncertainty. The PDF uncertainty is taken from the PDF4LHC15 NLO 100 meta-PDF set using the PYTHIA8 generator. The physics model uncertainty is evaluated by comparing a response matrix derived from PYTHIA8 to a response matrix derived from HERWIG++.
Acknowledgments We congratulate our colleagues in the CERN accelerator departments for the excellent performance of the LHC and thank the technical and administrative staffs at  CERN  and at other  CMS institutes  for their contributions to the success of the CMS effort. In addition, we gratefully acknowledge the computing centres and personnel of the Worldwide LHC Computing Grid for delivering so effectively the computing infrastructure essential to our analyses. Finally, we acknowledge the enduring support for the construction and operation of the LHC and the CMS detector provided by the following funding agencies:  BMWFW  and  FWF (Austria) ;  FNRS  and  FWO (Belgium) ;  CNPq ,  CAPES ,  FAPERJ ,  FAPERGS , and  FAPESP (Brazil) ;  MES (Bulgaria) ;  CERN ;  CAS, MoST , and  NSFC (China) ;  COLCIENCIAS (Colombia) ;  MSES  and  CSF (Croatia) ;  RPF (Cyprus) ;  SENESCYT (Ecuador) ;  MoER ,  ERC IUT , and  ERDF (Estonia) ;  Academy of Finland ,  MEC , and  HIP (Finland) ;  CEA  and  CNRS/IN2P3  (France);  BMBF ,  DFG , and  HGF (Germany) ;  GSRT (Greece) ;  NKFIA (Hungary) ;  DAE  and  DST (India) ;  IPM (Iran) ;  SFI (Ireland) ;  INFN (Italy) ;  MSIP  and  NRF (Republic of Korea) ;  MES (Latvia) ;  LAS (Lithuania) ;  MOE  and  UM (Malaysia) ;  BUAP ,  CINVESTAV ,  CONACYT ,  LNS ,  SEP , and  UASLP-FAI (Mexico) ;  MOS (Montenegro) ;  MBIE (New Zealand );  PAEC (Pakistan) ;  MSHE  and  NSC (Poland) ;  FCT (Portugal) ;  JINR (Dubna) ;  MON, RosAtom ,  RAS ,  RFBR , and  NRC KI (Russia) ;  MESTD (Serbia) ;  SEIDI, CPAN, PCTI , and  FEDER (Spain) ;  MOSTR (Sri Lanka) ;  Swiss Funding Agencies (Switzerland) ;  MST (Taipei) ; ThEPCenter, IPST, STAR, and  NSTDA (Thailand) ;  TUBITAK  and  TAEK (Turkey) ;  NASU  and  SFFR (Ukraine) ;  STFC  ( United Kingdom );  DOE  and  NSF (USA).
New analyses often require novel combinations of multiple tools, and the heterogeneity of scientific software makes management of a software stack complicated and error-prone. Moreover, it inhibits reproducible science  (Mesirov, 2010; Baker, 2016; Munafò et al. , 2017) , because it is hard to reproduce a software stack on different machines. System-wide deployment of software has traditionally been handled by administrators, but reproducibility often requires that the researcher (who is often not an expert in administration) is able to maintain full control of the software environment and rapidly modify it without administrative privileges. The Conda package manager (https://conda. io) has become an increasingly popular approach to overcome these challenges. Conda normalizes software installations across language ecosystems by describing each software package with a recipe that defines meta-information and dependencies, as well as a build script that performs the steps necessary to build and install the software.
Conda prepares and builds software packages within an isolated environment, transforming them into relocatable binaries. Conda packages can be built for all three major operating systems: Linux, macOS, and Windows. Importantly, installation and management of packages requires no administrative privileges, such that a researcher can control the available software tools regardless of the underlying infrastructure. Moreover, Conda obviates reliance on system-wide installation by allowing users to generate isolated software environments, within which versions and tools can be managed per-project, without generating conflicts or incompatibilities (see online methods). These environments support reproducibility, as they can can be rapidly exchanged via files that describe their installation state.
Conda is tightly integrated into popular solutions for reproducible scientific data analysis like Galaxy  (Afgan et al. , 2016) , bcbio-nextgen (https://github. com/chapmanb/bcbio-nextgen), and Snakemake  (Köster and Rahmann, 2012). Finally, while Conda provides many commonly-used packages by default, it also allows users to optionally include additional repositories (termed channels) of packages that can be installed.
Results In order to unlock the benefits of Conda for the life sciences, the Bioconda project was founded in 2015. The mission of Bioconda is to make bioinformatics software easily installable and manageable via the Conda package manager. Via its channel for the Conda package manager, Bioconda currently provides over 3000 software packages for Linux and macOS. Development is driven by an open community of over 200 international scientists. In the prior two years, package count and the number of contributors have increased linearly, on average, with no sign of saturation (Fig. 1a, b ). The barrier to entry is low, requiring a willingness to participate and adherence to community guidelines. Many software developers contribute recipes for their own tools, and many Bioconda contributors are invested in the project as they are also users of Conda and Bioconda.
Bioconda provides packages from various language ecosystems like Python, R (CRAN and Bioconductor), Perl, Haskell, as well as a plethora of C/C++ programs (Fig. 1c ). Many of these packages have complex dependency structures that require various manual steps to install when not relying on a package manager like Conda (Fig. 2a , Online Methods). With over 6. 3 million downloads, the service has become a backbone of bioinformatics infrastructure (Fig. 1d ). Bioconda is complemented by the conda-forge project (https://conda-forge. github. io), which hosts software not specifically related to the biological sciences. The two projects collaborate closely, and the Bioconda team maintains over 500 packages hosted by conda-forge. Among all currently available distributions of bioinformatics software, Bioconda is by far the most comprehensive, while being among the youngest (Fig.
2d ). c ) package count per language ecosystem (saturated colors on bottom represent explicitly life science related packages). (d) total downloads per language ecosystem. The term "other" entails all recipes that do not fall into one of the specific categories. Note that a subset of packages that started in Bioconda have since been migrated to the more appropriate, general-purpose conda-forge channel. Older versions of such packages still reside in the Bioconda channel, and as such are included in the recipe count (a) and download count (d). Statistics obtained Oct. 25, 2017. To ensure reliable maintenance of such numbers of packages, we use a semi-automatic, agent-assisted development workflow (Fig. 2b ). All Bioconda recipes are hosted in a GitHub repository (https://github. com/bioconda/bioconda-recipes).
Both the addition of new recipes and the update of existing recipes in Bioconda is handled via pull requests. Thereby, a modified version of one or more recipes is compared against the current state of Bioconda. Once a pull request arrives, our infrastructure performs several automatic checks. Problems discovered in any step are reported to the contributor and further progress is blocked until they are resolved. First, the modified recipes are checked for syntactic anti-patterns, i. e. , formulations that are syntactically correct but bad style (termed linting). Second, the modified recipes are built on Linux and macOS, via a cloud based, free-of-charge service (https://travis-ci. org). Successfully built recipes are tested (e. g. , by running the generated executable). Since Bioconda packages must be able to run on any supported system, it is important to check that the built packages do not rely on particular elements from the build environment.
Therefore, testing happens in two stages: (a) test cases are executed in the build environment (b) test cases are executed in a minimal Docker (https://docker. com) container which purposefully lacks all non-common system libraries (hence, a dependency that is not explicitly defined will lead to a failure). Once the build and test steps have succeeded, a member of the Bioconda team reviews the proposed changes and, if acceptable, merges the modifications into the official repository. Upon merging, the recipes are built again and uploaded to the hosted Bioconda channel (https://anaconda. org/bioconda), where they become available via the Conda package manager. When a Bioconda package is updated to a new version, older builds are generally preserved, and recipes for multiple older versions may be maintained in the Bioconda repository.
The usual turnaround time of above workflow is short (Fig. 2d ). 61% of the pull requests are merged within 5 hours. Of those, 36% are even merged within 1 hour. Only 18% of the pull requests need more than a day. Hence, publishing software in Bioconda or updating already existing packages can be accomplished typically within minutes to a few hours. Figure  2 : Dependency structure, workflow, comparison with other resources, and turnaround time. (a) largest connected component of directed acyclic graph of Bioconda packages (nodes) and dependencies (edges). Highlighted is the induced subgraph of the CNVkit  (Talevich et al. , 2016)  package and it's dependencies (node coloring as defined in Fig. 1c , squared node represents CNVkit). (b) GitHub based development workflow: a contributor provides a pull request that undergoes several build and test steps, followed by a human review.
If any of these checks does not succeed, the contributor can update the pull request accordingly. Once all steps have passed, the changes can be merged. (c) Turnaround time from submission to merge of pull requests in Bioconda. (d) Comparison of explicitly life science related packages in Bioconda with Debian Med (https://www. debian. org/devel/debian-med), Gentoo Science Overlay (category sci-biology, https://github. com/gentoo/sci), EasyBuild (module bio, https://easybuilders. github. io/easybuild), Biolinux  (Field et al. , 2006) , Homebrew Science (tag bioinformatics, https://brew. sh), GNU Guix (category bioinformatics, https://www. gnu. org/s/guix), and BioBuilds (https://biobuilds. org). The lower panel shows the project age since the first release or commit. Statistics obtained Oct.
With its ability to maintain isolated software environments, the integration into major workflow management systems and the fact that no administration privileges are needed, the Conda package manager is the ideal tool to ensure sustainable and reproducible software management. With Bioconda, we unlock Conda for the life sciences while coordinating closely with other related projects such as conda-forge and Biocontainers. Bioconda offers a comprehensive resource of thousands of software libraries and tools that is maintained by hundreds of international contributors. Although it is among the youngest, it outperforms all competing projects by far in the number of available packages. With almost six million downloads so far, Bioconda packages have been well received by the community. We invite everybody to participate in reaching the goal of a central, comprehensive, and language agnostic collection of easily installable software by maintaining existing or publishing new software in Bioconda.
How isolated software environments enable reproducible research With isolated software environments as shown above, it is possible to define an exact version for each package. This increases reproducibility by eliminating differences due to implementation changes. Note that above we also pin an R version, although the latest compatible one would also be automatically installed without mentioning it. To further increase reproducibility, this pattern can be extended to all dependencies of DESeq2 and Salmon and recursively down to basic system libraries like zlib and boost (https://www. boost. org). Environments are isolated from the rest of the system, while still allowing interaction with it: e. g. , tools inside the environment are preferred over system tools, while system tools that are not available from within the environment can still be used.
Conda also supports the automatic creation of environment definitions from already existing environments. This allows to rapidly explore the needed combination of packages before it is finalized into an environment definition. When used with workflow management systems like Galaxy  (Afgan et al. , 2016) , bcbio-nextgen (https://github. com/chapmanb/bcbio-nextgen), and Snakemake  (Köster and Rahmann, 2012 ) that interact directly with Conda, a data analysis can be shipped and deployed in a fully reproducible way, from description and automatic execution of every analysis step down to the description and automatic installation of any required software.
Security Considerations Using Bioconda as a service to obtain packages for local installation entails trusting that (a) the provided software itself is not harmful and (b) it has not been modified in a harmful way. Ensuring (a) is up to the user. In contrast, (b) is handled by our workflow. First, source code or binary files defined in recipes are checked for integrity via MD5 or SHA256 hash values. Second, all review and testing steps are enforced via the GitHub interface. This guarantees that all packages have been tested automatically and reviewed by a human being. Third, all changes to the repository of recipes are publicly tracked, and all build and test steps are transparently visible to the user. Finally, the automatic parts of the development workflow are implemented in the open-source software bioconda-utils (https://github.
Software management with Conda Via the Conda package manager, installing software from Bioconda becomes very simple. In the following, we describe the basic functionality assuming that the user has access to a Linux or macOS terminal. After installing Conda, the first step is to set up the Bioconda channel via: $ conda config --add channels conda-forge $ conda config --add channels bioconda Now, all Bioconda packages are visible to the Conda package manager. For example, the software CNVkit  (Talevich et al. , 2016) , can be searched for with $ conda search cnvkit in order to check if and in which versions it is available. It can be installed with:.
Reproducible software management and distribution is enhanced by other current technologies. Conda integrates itself well with environment modules (http://modules. sourceforge. net/), a technology used nearly universally across HPC systems. An administrator can use Conda to easily define software stacks for multiple labs and project-specific configurations. Popularized by Docker, containers provide another way to publish an entire software stack, down to the operating system. They provide greater isolation and control over the environment a software is executed in, at the expense of some customizability. Conda complements containerbased approaches. Where flexibility is needed, Conda packages can be used and combined directly. Where the uniformity of containers is required, Conda can be used to build images without having to reproduce the nuanced installation steps that would ordinarily be required to build and install a software within an image.
In fact, for each Bioconda package, our build system automatically builds a minimal Docker image containing that package and its dependencies, which is subsequently uploaded and made available via the Biocontainers project (da Veiga Leprevost et al. , 2017). As a consequence, every built Bioconda package is available not only for installation via Conda, but also as a container via Docker, Rkt (https://coreos. com/rkt), and Singularity (Kurtzer et al. , 2017) , such that the desired level of reproducibility can be chosen freely (Grüning et al. , 2017).
, 2016). The sampling strategy took ecosystem service provisioning as the base of socio-ecological stratification. A multi-level binomial logistic regression model has been used to systematically assess the contribution of provisioning ecosystem services to income across the diverse socio-ecological systems (SES). Equal number of representative households (HHs), meeting the research criteria were selected from each SES following multi-stage random sampling. Primary data was collected through three rounds of cross sectional HH survey, four months apart covering February 2014 to 2015 timeframe. Drinking water samples, food consumption information and blood pressure was collected from more than 1,500 households (1,586, 1,516 and 1,531 households in first, second and third survey round respectively).
For each round, data was collected from the same respondents in the same households. The questionnaire instrument was designed to generate precise quantitative and spatially explicit data on the nature of the relationship between ecosystem services and human well-being. Data were collected at household level, with certain subjective questions and health assessment through anthropometry and blood pressure measurements at individual level. A panel dataset was created from three cross-sectional surveys; bivariate analysis was performed to understand household characteristics and socio-demographic status within the seven SES. Water samples were collected manually based on standard protocols and field practices (G. K. Khadse, 2010 , Sundaram et al. , 2009). Samples were collected from all types of drinking water sources except bottled water and rainwater since they were assumed as saline free.
Acknowledgements We are grateful to the research participants and their families from  Khulna and Barisal  for their valuable time, generosity and patience for the study. We acknowledge the contribution of  Associates for Community and Population Research (ACPR)  team for their hardwork in survey implementation. We are thankful to  Md. Zahirul Haq ,  Mohammed Mofizur Rahman ,  Dilruba Begum  and  Sate Ahmad International Centre for Diarrhoeal Disease Research, Bangladesh  (icddr,b) for their assistance in the survey,  Md. Mahabub Arefin Chowdhury of Bangladesh University of Engineering and Technology (BUET)  for GIS support, and  Ms Kristine Nilsen  of  University of Southampton  for valuable suggestions in data analysis.
Data harmonisation The genetic association data for BW and breast cancer susceptibility were based on imputation using the 1000 Genomes reference panel, while all other data sets had been imputed using HapMap. Out of the 59 BW-associated lead SNPs that were also present in the breast cancer data set, summary statistics were available for 26 SNPs across all data sets (Supplementary Table  3 ). For an additional 26 SNPs, proxy SNPs in linkage disequilibrium with the BW-associated lead SNP (r 2 > 0. 6 in European samples) were previously identified by Horikoshi et al. [29]. The same proxies were used here because they were available across all data sets (Supplementary Table  3 ). For a further two SNPs (rs10402712 and rs7402982), proxies with r 2 > 0. 6 in European samples (rs11667352 and rs2017500, respectively) were identified in the current study using the SNP Annotation and Proxy (SNAP) Search tool version 2.
2 (http:// archi ve. broad insti tute. org/mpg/snap; [37] ). No suitable proxy SNP was identified for four BW-associated lead SNPs (rs61830764, rs138715366, rs72851023, and rs144843919). A fifth SNP (rs11096402) is an X-chromosome variant mapped only in the BW and breast cancer data sets. In summary, breast cancer data were available for 59 of the 60 BW-associated lead SNPs. When considering these two data sets together with the seven additional "risk factor" data sets, 54 BW loci had results listed across all data sets [26 represented by BW-associated lead SNPs and 28 by correlated (r 2 > 0. 6) proxy SNPs]. The signs of the beta coefficients for each SNP across all summary data sets were aligned to the BW-increasing allele (except for age at first birth and number of children ever born, where only P-values were available).
Univariable Mendelian randomisation Of the 54 BW loci represented across all data sets, 13 demonstrated association with at least one of the seven breast cancer risk factors at P < 5 × 10 -8 (Supplementary Table  3 ). The BW-associated lead SNP at the 41 loci that did not show genome-wide significant pleiotropic associations were used to construct the main 41-SNP IV for univariable MR analyses (these SNPs are highlighted in Supplementary Table  2 ). This was done to ensure that the univariable MR analyses were, as far as possible, evaluating the association between BW and adult breast cancer risk independent of the effects of SNPs that were also associated with other potential laterlife breast cancer risk factors such as adult height. MR was first performed using the inverse-variance weighted (IVW) method wherein SNP associations with the outcome (breast cancer) were regressed on SNP associations with the exposure (BW) using a linear model weighted by the inverse of the variance of SNP associations with the outcome  [38].
Further, the MR-Egger regression intercept provides an estimate of the average pleiotropic effect over all SNPs in the IV and if this differs from zero, it indicates the presence of horizontal pleiotropy  [41]. The null hypothesis that this intercept did not differ significantly from zero was also tested. The R package MendelianRandomization (v0. 2. 2) was used for the penalised robust IVW MR analysis and TwoSampleMR for all other MR methods  [42, 43]. Pleiotropy was also assessed by calculating Cochran's Q as a measure of between-instrument heterogeneity using the Wald ratios for each SNP in the 41-SNP IV  [44]. To identify specific SNPs in this IV that contributed to observed heterogeneity and were potentially pleiotropic, four steps were taken. First, SNPs were removed iteratively from the 41-SNP IV until Cochran's Q test was no longer significant at the P < 0.
Statistical power The 41-SNP IV explained 1. 3% of the variance of BW (F-statistic = 46. 1) and had over 80% power to detect 11% increase (or decrease) in overall breast cancer risk in the univariable MR analysis (odds ratios (ORs) of 0. 89 or 1. 11 per 1-standard deviation (SD; 500 g) higher BW). The 59-SNP IV explained 2% of the variance of BW (F-statistic = 49. 7) and had over 80% power to detect 9% increase (or decrease) in overall breast cancer risk in the univariable MR analysis (ORs of 0. 91 or 1. 09 per 1-SD higher BW). For comparison, the largest observational investigation of the association between BW and breast cancer risk  [7] , a pooled analysis of individual participant data from 32 studies (22,058 breast cancer cases and 604,854 non-cases) identified 6% increase in breast cancer risk or a pooled relative risk per 1-SD (500 g) higher BW of 1.