dataesr/scientific-paragraphs-categorization huggingface dataset:
3 4 5 were generated using the 'SANS instrument model' for the D33 instrument Simultaneous fitting of Bragg peaks in the 2D data from the vortex lattice in YNi 2 B 2 C, summed over the rocking curve  (Levett et al. , 2002). with a dilute and perfect sphere form-factor model of radius 60 A ˚, zero polydispersity, contrast 6 Â 10 À6 A ˚À2 and concentration 1%. Background-scattering components of a 1 mm thick sample of D 2 O buffer solution were modelled on the basis of real measurements. While the methodology describing the instrument resolution as the convolution of various real-shape distributions in divergence, wavelength etc. is the same both for the treatment of data in GRASP and for the 'SANS instrument model', the precise implementation and code are different. These are effectively the reverse processes of each other.
Instrument configuration files and data loaders Instrument descriptions in GRASP are based on text-based configuration files that are read from the instrument_ini directory and included into the GRASP menu of available instruments upon launching the program. New instruments can be included into GRASP in a relatively straightforward manner even in the compiled version of the software and do not need to be pre-compiled into the code. A minimum instrument configuration file contains information such as the instrument and facility name, a description of the data-file naming protocol, and a pointer to the MATLAB-coded data loader. The data loader can be executed even within the compiled version of the code. The detector(s) configuration and geometry are defined by the detector type ('tube', 'multiwire' or 'banana') along with parameters defining the number of pixels, pixel size and detector deadtime, and several default geometric parameters describing detector position, translations, rotations and offsets relative to the sample position.
Default detector mask files, flat-field detectorefficiency files and relative detector efficiencies can also be specified. The maximum detector sizes that are useable within GRASP are essentially limited by computer memory and speed but are perfectly reasonable for detectors commonly used in neutron instrumentation. The largest detectors currently described and used in GRASP are those of the new D16 cold neutron diffractometer with a banana detector of 220K pixels and the D22 in situ small-angle X-ray scattering instrument with 1M pixels. There are no specific requirements in terms of data formats, with ASCII, HDF, NeXuS HDF variant  (Ko ¨nnecke et al. , 2015) , binary or SPE formats all commonly used in the scattering community. The only requirement is that native MATLAB routines are able to open and read the files.
Often data from neutron sources contain histogrammed detector images of single measurements or time slices for TOF or kinetic data that are most easily catered for in GRASP. GRASP now offers some limited support for reading and histogramming event-mode data as new instruments, methods and data formats appear. Data-file names must have an incremental numeric part to best use the capabilities of GRASP for the treatment of large series of data but can contain non-incremental or non-numeric parts before and after followed by the filename extension, e. g. aaa012345bbb. nxs. Data-loader code must accept an input argument containing the path and filename of the data to be loaded. The output from the data loader must be a single structure-type variable with fields including the detector counts, statistical errors, and key instrument parameters such as the sample-to-detector distance and the wavelength required for the calculation of scattering vector magnitudes within GRASP.
Summary In this article, we have described the software package GRASP designed for the treatment, reduction and analysis of multidetector data from SANS instruments at the ILL and other neutron sources. GRASP has been available to the ILL and wider SANS user communities for more than 22 years. It serves as a vital tool in the process from measurement to publication, and is crucial for rapid inspection of data on the beamline during the course of experiments. The primary philosophy of GRASP is that the correction of data for background scattering, detector efficiencies, parallax data correction and geometric corrections is performed in two dimensions with the user aware of the 2D result at all times. Data reduction and extraction into 1D scattering curves, such as I versus |Q|, proceed directly from these 2D fully corrected and calibrated data.
A second fundamental architectural feature of GRASP is related to the fact that an experimental investigation often may involve many individual measurements requiring a parametric analysis through, for example, changing sample concentration, hydrogen-deuterium ratio or sample-environment parameters, with data analysis often involving the cross referencing and co-analysis of many individual data sets. The 'depth' to a given GRASP worksheet number provides this additional dimension to accommodate and regroup individual measurements as part of a single experimental investigation. This additional dimension of data storage and analysis also lends itself usefully to the analysis of TOF SANS data. GRASP has been developed in the high-level MATLAB programming environment, which offers a professionally maintained programming infrastructure tailored specifically to facilitate easy and rapid development of code in science, computer programs engineering and industrial contexts.
Although a commercial software, licence fees remain 'reasonable', at least for academic use, and are in line with those of other commonly used commercial software such as for word processing and presentation. Many GRASP users choose to use the code directly within MATLAB and contribute user modules, bug fixes and additional functionality directly. On the other hand, MATLAB code can be 'compiled' (or more correctly packaged in a runtime form), allowing licence-free distribution of the runtime version of GRASP. The development of GRASP has often been criticized in its potential for single-point failure in relying on, for the most part, a single code author (i. e. the author of this article) and lacking a formal project organizational structure. Up until now this has never posed a significant problem, with contingency in place in terms of freely accessible, well written, organized and commented code and developer documentation.
It is this author's opinion that, for a project on the scale of GRASP, the absence of a heavy software project structure allows for creativity in the development of new features and rapid response to bug reports or feature requests. The maintenance of the code has been successfully handed over to co-workers or summer students for certain periods during GRASP's history, thus demonstrating that code maintenance and development by others is indeed possible. The many instrument scientists, users and summer students who have contributed or maintained the code over the years demonstrate the ease and ability for persons not familiar with the code to rapidly get up to speed. The single-author approach is not uncommon in the provision of successful scientific software  (Rodrı ´guez-Carvajal, 1993; Weber et al.
, 2016; Qureshi, 2019; Katcho et al. , 2021)  but goes against the growing trend of large collaborative software projects, and the benefits and inconveniences that such organizations bring  (Arnold et al. , 2014; Wuttke et al. , 2022). As of March 2022, and with a reorganization of the ILL's scientific computing group, GRASP is now an officially maintained ILL software program.
Acknowledgements Professor Don Mck. Paul  provided the initial impetus for GRASP and highlighted the requirement for a graphical software package tailored for the analysis of anisotropic, diffraction-based or parametric SANS measurements. Don is also greatly thanked for the initial introduction to neutron scattering, SANS and MATLAB. Thanks also go to  Peter Timmins  and the various ILL directors through the years for allowing me to pursue this project in an informal manner without the imposition of a formal project structure. Dirk Honecker  is greatly thanked for taking charge of the maintenance of GRASP between 2015 and 2019 and for the implementation of polarization and analysis corrections. A great many scientists, collaborators, students and interns have contributed to, supported or been valued long-term users of GRASP, too many to mention, but they include  Bob Cubitt ,  Lionel Porcar ,  Anne Martel ,  Simon Levett ,  Isabelle Grillo ,  Sylvain Prevost ,  Ralf Schweins ,  Ted Forgan ,  Jonathan White ,  Morten Eskildsen ,  Elizabeth Blackburn  and  Alex Holmes.
For a SDR operating in antennas or transceivers, memory footprint is not an issue and all tasks run on CPU cores. This paper is an extension of a previous work  40  in which we presented a complete, real-life example, digital communication system (a DVB-S2 transceiver) running on both x86 (Intel ® ) and ARM (Cavium ® ) CPUs, that meets real-time requirements for ground-satellite transceivers. This paper includes the DVB-S2 software transceiver as well as the following new contributions: • A DSEL based on C++ to build parallel dataflow graphs for SDR signal processing, supporting loops (including nested and input-dependent ones), conditionals, early exits, pipeline and fork/join parallelism; • A set of micro-benchmarks to analyze the time taken by the different constructs; • In-depth insights to understand the performance and the genericity of the proposed DVB-S2 transceiver (for instance, two pipeline implementations are compared and its implementation with the proposed DSEL is shown); • A comprehensive and "as fair as possible" comparison with State-of-the-Art DVB-S2 software transceivers.
RELATED WORKS Many languages dedicated to streaming applications have been introduced  41, 42, 43, 44, 45, 46, 47, 48. These languages are often variants of the cyclo-static dataflow model and propose automatic parallelization techniques such as pipelining and forks/joins. The concepts presented in StreamIt  41  are very close to the ones implemented in the proposed DSEL. However, StreamIt does not provide dynamic loops and conditions. FeedbackLoop and SplitJoin are closer but their scheduling is static. On the other hand, some concepts like a dedicated control messaging system are not implemented in the proposed DSEL. Even if it is still possible to embed control messages in the data, this is less advanced than what StreamIt does. In Dardaillon et al. work  49  , a full compilation chain for SDR, based on LLVM on heterogeneous MPSoCs.
This is promising but it differs from our approach. Indeed, we chose to integrate our language into C++, making the DSEL compatible with any C++11 compilers. Works are also tackling OS and hardware aspects of SDR  50, 51, 52. However, the studied SDR systems are much simpler than those addressed in this paper. Few solutions specifically target SDR sub-domain so far. GNU Radio  53  is the most famous one. It is open source and largely adopted by the community. It comes bundled with a large variety of digital communication techniques used in real life systems. GNU Radio models digital communication systems at the symbol and frame level. The philosophy is close to typical algorithm descriptions from the signal processing literature, which enables fast prototyping of new digital processing algorithms.
To the best of our knowledge, this new version of GNU Radio breaks the compatibility with the existing systems designed with GNU Radio and is not yet fully implemented. However, this new version goes in the same direction as what we propose and we hope that some contributions of this paper could help the GNU Radio project. To the best of our knowledge, GNU Radio does not implement the duplication mechanism presented in Section 3. 3 and we show this is a key mechanism for high throughputs and scalability. Besides, a new construct in the next section (cf. the switcher module in Section 3. 1) allows the design of loops and conditions for SDR systems, not yet supported by GNU Radio where only static directed acyclic graph can be managed. Some other works are focusing particularly on an SDR implementation for a DVB-S2 transceiver.
Hereafter are the projects we have identified: • leansdr. A standalone open source project  56. A low-density parity-check (LDPC) bit-flipping decoder  57  is chosen. The project does not support multi-threading. • gr-dvbs2rx. An open source out-of-tree module  58  for GNU Radio. One of the motivation of this project is to increase the throughput compared to leansdr. The project is open-source and we were able to perform a fair comparison. The results are presented in Section 5. 5. • Grayver and Utter. In a recently published paper  18  , they succeed in building a 10 Gb/s DVB-S2 receiver on a cluster of server-class CPUs. The implementation is closed source, making fair comparisons difficult.
Then  3 ,  4 and  5 tasks will be executed and  sel will select the  5 output instead of the  1 output, and so on. Fig. 3b  shows how the tasks are regrouped into sub-sequences. It enables to build the execution graph illustrated in Fig. 3c. The corresponding pseudo code of the presented loop is shown in Alg. 1. One can note that in the proposed DSEL there is no limitation to include nested loops schemes. The loop pattern is common in iterative demodulation/decoding. This is why it is required in a DSEL dedicated to SDR. As an exception rule in the graph construction, the select task is added to the graph when its last input socket is visited (while all the other tasks require all input sockets to be visited). Fig. 4  illustrates a switch structure. The same switcher module presented in while loop structures is necessary.
Listing 3 and Listing 4 present the source codes corresponding to the loop example in Fig. 3  and the switch example in Fig. 4 , respectively. One may note that the proposed DSEL does not introduce new C++ keywords, it is only based on tasks binding. Thus, it can run on any C++ (version 11) compilers. In the previous listings, the Switcher module is a keyword of the DSEL (but not a C++ keyword). When the sequence is created, the task graph is parsed and the sw object is processed as an exception. The C++ runtime dynamic cast feature is used to recognized objects of Switcher class. Thus, the proposed DSEL can be seen as an interpreted language. The code corresponding to the tasks graph is generated only once when the sequence object is created (line 16 in Listing 3 and line 23 in Listing 4).
). In each computational task, an active wait of the same amount of time is performed. Four types of tasks are used: computational tasks , select and commute switcher module tasks  sel and  com resp. , and iterate tasks  to determine paths in loops and switches ( = control task). Evaluations ran on a single core of an Intel ® Core ™ i5-8250U @ 1. 60 GHz. The Turbo Boost mode has been disabled. This processor has a 15-Watt TDP that matches embedded system constraints. The GNU C++ compiler version 9. 3 (on Linux Ubuntu 20. 04 operating system) has been used with the following flags: -O3 -march=native. Though duration of a  task is controlled by the programmer, we measured a constant 135 ns overhead due to the DSEL and to the system call behind the std::chrono::steady_clock::now() function.
Sequence Duplication In a fully dataflow-compliant model, there is no need to duplicate the sequence because a stateless task is always thread-safe. In the proposed DSEL with stateful tasks, a clone method is defined for each module to deal with internal state and private memory (stored in the module). The clone method is polymorphic and defined in the Module abstract class. It relies on the implicit copy constructors and a deep copy protected method (overridable). It is the responsibility of the ModuleImpl developer to correctly override the deep copy method and to make sure the duplication is valid for this module. The deep copy method deals with pointer and reference members. If the pointer/reference members are read-only (const), then the implicit copy constructor copies the memory addresses automatically.
Stage 2 is duplicated four times to increase its throughput by four as we know that its latency is approximatively four times that of Stage 1. In general, a preliminary profiling phase of the sequential code is required to guide the pipeline strategy. In the proposed DSEL, each task can be automatically profiled: its duration is computed with the C++11 chrono standard library. For a given task, the API returns the average latency, the minimum latency and the maximum latency. In this work, the following strategy has been applied: 1) run a sequence of tasks 100000 times (without duplication parallelism) and 2) print the latency of the tasks. Then, knowing the sequential duration of each task, it is up to the system designer to find an efficient pipeline stages decomposition. Listing 7 presents the C++ DSEL source code corresponding to the pipeline description in Fig.
Open Source Integration with AFF3CT Toolbox The proposed software implementation of the DVB-S2 digital transceiver is open source §. It is described with the help of the AFF3CT toolbox  61. AFF3CT is a library dedicated to the digital communication systems and more specifically to the channel decoding algorithms. In this paper, we extend AFF3CT with the presented DSEL to the SDR use case while keeping the interoperability, reproducibility and maintainability philosophy initiated in the toolbox. Some components are directly used from the AFF3CT library (tasks  Tx {1,3,4,5,6} in Fig. 8  and tasks  Rx {14, 15,16,17,19} in Fig. 9b ) and are optimized for efficiency. For instance, knowing that the LDPC decoding is one of the most compute intensive task, an existing high performance SIMD implementation is used, based on the portable MIPP library  62.
Evaluation This section evaluates the receiver part of the system. The transmitter part as it is not the most compute intensive part and high throughputs are much more easier to reach. All the presented results have been obtained on two high-end NUMA machines. One § DVB-S2 digital transceiver repository: https://github. com/aff3ct/dvbs2. ¶ AFF3CT-core DSEL repository: https://github. com/aff3ct/aff3ct-core. An high performance LDPC decoder implementation with the inter-frame SIMD technique is used (the early termination criterion has been switched on). This choice has the effect of computing sixteen/four frames at once in each task of the receiver (depending on the x86 or ARM target). It negatively affects the overall latency of the system (by a factor of sixteen/four). But it is not important in the video streaming targeted application.
The source code modifications we made are available on a fork of the project #. Tab. 5 presents the per block normalized throughputs of gr-dvbs2rx and of this work (considering the gr-dvbs2rx pipeline decomposition). For each GNU Radio block the tasks equivalence with our system is given. We measured an overall information throughput of 14. 9 Mb/s. As GNU Radio pins each block to a thread, the throughput performance is driven by the slowest block (here bch_decoder_bb). gr-dvbs2rx uses 10 threads (same as the number of stages). If we applied the same decomposition without the duplication of the stage 7 our receiver will have been limited to the throughput of the BCH decoder (6. 9 Mb/s). With the duplication technique the stage 7 is automatically dispatched on multiple threads and its throughput is approximately multiplied by the number of threads.
CONCLUSION In this article, we introduced a new DSEL designed to satisfy SDR needs in terms of expressiveness and performance on multicore processors. It allows the definition of stateless/stateful tasks, dynamic control and early exits. First, we evaluated it on real-world representative micro-benchmarks and showed that its scheduling overhead is negligible for tasks longer than 4 s. Then, we evaluated a full software implementation of the DVB-S2 standard built with our DSEL and the AFF3CT library for tasks. This implementation is the fastest open source software solution on multicore CPUs. It matches satellite real time constraints (30 -50 Mb/s), which demonstrates the relevance and efficiency of the DSEL. This is the consequence of two main factors: 1) the low overhead achieved by DSEL, 2) an efficient implementation of the pipeline technique, where one stage, parallelized, reaches saturation.
Recently, a study has explored the available databases and the scientific literature to identify existing nonvalidated ED characterization methods that could be prioritized for validation in missing regulatory key areas  (Zgheib et al. , 2021). In the EU, the challenge for the regulatory agencies to identify and to reduce exposure to EDs is increasing due to the recent and emerging regulatory changes. Among the measures addressing EDs in the Chemical Strategy for Sustainability are the development of new and effective test methods for ED identification (Communication from the commission to the European parliament, 2020). Those tests could further be part of a coherent integrative testing strategy (ITS) which could be in an integrated approach to testing and assessment (IATA)  (Grignard et al.
, 2022). In the EU, the recognition of the lack of methods has led to the funding of research programs such as the EURION cluster to Improve Identification of EDs (https://eurion-cluster. eu/)  (Street et al. , 2021). This cluster, composed of eight independent H2020 projects funded by the EU, was formed in 2019 to jointly develop and improve testing methods to identify EDs regarding major outcomes (metabolism disruption, female infertility, neurodevelopmental defects, etc…) to be integrated in testing strategies, as well as to Adverse Outcome Pathways (AOP) to support regulatory decisions under a Weight of Evidence approach  (Bajard et al. , 2022). The H2020 OBERON project (http s://oberon-4eu. com/) (Audouze et al. , 2020) , which is part of EUR-ION, aims to develop a battery of new alternative test methods for identification of EDs related to metabolic disorders using the concept of IATA  (Street et al.
Implementation of the SAQ The use of the SAQ is fully anonymous. In agreement with the European Regulation on personal data ((EU) 2016/679), no personal data is collected or recorded by Université Paris Cité that developed the SAQ, and maintains the web interface. The user can choose, or not, to get in contact with the Pepper platform through a specific contact form available on the web interface. If the user wishes, he/she can share information, only with Pepper, and get help and answers about specific questions. All e-mail exchanges are managed with PHPMailer (v 6. 6) (https://github. com/PHPMailer/PHPMailer). If the user encounters technical problems (access to the SAQ, difficulties to download the pdf with the results…), an e-mail can be sent for assistance to the laboratory of Université Paris Cité that created the web interface.
The implementation of the ReadEDTest was done using the programming language PHP v7. 4 (https://www. php. net/releases/7_4_0. php), which also allows a long-term maintenance. Answers and results of the SAQ can be downloaded by the user in a table format (. xls) and/or as a pdf format, both including a radar chart. All these data are generated using the programming language python (v3. 9. 2) (https://www. python. org/ downloads/release/python-392/) using the modules openxl v3. 0. 10 (https://openpyxl. readthedocs. io/en/stable/), xlsxWriter 1. 1. 2 (https ://xlsxwriter. readthedocs. io/index. html) and matplotlib v3. 5. 2 (https://doi. org/10. 5281/zenodo. 7084615) and the PHP module fpdf (v1. 84) (http://www. fpdf. org/). In parallel, the results are sent to Pepper for information but without any personal data.