dataesr/scientific-paragraphs-categorization huggingface dataset:
Face validity on HCP dataset In Fig. 23 , we plot the results for five tasks taken from the HCP dataset, besides of the two described in Sec. 4. 6. For all methods, the statistical maps are thresholded such that the δ-FWER stays lower than 10% for δ = 12 mm. Qualitatively, EnCluDL discovers the most plausible patterns, Ada-SVR often makes dubious discoveries, patterns are too wide and implausible, while the two other methods exhibit a very weak statistical power. As discussed in the main person, Univ-OLS provides complementary results that highlight marginal association between the data and the target.
Figure23: Estimated predictive patterns on standard task fMRI dataset. Here, we plot the results for five tasks of the experiment described in Sec. 4. 6 thresholding the statistical maps such that the δ-FWER stays lower than 10% for δ = 12 mm. Qualitatively, EnCluDL discovers the most plausible patterns, Ada-SVR often makes dubious discoveries, patterns are too wide and implausible, while the two other methods exhibit a very weak statistical power. As discussed before, Univ-OLS provides complementary results that display marginal associations between voxel signals and the target. The results of emotion and gambling tasks are available in Fig. 7.
Acknowledgements. Data were provided in part by the  Human Connectome Project, WU-Minn Consortium  (Principal Investigators:  David Van Essen  and  Kamil Ugurbil ;  1U54MH091657 ) funded by the 16  NIH Institutes  and Centers that support the  NIH Blueprint for Neuroscience Research ; and by the  McDonnell Center for Systems Neuroscience at Washington University. This project has received funding from the  European Union 's  Horizon 2020 research and innovation program  under grant agreement No  826421 , and has been supported by  Labex DigiCosme  (project  ANR-11-LABEX-0045-DIGICOSME ) operated by  ANR as part of the program  " Investissement d'Avenir "  Idex Paris Saclay  ( ANR-11-IDEX-0003-02 ), as well as by the  ANR-17-CE23-0011   Fast-Big  project.
A shallow recess in the second containment gives access to the lamp and the optical components for replacement and adjustment. It is not trivial to achieve homogeneous illumination of the RW. The arc of the Cermax ® lamp is placed in the focus of a parabolic mirror. In the far field, the radial intensity profile of the beam decreases towards the rim and is similar to a Gaussian. Its transformation to a homogeneous profile is enabled by projecting the sharp intermediate focus of the arc image between the two lenses. The requisite condition is that the angular emittance at any point of this image reaches the solid angle of the full light cone. The final configuration was optimized by simulations with the optics program COMSOL. The results shown in Figure  19  yield the specified homogeneity of ±10 % (gray horizontal band) over the entire RW up to its maximal radius of 7 cm (marked with a solid line).
Commissioning results with the argon frost pump Argon frost preparation and purging with helium was successfully done for the first time in December 2017. In each beam tube section of the cold trap, the temperature is monitored by 3 rhodium-iron sensors with 50 mK accuracy. During the first activation of the 3-K cooling system, the measured temperatures on the beam tube did not reach the expected 3 K, but varied between 3. 4 K and 6. 2 K  [51]. In order to investigate the origin of the temperature discrepancy, the heat transfer module of the commercial simulation program COMSOL Multiphysics ® was used with a finite-element-method simulation. The results of these simulations are discussed in detail in  [38]. Except for some warmer spots, such as the bolts connecting the warmer inner radiation shield to the beam tube sections, most of the beam line areas, in particular those with the fins, are in a temperature range between 3 -4 K.
Therefore, the efficiency of this method depends on the electric dipole field strength and the kinetic energy of the stored electron, limiting its application to removing electrons  the application of a dipole pulse (green). Figures adopted from  [56]  up to a few keV. For efficient removal, a short dipole pulse of about one second is sufficient. The electric dipole mode, static or pulsed, and its on-off time is controlled by the ORCA software. The electric dipole cannot be applied during standard data taking, because the field would distort signal electron transmission. However, its short operation time allows its operation during changes of the retardation potential in a tritium run. For analysis purpose, the dipole status is stored together with the FPD data. Besides background mitigation, the electric dipole field can also be used for background electron investigations (e.
Readout Electronics and Data Acquisition The KATRIN DAQ system needs to cover a wide range of event rates, from single-channel rates of order 1 cps to 100 kcps, and order 10 cps to above 1 Mcps total rate over the whole detector  [1]. To meet these requirements, a modular, programmable custom DAQ system for multi-channel systems up to nearly 500 channels has been developed. The basic design has been used for the commissioning of the KATRIN FPD system and is described in  [57]. Since then, its performance for the highest rates has been optimized. The signal chain consists of analog filters, digitization, digital signal processing, readout by a Linux PC and management, monitoring, and control with the ORCA software  [94]. The development of the KATRIN DAQ system has benefited from the electronics being programmable.
Before entering the spectrometer for Raman spectral analysis, the radiation is cleaned by removing any residual laser light via a long-pass filter. The spectrometer range and resolution are fixed such that all six hydrogen isotopologues can be resolved and recorded simultaneously by the high-sensitivity CCD-array detector , as demonstrated in  [99]. System control, operation parameter recording, Raman spectrum acquisition, and real-time data treatment and analysis are integrated in a dedicated LabVIEW program  [103]. The analysis outputs for   ,  T , and  are extracted from the spectra and transmitted to the KATRIN slow control database. The Raman spectral data is accumulated for 20 s to 30 s. Selected sample data from a test setup ("LOOPINO") of the actual tritium loop  [104]   46. This demonstrates the LARA system performance over extended periods of time, when operating under KATRIN run conditions.
Performance of the Raman setup Since its first implementation  [1] , the LARA monitoring system has been continuously tested and improved through a number of measurement campaigns. These include the Test of Inner Loop (TILO) test run using only non-tritium isotopologues  [106] , and the LOOPINO tritium test runs in 2010  [104]  and 2013 (presented here). The first LARA setup had provided satisfactory results as early as 2005, but improvements since then showed that the KATRIN requirements could be met and in some cases exceeded. These improvements include: reducing the acquisition time by nearly two orders of magnitude, down to 20 s; upgrading components (excitation laser and CCD light detector); integrating a double-pass configuration, nearly doubling the Raman light intensity; implementing a fully quantitative intensity calibration  [101] ; and developing a custom data acquisition and evaluation software package  [103].
The potential inhomogeneity in the MS AP is one of the key parameters of the KATRIN setup that can be studied with the e-gun. Due to the physical design of the MS, radial and azimuthal inhomogeneities in the electromagnetic fields cannot be completely avoided. The potential depression Δ  (, ) is defined as the difference between the effective retarding potential in the AP,  ana (, ), and the high voltage applied to the spectrometer electrodes,  IE. It is typically about 1 V to 3 V and depends on the spectrometer configuration. Electrostatic simulations using the Kassiopeia software  [80]  can determine the effective retarding potential for an arbitrary electron trajectory, but need to be validated against dedicated measurements. A measurement of the retarding potential with the e-gun during the first neutrino mass campaign is shown in Figure  62.
All this data is available for further analysis by a dedicated data infrastructure consisting of several databases and web services. Access to the experimental data is provided via web front-ends used for manual monitoring, and a set of software libraries that allow analysis tools to process run and slow-control data. Data storage and computing resources of the analysis system are embedded in a cloud platform called KATRIN as a Service (KaaS) to ensure reliability and scalability of the analysis services. To ensure a reliable connection between the control systems and the integrated field-level devices, a redundant local network ring is constructed around the experimental site. In total 24 optical fibers are available to realize 12 independent network segments. This network infrastructure is used for machine control and experimental control.
3) is used to define the setpoints of individual voltages, usually by predefined scripts in the run control system. However, an emergency shutdown of the HV system components could be triggered by the machine control system. For instance, the HV is turned off in case of a sudden pressure rise in the vacuum system. The control system therefore continuously evaluates the global failure status and deactivates HV operation and the experimental control of the HV system if necessary. All sensor data are recorded in an internal PCS7 database and are archived by the KATRIN data management system via an OPC server. This information from the machine control system is made available to the experimental control system for monitoring and data analysis. An interface is integrated into the data service layer of the experimental control system.
Experimental control system The experimental control system is responsible for defining the experimental parameters and for acquiring all relevant information for data analysis. The operation of the KATRIN experiment is carried out by automated control scripts and, if necessary, can be manually adjusted by control room operators. The system includes devices for the monitoring and control of KATRIN instrumentation and the data archival system (slow control system). It also includes the run control system, which manages the detector readout and controls certain experimental parameters that need to be adjusted dynamically. The main experimental devices are calibration sources, the monitor spectrometer, high voltage system, FBM, the air-coil system, and the detector system. Most of the slow control systems are implemented in LabView using compact Reconfigurable Input Output (cRIO) hardware from National Instruments.
In total, 54 devices with a total of 2994 sensors are connected to the system. Typical sampling rates are in the range of 1 s to 10 s. The monitoring and control systems are integrated into the data management infrastructure. The status of all affiliated devices from both the experimental and machine control sections is continuously recorded in the slow control database. The data logging is performed using a legacy ZEUS  [57]  control system for cRIO devices. The parameters of PCS7 subsystems are queried using OPC protocol by a special archiving appliance. In both cases, Microsoft SQL Server instances are used to store the data (see Figure  78 ). cRIO devices with adjustable parameters are also integrated with the run control system using a standard network connection and a custom TCP-based protocol.
No experimental control is foreseen for PCS7 devices. The parameters of the system can only be changed from within the restricted local network. The values can be changed either manually by control room operators using the implemented Human-Machine Interface (HMI) interfaces, or through the run control system with automated scripts. The run control is implemented using the ORCA DAQ software  [94]. Scripting and graphical interfaces enable the control of the detector system and the configuration of experimental parameters. All current and historical data stored in the KATRIN data management system is available to ORCA through dedicated Representational State Transfer (REST) services. To adjust slow control parameters, a special ORCA object implements a TCP server that supplies the configured parameter set values to the cRIO systems upon request.
Data management, monitoring, and analysis system The design of the KATRIN data management system uses an on-premise cloud architecture aimed to simplify maintenance and ensure resilience against both hardware and software failures. The system is characterized by a high intensity of data flow and a relatively large archive of historical data. The three main data sources are the machine control system, experimental control system, and the FPD. About 6000 sensors are continuously monitoring the operating parameters of all components of the KATRIN infrastructure. Both machine and experimental control systems contribute about equally to the total data rates and the number of connected sensors, as shown in Figure  78. The cumulative bandwidth from sensor data is roughly 6 TB per year. The run data recorded at the FPD and MoS detectors are stored in a distributed file system.
The monitoring systems generate a significant load on the system, producing several hundred queries per second with an average data rate of roughly 20 MB/s from the caching database. The KATRIN Database (KDB) server integrates access to slow control and detector data for data analysis and provides a web interface to view the integrated data sets. Due to its role in the analysis of neutrino-mass runs, KDB experiences uneven, large load spikes after major data-taking campaigns. The OpenShift infrastructure allows us to reliably run a large collection of heterogeneous components developed by the international collaboration over more than a decade. These applications often depend on conflicting versions of software components, including deprecated and sometimes unstable versions. The container technology allows us not only to isolate the environment of each -123 -component but also to limit the impact that failures in one component might have on others and on overall system stability.
ADEI data management platform The KATRIN control systems integrate custom and commercial components from various vendors. Many different data formats, underlying storage engines, and workflows are used to store the data. The ADEI platform integrates all available data sources and makes them available to users in a uniform, comprehensible, and easy-to-use fashion  [159]. It includes a layer of abstraction to ensure a stable API over the course of the experiment and the development of its analysis, regardless of changes to the data format, the number of data streams, or the underlying databases. ADEI is also fully integrated with the OpenShift cloud platform to provide a highly available service to users and to auto-scale under increased load. The most prominent implementation of the ADEI web services is the interactive KATRIN data portal, which provides graphical access to data from all slow control systems.
For each display, several hundreds of sensors can be selected from the sensor inventory and placed as needed on the process image. Figure  81  show a CPS status page in the designer view and in operation. Once configured, the status is updated every 10 s and is available to the control room operators, but also to off-site collaborators via internet access. Measurement runs are taken with the ORCA software at the FPD, the MoS and the FBM sites. The data is first stored locally on the DAQ machine and then transferred to the KaaS cluster for automated processing and data distribution. Here a processing chain is implemented where the run files are converted into the ROOT  [160]  data format and registered in a dedicated database  [161]  to make these runs available for further analysis. The run processing works as follows: 1.
The run files are transferred to the cluster via the rsync software and stored on a distributed filesystem. This step is repeated in regular intervals to synchronize with the individual remote detector systems. 2. Each run file is then converted from the raw ORCA file format into a ROOT file, which stores all data fields in a tree structure where they can be easily accessed. Most runs are taken in so-called energy mode, where one entry corresponds to a single electron event; other data structures are used in some cases (see Table  7 ). During the conversion process, the events are also sorted by acquisition time and the data is checked for consistency. This step improves the performance of user-space analysis tools, which typically iterate over detector events. 3. ORCA assigns sub-run numbers to specific time intervals of programmable length within a run.
Sub-runs are typically used to represent a retarding voltage step during the KATRIN β-scans. The ROOT files are indexed on the sub-run level to improve performance when accessing data during analysis. Indices are added for the first and last events of a given type in each sub-run, allowing fast access to the corresponding sub-set of events in an entire run. 4. The processed runs are added to a central Structured Query Language (SQL) run database that is part of the KDB server. Each run and sub-run is added to a data table that contains the run number, start and end time, and other parameters. The corresponding run files (in ORCA and ROOT formats) are transferred to a central location on the distributed filesystem, where they can be accessed by users through the KDB interface.
Databases for run and sensor data In addition to the run data, there is also data from various sensor and monitoring systems which is taken continuously when the experiment is running. Examples are temperature and pressure readings, electric currents and voltages, or measurements from magnetic field sensors. This slowcontrol data is stored into SQL database tables and can be accessed through ADEI interfaces. To make this data available to analysis tools, an intermediate database layer is added in KDB to map individually named sensors to the corresponding table of the slow-control database  [161]. In 2019, the FBM switched from ORCA to a different data acquisition system. -126 -This is necessary because the data paths in ADEI can change with the experimental setup, while the analysis tools should not be aware of such low-level modifications.
Sensors and components are therefore referenced by a static label, the so-called KATRIN number, which is constructed with several groups and generally follows the format NNN-XXX-M-nnnn-ZZZZ. The groups are: NNN a 3-digit number referencing a sub-system (e. g. 200 for the WGTS); XXX a 3-character string for the sensor type (e. g. RTP for a temperature sensor); M a number for safety information (e. g. 3 for parts of the main beam line); nnnn a 4-digit number referencing an individual sensor system; and ZZZZ a 4-digit number referencing an individual channel of the sensor. For example, the reading of the central temperature sensor at the WGTS beam tube has KATRIN number 2 -RTP-3-5112-1. The sensor database is implemented with SQL and part of KDB, along with the run database explained earlier.
The advantage of this system is that it provides a consistent mapping, which can be adjusted in case the structure of the underlying slow-control database changes, for example, when new sensor channels are added after hardware upgrades or when sensors are regrouped. This applies both to LabView and PCS7 sensors. Furthermore, the database allows the definition of calibration functions for each mapped sensor channel, and analysis tools can choose between raw or calibrated data depending on their specific use case. Additional database tables exist for additional parameters of a sensor, such as geometrical position or alignment (useful for the definition of the simulation model) or definitions for automated data quality filtering of measurements. The organization of this data in a central database provides a consistent access method for the analysis tools and allows the sensor mappings, calibration curves, and other content to be updated as necessary.
To provide a means of consistency, all database entries are defined with an entry timestamp (when they were added to the database) and a user-defined validity start timestamp. A given entry is valid when the current time is equal to or later than the validity start timestamp. If multiple entries exist for this criterion, the entry time is used to select the most recent entry. Thus, only one valid entry can exist in the database at any given time. The database does not allow to change existing entries, and in order to update the database, a new entry must be created with the same or newer validity start timestamp. By this mechanism, it is ensured that existing entries and their validity time intervals are not modified accidentally, and all database changes can be traced back over time. Access to the database is provided through the KATRIN Library (KaLi) software  [161].
It is written in C++ and provides an object-oriented class structure that resembles the database contents; for example, there are classes that correspond to runs, sub-runs, sensor data, and so on. When the data is accessed by analysis tools, it is first serialized at the web service layer into an eXtensible Markup Language (XML) data stream via the Simple Object Access Protocol (SOAP)  [162]  framework. The stream is then transferred to the client over an HTTP connection, and de-serialized on the client side into C++ class objects that are then further processed by the analysis software. The implementation using SOAP allows for consistent data handling on the server and user side by the same software framework. In addition, a web interface for managing database contents is implemented using the Wt library.
This interface can be used to list and update database contents such as sensor mappings or calibration functions. Additional user-space counts with efficiency corrections, the retarding voltage, the source temperature, tritium pressure, gas throughput, isotopologue composition provided by LARA, and so on. These are typically produced by KAFFEE automation with BEANS scripts, and stored in IDLE. Some simulation outputs and calibration analysis results used for tritium spectrum fitting, such as field maps of the analyzing plane or the column density determined from routine calibrations, are also stored in IDLE in the same format. IDLE implements file version control with validity periods and file access permission levels. Data blinding to tritium runs makes use of these control features. The files stored in IDLE are distributed through KaLi, taking advantage of KaLi's cache mechanism.
Acknowledgments We are grateful to  Karlsruhe Institute of Technology (KIT)  for hosting and continuously supporting the KATRIN experiment in many different ways. We are deeply indebted to the staff of all the workshops at  KIT  and at all our other institutes for the great developments and constructions, without which this unique experiment would never have been possible. We greatly appreciate the many services at  KIT , such as project management, quality control, supply of liquid helium, etc. We would like to thank  KIT , all our institutions, the  scientific community  and the funding agencies, who have always believed in the success of this experiment, despite the delays of this difficult experiment, which was pushed to the limit of what is technically feasible. We would also like to add our heartfelt thanks for the invaluable contributions and guidance of collaborators who have passed away, including  H.