dataesr/scientific-paragraphs-categorization huggingface dataset:
ITN use during the study period also applies to the pre-study period 1   Village Ratio for the incidence of primary infection in Sunuhu compared to Ilaita (regions within the study area) 1 There was no special ITN campaign in the pre-study or study periods doi:10. 1371/journal. pntd. 0004582. t001 polymorphic for the method to work well: many co-infections have the same allele as this locus. This supports the use of P vivax MS16 for the primary analysis. We also ran the analysis with and without the frequent P vivax msp1F3 alleles. To describe the observed longitudinal patterns, we summarize data from the 143 children with at least one visit at each of the 9 routine study time-points. There were 1837 P vivax MS16 genotypes detected in 143 children with samples at each routine time-point: of the genotypes detected, 1283 (69%) were observed in one interval per child (e.
Acknowledgments We thank  Katie Colborn ,  Felipe de Jesús Colón-Gonzalez ,  Diggory Hardy ,  Manuel Hetzel ,  Natalie Hofmann ,  Martin Jacquot ,  Stephan Karl ,  David Lister ,  Nicolas Maire ,  Peter Pemberton-Ross ,  Leanne Robinson ,  Christian Schindler ,  Mariabeth Silkey ,  Adrian Tompkins ,  Rahel Wampfler ,  Lisa White  and  Michael White  for helpful exchanges. The analyses were run using the sciCORE scientific computing core facility at the  University of Basel.
We also train the rescoring function for different complex classes and demonstrate its improved performance for an independent dataset. Results: The trained rescoring function produces a better ranking than ZDOCK for more than 50 % of targets, rising to over 70 % when considering only enzyme/inhibitor complexes. Conclusions: This study demonstrates for the first time that energy functions derived from the coarse-grained OPEP force field can be employed to rescore predictions for protein-protein complexes.
Background One of the main goals of proteomic research is to understand the biological function of proteins. Many proteins generate their function not as monomers but as part of complexes. Thus knowledge about protein-protein interactions is fundamental and allows regulation of protein structure and function. The Protein Data Bank (PDB)  [1]  contains more than one hundred thousand protein structures. However, structures of protein-protein complexes are often difficult to determine experimentally. These complexes are usually very big, which is a problem for elucidating structure via nuclear magnetic resonance (NMR), and the interactions are often too transient to be captured by X-ray crystallography. Protein-protein docking is an in silico method for predicting the structures of protein-protein complexes.
86 , with which the predictions are rescored. Steps (3) to (  6 ) are iterated 30 times on the training dataset perform 140 minimization steps in full Cartesian space with the limited-memory Broyden-Fletcher-Goldfarb-Shanno (LBFGS) minimizer  [25] , which leads to minimization times between 3. 5 s for the target with PDB ID 1AY7 (185 amino acids) and 250 s for the target with PDB ID 2HMI (1413 amino acids) on a single CPU core. This amounts to an overall minimization time for the 2000 ZDOCK predictions per target of less than 24 h for 85 % of targets. Afterwards, the minimized predictions are reranked. For this, we replaced the side chain-side chain interaction potential of OPEP with a softer 8-6 Lennard-Jones-potential, while preserving the optimal distances and energies (step (2) in Fig.
1 ). At this stage, the OPEP potentials for salt bridges, interactions involving backbone atoms, and H-bonds are not changed. In a further step, we trained the parameters of side chain-side chain interactions, including salt bridge interactions with an iterative learning approach with the aim of further improving the performance of the OPEP-based rescoring function (steps (3)-(  6 ) in Fig. 1 ). The resulting scoring function is tested on another dataset to independently prove its ability to distinguish between native and non-native complexes.
The dataset We use two different benchmarks to perform unbound docking. ZDOCK benchmark 4. 0 is used as training dataset, while for further evaluation we use the Dockground benchmark 2. 0. We used a subset of ZDOCK benchmark 4. 0  [26]. We downloaded the docking predictions for 6°angular sampling from the ZDOCK website, which were obtained using ZDOCK 3. 02  [27]. Ninety-six complexes were selected, including 39 enzyme/inhibitor, 19 antigen/antibody, and 38 other types of complexes. The latter will be called 'other complexes' for the remainder of this paper. One condition for selecting these complexes is that ZDOCK found at least one hit in the top 2000 predictions. A hit is defined as a prediction with an interface root mean square deviation (IRMSD) from the target of lower than 4 Å. Complexes that contain small molecules like ATP and GTP, for which OPEP is not parametrized, were not considered.
The 1N2C complex could not be used, because it has more than 15,000 beads after coarse graining and the fixed file format for parametrization in OPEP currently only allows for up to 9999 beads. The second dataset is a subset of the Dockground benchmark  [24]. Here we follow the same selection criteria as for the ZDOCK benchmark. Furthermore, we remove complexes present in ZDOCK benchmark 4. 0 in order to generate an independent and unbiased test set. The resulting test set contains 74 targets with 18 enzyme/inhibitor, 16 antigen/antibody, and 40 other complexes. As before, to generate complex predictions we applied ZDOCK with 6°sampling, using a local ZDOCK 3. 02 installation and keeping the top 2000 predictions. As in the ZDOCK dataset, the docking for the antigen/antibody complexes was restricted to the complementarity determining regions (CDRs).
For the parameter k, values between 0. 1 and 0. 6 were tested, and k = 0. 2 was found to be optimal. Equation (  9 ) was iteratively applied. Thus, we had to determine when to stop the training for best parametrization and to avoid overfitting. To this end, we performed a 4-fold cross-validation on the enzyme/inhibitor training dataset, which gives us meaningful numbers for training and validation. This enzyme/inhibitor set contains 39 targets, of which 29 complexes were used for training, with the remaining 10 used for cross-validation. For these 10 targets, we measured the quality with 10 i=1 ln(rank(target i )), where rank() returns the rank of the best ranked hit. This function should decrease during training, while an increase is indicative of overfitting. We observe that overfitting becomes an issue after 30 iterations of Eq.
Test on a new dataset To test the optimized rescoring function, we use the protein-protein complexes from the Dockground test set  [24] , removing all complexes which are also in the ZDOCK Benchmark 4. 0 and were already used for training. The remaining 74 complexes are listed in Table  2. As before, we perform unbound docking with ZDOCK producing 2000 predictions for each target. However, ZDOCK is not able to produce a hit for all targets in the top 2000 predictions. In particular, ZDOCK is not very successful for other complexes, generating hits for only 19 out of 40 of these complexes. However, it is successful for 15 out of 18 enzyme/inhibitor complexes and 12 out of 16 antigen/antibody complexes. For complexes for which ZDOCK produced one or more hits, the 2000 predictions are rescored using E 86 and E trained 86.
Furthermore, the average rank with E 86 is for antigen/antibody complexes considerably higher than that obtained with ZDOCK. To improve these results, we developed a training scheme for the OPEPbased rescoring function based on false positive and false negative predictions. The resulting trained rescoring function callesd E trained 86 , which was applied to the targets from the test dataset taken from the Dockground benchmark  [24] , produces a lower best rank compared to the ZDOCK results for 54 % of the targets, while the untrained OPEP-based scoring function can only improve the rank of 48 % of targets. The trained scoring function performs particularly well for enzyme/inhibitor complexes, where the best rank of 73 % of targets can be improved. These figures are 47 % for other complexes, and 42 % for antigen/antibody complexes.
HRR and CaMa-FLOOD offer a greater degree of openness than LISFLOOD-FP because their respective source codes can be obtained, although this also requires contacting the developers. The code for RTM can be downloaded upon open registration, and that of Lohmann is openly available. Perhaps because their source codes are readily accessible, these two latter river models appear to be the only ones that are currently used by large modeling centers: RTM is an integral part of the Community Land Model  [Oleson et al. , 2013] , and the code of  Lohmann et al. [1996]  is used along with the North American Land Data Assimilation System  [Lohmann et al. , 2004; Xia et al. , 2012]. The generally limited tradition of sharing within the continental to global scale river modeling community makes this field of Earth system modeling a suitable candidate-out of potentially many-for a case study on sharing source code and data, which is the purpose of this paper.
We here reflect on the benefits and challenges that have been associated with the open source development of an alternative river model (Routing Application for Parallel Computation of Discharge (RAPID)  [David et al. , 2011d] ) based on 10 years of experience since its inception. This paper starts with a short background on RAPID (section 2). We then highlight three consecutive but distinct phases of the sharing process: opening (section 3), exposing (section 4), and consolidating (section 5). The implications for Earth science are then presented (section 6), followed by our conclusions. This paper is intended as a reflective perspective in line with this special issue on Geoscience Papers of the Future. Our reflection based on the decade-long history of RAPID includes answers to questions that are relevant to sharing any other type of Earth science model: How to share a geoscience model? What are the minimum sharing steps? How to share data? How to make both model and data citable? How to programmatically reproduce an entire study? How to test a model and how to do so automatically? What are the limits of sharing? Such questions shall be answered if, as a whole, the geoscience community yearns to abide AGU's motto of "unselfish cooperation in research.
Each river reach j of a river network can be prescribed its own set of parameters (k j , x j ). RAPID includes an automated parameter estimation procedure based on an inverse method that searches for an optimal set of model parameters by comparing multiple model simulations with available observations located across the river basins of interest while varying the Muskingum parameters. Different types of river networks can be used including those based on traditional gridded representations  [David et al. , 2011a]  and those from vector-based hydrographic data sets (the "blue lines" on maps)  [David et al. , 2011d [David et al. , , 2013a [David et al. , , 2013b [David et al. , , 2015]]. River routing and parameter estimation can both be performed on a subset of a large domain in order to study local processes.
RAPID has been applied to areas ranging from 10 3 km 2 to 10 6 km 2 (Figure  1 ) and can be run on personal computers as well as on larger parallel computing machines with demonstrated fixed-size parallel speedup  [David et al. , 2011d [David et al. , , 2013a [David et al. , , 2015]]. The idea of building a river routing model capable of simulating river discharge in large vector-based hydrographic data sets was first discussed with the author in January 2006 (Figure  2 ; this idea was discussed in a meeting between Cédric H. David and David R. Maidment held on Thursday, 26 January 2006 at the Center for Research in Water Resources of the University of Texas at Austin). The first lines of the RAPID source code were written in September 2007 after a year of initial research. The development of RAPID has been ongoing since then, with a source code now containing over 5000 lines.
The code is written using the FORTRAN programming language and three scientific libraries: the Network Common Data Form (netCDF)  [Rew and Davis, 1990]  for the largest input and output files, the Portable, Extensible Toolkit for Scientific Computation (PETSc)  [Balay et al. , 1997 [Balay et al. , , 2013] ]  for linear algebra, and the Toolkit for Advanced Optimization (TAO)  [Munson et al. , 2012]  for automatic parameter estimation. PETSc and TAO both use a standard for parallel computing called the Message Passing Interface (MPI)  [Dongarra et al. , 1994]. The community of RAPID users has grown steadily since the software inception a decade ago and currently includes researchers in universities, government agencies, and industry. Notable applications of RAPID include studies of river aquifer/interactions  [Saleh et al.
Second, many potential collaborators might want to assess the capabilities of a piece of software and gauge whether or not it could help their needs prior to contacting the authors. The first RAPID website was published in July 2010 to promote community usage and facilitate ongoing collaborations and was at the time hosted by the software author's institution. At that point in the development, RAPID had reached a certain level of maturity, demonstrated by its ability to run on two conceptually different types of river networks: a vector-based hydrographic data set  [David et al. , 2011d ] and a grid-based network  [David et al. , 2011a]. Note, however, that the corresponding manuscripts had yet to be accepted for publication (Figure  2 ). The website creation and online sharing of the open source software therefore occurred approximately 3 years after the first lines of code were written but a year before the first papers were published.
Version Control System and Online Code Repository Between July 2010, when RAPID was first shared online, and March 2014, a total of 32 successive archives to the source code were made available on the website. For each revision, the entire source code was included in an archive file with a name that included the date of creation. A text file briefly describing the changes made to the code was then maintained (but not shared) by the author. The increasing number of versions of the source code associated with the growth of the RAPID users community made it difficult to support Earth and Space Science 10. 1002/2015EA000142 users; particularly when their applications were based on outdated RAPID code. It became clear then that there was a need for a more advanced code management strategy, including mechanisms for fully documenting and exposing code changes, and for enabling automatic updates by users.
Documenting code changes has traditionally been done using a type of computer science tool called Version Control Systems  (VCSs). Notable examples include the Concurrent Versions System (cvs), Subversion (svn), Mercurial (hg), and git (git). VCSs have many capabilities including: tracking, commenting, labeling, saving, comparing, and sometimes merging code changes. These systems can be deployed and used by a single person or by a team of developers to track code changes locally. Alternatively, VCSs are capable of interacting with online servers called code repositories, in which case the source code is hosted in a remote location. Examples of code repositories include SourceForge, CodePlex, Google Code, BitBucket, and GitHub. The increasing notoriety and usage of both git and GitHub motivated their use for RAPID.
These two tools are designed to work hand in hand and together allow tracking and fully exposing code changes online. The somewhat overwhelming tasks of tracking and documenting changes in all 32 previously released versions of the RAPID code using git and publishing the full repository on GitHub were therefore undertaken in March 2014. Despite a steep learning curve associated with understanding the functioning and usage of these tools, the effort turned out to be more natural and less time consuming (approximately 100 h) than initially anticipated. One of the capabilities of git that was valuable for this endeavor is the tagging of the source code at any given stage. Tags can then be used to navigate through various snapshots of the software. In the case of RAPID, tags consisting of the previous release dates were used and hence enabled instant retrieval of any of the past versions.
Version control for all 32 previous releases was completed on 8 April 2014, date that also coincided with the first code update published on GitHub. The same process has continued since April 2014, and the repository now contains 53 tagged versions including five official releases (see below). The full downloadable repository including all previously released versions of RAPID with tracked changes is available at https:// github. com/c-h-david/rapid (Figure  3 ). This GitHub repository allows obtaining all previous versions of the code, navigating among them, and retrieving any available updates; each of these actions using single-line commands. Several unanticipated aspects of version control systems and code repositories have also been beneficial to RAPID. Among them is the ability to create official releases of the source code with tags using classic version numbers.
To leverage this capability, it was decided to associate official release numbers to the snapshots of the code used in peer-reviewed papers written in the development of RAPID [i. e. ,  David et al. , 2011a David et al. , , 2011d David et al. , , 2013a David et al. , , 2013b David et al. , , 2015] ]  with incremental version numbers from v1. 0. 0 to v1. 4. 0. A direct link to the latest official release of RAPID is at: https://github. com/c-h-david/rapid/releases/latest. This study will be a candidate for a new official version number. The GitHub official releases are also convenient because they can be assigned a unique citable Digital Object Identifier (DOI) through a data repository called Zenodo (see section 4. 2) as was done in this study. Each one of the official release numbers hence now has a citable reference (respectively,  David [2010 David [ , 2011a David [ , 2011b David [ , 2013a David [ , 2013b]] ).
Sharing the Data Over the years of development of RAPID, the size of all input and output files used in associated peerreviewed publications has grown. These data sets have been stored on various machines and their cumulative size approaches 200 GB. Such data can fill a large portion of the total storage capacity of current personal computers and therefore represent a potential issue for data storage and data preservation. Additionally, these files provide examples of the inputs necessary to run RAPID (and of the outputs it produces) and can Earth and Space Science 10. 1002/2015EA000142 therefore serve as the basis for training material. Finally, such files can be used to check that potential new modifications to the software have not altered its overall functioning (i. e. , software testing).
There are therefore many aspects for which the sharing of files associated with previously published RAPID studies can be valuable, including data preservation, software training, and software testing. As with software sharing, the choice of authorship, license, and repository are at the base of data sharing. The most widely used data licenses appear to be those of the Creative Commons (CC). CC licenses and their differences share many commonalities with the various software licenses (section 3. 1) and specify details related to attribution, derivatives, distribution, and commercial use. Readers may find the online service for guiding the choice of a Creative Commons license (https://creativecommons. org/choose/) helpful when picking a license for their data. Note that the selection of a data license is a requirement before sharing data on online repositories.
Three repositories currently seem to be the most popular for scientific data sharing: FigShare (http://figshare. com/), Dryad (http://datadryad. org/), and Zenodo (https://zenodo. org/). These repositories vary in their cost and storage capabilities, but all provide a unique Digital Object Identifier (DOI) making the data fully citable in peer-reviewed publications. Data repositories (like software repositories) also allow for the inclusion of a short description of the files. The input and output files associated with RAPID simulations consist in a series of small Comma Separated Variables (csv) files and of larger netCDF files. The csv files contain information including river network connectivity, Muskingum model parameters, existing observations, and subbasin specifications. The netCDF files contain the inflow of water from land and aquifers into river reaches and the outflow of water from the river reaches.
The input and output files corresponding to peer-reviewed publications of RAPID are usually either generated from scratch or prepared based on off-the-shelf data sets or on files prepared by coauthors. Generally, the amount of work involved in the choice of data sources, data preparation, or data transformation is well aligned with the authorship of the associated papers. It was therefore decided that the authorship of the data sets used in the preparation of existing peer-reviewed RAPID publications would mirror the authorship of the corresponding papers. The details associated with each of the few Creative Commons licenses vary from very permissive to very restrictive. Similarly to the choice of software license for RAPID, the selection of data license was made to maximize community usage.
The Creative Commons Attribution (also known as CC BY) license was chosen for RAPID-related data sets as it allows for distribution, modifications, derived works, and commercial use. The CC BY license is the most accommodating of the Creative Commons licenses, and its only requirement is to credit the original author(s) of the work. FigShare, a free data repository, is probably the most popular of the available data sharing services, but its current 250 MB limitation on any file in each data set makes it impossible to share RAPID files (often of larger than 1 GB). Dryad only accepts files corresponding to peer-reviewed publications, which would satisfy our needs, but their service is not free, and data publication charges increase steeply once the size of each data set goes beyond 10 GB (here again common in RAPID data sets).
Zenodo was therefore chosen to host data associated with our peer-reviewed publications as it allows for many large files (each up to 2 GB) and remains free. Zenodo is supported by the European Center for Nuclear Research and appears to be functioning under stable funding. Furthermore, Zenodo guarantees survival of data sets and of their DOI. The files corresponding to the first two peer-reviewed articles using RAPID [i. e. ,  David et al. , 2011a David et al. , , 2011d] ]  were published in two separate Zenodo repositories (respectively,  David et al. [2011b David et al. [ , 2011c]] ) for the purpose of this study. A short note (1-2 pages) included in each data publication summarizes the sources for all raw data used and explains the content of each file as well as how it was prepared. In addition to fulfilling recent requirements for increasing access to funded research [e.
Training Courses To date, three training courses have been organized for RAPID (Figure  2  Additionally, each training course allowed the evaluation of the ease of use of RAPID and of the quality of the tutorials. Note that while the first two training courses were taught by the lead software developer, the instructor of the third training was instead a member of the RAPID users community. The third training course hence marked a transition when RAPID users started teaching themselves, which can be seen as a milestone in user support. The organization of training courses therefore allows for the evaluation of software usability, but can also be seen as an integral part of community growth and engagement.