dataesr/scientific-paragraphs-categorization huggingface dataset:
REST-for-Physics defines a framework, or code development space, that centralizes event processing and analysis routines. These routines contributed by the same experts that work on the analysis of the data. The REST community keeps a strong link between algorithm design and the framework design, since there is an implicit connection between the algorithm development, analysis interpretation, and framework design requirements. REST provides already existing processes that can be used directly to define a given event processing task. REST has been designed to provide the means to be extended with new processes, metadata or event data types. The development of REST emerges in a strong academical environment. In such context, REST intents to provide the means for academic works to materialize in the form of a piece of code that can be re-used within an already consolidated software infrastructure.
The framework philosophy is to create specific metadata classes with dedicated data members to store any information crucial for the final analysis, and/or to fully determine the nature of the data being stored. All the metadata inherited objects gain data member reflection support, thus creating a relation between the C++ conceptual class members and the text fields used in the configuration files. Through the implementation of the metadata object, a dedicated configuration file format for REST has been designed, based on Extensible Markup Language (XML). This upgrade allows the reading of XML files with additional features, such as system environment variables, complex programming instructions, including if conditions or loops, evaluation of mathematical expressions or even support for arbitrary physical units conversion inside any parameter.
The data is then processed using the implementation inside the process runner object. Different event types (A,B,C,D) make reference to different specific event implementations. The resulting output REST file will contain all the metadata information available to the chain, including any previously available, together with the transformed output specific event, and the updated analysis tree. event processes at the processing chain: i. e. one may use a ROOT browser to explore the REST data files, and quickly draw and inspect variables from the analysis tree (as shown previously in Figure  4 ). Furthermore, REST implements dedicated tools for automatic and systematic plot generation, such as the analysis plot or the metadata plot classes. The analysis plot will efficiently integrate the capability to merge thousands of files through an rml file in which the desired plots will be assembled using the combined datasets.
restManager allows the definition of all those actions through a configurable rml file. The manager class, executed through the restManager executable, guarantees that the event data processing flow follows the standards previously described in Figure  5. A bash script, rest-config, is generated at each project compilation to provide information on the configuration of a particular build and to facilitate the linking of REST with external applications. It is important to remark that once REST has been compiled with a particular version of ROOT, Geant4 or Garfield++, that compilation of REST must only be used with those versions. The shell script thisREST. sh will be responsible to load the ROOT, Geant4, Garfield++, or any other packages required, so that they match the correct versions used to compile REST at runtime.
Project structure, versioning and code validation The main framework defines the basic functions, and describes the behavior of the main elements of REST. As previously mentioned, it also serves to centralize all the REST-for-Physics components, such as packages or libraries, and eventually dedicated projects. We have adopted a git submodule 4  strategy to integrate those components in a modular way inside the main framework repository. This scheme allows to independently monitor the development activity at each of those components, to isolate technical issues, and to focus on their functionality. Each component evolves independently with its own version or tracking system. A particular state of the code at each of those components is fixed at the main framework through a git commit hash, or a unique number.
When that happens, the corresponding git commit becomes the official component version of REST. The framework repository fully centralizes the versioning system of REST, understood as the state of the code at a given period of time, including the state of the official git submodules attached to it. Any REST metadata object written to disk using the ROOT I/O scheme will be stamped with metadata values (e. g. the REST release number, latest commit hash, release date, etc) that ensure that the data written to disk has been processed with a given version, or state of the code. In order to certify that, two of those metadata members will be initialized at the code compilation time. The first metadata member will guarantee the source code was built from a clean, unmodified state with respect to the git remote repository, and the second metadata member will certify that the corresponding framework code state is associated with an official git tag release, where each git tag generated at the main framework repository will automatically produce a code release referenced and citable at the Zenodo system  [1].
On top of that versioning strategy, it is important to mention that REST properly implements the ROOT schema evolution and ensures backwards compatibility for objects that have suffered changes in their data members. To ensure the code quality and stability with time, each repository integrates a validation pipeline where basic tests on the code are performed: some examples are code formatting and style validation, testing the proper libraries integration and building of executable programs or, even more important, testing basic results from complex data processing chains (see Figure  9 ). Each modification to the code, or git commit, will be verified by running those validation pipelines. If a modification to the code produces an unexpected value on a consolidated data processing routine, the contributor will be notified, and changes will only become official after peer reviewing the code.
It is important to mention that this library is not directly linked to the official Geant4 libraries. Its purpose is to store the event information generated by a Geant4 simulation, but once a simulation package has registered the information inside the geant4 event data holder, the connection to Geant4 libraries is not required anymore. Therefore, a user would be able to access a Monte Carlo database of previously Geant4-generated files in REST format without the need to perform a system Geant4 installation. Inside the REST-for-Physics ecosystem we have developed an independent package, restG4  [37] , which is a particular Geant4 code implementation taking advantage of the geant4 event type and all the definitions available at the library to describe the simulation conditions. For example, the geant4 metadata class defines the number of primaries to be generated, together with their energy and angular distributions, or the generator type, in order to determine how the primaries will be launched or initialized.
There are many other options that allow to produce datasets in different experimental conditions and apply specific storage instructions. The library implements another relevant metadata object, the geant4 physics list, in which the particle physics processes to be considered in the simulation can be customized. restG4 will register those metadata structures and the geant4 event tree, together with a run metadata object complying with the REST data format conventions so that the resulting data are ready to be further processed with this or other libraries available in REST. A simulation with restG4 requires as input the description of those three objects, the run, the geant4 metadata and the geant4 physics list, through an rml file, and a description of the geometry through a GDML  [38]  file (see Figure  12 ).
Once a first Monte Carlo dataset has been generated using restG4 it can be processed using the existing routines in this library. These routines, or processes, can be used to extract the Monte Carlo truth at an early processing stage. One example is the blob analysis process, aiming to extract the real electron track-ends in a 0νββ event: another is the neutron tagging process allowing to produce elaborated observables (e. g. the mean position of energy deposits found at a particular volume in the geometry) to perform a detailed analysis of the interaction of neutrons with an active cosmic veto system. Therefore, some processes at this library introduce sophisticated physics models producing results that will be exported to the analysis tree in the form of observables, to be accessed at a later stage of data treatment.
The main idea, or philosophy, is that restG4 is simply used to generate a first dataset, while the geant4 library will be used to introduce models that need to know about the nature of the particles or the interactions that produced the energy deposits inside the detector geometry. Once all the relevant information has been extracted and placed in the form of observables in the analysis tree it can be migrated to other REST libraries (see section 4. 5) in order to include a detailed detector response, condition the data to mimic raw detector data, and perform the same data processing and analysis applied to real experimental data.
Summary In this work we have given a broad overview of the REST-for-Physics framework and components. Our aim was to provide the reader with a general idea of the philosophy, structure and organization of the software project. And, without entering into great detail, provide an overview of the present use and functionality of REST-for-Physics. The REST-for-Physics framework and libraries are a natural extension of ROOT, since the most basic elements inherit directly from TObject. The ROOT I/O serialization is exploited to manage the data storage while focusing on the development of physical processes that provide to REST its functionality. The motivation for this choice is the experience acquired with the ROOT framework, and the benefit of using the analysis tools it provides. ROOT was born already more than 25 years ago and it is still strongly supported and actively maintained by the CERN community which counts with thousands of users.
ROOT is exhaustively used in particle physics today, and its continuity in the long term seems to be guaranteed by CERN. The REST-for-Physics framework fully exploits the schema evolution from ROOT in order to minimize the impact on data member changes in specific event or metadata objects, thus making files written with REST to be backward-and forward-compatible. One of the key aspects of the REST-for-Physics code, crucial for the storage and processing of experimental data, is its versioning strategy that it was carefully described in this paper. Such versioning strategy provides a unique relation between the code and the registered data, ensuring data and code traceability, leading to reproducible results. One of the main motivations of the development of REST-for-Physics is to collect and centralize the software efforts and progress on detector physics for the construction of low-background detection technologies.
Acknowledgements We acknowledge support from the the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation programme , grant agreement  ERC-2017-AdG788781  (IAXO+), and from the  Spanish Agencia Estatal de Investigación  under grant  FPA2016-76978-C3-1-P. The  IRFU  group acknowledges support from the  Agence Nationale de la Recherche (France)   ANR-19-CE31-0024.
The project is a concrete example where the academic and the industrial sector are joining forces to develop and benchmark the tools that are required by the value chain of emerging quantum industry. Often, the initial market of tools for sufficiently advanced technologies is too small to be pursued by larger corporations, opening a niche-market opportunity for small and medium-sized enterprises (SME). This demand is satisfied by the industrial partner nextnano GmbH 7 -an SME based in Munich (Germany) with 12 employees and 300 customers in more than 35 countries -which develops a software tool calculating the quantum mechanical properties of semiconductor nanodevices. The synergy of academic and industrial partners on numeric simulations and experimental implementations within UltraFastNano fosters progress on electron flying qubits opening a novel branch of quantum industry.
The partitioning data shows a constantly high transfer efficiency despite the detuning of the TCW potential. The shape   [31]  of the partitioning data bears important information on the time-evolution of the flying quantum state that is of central importance for quantum applications. To draw the right conclusions from the single-shot partitioning data, numerical simulations are essential. In the presently discussed example, time-dependent simulations of the electron's propagation through the TCW region, revealed charge excitation -as schematically shown via the potential landscapes shown in Fig. 2d  -due to insufficient SAW confinement. In these calculations, the stationary potential is calculated with the nextnano software based on the true sample geometry and the electric properties of the heterostructure.
The self-consistent potential can be used by quantum solvers to calculate the quantum transport properties of the device, e. g. the conductance or the current noise or other observables. Those properties can be directly compared to DC experimental measurements to obtain a direct feedback on the quality of the modelling and its calibration. The proprietary nextnano  [142]  platform or the open-source KWANT software  [143]  are complementary tools that can be used for this stage. Once the static properties are well understood, one can proceed to simulate the propagation of the electron flying qubits, including voltage pulses and the associated Levitons, in real time. The TKWANT extension  [144]  of KWANT provides the necessary environment for such simulations (e. g. , to study the role of Coulomb repulsion at the time-dependent mean field level).
Since the basic elements of the electron flying qubits (interconnects, TCWs and interferometers) are exploiting to a great extent single-particle physics, they require highquality quantum mechanical simulations for one electron in complicated electrostatic potentials. The necessary information is obtained from a numerical solution of the stationary Schrödinger equation, see Eq. (  4 ) below. The precise solution can be found by using a platform such as the nextnano software. Its advantages include the possibility to adapt the numerical procedure for different materials, various geometries of the nanoconductors and shapes of the gate-induced potentials. Let us review the basics of the static quantum mechanical simulations, some features of the nextnano tools, and provide examples of how these tools can be used for calibration of the experiments and engineering the nanodevices.
The nextnano software and its applications for engineering flying qubits Starting from the year 2000, the nextnano software had been developed at the Walter Schottky Institute of the Technische Universität München. Later, it resulted in the spin-off company nextnano GmbH. The software, which is now further developed by this company, is a user-oriented platform meant for modelling various semiconductorbased nanodevices, cf. Refs. [142, 154, 155] , including optoelectronic elements and qubits. The main focus is on the simulation of the quantum mechanical properties of such devices. The nextnano's core product, the nextnano++ software  [142] , is a 3D Schrödinger-Poisson-Current/CBR solver for nanotransistors, LEDs, laser diodes, photodetectors, quantum dots, nanowires, solar cells and qubits.
The second product, nextnano. NEGF  [152] , is a quantum transport solver targeting quantum cascade lasers and resonant tunneling diodes. The nextnano software (including its early versions) has been successfully used to optimise the design of semiconductor-based (charge and spin) qubits  [156] [157] [158] [159] [160] [161]. Below, we focus on several important applications of this software for engineering the electron flying qubits. Appropriate models for quantitative simulations: Quantum devices made from GaAs semiconductor heterostructures can easily be engineered by proper design of the gate geometry. To ensure the best performance of the electronic device -that is to find the most suitable gate geometry -it is crucial to know the exact electrostatic potential landscape generated by the electrostatic gates.
This requires to take into account the material parameters such as 2DEG density and mobility, dopants concentration, induced surface charges, etc. Traditionally, the workflow to determine the optimum gate geometries for a given heterostructure has been an iterative process between device fabrication in clean room facilities and low-temperature characterisations. This is immensely time consuming and resource demanding. The ideal workflow is presented in Fig. 9  where the iterative process takes place mainly at the modelling stage, before the device fabrication. To find an accurate model for quantitative simulations, Chatzikyriakou et al. [162]  developed a model using the nextnano software and benchmarked it with experimentally measured QPCs with a wide range of geometries. They assumed a layer of surface charges and a spatially uniform doping concentration, both having a frozen ionization state due to the very low temperatures at which the experimental measurements are taken  [31, 163].
2 K (frozen surface states). To simulate the region where electron transport takes place, 3D simulations are carried out with the exact gate geometry of the quantum device. These gate geometries are directly imported from the computer-aided design (CAD) layouts (standard files in GDS format) using the open-source Python package nextnanopy  [164]. Figure  10  shows a typical example of electron depletion in the 2DEG when applying a gate voltage to the electrostatic gates that face each other. When a small negative voltage is applied, the electron density under the gates is first depleted, forming only a narrow 1D constriction in the center of the two gates. Reducing further the voltage, the 1D channel is completely depleted and the transport channel is pinched-off. The simulation shows a remarkable agreement with the experimental pinch-off value (V G = -1.
Namely, one needs an experimental setup where, on one hand, the reflection is reduced to a minimum and, on the other hand, the sensitivity of the electron state to the respective gate voltages is high. Let us explain how using the nextnano software helps to find such a setup. To this end, nextnano enables the calculation of the pLDoS and the transmission of the nanodevices using the CBR method  [149, 153]. In the following, we demonstrate such calculation via two cases that are the central building blocks of the electron-flying-qubit architecture. Firstly (see left columns of Fig. 12  and Fig. 13 ), we address electron propagation through a tunnel-coupled wire (TCW). We remind readers that here at y = 0 a narrow potential barrier is present between two transport channels that allows for coherent tunneling of the electron.
The potential profile of both models is shown in Fig. 13a, d. For such study of a nanoscale device, materials properties have to be specified in the nextnano input file such that the potential energies are properly set. We have used GaAs for the device and leads, and adjusted the potential energy in different regions representing high insulating barriers (red lines), tunneling barriers (light blue lines), and gates (green regions). The potential energy at the gates can be tuned by applying gate voltages and the strengths of the barriers are given in Fig. 13  and its caption. Several examples of the pLDoS are shown in Fig. 12  which have been generated using the nextnano software. In these simulations, the electron has been injected into lead no. 1 with a given energy that is E = 9. 2 meV for TCW and E = 7.
The south pole of the Bloch sphere is reached in Fig. 12j  despite a substantial blockage of the lower transport path by the strong gate potential of the side gate. To conclude the discussion of the pLDoS, we note that a detailed analysis of the flying qubit geometry in relation with experiments has also been performed using a combination of the theoretical approach and the KWANT software, see Ref. [145]. Having discussed electron propagation at a qualitative level via the pLDoS, let us now investigate electron propagation in a more quantitative way employing energy dependent transmission, T ij (E) from the first lead to the output leads no. 3 and no. 4. First, we study the dependence on the injection energy (Fig. 13b, e ). The energy of the incoming electron is counted from the potential energy of the lead no.
These theoretical developments are very much on-going research for which no standard approaches have yet emerged. As in-depth discussion of these aspects goes beyond the scope of the present review, we refer to Ref. [7]  for pointers to the literature or to Ref. [166]  for an introduction to the non-interacting formalism and to Ref. [144]  for illustrative time-dependent simulations of the propagation of voltage pulses, in particular in the quantum Hall regime  [167]. These methods have not been included into the nextnano software, however, TKWANT, the time-dependent extension of the KWANT software is able to provide an appropriate platform which is complementary to the nextnano one. Both KWANT and TKWANT software packages are distributed under the BSD license which imposes minimal restrictions on the use and distribution of this software.
Consequently, algorithms developed by the KWANT team could be incorporated into commercial software packages targeting specific quantum industry applications, such as electron-flying-qubit devices. The principal developers of KWANT are from CEA Grenoble and TU Delft. Note that there are no general purpose simulation approaches that can handle manybody problems in an exact and systematic way except in very particular cases. Most approaches rely on some approximation scheme whose validity must be checked a posteriori. A promising route followed by some of us to design a systematic method with a controlled accuracy uses calculations of high order processes (i. e. processes where electrons interact strongly) made possible by the use of a machine learning approach to evaluate the corresponding high dimensional integrals  [168].
Funding We acknowledge funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 862683 (UltraFastNano). EC acknowledges funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 840550 (PRESQUE). JW acknowledges funding from the European Union's Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No. 754303 (GreQuE). CB, DCG and XW acknowledge funding from the French National Funding Agency (ANR) through project ANR-16-CE30-0015-02 (FullyQuantum). CB and GG acknowledge funding from the French National Funding Agency (ANR) through project ANR-19-CE47-0005 (STEPforQUBITS).
The AROME NWC initial conditions are provided by a three-dimensional variational (3D-Var) data assimilation of observations available within a 20 minutes windows centered on the analysis time, each hour. The observations are primarily radar (reflectivity and radial velocity) data, screen level measurements, and to a lesser extent, aircraft, sounding and satellite data. Arome-NWC is run every hour and provides short-range forecasts up to 6 hours with a time step of 15 minutes on a domain covering France and adjacent areas. Forecasts were available within 35 minutes at the time of the study.