dataesr/scientific-paragraphs-categorization huggingface dataset:
e. speech of one interactant caught by the other interactant's microphone). Finally, the recordings will be carried out in a quiet room to limit environmental noise. This is consistent with previous analyses on acoustic patterns in psychiatry  [79]. The. wav files obtained will be annotated using Praat software and subsequently analyzed with Praat  [80]  and R. Prosodic features will be extracted using the Prosogram tool (a set of Praat scripts, open-source)  [81]  and voice quality features will be computed with a modified version of scripts from the Prosogram tool  [82]. Turn-taking variables will be quantified with combined Praat and R scripts  [62, 66, 83]. This task has been designed and will be supervised by an expert in Phonetics and by a psychiatrist trained in linguistic data extraction and analysis (MGr and VL).
The order of the 90% and 50% blocks is randomized. The tactile and visual stimuli are generated with a MATLAB script. Each block consists of 100 trials, in total 500 trials. EEG data is recorded throughout the task, using a 64-channel EEG cap (from Biosemi). The setup is coupled to an eye tracker in order to control that the participant is fixing the cross at the center of the screen during each block. At the end of the task, a five minute eyes closed resting-state EEG will also be recorded. In order to examine attentional modulation, measurement of alpha power band (in Hz) is computed. Cortical excitability and inhibition are analyzed with mu and theta bands (in Hz), and integration of sensory information as somatosensory evoked potentials (SEPs), where amplitudes (in µV) and latencies (in msec) are extracted.
Finally, participants will undergo two episodic memory tests: a free recall task and a recognition task. The free recall will be based on a verbal interview of 20 min, during which participants will be asked to recall all the events that they remember encountering in the virtual city. The recognition test will be programmed using the Python module Neuropsydia  [89]  and consists of displaying on a computer screen all 32 encountered events mixed with 16 lures which were not encountered in a random order, and asking participants whether they encountered this event in the virtual city. For both memory tests, participants will be asked to provide systematically and the most precisely possible, for each recalled event: description of the event, spatiotemporal situation, source, referent for the personal significance rating, perceptive and phenomenological details, degree of reliving or familiarity of the event.
Microstates analysis Microstate analysis will be performed on eyes-closed resting-state, during the sensorimotor integration task, and during sleep. A minimal preprocessing will be done with the MNE EEG software on Python, which includes a bandpass filter between 0. 5 and 40 Hz, rereferencing to the mean, and visual and automatic correction for artifacts using independent component analysis (ICA). Each recording will be visually reanalyzed by clinical neurophysiologists to check for any residual artifact. Microstate analysis will be done using the Pycrostates package  [91]. Global field power (GFP) will be determined for each participant. Only EEG topographies at GFP peaks will be retained to determine microstates' topographies, through a modified K-means clustering. For each subject the same number of GFP peaks will be extracted and concatenated into a single data set for clustering.
Regarding the linguistic data collection, high-quality double-channel audio recordings are crucial to allow precise and reliable analyses with the Praat software. Regarding the self-reference effect, the innovative task using immersive virtual reality will enable to study this effect in a naturalistic and standardized context, which will capture the richness of episodic memory and its links with the self in everyday life better than the simplistic lists of words or objects that are traditionally used in self-reference effect studies. Moreover, the task will integrate both minimal and narrative self-reference, which will enable to examine under the same design the respective but also joint contributions of both facets of the self to the self-reference effect in patients with self-disorders.
Acknowledgements We thank the team of the  Délégation à la Recherche Clinique et à l'Innovation (DRCI) of GHU Paris Psychiatrie et Neurosciences  for providing administrative and legal support to build this protocol, with special thanks to  Bernadette Lemercier ,  Thujin Yoharajah ,  Khaoussou Sylla ,  Didier André , and  Kahina Belkhir Hadid. We thank the  Centre de Recherche Clinique (CRC) of GHU Paris Psychiatrie et Neurosciences  for providing the material support of subject inclusions. Figures were done with Biorender (https:// www. biore nder. com/).
Funding This study is funded by the  DEMETER Starting Grant ,  GHU Paris Psychiatrie et Neurosciences  (principal investigator:  Anton Iftimovici ). Valeria Lucarini  was supported by the doctoral grant ' Young Talents in Psychiatry 2021 ' from the  Fondation FondaMental-Fondation Bettencourt-Schueller. Anaëlle Alouit was also financed by the  French government 's " Investissements d' Avenir" programme  ( ANR-18-RHUS-0014 PsyCARE ).
III. TRACKING In this section, the consequences of the high frequency increase of the real part of the NEG coated beam pipe resistive-wall impedance are investigated by tracking simulations in the framework of the SOLEIL II project. The SOLEIL II project aims to upgrade the SOLEIL storage ring, the French third-generation light source  [21] , to a fourth-generation light source  [6, 9, 22]. The storage ring lattice parameters used for this study are reported in Table  I. The tracking study is done using MBTRACK2, an opensource collective effect library written in python3  [23, 24]. The tracking part of MBTRACK2 is designed to be able to integrate both single and multi-bunch collective effects. Here the single bunch effects of the NEG-coated beam pipe are introduced by using the WakePotential class.
Whether it is a data scientist trying to understand the energy consumption of her/his GPU while performing AI model training, a data center manager wanting to perceive the consumption of CPU and RAM-intensive cloud workloads, or a user wishing to understand the power consumption of her/his laptop, energy and power measurement needs are numerous. The most mature and less intrusive way to estimate the power consumption of a computing node is through the use of physical power meters. But they require the deployment of an additional measuring infrastructure. In addition, data must be collected and made available using specific software often imposed by the power meter supplier. Finally, a physical power meter only measures the overall consumption of the computing node. It does not detail the consumption of the various components or services launched on this computing node.
a) Intel CPU RAPL: The RAPL (Running Average Power Limit) interface was introduced by Intel in 2011  [4]  in the Intel Sandy Bridge architecture. The first implementation of RAPL used a software power model in order to estimate energy usage based on "a set of architectural events from each Intel architecture core, the processor graphics, and I/O"  [5]. The second implementation of RAPL, introduced with the Haswell architecture, is based on fully integrated voltage regulators and enables actual power measurement, improving the accuracy of RAPL measurements  [6]. RAPL reports energy consumption and is able to limit the power consumption on different levels or power domains: entire CPU socket (PKG), all CPU cores (PP0), integrated graphics (PP1), dynamic random-access memory (DRAM), and entire SoC (PSys).
The RAPL registers are limited to 32 bits and can overflow. This must therefore be taken into account when reading the RAPL values directly. In the Zen architecture (17h family), AMD introduced a version of RAPL  [10]  whose implementation is similar to the first software model-based Intel RAPL and can show inconsistent results  [11]. b) Nvidia GPU NVML: NVIDIA provides users with an API called NVIDIA Management Library (NVML)  [12]. It provides access to GPU device metrics such as current utilization, temperature, and power draw. According to the official documentation, the method nvmlDeviceGetPowerUsage() returns the current power draw within an accuracy of 5% of the GPU and its associated circuitry (e. g. memory). Retrieval of current power draw is supported by Nvidia GPUs of the Fermi generation and newer.
The three software packages we selected are all Python packages based on Intel RAPL and Nvidia NVML interfaces. Carbon Tracker (version 1. 1. 6)  [37]  can be integrated into a machine learning model training to predict the energy consumed by the whole training from the training of one epoch. Code Carbon (version 2. 0. 0)  [38]  automatically retrieves the TDP coefficient from an internal database if Intel RAPL and Power Gadget are not available. Experiment Impact Tracker (version of June 4, 2021)  [39]  distinguishes itself by separating the consumption of the Python script execution process from the rest of the system. 3) Power profiling software: Finally, we study tools returning the power profile of a program and that are based on the Intel RAPL and/or Nvidia NVML interfaces. PowerAPI (version 1.
0. 7)  [40]  is an open-source toolkit for building power meters. Smartwatts (version of Feb 28, 2022) is a software-based power meter implemented with PowerAPI able to estimate consumption at a process level. Smartwatts process-level estimates are based on performance events generated by each monitored process. Perf (version 5. 4. 203) is a command-line utility designed for Linux profiling with performance counters capable of reporting energy consumption gathered from RAPL. Scaphandre (version 0. 4. 1)  [41]  is a monitoring agent able of reporting power consumption at the process level based on usage-based process-level modeling and CPU utilization metrics. Energy Scope (version of January 2022)  [42]  is an energy monitoring and application profiling software package taking into account the power consumption of Nvidia GPUs.
"Good" if the available documentation addresses usage questions such as parameter settings  [29]. Resulting data format In which format the result data are provided. For example, as a value stored in a code variable (Code) or written into a database back-end (Prometheus, InfluxDB, MongoDB, Riemann, Warp10), sent via a socket connection (Socket), a text file (JSON, CSV, Latex), available on a web page (Web) or just printed in the standard output (Stdout). Data visualization possibilities Dashboards (Grafana, Comet, custom) or online web resources.
IV. METHODOLOGY After qualitatively comparing the software-based power meters, we conducted a group of experiments to verify how the selected tools work and evaluate the quality of their outputs. A. Environment 1) Infrastructure: We executed all experiments on a machine from the Gemini cluster of large-scale test beds for experimental research called Grid'5000  [47]. This cluster was selected because it contains nodes with multiple recent GPUs supporting power metric retrieval with Nvidia NVML, two CPUs with the second implementation of Intel RAPL, and high-performance external power meters. The nodes in this cluster have the following specifications: • System model: Nvidia DGX-1 • CPU: 2 x Intel Xeon E5-2698 v4 (Broadwell, 2. 20GHz, 20 cores/CPU) • Memory: 512 GiB • GPU: 8 x Nvidia Tesla V100-SXM2-32GB (32 GiB) a) External power meter: The power consumption of each node in the Gemini cluster is individually monitored by an Omegawatt  [48]  power meter.
B. Selected benchmarks In order to evaluate software-based power meters, we executed benchmarks representative of typical workloads, well known by the community, and implemented for both CPU and GPU. For this purpose, we chose the NAS parallel benchmarks in their classic implementation  [49]  and implemented for GPU in CUDA  [50]. We selected three NAS benchmark kernels in order to simulate an intensive use of different computing node components. The first kernel is the EP (Embarrassingly parallel) kernel that generates pairs of Gaussian random deviates thus making intensive use of the CPU (and respectively GPU). The second kernel is the MG (Multi-Grid) kernel. This kernel performs a V-cycle multigrid algorithm and tests both short and longdistance data communication, thus is memory intensive.
C. Experiment methodology We evaluated the consumption results given by the software power meters listed in Section III while executing the NAS benchmark kernels presented in Section IV-B. We selected a one-minute interval between each benchmark execution to let the computing node component cool down after each benchmark run and prevent the power consumption of subsequent executions from being impacted. 1) Tools configuration: Most of the software-based power meters studied in this work were used with the default configuration. However, some of them have multiple configuration possibilities or the default values are not suitable for our experiments. We used PowerAPI with Hwpc-sensor as a sensor, Smartwatts as a formula, and MongoDB as a database. The Hwpc-sensor and Smartwatts formula was configured with a sampling frequency of 1 Hz.
We also enabled the DRAM formula in Smartwatts and configured the Hwpc-sensor to collect and send DRAM RAPL events to the database. Scaphandre was used with the Prometheus exporter, which exposes power metrics on an HTTP endpoint. The default power data fetch interval of 10 seconds is insufficient in the context of our study, so we configured Prometheus to retrieve power data every five seconds (0. 2 Hz). Perf was used with a sampling frequency of 10 Hz and with a CSV file as the data output. Experiment Impact Tracker and Carbon Tracker multiply the computed energy by a Power Usage Effectiveness (PUE) ratio by default. It was systematically removed. 2) Benchmarks execution: For the CPU benchmarks, the NAS benchmarks were launched on all cores of both CPUs by keeping the default thread number configuration.
This additional consumption could be due to the fans running at high speed in order to cool the components after the execution of the benchmark. Since the power profile given by software-based power meters excludes fan consumption, this phenomenon is not observed by Energy Scope. 2) Correlation and offset with external power meter: We previously observed that the software-based power profiles are similar and are visually strongly correlated with the external power meter and the BMC profiles. We will study this correlation in more depth in this section. The tools do not have exactly the same timestamps and sampling frequencies. To do a point-by-point correlation study between power profiles, we had to fit the higher frequencies data points to the lower ones by averaging. To compute the correlation, we used the library Pandas  [51]  and the default Pearson correlation.
The standard deviation of the energy reported by the tools is not significant in general which means that the tools are consistent. For CPU benchmarks, almost all studied tools report similar energy consumption on every benchmark, except Code Carbon and online energy calculators (Green Algorithm, ML CO2 Impact). Code Carbon tends to report power consumption values almost twice as high as other tools based on the same interface for obtaining consumption values (Intel RAPL). For GPU benchmarks, the differences between tool reports are larger, which is due to a higher difference in sampling frequency (see Table  I ). Experiment Impact Tracker has a higher variability on all benchmarks but especially on the MG benchmark. For all benchmarks, the online calculators (Green Algorithm, ML CO2 Impact) tend to report energies closer to the external power meters than the tools based on RAPL and NVML, but not on the MG NAS benchmark.
B. Computing node components consumption Power API  [40] , Scaphandre  [41] , Perf  [46] , and Energy Scope  [42] have an additional feature to provide us with power profiles of the following components of the computing node: CPU, DRAM, and GPU (only for Energy Scope). Fig. 3b  and Fig. 3a  show the power profiles for every CPUs, DRAMs and GPUs as provided by the above-mentioned software. The CPU benchmark power profiles are highly similar. The differences in the power profiles are due to different sampling frequencies. We can also mention that the DRAM consumption reported by each tool seems to reflect the actual DRAM usage by each benchmark. For memoryintensive benchmarks such as LU and MG, we see the change in DRAM consumption reports while the benchmark is running. Whereas, for the EP benchmark which uses no memory, the DRAM consumption data remain unchanged.
VI. LESSONS LEARNED Goals in measuring the power or the energy can be numerous. We identify a few scenarios and give recommendations on which tool to select based on our study. When the objective is to reduce the amount of energy needed to execute a workload, any energy calculator, energy measurement software package, Energy Scope, or Perf can be used since they all report the energy. We have found that the energy calculators Green Algorithm and ML CO2 Impact can give very good estimations on the conditions of having a constant workload and an in-depth knowledge of the execution (duration and average usage). There is no guarantee of the quality of the estimation. The three energy measurement Python libraries are highly similar in their energy reports. Code Carbon has the lowest offset in all experiments.
VII. CONCLUSION In this paper, we propose a comparison of nine softwarebased power meters: Carbon Tracker  [37] , Code Carbon  [38] , Energy Scope  [42] , Experiment Impact Tracker  [39] , Perf  [46] , Power API  [40] , Green Algorithms  [36] , ML CO2 Impact  [35] , and Scaphandre  [41]. We detail the existing methods to measure or estimate the energy consumption of a computing node or an application execution. Then we present and compare the selected tools qualitatively. An experimental study investigates the quality of the power profiles and the energy estimations under computation and/or memory-intensive benchmarks. Those experiments allow us to evaluate other characteristics of the software-based power meters, such as their overhead, the maximum sampling frequency, and the maximum number of processes they support.
ACKNOWLEDGMENTS This research is partially supported by the  FrugalCloud collaboration between Inria  and  OVHCloud , by  MIAI  ( ANR-19-P3IA-0003 ), and by the  BATE  project ( BATE-UGA-REG21A87 ) of the  Auvergne Rhône-Alpes  french region. Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by  Inria  and including  CNRS ,  RENATER , and several Universities as well as other organizations (see https://www. grid5000. fr).
64 Our ERS program "High Contrast Imaging of Exoplanets and Exoplanetary Systems with JWST" (ERS-01386;  Hinkley et al. 2022)  is the only ERS program that has tested the highcontrast exoplanet imaging modes of JWST and includes coronagraphic imaging from 2 to 16 μm of the known exoplanet HIP 65426b  (Chauvin et al. 2017; this work)  and circumstellar disk HD 141569 A  (Weinberger et al. 1999; M. Millar-Blanchaer et al. 2023, in preparation; E. Choquet et al. 2023, in preparation) , spectroscopy from 1 to 28 μm of the PMC VHS J125601. 92-125723. 9 AB b (VHS 1256b;  Gauza et al. 2015; Miles et al. 2023) , and AMI observations of HIP 65426 at 3. 8 μm (S. Sallum et al. 2023 , in preparation; S. Ray et al. 2023, in preparation). This program is rapidly disseminating these crucial initial data, and it is demonstrating the true capabilities of JWST for high-contrast imaging and spectroscopy for the first time.
(2021)  performed an atmospheric forward model analysis of HIP 65426b, indicating that it has T eff = 1560 ± 100 K, log (g) 4. 40 dex and [M/H] = 0. 05 0. 22 0. 24 -+ dex, and the atmospheric carbon-to-oxygen ratio has an upper limit of C/O 0. 55. Furthermore,  Petrus et al. (2021)  also detect the presence of H 2 O and CO in the atmosphere of HIP 65426b using crosscorrelation molecular mapping, in addition to nondetections of CH 4 and NH 3. Finally, from evolutionary model analyses to the data reported in  Chauvin et al. (2017) ,  Marleau et al. (2019)  estimate the mass of HIP 65426b to be 9. 9 1. 8 1. 1 -+ M Jup or 10. 9 2. 0 1. 4 -+ M Jup for hot-or cold-start initial entropy conditions, respectively (see, e. g. ,  Marley et al. 2007; Spiegel & Burrows 2012). In Section 2, we describe our JWST observations of HIP 65426b and all necessary data reduction.
Observational Structure The observational strategies used for this program were adopted following the recommended best practices as known prior to launch and described in the JWST user documentation. 65,66 All observations of HIP 65426b are repeated at two independent roll angles separated by ∼10°to enable subtraction of the residual stellar point-spread function (PSF) through angular differential imaging (ADI;  Müller & Weigelt 1985; Liu 2004; Marois et al. 2006). Although a large number of rolls across a larger angular range would be desirable for an optimal subtraction using this technique, the combination of lengthy exposure times, increased overheads, and spacecraft orientation constraints prohibit an observing strategy more complex than described. Given the maximum possible roll offset for JWST at any given epoch is 14°, a larger roll offset than we have adopted would also require multi-epoch observations.
SpaceKLIP For all observations, we perform data reduction using the newly developed and publicly available Python package, spaceKLIP 68  (Kammerer et al. 2022). Briefly, spaceKLIP takes a collection of data products from the jwst pipeline 69,70. (Bushouse et al. 2022)  as inputs, and generates PSF subtracted images, contrast curves, and measurements of companion photometry and astrometry. The majority of this functionality is provided by the underlying pyKLIP  (Wang et al. 2015)  package, with spaceKLIP providing a user friendly interface, streamlined code execution, custom JWST data reduction routines, and built-in plotting procedures.
At present, the dark current calibration data exhibit a large number of hot pixels, persistence, and cosmic rays that cannot be averaged out or corrected, due to limited number of available integrations. Attempts to perform a dark current subtraction using this data result in a variety of negative flux residuals in the reduced images and an overall reduced sensitivity of the final pipeline product. Once this calibration file is improved through further calibration observations, we do not anticipate a need to skip this step for NIRCam coronagraphic data. During the jump detection step, the jwst pipeline will make use of a detection threshold value based on the estimated signal and noise to assess whether a deviation between groups is significant enough to be considered a jump (see footnote 6 for further detail).
6) that bias our measurements of the contrast performance. Therefore, we provide the locations of these pixels to spaceKLIP manually and correct them in an identical manner as for the pixels marked with data quality flags. As the NIRCam PSF in the F250M filter is undersampled, ringing artifacts are generated by the interpolation methods in pyKLIP used for image registration and spatial shifting of input PSFs. These artifacts bias the image registration process and limit our ability to accurately inject synthetic PSFs for contrast curve calibration and companion astrometry and photometry. To overcome this issue, we smooth all of the F250M images by a Gaussian filter, as implemented by scipy, with σ = 1. 3 pixels. This value of σ was chosen because it was the minimum possible value that removed the observed artifacts across a test of ten equally spaced values from σ = 1 to σ = 2.