dataesr/scientific-paragraphs-categorization huggingface dataset:
| Third stage At the end of the second stage, most of the DSS components should be fully developed while the DSS functions are able to satisfy the major requirements demanded by the users. Nevertheless, the DSS still needs to be continuously updated with new feedback. Considering the DSS sustainability, the optimization of data management and the improvement of links between DSS and other systems (e. g. , real-time monitoring system) will be defined as the emphasis of this stage. On one hand, massive information and data collected and produced by the DSS need to be well-managed. Having an independent database for the DSS could be one of the operational solutions. On another hand, both the connections between all DSS components and the links between DSS and other systems should be built and enhanced to ensure efficient data transmission under the entire system framework.
| Architecture design of the DSS A new architecture design of real-time online DSS with high levels of functionality and sustainability is designed including four main components, respectively, presented as follows (Figure  2 ). The link between the real-time monitoring system and the DSS data management (Database) is the cornerstone of the proposed DSS. The database is devised to play as the main information recipient and manager in the DSS in charge of processing, analyzing, and saving all data and materials. Compared to the data collected from other sources (e. g. , reports, articles, and photos, etc. ), the records and forecasts from the real-time monitoring system are the core inputs to launch and run the DSS and need to be well organized. One example of data storage is to implement classification storage based on the data types (e.
g. , time series, vectors, grids, etc. ). The DSS is designed to consist of three main components: A multimodular modeling system, a functional database, and a multilayer online platform. Obviously, each component plays a different role in the DSS. To ensure the efficiency of DSS functions, the data handled by the models integrated into the multimodular system are defined within different formats depending on the model preference. A functional database is inserted at the center of the DSS as the "information transfer station" responsible for converting the external inputs (e. g. , from the user interface) into the module-accepted formats. Different from the independent database, the functional database is designed as a temporary data manager. All user-requested information and the most recent real-time modeling results are temporarily saved in such database waiting for further transmissions (e.
g. , to show on the user interface or to store in the independent database). Following the DSS development and implementation strategy, the design of the modeling system is emphasized to follow the multimodular structure (see Section 4. 2. 2). Depending on the simulation objectives, all the models applied in the DSS need to be packaged into several modules controlled by a unified engine (described in Section 5. 1). A multilayer user interface is proposed in this DSS design. According to the users' requirements, the information collected and produced by the DSS will be generalized and reclassified through the functional database and further displayed on the relevant layers. The DSS is designed to give different access permissions to the users to visit their interesting information. On top of the designed architecture are the predefined DSS user groups which are classified based on the users' requirements and their knowledge backgrounds: (i) Expert users: The expert users are mostly from the scientific field, and are fully involved in the DSS development process; (ii) Professional users: The professional users are from the management field, and who are the main end-users; and (iii) Public users: The public users could be any general public, and who lack relevant professional knowledge but have interests on the topics of IWRM.
| Roles of different modules For the Var catchment, a single deterministic model cannot fully satisfy the overall requirements of the decision-makers. Therefore, it is necessary to set up a multimodular modeling system consisting of several deterministic distributed models to catch all relevant information about the catchment hydrological characteristics and provide accurate diagnostics requested by the DSS users. To optimize the workflow and data transmission, the roles of the different modules need to be clarified. The modeling system of AquaVar DSS was constructed with five modules consisting of three deterministic distributed models (hydrology, surface hydraulic, and groundwater) (Figure  5 ). The hydrological module was designed as the first module to run in the system simulation. It contained many modeling functions related to data management and hydrological simulations.
The core function in this module was the deterministic distributed hydrological model simulation: MIKE SHE (DHI, 2017a) over the whole Var catchment. Considering the catchment flow mechanism (concentration-time less than 1 day), the hydrological simulation was first set up with both daily and hourly time intervals from 2008 to 2014. The data applied for setting up the hydrological model were collected from many sources including Metropole Nice Côte d'Azur, Agence de l'Eau Rhône Mediterranée, and Météo France. Through a series of data treatments and interpolations, the raw data were converted into the model-accepted formats and inputted to the model to run the simulations. The results of this module contained all relevant hydrological elements (e. g. , rainfall, temperature, evapotranspiration, infiltration, surface water level, flow discharges, etc.
) at each computation cell in the model domain (Figure  6 ). Those outputs can be either directly used for supporting a part of the decisionmaking process or further be applied as the input variables for other modules to have more specific simulations in the user-targeted area. In the "Requirements analysis," the actors had predefined the Low Var Valley as one of the sensitive areas in the Var catchment. Consequently, two highresolution deterministic distributed models (MIKE 21FM and FeFlow) had been set up at the Low Var Valley and integrated into three different modules for more accurate simulations. To properly represent the river morphology and the hydraulic structures The high-resolution models of MIKE 21FM and FeFlow had been integrated into the AquaVar modeling system as one of the core functions in both surface hydraulic and groundwater modules.
| AquaVar engine After all the modeling simulations were set up and validated against the observations, the system was continuously developed for being an online service, dealing with either the real-time information collected from the monitoring system or the data uploaded by the end users. One innovative approach of the AquaVar DSS is that the DSS contains a modular engine for automating the management of the modular simulation services by coordinating the data exchange through their interactions (Figure  9 ). The engine consisted of the following modules: • Simulation engines: A simulation engine is a wrapper around specific simulation software. The wrapper makes it easy to add a new simulation engine with no change in the architecture; • Configuration modules: Each simulation engine relies on a corresponding configuration module to automatically set up the simulation parameters.
The configuration module is also able to perform data format conversion when necessary; • Scheduler: The scheduler allows running automatically the simulation engines in the background at regular intervals; • Data acquisition module: this module fetches the input data from a data store which itself collects live data from sensors. It implements a common interface that allows easy connection to new data sources; • Data delivery module: This module pushes the result files from simulation engines into a database. Similar to the previous one, this module implements a common interface that allows delivering the results in different ways (database, plain file system, etc. ); • Orchestrator: The orchestrator manages all the other modules and can be parametrized by the user through a web-based user interface.
| Work process of AquaVar engine The main work process of the AquaVar engine (Figure  10 ) consisted of three modules: (i) Real-time monitoring; (ii) real-time monitoring with simulations; and (iii) exceptional scenario simulation. Those modules were, respectively, F I G U R E 6 Examples of MIKE SHE model simulation outputs in the Var catchment responded to the three phases of users' action in the decision-making process (see Section 2): (i) To know the current situations, (ii) to forecast the next actions, and (iii) to predict the future impacts. The first module was implemented through the integration with real-time monitoring and was mainly used for presenting current situations through web applications. In the second module, three deterministic distributed simulations, respectively, handled by MIKE SHE, MIKE 21FM, and FeFlow were running automatically in real-time to produce accurate descriptions of the current catchment behaviors and shortterm forecasts for the future natural conditions (e.
The three models are performed over the period of 1st to 8th of November 2011 version. The simulation is covering a period of 7 days with 4 days of past and recorded situations and 3 days for the forecasts The tested architecture allows performing the requested simulation in less than 1 h. The obtained results can be converted and displayed within the web mapping services of the AquaVar system. The technical requirements remain affordable and can be easily implemented within an operational environment. • Hydraulic model-MIKE 21 FM model. The hydraulic model built with the MIKE 21 FM code can be used with GPU resources as the code is allowing parallel computing. As for the hydrological model, the simulation time is covering a period of 7 days with 4 days of past and recorded situations 3 days for the forecasts.
The obtained results can be converted and displayed within the web mapping services of the AquaVar system. As for the GPU server, the technical requirements remain affordable and can be easily implemented within an operational environment. • Hydrogeologic model-FEFLOW model. The hydrogeologic model with the FEFLOW code is using CPU resources but as the number of timesteps is limited the idea was to use the same computation server as for the hydraulic model. As for the two previous models, the simulation time is covering a period of 7 days with 4 days of past and recorded situations and 3 days for the forecasts. The results demonstrate also that the solution is highly efficient for the hydrogeologic model that can produce a full simulation in less than 30 min with the server equipped with a single GPU resource.
This result can be explained by the quality of the source code of FEFLOW which has been optimized recently for computing efficiency. The tested architecture for the model with one GPU resource allows performing the requested simulation in less than 30 min. The obtained results can be quickly converted and displayed within the web mapping services of the AquaVar system. As previously, the technical requirements remain affordable and can be easily implemented within an operational environment. In addition, due to the limited computational effort requested, the model can be associated with the hydraulic model on the same GPU computational resource. From both the obtained tests' results and the target performances allowing to produce a full hourly update of the forecasts for the hydrological, hydraulic, and hydrogeologic F I G U R E 11 AquaVar Decision Support System web interface models, an operational architecture for the AquaVar DSS can be established and implemented for real-time operations.
| Implementation of AquaVar web application The AquaVar engine was deployed on the NCA (NICE Côte d'Azur) server and implemented as a RESTful web service able to export the model simulation results on request. This web service can be queried by various clients including our AquaVar Web interface which allows end-users to visualize the simulation results through various plotting widgets. The AquaVar web service was based on the Tomcat web container following the REST technology conventions. It is currently implemented in the Java programming language (Java 1. 8). The RESTful model is widely used by NCA web services for real-time monitoring. The AquaVar Web interface was a web application hosted on a different server than the one for the AquaVar engine. This web application was based on the usual LAMP stack (Linux, Apache, MySQL, PHP) and made heavy use of Ajax technology to query the AquaVar engine for data.
The AquaVar DSS was designed with a specific focus on the Low Var Valley where the need for IWRM is the strongest. The AquaVar DSS engine was based on the use of high spatial resolution and had automatically run properties in real-time to provide a 3D comprehensive view of the physical hydrogeological processes over the whole catchment area, especially at the Low Var Valley. Following the proposed DSS strategy, the AquaVar project is currently in the third stage. The main functions of the DSS have been almost fully developed and realized by the modules integrated into the DSS modeling system. The professional users from Metropole Nice Côte d'Azur and Agence de l'Eau Rhône Mediterranée have expressed a high level of satisfaction and acceptance of those developed DSS functions. Highlighted points and innovative approaches of the DSS implementation in the AquaVar project are (i) setting up a multipartite-cooperation in the project management with clear identification of the users' rights and duties; (ii) using of standard modeling software as noninteractive services; and (iii) integrating with the existed hypervision platform already used for real-time monitoring in the city management.
As a result, an overcoming of the classical (i-iii) weaknesses listed in the first paragraph of this section is achieved. However, some feedback and comments from all three user groups have also pointed out several limitations in the current version of AquaVar DSS: (i) The data management in the AquaVar DSS still needs to be continuously optimized. (ii) The efficiency of running the model simulations and of displaying the model results on the web-GIS interface should be kept improving. As a cold analysis, it is remarkable that these types of points identified by stakeholders as remaining for improvements can be categorized as technical and technological gaps to be addressed. Indeed, thanks to the developed DSS strategy, the implementation of these evolutions/improvements (i) perfectly falls within the design DSS development and implementation strategy in the so-called "Future stage" and (ii) thanks to the progress of the past Stages 1-3, implementation of correction/evolutions in the future stage lead technical/technological upgrade without involving any structural changes in the DSS, avoiding then importance rethinking or reorganization in the DSS.
ACKNOWLEDGMENTS This research is currently developed within the  AquaVar  project with the support of  Metropole Nice Côte d'Azur, Agence de l'Eau Rhône Mediterranée, University of Nice Sophia-Antipolis ,  Conseil Départemental des Alpes-Maritimes  and  Meteo France. The work benefited from the data provided by the  Metropole Nice Côte d'Azur ,  Conseil Départemental des Alpes-Maritimes ,  Meteo France , and  H2EA. Part of this research is funded by the  National Key Research Program  ( 2019YFC1510603 ) and the  "Five talents" Plan of the China Insititute of Water Resource and Hydropower Research  ( WH0145B062022 ).
Thresholds for conditional signals, discovery, and transferability We conducted approximate conditional analyses using genomewide complex trait analysis (version 1. 93. 1) software. For HISLA analyses, we used our stage 1 discovery results with the Hispanic Community Health Study/Study of Latinos (HCHS/SOL) as the LD reference dataset. For the approximate conditional trans-ancestral analyses, we used our trans-ancestral results from HISLA stage 1, AAAGC, or GIANT and a trans-ancestral LD reference dataset of Europeans and African Americans from the Atherosclerosis Risk in Communities (ARIC) cohort, and Hispanic/Latinos from the HCHS/SOL cohort, as a representation of the ancestry distribution of our meta-analysis. In both conditional analyses (HISLA-only and trans-ancestral results), we first identified all independent SNPs using the -cojo-slct command.
We performed expression quantitative trait loci (eQTL) analysis with our top HISLA SNP findings, by modeling SNP dosages (exposure) in a linear regression of gene expression levels (outcomes), for each gene within the 1 Mb interval around each lead SNP. We inverse normalized the gene expression levels and adjusted for age, sex, and three PCs to capture population substructure. Bonferroni correction for each region varied according to the number of SNPs tested. To gain further insight into the possible functional role of the identified variants and to assess their relevance to other phenotypes, we conducted bioinformatic queries of our potentially novel loci and new signals within known loci in multiple publicly available databases, including PhenoScanner,  68  RegulomeDB,  69  Haploreg,  70  UCSC GenomeBrowser,  71  and GTEx.
Trans-ancestral findings to account for population structure in previous GWAS We demonstrated the degree to which the present trans-ancestral meta-analysis could lessen the bias induced by population stratification, using height from HISLA as an example. We first conducted PCA on the four European populations (CEU, GBR, IBS, and TSI) from 1000 Genomes. We excluded the Finnish population because of its known unique demographic history that could drive or dominate the top PCs in a limited sample. 33 We only used biallelic SNPs with minor allele frequency (MAF) > 5% in the four European populations, and then pruned them by both distance and LD using PLINK 1. 9. 73 Specifically, we pruned the dataset such that no two SNPs were closer than 2 kb, and then pruned using a 50 SNP LD window (moving in steps of 5 SNPs), such that no SNPs had r 2 > 0.
If there was significant correlation in either the GIANT dataset or the HISLA stage 1, AAAGC, and GIANT transancestral meta-analysis, we then further evaluated the improvement of bias due to stratification in trans-ancestral meta-analysis by comparing the correlation coefficients in the trans-ancestral meta-analysis with those in GIANT. Restricting to variants shared between GIANT and the trans-ancestral meta-analysis, we computed their difference in correlation coefficients of PC loadings and effect sizes, and estimated p values again based on Jackknife standard errors from 1,000 equal sized blocks.
We replicated this signal in stage 2 with directional consistency and a stage 1 þ 2 meta-analysis that was GWAS significant (Table  1 ). In additional gene expression and bioinformatics analyses (Tables S18-S20), we found that each of the three additional signals in established anthropometric loci is supported by an eQTL in whole blood in Hispanic/Latino populations (Table  S18 ), and an eQTL in other relevant tissues, e. g. , thyroid, esophagus, artery, using publicly available (non-Hispanic/Latino) datasets (Tables  S19  and S20 ). Fine-mapping of Hispanic/Latino anthropometric findings We fine-mapped the PAX3 locus for BMI and the three additional signals in known loci (BMI, ADCY5 and ILRUN; height, B4GALNT3; Table  S9 ). For the three BMI loci, FINEMAP revealed one potential causal set for each locus at PAX3, ADCY5, and ILRUN loci.
In light of the notable ancestral, geographical or environmental diversity of the samples analyzed in our metaanalyses, we observed evidence of allele frequency differences for many of our Hispanic/Latino (Figure  4 ) and trans-ancestry findings (Figure  S53 ). Similar to reports from other diverse genome-wide analyses,  55  this allele frequency heterogeneity may explain heterogeneity in effects seen across consortia in our trans-ancestral HISLA, AAAGC, and GIANT meta-analysis (e. g. , IGF2BP2 I 2 ¼ 78. 7; MYO6 with I 2 ¼ 84. 4, Tables  2  and S16 ). Our use of fixed-effect meta-analyses may have failed to identify loci with effect heterogeneity unrelated to allele frequency or LD differences across populations; future studies should address this limitation by considering trans-ancestral random-effects meta-analysis, local ancestry and haplo-type analyses as these studies explore sources of heterogeneity in large, diverse datasets.
Acknowledgments A. G. L. was supported by  NIH  ( T32 HD091058 ,  P2C HD050924 , and  P30 AG066615 ). A. G. T. was supported by  NIH  ( T32HL007055 ). A. R. L. has been supported by the  Leverhulme Trust  ( F/07 134/DF ), the  Excellence Initiative of Aix-Marseille University -A*MIDEX  (a  French ''Investissements d'Avenir'' programme) , the  National Natural Science Foundation of China  (# 31771393 ), the  Scientific and Technology Committee of Shanghai Municipality  ( 18490750300 ),  Ministry of Science and Technology of China  ( 2020YFE0201600 ),  Shanghai Municipal Science and Technology Major Project  ( 2017SHZDZX01 ), the 111 Project ( B13016 ), and  BBSRC  ( BB/I021213/1 ). L. F. was supported by  NIH  ( R01CA204797 ). L. F. -R. was supported by an  American Heart Association  predoctoral grant ( 13PRE16100015 ).
Study Design The main objectives of the study were to assess the impact of the pandemic on public opinion about 3 aspects: the decision to get vaccinated against COVID-19, doubts about vaccinations in general, and the decision to get vaccinated against other diseases. We performed an observational study in the population in Catalonia aged 18 years or older who had access to the online survey in 2021 and who had the faculty to decide on their or others' vaccination. We obtained the information through an electronic, self-administered questionnaire designed by the project research team. A pilot test was performed before the definitive questionnaire was obtained. Both were registered on a Research Electronic Data Capture (REDCap) web platform on a centralized server where the data remain in the custody of the Institut Català de la Salut.
Ethical Considerations This study was approved by the ethics and clinical Research Committee of the Institut Universitari per a la recerca a l'Atenció Primària de Salut (IDIAP) Jordi Gol i Gurina, with code 20/221-P. The study was conducted in accordance with the principles of the Declaration of Helsinki. The variables collected were treated anonymously and to guarantee the confidentiality of the data, as established in Regulation (EU) 2016/679 of the European Parliament and the Council of April 27 on Data Protection (RGPD) and the organic law 3 /2018, of December 5, protection of personal data and guarantee of digital rights. The database is kept by the principal investigator and the research team in an Excel format, protected by password access. An anonymized database was used for the analysis.
Acknowledgments Data collection would not have been possible without the collaboration of the  MC-MUVA  work group (Multimedia Appendix 1),  la Xarxa de Recerca en Pediatria d'Atenció Primària , and  la Societat Catalana de Pediatria. Our special thanks go to the dedicated investigators and participants. This work was supported by  Diputació de Lleida ,  Societat Catalana de Pediatria , and  Asociación Española de Pediatria de Atención Primaria.
Data and Methods Our local earthquake tomography is based on the inversion of compressional (P) and shear (S) waves travel times produced by local earthquakes and recorded by both permanent and temporary arrays in central Chile. The main contribution comes from 25 broadband stations deployed in our study area between 2013 and 2017, which are part of the Chilean Seismological Center (CSN) permanent network (Figure  3a ). We also use travel-time data obtained during the CHASE temporary experiment: 50 seismometers deployed in the Chilean forearc (Figure  3a ), from November 2005 to March 2006  (Marot et al. , 2013).