dataesr/scientific-paragraphs-categorization huggingface dataset:
Accessing code Access to the source code underlying the ISRaD database compilation and calculations allows for users to check for errors and contribute to the functionality of ISRaD. Users with a registered GitHub account are invited to write code that adds to or improves upon the existing database tools. Using standard GitHub tools, users will submit a "pull request", and following code testing and evaluation of utility to the ISRaD community, user-submitted code will be incorporated into the ISRaD-R package. 4. 3 Reporting Issues, making suggestions, and asking questions. One of the most important tools available to ISRaD users is the ability to post questions, report issues, or make suggestions, including requests to incorporate new variables. We use issue tracking tools provided by GitHub to track and categorize user input including: suggestions for improvements; problems or errors with web interface, the R-package, code, or any other aspects of ISRaD; requests for new variables or issues related to existing variables (e.
g. , incorrect acceptable ranges used in QA/QC); or asking questions related to template entry or any other aspect of ISRaD. While the GitHub issue-reporting functionality is the preferred means for reporting questions or issues with the database or process, it does require that users register a GitHub account. Users who do not wish to or are not able to register with GitHub, can also submit issues or questions via an email to the ISRaD editor (info. israd@gmail. com), however, the response time may be slower.
Database Versioning and Archiving Updated versions of the database will be periodically released following substantial changes or ingestion of new datasets. Versioning of these official releases are tracked an associated version number, e. g. , ISRaD v1. 0, and so on. These official releases will be annually archived at the USGS Science Base repository and at Zenodo (https://zenodo. org/), with a dataset DOI issued for each release. These archived releases will be maintained into perpetuity to facilitate reproduction of any analyses conducted using a past version of the database. Additionally, each release of a new ISRaD version will correspond with the splitting of a stable branch of the GitHub repository, where the particular versions of the ISRaD-R package and the underlying code will be maintained in a stable state so that users may revert back to the earlier version if so required.
Data Sharing Between Soil Databases ISRaD is not the only soils database available to the international research community. The primary niche of ISRaD is the ability to synthesize soil radiocarbon data and provide a framework for comparing soil carbon fraction data. For other purposes, there may be other soil databases that are more applicable. However, as a benefit of adding data to ISRaD, we facilitate sharing of data ingested into ISRaD with other databases developed by the soil science community. At present, ISRaD has a reciprocal agreement with the International Soil Carbon Network (ISCN), which is focused on soil carbon content and related variables from bulk soils (i. e. , no isotope or soil fraction information). As per this agreement, the ISCN retrieves bulk soil data from ISRaD, and is responsible for filtering duplicate entries and incorporating any new data into the ISCN database.
Database Governance ISRaD is a community effort with multiple contributors operating at different levels. Governance of ISRaD is required in order to ensure continuity of services and to plan for the future evolution of this data repository. The governance structure of the ISRaD is pyramid shaped (Fig. 5 ). The ISRaD scientific steering committee (SSC) consists of a rotating group of 7 scientists and data managers. The committee members are nominated and voted into service by a majority vote of the existing steering committee. The role of the steering committee is to determine the feasibility of major changes to ISRaD proposed by the community; to oversee data management, archiving, and establishment of cooperative agreements; and to coordinate activities and funding of affiliated institutions.
Database maintainers oversee the development and maintenance of the technical resources underlying ISRaD. For example, these individuals are responsible for overseeing GitHub pull requests and managing major changes in the ISRaD data template and/or data structure. The ISRaD associate editor is a special case of maintainer, whose role also includes assigning submitted templates to expert reviewers (described below) and periodically rebuilding the database with new entries that have passed the expert review process. Data contributors are users who contribute data to ISRaD. Anyone can be a data contributor provided they agree to the terms of use and follow the proper steps for contributing data to ISRaD. Within the pool of data contributors, individuals with significant experience working within the ISRaD structure may be designated, either by the steering committee or database maintainers, as expert reviewers.
Conclusions and Outlook ISRaD is an interactive open source data repository specializing in radiocarbon data associated with measurements of soils spanning a broad range of spatial scales. The ISRaD dataset is unique in that it includes not only measurements of bulk soils but also measurements of soil water, gases, and the wide diversity of soil pools isolated through different fractionation methodologies. Most of the studies summarized in ISRaD were conducted with a goal of understanding the factors controlling timescales of carbon cycling in specific sites, regions or biomes. ISRaD is an attempt to gather the data from these individual studies in one place and in the same format to facilitate comparisons and synthesis activities. There are three ways through which potential users can access ISRaD: (1) the web-interface enables users to download of the most recently compiled report formatted as a.
csv file, (2) the ISRaD-R package provides access to the compiled reports as well as visualization tools and R-based querying tools, or (3) the GitHub repository provides direct access to the source code for the ISRaD-R package, as well as data from individual entries and the compiled database. Currently, the ISRaD dataset contains ~8500 radiocarbon analyses, which, at a typical cost ~$500 each, represent over US $4,250,000 dollars of research investment. By providing a useful platform for existing data, we hope to encourage the community to increase the effectiveness of that investment, and to use the ISRaD platform as a repository to increase the impact of new results. Many opportunities exist for applying ISRaD data for improving our understanding of controls on soil carbon dynamics, for comparing different methodologies of characterizing soils, or for constraining soil processes in models ranging from profile to global scales.
is archived and freely available at https://doi. org/10. 5281/zenodo. 2613911 Anyone may share or adapt the ISRaD dataset provided they do so in accordance with the Creative Commons Attribution 4. 0 International Public License (https://creativecommons. org/licenses/by/4. 0/legalcode), also referred to as CC-By. In addition, we strongly encourage ISRaD users to follow two simple guidelines for use: Earth Syst. Sci. Data Discuss. , https://doi. org/10. 5194/essd-2019for journal Earth Syst. Sci. Data Discussion started: 9 May 2019 c Author(s) 2019. CC BY 4. 0 License. (1) When utilizing the resources provided by ISRaD, including the complete dataset, individually curated entries, or value-added calculations included in the R-package, users should cite this publication and reference the version of ISRaD that was used for their work (see section 3.
coordinates are often not reported in publications. delta_delta Delta-delta (DD ) is the offset This function calculates the DD values for all between the D 14 C ratio of the radiocarbon measurements in the database, using the atmosphere and that of a sample profile coordinates and the year of observation to during the year of collection and is a extract an atmospheric radiocarbon value for the region useful way to compare radiocarbon of sample collection. The output is appended as a new data across a range of collection variable, e. g. lyr_dd14c. years. fill_FM In some studies, only D 14 C values are If no FM values reported, they are calculated from reported. D 14 C values. CStocks Measurements of carbon If not measured directly, organic carbon concentration concentration are not, on their own, is filled with total carbon concentration (carbonates are good estimates of the mass of carbon accounted for only if reported).
Then, with user- in soils. supplied bulk density, these values are used to calculate the mass of carbon in each soil layer (i. e. , C stocks). fill_expert In some cases, data measured at one Original reported data can be merged with expert extent may be reasonably substituted suggested data to provide unreported bulk layer values. at another extent for the purposes of These estimates are not from original studies, and may conducting comparisons across be approximations, but they are useful for large-scale incomplete datasets global analyses.
'Non-Ideal' Calculations pH calculations were performed as shown in  Rosén and Jeppsson (2006)  and  Volcke et al. (2005). In order to implement 'non-ideal' conditions, the K a,i of all the ionic species in ADM1 (i. e. S in , S ic , S ac ) were modified at each time-step, as shown in section 2. 1. For 'non-ideal' simulations, S cat and S an were entirely associated to Na + and Cl -, respectively. Importantly, apparent concentrations (i. e. kmol/m 3 Solvent) were used in the pH calculations -as well as in all the bio-physical-chemical dynamics -of the HS-AD model, in contrast to the CSTR implementation of ADM1 that used global concentrations (i. e. kmol/m 3 Total). In some HS-AD model simulations, the Phreeqc engine  (Charlton & Parkhurst, 2011; Parkhurst & Appelo, 1999)  was used for pH, I and γ i calculations, as an alternative to the proposed 'non-ideal' module [Figure  1 ].
In these cases, precipitation was not used, though ion pairing is one of the main features of Phreeqc. It must be mentioned that the proposed module for assessing 'non-ideality' in HS-AD simulations [Figure  1 ] is a simplification of more complex physical-chemical engines (i. e. Visual MINTEQ and Phreeqc). Nonetheless, the proposed 'non-ideal' module -instead of Phreeqc -served to compare 'ideal' and 'non-ideal' HS-AD simulations, using the same pH calculation routine in both cases, by only modifying the equilibrium constants (K a,i ) at each simulation time-step in the 'non-ideal' implementation. To illustrate the existing link between 'non-ideality' and the main NH 3 inhibition parameters in structured HS-AD models, the NH 3 half-inhibition constant for acetoclastic methanogens (K i,Snh3,Xac ) was slightly modified in some cases.
Experimental Data and Model Calibration A HS-AD batch experiment fed with OFMSW and using an inoculum-to-substrate ratio For calibration, the 'non-ideal' CSTR implementation of ADM1 (ADM1 Non-Ideal) and the HS-AD model (HS-AD Model Non-Ideal) were compared, using the biochemical rates reported in Table  1. Noteworthy, these rates were slightly different than those used in the original ADM1 implementation  (Batstone et al. , 2002) = ,Q ,Q + ,RSS (17) It must be stated that both the initial conditions and/or the biochemical model parameterization are tightly related to the model structure  (Dochain & Vanrolleghem, 2001; Donoso-Bravo et al. , 2011; Poggio et al. , 2016). Thus, in order to minimize the differences between the CSTR implementation of ADM1 and the HS-AD model, the same set of initial conditions [Supplementary Information] and thermophilic (55ºC) parameters [Table  2 ] were used in both cases.
, 2006). To validate the 'non-ideal' module proposed in this study [Figure  1 ], 'non-ideal' simulations of the HS-AD model were also performed coupling the Phreeqc engine  (Charlton & Parkhurst, 2011). In spite of the higher complexity of Phreeqc, both 'nonideal' modules yielded practically the same HS-AD dynamics (i. e. S ac , S in , X ac ) using 30 % influent TS [Figure  3 ], being the 2 -6 % higher I the most noticeable difference when Phreeqc was used as 'non-ideal' module [Figure  3f ]. The Phreeqc engine coupling to the HS-AD model also yielded closely-matching results to the proposed 'non-ideal' module under all the HS-AD simulations presented in section 3. 1. 2 -data not shown. Importantly, due to the reduced complexity of the proposed 'non-ideal' module [Figure  1 ] and/or the coupling of an 'external' software, the simulation speed increased considerably (i.
HS-AD Calibration under 'Non-Ideal' Conditions The calibration in this study was not aimed to be exhaustive due to the great number of parameters (i. e. > 15) and initial conditions (i. e. > 10) involved in an ADM1-based model, as well as the reduced number of experimental data available  (Dochain & Vanrolleghem, 2001; Donoso-Bravo et al. , 2011; Poggio et al. , 2016). Instead, the calibration aimed to assess the operative levels of I in HS-AD of OFMSW. Moreover, real data calibration could also serve to evaluate the influence of the model complexity (i. e. mass balances) regarding the need for 'non-ideal' calculations in HS-AD. For the calibration of ADM1 Non-Ideal and HS-AD Model Non-Ideal, the same initial conditions and biochemical parameters [Table  2 ] were used, yielding a similar degree of adjustment regarding the experimental data (i.
Batstone et al. (2002) 2018)uation17] was also used for propionate and valerate uptakes in model calibration [Table1], to account for the potential methanogenic and/or acetogenic NH 3 inhibition observed in the experimental dataset(Pastor-Poquet et al. , 2018). The initial conditions were recalculated based on the experimental data available. The biochemical parameters for thermophilic (55ºC) conditions were extracted fromBatstone et al. (2002). Meanwhile, some parameters were also modified aiming to fit adequately the experimental data [Table2]. Parameter.
Batstone et al. (2002) 2018)uation17] was also used for propionate and valerate uptakes in model calibration [Table1], to account for the potential methanogenic and/or acetogenic NH 3 inhibition observed in the experimental dataset(Pastor-Poquet et al. , 2018). The initial conditions were recalculated based on the experimental data available. The biochemical parameters for thermophilic (55ºC) conditions were extracted fromBatstone et al. (2002). Meanwhile, some parameters were also modified aiming to fit adequately the experimental data [Table2]. Parameter (Pastor-Poquet et al. , 2018) valerate degraders (X c5 ) was included, while the composite (X c ) disintegration was disregarded, as shown byPastor-Poquet et al. (2018). As an example, a reversible (non-competitive) calibration and all the initial biomass concentrations (e.
Also known as "Stepwise Uncertainty Reduction," this algorithm is embedded in the "Funz" engine (https://github. com/Funz) tasked with bridging the numerical model and any design of experiments algorithm. We applied this algorithm to a real two-dimensional numerical model of the Garonne river (France), constructed using the open-source TELEMAC-2D model. We focused our attention mainly on the maximum water depth in a given area (the "safety criterion") when considering the influence of a simplified flood defense during a flooding event. We consider the two safety control parameters describing the slab and dyke elevations of the flood defense system, to design against the full operating range of the river in terms of possible watershed flooding. For this application case, it appears that less than 200 simulations are needed to properly evaluate the restricted zone of the design parameters (the "safety zone") where the safety criterion is always met.
Our choice is mainly motivated by this non-parametric metamodeling because although some properties of the considered response surface may be assumed (like continuity, derivability, etc. ), its precise  shape cannot be assumed a priori. Thus, kriging became a standard metamodeling method in operational research  (Santner et al. , 2003; Kleijnen, 2015)  and has performed robustly in previous water resource applications  (Razavi et al. , 2012; Villa-Vialaneix et al. , 2012; Lowe et al. , 2018). More practically, it is of considerable interest when investigating engineering objectives like max-minima or level sets of such random functions, inheriting convenient properties of Gaussian processes, and the method is fast provided the datasets exceed no more than a few hundred observations. The kriging model (which later provides an estimation of water height in an industrial area) is then defined for x € S (x will then represent study variables like the slab and dyke height or flow hydrograph parameters) as in the following Gaussian process: M(x) = N (m(x), s2(x)) (1) where (for "simple" kriging): • {X, Y} are the coordinates of the "true" numerical simulations, taken as conditioning events of the statistical process: • thus conditional mean is m(x) = C(x)TC(X)-1 Y • thus conditional variance is s2(x) = c(x) -C(x)TC(X)-1C(x) • C is the covariance kernel C(.
SOFTWARE AND NUMERICAL TOOLS This work lies within a trend of applied research aimed at engineering enhancement. In practice, the previous (Algorithm 3) requires a heterogeneous set of hardware and software to be applied. The workbench which drives the simulations according to the algorithm:  (Richet, 2019)  [which may also be used through its Graphical User Interface  (Richet, 2011) ] is intended to fill the gap between: J : x -f RSUR(x = {xc, xu}) = -E n Pn+1(x0 x (1 Pn+1(x'c))dx'c (5) where: -Mn+{x} is the kriging metamodel conditioned by the n points {X, Y} (just like "M"), plus the new point x, -T being the target value of inversion. • the flooding simulations: TELEMAC-2D, running in parallel on some Amazon Web Services "instances" (i. e. , virtual machines); • the robust inversion algorithm: RSUR, from the RobustInv R package  (Chevalier et al.
Robust Inversion Algorithm The Robust Stepwise Uncertainty Reduction (RSUR) algorithm was implemented in a dedicated R package  (Chevalier et al. , 2017). It should be used in the same way as other R packages dedicated to Bayesian optimization or inversion like DiceOptim  (Picheny and Ginsbourger, 2013)  or KrigInv  (Chevalier et al. , 2012). However, for convenient and simple integration (in the Funz workbench), the standardized wrapper of the MASCOT-NUM research group  (Monod et al. , 2019)  was applied to provide a front API2 (http://www. gdr-mascotnum. fr/template. html) with the following R functions (https://github. com/Funz/ algorithm-RSUR): • RSUR(options): basic algorithm constructor, will return RSUR object to hold algorithm state.
Funz Workbench Developed by the IRSN and distributed under the BSD3 license (https://github. com/Funz), Funz is a server client engine designed to support parametric scientific simulations. An overhanging graphical user interface design for practical engineering is also available at http://promethee. irsn. fr. Funz can be easily and quickly linked to any computer simulation code through a set of wrapping expressions (a set of regexp-like lines in the ASCII file). It uses the R programming language that is freely available and widely used by the scientific community working with applied mathematics. In addition to its use by the research community, this language is also used by many regulatory organizations. It is therefore simple to integrate algorithms developed and validated by the scientific community into Funz, which can then be applied to the previously-linked computer codes.
Thus, to perform this study, Funz was used to link Telemac (plugin available at https://gtihub. com/Funz/ plugin-Telemac) and the RSUR algorithm (available at https:// github. com/Funz/algorithm-RSUR). Moreover, in order to perform a given set of computations, Funz can bring together independent servers, clusters (above their own queue manager if available), workstations, virtual servers (see Annex for Amazon Web Services / EC2 example), and even desktop computers running Windows, MacOS, Linux, Solaris, or other operating systems. While more focused on medium-sized performance computing (usually less than 100 concurrent connected instances), the high performance bottleneck is indeed delegated to each connected simulator instance, able to require dozens of CPUs independently (or even launch a Funz master itself).
MATERIAL AND METHODS Software, databases, and webservers used in this study are listed in Supplemental Table  1. A flowchart for the IH approach is presented in Supplemental Figure  1. A conformational ensemble of structures from the post-equilibration simulation trajectory of heterotetramer complex model 1 is submitted to the PDB-dev IH structure database  (14, 15). Detailed methodology can be found in the Supplemental methods.
Generation of the FXIII-A 2 B 2 all-atom model Inter-subunit, XL-MS-directed docking of all FXIII-B monomer conformations on the FXIII-A 2 crystal structure (PDB ID: 1f13) was performed using the HADDOCK expert interface webserver (http://milou. science. uu. nl/services/HADDOCK2. 2/) (21). Since this webserver allows for only bi-molecular docking, whereas the in-silico model involves 3 proteins (FXIII-B monomer and FXIII-A 2 dimer), we treated the dimer as a single molecule by renumbering the residues of each FXIII-A monomer in continuum. We based structural constraints for modeling and docking FXIII-B monomer on FXIII-A 2 on inter-and intra-subunit cross-linked residues (Supplemental Tables  2  and 3 ). Docking constraints (n=64) required that all residues belong to detected cross-linked peptides that can form side chain contacts (Supplemental Table  4 ) to cover the FXIII-A 2 /FXIII-B trimer surface.
Introduction Recent successes like the Microsoft Hypervisor project  [16] , the verified CompCert compiler  [17]  and the seL4 microkernel  [13, 14]  show that the verification of low-level systems code has become feasible. However, a closer look at the underlying verification engines VCC  [8] , or Isabelle/AutoCorres  [10]  show that the road is still bumpy: the empirical cost evaluation of the L4. verified project  [13]  reveals that a very substantial part of the overall effort of about one third of the 28 man years went into the development of libraries and the associated tool-chain. Accordingly, the project authors  [13]  express the hope that these overall investments will not have to be repeated for "similar projects". In fact, none of these verifying compiler tool-chains capture all aspects of "real life" programming languages such as C.
The variety of supported language fragments seem to contradict the assumption that we will all converge to one comprehensive tool-chain soon. There are so many different choices concerning memory models, non-standard control flow, and execution models that a generic framework is desirable: in which verified compilers, deductive verification, static analysis and test techniques (such as  [12] ,  [1] ) can be developed and used inside the Isabelle platform as part of an integrated document. In this paper we present Isabelle/C 1  , a generic framework in spirit similar to Frama-C  [7]. In contrast to the latter, Isabelle/C is deeply integrated into the Isabelle/PIDE document model  [21]. Based on the The plug-in mechanism of Isabelle/C can integrate diverse semantic representations, including those already made available in Isabelle/HOL  [18] : AutoCorres  [10] , IMP2  [15] , Orca  [4] , or Clean (discussed in this paper).