dataesr/scientific-paragraphs-categorization huggingface dataset:
IV. TECHNICAL DETAILS OF NixOS Compose Nix can generate a NixOS configuration from a Nix expression, including the boot and init phases required to start the kernel. Nix stores those phases in the Nix Store, which enables NixOS Compose to call them later on. NixOS Compose works in two steps: Building and Deployment. The building phase is done using Nix tools wrapped with Python for the commandline interface. The deployment is fully done with Python and mostly consists in the interaction with the different deployment tools (Kadeploy, docker-compose, QEMU). The Nix part is around 2000 lines of code, and the Python part around 4000. The following section (IV-A) details how NixOS Compose manages g5k-ramdisk, the flavour that enables quick in-memory deployment without the need to reboot host machines on Grid'5000.
A. Presentation of Melissa Melissa is a framework to run large-scale sensitivity analyses. Its main specificity is the online processing of data to limit usage of intermediate file storage, contrary to postmortem approaches. It can be used in several HPC environments as it is compatible with two resource managers (RM): Slurm  [32]  and OAR  [5]. Melissa implements a client/server model where the clients are simulations that generate and send data to a server that runs the statistics algorithms. NixOS Compose enables to deploy a resource manager (including all the components it requires, e. g. , a database), Melissa, and all the components required by Melissa at runtime (e. g. , a distributed file system).
C. Melissa Images Content Comparison NixOS Compose aims to provide the same environment on different target platforms. This section analyses the content of the Nix Store in the Melissa images generated for every flavour, as the Nix Store content represents the software environment available on the node. The docker flavour is omitted here as the containers do not have a well-defined specific Nix Store but mount the Nix Store of the host machine instead. Figure  6  presents the content of the Nix Store of the Melissa image for the different flavours. The smaller packages are gathered under the others-* name. We can see that the vast majority of the software stack is shared by several flavours. There is a common 2 GiB set of packages common to every flavour containing the NixOS definition and the dependencies of Melissa.
A. Experimental Setup The following experiments have been carried out on the dahu cluster of the Grid'5000 testbed. This cluster has machines with 2 Intel Xeon Gold 6130 CPUs with 16 cores per CPU and 192 Gib of memory. The nodes of this cluster have SSD SATA Samsung MZ7KM240HMHQ0D3 disks with a capacity of 240 GB formatted in ext4. The experiments conducted in this article are repeatable with variation. Data and analysis scripts are available on Zenodo 4 with the link to the experiments repository. 4 https://zenodo. org/record/6568218.
B. Comparison to Kameleon Grid'5000 provides base images for several Linux distributions and versions. Users need to build their own images if they want to use more complete images. This is usually done with Kameleon on Grid'5000 -in fact all the images provided by Grid'5000 are generated by Kameleon recipes. In this study, we want to compare the performance of NixOS Compose and Kameleon to build images. We will focus on the image build time, as well as the size of the generated images. We also want to evaluate whether caching the Nix Store enables an interesting build time speedup. 1) Protocol: The following steps are executed in this order. We first build a base image with NixOS Compose and Kameleon, measuring its build time and the size of the generated images. base contains the basic software needed to conduct a distributed experiment: grid5000/debian11-x64-nfs for Kameleon as this is the most convenient and common image for distributed experiments on Grid'5000, and all the packages required by the flavour for NixOS Compose.
Then we add the hello package to the recipes and build a new image (base + hello) while measuring the same metrics. This experiment has been executed using Grid'5000's NFS (mounted on /home) or without it (using local disks on machines mounted on /tmp), in order to compare the performance of the tools depending on the filesystem setup used. We clear the Nix Store before building the base image, but not before building base + hello, in order to evaluate the impact of cached builds on NixOS Compose. Kameleon has an indirect caching mechanism via the HTTP proxy Polipo  [26]. However, we did not manage to make it work with Kameleon, and Polipo is no longer maintained as its utility has become arguable -most of today's traffic is encrypted, including fetching packages from mirrors. 2) Results and Comments: As seen on Figure  7 , NixOS Compose substantially outperforms Kameleon in terms of image build time.
VII. CONCLUSION AND FUTURE WORK This article has presented NixOS Compose, a tool that enables the generation of reproducible distributed environments. We have showed that NixOS Compose deploys the exact same software stack on various platforms of different natures, without requiring specific work from users. The software stack is reconstructible by design, as NixOS Compose inherits its reproducibility properties from Nix and NixOS. Our experiments showed that NixOS Compose's reproducibility and platform versatility properties are achieved without deployment performance overhead in comparison to the existing solutions Kameleon and EnOSlib. NixOS Compose is a free software released under the MIT license. As we write these lines, we think that its maturity level enables to deploy the distributed environment of many experiments.
• dbd: MariaDB database (accounting for the RM) • computeNode: worker node • frontend: node from where initial jobs are submitted server = { pkgs,. }: { 2 imports = [ slurmconfig nfsConfigs. server ]; 3 services. slurm. server. enable = true; 4 systemd. services. slurmctld. serviceConfig = { Configuration of the server and computeNode roles.
{ pkgs,. }: 2 pkgs. stdenv. mkDerivation rec { 3 pname = "melissa-${version}"; 4 version = "0. 7. 1"; 5 src = pkgs. fetchgit { 6 url="https://gitlab. inria. fr/melissa/melissa"; Build phases are omitted 15 } Listing 5. Snippet of the package definition for Melissa.
ACKNOWLEDGMENT 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). This research was partly supported by the  EuroHPC EU Regale  project (g. a. 956560). The authors would like to thank  Matthieu Simonin  for the helpful discussion on EnOSlib.
6 1 5 RestartListing 4. 654 • dbd: MariaDB database (accounting for the RM) • computeNode: worker node • frontend: node from where initial jobs are submitted server = { pkgs,. }: { 2 imports = [ slurmconfig nfsConfigs. server ]; 3 services. slurm. server. enable = true; 4 systemd. services. slurmctld. serviceConfig = { Configuration of the server and computeNode roles.
1 14 # 14 { pkgs,. }: 2 pkgs. stdenv. mkDerivation rec { 3 pname = "melissa-${version}"; 4 version = "0. 7. 1"; 5 src = pkgs. fetchgit { 6 url="https://gitlab. inria. fr/melissa/melissa"; Build phases are omitted 15 } Listing 5. Snippet of the package definition for Melissa.
Total ozone data In the present study we use total ozone data from three Brewer spectrophotometers, a SAOZ instrument, and three ground-based ultraviolet radiometers (GUVs). Measurements are performed at the Sverdrup station at Ny-Ålesund, Svalbard (78. 92 • N, 11. 88 • E; 15 m a. s. l. ), at the Arctic Lidar Observatory for Middle Atmosphere Research (ALO-MAR) on Andøya (69. 28 • N, 16. 01 • E; 360 m a. s. l. ), and at Oslo (Blindern and Kjeller) (Fig. 1 ). Measurements at Oslo were performed in Blindern (59. 95 • N, 10. 72 • E; 96 m a. s. l. ) at the University of Oslo until July 2019; afterwards the instruments were moved to the Norwegian Institute for Air Research (NILU) in Kjeller (59. 98 • N, 11. 05 • E; 139 m a. s. l. ), which is located around 18 km east of Blindern. We have colocated Brewer and GUV measurements at all stations and additional SAOZ measurements at Ny-Ålesund.
Brewer spectrophotometers We use ozone data from three Brewer spectrophotometers that measure UV radiation between 305 and 320 nm. The Brewer located at Oslo is a single-monochromator Brewer MKV (serial number B42), whereas a doublemonochromator Brewer MKIII (B104) is located at Andøya. Both instruments are operated by NILU and have been cal- We investigated all calibration reports and performed some changes in the calibration files. The updates were small (mainly small calibration date corrections) and affected only a few single days. Measurements during the whole calibration period were excluded.
Direct sun method For the default direct sun (DS) measurements, the Brewer instrument measures direct sunlight in the UV, as described for example in  Savastiouk and McElroy (2005). Total ozone is then derived from the intensities by considering ozone absorption coefficients and Rayleigh scattering coefficients (e. g. Fioletov et al. , 2011) , using the O3Brewer software (version 6. 6 available at http://www. o3soft. eu/o3brewer. html, last access: February 2021). All DS measurements are regularly calibrated with daily standard lamp (SL) measurements. For the SL correction, the intensities of an internal halogen lamp (SL) are measured at the same five wavelengths as for the ozone measurements. The SL produces a stable and continuous light spectrum. Any variations visible in the SL measurements would also affect the ozone measurements and are therefore corrected in the routine DS calculation.
Combined ground-based total ozone data To obtain ground-based total ozone time series with as few missing measurement days as possible, we combine total ozone measurements from the four different measurement techniques to a combined time series (GBcomb). Brewer DS and SAOZ have been used in multiple studies (e. g. Hendrick et al. , 2011; Goutail et al. , 2005; Scarnato et al. , 2010)    therefore used as a baseline in GBcomb. Measurement gaps are then filled with GI and GUV data. GUV data have been validated against Brewer DS and SAOZ data by  Svendby et al. (2021) , who found no significant biases between the datasets. GI data are evaluated in Appendix A. The Brewer DS measurements build the baseline in Oslo (53 % of the measurement days) and Andøya (44 %). Missing measurement days are first filled with GI data (around 40 % at both stations), then with GUV (5 % in Oslo and 15 % in Andøya) (Fig.
3e ) and Ny-Ålesund (Fig. 3f ). The datasets generally agree on the natural variability and the anomalies, with larger anomalies in some years. For example, the ozone-poor year 2020 in the Arctic is clearly visible at Ny-Ålesund (Fig. 3f ). Also, the strong negative anomaly in 2011 can be seen in all datasets at all stations. However, we observe that ERA5 reports more total ozone than the other datasets at all stations starting in 2014, which coincides with a change in assimilated satellite data in ERA5, as indicated by  Hersbach et al. (2020)  (new assimilation of METOP-B GOME-2 and change in assimilated SBUV-2 data). Furthermore, ERA5 and SBUV seem to drift from 2000 to 2005 compared to the ground-based data at all stations. Afterwards, this drift is not visible any more, suggesting that the drift may be corrected with the beginning assimilation of Aura observations in ERA5  (Hersbach et al.
Multiple linear regression We use a multiple linear regression model that was developed within the activity Long-term Ozone Trends and Uncertainties in the Stratosphere (LOTUS). The so-called LOTUS regression has been tested with several ozone datasets and is described in detail in SPARC/IO3C/GAW (2019). We use the model version 0. 8. 0 (USask ARG and LOTUS Group, 2017) and extended it by adding additional predictors (see Sect. 4. 1). The following regression function is used: ŷ(t) = a + b • t + 4 n=1 c n • sin 2π l n • t + d n • cos 2π l n • t + m n=1 (β n X n ) , (1) with the estimated ozone time series ŷ(t), the time vector of monthly means t, a constant intercept a, and a linear term b. The regression is applied to monthly means from the combined daily ozone data (GBcomb). We exclude months with fewer than 25 measurement days to avoid values that are not representative of the whole month.
Conclusions This study investigates ground-based total ozone trends at the northern high-latitude stations Oslo, Andøya, and Ny-Ålesund. We presented combined total ozone time series at the three stations with measurements from four measurement techniques (Brewer DS, Brewer GI, SAOZ, and GUV). The combination of various techniques makes it possible to overcome measurement gaps due to instrumental limitations. The combined time series were compared with satellite overpass data and ERA5 reanalysis. All datasets agree on average within 1 % to 3 % with the ground-based time series. To derive total ozone trends from 2000 to 2020, we used the LOTUS regression model for the first time for groundbased total ozone data at high latitudes. Additional regression predictors have been examined, and a set of predictors have been identified that should be considered when deriving total https://doi.
The advantage of GI is that it can also be used at high SZA, and the measurement season at high latitudes can therefore be extended in winter months when the sun is low. Furthermore, the GI method is based on physical measurements, whereas the ZS method is normally based on purely statistically derived relationships. nasa. gov/Data_services/merged/ (last access: 24 November 2021; NASA Goddard Space Flight Center, 2022c). The NCEP Reanalysis Derived data used for tropopause predictors were provided by the NOAA/OAR/ESRL PSL, Boulder, Colorado, USA, from their website at https://psl. noaa. gov/data/gridded/data. ncep. reanalysis. derived. tropopause. html (last access: 27 May 2022; NOAA PSL, 2022). The other sources for the predictors used in the trend model are given in Table  2. The Python version of the GI processing programme is available upon request by Tove Svendby (tms@nilu.
Code and data availability. The combined time series used in this study -including daily SAOZ means and noon measurements of Brewer DS, Brewer GI, and GUV -are provided at https://doi. org/10. 5281/zenodo. 6760259 (Bernet et  al. , 2022). The full Brewer GI dataset can be found at https://doi. org/10. 5281/zenodo. 6760244 (Svendby et al. , 2022). The full time series of Brewer DS daily means are available at the World Ozone and Ultraviolet Radiation Data Centre (https://doi. org/10. 14287/10000001, NILU et al. , 2021). SAOZ data are available at http://www. ndacc. org/ (last access: 4 July 2022; Network for the Detection of Atmospheric Composition Change, 2022). GUV data (v2. 0) are available at https://doi. org/10. 5281/zenodo. 4773478 (Svendby, 2021)  and are used here with some updates (extended to 2020, and calibrated in 2019 and 2020).
OMI and GOME-2 overpass data are available at the Aura validation centre, for OMI (OMDOAO3) through https://avdc. gsfc. nasa. gov/pub/ data/satellite/Aura/OMI/V03/L2OVP/OMDOAO3 (NASA Goddard Space Flight Center, 2022b; please see  Veefkind, 2006 , https://doi. org/10. 5067/Aura/OMI/DATA2012 for the global data) and for GOME-2A and GOME-2B through https://avdc. gsfc. nasa. gov/pub/data/satellite/MetOp/GOME2/V03/L2OVP/ (last access: 7 December 2021; NASA Goddard Space Flight Center, 2022a). The SBUV MOD data are available at https://acd-ext. gsfc.
clouds https://ozonewatch. gsfc. nasa. gov/meteorology/temp_2020_MERRA2_NH. html (last access: 27 May 2022) https://acd-ext. gsfc. nasa. gov/Data_services/met/ann_data. html (last access: 17 February 2022) T50 * Stratospheric Deseasonalized temperature at 50hPa from ERA5 reanalysis at each station. temperature Hersbach et al. (2019, https://doi. org/10. 24381/cds. 6860a573 ) TropP * Tropopause Deseasonalized data from NCEP reanalysis (Kalnay et al. , 1996) at each station. pressure ftp://ftp. cdc. noaa. gov/Datasets/ncep. reanalysis. derived/tropopause/pres. tropp. mon. mean. nc (last access: 27 May 2022) TropT * Tropopause Deseasonalized data from NCEP reanalysis (Kalnay et al. , 1996) at each station. temperature ftp://ftp. cdc. noaa. gov/Datasets/ncep. reanalysis. derived/tropopause/air.
o. ) who performed 3 sessions-separated by 7 days-of the Multi-Attribute Task Battery-II (MATB-II) with 3 levels of difficulty per session (pseudo-randomized order). The data -training and testing sets-were made publicly available on Zenodo along with Matlab and Python toy code (https://doi. org/10. 5281/zenodo. 5055046). To this day, the database was downloaded more than 900 times (unique downloads of all version on the 10th of December 2021: 911). Eleven teams from 3 continents (31 participants) submitted their work. The best achieving processing pipelines included a Riemannian geometry-based method. Although better than the adjusted chance level (38% with an α at 0. 05 for a 3-class classification problem), the results still remained under 60% of accuracy. These results clearly underline the real challenge that is cross-session estimation.
This is equally true for other EEG-based datasets and competitions outside the field of pBCI. Recent examples include the public database of joint recording of EEG and fNIRS data during cognitive tasks published by  Shin et al. (2018)  that enabled the authors to evaluate the benefits of a hybrid-BCI for withinsubject and single-session mental state estimation during a word generation task. The Clinical BCI challenge in 2020 provided data from healthy and stroke patients, which was new and enabled both within and cross-subject estimation, but using only one session (consisting of 1 offline training session and 1 online testing session;  Chowdhury and Andreu-Perez, 2021). Lastly, the NeurIPS 2021 BEETL Competition: Benchmarks for EEG Transfer Learning  (Xiaoxi et al. , 2021)  provided 1 sleep dataset and 5 Motor-imagery datasets (active BCI).
The goal was to perform cross-subject sleep stage estimation (impact of the age of the participants), as well as cross-dataset MI-BCI estimation with multiple sessions. Hence, to our knowledge, existing public EEG datasets-and the scarce pBCI datasets-provide brain signals recorded on a single day/session  (Hinss et al. , 2021b) , preventing the design and evaluation of pBCIs that would work across days/sessions. Ideally, a real-life pBCI, as envisioned in neuroergonomics, would need to be effective and efficient at all time, i. e. , across sessions, without the need for recalibration. We thus proposed a data analysis competition at the 3rd International Neuroergonomics conference, that aimed at addressing this scientific challenge. We notably released the first (to the best of our knowledge) public pBCI dataset providing EEG signals across multiple sessions for each user, and we challenged the competitors to come up with the best algorithm to decode mental workload from EEG signals on a new unseen session, from a training dataset comprising several sessions.
The choice was made to focus on a mental state frequently investigated in the pBCI literature, namely, mental/cognitive workload. Hence, data was acquired using a well-known task that elicits various levels of mental/cognitive workload: the Multi-Attribute Task Battery-II (MATB-II) developed by NASA, which enables to assess taskswitching and mental workload capacities [https://matb. larc. nasa. gov- (Santiago-Espada et al. , 2011) ]. The dataset is part of a new open EEG database currently under development, and designed to address the need for more publicly available EEGbased datasets to design and benchmark passive brain-computer interface pipelines [as detailed in  Hinss et al. (2021b) ]. This article provides a retrospective on the competition by first detailing the competition management, the released dataset, the competitors and the methods employed by them as well as the obtained results and a reflection on which methods seem more fit for cross-session EEG-based mental workload estimation.
Competition Management The competition was organized as the grand challenge of the 3rd International Neuorergonomics conference (https:// www. neuroergonomicsconference. um. ifi. lmu. de/) held online in September 2021 (from Munich, Germany). It was managed using the conference ConfTool submission website and the Zenodo dataset sharing website  (Hinss et al. , 2021a). The participation and submission rules were the following: • One submission per team; • One participant may only be part of one team; • Submissions must include: results (estimated labels for the test set) and abstract (same format as regular paper submissions for the conference). The important dates of the conference competition were the following: • Overall, the goal of the participants was to design and to train a 3class pBCI workload classifier on the first two labeled sessionsi.
Task As mentioned earlier, the dataset used for the competition comprised epoched data acquired during the performance of a well-known task in the human factors domain: the MATB-II whose graphical user interface is shown in Figure  1A. In this task, participants had to perform several sub-tasks simultaneously. Depending on the condition, the number of sub-tasks and their respective difficulty differed. Each condition lasted 5 min. The order was randomized with the other tasks, meaning that participants did not necessarily start with the easy task first. In the easy condition (label 0), participants engaged in the TRACKING and SYSTEM MONITORING sub-tasks. The TRACKING task is a simulation of manual control, and the participant has to keep a target at the center of a window. The SYSTEM MONITORING task requires monitoring 4 gauges and 2 warning lights.
Data Acquisition A MATLAB version of the MATB-II task was used for the experimental campaign (developed and used by  Verdiere et al. (2019) ; https://github. com/VrdrKv/MATB). EEG data acquisition was performed using a 64 active Ag-AgCl electrode system (ActiCap, Brain Products Gmbh) and an ActiCHamp amplifier (Brain Products, Gmbh; Figure  1B ). One electrode could not be used and one electrode was dedicated to record cardiac activity, resulting in 62 electrodes, placed according to the international 10-20 system. In addition, the precise electrode location was obtained using a STRUCTURE (https://structure. io) 3D camera and the get_chanlocs plug-in developed specifically for electrode localisation purposes (https://github. com/sccn/get_ chanlocs/wiki). The sampling frequency was set to 500 Hz.
Data Preprocessing Data preprocessing was done in MATLAB with the help of the EEGLAB toolbox  (Delorme and Makeig, 2004). First, the data from the resting state as well as the tasks were extracted from the overall recording. The electrode recording cardiac activity was removed. The following pre-processing pipeline was applied: • Epoching into 2-s non-overlapping epochs; • Referencing using right mastoid electrode; • High-pass filter 1 Hz (FIR Filter, pop_filtnew from EEGLAB); • Electrode rejection (average amplitude above 2 times the standard deviation across channels) and spherical interpolation; Note that these preprocessing steps were performed in order to enhance the signal-to-noise ratio, but also to reduce biases in the competition. For instance, data were filtered below 40 Hz, and ICA was used so as to reduce as much as possible the risk of estimations based on motion-related ElectroOculoGraphy (EOG) and ElectroMyoGraphy (EMG) artifacts.