dataesr/scientific-paragraphs-categorization huggingface dataset:
(Figure  4C ). Other master TFs such as CEBPB, which was previously described as a major transcription factor regulating the expression of genes involved in inflammatory responses  [46] , and the ETV6 transcriptional repressor, which is known to play a critical role in hematopoiesis  [47] , are described as being regulated by CEBPA within the reconstructed regulome but not expressed within the protocol described by Chen et al. (Figure  4C ). These cumulative observations strongly support for a suboptimal activation of the core transcription regulatory circuitry driving microglial differentiation when using the protocol described by Chen and colleagues, which is most likely due to the partial activity associated with the over-expressed factor CEBPA. In fact, the read count enrichment at the CEBPA locus observed in the RNA-seq samples issued from the CEBPA over-expression generated by the protocol described by Chen and colleagues, reveals a shorter gene expression version than that observed in RNA-seq samples issued from all other protocols as well as those related to the fetal and adult microglia control datasets (Figure  4D ).
In this context, it would be essential to reconsider the strategy, this time using endogenous promoter activation systems, such as the use of RNA-guided gene activation by CRISPR-Cas9-based transcription factors  [51]. Finally, the presented core transcription regulatory circuitry provides means to enhance microglia differentiation protocols, but also to evaluate potential deregulated core transcription regulatory circuits, which might arise in the context of neurodegenerative diseases, which, for instance, can be modeled with the help of 3-dimensional cerebral organoid systems. S1 : Public Datasets and their associated identifiers (GSM) used in this comparative study (Excel file), Table  S2 : Differential gene expression readouts (DeSeq2) (Excel file), Table  S3 : Microglia-specific up-regulated genes identified in this study (Excel file), Table  S4 : Master regulatory indexes per TF assessed by TETRAMER (Excel file).
(GSE97744); Muffat et al. (2016) [32] (GSE85839); Douvaras et al. (2017) [27] (GSE97744); McQuade et al. (2018) [26] (GSE117829); Trudler et al. (2021) [29] (GSE169065); and Chen et al. (2021) [30] (GSE163984).
The PCA graph reveals the stratification of all iMGL samples on three major clusters. The first cluster is composed by iMGL samples issued from protocols developed by Muffat et al. , Douvaras et al. , and Trudler et al. and presents a striking similarity with the in vivo microglia control samples. The second cluster, separated from the first cluster because of PC2, is composed by iMGL samples issued from protocols developed by Abud et al. and McQuade et al. Finally, the third cluster present in the monocytic region of the graph presented the iMGL samples generated by Chen et al. (B) Similarity and divergency matrix (in percent) for each of the iMGL datasets compared to the control microglia samples. This analysis is based on the upregulated genes (2-fold change; adjusted p-value < 0. 01) assessed in each of the iMGL samples relative to the corresponding induced pluripotent stem cell (iPSC) precursor samples.
The transcription factors SPI1 and CEBPA, which were over-expressed in the protocol described by Chen et al. , are part of group (a), as highlighted by the "*". (B)Cell ontology analysis was performed for each of the TF groups described in (A). (C) SPI/CEBPA co-regulatory network displaying their first TF neighbors within the master players listed in (A). The color-code associated with each node corresponds to the groups described in (A). Similarly, edges are colored in agreement with the color of the source node. (D) RNA-sequencing read count enrichment at the CEBPA locus for iMGL datasets issued from the different protocols (green) as well as the fetal and adult control samples (red). Notice the shorten read count enrichment pattern observed for the sample associated with the protocol described by Chen et al.
The transcription factors SPI1 and CEBPA, which were over-expressed in the protocol described by Chen et al. , are part of group (a), as highlighted by the "*". (B) Cell ontology analysis was performed for each of the TF groups described in (A). (C) SPI/CEBPA co-regulatory network displaying their first TF neighbors within the master players listed in (A). The color-code associated with each node corresponds to the groups described in (A). Similarly, edges are colored in agreement with the color of the source node. (D) RNA-sequencing read count enrichment at the CEBPA locus for iMGL datasets issued from the different protocols (green) as well as the fetal and adult control samples (red). Notice the shorten read count enrichment pattern observed for the sample associated with the protocol described by Chen et al.
The following are available online at https://www. mdpi. com/article/ 10. 3390/brainsci11101338/s1, FigureS1:Step by Step visualization of RNA-seq readouts on QC Genomics platform, FigureS2: Volcano plots revealing the differentially expressed genes (DEGs) in iMGL datasets generated by the various differentiation protocols, FigureS3: Master regulatory Transcription factors predicted by TETRAMER for each of the differential expression data associated to each of the iMGL differentiation protocols, FigureS4: Consensus master transcription regulatory circuitry driving microglia differentiation, Table.
Supplementary Materials: The following are available online at https://www. mdpi. com/article/ 10. 3390/brainsci11101338/s1, FigureS1:Step by Step visualization of RNA-seq readouts on QC Genomics platform, FigureS2: Volcano plots revealing the differentially expressed genes (DEGs) in iMGL datasets generated by the various differentiation protocols, FigureS3: Master regulatory Transcription factors predicted by TETRAMER for each of the differential expression data associated to each of the iMGL differentiation protocols, FigureS4: Consensus master transcription regulatory circuitry driving microglia differentiation, Table.
blogspot. com, last access: 1 March 2021). In addition, many short courses and workshops are regularly organised (e. g. the "Using R in Hydrology" short course at the European Geosciences Union (EGU) General Assembly). The R-Hydro community is also very active in many R projects and websites, such as the rOpenSci project (https://ropensci. org, last access: 1 March 2021) or the many code examples available on Stack Overflow (https://stackoverflow. com, last access: 1 March 2021). R can be used at each step required for a basic study in hydrology (the hydrological workflow steps, see Fig. 3  of  Slater et al. , 2019 , that shows the growth of available packages over the last 10 years). Consequently, there has been an important increase in the growth and use of hydrological R packages (see Fig.
By referring to the provided documentation, any user should be able to make a choice and use a model in full knowledge of its characteristics, thus guaranteeing good practices  (Jakeman et al. , 2006). Unfortunately, despite the wish to standardise package documentation, especially regarding the rules imposed by the main R packages repository, the Comprehensive R Archive Network (CRAN; https://cran. r-project. org/, last access: 1 March 2021), it remains complicated and sometimes even daunting to select a package among the R packages containing hydrological models. Yet, to our knowledge, there has never been a published study dealing with the comparison of hydrological modelling R packages. This work should (i) enable any newcomer in hydrology, or even more experienced hydrologist, to knowledgeably employ one of the packages presented in this comparison and (ii) highlight possible improvements for future developments of the packages.
, 2019)  and a smaller computational demand. This makes it easier for users to employ the models. We based our search on the following four sources: the CRAN, GitHub (https://github. com/, last access: 20 September 2020), the R-Forge (https://r-forge. r-project. org/, last access: 20 September 2020) and a CRAN Task View dedicated to hydrology. 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 checking of packages or mailing lists and forums. Task Views are guides -proposed by the CRAN -on the main packages related to a certain topic. Many R packages are stored on the CRAN that contains more than 15 000 packages.
This type of unified comparison was, for example, employed in the framework for understanding structural errors (FUSE; see Fig. 3  of  Clark et al. , 2008)  to compare the structures of four models or to present the 40 models included in the MarRMOT toolbox (see Fig. 2  of  Knoben et al. , 2019). We selected an approach for this analysis that derives from the work of de  Boer-Euser et al. (2017, Fig. 3 ). This analysis aims at depicting the conceptual storages and fluxes at a spatial unit scale. More details about the diagrams are given in Sect. 4. 1 and Fig. 1. This analysis was reviewed by the package authors to ensure consistency.
User implementation 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. We try to put ourselves in the shoes of users who have to apply the models of the different packages and, therefore, need to understand which function they have to use, where to use it in the script and how to use it. In this regard, we propose a unified diagram of the connections between the main functions that we have been able to run (see Fig. 4 ). We use the term user function, which means that users have to write their own R function integrating, among others, the legacies illustrated on the diagrams. This analysis is intended for users familiar with R packages and aims at guiding users in their application of the hydrological modelling R packages.
Base packages, such as stats, and recommended packages (https: //cran. r-project. org/src/contrib/3. 6. 0/Recommended, last access: 10 June 2021), such as lattice, are not taken into account in this assessment, as they are packages installed by default. 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 to a large database, generating an ensemble in operational (flood) forecasting or 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 analysed the CPU time required for one model run, which was estimated from 1000 runs with the microbenchmark package  (Mersmann, 2019). We ran the packages on a computer with the following characteristics: random access memory (RAM) capacity -8. 00 GB; central processing unit (CPU) -Intel i5-8250U 1. 80 GHz; operating system (OS) -Windows 10 (64 bit), using the 3. 6. 0 (64 bit) R version. The models were run at a daily time step on a catchment where high flows mostly result from precipitation events in winter, i. e. the Meuse River at Saint-Mihiel (2543 km 2 ; from 1 January 1990 to 31 December 1999) and, for the packages integrating a snow function, on a mountainous catchment where high flows mostly result from snowmelt in spring, i. e. the Ubaye River at Lauzet-Ubaye (943 km 2 ; from 1 January 1989 to 31 December 1998).
The time series of precipitation and temperature at a daily time step were extracted by  Delaigue et al. (2020b)  from the SAFRAN countrywide climate reanalysis of Météo-France  (Vidal et al. , 2010). The potential evapotranspiration (PET) time series were calculated using the  Oudin et al. (2005)  formula. The streamflow data were retrieved from the "Banque Hydro" database  (Leleu et al. , 2014). For the use of some packages, a digital elevation model (DEM) with a resolution of 25 m by 25 m was derived from the BD ALTI DEM  (IGN, 2013). Only one parameter set is tested for each model.
dynatopmodel Driven by a desire to relax some of the assumptions of TOP-MODEL, the authors proposed a new version, i. e. the dynamic TOPMODEL  (Beven and Freer, 2001). In the original version, simulations of subsurface flows depend on a quasi-steady-state assumption for the redistribution of moisture at each time step  (Beven, 1997). Dynamic TOPMODEL relaxes this assumption to a non-steady kinematic wave solution for subsurface flows (between the similarity units) and allows other geographical information to be taken into account in the discretisation of the catchment -but with a simi-lar aim of grouping parts of the catchment into computational units for efficiency. The dynatopmodel package  (Metcalfe et al. , 2018)  includes this model and offers the technical features to prepare the basic data required to run the dynamic TOPMODEL.
HBV. IANIGLA The HBV model  (Bergström, 1976)  has been improved over the years, one of its most employed version being the HBV-96  (Lindström et al. , 1997). The HBV. IANIGLA package  (Toum, 2019)  enables the application of each component (i. e. snow, soil moisture and routing) of the HBV model indepen-dently. Other types of snow, soil moisture functions and routing functions are also implemented, which are derived 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).
hydromad The hydrological model assessment and development package hydromad  (Andrews et al. , 2011; Andrews and Guillaume, 2018)  suggests the following 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 is considered which distinguishes 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 11 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 preprocessing, calibration and post-treatment are made available by the package.
Dynamic TOPMODEL The dynamic version of TOPMODEL  (Beven and Freer, 2001)  is implemented in the dynatopmodel package and 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. 4. 2. The difference in terms of storages and fluxes between the model in the topmodel package and the model in the dynatopmodel package concerns the subsurface runoff and the water table. In the 1995 version of TOPMODEL, the water table is represented as a succession of quasi-steady states, whereas the dynamic TOPMODEL includes a time-dependent kinematic routing  (Beven and Freer, 2001; Metcalfe et al. , 2015). The saturated zone (brown rectangle) water level is predicted using implicit kinematic routing between (and within) the spatial computational units.
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. One would hardly acknowledge the differences between a computational unit of TOPMODEL 1995 and HSUs of dynamic TOPMODEL defined by the upslope area calculations. Nevertheless, these specificities can have a great influence on the final result and, consequently, the interpretations deriving from it. Please note that the high level of spatial discretisation enabled by some of the packages sometimes requires a demanding preprocessing to be carried out outside of the corresponding package (e. g. sacsmaR; see Sect. 5 and Table  6 ). In addition, please note that the recently released version of airGR (v.
Inputs and number of adjustable parameters Table  4  highlights the minimum requirements that have to be supplied to run one of the models. Other inputs can be used to increase model accuracy, such as satellite snow data to constrain the calibration of the snow function in airGR, snow cover areas for enhanced snow inclusion in HBV. IANIGLA or data concerning groundwater and surface water supply or withdrawals when running WALRUS. A digital river network can be used to set up the dynamic TOPMODEL in digital terrain analysis. The HBV. IANIGLA package includes five configurations of the HBV routing routine. These functions rely on either three or five 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.
HBV. IANIGLA provides an example on how to generate random time series of inputs. airGR includes several vignettes, for example on how to estimate parameters within a Bayesian MCMC framework. The WALRUS package is stored on the GitHub platform, where a complete set of documents, tutorials and data can be found (e. g. an R script to run a Monte Carlo parameter estimation procedure). A comprehensive user manual, with a structure that is different from the usual R documentation, can also be found on GitHub. sacsmaR is stored on GitHub with a vignette on how to use the different functions. hydromad offers a vignette, and nine demonstrations are available that deal with subjects such as how to estimate the model parameters or how to conduct a sensitivity analysis. Examples of sensitivity analysis and GLUE method  (Beven and Binley, 1992)  are available on topmodel's website.
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. Figure  4  shows the links between the main functions required to apply each package on a simple hydrology example (R scripts are provided in the supplementary documentation;  Astagneau et al. , 2020). 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 implementa- Table  7. Assessment of package documentation. Note: Description -information on the general purpose of the function and the associated possibilities; details -precise explanations of the function; arguments -description of the function arguments that requires details about the unit, the R object class and how to obtain it; value -description of the function outputs; references -related documentation where users can find more information on the function; examples -R commands to use the function (examples are considered as being comprehensive if they cover most of the functionalities and if there is an example for each function); data set -an example data set is provided and can be used with the package functions; steps between functions -explanations of the required stages to run the main functions.
Package 2. sacsmaR, TUWmodel and HBV. IANIGLA, on the other hand, whose functionalities are less extensive, rely on a very simple R structure. R objects preparations are left to the user (i. e. without particular specifications or requirements), who has to provide vectors of data time series. The sacsmaR and TUWmodel packages do not contain preprocessing functions to use their models with the spatialisation specificities explained in Sect. 4. 2. As the packages only integrate functions allowing one 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 desired plots by using the runoff outputs.
CPU times We hereby present the CPU time required for one model run with the selected packages (Fig. 5 ). As the hydromad package includes two implementations of the GR4J and IHACRES-CMD models, one coded in R and one coded in C (see Sect. 5. 3. 1), computation times were estimated for both implementations. Note that WALRUS computation times can vary depending on the selected parameter set. The results of Fig. 5  show that the packages based on models coded with a compiled programming language have lower CPU times than the packages integrating models coded in R. The CPU times associated with the packages integrating models coded with a compiled language have the same order of magnitude. The HBV. IANIGLA package has lower CPU times than the other selected packages. The CPU times associated with sacsmaR and the models coded in R of hydromad are lower than the CPU times of dynatopmodel and WALRUS (CPU times can also depend on the model implementation).
Towards helping users to use new models appropriately Appropriately using a new model is fundamentally difficult. Understanding the complexity resulting from the different modelling choices, the model inner consistency and whether it is appropriate for a specific research problem also depends on the perceptual model of the hydrology of a catchment (e. g. Wrede et al. , 2015; Beven and Chappell, 2021). Adding the difficulty of implementation in terms of software or programming language complicates this task even more. Flexible modelling frameworks, such as SuperflexPy  (Dal Molin et al. , 2020)  and FUSE  (Clark et al. , 2008) , have partially addressed these difficulties. However, their complex conceptualisation makes them more accessible to advanced modellers than to newcomers. The FUSE implementation for R available on GitHub is in need of active maintenance by the community (https://github.
Aspects of practical implementation and maintenance of packages The adaptability and efficiency of packages can also be assessed in terms of R structure. The choices that developers have made for their R packages, programming languages used for the core functions of the models and dependence on external packages for some functions have resulted in very different R structures. Using a compiled programming language for the core model functions (airGR, HBV. IANIGLA, hydromad, topmodel and TUWmodel) tends to lower CPU times and ease parameter estimation procedures, though computation times can also depend on algorithm efficiency, the choice of parameter estimation technique, number of parameters to be estimated and operations not related to the core model runs. As a result, applications on studies relying on a large database of catchments and uncertainty analysis procedures, such as Monte Carlo realisations, are easier with these packages.
This sometimes induces errors with functions that can no longer be run by users, which could, thus, reduce the durability of R scripts and, therefore, the transferability and understanding of methods and results. Slater et al. (2019)  identified key points for future developments of R in hydrology that would improve the transferability of methods. A structured approach when developing a package, user-friendly functions and the documentation are in line with the specific results of our analyses of practicalities. Developers are advised to consider these analyses, as R packages implementing hydrological models have the advantage of avoiding the requirement to recode the model or buy a specific software. Even if users need to learn the basics of the R language to employ one of these packages, this allows many modellers to save time and focus on modelling rather than algorithm issues.