dataesr/scientific-paragraphs-categorization huggingface dataset:
Kim et al. proposed PAR, a program repair tool that generates patches following patterns learned from existing patches implemented by developers, and they conducted a user study to investigate if humans accept or not the patches generated by PAR  [17]. The user study involved 72 students and 96 developers who were proposed patches generated by PAR and GenProg  [21]. The results show that humans accepted more patches generated by PAR than GenProg, confirming also in this case that humans tend to trust patches that follow strategies already used by developers in the past more than other types of patches, that follow strategies different from the human reasoning, like genetic programming. Finally, a study conducted by Tan et al. [48]  shows that enforcing a program repair tool such as GenProg  [21]  to use anti-patterns allows to have less deletion of program functionalities.
, 2017; Hop et al. , 2020). Of the 3,643 genes with a nearby variant associated with a remote CpG site, 33% have its expression altered by the same variant in the eQTLGen database  (Võsa et al. , 2018). In total, 200 protein-coding genes have local variants that are associated with 5mC levels at ≥ 10 remote CpG sites (Figure  1H ). Variants that affect the largest number of remote CpG sites are located nearby well-known structural factors and TFs such as SENP7, BCLAF1, CTCF, NFKB1 and NFE2, and, consistently, CpG sites remotely associated with a TF local eQTL are strongly enriched in binding sites of the corresponding TF, or a TF related to it (Tables  1  and S3 ). For example, the rs10417143 variant alters ZNF257 mRNA levels (P adj = 2. 8×10 -70 ;  (Võsa et al. , 2018) ) and 5mC levels at 16 CpG sites, which are enriched in binding sites for the ZNF534 TF (Figure  1I ).
Flow cytometry Protocols, panels, staining antibodies and quality control filters used for flow cytometry analyses are detailed elsewhere  (Patin et al. , 2018). Briefly, immune cell proportions were measured using ten eight-color flow-cytometry panels. The acquisition of cells was performed using two MACSQuant analyzers, which were calibrated using MacsQuant calibration beads  (Miltenyi, Germany). Flow cytometry data were generated using MACSQuantify software version 2. 4. 1229. 1. The mqd files were converted to FCS compatible format and analyzed by FlowJo software version 9. 5. 3. A total of 110 cell proportions were exported from FlowJo. Abnormal lysis or staining were systematically flagged by trained experimenters. We removed outliers by using a scheme detailed previously  (Patin et al.
, 2018). Briefly, we used a distance-based approach that, for each cell-type, removes observations in the right tail if the distance to the closest observation in the direction of the mean is larger than 20% of the range of the observations. Similarly, observations in the left tail were removed if the distance to the closest observation in the direction of the mean is more than 15% than the range the observations. We removed 22 observations in total, including a maximum of 8 observations for a single cell type (i. e. , for the proportion of neutrophils). Finally, missing data were imputed using the random forest-based missForest R package  (Stekhoven and Buhlmann, 2012).
Biological annotations Information about the position, closest gene and CpG density of each CpG site was obtained from the Illumina EPIC array manifest v. 1. 0 B4. We retrieved the chromatin state of regions around each CpG site, using the 15 chromatin states inferred with ChromHMM for CD4 + naive T cells by the ROADMAP Epigenomics consortium  (Roadmap Epigenomics et al. , 2015). We used CD4 + naive T cells as a reference because it is a large, relatively homogeneous subset of cells that are less differentiated than memory cells. We obtained similar results when using other cell subsets as reference (data not shown). The data was downloaded from the consortium webpage (https://egg2. wustl. edu/roadmap/web_portal/chr_state_learning. html). The transcription factor binding site data used was public CHIP-seq data collected and processed for the 2020 release of the ReMap database  (Cheneby et al.
study is sponsored by the Institut Pasteur (Pasteur ID-RCB Number: 2012-A00238-35) and was conducted as a single center study without any investigational product. The Milieu Intérieur clinical study was approved by the Comité de Protection des Personnes -Ouest 6 (Committee for the protection of persons) on June 13, 2012 and by the French Agence Nationale de Sécurité du Médicament (ANSM) on June 22, 2012. The samples and data used in this study were formally established as the Milieu Intérieur biocollection (study# NCT03905993), with approvals by the Comité de Protection des Personnes -Sud Méditerranée and the Commission nationale de l'informatique et des libertés (CNIL) on April 11, 2018.
DATA AND SOFTWARE AVAILABILITYThe Infinium MethylationEPIC raw intensity data have been deposited at the European Genomephenome Archive (EGA, https://www. ebi. ac. uk/ega/) under accession number EGAS0000XXXXXX. Data access applications are reviewed by a data access committee (DAC) and access is granted if the request is consistent with the consent provided by Milieu Intérieur participants. All association statistics obtained in this study (i. e. , local meQTL mapping, the 141 EWAS and interaction models) can be explored and downloaded from the web browser hub05. hosting. pasteur. fr/MIMETH_browser/. All the code supporting the current study has been uploaded to GitHub: https://github. com/JacobBergstedt/mimeth.
ACKNOWLEDGMENTS We thank  Sarah Merrill ,  Nicole Gladish ,  Violaine Saint-André ,  Lucas Husquin  and the  Milieu Intérieur  scientific advisory board for helpful discussions. We acknowledge the help of the  HPC Core Facility of Institut Pasteur  for this work. This work benefited from support of the  French government's program  ' Investissement d'Avenir' , managed by the  Agence Nationale de la Recherche  (reference  10-LABX-69-01 ).
Furthermore, the simultaneous use of these two tools makes it possible to check the consistency between the measurements (waveforms, execution times, etc. ) made with openZmeter and those made internally. Additionally, with the use of the Power Gadget, other collateral measurements to the objective of this work are obtained, such as RDTSC (number of cycles), elapsed time, CPU frequency, CPU utilization (%), and package temperature, which are included because they are related to the energy consumption of the complete equipment and can be analyzed in more detail in future works. These two tools are briefly described below.
OpenZmeter In the literature, there are several articles that have shown comparative studies about different smart energy meters  [40]. In this research, the OpenZmeter (Figure  3 ) was used because it covers the requirements needed for the present work. openZmeter is used to measure global energy consumption in the SUTs, from which the energy efficiency is calculated (Section 3), while the Power Gadget allows to obtain separately the specific energy efficiency of the processors of the analyzed systems (Section 4). Furthermore, the simultaneous use of these two tools makes it possible to check the consistency between the measurements (waveforms, execution times, etc. ) made with openZmeter and those made internally. Additionally, with the use of the Power Gadget, other collateral measurements to the objective of this work are obtained, such as RDTSC (number of cycles), elapsed time, CPU frequency, CPU utilization (%), and package temperature, which are included because they are related to the energy consumption of the complete equipment and can be analyzed in more detail in future works.
• Free and open system: Open-source software and hardware. Data are stored in an SQL-like database (PostgreSQL) located in oZm and can be retrieved through the API at any moment. The computed data include time aggregations for minutes, day, week, month, or year. These data are analyzed with statistical tools  [41]  and the results can be then displayed to the user through a graphical interface specifically designed for oZm. The main view (dashboard) of the oZm user interface (Figure  4 ) includes a summary of the main variables:.
• Plots of RMS voltage, RMS current, frequency, and active power for a 3 s aggregation interval. accessing oZm via WiFi or the cloud via an MQTT-based synchronization service. • Free and open system: Open-source software and hardware. Data are stored in an SQL-like database (PostgreSQL) located in oZm and can be retrieved through the API at any moment. The computed data include time aggregations for minutes, day, week, month, or year. These data are analyzed with statistical tools  [41]  and the results can be then displayed to the user through a graphical interface specifically designed for oZm. The main view (dashboard) of the oZm user interface (Figure  4 ) includes a summary of the main variables: • The active energy consumption (kWh) for a fixed or variable time span (see top of Figure  4 ).
Data can be shown in different time periods using aggregations based on nominal values of 3 s, 1 min, 10 min, or 1 h. • Plots of RMS voltage, RMS current, frequency, and active power for a 3 second aggregation interval. The measurements stored in the database can be analyzed in more detail by obtaining, for instance, average, maximum, and minimum magnitudes of voltage in a time period using different aggregation scales, and the voltage waveform. Table  2  shows an excerpt of a CSV file exported from oZm. The measurements stored in the database can be analyzed in more detail by obtaining, for instance, average, maximum, and minimum magnitudes of voltage in a time period using different aggregation scales, and the voltage waveform. Table  2  shows an excerpt of a CSV file exported from oZm. To a certain extent oZm, with its associated software, could be considered as a digital oscilloscope for waveform diagnosis.
Intel Power Gadget The Intel Power Gadget tool uses the Running Average Power Limit (RAPL) interface, included by Intel in its Sandy Bridge processor architecture. RAPL is a tool that makes it possible to monitor and act on the processor's power consumption and associated circuits. Indeed, RAPL allows the measurement of power consumption with a very fine granularity and a high sampling rate, and also makes it possible to limit the average power consumption of the different components inside the processor, which prevents the processor temperature from reaching an undesirable value  [43]. With RAPL, it is possible to develop applications that capture real-time measurements of the power consumption of the CPU package and its components, as well as that of the DRAM memory managed by the CPU. The RAPL interface provides this information through control register-counters (MSR, model-specific register) accessible from the instruction set included in the architecture specifically for debugging, program execution tracing, computer performance monitoring, and toggling/altering certain CPU features.
• PSys. Domain available on some Intel architectures, to monitor and control the thermal and power specifications of the entire system on the chip (SoC), instead of just CPU or GPU. It includes the power consumption of the package domain, System Agent, PCH, eDRAM, and a few more domains on a single-socket SoC. • PSys. Domain available on some Intel architectures, to monitor and control the th mal and power specifications of the entire system on the chip (SoC), instead of j CPU or GPU. It includes the power consumption of the package domain, Syst Agent, PCH, eDRAM, and a few more domains on a single-socket SoC. Not all architectures generate data from all the domains described above. For mu socket server systems, each socket reports its own RAPL values. The Intel Power Gadget is the other tool, in addition to oZm, used to perform energy measurements in this work and is based on the use of the energy register-count associated with the RAPL interface just described.
This tool is enabled for Intel Core p cessors (from 2nd Generation up to 10th Generation) and is supported on Windows a Mac OS. It contains an application, driver, and libraries to monitor and estimate real-ti processor package power information in watts (W) using the energy domain registers the processor. The Intel Power Gadget was chosen because: (1) It largely meets the needs for performing the measurements shown in Section 4, The in-depth study of the RAPL interface, using different benchmarks, implemen by K. N. Khan and M. Hirki  [45]  concludes that the RAPL readings are highly correla with the socket power, sufficiently accurate and produce negligible performance ov head. Figure  6  shows graphs obtained during the execution of the Intel Power Gad tool. An example of the data generated by Intel Power Gadget (once installed on the v ious test platforms) is shown in Table  3.
The meaning of each of the parameters is p vided in Table  4. Not all architectures generate data from all the domains described above. For multisocket server systems, each socket reports its own RAPL values. The Intel Power Gadget is the other tool, in addition to oZm, used to perform the energy measurements in this work and is based on the use of the energy register-counters associated with the RAPL interface just described. This tool is enabled for Intel Core processors (from 2nd Generation up to 10th Generation) and is supported on Windows and Mac OS. It contains an application, driver, and libraries to monitor and estimate real-time processor package power information in watts (W) using the energy domain registers of the processor. The Intel Power Gadget was chosen because: (1) It largely meets the needs for performing the measurements shown in Section 4, (2) It has been developed by the manufacturer of the processors under study, (3) It is freeware, and (4) It collects data from the RAPL interface.
Methodology To analyze the performance rate when executing scientific problems and the energy efficiency of the computers under test, Linpack Extreme is run on each of the SUTs and, simultaneously, measurements with Intel Power Gadget and oZm are taken and stored. The information obtained is shown in Tables  2  and 3. The results generated in both applications are synchronized in time, and mean values, standard deviations, etc. , are calculated. The time periods in which Linpack is being executed or not are also identified. To better interpret the results, the evolution of power consumption over time of the measurements obtained with Intel Power Gadget and oZm is also plotted. To carry out the tests on each device, 5 runs of the Linpack Xtreme program are performed, which is the maximum value in the parameters established by Intel for each trial (see Table  1 ).
Linpack Extreme, Intel Power Gadget, and oZm data shown in the table correspond to the same five runs. When the Linpack test is performed, it is obviously running in parallel to the OS and other system programs. In an attempt to obtain an estimate of the magnitudes specifically attributable to the execution of Linpack, an evaluation of the baseline (or idle) parameters has been performed. Here, we define the "core phases"  [47]  as the time intervals in which the Linpack program is running, and the "idle or baseline phases", as those corresponding to intervals in which Linpack is not running, but in which the system is ready to start its execution. It should be noted that idle phases are not a state of suspension or hibernation. The power consumed and other parameters in the idle phases have been estimated by averaging the values obtained in the time intervals where the program was not running, either before or after execution of a run of the five trials.
These tests have been executed in multitask OS (Windows), so the CPU have to spend some time in another small processes, internal Kernel activities or attending network packets, so that during the execution of a program the values can spread over a wide range around the mean. In Figures  7 8 9 10 11 , it is possible to observe both the power variations in the successive core phases and in the idle phases (baseline), which determine the value of the standard deviation. Even from Figure  11 , it can be seen how the first run of Linpack contains at the beginning instructions different from the other four, probably to initialize the parameters and data of the program. All these variations are mathematically represented by the standard deviation, being greater as the fluctuations between the energy consumed by the instructions increase.
These tests have been executed in multitask OS (Windows), so the CPU have to spend some time in another small processes, internal Kernel activities or attending network packets, so that during the execution of a program the values can spread over a wide range around the mean. In Figures 7 to 11, it is possible to observe both the power variations in the successive core phases and in the idle phases (baseline), which determine the value of the standard deviation. Even from Figure  11 , it can be seen how the first run of Linpack contains at the beginning instructions different from the other four, probably to initialize the parameters and data of the program. All these variations are mathematically represented by the standard deviation, being greater as the fluctuations between the energy consumed by the instructions increase.
To meet the stated objective, a complete methodology has been presented to determine the energy efficiency of complete computer systems. Specifically, the energy efficiency of a computer system has been determined by executing Linpack, a reference application considered to be among the most used in scientific and engineering systems. This has been done using the (a) external meter oZm and the (b) Intel Power Gadget, an internal power meter that considers the counters and hardware registers included in the processor. The Linpack program has been used as a reference for the measurements. This program is considered a very suitable benchmark to measure the computing power of a device executing instructions with float-point data, which is the most computationally complex type of data, requiring fast processing times and is representative of scientific and engineering applications.
The consumption of this last set of components would be obtained by the difference between the oZm measurements and those provided by Intel Power Gadget, and would include the consumption associated with data transfer via buses external to the processor, I/O ports, peripherals, power supply, etc. On the other hand, although the precision obtained with 5 measurements is a priori sufficient to make the comparative analysis with the GREEN500 systems, a more exhaustive analysis with more than 5 runs should be carried out to obtain a more reliable mean values. The main pitfall here is that a program such as Linpack, running on laptops, entails a very long execution time. It is concluded that the power efficiency of PCs for the same workload is comparable to that of more powerful computers, which means that, in many cases where execution time is not constrained, it may be appropriate to migrate program execution from servers or workstations to personal computers in order to contribute to reducing the overall energy consumption produced by ICTs.
Voltage measurement with a precision of 0. 1% for RMS values. Frequency measurement with a precision of 10 MHz (in the range 42. 5-57. 5 Hz for 50 Hz power systems or 55. 8-64. 2 Hz). Current measurement up to 35 A RMS (integrated Hall-effect sensor). • Sampling frequency of 15,625 Hz (64 microseconds between samples). • Connectivity: USB ports (Wi-Fi dongle, 3G/LTE/4G, etc. ), Ethernet port, and Wi-Fi. SPI, I2C, UART and PWM. Measurements can be visualized, for example, by accessing oZm via WiFi or the cloud via an MQTT-based synchronization service. •Electrical measurements: Root Mean Square (RMS) voltage and current values; active, reactive, and apparent power and energy; power factor, harmonics, and frequency in real time through the API and stored in a database. •.
It 4 There is currently no structure available for the full-length MeCP2 in any of the protein databases. MBD is the only domain for which the secondary structure is known, and it only accounts for ~17% of the amino acids  1  ; MBD is also the only ordered domain. Circular dichroism (CD) of recombinant human MeCP2 has shown that the protein consists of ~35% β-strand/turn, 5% α-helix and almost 60% is unstructured  2. Characterization of MeCP2 by hydrogen/deuterium exchange has indicated disorder in the entire polypeptide chain with the exception of the MBD domain  3. Further CD studies of isolated NTD, ID, TRD and CTD domains confirmed their lack of stable secondary structure  4. It has been experimentally demonstrated that the NTD, CTD and TRD domains can undergo a coil to helix transition, with the TRD showing the greatest tendency for helix formation  4.
Ab initio modelling Modeller 9 version 9. 19 was used to build a model for the full-length MeCP2 protein. Using the BLAST algorithm  10  , we searched the UniProt database  11  for homologues of MeCP2 with a 3D structure. Unfortunately, the only known structures belong to homologues of the MBD domain, which accounts for only ~17% of MeCP2 amino acids and whose structure has already been determined. Thus, we used the Protein Data Bank 1QK9,  1  which contains the MBD domain structure, as a template. Twenty different models were generated with Modeller 9. There was little variation between the different models and thus the first model was chosen as the starting structure for the simulations (Fig. S1 ). With the aim of having a different starting structure for our coarsegrained simulations, a second model was built by refining the loops of the first model using the loopmodel class in Modeller.
There is no structural information on this protein besides its known disorder and the structure of the MBD domain, and thus no quality assessment predictors were used to evaluate the generated models. The evaluation will come from the data obtained during the simulations. The AlphaFold 12 model for human MeCP2 (UniProt code: P51608) was downloaded from the database hosted by the European Bioinformatics Institute (https://alphafold. ebi. ac. uk). Three simulations were performed with this model as the initial structure, using the procedure described in the next section.
Comparing the simulations with AlphaFold prediction Last year, the field of bioinformatics had a major breakthrough when the deep learning model AlphaFold was able to successfully predict the three-dimensional structure of proteins from their sequence  12. Since then, the model has been used to predict 98. 5% of the proteins in the human proteome  51  ; all the structures are available to the community in a database hosted by the European Bioinformatics Institute (https://alphafold. ebi. ac. uk). Nevertheless, predicting the structure of IDPs remains a challenge, as the vast number of low and very low confidence regions from the structures predicted by AlphaFold overlap with regions predicted to be disordered  52. The model we built with Modeller 9 (MeCP2_1) has the N-and C-terminal ends extended into the solvent, and its radius of gyration is large (8.
Results Core genome-based phylogeny of Neisseriaceae suggests that MuLDi evolved from a rod-shaped ancestor The Neisseriales order comprise the Chromobacteriaceae family and the Neisseriaceae family. Recently three new families have been suggested (Aquaspirillaceae; Chitinibacteraceae and Leeiaceae)  (Chen et al. , 2021). The Neisseriaceae family now includes 12 genera (Alysiella; Bergeriella; Conchiformibius; Eikenella; Kingella; Morococcus; Neisseria; Simonsiella; Snodgrassella; Stenoxybacter; Uruburuella; Vitreoscilla). We selected species from each of these Neisseriaceae genera and used SMRT (PacBio) and Minion (Nanopore) technologies to obtain 21 additional closed genomes (Table  S1 ). Genomes obtained in this study were combined with Neisseriaceae draft genomes (n=365) from NCBI database to calculate the Average Nucleotide Identity (ANI) in order to identify the main species corresponding to genomes with ANI>95% (Table  S2 ).