dataesr/scientific-paragraphs-categorization huggingface dataset:
A custom-made firmware running on a Virtex 5 FPGA embeded in a FlexRIO board (PXIe 7962R) acquires and deserialises the 12 serial links -two per sensor -at 80 Mb/s, detects triggers on the trigger line, and reads the trigger data. The resulting data stream of 960 Mb/s is read by the CPU (PXIe 8130) from the PXIe bus via a DMA channel and processed on-line by software. Data packets on which the TLU has triggered are selected, demultiplexed and actual frames built. The data are then available to the EUDAQ framework (cf. section 4), and an event is written to disk in normal handshake mode, only if a trigger has been raised for a certain telescope readout frame. This co-development, i. e. sharing processing tasks between firmware and software, allows for high flexibility for system upgrades. The presented DAQ architecture is able to read six MIMOSA 26 sensors without any dead-time at up to 8680 frames/s.
The EUDAQ data acquisition framework The modular cross-platform data acquisition framework EUDAQ  [15]  has been designed and developed to serve as flexible and simple-to-use data taking software for the EUDET-type beam telescopes, allowing for easy integration of other devices. It consists of completely independent modules communicating via TCP/IP enabling a distributed data acquisition with modules running on separate machines. Currently, EUDAQ is designed for synchronous DAQ systems requiring one event per trigger per attached subdetector system before building the global event. Thus, the trigger rate is always limited by the slowest device. The central interaction point for users with the framework is the Run Control and its graphical user interface (GUI). All other modules connect to the Run Control at startup and receive additional information from there during operation such as the commands for starting and stopping a DAQ run.
The GUI provides all controls necessary to the user on shift. Another important user interface is the Log Collector, gathering logging information from all modules and displaying them in one unified logging window. Log files are stored along with the recorded data files for later reference. The actual detector data are delivered to the framework by so-called Producers. Producers are the links between the EUDAQ framework and the subdetector systems such as the beam telescope, the TLU, or user DAQ systems. They interface with the EUDAQ library and provide a set of commands to be called by the Run Control. This simple interface scheme eases the integration of user DAQ systems into the software framework. The data read out from the detectors by the individual Producers are sent to the so-called Data Collector.
This Data Collector is responsible for the event building, i. e. the correlation of events from all subdetector systems to single global events comprising all data belonging to one trigger. Basic sanity checks such as testing the consistency of event numbers reported by the individual subdetectors are executed. To ensure data quality during data acquisition, the Online Monitor tool is available. It connects to the Data Collector requesting a fixed fraction of the recorded events (e. g. one out of a hundred) to fully decode all subdetector data and build basic plots such as hit maps or correlation plots. Thereby, data quality monitoring verifying that the different devices are synchronized in time and all within the geometrical trigger acceptance, is possible during data taking. The data decoding is performed using Data Converter plug-ins for every detector type attached to the Run Control.
The plug-in to be called for a specific subevent is deduced from the event type transmitted by the Producer and written to the data stream by the Data Collector. Each Data Converter plug-in can implement several data format end points allowing, amongst others, for the conversion to the internal EUDAQ format for the Online Monitor, to simple ROOT trees, or to LCIO which is used by the offline reconstruction software described in the following section. Configuration of the data acquisition framework is performed via global configuration files. The information for every individual module is parsed and distributed by the Run Control. The configuration file is a plain text file divided into sections for the individual modules, which contain a list of parameter-value pairs defined by the module.
Offline analysis and reconstruction using EUTelescope For offline analysis and reconstruction of telescope test beam data the EUTelescope software package  [16, 17]  is available and features a close integration of the EUDAQ software framework described in section 4. EUTelescope is based on the ILCSoft framework  [18]  which provides Figure  3 : Schematic of the overall telescope data reconstruction and analysis strategy of the EUTelescope framework. EUTelescope provides processors for all steps, except for the conversion of the DUT raw data, marked with a dashed outline. the basic building blocks for offline analysis such as a generic data model (Linear Collider I/O, LCIO), a geometry description language (GEAR) and the central event processor (Marlin)  [19]. Marlin allows for a modular composition of analysis chains for various applications.
Every task is implemented as an independent processor which is called by Marlin for every event. Each processor exposes a set of parameters to the user which can be configured and loaded at runtime via so-called steering files in XML format. This way the Marlin/Processor architecture gives maximum flexibility to the user. EUTelescope provides several processors for Marlin, implementing algorithms necessary for a full track reconstruction and data analysis of test beam experiments. Figure  3  shows the analysis strategy of the framework starting from the recorded detector response to the final reconstructed particle tracks. At low-energy beam lines such as the DESY-II test beam facility, multiple scattering is an important contribution to the overall track resolution uncertainty, especially in measurements with non-negligible DUT material budget, cf.
Track resolution studies The data presented were taken in 2015 using DATURA, an EUDET-type beam telescope, which was operated with EUDAQ, cf. sections 3 and 4. Results shown in this section have been obtained using the EUTelescope software described in section 5. The set-up does not include any additional DUT, only six MIMOSA 26 telescope planes. Track fits are performed using the GBL formalism and track residuals, i. e. the distance between the track fit and the measured hit, are calculated for each telescope plane. The intrinsic resolution of the sensor planes is derived from data and used as input for track resolution predictions.
Considerations for DUT integrations DUTs can be mechanically integrated into an EUDET-type beam telescope at three positions: upstream or downstream of the telescope, or between the two telescope arms. If placed between the arms, micrometer precision xyφ-stages are available for translation scans and rotation of the DUT  [35]. At this position, the maximum width of the DUT set-up is 500 mm. DUTs with larger spatial dimensions are therefore placed at the downstream end of the beam telescope. User DAQ systems are integrated to the TLU the same way as the beam telescope DAQ itself using either the RJ45 or the LEMO interface, cf. section 3. 2. The handshake mode is configurable for each integrated system individually. For the integration of the DUT data stream with EUDAQ, a producer capable of receiving commands by the Run Control and sending data to the EUDAQ Data Collector is necessary as described in section 4.
A dedicated alignment run prior to data taking with no DUT in the beam allows for precise alignment of the telescope planes, especially for larger ε DUT. With a proper alignment at hand, runs including a DUT are to be analysed subsequently in order to align the DUT with respect to the beam telescope. The reconstructed tracks can then be used to characterise the DUT, i. e. to measure its intrinsic resolution or efficiency. With increasing ε DUT , and thus multiple scattering within the DUT, the choice of the tracking algorithm needs further consideration. In general, a GBL fit produces tracks with a lower χ 2 compared to straight line fits, as kinks at the possibly thick DUT and also at the MIMOSA 26 planes themselves are allowed for. Therefore, using GBL for track fitting is recommended. For comparison, in a narrow configuration using a 5 GeV electron/positron beam, the track resolution of a EUDET-type beam telescope at a DUT with ε DUT = 0.
Conclusion In this work the EUDET-type beam telescopes have been described and their performance has been investigated. The highly flexible and versatile EUDET-type beam telescopes come with a Trigger Logic Unit with time stamping capabilities and a clearly defined interface for an integration of user data acquisition systems. It is complemented by a data acquisition system for the telescope sensors, and the powerful software packages EUDAQ and EUTelescope -a modular data acquisition framework and an offline reconstruction software, respectively. The intrinsic resolution of the MIMOSA 26 sensors have been measured to be (3. 24 ± 0. 09) µm. General Broken Lines calculations predict a track resolution of (1. 83 ± 0. 03) µm on the DUT with 20 mm plane spacing for thin sensors with ε DUT = 0. 001 at 5 GeV.
Continuous development efforts are ongoing to upgrade and enhance the Trigger Logic Unit, the data acquisition system, and offline reconstruction framework  [36]. The maximum achievable rate will be increased by the successor of the TLU. A new plane comprising four MIMOSA 28 planes has been built for the AIDA telescope, covering a detection area of 16 cm 2 , and an appropriate DAQ has been developed to cope with the higher data rates. Future versions of EUDAQ will provide support for asynchronous data streams allowing to operate certain devices at a much higher trigger frequency than others and thus making full use of the the beams available in the various beam lines. The development of the EUTelescope analysis software is driven by the large and diverse user community. Features currently under development include tracking in magnetic fields and more accurate detector geometry descriptions.
Acknowledgements We are indebted to  Claus Kleinwort  for his counsel and numerous discussions. Also, we would like to thank  Ulrich Kötz. The test beam support at DESY is highly appreciated. This work was supported by the  Commission of the European Communities  under the  FP7 Structuring the European Research Area , contract number  RII3-026126  (EUDET). Furthermore, strong support from the  Helmholtz Association  and the  BMBF  is acknowledged.
Data and materials The datasets supporting the conclusions of this article are available from reference  [37]. The software used is available from the github repositories: 1) https://github. com/eutelescope/ eutelescope, 2) https://github. com/simonspa/eutelescope/, branch scattering and 3) https: //github. com/simonspa/resolution-simulator. For the presented analysis, these specific tags have been used:  [28]  and  [32].
Masks of the cerebrospinal fluid and white matter were computed from the structural images of participants using the FAST program in FSL, then moved into the functional space of the resting state and extracted as time series. The RVT, the RR cardiac interval, P ETCO2  [Peng et al. , 2013; Wise et al. , 2004] , O 2 saturation, and cerebrospinal fluid and white matter time series were then included into a multivariate linear regression model to account for significant influences of these potentially confounding factors on the blood O 2 level-dependent (BOLD) signal and were regressed out. Statistical images were then registered to high-resolution structural and standard space images using FLIRT  [Jenkinson and Smith, 2001] , and further refined using FNIRT nonlinear registration.
Study Limitations We selected the seed regions based on significant BOLD signal alterations detected during block design imaging with the controls > COPD contrast. Therefore, this approach did not include the thalamus among seed regions although its role in gating respiratory sensory information to the cortex has been described in response to CO 2 stimu-lation or during air hunger in healthy individuals  [Evans et al. , 2002; Pattinson et al. , 2009]. We removed the noise from the resting state data using independent component analysis (ICA) as implemented in MELODIC  (FSL software). This method has limitations as the determination of the proper dimensionality: a too restricted decomposition might fail in separating the noise from the biological signal whereas in case of a high model order dimensionality, ICA results may be split into a number of subnetworks, which may be difficult to identify and classify.
ACKNOWLEDGMENTS Authors are grateful to the anonymous reviewers for the time and expertise they spent on our manuscript. L. M. designed the research; L. Y. , M. D. M. , A. H. , Y. K. , H. M. , M. C. , and L. M. performed the research; L. Y. , M. D. M. , A. H. , M. C. , and L. M. analyzed the data; F. R. A. and H. M. contributed inputs; L. M. and M. C. wrote the article.
The CHISIS interface module A Fortran module called CHISIS (CHImere/oaSIS) that interfaces CHIMERE and OASIS was developed. This module gathers all calls to OASIS subroutines required by CHIMERE in order to exchange fields with another model. Furthermore, a reading routine of the OASIS configuration file (i. e. the namcouple file) was included, thus allowing each model to be aware of coupling parameters (e. g. exchanged variable names, time steps, partitions, grids, models involved), leading to generic subroutines without any hardcoded information. Even though the CHISIS module was designed for CHIMERE, it does not contain any CHIMEREspecific material; therefore, it may be used in other models. An OASIS interface module already exists within WRF as a WRF-NEMO coupling has already been implemented.
However, WRF-NEMO exchanged variables were hardcoded within this interface module, making it difficult to reuse this module for the WRF-CHIMERE coupling. Thus, new compilation flags were added within the WRF code ("cpl_wrf_chimere" and "cpl_wrf_chimere") in order to distinguish the generic OASIS interface material that may be of use in a coupling with any model from the specific material of either WRF-NEMO or WRF-CHIMERE coupling.
OASIS configuration The latest OASIS release, OASIS3-MCT, internally uses the Model Coupling Toolkit (MCT), developed by the Ar-gonne National Laboratory in the USA, for parallel regridding and parallel distributed exchanges of the coupling fields  (Larson et al. , 2005; Jacob et al. , 2005). To perform a WRF-CHIMERE coupling, the exchange of threedimensional fields is required (e. g. temperature, wind velocity, pressure). A previous OASIS release, OASIS4, allows one to exchange three-dimensional variables  (Redler et al. , 2010) ; however, its code was too complex to evolve easily. Thus, OASIS developers decided to take a step back and use MCT with the OASIS3 release, which does not include the possibility of three-dimensional variable exchange. Therefore, three-dimensional spatial interpolation between model grids is not possible either.
, 2001). The MELCHIOR2 chemical mechanism and the  Bessagnet et al. (2004)  aerosol module are used. The Fast-JX module, version 7. 0b  (Wild et al. , 2000; Bian and Prather, 2002) , was included in the CHIMERE model in order to compute photolysis rates along with aerosol optical depth  (Mailler et al. , 2016a). Dry and wet depositions are treated as described in  Wesely (1989)  and  Loosmore and Cederwall (2004) ; 20 pressure-dependent vertical levels are used, from the surface up to 200 hPa. The WRF model fields computed on 32 σ levels, which are either received via the OASIS coupler (online mode) or read from the WRF output files (offline mode), are linearly interpolated over the 20 CHIMERE vertical levels. Rea et al. (2015)  studied the contribution of the different aerosol sources to surface particulate matter (PM), using the CHIMERE model with a similar configuration and over a similar domain during the summer of 2012.
Comparison of both offline and online simulation times The total online simulation durations are compared here to the offline simulation times. Time measurements were made using the Linux command "time". There is an uncertainty regarding these measurements that is not fully known, as it depends on the load of the computer that is used, which may vary during the simulations. However, simulations are long enough for the average times per iteration along with the trend to be significant. Average simulation times per iteration are shown in Fig. 5  as a function of the number of cores per model. As the WRF model is much faster than the CHIMERE model, the maximum of both WRF and CHIMERE offline run times is equal to the CHIMERE offline run time. As expected, the CHIMERE model parallelisation induces a decrease in the overall computational time with the increase in the number of cores.
Comparison with AirBase PM 10 concentrations Hourly PM 10 measurement from the European Air quality dataBase (AirBase) of the European Environment Agency (http://acm. eionet. europa. eu/databases/airbase) are used in this section for comparison with CHIMERE PM 10 concentrations. As in  Rea et al. (2015) , only rural and background stations are considered for the comparison in order to avoid sites which are strongly influenced by local sources. In addition, stations with a minimum of 300 measurements during the period ranging from 1 June to 14 July are selected, leading to a total of more than 940 remaining stations located over Europe. Averaged performance indicators show that all simulations overestimate measurements and that the overestimation is higher with both online simulations (6. 8 µg m -3 ) than with the offline simulation (1.
Code availability The WRF model is available at http://www. wrf-model. org/ index. php (Skamarock et al. , 2007)  and OASIS coupler code is available at https://verc. enes. org/oasis (Valcke et al. , 2015). The CHIMERE model is provided under the GNU General Public License and is available on the CHIMERE website: http://www. lmd. polytechnique. fr/chimere/ (Mailler et al. , 2016b). Both WRF and CHIMERE online coupling developments will be made available in a future CHIMERE release and are available upon request.
Acknowledgements. The authors acknowledge the  French Direction Générale de l'Armement  for funding the  APPAD  project, the  COPERNICUS-DD program  for funding the  NATORGA  project and the  University of Geneva  for its support. This work was also supported by the  DRUMS (DeseRt dUst Modeling: performance and Sensitivity evaluation ; project  ANR-ASTRID-DRUMS-2012 ) research program funded by the  ASTRID  fund call of the  French Agence Nationale de la Recherche (ANR). We thank the  OASIS modeling team  for their support with the OASIS coupler. Finally, we thank the  National Aeronautics and Space Agency  for the availability of the MODIS data, the investigators and staff who maintain and provide the AERONET data, the  University of Wyoming  for the availability of the atmospheric soundings, and the  European Environment Agency  for providing the AirBase data.
Thus, a task is the representation of an activity within a one-time execution of this activity, which processes a data partition or chunk  [22]. A SWf Management System (SWfMS) is the tool to manage SWfs  [22]. In order to execute SWfs efficiently, SWfMSs typically exploit High Performance Computing (HPC) resources in a cluster, grid or cloud environment. Because of virtually infinite resources, diverse scalable services, stable quality of service and flexible payment policies, clouds have become an interesting solution for SWf execution. In particular, the user of Virtual Machines (VMs) makes it easy to deal with elasticity and workloads that change rapidly. A cloud is typically made of several sites (or data centers), each with its own resources and data. Thus, in order to use more resources than available at a single site or to access data at different sites, SWfs could also be executed in a distributed manner at different sites.
Nowadays, the computing resources or data of a cloud provider such as Amazon or Microsoft are distributed at different sites and should be used during the execution of SWfs. As a result, a multisite cloud is an appealing solution for large scale SWf execution. As defined in  [21] , a multisite cloud is a cloud with multiple data centers, each at a different location (possibly in a different region) and being explicitly accessible to cloud users, typically in the data center close to them for performance reasons. To enable SWf execution in a multisite cloud, the execution of each activity should be scheduled to a corresponding cloud site (or site for short). Then, the scheduling problem is to decide where to execute the activities. In general, to map the execution of activities to distributed computing resources is an NPhard problem  [36].
The objectives can be to reduce execution time or monetary cost, to maximize performance, reliability etc. Since the SWf execution may take a long time and cost much money, the scheduling problem may have multiple objectives, i. e. multi-objective. Thus, the multisite scheduling problem must take into account the impact of resources distributed at different sites, e. g. different bandwidths and data distribution at different sites, and different prices for VMs. In this paper, we propose a general solution based on multiobjective scheduling in order to execute SWfs in a multisite cloud. The solution includes a multi-objective cost model, a Single Site VM Provisioning approach (SSVP) and ActGreedy, a multisite scheduling approach. The cost model includes two objectives, namely reducing execution time and monetary costs, under stored data constraints, which specify that some data should not be moved, because it is either too big or for proprietary reasons.
Although useful for fixing some activities, these constraints do not reduce much the complexity of activity scheduling. We consider a homogeneous cloud environment, i. e. from single provider. The case of federated clouds (with multiple cloud providers) is beyond the scope of this paper and not a reality (although there are some recent proposals). Act-Greedy handles multiple objectives, namely reducing execution time and monetary costs. In order to schedule a SWf in a multisite cloud, the SWf should be partitioned to SWf fragments, which can be executed at a single site. A SWf fragment (or fragment for short) is a subset of activities, dependencies and associated input data of the original workflow  [21]. Then, each fragment can be scheduled by ActGreedy to the site that yields the minimum cost among all available sites.
Rather than using real execution, they simulate the execution of SWfs , thus missing the heterogeneity among the activities of the same SWf, to evaluate their proposed approaches. In real SWf execution, the activities generally correspond to different programs to process data. However, in simulations of SWf execution, the activities are typically made homogeneous, namely, they correspond to the same program. Different from the existing approaches, our approach is suitable for multisite execution and is evaluated by executing a real-life SWf on a multisite cloud that is Azure. Some scheduling techniques have been proposed for the multisite cloud, yet focusing on a single objective, i. e. reducing execution time. For instance, Liu et al. [21]  present a workflow partitioning approach and data location based scheduling approach.