dataesr/scientific-paragraphs-categorization huggingface dataset:
During the second long shutdown (LS2) of the CERN Large Hadron Collider (LHC), the Detector Control System (DCS) of the Compact Muon Solenoid (CMS) Electromagnetic Calorimeter (ECAL) is undergoing a large software upgrade at various levels. The ECAL DCS supervisory system has been reviewed and extended to migrate the underlying software toolkits and platform technologies to the latest versions. The resulting software will run on top of a new computing infrastructure, using the WinCC Open Architecture (OA) version 3. 16 and newly developed communication drivers for some of the hardware. The ECAL DCS has been configured and managed from a different control version system and stored with more modern encoding and file formats. A new set of development guidelines has been prepared for this purpose, including conventions and recommendations from the CMS Central DCS and CERN Joint Controls Project (JCOP) framework groups.
Introduction The Electromagnetic Calorimeter  [1]  is one of the detectors of the CMS experiment, sitting at the CERN LHC. The DCS software of the ECAL detector monitors and controls a large number of equipment using the WinCC OA [2] platform. During the LHC long shutdowns, the architecture is typically reviewed and extended to include features that require extensive testing and long validation periods. The second long shutdown (LS2) has been extended by one year. This extension allowed us to implement large software updates, as described in the CMS ECAL DCS upgrade plan  [3] , as well as to carry out software migrations to bring the systems up to date, in line with the latest versions of the control platform and frameworks. We present in this document the main software updates, focusing on the migration of different software toolkits and platforms in terms of maintainability, compatibility and their impact in the existing architecture.
Migration of the version control system CERN announced the discontinued support for the software versioning and revision control system known as Apache Subversion (SVN)  [4]. The CMS collaboration has started a migration campaign to port the DCS source code from SVN to the Git distributed version control system  [5] , using the CERN GitLab hosting service. This type of migration has required not only the planning and reorganization of the repositories, but also the integration of the new toolkit and the migration of all historical records. After considering different options, it has been decided to break down the original single SVN repository into a hierarchy of individual Git repositories, organized according to their functional purpose. The pre-existing repository was re-organized while transferring all the historical records from one platform to another.
Migration from WinCCOA version 3. 15 to 3. 16 The details for the WinCCOA migration were released during the first half of 2020. Among other changes, the different CMS detectors were requested to adapt their DCS software in order to make it compatible with the latest release of the control platform. On the contrary of previous migrations, the change of version from WinCCOA 3. 15 to the version 3. 16 has required a complex transition between encoding types and source file formats. Most of these changes aim to make the DCS software compatible with upper versions of the platform. Therefore, a proper planning and execution of the different migration steps are crucial to minimize the code-freezing transition period between versions.
Change of the character encoding from ASCII to Unicode The version 3. 16 of WinCCOA only supports the UTF-8 encoded projects. In lower versions, projects were created using the ISO-8859-1 (Latin1) encoding by default, not compatible with most of western European languages. By contrast to the UTF-8, ASCII characters are represented by single bytes and can be stored and treated within the code using a character data type. In the UTF-8 encoding, all symbols including all language special characters, can be treated using a dynamic multi-byte representation from 1 to 4 bytes per character. Only a small sub-set of the UTF-8 encoding is backwards compatible with the first half of the ASCII set of characters (codes from 0 to 127 are identically represented in both encoding formats). Even if not enforced by the JCOP framework  [6]  convention, the usage of only ASCII compatible characters, excluding the language support features, is still considered a good practice.
The first step towards this migration was a consistency check to verify if the ECAL DCS code was compliant with this rule. All source files (libraries, scripts and panels) have been analysed to identify problematic pieces of code. As shown in the Most of the ECAL DCS functionality is programmed using the native WinCC OA Control (CTRL) Language. The original standard library functions for string processing in CTRL language are byte-wise and remain unchanged between both versions for backward compatibility. A new set of Unicode standard functions has been tested and proven to be compatible also with ASCII character set. This compatibility feature has motivated the introduction of Unicode functions, whose deployment has been carried out even before the migration to 3. 16 all across the ECAL DCS code.
Migration of the Control Framework from 8. 1. 2 to 8. 4. 0 One of the most important changes in the underlying software structures has been the migration to the version 8. 4. 0 of the CERN JCOP framework. In previous versions of this software framework, libraries and utilities were included as part of the global scope of WinCCOA. This means that most framework functions were accessible without declaring an explicit usage of their libraries. This feature was widely used across the CMS DCS, till the point that almost no source code file made an explicit inclusion of framework libraries. In the version 8. 4. 0 of the framework, it has been decided to discontinue this feature, mainly for performance purposes. This has forced the developers' community to update the source code to include framework libraries explicitly.
However, this new paradigm has been proven to require a more programmatic approach because of the large number of code mentions and file sources. We have used a combination of tools prepared by the JCOP and CMS Central DCS teams to identify and modify sources automatically. In more details, we have used a small utility called codePurger to construct the graph of function-calls across the ECAL DCS code repositories. This utility has been used to analyse and create a symbol's crossreference database with all the framework function calls throughout the ECAL DCS code. As shown in Fig. 2 , the symbol's database, later used by a java utility to look up for each framework function, has allowed the identification and modification of the sources that required an explicit library inclusion. The tools have processed a total of 120 different source files and performed 240 code transformations for purposes of library inclusions.
Migration to the OPC Unified Architecture The OPC server is a fundamental software component that runs as part of the chain of components in a control system. The OPC Unified Architecture (UA) is the successor of the OPC Data Access (DA) that defines how real-time data can be transferred between a data source and a data client without having to know each other's native protocol. The ECAL DCS uses three types of OPC servers to monitor and control large collections of fieldbus devices: 1. Wiener OPC to access the Wiener Maraton power supplies feeding Low Voltage (LV) power to the ECAL Endcaps (EE) and Barrel (EB). 2. CAEN OPC to access the CAEN power supplies feeding power to the Preshowers and High Voltage (HV) power to the EE and EB. The first step towards the migration of the OPC has been the massive reconfiguration of the address space for every component.
Conclusion During this long shutdown of the LHC, the ECAL DCS has been brought up to date to use some of the latest versions of the control platform, software frameworks, drivers and utilities. All code sources have been reviewed and thoroughly modified to accommodate to the new context. All code sources and their history along the past 12 years have been ported to the CERN Gitlab instance, a more modern and powerful version control system. The different code transformations imposed by the WinCCOA and JCOP migrations have been planned and organized to minimize the code-freezing period during the transition between versions. Decisions such as maintaining the ASCII backwards compatibility or the explicit inclusion of libraries have allowed partial deployments in the legacy systems, while continuing developing other features.
Numerical trajectory simulations In order to model the particle dynamics within the entire decelerator and characterize its deceleration performance, a numerical trajectory simulation code in the Python programming language was developed. In the simulation, 10 5 OH molecules were initialised and their trajectories through the decelerator were calculated under different operating conditions. The forces F i acting on each particle i along its trajectory x i (t)) were obtained from its Zeeman energy W i according to F i (x i (t)) = -∇W i (x i (t)). The Zeeman energy level structure of OH  [48]  in its X 2 Π 3/2 , v = 0 ground electronic and vibrational state in a ) OH e f J = 3/2 M J 3/2 1/2 -1/2 -3/2 Figure 8. The Zeeman effect of OH in its ground rovibronic state, X 2 Π 3/2 , v = 0, J = 3/2, as a function of magnetic field strength B.
The molecules were initially generated within a cylinder with a radius of 2 mm and a length of = 11 mm, which mimics the initial spatial distribution of our experimental molecular beam  [49] , with a transversal velocity spread of 45 m/s and a longitudinal velocity spread of 90 m/s. The mean forward velocity was initially chosen to be 450 m/s in line with our experiments  [45]. Thus, the particles fill an initial 6-dimensional phasespace volume of 0. 5 × 10 8 mm 3 (m/s) 3. Due to the time-dependence of the currents and complex structure of the wire geometry, the magnetic fields could not be fully calculated prior to a simulation run and were thus calculated on the fly. In order to reduce the computation time, the calculations were GPU-accelerated using the NumbaCUDA library in Python  [50].
With the present diaphragm diameter of 4 mm, when injecting He gas in the first trap, the pressure upstream the magnet measured by the gauge can be increased up to about 5 × 10 -6 mbar without degrading the vacuum downstream the Penning-trap setup. Monte Carlo simulations using the Molflow+ software  [46]  have been performed to estimate the pressure inside the first trap cavity when He gas is injected, under the assumption of being in a molecular regime. A factor of 12 between the pressure measured by the gauge and the pressure inside the trap has been determined.
5 mm step) for both horizontal and vertical planes  [48]. Equipped with high-sensitivity charge preamplifiers, these semi-interceptive BPM are used to monitor down to a few tens of pA ion beams with a transparency higher than 90%. Ion bunches generated by the GPIB can be detected by the FC, coupled to a fast commercial I/V converter (FEMTO DHPCA-100). This detection system can be used only for high-intensity bunches (>10 4 particles in a 1 μs bunch), the lower ion number limit strongly depending on the time distribution of the bunch. The voltage image of the bunch intensity is digitized with a Red Pitaya board, which is also controlling the amplifier using digital I/O (switchable gain from 10 2 to 10 8 V/A). The Red Pitaya board is a cost-efficient data acquisition platform based on a Xilinx FPGA and a dual-core ARM processor running a Linux operating system.
Trap electronics In order to meet the DESIR High Voltage-Power Supplies (HV-PS) requirements, ISEG multichannel crates are used for providing the DC voltages to the DESIR instruments. The reasons of such a choice are (i) the large variety of low-noise, precise and stable HV-PS proposed, (ii) its ability to concentrate a large number of HV channels in a single crate, and (iii) the CC-24 ISEG crate controller with its built-in EPICS server (see Section 4. 5). A SPIRAL2-like EPICS records database is developed and used on all DESIR ISEG crates. The PIPERADE electronics stands in a dedicated 19'' rack placed on a 29. 95 kV platform and require 75 HV-PS, all with negative polarity. The DC signals for the trap electrodes and the diaphragm are provided by 0-500V high-precision supplies (ISEG EHS-F205N).
Control system Control System (CS) developments performed at CENBG for DESIR are based on the Experimental Physics and Industrial Control System (EPICS) architecture  [50] , being the basic framework for the SPI-RAL2 control system  [51]. PIPERADE is therefore also fully remotely controlled under EPICS. This system is based on Clients (Operator Interfaces) and Servers (Input Output Controllers IOC) communicating together via shared Process Variables (PVs) on an Ethernet Network using a dedicated communication protocol named Channel Access (CA). Most of the PIPERADE electronics is embedded on a high-voltage platform. Therefore, fiber optics coupled to Ethernet switches ensure galvanic insulation and TCP communication of the equipment with the EPICS IOCs running on a CentOS Linux PC. Some IOCs are embedded into the equipment: this is the case for the ISEG HV multichannel crate (ISEG CC24 Controller) and the Red Pitaya used for beam intensity, ion counting and time-of-flight (RedPiTOF) measurements.
SPIRAL2 vacuum systems and interlocks are controlled using dedicated PLCs (Siemens S7-1500). The Profibus Fieldbus is used by the vacuum PLC to communicate with turbo-molecular pumps and Profinet (Profibus on Ethernet Network) is deployed to manage Input-Ouput terminal modules (ET 200S) distributed along the beam line and on the high-voltage platforms. Each PLC has its own HMI (Human Machine Interface) on a dedicated Touch Panel. Shared software development tools are used such as the SPIRAL2 version of CSS/BOY (CSS-Dev) used to build most of the Graphical User Interfaces (GUIs) and will handle central services like the data archiver or the alarm handler system in the near future. EPICS with its CA protocol makes possible to monitor and control any beam line equipment through its PVs in many programming languages.
Acknowledgments The authors would like to thank the  JYFLTRAP team for providing the PyMassScanner program , and in particular  T. Eronen  for all the fruitful discussions. Contributions from  H. Guérin ,  M. Aouadi ,  P. Dupré  and  S. Stahl  are gratefully acknowledged. The authors also thank the MPIK mechanical workshop and design office, as well as the CENBG mechanical workshop. The  PIPERADE  project was supported by  Agence Nationale de la Recherche ,  France  ( ANR-2011-BS04-020-02  and  ANR-11-EQPX-0012 ) and the  Max Planck Society, Germany.
Most public blockchain protocols, including the popular Bitcoin and Ethereum blockchains, do not formally specify the order in which miners should select transactions from the pool of pending (or uncommitted) transactions for inclusion in the blockchain. Over the years, informal conventions or "norms" for transaction ordering have, however, emerged via the use of shared software by miners, e. g. , the GetBlockTemplate (GBT) mining protocol in Bitcoin Core. Today, a widely held view is that Bitcoin miners prioritize transactions based on their offered "transaction fee-per-byte. " Bitcoin users are, consequently, encouraged to increase the fees to accelerate the commitment of their transactions, particularly during periods of congestion. In this paper, we audit the Bitcoin blockchain and present statistically significant evidence of mining pools deviating from the norms to accelerate the commitment of transactions for which they have (i) a selfish or vested interest, or (ii) received dark-fee payments via opaque (non-public) side-channels.
Worse, some transactions may be conflicting, meaning at most one of the transactions can be included in the blockchain; for such transactions, the order in which a miner chooses to include transactions will determine the ultimate state of the system. The conventional wisdom today is that many miners follow the prioritization norms, implicitly, by using widely shared blockchain software like the Bitcoin Core  [9, 16]. Then, in Bitcoin, the presumed "norm" is that miners prioritize a transaction for inclusion based on its offered fee-rate or fee-per-byte, which is the transaction's fee divided by the transaction's size in bytes. We show evidence of this presumed norm in Figure  1. The norm is also justified as "incentive compatible" because miners wanting to maximize their rewards, i. e. , fees collected from all transactions packed into a size-limited block, would be incentivized to include preferentially transactions with higher fee-rates.
Transaction prioritization norms A crucial detail absent in the design of a proof-of-work blockchain per  [49]  is any notion of a formal specification of transaction prioritization. Said differently, Nakamoto's design does not formally specify how miners should select a set of candidate transactions for confirmation from all available unconfirmed transactions. Notwithstanding this shortcoming, "norms" have originated from miners' use of a shared software implementation: Miners predominantly use the Bitcoin Core  [9]  software for communicating with their peers (e. g. , to advertise blocks and learn about new unconfirmed transactions) and reaching a consensus regarding the chain. Of particular note in the popular Bitcoin core's implementation is the GetBlockTemplate (GBT) mining protocol, implemented by the Bitcoin community around February 2012.
DATA SETS To understand the importance of transaction ordering to users and to investigate when and how miners violate the transaction prioritization "norms, " we resort to an empirical, data-driven approach. Below, we briefly describe three different data sets that we curated from Bitcoin and highlight how we use the data sets in different analyses in the rest of the paper. Data set A. To check miners' compliance to prioritization norms in Bitcoin, we analyzed all transactions and blocks issued in Bitcoin over a three-week time frame from February 20 through March 13, 2019 (see Table  1 ). We obtained the data by running a full node, a Bitcoin software that performs nearly all operations of a miner (e. g. , receiving broadcasts of transactions and blocks, validating the data, and re-broadcasting them to peers) with the exception of mining.
The top five MPOs are BTC. com (: 889; ℎ: 19. 67%), AntPool (: 577; ℎ: 12. 77%), F2Pool (: 523; ℎ: 11. 57%), SlushPool (: 438; ℎ: 9. 69%), and Poolin (: 433; ℎ: 9. 58%). As in the case of A, we use this data set in §4. Data set C. The insights derived from the above data motivated us to shed light on the aberrant behavior of mining pool operators (MPOs). To this end, we gathered all (53,214) Bitcoin blocks mined and their 112,542,268 transactions from Jan. 1 st to Dec. 31 st 2020. These blocks also contain one Coinbase transaction per block, which the MPO creates to receive the block and the fee rewards. This data set, labeled C, contains 112,489,054 issued transactions (see Table  1 ). MPOs typically include a signature or marker in the Coinbase transaction, probably to claim their ownership of the block.
These observations also hold in data set B, the details of which are in §A. The Mempool congestion, which in turns leads to the contention among transactions for inclusion in a block, has one serious implication for users: delays in transaction-commit times. While 65% (60%) of all transactions in data set A (B) get committed in the next block (i. e. , in the block immediately following their arrival in the Mempool), Figure  4a  shows that nearly 15% (20%) of them wait for at least 3 blocks (i. e. , 30 minutes on average). Moreover, 5% (10%) of the transactions wait for 10 or more blocks, or 100 minutes on average, in data set A (B). While no transaction waited for more than a day in data set A, a small percentage of transactions waited for up to five days (because of the high levels of congestion in June 2019) in data set B.
ACKNOWLEDGMENTS K. P. Gummadi  acknowledges support from the  European Research Council (ERC) Advanced Grant "Foundations for Fair Social Computing , " funded under the European Union's  Horizon 2020 Framework Programme  (grant agreement no. 789373 ). P. Loiseau was supported by  MIAI @ Grenoble Alpes  ( ANR-19-P3IA-0003 ) and by the  French National Research Agency  through grant  ANR-20-CE23-0007. A. Mislove  acknowledges support from  NSF  grants  CNS-1900879  and  CNS-1955227. J. Messias  dedicates this work to his late father,  Jota Missias  [32].
General Introduction Anomaly-based intrusion detection systems are either supervised or unsupervised  [99]. In supervised methods, training data are labeled "normal" or "abnormal" by the domain expert and the system is trained to discriminate between "normal" or "abnormal" observations, so that new observations could be classify to "normal" or "abnormal" classes. In unsupervised approaches there is no labeled data. A baseline distribution of "normal" behaviors is modeled, so that the system could detect observations that show significant difference from the "normal" ones  [99]   [157]. But the labeling of huge datasets by human experts is costly, time consuming and error-prone. Deep learning techniques can use unsupervised strategies to automatically learn hierarchical representations in deep architectures for classification purpose  [20]  [59]  [92]  [97]  [104]  [105]  [113]  [130]  [132].
The second sub-question is : RQ 1. 2 : What are the characteristics of the SCADA dataset used ? The answer to this question will help us have a clear understanding of the SCADA dataset used i. e. the nature of the records and the different types of attacks it contains. The last sub-question is : RQ 1. 3 : How can we design a deep learning based unsupervised feature learning framework that will learn important features from SCADA data ? To answer this question, we will show the process of designing a deep neural network for unsupervised feature learning in SCADA systems, i. e, how to determine the parameters, the activation functions of the layers, the loss function to be used, the various hyper-parameters such as the learning rate, batch size, regularization, etc. , and the training method of the model.
Components of a SCADA system A typical SCADA system (Figure  1. 1) has three parts that are the control center, the communication links and one or more distributed field sites  [145]. The control center is the part of a SCADA network where the Master Terminal Unit (MTU) also called SCADA server, the engineering workstations, the Human Machine Interfaces (HMIs), and the data historian are located. The Master Terminal Unit (MTU) is the key component of the control center. It is used to store and 1. 2. SCADA Systems Architecture process information from the Remote Terminal Units (RTUs). The monitoring and control of the entire SCADA network is done by human operators thanks to the HMIs, while the engineering workstations are used by engineers for maintenance and configuration purpose. Finally, all the information collected on the SCADA networks are store on a database called the data historian for further processing.