dataesr/scientific-paragraphs-categorization huggingface dataset:
A : EUDAQ is a generic data acquisition software developed for use in conjunction with common beam telescopes at charged particle beam lines. Providing high-precision reference tracks for performance studies of new sensors, beam telescopes are essential for the research and development towards future detectors for high-energy physics. As beam time is a highly limited resource, EUDAQ has been designed with reliability and ease-of-use in mind. It enables flexible integration of different independent devices under test via their specific data acquisition systems into a top-level framework. EUDAQ controls all components globally, handles the data flow centrally and synchronises and records the data streams. Over the past decade, EUDAQ has been deployed as part of a wide range of successful test beam campaigns and detector development applications.
Introduction Test beam campaigns with beam telescopes constitute a crucial component in the research and development of novel particle detectors. In-depth performance studies usually require simultaneous operation of different detector systems and synchronised recording of data. This often poses a significant challenge due to the necessary hardware and software integration into a common data acquisition (DAQ) system. EUDAQ is a generic DAQ software framework that was developed to simplify this integration process. Written in C++, supporting multiple platforms such as Linux, MacOS X and Windows and distributed under the LGPLv3  [1] , EUDAQ provides a high level of interoperability. As such, it is one of the few examples of common tools for test beams today and is well-received by a growing user community  [2].
The development of EUDAQ started as part of the EU-funded Joint Research Activity of the EUDET project "Test Beam Infrastructure"  [3, 4]  in 2005. The goal of the project was the development of a high-precision pixel beam telescope for investigations of the tracking performance of sensor devices. To make this beam telescope a versatile tool for a broad user base and a wide variety of devices, an easy integration strategy for devices under test (DUT) and its DAQ was a priority from the beginning of the project  [5]. The interface that was considered to be the most flexible for the user consisted of two separate layers: on the hardware level, the different DAQ systems were to be synchronised using a simple trigger-busy communication protocol; on the software level, the full integration of the DUT into EUDAQ was foreseen as the preferred approach, yet was kept optional.
During event building the Data Collector ignores the absence of events from Slow Producers, which are distinguished from the usual Producers by the type information that is communicated during the initial connection. By default, the data files are just the serialised EUDAQ Event objects, consisting of a common header with run number, trigger number etc. and the raw binary data provided by the respective detector. By directly recording the raw detector response without online processing, all initially available information is retained and the risk posed by possible mistakes in the intermediate data processing code is mitigated. These architectural decisions have proven to provide a high degree of stability and confidence in the integrity of the collected data. If required, EUDAQ may also be configured to write in various other formats, such as the LCIO format  [12, 13]  or its own StandardEvent format.
A range of standard types, such as std::vector and std::map are also handled by EUDAQ, using a similar scheme. Classes defined in the EUDAQ code base, or by the user, are made serializable by inheriting from the Serializable base class, and by implementing the virtual Serialize function and a constructor that takes a single Deserializer instance. In most cases, the implementation is as simple as writing each member variable to the Serializer in the Serialize method, and reading them in the same order in the constructor. All member variables of a Serializable class must also be serializable -either by inheriting from Serializable, or being explicitly handled by the Serializer class.
Integration & Operation The straightforward architecture of EUDAQ allows new users to quickly integrate existing, hardwarespecific DAQ systems into EUDAQ with minimal overhead. Within EUDAQ, each such integrated system is represented by a Producer. The Producer has two roles: to receive commands from Run Control and to send the acquired data to the Data Collector. As such, it provides an interface between the user's DAQ and the rest of the EUDAQ system. Producers can be implemented by deriving from a provided C++ base class, or by using ctypes-based Python bindings. For both use-cases, documentation as well as several examples are provided  [6, 17]. Whenever a command is received from Run Control, a corresponding member function of the Producer is invoked. By providing their own implementations of these functions, users are able to control their device's DAQ.
Having this information stored alongside the actual data significantly simplifies the bookkeeping for later offline analysis and reference. A utility program called Magic Log Book can be used to extract run numbers and their associated parameters from collected data files in order to automatically generate a test beam "log book". During a run, the data retrieved from a device may be submitted through the Producer's SendEvent method. The data is expected to be encapsulated in one of EUDAQ's event formats: usually, this is of type RawDataEvent which is a generic container for blocks of binary data. Additionally, each event can hold metadata which can be useful to record variables relating to device state changes. It is up to each Producer how the raw data is encoded, thus ensuring minimal interference by the data acquisition system and therefore reducing the potential for data corruption.
At this point users are encouraged to submit their code for inclusion into the EUDAQ software repository  [17]. This centralised collection of Producers on the main repository helps prospective users in the detector R&D community by providing examples. Furthermore, the contributors benefit from the continuous integration methods employed in the EUDAQ development process. Through regular automated builds and tests, potential issues can be identified early in the process and mitigated before future releases. As EUDAQ is licensed under the GNU LGPLv3  [1] , users are generally welcome to share, modify and contribute to its development. The source code of EUDAQ is hosted on GitHub, where any potential issues or feature requests can be reported through its issue tracking system. Since interconnection between different platforms and even different architectures is often necessary when performing beam tests, EUDAQ has been developed with interoperability and easy deployment in mind.
Using the CM build system, EUDAQ can be compiled on recent versions of GNU/Linux, MacOS X, and Microsoft Windows using the native compiler tools. The core library and the command-line executables of EUDAQ are self-contained and require no additional external dependencies. Optional components, such as specific Producers, can be enabled at build-time and might have additional dependencies. Commonly, these are Qt  [18]  for the graphical user-interface (GUI) and ROOT  [14, 15]  for the online monitoring. Each individual component of EUDAQ, such as the Run Control, the respective Producers and the Data Collector, run as separate processes communicating with the rest of the system via TCP/IP on configurable port numbers as described in Section 2. Start-up scripts are provided that help to set up typical use-case scenarios.
Two additional developments originated from within the ATLAS Pixel Detector R&D: Firstly pyBAR software for the readout of FE-I4 ASICs has been developed as an alternative DAQ software using PYTHON. This has been used with several readout boards including USBpix Gen2 and USBpix Gen3 boards. It was initially developed to investigate chip tuning methods  [55]  and then used for hybrid pixel detector R&D  [56]  ranging from single-chip readout for sensor characterization  [57]  to multi-chip readout for operation and testing of larger-scale detectors  [58] [59] [60]. The pyBAR software uses PYTHON bindings to integrate into the EUDAQ framework and to provide a dedicated Producer which enables the complete control of pyBAR via the EUDAQ Run Control. A second development was an additional telescope plane consisting of a FE-I4 based module read out by a USBpix board.
In 2017 the DAQ was upgraded to EUDAQ version 2 for subsequent test beams  [64]. The readout cycle of the DUTs corresponds to the LHC bunch-crossing frequency at 25 ns and is thus much shorter than the rolling shutter readout of the Mimosa26 sensors of EUDET-type beam telescope. In order to select only tracks passing within one readout cycle of the DUT, the integrated FE-I4 plane described in Section 4. 2 has been used. An entire barrel module was irradiated to the full expected dose at the HL-LHC and was characterised in 2016, which provided valuable information regarding the future performance of the modules at the end-of-lifetime of the HL-LHC. The ITk Strip DAQ (ITSDAQ) used to operate the detector prototypes runs on an FPGA which performs the trigger-busy-handshake with the EUDET TLU.
Events were then combined on the basis of the trigger number and converted to LCIO. The EUDAQ online monitor provided a visual verification of the synchronization via the spatial correlation between the detectors. EUDAQ was also used for a combined test at the CERN SPS in 2017 of the AHCAL prototype with the CMS HGCAL prototype described in Section 4. 7. For this, an additional EUDAQ Producer was developed to control and read out Delay Wire Chambers (DWCs) using a CAEN TDC VME module. Similar to the preceding test beams, events were built in EUDAQ using the trigger numbers recorded by all participating devices. Since the first test beam with EUDAQ, the AHCAL group has adopted EUDAQ as DAQ framework for most test beams including the integration with the AIDA-2020 beam telescopes and the TLU.
For the first small-scale tests of prototype hexagonal silicon modules at FNAL and CERN in 2016  [91]  a proprietary DAQ system  [92]  was sufficient. Larger-scale tests were planned for 2017/18 using new DAQ components. In order to allow synchronous data taking with other hardware, EUDAQ was selected as central DAQ system due to its configurability, scalability, integrated Data Quality Monitoring (DQM), ease of use and relatively simple integration with different hardware. Initially three dedicated EUDAQ Producers were implemented: for the so-called RDOUT boards using the IPbus protocol  [93] , for CAEN v1290 TDCs, and for CAEN v1742 digitisers. The latter were incorporated for the readout of various beam-characterizing detectors at CERN such as Delay Wire Chambers (DWCs)  [94] , threshold Cerenkov counters and timing devices.
Following the recommended procedure, DataConverterPlugins for the online reconstruction and analysis of the HGCAL data were developed. The converted data were then visualised by suitably modifying the EUDAQ DQM to correctly display the hexagonal pixels of the CMS HGCAL modules. Independently-developed systems using EUDAQ for the readout, such as the CALICE AHCAL presented in Section 4. 5, could be integrated into the tests with little modifications to the triggering logic at the hardware level. It is noteworthy that for the 2018 HGCAL test at DESY, the integration of the EUDET-type telescopes and X-Y stage was straightforward and allowed exploiting the pre-installed telescope Producer, Slow Producer and the TLU provided at the DESY II Test Beam Facility. Using EUDAQ as central DAQ framework, systems ranging from a single 128-channel hexagonal silicon module, to 94 modules plus the 39-layer 2018 CALICE AHCAL prototype, were successfully tested in beams at DESY and CERN in 2017 and 2018 for a total of more than two months.
The system is capable of operating single ROC assemblies as well as full detector modules and has been used for test beam measurements and for the qualification of all final detector modules produced. The software library strictly separates user inputs from hardware calls by means of a hardware abstraction layer (HAL). This concept has allowed a stable application programming interface (API) to be provided to various users and developers of user interfaces while major changes could be implemented on firmware and HAL-level without entailing additional changes to user software or breaking compatibility with older versions. Using this interface, an EUDAQ Producer (CMSPixel) was written which parses the configuration parameters obtained from the EUDAQ Run Control and calls the appropriate API functions of the pxarCore library.
Providing a Data ConverterPlugin for EUDAQ ensured full integration of the detector into the online monitoring system and allowed supervision of basic detector parameters as well as correlation with telescope planes during data taking. The test beam activities and results have been summarised in a publication  [97] , and the detector was successfully built, commissioned and is in operation since the LHC year-end technical stop 2016/2017. The test beam setup and its EUDAQ integration has also been used for measurements studying the performance of the ROC under the influence of radiation-induced damage  [99]. In addition to the comprehensive test beam campaigns for the characterization of the new readout chip, measurements with full CMS Phase I pixel detector modules have been performed  [100].
Two different module types are foreseen for the OT: 2S modules comprising two strip sensors, and PS modules, where a strip sensor and a macro-pixel sensor are used. The latter are deployed at radii from 200 -600 mm, the former at radii larger than 600 mm. Four successful test beam campaigns investigating Outer Tracker prototype modules have been performed at DESY and CERN in 2017 and 2018 with the EUDET-type beam telescopes. The FPGA running the CMS OT DAQ performs the full trigger-busy-handshake protocol with the EUDET TLU. A custom EUDAQ Producer has been developed and interfaces the CMS OT DAQ with the EUDAQ Run Control. Whilst the initial configuration of the CMS modules is performed separately, the Producer sends the hit data of both prototype sensors to the Data Collector. Furthermore, parameters from the front-end ASICs such as TDC or stub information are added to the individual EUDAQ events for the track reconstruction and subsequent analysis.
Using this method, structures of devices can be resolved in a two-dimensional image covering the Mimosa26 active area or even in three-dimensional tomographic images by rotating the sample under test  [99, 104]. In this case a large amount of recorded particle tracks is needed to reach a reasonable resolution and contrast in the images. With the particle fluxes in the order of 5 kHz/m 2 achievable at the DESY II Test Beam Facility, it is required to employ automatic data taking over longer time periods. EUDAQ and the DAQ of the EUDET-type beam telescopes have shown to perform stably when conducting measurement campaigns overnight using the automatic-next-run option. The x and y linear stages can be used in order to explore samples larger than the active area of the Mimosa26 sensors. The rotational stage offers the possibility to perform tomographic studies.
For this, the control over the different motor stages was implemented in EUDAQ as a Slow Producer, which allows one-dimensional scans to be performed by defining the scan range in the configuration file. For performing arbitrary two-dimensional scans, multiple configuration files for the respective coordinates can be created. After the completion of a given run, corresponding to one configuration file, the subsequent file is automatically loaded by the Run Control. This feature is extensively used for the three-dimensional tomographic imaging technique. Owing to this fully automated data taking as well as the possibility to record even larger areas than the size of the Mimosa26 active area by stitching images, this technique is a valuable tool to gain insights into the material budget of calibration material as well as complex structures as demonstrated in Figure  9.
A hit is registered and read out in less than 200 ns, compared to the rolling shutter revolution time of up to 230. 4 µs of the Mimosa26 sensors. During a single Mimosa26 readout cycle, the timestamps on the MuPix laps 15 times. Additionally, the prototypes are significantly smaller than the Mimosa26 sensors, leading to events without a hit in the MuPix. To avoid several triggers without hit-data, empty blocks are sent to the Data Collector to match the trigger frequency. The full trigger-handshake with the TLU is realised on an FPGA. A custom Producer, serving as interface between the MuPix DAQ and the EUDAQ Run Control, has been developed. The flow chart of the interaction between the two systems is depicted in Figure  10. The EUDAQ Producer steers the complete MuPix readout and configuration procedure.
Conclusion & Outlook EUDAQ has been developed as a common data acquisition software for many different use cases and fulfills several common requirements: • Flexible and light-weight: EUDAQ is platform independent and can be operated on Linux, Windows or macOS, and comes with as few external dependencies as possible. • Easy-to use: EUDAQ incorporates well-defined interfaces which allow data sending and control of the user's hardware and conversion of the data for monitoring or offline analysis. • Robust data taking: The data taking strategy is to store detector-native raw binary data without additional processing by the DAQ system. This allows to retain all information initially recorded and reduces the risk of data loss through errors in the processing code. The data handling is performed by one central instance and data from different sub-detectors are synchronised on an event-by-event level, ensured by the global busy-trigger communication provided by the EUDET TLU.
Thanks to many user groups continuing to share their code integrating their own devices, EUDAQ now ships with support for many different devices. This both serves as a reference for new users and allows developers to ensure compatibility when modifying core parts of the framework. Over more than a decade, EUDAQ has thus been maintained for production and, at the same time, been constantly developed and improved. The diversity of the contributing user groups is a testament to the collaborative spirit of the test beam community and the central role that the EUDET-type beam telescopes, and in turn EUDAQ, plays. As part of the EUDET-type beam telescopes, EUDAQ was assessed by the community at the "Beam Telescope and Test Beam" workshop in 2018  [2]. From the discussion and survey among the participants, it was concluded that the EUDAQ architecture and development road-map fulfills the test beam user's needs for the foreseeable future.
During the implementation phase of the AIDA framework  [107] , EUDAQ became a candidate for a common test beam DAQ, extending beyond its initial goal of serving as system for telescopebased test beams only. In a comparison with other DAQ frameworks such as XDAQ  [108] , EUDAQ was judged as "greatly simplified, and relies on as few external libraries as possible. EUDAQ is designed to be portable. " Furthermore, recommendation for improvements were collected from the telescope community. These included suggestions such as parallel data streams and the possibility to acquire individual events for each particle or trigger  [109]. These requirements led to the development of an improved version of EUDAQ and the new version -called EUDAQ2 -was selected as the common software framework under the work package WP5 within the AIDA-2020 framework  [110].
EUDAQ2 breaks with several concepts such as the event-by-event synchronization of devices and is therefore not compatible with Producers written for EUDAQ. It comes with the possibility to run multiple Data Collector instances for decentralised data taking and is therefore more scalable than EUDAQ. Together with the new AIDA TLU  [111]  a higher trigger rate can be achieved and events can be built either online or offline by synchronizing the individual data streams using their trigger IDs or a common clock. The framework was released in 2017  [64]  and has already been applied by the ATLAS ITk Strips test beam group for the first time. Thank to these enhancements EUDAQ has become even more flexible and is ready for testing the next generation of detectors for future experiments.
Acknowledgments The authors are greatly indebted to their colleagues from the  DESY  FH division over the last decade, who are essential to successfully maintain and extend this software framework. This work was supported by the  Commission of the European Communities  under the 6 th  Framework Programme  " Structuring the European Research Area ", contract number  RII3-026126. The research leading to these results had received funding from the  European Commission  under the  FP7 Research Infrastructures project AIDA , grant agreement no. 262025. This project has received funding from the  European Union 's  Horizon 2020 Research and Innovation programme  under Grant Agreement no. 654168. The support is gratefully acknowledged. The information herein only reflects the views of its authors and not those of the  European Commission  and no warranty expressed or implied is made with regard to such information or its use.
, 2017; Sándor et al. , 2017)  or a single-model approach (e. g. accurately using fewer input data, provided they make predictions within the boundaries of 85 their validity domain  (Luo et al. , 2013). The first step was to improve STICS' ability to 86 simulate DM and N fluxes in grasslands, in particular by representing animal returns during 87 grazing, and by comparing its predictions to a database of observed grassland yields. 88 89.
Weather and soil conditions: definition of the spatial resolution of simulations 122 The weather information required to run STICS was provided by the mesoscale atmospheric 123 analysis system (SAFRAN)  (Durand et al. 1993). Soil information from the 1:1,000,000-scale 124 soil geographic database of France  (Jamagne et al. , 1995)  was used to parameterise STICS' 125 soil parameters. In this database, soil information is available in soil mapping units (SMU), 126 which are areas which consist of 1-6 soil types whose percentage within the SMU is known. 127 STICS soil parameters were provided by the INRA InfoSol lab. Soil organic N content in the 128 topsoil (0-30 cm) was estimated according to  Mulder et al. (2015)  for both temporary and 129 permanent grasslands. Soil types with an organic texture such as histosols were excluded from 130 the simulation plan (i.
e. 1% of soils, 0. 3% of simulations), as they lay outside STICS' validity 131 domain. Similarly, according to STICS' limits, soil organic N content in the topsoil was 132 limited to 0. 4% (i. e. soil organic matter content < 7. 6%;  Graux et al. , 2017). 133 Corsica and overseas French regions were excluded from simulations as they were not 134 included in the databases used. Combining weather and soil information at the SMU level led 5 to definition of 30,966 pedoclimatic units (PCU), each of which was no larger than 6400 ha 136 (Figure  1 ). Only PCU with utilised agricultural area (UAA) greater than 100 ha and with 137 grassland area greater than 10% of UAA were considered in the simulation plan. This led to 138 the definition of 15,032 PCU (i. e. half of the total number of PCU), thus excluding four 139 highly urbanised departments (Hauts-de-Seine (department code 92), Paris (75), Seine-Saint-140 Denis (93) and Val-de-Marne (94)).