dataesr/scientific-paragraphs-categorization huggingface dataset:
In the same line of research, the authors in  [32]  described a concept combining a traffic and driving simulator using Open Street Maps (OSM)  [33]  and the hardware-accelerated OpenGL renderer based on SUMO, Glosm, to generate the visualization of the three-dimensional module  [34]. An interactive motion-based traffic simulation environment was also proposed in  [35] , where the authors implemented a system involving multiple types of simulation, including driving vehicles such as cars, motorbikes, bicycles, as well as pedestrians. For a further example of a driver-centric simulator, please refer to  [36]. Within this work, SUMO has been used to create traces of vehicles' movements, which was then utilized by Unity 3D as a means to generate the model traffic, without explicit communication between Unity 3D and SUMO.
Given the fact that the simulation is seeking to examine driver behavior and does not pay particular attention to the metrics associated with this interaction with traffic, data collection for speed and position was not recorded even if available. As previously mentioned, a connection between SUMO and Unity 3D was created via the TraCI protocol. First, Unity 3D sent a connection request to SUMO, and once it was accepted, the behavior of the simulation could be modified from Unity. TraCI provides the platform for the communication protocol, ensuring control and modification of the simulation process parallel with SUMO. Beyond this, the system also is capable of retrieving any elements within the system that are being implemented in the simulation, such as edges, junctions, traffic lights, or vehicles.
Sumo Network and Traffic in Unity 3D The SumoCon script was in charge of the interactions between SUMO and Unity 3D. It contained a set of functions, each of which was used for different purposes. When the simulation scene was run for the first time, the SUMO simulation was set, and initial SUMO objects' information was retrieved by Unity. SUMO data were categorized into two groups: • static, meaning that the information did not change during the simulation; • dynamic, referring to the information that needed to be updated every simulation step.
To make the state of the information accessible, getter methods are created for each of the variables retrieved from the TLS as described below: It contains information about from which lane we come (from), to which lane we are going next if we are in the current lane (to) and through which lane, junction we will reach the future lane to which we are going (through). • getCompleteRedYellowGreen(id): returns a list with the complete program of the TLS; total number of phases, duration of each phase, and state of each phase. In addition to the process described to retrieve the traffic lights from SUMO and display them in Unity 3D, Algorithm 8 computes whether a traffic light is located at the end of the current lane of the UCV. refers to the list of links and c to the current lane. The function returns either a string with the traffic light ID or a null value.
Once the experiment was finalized, a qualitative questionnaire was completed by the participants. The analysis of the answers showed that 80% of the participants were satisfied with the simulator and the TLA system implemented. The scenario in which they were driving was scored as realistic, and they were also able to recognize the physical surroundings. They found the simulated vehicle characteristics to be realistic as well. Motor sound and advancement of steering wheel physics also contributed to the enhanced perception of realness. Table  2  shows the items of the questionnaire and the results of the analyzed data. Table  2. Items of the questionnaire and the correspondent results from the analyzed data (Likert scale range: 1 = strongly disagree to 5 = strongly agree).
Study area The study was conducted during May-July 2016 in Wielkopolska province, Poland (52 • N, 16 • E). Habitats cover mainly mixed farmland, with small patches of forest and waterbodies. Information on the density of cuckoos and potential hosts is reported in  Tryjanowski & Morelli (2015). Data were collected at 97 sites distributed over agricultural landscapes with minimum distances of 1 km between study sites.
Field observations Data were collected 1 May-15 June 2016 6:00-9:30) on days without rain or strong wind. In experimental sites during each of the four trials birds were counted using the point-count method during a period of 5 minutes before start of the playback (I. P. A. method following  Järvinen, 1978). Additionally, data from point-counts were summarized and used to describe the breeding bird community around experimental sites where a stuffed cuckoo was presented. At each of the 97 study sites data were collected four times (treatments a-d, see above), and calls of the cuckoo (short and long) and the woodpigeon (short and long) were presented randomly. In one day only one treatment was presented, and the study site was visited the following days to collect data on reaction to all prepared calls.
Statistical analyses We used Generalized Linear Models (GLMs) to analyze the reaction of birds after playback (synthetic calls). Models were fitted assuming a Poisson distribution (for number of birds reacting and number of real cuckoo males reacting) after having explored the distribution of variables as suggested by  Box & Cox (1964) , using the package 'MASS'  (Venables & Ripley, 2002) , and 'glmmADMB' in R  (Fournier et al. , 2012; Skaug, Fournier & Nielsen, 2013). The treatment and the covariates entered in the full model were respectively type of synthetic call (a, b, c, d), date, time and distance to houses. Model selection was performed using the package 'AICcmodavg' in R  (Mazerolle, 2016). The best model was selected considering both the smallest Akaike's Information Criterion (AIC) and largest Akaike weights, because this model has the strongest support for the data  (Burnham & Anderson, 2002; Mazerolle, 2016).
Still, the number of spectra treated exceeds 280 million. It is a major challenge to process such large amounts of data, and in addition to the reliability and robustness of the scientific processing software, the RVS pipeline has to cope with technical issues, such as computational time, data storage, backup, and I/O management for the scientific software and database access. In this paper, we describe the data processing behind the radial velocities presented in DR2 and the performance achieved. A companion paper  (Katz et al. 2018 ) presents a posteriori checks of the DR2 radial velocities and the dependence of the accuracy and precision of velocity measurements on stellar properties.
Auxiliary radial velocities of standard stars The radial velocity standard stars used by the wavelengthcalibration modules have V R that is constant in time and precise at the level of 0. 1 km s -1 , as determined from high-precision ground-based observations. They are needed as external calibrators to fix the RVS V R zeropoint. The auxiliary V R catalogue, including the 2568 standard stars with the highest precision and accuracy used in wavelength calibration, is described in  Soubiran et al. (2018). The V R zeropoint of that dataset is set by the SO-PHIE spectrograph  (Perruchot et al. 2008). By being calibrated on this dataset, the RVS V R zeropoint should agree with that in  Soubiran et al. (2018). The wavelength calibration software module, which works per CCD and FoV (Sect. 5. 3), requires standard stars covering the AC dimension of each CCD in order to produce good results in each calibration unit (a calibration unit consists of a dataset covering 30 hours of observations and containing the calibrator stars; see also  Sect.
Auxiliary radial velocities of validation stars The validation dataset consists of stable stars for which a groundbased radial velocity is available. Table  1  also lists the catalogues used for validation in the automated verification workflow (Sects. 7. 8 and 9)  and in the off-line validation  (Katz et al. 2018). Figure  3  shows the G ext RVS magnitude distribution of the stars processed by the pipeline. The selection of the stable stars was based on the following criteria: -CU6GB-val: All the stars from  Soubiran et al. (2018)  that were not used as CU6GB-cal were used as validation stars. These stars are presumed to be stable based on at least two high-precision ground-based observations over a minimum time baseline of 30 days and with a standard deviation < 0. 3 km s -1. It includes observations with standard deviation < 0.
Auxiliary atmospheric parameters The atmospheric parameters (T eff , log g and [Fe/H] ) of the observed stars are used for two tasks in the pipeline: to select the synthetic template that matches the stellar spectrum (the template is selected based on the minimum distance between the atmospheric parameters of the star and those of the synthetic spectrum, Sect. 6. 5); to select calibration stars with a suitable spectrum for the calibration in question. Specifically, the wavelength calibration needs spectra with pronounced Ca ii lines, therefore the selection is 4500 < T eff < 6500 K. Because the T eff measurements obtained with Gaia data in  Andrae et al. (2018)  were not available to the pipeline, a list of auxiliary atmospheric parameters was compiled. It contains parameters, mostly T eff , for ∼1.
Synthetic template spectra For those stars without atmospheric parameters in the auxiliary catalog (the majority), a pipeline module, called DetermineAP (Sect. 6. 5) was used to determine their atmospheric parameters by cross-correlation with the star spectrum. The template that matched the RVS spectrum best was selected, and the atmospheric parameters associated with this template were attributed to the star. This restricted template spectral library, containing 28 spectra, was created for DetermineAP, and contains a subset of the synthetic spectra data  (Sect. 4. 4). The following arguments were used to construct this restricted synthetic template data set: -The set should be relatively small, so that the computation time is short. -The steps in the atmospheric parameters should be chosen based on changes in the spectrum morphology.
An additional smaller discontinuity is produced by the change in the Gaia scanning law from the ecliptic pole scanning law (EPSL) to the nominal scanning law (NSL). Gaia was operated in EPSL during the first weeks of operations (between 25 July to 21 August 2014), with the spin axis in the ecliptic plane and the FoV scan through both the south and north ecliptic poles  (Gaia Collaboration et al. 2016). Based on these discontinuities, five breakpoints were defined that correspond to these events, and the entire calibration data set was separated into six trending epochs. A calibration model was produced for each trending epoch. In addition to the wavelength calibration, the bias nonuniformity (bias NU) effect (Sect. 5. 1), which produces jumps in the spectra (see Fig. 10 ) that compromise the V R estimation even in bright stars, needed to be calibrated.
The calibration coefficients were computed by a dedicated RVS pipeline, and were shown to be stable for the DR2 purposes  (Hambly et al. 2018) , so no temporal variation was implemented. The other calibrations that were necessary to treat the spectra but that had only second-order impact on the V R estimation of bright stars were not included in the pipeline. These are the linespread-function in the AL direction (LSF-AL), the CCD blemishes and saturation level, and straylight. The calibration model used for these was determined off-line using a limited data set, or the pre-launch data. We describe here the calibration models we used to obtain the DR2 V R , both those produced by the pipeline, and those produced off-line.
Electronic bias non-uniformity Hambly et al. (  2018 ) (see also  Cropper et al. 2018)  described the bias NU effect, its calibration procedure, the resulting parameters and their temporal evolution in detail. A constant voltage offset is applied to the CCDs prior to digitalisation. This electronic bias is needed to avoid negative signal values and wrap around zero-digitised units (ADU) at low signal levels. This constant bias level is measured from the prescan data that are acquired every 70 minutes in bursts of 1024 samples. The constant (uniform) bias calibration consists of extracting the median signal from the bursts of prescan data for each CCD and of applying a linear interpolation to these data to obtain the bias offset that is to be subtracted from the spectra at any time. In addition to this constant bias, owing to the manner in which the Gaia CCDs are operated, the electronic bias applied to an acquired sample prior to digitisation contains an unstable component such that the bias value applied to a given sample depends on the details of the read-out process, in particular on the number of flushes (fast skipping of the inter-window pixels before the sample), the position of the glitches caused by interruptions of the serial clocks during the operation of the parallel clocks, and the common baseline (the difference between the prescan bias and the image area bias).
The scatter map is used to obtain the background level to subtract from the RVS spectra, depending on their AC position on the CCD and on the rotation phase of the satellite during their acquisition. The scatter map used in the pipeline was produced off-line using the VOs acquired only during the first 28 days of Gaia operation, when Gaia was in EPSL mode, in the first trending epoch. It is used to correct the entire data set, and temporal variations are not considered. To produce the scatter map, the software proceeds in two steps: 1. MakeScatter is responsible for treating the single VOs. First, the VO spectra with truncated windows, 2D windows, or windows that are affected by a CCD defect are discarded to remove other signal contamination from the background measurements. Then, the VO spectra are corrected for the bias NU.
The background flux level is calculated as the median flux of all valid samples in the VO spectrum after excluding the samples that are affected by cosmic rays or saturation. These results are stored in data files (one per VO), called Scatter, that also contain all the information needed to create the scatter map: the CCD and the AC position of the VO, including the CCD row as well as the solar phase of Gaia at the acquisition time. 2. MakeScatterMap uses all the accumulated Scatter data and combines them based on their position, to create one 2D map. A map covers one revolution time in x and all CCD AC positions in y. It is composed of a grid with 2160x50 cells (10 seconds AL and 157 AC pixel per grid cell), chosen in order to have a sufficient number of background Scatter measurements per cell (18 measurements).
In order to quantify the consequences of neglecting time variations and using the constant scatter map obtained off-line with the EPSL data to process all of the DR2 data, the average background level of the EPSL map was compared with the average level of the background over the last five months of data covered by DR2. During this period, the daily pipeline (which started operation in December 2015, with the primary goal of tracking and verifying the status of the RVS) estimated and monitored the average background level every 30 hours. Figure  6  shows the variation in average background level  (in CCD strip 16)  between December 2015 and May 2016 compared with the average EPSL scatter map level from August 2014. The figure shows that the mean background level during EPSL was higher than during the period between December 2015 and May 2016.
Wavelength calibration The RVS is not equipped with wavelength-calibration lamps as these are difficult to implement in TDI operation. Hence a selfcalibration approach is adopted, where some of the RVS observations themselves are used to calibrate the instrument  (Guerrier et al. 2007 ). The basic principle of the RVS wavelength calibration is that the wavelength value associated to a sample can be expressed as a function of the FoV coordinates (η, ζ) of the source at the time when the sample crosses the CCD fiducial line (Sect. 3. 1). Each FoV and CCD of the RVS is calibrated independently and continuously using the data acquired during time intervals of 30 hours in order to obtain one wavelength calibration every 30 hours. This time period, over which the calibration stars and the characteristics of the instrument are assumed to remain constant, defines the wavelength calibration unit (CaU) duration.
Line spread function (LSF-AL) The Gaia point spread function (PSF) is approximated by the cross product of the AL and the AC line spread functions (LSF). The LSF-AL and LSF-AC calibrations are not implemented in this pipeline version. The LSF-AC calibration will be implemented for DR3 and will be used for deblending the spectra and to estimate the flux loss out of the windows. The LSF-AL, on the other hand, is needed in this pipeline version. It contains information on the resolution of the RVS spectra and is used to convolve the synthetic spectra to generate the templates. The LSF-AL calibration was therefore estimated off-line, using the 28 days of EPSL data, and was used for the data acquired before the first decontamination at OBMT 1317. For the remaining data, the LSF-AL calibration was derived using on-ground data.
In future data releases, the LSF calibration will be included in the pipeline and the estimation will be improved. The RVS resolution element is monitored daily in each configuration in the first-look (FL) pipeline  (Fabricius et al. 2016)  since the beginning of the Gaia operations in order to detect defocusing. In the FL, the resolution element is determined by measuring the width of some unresolved Fe lines via correlation with a mask. The FL diagnostics show that the resolution element is in general very close to the nominal value (3 pixels, corresponding to R=11 500), with a maximum degradation of ∼ 3% owing, in general, to gradual de-focus. The degradation of the resolution element appeared much more important, ∼ 20%, at the beginning of the operation before OBMT 1317, when the Gaia optics suffered from high contamination by water ice.
The high contamination is also shown by bright values of the magnitude zeropoint in Fig. 9. Two LSF-AL models were estimated, both using principal component analysis  (Lindegren 2009) : one is the on-ground LSF-AL, which was used to generate the templates of all the RVS spectra acquired after the decontamination at OBMT 1317; the other is the in-flight LSF-AL, which was calculated using the EPSL data (before the 1317 decontamination). This was also used to generate the template for the RVS spectra acquired before OBMT 1317 to take into account the strong contamination of the optics. No other time variation was considered. The two LSF models are shown in Fig. 8. The on-ground LSF-AL model profiles that were used after OBMT 1317 were produced for each CCD and FoV. They were based on 15 wavebands, each of 2 nm, covering the range 846-874 nm (there are 15 LSFs per CCD and per FoV in total).
Time variations and inter-CCD AC variations were neglected. The in-flight LSF, before the 1317 decontamination, was derived for each CCD and FoV. It was based on one waveband centred at 858 nm and covering 24 nm (there is one LSF per CCD and per FoV in total). It is independent of wavelength, and time variations and inter-CCD variations were neglected. It was modelled using the PCA as a linear combination of eight basis functions: LSF = 7 n=0 h n H n , (5) where h n are the linear combination coefficients of the basis functions H n. The basis functions were selected from a set of on-ground basis functions  (Lindegren 2009 ) in order to model the nominal LSF profiles adequately (which were chosen to represent all the data configurations). Deriving the observed LSF is equivalent to finding the coefficients h n.
G RVS zeropoint The pipeline provides the calibration and temporal evolution of the G int RVS zeropoint (ZP G RVS ), which is useful for monitoring the contamination during the period covered by the DR2 data set. The ZP G RVS is estimated for each CCD and FoV and for each CaU (30 hours). The calibration is made using the Hipparcos stars listed in the auxiliary file as reference (Sect. 4. 6) , for which we have estimated the reference magnitudes G ref RVS. -First, the RVS spectra of the calibration stars (Sect. 4. 6) were selected; they were already cleaned and calibrated in wavelength. Spectra with a window size AC < 10 were discarded to limit the flux loss, which typically left about 2000 stars per CaU. -The ZP is estimated for each spectrum by ZP spec = G ref RVS + 2. 5 log(T otFlux), where G ref RVS is the magnitude coming from the auxiliary file, and T otFlux is the integrated flux between 846 and 870 nm, divided by the exposure time for one CCD (4.
Cleaning and reducing the RVS spectra This section describes the process responsible for transforming the RVS windows into cleaned and calibrated spectra. This pro-A&A proofs: manuscript no. 32836_corr cess is applied to the spectra to be used for calibration (i. e. in the workflow Calibration Preparation of Fig. 2 ) using initial, first-guess calibrations, and is then applied to all the spectra, this time using the final calibrations (this is done in the FullExtraction workflow of Fig. 2  in charge of preparing the spectra to be used to extract the radial velocities). The spectra entering this process have already undergone the on-board processing  (Cropper et al. 2018) , and the IDT window reconstruction  (Fabricius et al. 2016 ) (Sect. 3). They have also passed the Ingestion step (Sect.
Background removal The background level is subtracted from each spectrum using the ScatterMap obtained as described in Sect. 5. 2. Based on the AC location of the RVS window, and the Gaia Solar phase angle, the position of the window in the ScatterMap is found and the corresponding straylight level is subtracted from the spectrum. The spectra falling in ScatterMap regions where the straylight level is higher than 100 e -pix -1 in the 4. 4 s exposure are flagged and excluded from the processing. In total, another ∼ 0. 3% of spectra have been excluded for this reason. The straylight level is assumed here not to vary with time. The consequence of neglecting time variations, and using, for the entire data set, the ScatterMap obtained using the data obtained only during EPSL, is that, in general, the level of straylight subtracted from the spectra is too high (see Fig.
A description of a more detailed study on the template mismatch errors is in preparation by  Blomme et al. (in prep. ). In the next data release, the spectroscopic pipeline will include the atmospheric parameters produced with Gaia data and more appropriate templates will be assigned to the stars to improve the V R estimation of hot and cool stars. Table  2 : Performance of the module DetermineAP and template mismatch errors. Each of the 28 templates in the first column is identified with its atmospheric parameters (T tpl eff , log g tpl , and [Fe/H] tpl ); nb is the number of transits for which the template has been selected.
Combine template atmospheric parameters DetermineAP estimates the atmospheric parameters for each transit of the star. Then, for each star, the parameters found most frequently are selected and the synthetic spectrum with these parameters is used to derive the V R of the star. These parameters are published in DR2 (Sect. 2) and provide information on the synthetic spectrum that was used to obtain the star V R. The transit information is combined in the workflow Combine Template (shown in Fig. 2 ). Even though it contains only simple functionality, this workflow is technically important because it is the first that uses information from all the transits. It runs after all the data were processed by the other workflows, and together with the following STAMTA workflow, works per source.