dataesr/scientific-paragraphs-categorization huggingface dataset:
, 2015). Finally, the AX22 XBT data are also assimilated into the Southern Ocean State Estimate (SOSE) and used to test ocean and coupled climate models  (Jiang et al. , 2014). XBT data have detected warming trends in the Southern Ocean and revealed details regarding processes that could lead to warming. In the Antarctic Zone, data from the IX28 and AX22 transects show that Antarctic Surface Water and Upper Circumpolar Deep Waters have warmed over the past several decades  (Morrow et al. , 2008; Sprintall, 2008)  and that the cold Winter Water tongue has become warmer, thinner, and shallower. In the South African sector, warming anomalies observed using XBT data have reached values as large as 1 • C in the Ekman layer that are linked with changes in the wind field that could potentially provide a source for the overall ACC warming.
Mediterranean Sea The MX04 XBT transect (Genoa to Palermo) has been sampling upper ocean variability in the Tyrrhenian Sea and the northeastern Ligurian Sea since September 1999. To date, about 90 transects have been completed, resulting in over 3,000 profiles. This XBT transect is nearly coincident with one altimetric track, allowing a combination of XBT, and remotely sensed sea surface height anomaly data to estimate the geostrophic circulation  (Vignudelli et al. , 2003; Ciuffardi et al. , 2016; Napolitano et al. , 2018). The Tyrrhenian Sea is an area where the mixing of the waters coming from the eastern and western Mediterranean occurs, while the formation of dense winter waters takes place in the Ligurian Sea. XBT temperature profiles have shown a warming that could be linked to the anomalous 2003 summer (an unusually long, hot, and dry season in the southern Europe).
A distinguishable seasonal cycle was, however, found for the geostrophic and Ekman heat transports, which have similar amplitudes but are close to 180 • out-of-phase. Consequently, this explains the small amplitude of the seasonal cycle in the total northward MHT and MOC  (Dong et al. , 2009 (Dong et al. , , 2011)). Statistical analyses of the MOC and MHT in this region using XBT data indicate that they are significantly correlated. Results from this transect also provide a ground truth for evaluating numerical models and methodologies to estimate the MOC using other data sources. Current generation climate models are unable to reproduce the seasonal variations in the geostrophic transports; subsequently, the model MOC and MHT seasonal evolution is controlled largely by Ekman transport  (Dong et al.
, 2014). A detailed analysis of XBT observations show that the weak seasonal cycle in geostrophic transport from Coupled Model Intercomparison Project Phase 5 (CMIP5) Models [National Center for Atmospheric Research Community Climate System Model (NCAR-CCSM4) and the Geophysical Fluid Dynamics Laboratory Earth System Model (GFDL-ESM2M)] is due to poor representation of the boundary currents and vertical stratification. Some XBT transects are currently being assessed using Observing System Experiments (OSEs) to determine the best strategy for monitoring currents and mass and heat transports. For example, AX18 was assessed using the HYbrid Coordinate Ocean Model (HYCOM)/Navy Coupled Ocean Data Assimilation (NCODA) eddy resolving analysis  (Goes et al. , 2015a). Results showed that horizontal resolution finer than 25 km is required to resolve boundary currents, that at least 15 years of quarterly sampling is needed to resolve the seasonal cycle of the MOC, and that altimetric sea level height can be used to infer the barotropic mode.
, 2014). However, the uncertainties in models are much larger than in the observations, indicating that observational OHC records, including those that use XBT observations, remain a critical metric for model evaluation. The subsurface temperature data in the western North Atlantic Ocean can be used to investigate variations in the    Cheng and Zhu, 2016 and Cheng et al. , 2017). The data used to generate this figure is from gridded ocean temperature analysis in  Cheng et al. (2017) , and this analysis is based on all available in situ ocean subsurface temperature observations (including XBT data) from World Ocean Database  (Boyer et al. , 2013). upper OHC and to assess the contributions from surface heat fluxes and oceanic processes  (Dong et al. , 2007a). A heat budget study in a region bounded by the XBT transects AX07, AX08, AX10, and the Gulf Stream  (Dong et al.
Operational Oceanography and Ocean Forecasts In the context of operational oceanography, XBTs are widely used among international centers that run Ocean Forecasting Systems (OFSs). Tonani et al. (2015) , in a revision of the status and future of global and regional ocean prediction systems, provided a geographic distribution of the centers that developed OFSs under the Global Ocean Data Assimilation Experiment (GODAE) and GODAE OceanView initiatives. The configuration of OFSs is quite variable in terms of horizontal and vertical resolution, the base model adopted, and data assimilation. While some of the systems are limited to a specific geographic region (e. g. , the Oceanographic Modeling and Observation Network, REMO configuration focuses only on the South Atlantic Ocean), 12 of these OFSs are global systems.
A common ground for these systems is the use of vertical profiles of temperature and salinity from different platforms (e. g. , ship-based CTD, XBT, Argo, gliders, and drifters) in their data assimilation schemes. Martin et al. (2015)  presented a more detailed description of seven of these systems, which assimilate XBT data in near real-time. In terms of representativeness and impact, vertical profiles of temperature that are obtained from different observational platforms are being evaluated in a complementary manner. In an assessment of the current status of the real-time in situ GOOS for operational oceanography,  Legler et al. (2015)  argued that XBT transects provide a very different view of the global ocean to that of Argo floats. XBT deployments sample along wellobserved transects, at either large or small spatial scales or at special locations such as boundary currents and chokepoints, all of which are complementary to the global Argo broad scale array.
The impact of XBT data on improving OFSs can be assessed by OSEs. In a near real-time OSE using the UK Met Office's operational OFSs-Forecasting Ocean Assimilation Model where XBT data were not assimilated,  Oke et al. (2015a)  found that although XBT data did not significantly impact global metrics, they did have significant local impacts. On a global scale, suppression of XBT data resulted in a mean (maximum) temperature difference of ∼0. 04 • C (5. 42 • C), which compares to a difference of 0. 27 • C (10. 53 • C) in the case of suppressing Argo data. Moreover,  Oke et al. (2015a)  argued that, although XBT data represented a small component of the GOOS, their impact in the vicinity of the XBT transects was significant. Suppression of XBT data resulted in a marked degradation of the forecast system.
(Bailey et al. , 1994; Thadathil et al. , 2001). Once the profile QC phase is complete, all profiles approved during this process are encoded into FM 63-XI Ext. BATHY (the traditional alphanumeric code for reporting temperature profiles) and/or BUFR (Binary Universal Form for the Representation of meteorological data) bulletins and submitted to the GTS for worldwide distribution in near realtime. The GTS is a core component of WMO's World Weather Watch Programme and contributes to the rapid collection and distribution of satellite, in situ, and other processed datasets  (WMO, 2015b). The collection and distribution of XBT data is routinely performed through GTS centers in the United States, Australia, Japan, France, Canada, and Brazil. The centers in the first four countries also disseminate the profile data and associated metadata in BUFR format.
All time series are displayed after applying a 1-year low pass filter. generate reports, detect anomalies and data gaps, and analyze the performance and latency of the data collection and distribution system. The data originators retain the original and delayedmode QC profiles and intermediate products. XBT data posted to the GTS in near real-time are collected by the Marine Environmental Data Section (MEDS) of the Oceans Science Branch, Fisheries and Oceans in Canada, along with other ocean temperature profile data, and relayed as a package every 3 days to the National Oceanic and Atmospheric Administration (NOAA) National Centers for Environmental Information (NCEI) in the US. NCEI hosts the long-term archive center of GTSPP and preserves XBT data in the GTSPP Continuously Maintained Database (CMD).
The delayed-mode profiles (those that are either not posted to the GTS or are full resolution or are fully quality controlled replacements for the GTS versions) are sent to NOAA/NCEI for inclusion in the GTSPP, from where they are disseminated and enter other global data sets such as the NOAA/World Ocean Database, thus becoming part of the data flow of the JCOMM Marine Climate Data System. Every other year, the data centers and XBT providers gather under the auspices of GTSPP to discuss potential improvements to quality control and global dissemination of XBT data.
ACKNOWLEDGMENTS The authors acknowledge the many agencies and institutions that support the implementation and maintenance of the  Global XBT Network , and data management and research activities, including but not limited to:  NOAA (United States ),  National Science Foundation  ( United States ),  Commonwealth Scientific and Industrial Research Organization (CSIRO) ,  Bureau of Meteorology (BOM) ,  Integrated Marine Observing System (IMOS) , a national collaborative research infrastructure supported by the  Australian government (Australia) ,  National Agency for New Technologies, Energy and Sustainable Economic Development (ENEA) (Italy) ,  Tohoku University (Japan) ,  University of Miami  ( United States), University of Tasmania (Australia), Scripps Institution of Oceanography (United States ),  National Institute of Water and Atmospheric Research (New Zealand), Laboratoire d'Etudes en Géophysique et Océanographie Spatiales (LEGOS) (France), Institute of Atmospheric Physics and Chinese Academy of Sciences (China) ,  University of Rhode Island  ( United States ),  BIO (Bermuda) ,  University of Cape Town  ( South Africa ),  Federal University of Rio Grande do Sul (Brazil) ,  Federal University of Rio de Janeiro (Brazil) ,  University of Paris (France) ,  National Institute of Oceanography (India) ,  MEDS (Canada) ,  Servicio de Hidrografía Naval (Argentina), Servicio de Hidrografía Naval (Brazil), State University of New York at Stony Brook (United States) ,  Indian National Centre for Ocean Information Services (India) , and the  Woods Hole Oceanographic Institution (United States ).
FUNDING GG, FB, SD, UR, MB, RD, and DV were supported by a grant from the  NOAA/Ocean Observing and Monitoring Division (OOMD)  and by  NOAA's Atlantic Oceanographic and Meteorological Laboratory (AOML). The participation of JS and NZ in this study was supported by  NOAA's Global Ocean Monitoring and Observing Program  through Award  NA15OAR4320071  and  NSF  Award  1542902. CD was funded by the  Australian Research Council  ( FT130101532  and  DP160103130 ); the  Scientific Committee on Oceanic Research (SCOR)  Working Group 148, funded by national SCOR committees and a grant to SCOR from the  U. S. National Science Foundation  (Grant  OCE-1546580 ); and the  Intergovernmental Oceanographic Commission of UNESCO/International Oceanographic Data and Information Exchange (IOC/IODE) IQuOD Steering Group.
A : The data acquisition software framework, EUDAQ, was originally developed to read out data from the EUDET-type pixel telescopes. This was successfully used in many test beam campaigns in which an external position and time reference were required. The software has recently undergone a significant upgrade, EUDAQ2, which is a generic, modern and modular system for use by many different detector types, ranging from tracking detectors to calorimeters. EUDAQ2 is suited as an overarching software that links individual detector readout systems and simplifies the integration of multiple detectors. The framework itself supports several triggering and event building modes. This flexibility makes test beams with multiple detectors significantly easier and more efficient, as EUDAQ2 can adapt to the characteristics of each detector prototype during testing.
The accompanying data acquisition software, EU-DAQ  [2] , was originally developed to read out the data from the EUDET-type pixel telescopes and was therefore closely connected to its data acquisition (DAQ) architecture. During a decade of usage many user groups have integrated their DAQ system into EUDAQ and have successfully combined their data with the telescope data, based on common trigger IDs. Together with the EUT software package , a common pixel telescope data analysis framework, the EUDET-type pixel beam telescopes offer the whole infrastructure for detector development from the initial measurements to the final results. Furthermore the availability of these telescopes at the test beam facilities at CERN, DESY, ELSA(Bonn) and SLAC provided users the possibility to move their setup between test beams and use the same interface to the telescopes.
The recent development of EUDAQ2 provides a more flexible DAQ software framework for operating detector prototypes at test beams worldwide. The emerging need for running several detectors together with a telescope as a so-called system test is extending the use case way beyond the original conception of EUDAQ. Being a major upgrade to EUDAQ, EUDAQ2 has been completely rewritten using modern C++ and was designed to become even more versatile and usable for an extended range of detectors. The modular and cross-platform data acquisition framework serves as a flexible and simple-to-use data taking software for the EUDET-type pixel beam telescopes while allowing for the easy integration of many other detectors. EUDAQ2 is freely available  [3]  and distributed under the LGPLv3  [4]  open-source license.
EUDAQArchitecture EUDAQ2, like its predecessor EUDAQ, is implemented in C++, taking advantage of many of the powerful features provided by the C++11 standard  [5]. Compatibility across operating systems and compilers is one of the EUDAQ2 design principles, hence it only uses standard C++ language features and POSIX  [6]  system routines. Therefore, EUDAQ2 can run natively on Linux, MacOS and Windows. To build an EUDAQ2 system, different compilers such as GCC, LLVM/Clang and MS Visual C++ are supported. The build and installation processes are configured using CM  [7]. EUDAQ2 is a distributed DAQ framework with its communication protocol running on a custom TCP/IP stack. Figure  1  shows a schematic overview on the EUDAQ2 framework: Each component of EU-DAQ2 can run anywhere on the network on separate machines, entirely operating-system independent, and connect to each other using the EUDAQ2 data taking setup at run-time.
Integration with User code To keep the pure C++ EUDAQ2 core clearly separated from all user code, which may depend on non-standard libraries, the EUDAQ2 binary library is split into a core library and and optional module/extension libraries. Figure  4  shows this relation libraries with respect to the EUDAQ2 core library. A CM configure file to support user code integration against the EUDAQ2 core is supplied. EUDAQ2 is not compatible with EUDAQ, as the API has been changed and several interface methods have been deprecated. However, the migration to EUDAQ2 is straightforward and requires only minor changes in the user code, as the exception and error handling has changed. To avoid accidental misuse of EUDAQ user code in EUDAQ2, all interface functions have been renamed.
Modular Plugins Modular plugins are used to interact with the user hardware, the DAQ systems, or to adjust the EUDAQ2 core functionalities to meet certain user requirements. A typical EUDAQ2 modular plugin contains a Producer, a Data Collector and specific hardware code provided by the user. Optionally a modified Run Control can also be defined as a module. External libraries or specific dependencies of a module have to be handled by the user by adjusting the module's CM file. A shared library is created for each modular plugin at compile time. This library is loaded at the startup of EUDAQ2 run-time instances. EUDAQ2 takes advantage of the Object Oriented Programming (OOP)  [9]  capabilities of C++ to create objects like Producers and Data Collectors, which inherit from the base classes by method dispatching.
Using factories instead of constructors allows the usage of polymorphism for the object creation. There are a few generic EUDAQ2 executables, so-called portals, which provide a generic way to create a user instance, e. g. a Producer. Examples for such portals are the the euCliProducer and euCliConverter (see Fig. 4 ), which are generic utilities. After a EUDAQ2 portal executable has created an EUDAQ2 instance, the portal executable only interacts with the EUDAQ2 core library, while all user-specific functionality required by each instance is implemented in modular plugins. The EUDAQ2 core then takes care of searching and loading all available user plugin modules located in the specified directories. The communication between the EUDAQ2 core and its plugins is based on derived OOP classes. Therefore, the EUDAQ2 core can steer any user plugin binary without having knowledge of the hardware/plugin specific dependencies, both during build and during runtime.
Extension library Supporting EUDAQ2 on multiple operation systems requires a compact core package without any external dependencies. However, this limits the available functionality, which can be an issue in certain use cases. To increase the flexibility, the core library is very modular with a minimal coupling between the major components. This allows for a simple replacement of individual components using extension libraries. An extension library provides additional optional core features, which might then require external dependencies. These extensions provide a convenient way to extend the functionality of EUDAQ2, without changing the core libraries themselves. The data for example can only be stored as a raw and uncompressed serial-event object stream within the standard EUDAQ2 core. Extensions can be used to write out data using different forms: The LCIO  [10, 11]  extension library for example allows for writing data as LCIO-formatted data, which is widely used in the Linear Collider community.
P interface P has become a very popular programming language in the particle physics community. Therefore, a P wrapper based on pybind11  [14] , which is a lightweight, header-only library that exposes C++ types to P , is provided. P and C++ have significant differences in the treatment of variables and memory: While P passes variables as a reference and does automatic garbage collection, C++ requires manual memory management by default. With the introduction of C++11  [5]  smart pointers, which provide memory management, have become available. Using smart pointers to store all the EUDAQ2 objects instead of raw pointers bridges the gap between P and C++. However, a small performance penalty has to be paid using P due the use of an interpreter and an additional layer, which encapsulates the C++ methods and converts the interfaces to P.
Implementation of a DataConverter to convert each RawEvent to a StdEvent and to the LCIO format, if used for later analysis. 3. Optionally, implementation of a Data Collector, if a specific synchronization, other than trigger-ID or timestamp based methods, is required. The EUDAQ2 manual  [15]  provides detailed technical information as well as a set of code examples. EUDAQ2 contains many new features from long-standing requests of the user community that has used EUDAQ for nearly a decade. Several user groups have become early adopters already during the development phase of EUDAQ2 and provided very valuable feedback throughout and are now using EUDAQ2 for their test beam campaigns. Already today, EUDAQ2 supports many test beam campaigns of detector prototypes at CERN and DESY. EUDAQ2 is becoming more popular and many users migrate their EUDAQ implementations to EUDAQ2.
EUDET-type beam telescopes As the origin of the EUDAQ framework, measurements based on EUDET-type beam telescopes are the most extensive application of EUDAQ2/EUDAQ software. Together with the EUDET-TLU  [16]  they compose a common Trigger-DAQ infrastructure provided by several facilities. Over the last decades, many different user setups have been integrated into EUDAQ in order to use one of the seven copies of EUDET-type beam telescopes located on five different beam lines  [2]. In parallel, developments to achieve higher trigger rates in the Trigger-DAQ system of common beam telescopes  [17]  have started. EUDET-type telescopes are M 26-based  [18, 19] , which operate in a rolling shutter mode with a period of 115. 2 µs. A single FPGA receives the data of six individual telescope planes and creates trigger based double sensors frames.
Therefore, exemplary executables are provided for synchronizing multiple data streams by event number or trigger ID offline. Finally, DataConverter modules can convert the TLU, FE-I4 and M 26 RawEvent to StdEvent blocks for providing interpretable data to the StdEventMonitor which is the exported EUDAQ OnlineMonitor. Corresponding DataConverter modules are available to convert events to the LCIO format  [11]  in order to perform track reconstruction with the EUT framework  [22]  as part of the EUDET-type telescope infrastructure.
ATLAS ITk Strip The ATLAS Inner Tracker (ITk) is a planned silicon tracker which is foreseen to start operation in 2026. It comprises an inner section consisting of pixel sensors, and an outer section consisting of strip sensors. The latter will cover an active area of approximately 165 m 2 with 17888 modules. Each module is composed by a silicon sensor, front-end electronics and a power board. Since 2017, five successful test beam campaigns with EUDAQ2 have been conducted. Two fully irradiated prototype end-cap module and the first double-sided prototype end-cap module were tested, among other devices  [23]. The migration from EUDAQ to EUDAQ2 did not require extensive modifications to the previous setup. As in EUDAQ, two separate Producers are used for the ATLAS ITk DAQ: a Producer transmitting data from the front-end chips, as the hit information, and a Producer providing TTC (Timing, Trigger and Control) information from the readout FPGA.
KPiX strip telescope The KPiX readout system is used by the L strip telescope  [24]  at the DESY II Test Beam Facility. Its native DAQ system consists of an ASIC called KPiX  [25] , and a FPGA DAQ board. The KPiX digitizes and serializes the collected data, the FPGA reads out the data from all the connected KPiX and transmits to the PC. The KPiX chip is designed to be power cycled in between data acquisition periods, which requires an external acquisition start signal. The chip has an internal calibration and trigger module, but it can work with a forced external trigger. Both the acquisition start signal and the external trigger can be sent from the DAQ software. KPiX has its own DAQ software, which is the prototype version for the ROGUE  [26]  framework developed by SLAC. Given that KPiX DAQ has been designed with multiple threads to control data taking and software command transmission, the final integration to the EUDAQ2 was implemented with an intermediate FIFO queue.