dataesr/scientific-paragraphs-categorization huggingface dataset:
Sensitivity of snowpack simulations to the radiative forcing DSSF and DSLFnew irradiance datasets were used to replace AROME irradiance forecasts as radiative forcing of Crocus simulations. The rest of the atmospheric forcing was taken from AROME forecasts. A similar experiment was done with SAFRAN irradiances. The performance of the snowpack simulations was degraded when using DSSF and DSLFnew products, with an increased positive snow depth bias. On the contrary, the use of SAFRAN irradiances was found to decrease the positive bias obtained with AROME-Crocus. Vionnet et al. (2016)  and  Quéno et al. (2016)  already showed an overestimation of snow depth by AROME-Crocus in the French Alps and the Pyrenees respectively. In addition,  Quéno et al. (2016)  partly attributed this overestimation to an underestimation of strong melting.
It is also due to the earlier snowmelt at low altitudes, which limits the crucial role played by SW↓ in spring. Furthermore, the differences between the different radiative forcing datasets mainly consist of biases rather than random errors: a typical example is the difference between AROME and DSSF in SW↓ at high altitudes, shown in Fig. 11. Their effect is then cumulated during the whole season, rather than counterbalanced, which increases their impact. It is consistent with the outcomes of  Raleigh et al. (2015)  who showed that snowpack models are more sensitive to biases than random errors in the forcings. It was particularly highlighted for incoming radiative fluxes by  Lapo et al. (2015b). Finally, although the SWE is not impacted by the differences in incoming radiative fluxes at high altitude during the accumulation period (Fig.
11 ), impacts are to be expected in terms of snow surface temperatures, with possible consequences on the snow metamorphism processes. Lapo et al. (2015b)  indeed showed more sensitivity of the snowpack simulations to irradiance errors at the coldest sites when evaluated in terms of snow surface temperature rather than SWE. Future works could thus focus on the impact of the different incoming radiative flux datasets on the surface energy budget and the resulting effects on the snowpack stratigraphy.
In terms of longwave irradiance, contrasted results were obtained at the mountain stations, all falling within the range of uncertainty of sensors. A systematic underestimation by AROME, DSLF and DSLFnew was highlighted. The negative bias of DSLF was reduced by DSLFnew up to mid-altitudes but enhanced at high altitudes due to an overly strong altitudinal gradient associated with the cold bias in AROME near-surface air temperature at high altitudes. A spatial comparison of the datasets showed that AROME and DSSF better represent the spatial variability of SW↓ fluxes in mountains by comparison with SAFRAN. These results are encouraging and highlight the potential benefits of using DSSF, DSLF and DSLFnew as radiative forcing for snowpack modelling in mountainous terrain. Their relatively good quality in mountains as compared to lower altitudes also supports the use of these data as climatological inputs and/or validation datasets for NWP models over complex domains such as mountains, where incoming radiative flux measurements are scarce.
An evaluation of distributed snowpack simulations by Crocus driven by AROME and the different irradiance datasets was then conducted in the French Alps and the Pyrenees. We showed that replacing AROME irradiances by DSSF and DSLFnew increased the positive bias of snow depth, despite an overall better performance of these datasets in terms of incoming radiative fluxes. Therefore, an improved meteorological forcing does not ensure more accurate snowpack simulations. This is mostly due to error compensations within the atmospheric forcing and the snowpack model. Complementary studies are sorely needed to identify the cause of the underestimated melting, which cannot be attributed to radiative fluxes. They should tackle factors such as the turbulent fluxes simulated by AROME-Crocus and the albedo parametrization in Crocus.
Multiphysical ensemble snowpack modelling would also enable simulation errors to be accounted for  (Lafaysse et al. , 2017). Until such improvements are performed in the AROME-Crocus modelling context, the LSA SAF products of incoming radiative fluxes can be used to improve understanding of snowpack models as well as in other snowpack-related studies, because they provide irradiance data of reasonable quality in mountainous areas. Data availability. Irradiance datasets are available from the following sources: -DSSF and DSLF were provided by the EUMETSAT Satellite Application Facility on Land Surface Analysis (LSA SAF; Snowpack datasets are available from the following sources: -SURFEX/ISBA-Crocus model source code is available at https://opensource. umr-cnrm. fr/projects/surfex (last access: 23 April 2020).
Trigo et al. , 2011; http://lsa-saf. eumetsat. int, last access: 23 April 2020). -AROME forecasts in real time are publicly available at https:// donneespubliques. meteofrance. fr (last access: 23 April 2020). All AROME forecast archives are available on request from the same website for a data provision fee. The AROME and SAFRAN database used in this study is available for research purposes on request from the authors. -Shortwave and longwave irradiance in situ measurements from the Météo-France station network are available for a data provision fee at https://donneespubliques. meteofrance. fr (last access: 23 April 2020). The measurements covering the domain and period used in this study are available for research purposes on request from the authors. Irradiance measurements from Argentière glacier and Saint-Sorlin glacier AWSs are available at http://data.
Acknowledgements. DSSF and DSLF were provided by the  EU-METSAT Satellite Application Facility on Land Surface Analysis (LSA SAF ; Trigo et al. , 2011). The authors are grateful to  Simon Gascoin  ( CESBIO ) for providing irradiance measurements from the  Bassiès AWS , and to  Delphine Six (IGE)  for providing irradiance measurements from  Saint-Sorlin glacier and Argentière glacier AWSs (data from GLACIOCLIM program , https://glacioclim. osug. fr,last access: 20 April 2020). We also thank  Dominique Carrer ,  Jean-Louis Roujean  and  Catherine Meurey  ( CNRM ) for help with the LSA SAF data, and  Isabel Trigo  ( IPMA ) for information about the DSLF algorithm. CNRM/CEN is part of  LabEx OSUG@2020  ( ANR10 LABX56 ). We are also grateful to the anonymous reviewers for their detailed comments which helped improve the paper.
I. INTRODUCTION ECENTLY installed soft X-ray measurement system for plasma impurities monitoring was used during plasma campaign measurements in 2019 year  [1]. At the moment, the vertical GEM camera is working, the most difficult one for the installation due to direct in-port detector placement  [2]. The system consists of 103 Line-Of-Sights, thus allowing a large angle of tokamak vessel view, especially the divertor part. This allows to perform studies about plasma impurities with large amount of diagnostic data. The key assumption of the measurement system is that due to modern FPGAs used (Xilinx Series7 at moment of design), the system allows to select valuable data (events related to photon emission from plasma) and then using streaming interfaces postprocess them in advanced Matlab algorithms  [3] -  [5].
II. DATA QUALITY MONITORING FEATURES The system is working in the difficult tokamak environment. Especially due to electro-magnetical interferences, neutron radiation and very low space for the electronics (cooling aspects). Therefore, it is especially valuable to implement data quality monitoring mechanism in order to better understand the measurements effects of the system and its data validity. Each of the FPGA boards is capable of handling up to 64 measurement channels from the GEM detector. The system is under verification in global trigger mode to observe the full behavior of the detector and measurement channels. In this mode, the algorithms are sensitive to single photon registered by the detector and creates a snapshot of whole GEM detector, from all channels. All of the connected FPGAs are registering data at the same time.
Each of the FPGA creates data pack of 64 channels and send it to PC. The data is transmitted without any change to the measurement PC for further postprocessing in Matlab software. More details about data handling in scope of DQM mode can be found in  [10]. This mode is also very valuable for further postprocessing algorithms, especially is scope of the charge computation. If working in global trigger mode, the postprocessing algorithm needs first check every frame in scope of signal above the triggering level. After, on selected signals is possible to perform charge computations. In addition, in one frame can occur multiple pulses, corresponding to several clusters at one time. Therefore, it is necessary to check each channel for localization of valid signals. Having triggering channels information attached to beginning of every event reduces the necessity of each channel verification resulting in faster computation speed.
D. Dynamic offsets DQM -Implementation details The FPGA implementation registers the offset value for each independent channel. This crate a matrix of 64 x 16-bit values with dynamically computed offsets. After startup of event registration in the FPGA, the dynamic offsets values are latched and attached as one row to the end of the data frame. The values are attached to each event. Under Matlab tools during postprocessing it is possible to do a verification of this offset computation mode, as well offset behavior, especially by creating plots of: • Offset value with added relative trigger DQM values and offset from first sample of the event (assuming that the pulse is in the middle of the frame) This mode creates extra 1024bit data for each event. The basic global triggering mode provides 799 events per each DMA packet (4MB).
This is also valuable information about offset computations during plasma pulse, since the algorithm is blocked during voltage pulses. The user can compare the expected trigger level with computed offset. This mode is planned to be upgraded to have automatic plotting regarding offset level from initialization with relative trigger value using offset level from the DQM. Then it can be shown, on which level the pulse was really registered. This mode is valuable to be connected with local trigger DQM mode in order to check, it the proper channel is triggering the event. More details about data integration with the Matlab and embedded PC platform on data postprocessing level can be found in  [10]. In order to fully verify the measurement system, not only it measurement capabilities, but also the functional features, all the time there should be access to the tokamak and its infrastructure.
Having those 2 triggers is possible to register plasma, after storage register the isotope spectra and then wait for another plasma experiment. This automatization involves and extension on the system on all of the levels of algorithms: • FPGA firmware, • Low-level control software, • Data registration software, • Matlab routines. In Fig. 4  is presented a layout of hardware triggering signals with correlation to plasma. The trigger 1 is providing information regarding very precise start of the acquisition. However, with use of GEM detectors, some calibration/ reference measurements should be done with the 55 Fe sources during idle time. For that reason, second trigger is planned to be involved. Having it configured as a pretrigger, it is possible to measure isotope during idle time, and reinitiate the system just before plasma (2 minutes should be well above the requirements).
The simulation works continuously, thus giving possibility to test the system as it would be working on tokamak hall during whole measurement day. The design has been also integrated with data management software and Matlab, described in  [10]. Fig. 4  Triggering system including 2 external hardware triggers: plasma trigger and pretrigger IV. SUMMARY In the paper are described an upgrades for a new measurement system for plasma measurements. It uses a multichannel GEM detector with more than 100 channels. It consists an analog stage and FPGA for data preprocessing and streaming. With use of FPGA it is possible to provide unique feature of postprocessing data based on raw signals, selected by the FPGA. Whole spectra, i. e. topological, energetical with userselectable time resolution are produced by high-end embedded server at postprocessing stage.
This approach is different then the one used at JET tokamak  [13] ,  [14] , where all of the data were computed in the FPGAs. The main difference is that implementation of complex algorithms, e. g. pile-up resolution, clustering, etc. is difficult in FPGAs, especially where multiple channels need to be considered. In the current approach Matlab or C algorithms are working on raw data, allowing high flexibility in modifications of the algorithms, and also its validation. The multichannel GEM-FPGA SXR measurement system was working on WEST tokamak during 2019 plasma campaign. The first results shows good correlation with other diagnostics, as described in  [1]. Due to preparation for more automatic functionality of the system as well integration with the WEST tokamak database, new modes have been developed.
This work has been carried out within the framework of the  EUROfusion Consortium  and has received funding from the  Euratom  research and training programme 2014-2018 and  2019-2020  under grant agreement No  633053. The views and opinions expressed herein do not necessarily reflect those of the  European Commission. This scientific work was partly supported by the  Polish Ministry of Science and Higher Education  within the framework of the scientific financial resources in the year 2020 allocated for the realization of the international co-financed project No  5125/H2020-Euratom/2020/2. A. Wojenski  is with  Warsaw University of Technology ,  Institute of Electronics Systems , Poland.
[35]. These were 3D printed (acrylonitrile butadiene styrene plastics; Dimension Elite 3D printer, Stratasys Ltd. , Eden Prairie, MN, USA) and used to calibrate the position of the respective detectors relative to the fiducials at the distal end of the opto-nuclear probe  [35]. An oscilloscope (PicoScope, By simultaneously recording the position and orientation of the opto-nuclear probe and its 1D probe readings (sample rate of 0. 5 s), software algorithms could be used to extrapolate the geometrical source location of the readings. A modified version of the declipse 6. 0 software (SurgicEye GmbH) was used to reconstruct a tomographic 3D volume based on the gamma readings (i. e. an fhSPECT scan as previously described  [8] ,  [38] -  [40] ). A tomographic 3D reconstruction of the fluorescence readings (i.
Due to the above-mentioned detection differences, the customized fhFluo software was configured different to that of the fhSPECT (settings are shown in table  1 ). To accommodate for the quick detection fall-off and typical tissue attenuation of fluorescent signals  [9] ,  [48] , the volume of interest (VOI) used for the fhFluo scans was limited to a depth of 20 mm, while the fhSPECT VOI depth was configured at 160 mm. For both fhSPECT and fhFluo imaging options, scan reconstruction was performed 'on-the-fly' (i. e. during the 1-3 min scan acquisition). To ensure similar software performance, the number of voxels (392000) used was equal for both modalities. As a result, the reduced scan volume of the fhFluo yielded twofold smaller voxel dimensions as compared to the fhSPECT scans.
B. Imaging Resolvability and Quantification Figure  3a  depicts the distinct differences in the resolvability outcomes obtained using the different modalities. The FIS-00 displayed the highest resolution: allowing separation at an edge-to-edge distance of 0. 5 mm. The newly introduced fhFluo was second best, discriminating sources at 1 mm edge-to-edge. The CrystalCam came third with a resolvability of 2 mm, while the fhSPECT came last with a resolvability of 6 mm. For the freehand imaging options the declipse 6. 0 software was able to segment separate navigation targets for the tracer sources (depicted as virtual red and gray targets within the image hotspots; see Fig. 3 ). Because of this segmentation, navigation and relative hotspot quantification became possible (see Fig. 3b ). For the latter, analysis of the fhSPECT images of the resolvability phantom yielded an average absolute inaccuracy of 3.
ACKNOWLEDGMENT The authors would like to gratefully acknowledge the surgical staff of the  NKI-AVL (Amsterdam , the  Netherlands)  for assistance in the operating room. Furthermore, they would also like to thank  Sven van Leeuwen  ( Interventional Molecular Imaging Laboratory, Department of Radiology, Leiden University Medical Center, Leiden, the Netherlands ) and  Michael Boonekamp  ( Department of Technical Services subsection Development, Leiden University Medical Center, Leiden, the Netherlands ) for their assistance with the article illustrations and prototyping of the geometrical calibrators. Material support was provided by  Eurorad (Eurorad S. A. , Eckbolsheim, France ) supporting the study with a prototype opto-nuclear probe,  SurgicEye (SurgicEye GmbH, Munich, Germany ) allowing the authors to run their own prototype software on the declipseSPECT and  Hamamatsu (Hamamatsu Photonics kk.
Experimental set-up PA cells In  [7]  we demonstrated for the first time the possibility to quantitatively simulate photoacoustic signals using FEM software and PAM. Quality factors and resonance frequencies were compared with experimental ones demonstrating a very good agreement. We also go further at using the FEM model with PA cells of different shapes  [8]  and also measurement conditions where the repartition of the laser intensity across PA cell in the FEM model must be taken into account  [9] , for these studies the method has proved to be robust as well. To explain the remaining differences between FEM and experimental results, some technical characteristics were impossible to precisely determine and where p ~, T ~ and u ~ are respectively the pressure, temperature and velocity fields in the gas.
We do not propose new optimizations, but rather evaluate the standards-compliant solution. We produce the KPIs that an industrial user would expect before deciding whether a technology suits its requirements. To achieve this, we design a novel software-based platform called OpenBenchmark 1 , which uses a black-box approach to benchmarking a 6TiSCH implementation. The concept of the platform is that the user should not worry about network specifics, but rather obtain high-level KPIs of a 6TiSCH implementation. The black-box approach facilitates the use of the platform by users that are not experts in low-power networking and firmware design. The user uploads the 6TiSCH firmware image, selects the test scenario and launches the experiment (see Fig. 1 ). The platform takes care of testbed resource provisioning, firmware programming, data collection and processing, and presents the user with a set of KPIs.
It is important to stress that these results come from a vanilla open-source implementation of 6TiSCH. As each implementation can take different choices when implementing the standard, the performance of the implementations is likely to vary. As a consequence, these results should not be generalized as "performance of 6TiSCH". They should rather be seen as an example of a baseline when a reference open-source implementation of 6TiSCH is used. Furthermore, if application requirements are known in advance, many enhancements are possible. However, such optimizations are out of scope of this work. The contribution of this paper is threefold: • We obtain performance datasets of a reference 6TiSCH implementation in two test scenarios on two different testbeds and publish them under open-data licence 2  ; • We analyze the datasets and discuss KPIs of the reference 6TiSCH implementation in each case; • We design and implement in open-source OpenBenchmark and enable the community to leverage it for further evaluations or comparisons  3.
OpenBenchmark Platform OpenBenchmark automates the experimentation and network performance benchmarking on selected testbeds supporting Internet of Things devices compliant with the IEEE802. 15. 4 standard. OpenBenchmark instruments the execution of an experiment in real time, following the pre-defined test scenarios, and collects the data to calculate the network KPIs in a fully automated manner. Test scenarios are generic and derived from industrial requirements. A test scenario is mapped to an executable logic that runs concurrently with the experiment in the testbed. OpenBenchmark sends commands to trigger the desired actions of the firmware: configure radio transmit power, trigger application packet. The commands are sent to the Network Gateway, which processes and translates them into the potentially proprietary format expected by the firmware Implementation Under Test (IUT).
The Network Gateway may run at the testbed infrastructure and be physically connected to the serial port of IUTs, or run at OpenBenchmark premises and communicate with the IUTs over an emulated serial port. This emulated serial port is provided through the software component of the companion OpenTestbed project  [26] , which transports the serial data over the MQTT protocol. OpenBenchmark provides the necessary integration and provisioning of the OpenTestbed software on supported testbeds, such that this complexity is hidden from the user. This allows the user to focus on the protocol aspects of the firmware, while the performance evaluation is entirely handled by OpenBenchmark through the Application Programming Interfaces (APIs) exposed by compliant firmware projects.
3. Latency: 101 and subscriber. It publishes the events coming from the network towards the OpenBenchmark platform, needed to calculate the KPIs. It subscribes to the commands that the SUT should adhere to, coming from the Experiment Orchestrator. • Experiment Controller. A component in charge of testbed node reservation, firmware flashing, and launching the necessary software components that run at testbed infrastructure side. The Experiment Controller bootstraps the testbed infrastructure by opening an SSH connection with each embedded computer in the testbed, and starting the execution of the MQTT publish/subscribe component in charge of emulating serial ports of the devices. The serial port emulation software (OpenTestbed) makes the testbed nodes appear to the Network Gateway as if they were physically connected.
The Experiment Controller also starts the execution of the Network Gateway that can run either on OpenBenchmark or user premises and of the PHP backend that runs locally on OpenBenchmark premises. • Experiment Orchestrator. A component in charge of orchestrating the SUT according to the selected test scenario. The Experiment Orchestrator interprets the test scenario files and instruments the experiment based on the interpreted data. The Experiment Orchestrator acts as an MQTT publisher and publishes to the broker the commands that the SUT needs to adhere to. The broker then dispatches these commands to the OpenBenchmark Agent based on the subscription to the common MQTT topics. • Performance Event Handler. A component in charge of handling performance data events coming from the SUT. Based on these events, Performance Event Handler generates the experiment data sets and calculates the KPIs.
The Performance Event Handler acts as an MQTT subscriber and receives events from the SUT, which it then uses to calculate the KPIs. • Web server. A Laravel-based (PHP) backend and Vue. js-based frontend allowing the user to access the OpenBenchmark platform through a graphical interface. The backend serves as a bridge between the frontend and the rest of the OpenBenchmark components that are implemented in Python. The backend provides a RESTful API that enables the use of OpenBenchmark by 3 rd party applications.