dataesr/scientific-paragraphs-categorization huggingface dataset:
Relevance of the different proxies In order to create a trait-by-trait distance matrix, we first checked the statistical differentiation (p-value < 0. 05) of phenotypic traits between populations: we tested normality of distribution and homogeneity of variances using a Shapiro-Wilk test and a Levene test, respectively (R package "lawstat"  [92] ). When assumptions were not respected, data were log-transformed. To check the influence of the cylindro-conical tank on results, we compared linear (phenotypic traits as fixed factors, no random factor) and linear mixed models (cylindro-conical tanks as random factor and phenotypic traits as fixed factors; R package "lmer"  [93] ) using the corrected Akaike Information Criterion (AICc; R package "qpcR"  [94]. For most traits, there was no significant influence of the cylindro-conical tank on the model.
Therefore, we used one-way analyses of variance (ANOVA F-test), followed by Tukey post hoc tests (R package "stats"), to evaluate differences between populations. When the effect of the cylindro-conical tank was significant, we performed the ANOVA on the linear mixed model and estimated marginal means were calculated (R package "emmeans"  [95]. Regarding aggressive rate and activity, assumptions were not met despite log-transformation. Thus, Kruskal-Wallis H tests and Dunn post hoc test (R package "PMCMR"  [96]  were used. Traits presenting no significant differentiation between populations were excluded from further analyses. A trait-by-trait distance matrix was created using the Euclidean method (R package "vegan", three replicates per population). All distance matrices are available in Figshare (https:// figsh are.
In addition, we investigated correlations between trait-based and proxy-based distance matrices using Mantel tests in R (R package "vegan"; 9,999 permutations). Four Mantel tests were performed for each KTA: (i) ɸ ST genetic distance vs KTA-based distance matrix, (ii) habitat divergence vs KTA-based distance matrix, (iii) geographic distance vs KTA-based distance matrix, and (iv) hydrologic distance vs KTAbased distance matrix.
Prioritisation procedure We here propose a prioritisation procedure based on our dataset. First, all KTA-distance and proxy-distance matrices were standardised between 0 and 1 (all raw proxy and KTA matrices are available at https:// figsh are. com/s/ 1067e 47637 c5572 caaf7). Second, the average distance value among replicates was calculated for each proxy/KTA of each population pair. Third, the sum of the three proxy-distance values was calculated per population pair. Similarly, the sum of all KTA-distance values was also calculated per population pair. Relevant ranking of population pairs according to the sum of KTA or proxy values must take into account that pairs with similar sum values should be regarded as equivalent and no prioritisation among them cannot be proposed (i. e. indifference between pairs).
Therefore, we chose to use a k-means clustering procedure to determine indifference groups of population pairs. It aims at partitioning population pairs into k clusters in which each population belongs to the cluster with the nearest centroid. For each sum variable (i. e. sum of KTA distances and sum of proxy distances), the optimal number of clusters (k) was determined using the Elbow method (R package "factoextra"  [86] ). Then, a k-means clustering was performed for dividing all population pairs into k clusters for each sum variable independently (R package "stats").
Acknowledgements We gratefully acknowledge  Yannick Ledoré  ( URAFPA, France ),  Zoltán Bokor ,  Árpád Ferincz ,  Adam Staszny  ( SZIU, Hungary ),  Fodor Ferenc  ( Balatoni Halgazdálkodási Nonprofit Zrt, Hungary ),  Sami Vesala ,  Katja Kulo , and  Pasi Ala-Opas  ( LUKE, Finland ),  Espinat Laurent , and  Goulon Chloé  ( INRAE, France ) for their help with sampling. Special thanks to  Joëlle Couturier  ( URAFPA, France ). Authors acknowledge  Fabrice Teletchea  ( URAFPA, France ),  Nicolas Poulet (AFB, France) , and  Edwige Quillet  ( INRAE, France ) for their helpful comments and discussions on this experimental design.
Availability of data and materials The datasets supporting the conclusions of this article are available in the Figshare (https:// doi. org/ 10. 6084/ m9. figsh are. 11407 128 / https:// figsh are. com/s/ 1067e 47637 c5572 caaf7) for proxy-based matrices and in Genbank (MN939382 to MN939395) for haplotype sequences.
We present the VECMA toolkit (VECMAtk), a flexible software environment for single and multiscale simulations that introduces directly applicable and reusable procedures for verification, validation (V&V), sensitivity analysis (SA) and uncertainty quantication (UQ). It enables users to verify key aspects of their applications, systematically compare and validate the simulation outputs against observational or benchmark data, and run simulations conveniently on any platform from the desktop to current multi-petascale computers. In this sequel to our paper on VECMAtk which we presented last year [51], we focus on a range of functional and performance improvements that we have introduced, cover newly introduced components, and applications examples from seven different domains such as conflict modelling and environmental sciences.
The examples are Swift/T  [15]  and Parsl  [14] , both of which support execution of data-driven workflows. Another range of relevant related tools include more statistically oriented approaches. For instance, Uncertainpy  [16]  is a UQ and SA library that supports quasi-Monte Carlo (QMC) and polynomial chaos expansions (PCE) methods. PSUADE  [17]  is a toolbox for UQ, SA and model calibration in non-intrusive ways  [18] , while DUE  [19]  assesses uncertain environmental variables, and generates realisations of uncertain data for use in uncertainty propagation analyses. PyMC3  [20]  is a Python package for Bayesian statistical modelling and probabilistic machine learning which focuses on Markov Chain Monte Carlo approaches and variational fitting. Similarly, SimLab 4  offers global UQ-SA based on non-intrusive Monte Carlo methods.
(a) Release schedule and changes compared to the initial release The VECMA toolkit is an open-source and open development project, meaning that the latest source and development notes can be accessed at any time. In terms of releases, we have adopted a schedule with minor and major releases. Minor releases are made publicly every 3 months, are advertised within the project, and have limited amount of additional documentation and examples. The first major release was made in June 2019; the ensuing two releases will be made in June 2020 and June 2021, and will be public and fully advertised. They are accompanied with extensive documentation, tutorials, examples, training events and dedicated uptake activities. In addition to these two release types, we provide informal periodic updates to the master code branches, documentation and the integration of the components.
In this section we summarize each of the components that comprise VECMAtk, while we refer to the VECMAtk website https://www. vecma-toolkit. eu/ for more detailed technical information. (a) EasyVVUQ EasyVVUQ  [24]  [26] is a Python library designed to facilitate implementation of advanced nonintrusive VVUQ techniques, with a particular focus on high performance computing, middleware agnosticism, along with single scale and multiscale modelling. Generally, non-intrusive VVUQ workflows involve sampling the parameter space of the simulation. This usually means running the simulation multiple times. This process is tedious and error prone if done in an ad hoc manner, and further exacerbated if the parameter space is large with a corresponding large number of runs (e. g. of order thousands to millions of runs), or if each simulation is very computationally expensive.
(b) Decoder -responsible for parsing the output files of the simulation and extracting the needed values. (c) Execution action -describes how the simulation is run. (ii) Sampling -this step is very dependent on the VVUQ technique in question. The main task of sampling components is to produce a list of parameter sets for the simulation. (iii) Execution -this is handled entirely externally to EasyVVUQ. (iv) Collation -collects the outputs of the simulations and then stores them in the EasyVVUQ database, to be retrieved later for analysis. (v) Analysis -perform statistical analysis on the collected data. This analysis can then inform further actions such as collecting more samples. EasyVVUQ currently has support for variance-driven sensitivity analysis, stochastic collocation and polynomial chaos expansion methods, as well as more basic statistical analysis methods such as bootstrapping.
(b) FabSim3 FabSim3 7   [25]  is a Python-based toolkit for automating complex computational research activities which has several aims: First it helps to automate and simplify the creation, management, execution and modification of complex application workflows. To do so, FabSim3 supports functionalities such as ensemble runs, remote executions, iterative processing and code couplings. Second, it aims to help researchers become quicker and more systematic in handling complex applications in particular. To support this, FabSim3 is designed to be easy to customize for use on new machines and with new simulation codes, and automatically curates a wide range of environment and state variables to aid the testing and debugging of application runs. As usage examples, researchers may want to run and rerun static configurations, run a range of slightly different workflows, define new types of complex applications altogether or construct a routine to automatically validate their code.
FabSim3 also supports a range of adaptable mechanisms for code coupling, and domainagnostic code patterns that provide building blocks for enabling VVUQ in new applications. We provide an overview of the FabSim3 architecture in Figure  2. In the context of VECMAtk, FabSim3 plays a key role in introducing application-specific information in the Execution Layer, enabling users to combine different UQPs and VVPs, and providing an approach to curate large sets of production runs. Also, FabSim3 can use QCG-Client or QCG-SDK to submit ensemble runs via a "pilot job" mechanism  [51, 60]  (see Subsection ii), which boosts efficiency by starting and managing sub jobs without each of them needing to individually wait for resources to become available.
(iv) QCG-Now Since the traditional command-line interfaces may be perceived by many users to be too complicated, within VECMAtk we decided to provision a easy-to-use graphical tool for users. QCG-Now is graphical desktop program that enables the submission and management of jobs on HPC resources. It also supports automatic notifications, data sending and receiving. Since the first release of QCG-Now last year, several improvements have been made: for instance it is now integrated with the QCG-Monitoring system which allows users to track progress of execution of their tasks directly from its graphical interface. This capability is particularly important for VECMAtk users who want to keep track of the progress of long-lasting executions of EasyVVUQ and QCG-PJ workflows. Another new feature allows users to store frequently used execution schemes as quick templates for easy reuse.
Other integration are indeed possible as well, and the inclusion of a different job management and execution engine may be beneficial for individual applications and/or resources. To name a few examples, RADICAL-Cybertools can offer exceptional performance on machines where it is set up  [11] , Swift/T  [15]  can facilitate complex data flows with minimal serialization while Parsl  [14]  is optimised for the fast and flexible execution of Python programs and Jupyter notebooks. As indicated in Fig. 1  earlier, there are four components that provide a suitable entry point for new users to the toolkit. EasyVVUQ facilitates users that initially focus on incorporating VVUQ in their simulations. FabSim3 is aimed at users that initially focus on enabling complex and curated workflows, which could involve ensemble or dynamic execution.
(e) Urban air pollution Predicting air quality in complex urban areas is a challenging field where researchers need to balance accuracy against a practical turnaround time. There are numerous models for predicting contamination transport and dispersion, ranging from simple Gaussian models (that are fast and cheap but not necessarily accurate) to computational fluid dynamics simulations that are slower, more costly and potentially very accurate. In all cases the most important, and often missing part, is an accurate emission database that contains pollutant emission rates for different types of sources: point (e. g. industrial chimneys), line (e. g. road transportation) and areas (e. g. house heat appliances). The pollutants we consider are N O 2 /N Ox, SO 2 and two types of particulate matter (also known as floating dust): P M 2.
5 for particles 2. 5µm or less in diameter and P M 10 for particles 10µm or less in diameter. We use a mesoscale weather prediction model WRF  [47]  and an all-scale geophysical flow solver EULAG  [48]  in our multiscale simulation  [49]  to address uncertainties coming from incomplete emission database, and to provide a quantitative air quality prediction  [50]. We use VECMAtk to automate sampling, ensemble generation, execution of simulation codes on HPC machines, collating results and post-execution analysis. This automation simplifies the provision of better prediction results, because we analyze many different initial conditions and can automatically provide mean results (or some weighted ones) from all simulations. We are also able to run sensitivity analysis of the input parameters to identify and select the most important ones, thus limiting the number of required ensembles for future runs.
In terms of tools we rely on EasyVVUQ, coupled with QCG-PJ using EQI. Using Python we define the parameter space to be sampled, application to be run in HPC environment, hardware requirements (e. g. number of nodes and cores), and the parameters to be analysed after simulations ended. We then use QCG client and QCG-PJ to submit and control jobs on the HPC resources, EasyVVUQ to generate the samples, EQI for enabling the samples to be executed with QCG-PJ and EasyVVUQ to analyze the results. We summarize our workflow in Figure  8.
Toolkit performance and scalability The VECMA toolkit has been developed for use with large supercomputers, and therefore needs to be both fast and scalable. In this section, we present a range of key performance aspects of the toolkit, and discuss the advantages and limitations of VECMAtk in terms of scalability and exascale readiness. The main performance-critical aspects of the toolkit involve: (d) The efficient movement of data between coupled models. We will now briefly discuss the performance-related characteristics of VECMAtk in relation to these four potential bottlenecks: Sampling parameter values and creating large numbers of simulation inputs. There are multiple ways in which EasyVVUQ helps with the issues involved in sampling many and expensive simulation outputs. First of all, EasyVVUQ uses an SQL backend database that can handle 10000s of samples or more.
It also tracks the status of job execution, allowing users to cope with hardware failures by restarting failed jobs without having to rerun successful ones. Furthermore, EasyVVUQ allows one to sample in stages -appending more samples if results are not yet sufficiently robust, without losing the results already in the database. Lastly, EasyVVUQ can delegate the ensemble job submission to other scalable components, such as Dask or QCG-PJ. These components then execute part or all of the simulations on HPC resources. Submission and execution management of large ensembles of simulation jobs. Many scientific applications need to run large ensemble simulations (1000+ runs) to perform UQ and SA, which cannot be executed as individual jobs on most supercomputers due to scheduler constraints, and require a pilot job mechanism such as QCG-PJ.
2: https://www. vecma. eu/wp-content/uploads/2019/12/VECMA_D5. 2_First-Report-Infrastructure_PSNC_20191208. pdf 18 https://github. com/djgroen/FabCovid19 19 The maximum number of jobs a user can have running and pending at a given time is 5000. If this limit is reached, new submission requests will be denied until existing jobs in this association complete. whether files are staged to and from the remote resource as part of the approach, the need for remote deployment work, and the overall performance. using four or more threads. When using FabSim3 with QCG-PJ, the job submission overhead reduces by a factor 2 for ensembles with 100 jobs to about 0. 35 seconds per job. The overhead further diminishes for larger ensembles, as we measure an overhead of about 0. 275 seconds per job for ensembles with 1000 jobs.
In addition, FabSim3 and QCG-Client automatically perform file staging to and from HPC resources. In terms of performance, we chose to focus less on optimising file transfer rates (although FabSim3 and QCG-Client do support GridFTP), and more on limiting the number of file transfers altogether. The clearest example of this optimisation is the tight integration of EasyVVUQ directly with QCG-PJ. Using EQI, users can use HPC resources to generate, run and analyse their simulation ensembles for VVUQ purposes, and do this iteratively and dynamically within a single Python script. In this way, all the computations are brought to where the data is, and input files only need to be staged in once in advance, even if the workflow contains a large number of (dynamic) iterations. The efficient movement of data between coupled models.
The authors declare that they have no competing interests. Funding. This work was supported by the VECMA project, which has received funding from the European Union Horizon 2020 research and innovation programme under grant agreement No 800925. The development of MUSCLE3 and its respective description was supported by the Netherlands eScience Center and NWO under the e-MUSC project. The development of the migration and coronavirus modelling applications was supported by the EU-funded HiDALGO project (grant agreement No 824115). The calculations were performed in Poznan Supercomputing and Networking Center.
DNA Extraction and Sequencing Genomic DNA was isolated from peripheral blood using the QIAamp DNA blood kit according to the manufacturer's instructions (Qiagen, Hilden, Germany). A total of 10 ng of DNA per sample was used for library preparation, using the DNAprep with enrichment protocol (Illumina; San Diego, CA) and a custom NGS panel including in 19 thyroid-related genes (Supplemental Table  1 ). Sequencing was performed on the Nextseq550 platform (Illumina) using the Mid Output kit v2. 5. For a sequence variant to be considered valuable, a sequencing coverage of 30× reads was used as a minimum requirement in the present study. Sequence data were processed using custom bioinformatic software and compared to NextGENe independent analysis (Softgenetics, State College, PA, USA) to align reads to the HG19 reference genome.
Copy number variants (CNVs) were detected using the COV'COP tool  (11)  and confirmed by MLPA analysis (MRC-Holland, Amsterdam, Netherlands). All reported variants, described using the HGVS nomenclature, were explored using public and license databases, including HGMD professional, gnomAD, and ClinVar, as well as literature searches. Minor allele frequency <5% was considered. The majority of variants were rated according to the American College of Medical Genetics and Genomics (ACMG) guidelines  (12)  and VarSome ACMG implementation (http://varsome. com). For variants with no pathogenic reporting, we classified them based on allele frequency in corresponding ethnic population, cosegregation with thyroid balance within the upper limit (TSH value) for the carrier parent and nonpublished data.
Amino acid predictions were performed using the MutationTaster (http://www. mutationtaster. org), SIFT (http://sift. jvci. org), and PolyPhen-2 (http://genetics. bwh. harvard. edu/pph2) software tools and additional supporting evidence for pathogenicity was stated for variants of uncertain significance (VUS). We considered variants as deleterious when concordant annotations by two of these software tools using different algorithms were present. For intronic variants close to the splicing site, we used the ESEFinder2. 0 software tool. Variants detected by the Illumina platform were confirmed by targeted Sanger sequencing on an ABIXL3500 apparatus using the BigDye Terminator v3. 1 Cycle Sequencing kit (Applied Biosystems; Thermo Fisher Scientific, Inc. ). The data for this study have been deposited in the European Nucleotide Archive (ENA) at EMBL-EBI under accession number PRJEB42793.
Spectrum of Genetic Variants Among the 65 children, 37 (56. 9%) presented a constitutive variant from different ACMG classes: 3 (VUS), 4 (probably pathogenic), and 5 (pathogenic) in one or two genes of the thyroid hormone biosynthesis pathway, according to VarSome results and, for some variants, to our own pathogenicity evidence as referred in Patients and Methods section. Functional studies will ultimately be required to prove the pathogenicity of novel variants. We showed that for the majority of patients (78. 4%; 29/ 37), variants belonging to classes 4 and 5 have been previously reported in databases and/or in the literature. Biallelic variants in TG, TPO, DUOX2, and SLC5A5 genes were found in 27% (10/37) of patients, whereas monoallelic variants in TSHR, TPO, DUOX2, and TG were identified in 51.
General setup These models contribute to an experiment setup designed to assess the impact of historical and future warming under the Paris Agreement  (Frieler et al. , 2017). They are driven by the same climate input datasets under representative concentration pathways (RCPs) and socioeconomic scenarios (SSPs). The time span of the simulations is divided into preindustrial  (1661-1860), historical (1861-2005) , and future (RCP2. 6, RCP6. 0, and  RCP8. 5, 2006 RCP8. 5, -2099 RCP8. 5, (2299)) ). These models simulate the terrestrial water cycle on the global land area (except Antarctica) and quantify water flows, water storage compartments, and human water use under the given climatic and socioeconomic conditions. They do not simulate the ocean component of the global water cycle or water quality.
Therefore, these models distinguish between rainfall and snowfall. Further, they also divide throughfall into liquid and solid phases. Two models compute an interception scheme based on a leaf and stem area index, while seven models use only a leaf area index (Tables  7  and 8 ). A total of 10 models compute this considering vegetation type (a plant functional type system) (Tables  7  and 8 ). MPI-HM uses prescribed data taken from Land Surface Parameter dataset version 2  (Hagemann, 2002). PCR-GLOBWB uses the HYDE3. 2 (Klein Goldewijk, 2017), MIRCA  (Portmann et al. , 2010) , and Glob-Cover datasets  (Bicheron et al. , 2011). Generally, prescribed vegetation ignores the decisive interaction between vegetation and runoff and interactions between the atmosphere and Earth's surface  (Gerten et al.
, 2004; McPherson, 2007; Nicholson, 2000). In the ISIMIP2b, the word "prescribed" has two meanings: (i) data which are simulated by other models and provided by the ISIMIP2b framework as input (for example, https://www. isimip. org/gettingstarted/details/ 38/, last access: 8 June 2021) and (ii) data obtained from satellite observations, other datasets, or maps. Prescribed data highlight some limitations of the models or underline the lack of some processes that were intentionally or unintentionally removed from the model structure, according to the purpose of the model development or other priorities such as time. Throughfall is estimated by 13 models (Table  S5 ) depending on (1) total precipitation and relative canopy water content (JULES-W1); (2) difference between total precipitation and canopy storage deficit (mHM, WaterGAP2, WAYS); (3) ratio between rainfall or snowfall and total precipitation (CLM4.