dataesr/scientific-paragraphs-categorization huggingface dataset:
System settings: Our experiments run on the server with an Intel Core i7 4770 processor (L1 cache size is 32KB, L2 cache size is 256KB and L3 cache size is 8MB), 12GB DDR3 main memory and a 500GB SATA hard drive for Hyrise system model training. For MonetDB and PostgreSQL, we use a DELL E6430 (Intel Core i5 3340 processor (1 CPU -2 Core -4 Threads), 8GB DDR3 main memory, ATA Disk Toshiba 500 GB). We use power meters called Watt UP PRO at a 1Hz frequency placed between the electrical power source and the database server to quantify the system consumption. The environment topology of our experimentation is shown in Figure  13.
Parameters values After having made a series of observations in which the queries chosen for models training are executed one after the others, we use regression and Random Forest in R language to determine parameters values for our models describe in equations 3, 4, 5. The following equations 6, 7, 8 describe our model equations with parameter values for the three systems respectively for MonetDB, PostgreSQL and Hyrise. The Random Forest was trained upon all the statistics collected from the queries. Training parameters were set by changing each parameter one-by-one and by regenerating the regression model. The optimum value of each parameter was selected from the following ranges: mtryfrom 1 to 300; ntree-from 1 to 3. For nodesize value, it is fixed to the default. After analysis of output, the parameters were selected with values : for Hyrise model training(mtry=3 and ntree=260), for PostgreSQL(mtry=2 and ntree=30) and for monetdb(mtry=2 and ntree=40).
Models Validation In this subsection, we present the results of a series of experiments running the standard workload provided by the two benchmarks TPC-H and TPC-DS  19. We used our energy models (Non-Linear Regression or Random Forest) defined in equations 6 ,7 and 8 to execute the 22 queries on a 5GB data size for PostgreSQL and Monetdb. for Hyrise, we run the queries on 2GB and 3GB. We compare the energy estimated (EE) by our cost models with the real energy (ER) consumed by the database server during the processing of the query in parallel mode. To. ER denotes the real values of power measured by the power meter and EE denotes the prediction values of our models using Non Linear Regression (NLR) or Random Forest Regression(RFR).
7% and the maximum error is 5. 3%. The estimation error rates for Hyrise system are presented in tables 7 and 8. The average of the estimation errors is 9. 0% and the maximum error is 22. 14% using the Non Linear Regression technique and for Random Forest Regression, it is 7. 4% and the maximum error is 17,9%. To summarize, we present in Figure  14  the average errors obtained on the three database  Our finding demonstrates the ability of ours models to be exploitable. Almost, in all cases, the estimated energy is very close to the real values obtained by the measuring equipment. These finding allow us to pronounce on the quality and accuracy of our models on the TPC-H benchmark, however this is not an indication of predictive ability on other benchmark or on the other hardware configuration.
Results Analysis on TPC-DS benchmark To evaluate the quality of the model proposed for the Hyrise system, we used it on another benchmark (new DB diagram) in order to evaluate its portability. For this, we use the benchmark TPC-DS which is more complex than the TPC-H benchmark because of its diverse scheme, its distribution data and its decision support request load. We used a dataset with a size of 3 GB. We selected 11 queries out of the 99 random queries so that the aggregation functions defined within the queries are implemented in the Hyrise system. The results of queries execution are shown in Table  9. Note that the results of this new configuration are also of good quality with the Random Forest learning technique, as we can see in Table  9. The average error is 10% and the maximum error is below 19%.
The model on the other hand with the Non Linear Regression technique was not able to predict the energy values accurately. We found an average error greater than 50%. Energy modelization and optimization in database systems is the basic work to design energyefficient database systems. The methods used in the literature to predict the energy consumption of queries in databases are roughly divided between those, which use linear regression methods, and those, which employ Non Linear Regression. Here we have used Random Forest Regression technique and we found that it has performed better than Non-linear Regression for the data set used.
In order to save energy, they manage the DVFS level based on throughput target and workload characteristics (e. g. , I/O or CPU intensive). In the aims to save power consumption of online transaction processing (OLTP) in a multicore environment, the authors in  [33]  have  proposed an application-aware that dynamically scale the operating frequency of processors based on response time. Application-aware use a trade-off between power consumption and response time accepted as system level agreement. The authors report a reduction of 7. 6% of total power consumption on TPC-C benchmark queries. The authors of  [67] , experimentally studied the impact of reducing the clock frequency of the processor on the energy efficiency of common database algorithms such as scans, aggregations, hash joins. They showed that reducing unused computing power significantly improves the energy efficiency of memorybound database algorithms.
[65]  proposed the Predictive Energy Saving Online Scheduling (PESOS) algorithm in the context of Web search. Using the DVFS technique, PESOS selects the most appropriate CPU frequency to process a query. The goal of PESOS is to reduce the CPU energy consumption of a query-processing node while imposing a required tail latency on the query response times. The paper of  [73]  presents a technique called POLARIS for reducing the power consumption of transactional database systems. POLARIS directly manages processor DVFS within the DBMS and controls database transaction scheduling. Its goal is to minimize power consumption while ensuring the transactions are completed within a specified latency target. The work of  [5]  proposes a control-theoretic approach for DVS in multiprocessor system-on-chip pipelined architectures.
Microarchitectural Power Saving Microarchitectural techniques allowing energy saving in specific components (eg main memory, cache memories, etc. ) are widely known and studied in the literature. the authors in  [53]  used DRAM frequency scaling and power-down modes to improve power consumption without sacrifying performance under both transactional and analytical workloads. They start by identifying the hardware features that help reduce DRAM power consumption, and then they perform an experimental analysis of the impact of those features on power and performance. The work of  [55]  proposes a hybrid memory architecture consisting of both Dynamic Random Access Memory (DRAM) and Non-Volatile Memory (NVM) to reduce database energy consumption, through an application-level data management policy that decides to place data on DRAM or NVM.
In a recent work, the authors of  [72]  proposed the Energy-Control Loop (ECL) as a DBMS-integrated approach for adaptive energy-control on in-memory database systems that obeys a query latency limit as a soft constraint and actively optimizes energy efficiency and performance of the DBMS. The ECL relies on adaptive workload-dependent energy profiles that are continuously maintained at runtime. In  [44]  authors present survey on cache power/energyconsumption reduction techniques. They have surveyed various cache tuning techniques based on two categories, offline static cache tuning and online dynamic cache tuning, ranging from hardware support to cache tuning techniques. In  [46]  the effect of power and performance are analyzed by reducing cache capacity. Reducing cache size in some applications give significant energy saving in order of 3.
OS-Based Power Management The power-efficient resource management at the OS level plays an important role in energy efficiency and it completes the effort provided at the hardware level. The authors in  [6]  have developed a real-time power manager in the kernel for the Linux OS called the On-Demand Governor (LGD). The goal of the on-demand governor is to keep the performance loss due to reduced frequency to the minimum. [20]  discusses the behavior of the current task management subsystems (scheduler and load balancer) in the Linux kernel on a multi-core SMP system and also it covers its effectiveness in saving energy consumption under several situations (e. g. idle, moderate load). It then describes several techniques such as timer migration, task wakeup biasing and related heuristics for reducing energy consumption.
Rajkumar et al. [2]  have proposed several algorithms for application of DVFS in real-time systems and have implemented a prototype as a modified Linux kernel Linux/Resource Kernel (Linux/RK). The objective is to minimize the energy consumption, while maintaining the performance isolation between applications. our tested systems. Then we proposed three comprehensive energy cost models, one for each of the tested DBMSs. Later, we validated the models by running a second set of queries, and compared their power cost versus those predicted by the models in each system. Our results show that the predicted power is very close to the real values obtained by the measuring equipment. By comparing the estimation errors obtained using the two training techniques on our models, we find that the Random Forest technique gives better predictions than the Non-Linear regression.
The time-consuming effort required to identify the clinical record and re-assess segregated and unstructured genomephenome data, together with the non-scalability of current solutions to reanalyse exponentially-growing datasets over time, preclude its implementation in research and clinical practice. Indeed, most clinical centres still do not include any re-evaluation approach in their routinely workflow as the benefit of identifying a new diagnosis is hardly unbalanced compared with the cost and efforts required for reanalysis. Therefore, innovative bioinformatics solutions are crucial to overcome some of these issues and facilitate iterative re-evaluation processes  [11]. Solve-RD (http://solve-rd. eu/) aims to reveal the molecular cause underlying undiagnosed RDs  [13]. One of the main goals of the project is to comprehensively reanalyse more than 19,000 phenotypically well characterised exome/ genome negative datasets from unsolved patients with RDs submitted by European Reference Networks (ERNs).
Besides the genomic data, the datasets include the phenotypic and pedigree information according to the RD-REAL (Rare Disease -REAnalysis Logistics) minimum information recommended for reanalysis  [13]. All the existing RD-REAL datasets and the new ones generated by the project are being submitted to the RD-Connect Genome-Phenome Analysis Platform (GPAP, https://platform. rd-connect. eu/) as an entry point to the Solve-RD project. The RD-Connect GPAP is an online platform that facilitates genome-phenome data analysis for RD diagnosis and gene discovery. Since datasets are submitted by many clinical researchers and are generated in different clinical centres and genomic facilities, the data are quite diverse at the source. To harmonise the information across all patients and relatives, the GPAP enables submission of pseudonymised phenotypic and clinical data using ontologies and standards such as the Human Phenotype Ontology (HPO)  [14] , the Orphanet Rare Disease Ontology (ORDO) [1], and the Online Mendelian Inheritance in Man database (OMIM)  [2].
All the genomic data is processed through the same standardised pipeline  [15]  before being annotated and stored in an Elasticsearch database, which provides lowlatency queries to enable fast access and ensure scalability. Herein we describe a novel method that enables an automated, flexible, fast and iterative re-evaluation of thousands of genomic datasets using a programmatic access to the RD-Connect GPAP and we illustrate the utility of this procedure by reanalysing 4411 exome/genome negative index cases from the Solve-RD project. This approach has enabled the diagnosis of the first 120 cases within Solve-RD.
Genomic data processing 4551 exome and 201 genome sequencing data (FastQ or BAM) derived from the 4703 affected individuals included in the Solve-RD freeze 1 dataset, were processed using the RD-Connect GPAP standardised analysis pipeline based upon GATK3. 6 best practices and using the GRCh37 human reference, as described in ref. [15]. The resulting variants, including single nucleotide variants (SNVs), short insertions and deletions (InDels) and mtDNA variants (when captured) were annotated using VEP  [16]. In addition, GnomAD  [17] , and ClinVar  [18]  were annotated with the latest versions available as for January 2020. Each dataset was associated with its corresponding phenotypic data and tagged with the name of the submitting ERN or UDP. Data are available to authorised users for analysis through the RD-Connect GPAP user interface (https://pla tform.
Programmatic access to genome-phenome datasets Annotated genomic data is indexed in a non-relational Elas-ticSearch database engine (https://github. com/elastic/elasticsea rch, GitHub -elastic/elasticsearch) connected to a Hadoop environment (Apache Software Foundation, https://hadoop. apache. org). Phenotypic data is stored in a local phenotypic database. Both genomic and phenotypic data are made computationally accessible through Application Programming Interface (API) endpoints, allowing automated queries through an in-house python package. To ensure secure and GDPR (General Data Protection Regulation) compliant data access for authorised users, the python package integrates a keycloak user authentication and permission management (github. com/ keycloak/keycloak, GitHub -keycloak). The GPAP's API enables programmatic and flexible data analysis by (i) applying any type of filtering parameters according to the GPAP variants annotation (e.
g. population frequencies, protein impact and in silico predictors), (ii) integrating standardised phenotypic information from each index case to create unique on-the-fly gene list for each of the experiments, (iii) filtering by specific gene lists according to the type of disorder (curated by ERNs, remote access to PanelApp from Genomics England or genes from any local or public database of interest), (iv) restraining the query filtering by homozygous regions in consanguineous cases or by specific regions of interest (e. g. regulatory regions) and (v) include segregation analysis based on the suspected inheritance and data from patient relatives introduced in the system.
[19] ), gene constrain scores (pLI and o/e according to gnomAD v. 2. 1. 1), ACMG computationally predicted clinical significance and criterias (using InterVar)  [20]  and when relevant, specific disease pathogenicity databases such as the VKGL database (https://www. vkgl. nl/nl/dia gnostiek/vkgl-datashare-database) and the gene4denovo database  [21]. The overall approach was designed by the Solve-RD SNV-indel working group from the Data Analysis Task Force (DATF) in collaboration with the corresponding disease expert groups  [13]  (Fig. 1 ).
clinicalgenome. org/working-groups/sequence-variant-interpretation/). The final feedback of variant pathogenicity for a specific clinical condition was determined by integrating patient assessment, variant evaluation and segregation, suspected inheritance, and clinical fit. Concerning family data available for segregation analyses, 28% of cases were submitted as trios (80% of them from ITHACA families), 68% were submitted as singletons (62% of them from RND) and 4% were from other family structures (Table  1 ).
Programmatic reanalysis workflow To enable automated and reproducible analysis and reanalysis of the Solve-RD data, we have developed a python package to execute queries through the RD-Connect API in a secure manner (Fig. 1 ). The parameters must be indicated in a configuration file, allowing a flexible (re)analysis environment covering very high to very low filtering stringencies and integrating patient clinical information through the use of computer readable standards (HPOs, ORDO, and OMIM) (Fig. 1 ). Options available for filtering include all annotations and features integrated in the RD-Connect GPAP from standard annotations (e. g. internal and external population allele frequencies) to more advanced features integrating clinical information to create patient specific on-the-fly gene lists (e.
Application of the programmatic workflow for the reanalysis of undiagnosed rare disease patients Bioinformatics reanalysis and the programmatic evaluation workflow were applied to all affected cases in the Solve-RD freeze 1 dataset  [13]. In total, 4411 undiagnosed cases with heterogeneous genetic disorders were included: 1472 index cases referred as Intellectual disability (ERN-ITHACA), 2048 as Rare Neurological Disorder (ERN-RND), 616 as Neuromuscular Disorders (ERN-euroNMD), and 275 as Tumor Risk Syndromes (ERN-GENTURIS). Among the Fig. 1  Programmatic reanalysis data workflow. Unsolved cases (RD-REAL datasets = phenotypic and genomic data) are submitted by Solve-RD members from the 4 core ERNs and the 2 UDPs participating in the project. Genomic data is processed through a standard analysis pipeline  [15]  and integrated with the phenotypic information in the RD-Connect GPAP.
DITF include or are in contact with case submitters to enable a final decision for a new patient diagnosis. Diagnosed cases are automatically updated in the system and the remaining unsolved cases are susceptible to re-enter a new round of analysis. whole dataset, 55. 7% of the cases were males and 44. 3% females. To minimise the interpretation burden for the DITFs, the first round of analysis was designed with very stringent parameters to allow the identification of clear candidates ("low-hanging fruit") with known disease causality (Table  1 , Fig. 1 ). All candidate variants were reported as "pathogenic" or "likely pathogenic" in ClinVar. Pathogenic variants are defined (based on the ACMG) as variants that directly contribute to the development of a disorder in a specific dosage sensitivity.
Discussion Constant improvement of bioinformatics methods and advances in genomic understanding to identify and interpret variants highlight the need to periodically re-evaluate unsolved exome/genome cases as stressed by the ACMG  [12]. However, to date, the benefit of identifying a new diagnosis in clinical environments is hardly unbalanced compared with the efforts required for re-evaluation. In this study, we present a rapid, scalable and cost-effective approach to programmatically (re)analyse thousands of structured genome-phenome RD-REAL datasets from undiagnosed cases collated as part of the Solve-RD project  [13]. We have set up a programmatic system based on a python package to query structured genome-phenome data from the RD-Connect GPAP through its dedicated API. Only sample IDs and filtering parameters need to be defined in the system before attempting a new (re)analysis.
Then, the fully automated approach enables to intelligently and flexibly filter genomic data based on clinical, familial, biological and genomic quality information in a rapid (30 s per experiment on average) and massive way (currently >4400 samples tested). The big-data technologies upon which the RD-Connect GPAP is built enable systems to grow by adding more resources as needed. The described approach will allow for the (re)analysis of all the 19,000 exome/genome datasets that Solve-RD aims to collect and the new data it is producing  [13]. Despite the use of cutting-edge technologies, and that experts are able to re-evaluate hundreds of cases with the key information at sight, clinical interpretation remains a manual process. In order to facilitate and reduce interpretation efforts, the programmatic output is provided in a meaningful way, integrating relevant genomic, biological and clinical information for referring clinicians and clinical scientists to perform this final step.
3% of the prioritised cases. The overall positive results obtained from the prioritised variants of this "low-hanging fruit" reanalysis approach can be attributed to several factors. The original exome/genome data reanalysed in this study were sequenced by different centers at different times. This means that the original analyses (including mapping, variant calling, annotation and filtering) were performed with a variety of different tools and databases, likely using different versions and parameters. In addition, the human genome reference used might have been different even if with small changes (e. g. with or without viral and/or decoy sequences). Therefore, the pipeline used in Solve-RD will be in almost all cases somewhat different than the one used in the original analysis, which might have had an effect in unveiling previously undetected variants (e.
g. ref. [25] ). This result is aligned with previous studies in the RD-Connect GPAP on a cohort of patients with rare neuromuscular disorders reporting the importance of deep and accurate phenotyping for variant prioritisation  [26]. For cases remaining undiagnosed, it might be useful to keep updating the patient phenotypic descriptions with new observations, as this might help identify additional candidate pathogenic variants for the disease and increase specificity of the filtering step, thus lowering the time necessary for variant re-evaluation. In this sense, the RD-Connect GPAP facilitates updating the patient records through its phenotypic module. Remarkably, the interpretation of several causative variants identified in complex genes or regions was possible thanks to the multidisciplinary team of RD experts involved (e.
g. ref. [24] ). This first "low-hanging fruit" automated approach managed to solve 2. 7% of all clinically heterogeneous undiagnosed and previously negative-exome/genome cases in <37 h of computational time. The flexibility of the system described herein is now being applied to additional strategic reanalyses, varying parameters stringencies and contributing to increase the diagnostic yield. New approaches will focus on the identification of mtDNA variants using specific variant callers  [27]  or the inclusion of additional clinical resources such as HGMD  [8]  or Varsome  [28]. Indeed, the GPAP already provides direct links to those clinical databases to facilitate variant interpretation and another reevaluation approach relying on the HGMD database is planned for filtering by (likely) pathogenic variants based on the data available by the user's license.
This method could be adapted to any diagnostic (re) analysis workflow and extended to the whole RD-Connect dataset (currently >13,000 samples) or any subset of interest. Data can be periodically re-evaluated with no additional cost and according to any predefined period of time (e. g. every 6 months or once a year) or after relevant method improvements or database updates. This strategy reduces reanalysis costs and experts' time-consuming efforts while offering a solution to three out of the four key elements to reinterpret genetic data recently raised by ref. [30] : data storage and re-access, initiation of routine reinterpretation and reinterpretation with novel information. In summary, we have developed a scalable, costeffective programmatic approach to drastically decrease turnaround time and effort for periodic data reanalysis.
Acknowledgements The authors would like to thank the  Solve-RD SNV-indel working group  for its support on setting up the analysis and Solve-RD-DITF-GENTURIS, Solve-RD-DITF-ITHACA, Solve-RD-DITF-RND, Solve-RD-DITF-euroNMD,  UDP-Spain and UDP-Italy  for providing feedback on data interpretation.