dataesr/scientific-paragraphs-categorization huggingface dataset:
Monocular Approach Considering the comparison results shown below, it appears that Monodepth2  [30]  is the most suitable method if a monocular camera is used. This offers the best performance in terms of estimating distance and calculation time. However, it is important to note that Monodepth2 has been trained on the KITTI dataset and this one offers less good results on an unknown sequence. In both Figure  7  and Table  3 , results and comparison with the state-of-the-art approaches in terms of RMSE (Root-Mean-Square Error) between the estimated distance (given by the algorithm) and the ground truth for each pixel of a given frame.
Object Tracking Results We test the tracking algorithm in both indoor and outdoor environments. Initially, tests were performed indoors, the advantage being that it is easier to determine whether the predicted values diverge or not. The results can be found in Figure  10. We then carried out tests in the road domain using the KITTI dataset (see Figure  11 ). Here, we can see that the bike on the right is no longer detected from the frame (t + 1). The prediction of the Kalman filter is then used to estimate the position of this object. If this one is not associated with a detection before three frames, the algorithm deletes this target. Our method also allows for tracking a target even if it is not associated with a detect blob for up to three frames before it will be deleted. We can see in Figures  11  and 12  quantitative and qualitative results of our method over two different sequences of KITTI datasets.
Conclusions and Future Directions In this paper, we have presented an end-to-end deep learning based system for multi-object detection, depth estimation, localisation, and tracking for realistic road environments. For the object detection module, an effective detector based on YOLOv3 was proposed. Jointly, depth maps estimation has been introduced in order to render the localisation information of the detected objects. For this purpose, we make use of two different kinds of approaches, i. e. , Monodepth2 and MADNet to design the second module of object localisation. Finaly, a new object tracking method is introduced based on an improved version of the SORT approach. Extended Kalman Filter is presented to improve the estimation of object's positions. For each step, we set up various experiments over the large-scale KITTI dataset while comparing our proposal with the state-of-the-art approaches.
Overall, the reported qualitative and the quantitative results prove that our deep learning proposal is robust enough against challenges of road scenes. Ultimately, we aim to use our solution in both indoor (such as smart wheelchair for disabled people  [24] ) and outdoor (soft mobility for car and tramway) environments. The road and tramway domains are quite similar to outdoor environments, which allows the algorithms trained on the road domain to offer good performances when inferring on the tramway domain. However, due to the lack of a publicly available dataset for railway environments with 2D and 3D informations (barring the recently published RailSem19 dataset  [34] ), we are in need of acquiring our own dataset for this task. For this, we propose to extend the current version of our system by including a new stereoscopic sensor so that we can collect our own dataset under outdoor conditions with large and adjustable baselines.
Funding: This research is supported by both SEGULA Technologies and the ADAPT Project, which is carried out as part of the INTERREG VA FMA ADAPT project "Assistive Devices for empowering disAbled People through robotic Technologies" http://adapt-project. com/index. php The Interreg FCE Programme is an European Territorial Cooperation programme that aims to fund high quality cooperation projects in the channel border region between France and England. The Programme is funded by the European Regional Development Fund (ERDF)) and M2SINUM project (This project was co-financed by the European Union with the European regional development fund (ERDF, 18P03390/18E01750/18P02733) and by the Haute-Normandie Regional Council via the M2SINUM project).
Many R packages are stored on the CRAN that contains more than 15000 packages. Many other packages (around 1500) are only available on GitHub (https://github. com/) and some packages are stored on the R-Forge (https://r-forge. r-project. org/). Some of the packages stored on the CRAN are also available on GitHub or on the R-Forge. GitHub is a development platform based on the Git version control software. The R-Forge is a development platform specific for R packages. It is based on the Subversion version control software and offers tools, such as automatic build and check of packages or mailing lists and forums. Among these packages, some were designed for hydrological purposes. To identify as many packages as possible, we searched for packages on the CRAN, GitHub and the R-Forge by keywords.
Full list of selected hydrological modelling R packages The outcome of our selection is a list of eight packages that will be carefully compared throughout the paper. Here we give a first overview of these packages along with their related bucket-type hydrological models. The full list is presented in Table  1  with the main related documentation. Table  2  shows the snow models contained in the selected packages. The airGR package  (Coron et al. , 2020)  implements the models constituting the suite of Génie rural (GR) hydrological models  (Coron et al. , 2017)  which originate in the work of Claude Michel starting in the 1970s  (Michel, 1983). These models are parsimonious conceptual rainfall-runoff models that consider a catchment as a single entity (lumped). Several versions were developed over the years from the well-known GR4J  (Perrin et al.
, 2003)  to the GR6J model  (Pushpalatha et al. , 2011)  for improved low-flow simulations. A snow-accounting model called CemaNeige  (Valéry et al. , 2014 ) can be combined with the daily and hourly GR models or can also be operated independently. airGR includes a function to calculate potential evapotranspiration time series with the equation of  Oudin et al. (2005). Various technical features associated with the hydrological workflow from data pre-processing work to result analysis are offered. For the sake of brevity, only GR4J combined with CemaNeige will be assessed in the following analyses. airGR has a graphical user interface in the complementary package airGRteaching  (Delaigue et al. , 2018 (Delaigue et al. , , 2020a ), which will be analysed along with airGR. Table  1. List of the selected packages with their related models.
Package Version Repository Hydrological models Main references of the models airGR 1. 4. 3. 65 CRAN GR1A; GR2M; GR4J;  Mouelhi (2003) ;  Mouelhi et al. (2006) ;  Perrin et al. (2003)  HBV. IANIGLA HBV  Bergström and Lindström (2015)  hydromad snow. sim Andrews and Guillaume (2018)  sacsmaR SNOW-17  Anderson (2006)  topmodel None.
, 1997). The HBV. IANIGLA package  (Toum, 2019)  enables application of each component (i. e. snow, soil moisture and routing) of the HBV model independently. Other types of snow, soil moisture functions and routing functions are also implemented, deriving from the HBV model (see  Toum, 2019). This package also includes functions to calculate variables such as potential evapotranspiration with the method of  Calder et al. (1983)  or glacier discharge with the equations of  Jansson et al. (2003). The hydrological model assessment and development package, hydromad  (Andrews et al. , 2011; Andrews and Guillaume, 2018) , suggests two ways for treating rainfall-runoff modelling: either a single rainfall-runoff model is considered, which can be a model such as Sacramento  (Burnash, 1995) , or an effective rainfall framework, distinguishing between a soil moisture accounting (SMA) and a routing step as in IHACRES  (Jakeman and Hornberger, 1993).
A user has to choose the combination that best suits their requirements. hydromad includes eleven soil moisture accounting functions and six routing modules. A snow-accounting function can be added to the calculations when the IHACRES-CMD SMA is selected. Several functions for data pre-processing, calibration and post-treatment are made available by the package. In our next analyses, for conciseness purposes, we will only apply the Sacramento, IHACRES and GR4J models. The sacsmaR package (Taner, 2019) implements the well-known Sacramento soil moisture accounting model (SAC-SMA). In its original version, the SAC-SMA model was set with lumped parameters. In the sacsmaR package, the model can be run in a semi-distributed way (see Sect.
Consequently, the overland routine deals with storage excess coming from the saturated zones, routes the runoff on the hillslopes and generates a part of the flow that will then be routed by the channel routing. The saturated zone drainage reaches the channel baseflow and will thus be routed along with the surface runoff. A constant celerity time delay function (or lag function) is applied to route the sum of these two flows to the catchment outlet. The dynamic version of TOPMODEL  (Beven and Freer, 2001)  is implemented in the dynatopmodel package: conceptual storages and fluxes of the dynamic TOPMODEL are represented without taking the semi-distributed spatialisation into account (i. e. on a single hydrological response unit). Spatial characteristics of the package models will be dealt with in Sect.
The case of snow As presented in the previous section, some packages enable application of a snow function along with the hydrological models they include (airGR, HBV. IANIGLA, hydromad only for IHACRES-CMD, sacsmaR, TUWmodel and WALRUS). Depending on the package of interest, taking snow accumulation and melt into account does not involve the same spatial distribution. Four configurations were found possible. All these packages allow to proceed with snow calculations considering the catchment as a single unit. In that case, input data are aggregated at the catchment scale. HBV. IANIGLA, hydromad and WALRUS do not offer any other possibility regarding the spatial distribution of snow processes. The CemaNeige model of airGR is applied on different elevation zones of the catchment in order to take into account the important heterogeneity of snow.
, 2015 Metcalfe et al. , , 2018)). This also allows for connectivity between grids within the same HRU. Inputs can be spatially distributed if needed by associating each HRU with different rainfall and evapotranspiration data. HRUs thus have their own reservoirs. When it is required, a different parameter set can be assigned to every HRU. The HBV model of TUWmodel enables a very straightforward spatial configuration where the model is run independently on different zones (with different parameters and inputs), which can be subbasins, elevation zones or any area defined by the user. The discharge outputs from each zone are then summed up based on their relative area to the entire catchment. The Sacramento model of sacsmaR can be applied in different ways. During a preprocessing step (not provided by the package functions), the catchment can be divided into sub-catchments that can also include hydrological response units.
The sacsmaR package then enables assignment of a different set of parameters to each HRU as well as different data inputs. The water is run upstream to downstream through a hydraulic routing function based on  Lohmann et al. (1996). A large proportion of the packages that we have selected contain models that can be run as lumped models though some of them can rely on more complex spatial distribution with very specific characteristics. The most complex level of spatial distribution is enabled by the sacsmaR package (HRUs + sub-basins). Theoretically, it would be possible to run every lumped model on subbasins independently and sum the outputs with weights as permitted by one of the TUWmodel functions. We have noticed that there are thin boundaries between the different spatial configurations.
The HBV. IANIGLA package includes 5 configurations of the HBV routing routine. These functions rely on either 3 or 5 parameters to be estimated. The number of adjustable parameters associated with IHACRES-CMD depends on the selected routing function. When applying the exponential components transfer function with the structure identified in  Jakeman et al. (1990) , 6 parameters need to be estimated. For some models, several parameters may not require parameter estimation procedures but physical determination depending on the user's need and access to additional data. For instance, in the WALRUS package, a minimum of three parameters requires the use of estimation procedures, three parameters can either be calibrated or physically determined and the other ones are derived from physical properties of the catchment.
≈ mentations within the package (Shuffled Complex Evolution), or external packages, e. g. the differential evolution algorithm  (Storn and Price, 1997)  enabled through the use of the DEoptim package  (Ardia et al. , 2020). The plot function of airGR can display several variables (e. g. Fig. A1 ): time series of precipitation, potential evapotranspi-455 ration, actual evapotranspiration, temperature, snow water equivalent, simulated discharge, observed discharge and simulated minus observed discharge (residuals); interannual monthly median; correlation between observed and simulated discharge; cumulative frequency. dynatopmodel contains a function to plot the observed and simulated hydrographs along with the precipitation and actual evapotranspiration time series (mainly designed for short time series, e.
g. Fig. A2 ). hydromad integrates a function to plot simulated and observed hydrographs (including different simulation configurations and rainfall time 460 series, e. g. Fig. A3  and A4 ). This function can also plot the flow error, i. e. the criterion value for each point of the time series. A function to select and plot discrete events is also included in hydromad. airGR and TUWmodel offer a graphical interface for manipulating the models. WALRUS GUI is currently under development (see Sect. 4. 6 of  Brauer et al. , 2017). The airGR and TUWmodel GUIs rely on the shiny package  (Chang et al. , 2019)  that implements an R framework to build a web application. The GUI developed for the airGR package is proposed in the airGRteaching package  (Delaigue et al. , 2018 (Delaigue et al. , , 2020a)).
g. Fig. B2a ); a concise performance graphic displaying TS of precipitation, simulated and observed hydrographs, interannual monthly median, correlation between observed and simulated discharge and cumulative frequency (e. g. Fig. B2b ); TS of store levels and runoff components (e. g. Fig. B2c ); a model diagram displaying store levels, fluxes and unit hydrographs at each time of a selected temporal window (e. g. Fig. B2d ); a fact sheet with several hydrometeorological characteristics of the selected catchment (e. g. Fig. B2e  and B2f ). The simulation results and plots can be downloaded by users. The TUWmodel GUI  (Sleziak, 2019)  is available online (https://webaapptuwmodel. shinyapps. io/TUWteaching/). This interface includes five example datasets on which the TUWmodel parameters can be manually adjusted (see Fig.
We consider two types of scientific articles in this analysis: articles that were written in order to present the packages; and articles using the packages and made by one of the package authors. Websites usually contain elements such as video tutorials, list of publications mentioning the package, examples, user groups. Vignettes and external documentation are not required when creating a package but can be very useful for thorough understanding of the packages and models (Table  7 ). TUWmodel @ WALRUS @ and GH ity analysis and generalised likelihood uncertainty estimation (GLUE) method  (Beven and Binley, 1992)  are available on the topmodel's website. Articles related to the TUWmodel and the WALRUS packages were not written to present the packages themselves but the models included in these packages.
Other examples of TUWmodel were found in the appendixes of  Ceola et al. (2015). Users are invited to report bugs or ask for additional support via email and, for some packages, by creating GitHub (hydromad, sacsmaR, WALRUS) or GitLab (airGR) issues. A user group related to the hydromad package was created for additional support. Looking at Table  5 , it appears that there is an important heterogeneity in the availability of package functionalities. Packages such as airGR, hydromad and WALRUS integrate many functionalities from data management to result analyses whereas the other packages mostly contain the main functions to run the associated model. We can differentiate two types of packages in our study: packages guiding the user with functionalities in line with the hydrological workflow and, to a certain extent, constraining the use to reduce potential errors and packages allowing more flexibility but less guidance and thus potentially more errors.
A guide for user implementation Considering the previous analysis along with package distinctiveness in terms of R implementation raises the question of how to use the packages containing hydrological models. Indeed, one would expect consistent inter-comparison studies between https://doi. org/10. 5194/hess-2020-498 Preprint. Discussion started: 17 October 2020 c Author(s) 2020. CC BY 4. 0 License. the different models, leading to more reliable analyses. Package practicalities can also be assessed through an analysis of the links between the main functions of a package. Such an examination could be useful to provide guidance regarding package application. Here, we try to put ourselves in the shoes of a user who has to apply the models of the different packages and therefore needs to understand which function they have to use, where in the script and how.
In this regard, we propose a unified diagram of the connections between the main functions that we have been able to run (Fig. 4 ). This figure is intended for users familiar with R packages and aims at guiding users in their application of the hydrological modelling R packages. We therefore provide R scripts enabling the application of each package on a simple hydrology example (supplementary documentation). The provided R scripts show the basic R commands required to test one parameter set on a French midland catchment (The Meuse River at Saint-Mihiel) and, for the packages integrating a snow-accounting routine, on a French mountainous catchment (The Ubaye River at Lauzet-Ubaye). Parameter estimation and uncertainty quantification are important steps of the hydrological workflow. Multiple sources of epistemic uncertainty are associated with simulations of hydrological models  (Beven, 2016) , such as uncertainty in the available catchment data that can lead to incorrect model hypotheses  (Beven, 2019)  or uncertainty arising from the difficulty of models to represent the properties affecting river flows.
Several methods can be used to take uncertainty into account when estimating model parameters. For example, hydromad includes a function to determine feasible parameter sets and estimate prediction quantiles by applying the GLUE method. The FME package  (Soetaert and Petzoldt, 2010)  enables estimation of parameters within a Bayesian Markov Chain Monte Carlo (MCMC) framework. The diagrams of Fig. 4  indicate three main groups of packages in terms of R implementation: 1. airGR, hydromad and WALRUS integrate many R functions with complex connections and inner consistency. These choices regarding the R implementation follow similar steps from data formatting to result analysis. They aim at reducing potential errors arising from R codes written by the modeller, whose choices are guided throughout the hydrological workflow.
It also eases the application of a new model by end-users. 2. sacsmaR, TUWmodel and HBV. IANIGLA, on the other hand, whose functionalities are less extensive, rely on a very simple R structure. R objects preparation are left to the user (i. e. without particular specifications or requirements) who has to provide vectors of data time series. As the packages only integrate functions allowing to run the core models, the R structure only depends on the models inputs and outputs, whether it is with one function integrating all the modules of the model (TUWmodel) or with separate components (HBV. IANIGLA and sacsmaR). Unlike what is offered by the packages of the first group and dynatopmodel, the user has to code the plots they desire by using the runoff outputs. 3. As pointed out in Sect. 3. 2, operating the two versions of TOPMODEL requires spatialisation preprocessing steps.
dynatopmodel and topmodel integrate these steps at the beginning of the workflow, through more (dynatopmodel) or less (topmodel) complex functions and connections. The spatial operations also require the use of an external package to deal with raster data. The remaining steps of the workflow are then very similar to those of the second group of packages. airGR and hydromad contain parameter estimation functions and objective functions that are integral parts of their struc- The path to better guidance to avoid mistakes in application of the models -which implies more rigorous methods that include, for instance, uncertainty analyses -is a tricky road facing the wide heterogeneity of packages in terms of R structure and models in terms of modelling choices. One could imagine better harmonisation of packages taking advantage of other packages' strengths (e.
Three packages integrate models entirely coded with the R language and four packages with a compiled programming language (C, C++ or FORTRAN). The hydromad package integrates some models coded in R, some in C or C++, and some with both implementations to facilitate both debugging and fast execution. Table  9  summarises whether packages require other packages to run the models. A package is considered as being dependant if one of its functions cannot be run without downloading another package. A package is not considered as depending on any other package when the use of an external package is only suggested in an example or in one of the related articles. R Core Team packages, such as stats, are not taken into account in this assessment, as they are packages installed by default. Three of the selected packages integrate functions requiring the use of external packages.
CPU times From a user perspective, computation times can be meaningful to determine whether a package is suitable for a specific study. Short computation times are usually very well appreciated, especially when dealing with finer time steps or more complex spatial discretisations. Applying a model on a large database, generating an ensemble in operational (flood) forecasting or 610 performing Monte Carlo runs for uncertainty analyses can also significantly increase computation times, hence some of the packages include some compiled code to speed up the production runs of the model. We hereby present the CPU time required for one model run, which was estimated from 1000 runs (Fig. 5 ) with the microbenchmark package  (Mersmann, 2019). The models were run at a daily time step on a midland catchment where high flows mostly result from precipitation events in winter, France  (Vidal et al.