dataesr/scientific-paragraphs-categorization huggingface dataset:
B. The mean shift algorithm for cluster recognition Mean shift is a recursive algorithm based on the iterative calculation of the mean of points within a given region. Considering an ensemble {x i }, for each point the mean value m i of the neighbor points NH(x i ) is calculated recursively via a kernel function K(x i , x j ) via m s,i = x s,j ∈NH(x s,i ) K(x s,i , x s,j )x s,j x s,j ∈NH(x s,i ) K(x s,i , x s,j ) , with s = 1 and x s=1,i = x i for the first step. Then the procedure is repeated considering instead of the initial points x i , the mean values of the previous step, x s,i = m s-1,i , until convergence or the maximum number of allowed steps is reached. Different points belonging to the same cluster are identified by the vicinity of the final m s,i values. With the present implementation, via a Fortran module in NestedFit, the identification of the neighbor points NH is determined by the Euclidean distance d(x i , x j ) < D, with D selected by the user.
IV. CONCLUSIONS We present a new application of cluster recognition to a nested sampling algorithm for the evaluation of the Bayesian evidence and posterior parameter probability distributions. For this matter, we selected the method of the mean shift, a robust and simple classical cluster recognition method widely used in the machine learning community. This clustering algorithm proved itself well adapted to critical data analysis when several likelihood maxima are present. It has been implemented in the program NestedFit and tested with two different benchmark cases, proving its efficiency in exploring the parameter space without excluding any region. As a consequence, the computation time is reduced by a factor at least eight. At the same time, a smaller value of the estimated evidence uncertainty is obtained.
ACKNOWLEDGMENTS M. T. thanks the  Alexander von Humboldt Foundation  that provide the financing to attend the MaxEnt2019 conference. M. T. would like to express once again his deep gratitude to  Leopold M. Simons  who introduced the author to the Bayesian data analysis and without whom this work could not have been started. We thank  D. Schury  and  E. B. for the carful reading of the manuscript. 20 In addition, we would like to thank  Lorenzo Paulatto  for his help for the introduction of git and github for NestedFit future version development and sharing. The development of this program would not be possible without the close interactions and discussions with many collaborators that the author would like to thank as well  R. Grisenti ,  A. Lévy ,  D. Gotta ,  Y. Litvinov ,  J. Machado ,  N.
Radliński  [31]  applied data-mining techniques to a large set of IT project data (ISBSG dataset) to identify the correlations among RE practices (e. g. , RE techniques, documentation developed in a project) and the overall project results. Rapp et al. [32]  developed a questionnaire-based method of RE process assessment and validated it by assessing several industrial and semi-industrial projects. They also stressed that such a method must minimize the assessment effort and provide a real business value to the assessors and organizations undergoing the assessments. Bormane et al. [3]  analyzed 12 software projects from a major Latvian company, comparing Waterfall/Agile and small/large projects. They found that the Agile approach required much lower cost of change and enabled a more accurate effort and budget estimation in the case of large projects.
They also analyzed elicitation techniques used in Waterfall and Agile projects but were not able to draw conclusions from the datasets used. Liechti et al. [21]  proposed an approach for a continuous process improvement for Agile teams that uses analytical dashboards based on data from software supporting tools, for example. Their paper, however, does not provide many details on the metrics used and impact observed; this is possibly due to non-disclosure agreements. Verner et al. [39]  surveyed practitioners from Australia and the U. S. , gathering data from 164 projects. Their findings indicate that effective requirement elicitation and requirement management are the most important contributing factors to project success. Bjarnason et al. [2]  performed an interview-based exploratory case study investigating gaps in the communication of requirements.
When the component is ready, it is passed on to testers, who verify its quality. This is followed by a phase of fixing any defects and stabilizing it, resulting in concluding the work on the component. Another increment dedicated to another component and following the same workflow starts subsequently. Such a process continues until the whole product is ready; then, delivery to the customer takes place. The Agile practices are mostly related to the work of the development team and include self-organizing teams, a prioritized work list, daily stand-up meetings, and retrospectives. The software projects run by the company are supported by integrated Confluence 1 and Jira 2 tools (both provided by Atlassian) as well as an associated time-tracking plugin. Confluence is a software tool based on the idea of a wiki, enabling collaborative work on shared documents.
It is used by analysts to document all requirements (both generic and detailed). The requirements are available to other project participants (like developers or testers) who can ask questions or report requirement defects by adding comments to particular fragments of the specification. The company's policy is to register each query related to the requirements. In addition to the versioning mechanism provided by Confluence, this allows us to track the evolution of the requirement specification (including fixing the defects of particular requirements). All such changes are also timestamped. Jira is an issue-tracking tool that can be used for bug tracking and/or managing Agile development. In the software projects of the discussed company, Jira is applied for both purposes. Apart from the typical use of defining the issues representing the product features and development tasks (plus updating their statuses and reporting the work effort), requirements engineering activities are also strongly supported by this tool.
Study design The data from Jira and Confluence can be exported to a spreadsheet format. We received the data from the above-mentioned projects in such a form and used it to conduct our study. Additionally, we could contact some people involved in these projects who were able to provide us with background information that is not necessarily registered in the supporting tools (e. g. , the requirement elicitation techniques applied or stakeholder attitude). We started this research with the intent of exploring the quantitative impact of RE on requirement quality and on the work done in other areas of an IT project. We had not formulated more-specific research questions a priori, because such a study was dependent on the data we could obtain (unlike with a controlled experiment). For instance, if data about requirement-related defects was not available (because a company's procedures had not required reporting them or the supporting tool does not allow us to distinguish them from other issues), it would be impossible to investigate any consequences of such defects.
RQ2 The second question explores the correlation between requirement quality and rework. Requirements quality is measured in the same way as in RQ1 -by the percentage of requirements that contained defects. The rework, understood as the work that has to be done because of any defects (and could possibly be saved in the absence of such defects), turned out to be difficult to measure. When analyzing the data about the effort reported by the project participants, it was impossible to reliably distinguish the ordinary work and rework caused by defects. We were only able to capture it in a partial manner by identifying (on the basis of background information provided by the project participants) the people who were not initially involved in the considered projects but were engaged later on a temporary basis to deal with the consequences of the requirement defects.
Discussion of our approach As presented in the previous section, the data stored in the Jira and Confluence tools as part of the usual development activities (without any additional reporting) could be used to investigate some aspects of the impact of the different RE practices used among the considered projects. We presented a single study that we conducted, but we believe it can be generalized; i. e. , similar analyses can be applied to the data from other projects supported by such tools. Jira is one of the tools most widely used in software projects, especially those that apply Agile methods or at least some Agile practices (like the company presented in this paper). The results of the most recent Version One survey  [40]  announced Jira to be the most popular Agile management tool. Confluence is a team-collaboration tool offered by the same manufacturer and easily integrated with Jira.
It is clear that an evaluation approach dedicated to such a toolset is likely to have widespread application. The case study demonstrated that it is possible to explore various correlations and investigate any possible causal relationships, even despite the fact that we had no influence on the processes and work procedures of the considered projects -we merely received data from those projects that had already been finished. We could not even plan a priori the exact research questions, as we were dependent on the contents of the received dataset. Such datasets should be considered as a potentially rich source of information. Various kinds of research studies can take advantage of them; this can serve as a post-mortem analysis (using the data from concluded projects, as we did), action research (where the outcomes of decisions made in an ongoing project are investigated), or even controlled experiments (which, however, are unlikely in an industrial setting, as discussed in Section 1).
) would significantly reduce the effort necessary to obtain the information presented in Table  2  and Figure  2. If such a categorization was given when submitting a defect report, the effort would drop from the many hours we spent on classifying the defects to zero. It is also quite likely that such a field would help analysts understand any reported problems and introduce their corrections. This would require a change in reporting practices and in the software tools; however, Jira is known to be a very configurable tool. Some information is unlikely to be extracted from the datasets exported from tools. In our case, such missing information included requirement elicitation techniques, for example. Each requirement stored in Jira had a source (a stakeholder) assigned, but there was no information about the RE technique used to elicit a given requirement; from our knowledge, this is a rather typical situation.
Fortunately, we were able to gather the information we needed (including elicitation techniques) from the people involved in software projects. Access to such people is usually possible when researchers cooperate with a company; this is even more likely if the company is investigating its own data. To facilitate such analyses, Jira could be extended with a dedicated plug-in. We reviewed the Atlassian Marketplace 3  website, which lists more than 1500 Jira plug-ins; however, we found no such plug-in. This seems to be a niche worth exploring.
), as RE activities unfortunately tend to be occasionally neglected in practice. The most natural direction of any future work is to conduct more case studies and gather a larger and more diversified dataset. We are currently negotiating with two other companies to gain access to the databases of their tools. This would provide us with a significantly larger set of software projects, including more-complex ones that record their activities in the form of several thousands Jira issues, for example. A further step that we consider is the design and implementation of a Jira plugin to support analyses similar to those described in this paper. However, this would require decisions about particular metrics to be computed, and we believe it should be preceded by identifying the questions and metrics considered most useful to analysts, project managers, and other industry practitioners.
, 2013) , and many have called for "the end of model democracy" (e. g. Held, 2005; Knutti, 2010). Although there is still considerable discussion about how to constrain models using observations, and then how to combine and possibly weight models depending on their overall performance or performance against a minimum set of specific criteria (e. g. Eyring et al. , 2005; Tebaldi et al. , 2005; Gleckler et al. , 2008; Weigel et al. , 2008; Santer et al. , 2009; Parker, 2013; Abramowitz et al. , 2019) , it is clear that results from systematic evaluations are central to this process. A number of papers have examined specific aspects of the FireMIP baseline simulations. Andela et al. (2017)  showed that the FireMIP models do not reproduce the decrease in global burnt area over the past 2 decades inferred from analysis of version 4s of the Global Fire Emission Database (GFED4s) data product.
, 2017; Teckentrup et al. , 2019; Li et al. , 2019; Forkel et al. , 2019a) , mainly due to a lack of process understanding. In this paper, we focus on quantitative evaluation of model performance using the baseline historical simulation and a range of vegetation and fire observational datasets. We use the vegetation-model evaluation framework described by  Kelley et al. (2013) , with an extended set of data targets to quantify the fire and vegetation properties and their uncertainties. We identify (i) common weaknesses of the current generation of global fire-vegetation models and (ii) factors causing differences between the models and (iii) discuss the implications for future model development.
Benchmarking reference datasets Model performance was evaluated using site-based and remotely sensed global datasets of fire occurrence, fire-related emissions and vegetation properties (Fig. 1 ; Fig. S1  in the Supplement). We include vegetation variables (e. g. gross primary productivity, GPP; net primary productivity, NPP; biomass; and leaf area index, LAI) because previous analyses have indicated that they are critical for simulating fire occurrence and behaviour  (Forkel et al. , 2019a; Teckentrup et al. , 2019) , and there are global datasets available. We did not consider parameters such as soil or litter moisture because, although these may have an important influence on fire behaviour, globally comprehensive datasets are not available. All datasets are plotted in Fig. S1. We used multiple datasets as targets for variables where they were available in order to take into account observational uncertainty.
Ideally, model benchmarking should take account of uncertainties in the observations. However, observational uncertainties are not reported for most of the datasets used here (e. g. vegetation carbon). While it would in principle be possible to include uncertainty for example by down-weighting less reliable datasets (e. g. Collier et al. , 2018) , determining the merits of the methods used to obtain observational data is rather subjective, and there is no agreement as to which is more reliable if multiple reference datasets exist for the same variable (e. g. burnt area). Furthermore, some of the datasets (e. g. emissions) involve modelled relationships; there has been little assessment of the impact of the choice of model on the resultant uncertainty in emission estimates (e. g. Kaiser et al.
, 2012). While we use multiple datasets when available (e. g. for burnt area, where there are extremely large differences between the products and they may all underestimate the actual burnt area;  Roteta et al. , 2019) , in an attempt to integrate observational uncertainty in our evaluations, it seems premature to incorporate uncertainty in the benchmark datasets in a formal sense in calculating the benchmarking scores. The following datasets were used for model evaluation: -Burnt area Five global burnt fraction products were used in this study (Fig. S1 ). We used the fourth version of the Global Fire Emissions Database (GFED4) for 1997-2013, which uses the MCD64 burnt area MODIS-based product in combination with an empirical estimation of burnt area based on thermal anomalies when MODIS data were unavailable  (Giglio et al.
, 2013). We also included a version where the MCD64 burnt area product was merged with the small fire detection approach developed by  Randerson et al. (2012; GFED4s). The third dataset is the MODIS burnt area product MCD45, which is the only burnt area product not using MODIS thermal anomalies within its burnt area detection algorithm (2002-2013)  (Roy et al. , 2008). The fourth is the FireCCIv4. 0 dataset based on MERIS satellite data (Alonso-Canas and  Chuvieco, 2015) , available for the period 2005-2011. The fifth is the FireCCI5. 1 dataset based on MODIS 250m imagery  (Chuvieco et al. , 2018). -Fire emissions. Carbon emission by fires is estimated within the Global Fire Assimilation System (GFAS) based on satelliteretrieved fire radiative power (FRP)  (Kaiser et al. , 2012). Here we use the global GFAS data for the period 2000-2013.
-Fire size and numbers. Estimates on mean size and number of fires can be produced using a flood-filling algorithm to extract individual fires  (Archibald et al. , 2013). Here we use the data as produced by  Hantson et al. (2015)  from the MCD45 global burnt area product  (Roy et al. , 2008). Only large fires ≥ 25 ha (1 MODIS pixel) are detected, with a considerable underestimation of fires <∼ 125 ha. Therefore, a direct comparison with modelled fire numbers and size is meaningless, but evaluation of the spatial pattern in fire numbers and fire size can be performed. -Vegetation productivity. We use multiple datasets for vegetation productivity, both measurements from site locations and global upscaled estimates. The site-level GPP dataset is from  Luyssaert et al. (2007) , and the site-level NPP combines these data with data from the Ecosystem Model-Data Intercomparison (EMDI;  Olson et al.
, 2001)  databases. Sites from managed or disturbed environments were not used. A recent compilation of NPP site-level estimates was compiled by  Michaletz et al. (2014). The mean of observations was taken when more than one measurement was available within a 0. 5 • grid cell. We also use upscaled FLUXNET GPP data  (Jung et al. , 2017; Tramontana et al. , 2016). Kelley et al. (2013)  showed that the spreading of data between FLUXNET site observations in such upscaling artificially improved model performance, probably because it used similar input data and methods, which might emulate functional relationships used within DGVMs. Hence scores obtained by Jung should not be interpreted as true "benchmarking scores" but could help inform differences between models in relation to scores obtained from other comparisons like burnt area (See Fig.
S1 ). -Carbon in vegetation. A global dataset on aboveground vegetation biomass was recently produced by combining two existing datasets -  Saatchi et al. (2011)  and  Baccini et al. (2012)  -using a reference dataset of field observations and estimates  (Avitabile et al. , 2016). However, this dataset only considers woody biomass, and to be able to analyse vegetation carbon also for areas without tree cover we used the dataset generated by  Carvalhais et al. (2014) , which combined the  Saatchi et al. (2011)  and  Thurner et al. (2014)  biomass datasets while providing a best estimate for herbaceous biomass. -Leaf area index (LAI). We use the MODIS LAI product MCD15, which gives global LAI values each 8 d  (Myneni et al. , 2002)  and the LAI dataset produced based on AVHRR  (Claverie et al.
Model evaluation and benchmarking We adopted the metrics and comparison approach specified by  Kelley et al. (2013)  as it provides a comprehensive scheme for the evaluation of vegetation models. This protocol provides specifically designed metrics to quantify model performance in terms of annual-average, seasonal and interannual variability against a range of global datasets, allowing the impact of spatial and temporal biases in means and variability to be assessed separately. The derived model scores were compared to scores based on the temporal or spatial mean value of the observations and a "random" model produced by bootstrap resampling of the observations. Normalized mean error (NME) was selected over other metrics (e. g. RMSE) as these normalized scores allow for direct comparison in performance between variables with different units  (Kelley et al.
-Step 2 is with obs i and sim i replaced with the difference between observation or simulation and their respective means, i. e. x i → x i -x, removing systematic bias and describe the performance of the model around the mean. -Step 3 is where obs i and sim i from step 2 were divided by the mean deviation, i. e. x i → x i / |x i |. This removed the influence of bias in the variability and described the models ability to reproduce the spatial pattern in burnt area. To limit the impact of observational uncertainties in the reference datasets on the comparisons and as NME can be sensitive to the simulated magnitude of the variable, we mainly focus on benchmarking results after removing the influence of biases in the mean and variance (step 3). However, comparisons of steps 1 and 2 are given in Table  S1  in the Supplement.
We did not use FireCC4. 0 to assess seasonality or interannual variability (IAV) in burnt area because it has a much shorter times series than the other burnt area products. Model scores are interpreted by comparing them to two null models  (Kelley et al. , 2013). The "mean" null model compares each benchmark dataset to a dataset of the same size created using the mean value of all the observations. The mean null model for NME always has a value of 1 because the metric is normalized by the mean difference. The mean null model for MPD is based on the mean direction across all observations, and therefore the value can vary and is always less than 1. The "randomly resampled" null model compares the benchmark dataset to these observations resampled 1000 times without replacement (Table  3 ). The randomly resampled null model is normally worse than the mean null model for NME comparisons.
For MPD, the mean will be better than the random null model when most grid cells show the same phase. For comparison and application of the benchmark metrics, all the target datasets and model outputs were resampled to a 0. 5 • grid. Although some models were run at a coarser resolution, the spatial resolution at which the benchmarking was performed had only a limited impact on the scores (Fig. S2 ), which does not affect conclusions drawn here. Each model was compared to each reference dataset except in the few cases where the appropriate model output was not provided (e. g. LAI in ORCHIDEE, GPP in MC2). Only the models which incorporate the SPITFIRE fire module provided fire size and number results.
, 2019). Thus, we cannot definitively say that the apparent overestimation by CLASS-CTEM is unrealistic. With the exception of MC2 and LPJ-GUESS-GlobFIRM, the models realistically capture the spatial patterns in burnt area (Figs. 1  and 2 ) and perform better than either of the null models irrespective of the reference burnt area dataset (Table  3 ). CLM (NME: 0. 63-0. 80) and ORCHIDEE-SPITFIRE (0. 70-0. 73) are the best performing models. All the FireMIP models correctly simulate most burnt area in the tropics (24-466 Mha yr -1 ) compared to observed values in the range of 312-426 Mha yr -1 (Table  2 ). The simulated contribution of tropical fires to global burnt area is in the range of 56 % to 92 %, with all models except ORCHIDEE-SPITFIRE simulating a lower fraction than observed (89 %-93 %).