dataesr/scientific-paragraphs-categorization huggingface dataset:
In this paper, we describe and illustrate each processing step by applying the model to a selection of glaciers before running global simulations under idealized climate forcings. Even without an in-depth calibration, the model shows very realistic behavior. We are able to reproduce earlier estimates of global glacier volume by varying the ice dynamical parameters within a range of plausible values. At the same time, the increased complexity of OGGM compared to other prevalent global glacier models comes at a reasonable computational cost: several dozen glaciers can be simulated on a personal computer, whereas global simulations realized in a supercomputing environment take up to a few hours per century. Thanks to the modular framework, modules of various complexity can be added to the code base, which allows for new kinds of model intercomparison studies in a controlled environment.
g. , the Coupled Model Intercomparison Project -CMIP), recent initiatives originating from the glaciological community show a new willingness to better coordinate global research efforts following the CMIP example (e. g. , the Glacier Model Intercomparison Project 1  or the Glacier Ice Thickness Estimation Working Group 2 ). In the recent past, great advances have been made in the global availability of data and methods relevant for glacier modeling, spanning glacier outlines  (Pfeffer et al. , 2014) , automatized glacier centerline identification (e. g. ,  Kienholz et al. , 2014) , bedrock inversion methods (e. g. ,  Huss and Farinotti, 2012) , and global topographic datasets (e. g. ,  Farr et al. , 2007). Taken together, these advances now allow the ice dynamics of glaciers to be simulated at the global scale, provided that adequate modeling platforms are available.
In this paper, we present the Open Global Glacier Model (OGGM), developed to provide a modular and open-source numerical model framework for consistently simulating past and future global-scale glacier change. Global not only in the sense of leading to meaningful results for all glaciers combined, but also for any small ensemble of glaciers, e. g. , at the headwater catchment scale. Modular to allow different approaches to the representation of ice flow and surface mass balance to be combined and compared against one another. Open source so that the code can be read and used by anyone and so that new modules can be added and discussed by the community, following the principles of open governance. Consistent between past and future in order to provide uncertainty measures at all realizable scales.
For each of these steps, several choices are possible regarding the input data to be used, the numerical solver, or the parameterizations to be applied. Any given choice is driven by subjective considerations about data availability, the estimated accuracy of boundary conditions (such as topography), and by technical considerations such as the computational resources available. In this paper we present one way to realize these steps using OGGM, which, in our opinion, is the best compromise between model complexity, data availability, and computational effort to date. However, the OGGM software is built in such a way that future improvements and new approaches can be implemented, tested, and applied at minimal cost by ourselves or a larger community.
Model structure The OGGM model is built around the notion of tasks, which have to be applied sequentially to single glacier or a set of glaciers. There are two types of tasks: -Entity tasks are tasks which are applied on single glaciers individually and do not require information from other glaciers (this encompasses the majority of the OGGM's tasks). Most often they need to be applied sequentially (for example, it is not possible to compute the centerlines without having read the topographical data first). -Global tasks are tasks that are run on a set of glaciers. This encompasses the calibration and validation rou- tines, which need to gather data across a number of reference glaciers. This model structure has several advantages: the same entity task can be run in parallel on several glaciers at the same time, and they allow a modular workflow.
Indeed, a task can seamlessly be replaced by another similar task, as long as the required input and output formats are agreed upon beforehand. The output of each task is made persistent by storage on disk, allowing for later use by a subsequent task, even in a separate run or on another machine. For example, the preprocessing tasks store the topography data in a netCDF file, which is then read by the centerlines task, which itself writes its output in a vector file format. In this paper we will refrain from naming the tasks by their function name in the code, as these are likely to change in the future and are sometimes organized in a non-trivial way as a result of implementation details. Therefore, the next section is called "Modules", where each module can be seen as a collection of tasks developed towards a certain goal.
Preprocessing The objective of the preprocessing module is to set up the geographical input data for each glacier (the glacier outlines and the local topography). First, a Cartesian local map projection is defined: we use a local Transverse Mercator projection centered on the glacier. Then, a suitable topographical data source is automatically chosen, depending on the glacier's location. Currently we use the following: the Shuttle Radar Topography Mission (SRTM) 90 m Digital Elevation Database v4. 1  (Jarvis et al. , 2008)  for all locations in the 60 All datasets have a comparable spatial resolution (from 30 to 90 m, or 3 arcsec). Using different data sources is problematic but unavoidable as there is no consistent, gap-free, globally available digital elevation model (DEM) to date. The Advanced Spaceborne Thermal Emission and Reflection Radiometer (ASTER) global digital elevation model version 2 (GDEM V2) is available globally but was quickly eliminated due to large data voids and artefacts, in particular in the Arctic.
These artefacts are often tagged as valid data and cannot be easily detected automatically. The Viewfinder Panoramas products rely on the same sources but have been corrected manually (mostly with topographic maps; Jonathan de Ferranti, personal communication, 2017); thus, this ensures a more realistic void filling. Although they have nearly global coverage, the DEM3 products are not used in place of as it is not easy to retrieve the original data sources used to generate them (the information is scattered around the website, although ASTER and SRTM are the main data sources in most cases). It must be noted that a number of glaciers will still suffer from poor topographic information and/or a date of data acquisition which does not match that of the RGI outlines. Either the errors are large or obvious (in which case the model will not run), or they are left unnoticed.
g. , avalanches, topographical shading, cloudiness), and others that are related to systematic biases in the input data (e. g. , climate, topography). As a result, µ * can vary greatly between neighboring glaciers without obvious physical reasons. The calibration procedure implemented in OGGM makes use of these apparent handicaps by turning them into assets. The procedure begins with glaciers for which we have direct observations of specific mass balance (N = 254, see Appendix B). For each of these glaciers, annual sensitivities µ(t) are computed from Eq. (  1 ) by requiring that the glacier specific mass balance m(t) is equal to zero. 4  m(t) is the glacier integrated mass balance computed for a 31year period centered around the year t and for a constant glacier geometry fixed at the RGI outline's date (e.
Water-terminating glaciers Glaciers are defined as "water-terminating" in OGGM when their RGI terminus attribute is either flagged as marineterminating or lake-terminating. The major difference between a water-terminating glacier and a valley glacier is the additional mass loss that occurs at the glacier front (frontal ablation). This has implications for the bed thickness inversion, which currently assumes that the mass flux at the front is zero (by setting m = 0, see Sect. 3. 4), and for the dynamics of the glacier. The current treatment of water-terminating glaciers in OGGM is very simple but explicit. We do not take frontal ablation into account for the bed inversion (i. e. , the original glacier front has a thickness of zero), but we do have a basic parameterization in the ice dynamics module.
There is no guarantee that we use the same DEM as the original inventory, and therefore OGGM and RGI might disagree on the ideal position of an ice divide. -Unavailable data: some remote glaciers and ice caps are outlined in the RGI, but not divided at all. These are the most problematic cases, and should be a matter of concern for all RGI users. For example, the largest glacier in RGI (an ice cap in northeastern Greenland with the ID RGI60-05. 10315 and an area of 7537 km 2 ) is wrongly outlined and should be separated into at least a dozen smaller entities. Most of the small errors are filtered out by OGGM with algorithms based on surface slope thresholds (see Sect. 3. 2), but the latter group of glaciers should be handled upstream. We have developed an open-source tool to automatically compute glacier divides (https://github.
While both are viable options for the OGGM workflow, they represent a considerable increase in complexity and are not available yet. Like other fundamental issues described in this paper (such as missing topographical data or wrongly outlined glaciers), this problem will also affect other glacier models. We hope that some of the tools we introduce here will help to solve some of these issues upstream, and that the community will soon be able to put pressure on commercial data providers for better data availability. Thanks to its automated workflow, OGGM is able to apply all of the processes described in the previous section to all glaciers globally with the exception of Antarctica, where no CRU data are available (see Appendix C for an overview of the RGI regions). No special model setup is needed, and we use all model default settings without any calibration (this is not strictly true for the µ * calibration, which is an automated process and cannot be tuned or turned off).
Hardware requirements and performance Thanks to the computational efficiency of the flow-line model, OGGM runs quickly enough to be used on a personal computer for up to several dozen glaciers. At the global scale a high performance computing environment is required. For these global simulations we used a small cluster comprising two nodes with 16 quad-core processors each, resulting in 128 parallel threads. With this configuration, the model preprocessing chain (including the ice thickness inversion) takes about 7 h to complete (without data download). The total size of the (compressed) preprocessed output is 122G, which can be reduced by deleting intermediate computing steps. The amount of required storage increases with each dynamical run; here again it is possible to reduce the amount of data by only storing diagnostic variables, such as volume, area, length, and ELA, instead of the full model output.
Conclusions We present a new model of global glacier evolution, the Open Global Glacier Model (OGGM, v1. 1). The panoply of tools available to compute past and future glacier change range from simple box models (e. g. ,  Harrison, 2013)  to more complex, geometry aware models  (Huss and Hock, 2015 , to cite the most recent in date). OGGM undoubtedly belongs to the complex side of this scale. Different model complexities are justified by different problem settings, taking the modelspecific merits and drawbacks into account. Instead of endorsing one approach over the other, OGGM aims to provide a framework which allows one to switch between models and allows objective intercomparisons. In fact, the ice dynamics module represents only a small fraction of the OGGM code base: a huge amount of work has been invested to provide a series of tools which will help others in their own modeling endeavors.
Perfect modularity will be hard to achieve, but the recent implementation of alternative numerical solvers show that modularity is pos- Note the units of the y axes (10 3 km 3 ) and the marked regional differences. sible. Finally, we need to ensure attribution to the original contribution (e. g. , a scientific publication) in order to engage the wider community. For this purpose, we developed a template repository for external OGGM modules: https://github. com/OGGM/oggmcontrib (last access: 27 February 2019). This development model will ensure that users importing OGGM extensions will be aware of the source of each module they are using and will be able to refer to the original contribution appropriately. We hope that this development model will foster new collaborations. We cannot (and do not want to) demonstrate that OGGM will provide more accurate estimates of future sea-level rise than earlier attempts.
However, OGGM allows new studies which were not previously possible. The dynamical representation of glacier advance and retreat enables studies of glacier evolution at long (paleo-) timescales, where ice dynamics and geometrical attributes such as the accumulation area ratio play an important role (e. g. ,  Mackintosh et al. , 2017). The first OGGM simulations over the last millennium show very promising results  (Goosse et al. , 2018). The modular framework allows one to compare the performance of various pa- rameterizations such as the mass balance and downscaling algorithms. It may be argued that the amount of available data is not sufficient to constrain modeling studies such as ours at the global scale. The OGGM can now be used to test this argument by allowing simpler modules to be added to the code base and test the added value of increased complexity.
For example, how to deal with the transient climate issue in the ice thickness inversion algorithm? How much information about past climate can be extracted from moraine proxies and today's glacier extent? What are the uncertainties associated with global sea-level rise estimates, and where do they originate? How much complexity is appropriate? These are all questions that the authors hope will be easier to address through the publication of the OGGM. 6 Code availability, testing, and software requirements The OGGM software is coded in the Python language and licensed under the GPLv3 free software license. The latest version of the code is available on GitHub (https://github. com/OGGM/oggm, last access: 27 February 2019), the documentation is hosted on Read the Docs (http://docs. oggm. org, last access: 27 February 2019), and the project website for communication and dissemination can be found at http://oggm.
org (last access: 27 February 2019). The OGGM version used for this study is version 1. 1  (Maussion et al. , 2019). Past and future OGGM versions will be available from a permanent DOI repository (https://zenodo. org/badge/ latestdoi/43965645, last access: 27 February 2019). The software ships with an extensive test suite which can be used by the users to test their configuration. The tests are triggered automatically at each new code addition, reducing the risk of introducing new bugs (https://travis-ci. org/OGGM/oggm, last access: 27 February 2019). The suite contains unit tests (for example for the numerical core) and integration tests based on sets of real glaciers. At the time of writing, 85 % of all relevant lines of code are covered by the tests (i. e. , called at least once by the test suite).
The remaining 15 % are challenging to monitor because they mostly concern the automated downloading tools which are used in production and cannot be tested automatically. The following open-source libraries have to be installed in order to run OGGM: numpy/scipy (van der  Walt et al. , 2011 ), scikit-image (van der Walt et al. , 2014) , shapely  (Gillies, 2007) , rasterio  (Gillies, 2013 ), pandas (McKinney, 2010) , geopandas, xarray  (Hoyer and Hamman, 2017) , pyproj, matplotlib  (Hunter, 2007) , and salem  (Maussion et al. , 2017). OGGM runs on all major platforms (Windows, Mac, and Linux) but we recommend using Linux as this is the platform it is most tested on. The code and data used to generate all figures and analyses in this paper can be found at  Maussion (2019). Region names and basic statistics of the database (number of glaciers per region, regional contribution to the global area in percent, and the percentage of the regional area which cannot be modeled by OGGM).
Acknowledgements. Ben Marzeion ,  Johannes Landmann , and  Christian T. Wild  were supported by the  Austrian Science Fund (FWF) , grant no. P25362. Ben Marzeion ,  Anton Butenko , and  Julia Eis  were supported by the  German Research Foundation , grant no. MA6966/1-1. Anouk Vlug  and  Beatriz Recinos  were supported by the  DFG  through the  International Research Training Group IRTG 1904 ArcTrain. Kévin Fourteau  was supported by the  ENS Paris-Saclay. Nicolas Champollion  was funded by the  German Federal Ministry of Education and Research  (grant no  01LS1602A ). The computations were partially realized on resources provided by  Amazon Web Services Cloud Computing  (sponsored by Amazon) and on the computing facilities of the  Institute of Geography, University of Bremen. Edited by:  Didier Roche  Reviewed by:  David Rounce  and one anonymous referee.
Approach The Figure  1  depicts the overall approach. To extract reputation of people and products from Twitter, the first step consists in querying Twitter to retrieve data related to a target entity E and in extracting the set of Named Entities from the collected tweets. The overall dataset is then described using a Twitter representation model we defined to represent the tweets, the users and the entities. This model is detailed in Section 3. 1. In the second step, we enrich the information in the tweets to retrieve the tweets that have influence on the audience using a sampling algorithm detailed in Section 3. 3. In the third step, on top of the sampled data, we apply frequent itemset mining algorithm to extract the Frequent Named Entities (FNEs) related to the entity of interest E. This step is presented in Section 3.
4. Twitter data can be seen as a network characterized by a high interconnectivity between users and tweets. Each user or tweet of this network is rich of attributes. More formally, Twitter data is represented as a graph as follows: T =< V, U > ( 1 ) where V is the set of nodes and U is the set of directed edges between nodes. Different types of nodes are defined in V: t is a tweet, accompanied by attribute values, which include the text of the tweet, the id of the tweet, the number of favorites and the number of retweets. u is a user with attributes as username and number of followers. h is a hashtag extracted from the tweet. e is an entity discovered in tweets. url is an url found in a tweet.
Weighted Sampling Sampling data has widely been addressed to retrieve data from Twitter due to the immense number of data flowing through daily. Twitter has provided a REST API 1  which allows running queries against the data to retrieve a sample of the actual content on Twitter. But the REST API has a rate limit which allows users to query in 15-minute windows. Twitter also has a streaming API to listen to a 1% sample of the live Twitter feed. But using the streaming API requires a lot of bandwidth and storage space and no historical data is available as it is realtime. Sampling techniques are discussed in a vast number of papers. The most important question that we should pose is: "Do we went a statistically representative sample that aligns with the real, large Twitter dataset or do we want a filtered sample that focuses on the relevant tweets?".
Experiments In this section, we run experiments to evaluate our approach in different aspects such as the richness of the samples, effectiveness of frequent entity mining, and comparing the ranking of the sample to the population. Retrieving data from Twitter can be overwhelming due to the immense number of data flowing through daily. Twitter has provided a REST API which allows running queries against the data. The REST API data is a sample of the actual content on Twitter. Twitter also has a streaming API which allows users to listen to a 1% sample of the live twitter feed. We use the REST API to collect the data since we are interested in older tweets, as well as users. To collect data about a certain topic we used a query having a String as parameter (such as Obama). In  [3]  the datasets of Trump, Obama are collected in January 2017, La La Land and The Voice in March 2017, while for the new entity, Samsung, the data is collected in March 2018.
Neo4j 2  graph database for data storage, respecting the Twitter graphs definition of Section 3. We improved the quality of the text by separating merged words inside the hashtag. For example #iamsohappy and #iam#sohappy will be handled by our cleaning algorithm to produce i am so happy. We are using the corpus of words of Sentistrength 3  for word identification and then different techniques for organizing the sentence and discarding not relevant words. We have used Stanford NLP 4 to identify the Named Entities from the retrieved tweets; after identifying the entities e stored in the same database as separate nodes with the edge < t, e > relating to the tweet t. Stanford NLP also has a sentiment analysis module. But there have been tools that are designed and optimized for small text sentiment analysis specially for Twitter.
In this paper we have used Sentistrength as the sentiment analysis tool. Sentistrength scores a given text with a positive and negative values. The text will have both a negative and a positive score from -5 to -1 and 1 to 5. For instance, if a text is highly negative it will have a score of -5 and 1 indicating that there is no positive score but a high negative value. Once the sentiment analysis is done the scores are also stored in the database for each of the tweets as parameters. In the following, we firstly present statistics about the collected data then the results provided by each step.
Data analytics In this section, we analyze our datasets gathered through REST API from Twitter. In section 4. 1. 1, we run general statistics about the size of the dataset, number of retweets, number of followers etc, as well as advanced statistics regarding the richness of the datasets. Later, we continue with the correlation of our parameters of interest in section 4. 1. 2 and their relation to Named Entities in section 4. 1. 3.
Statistics of datasets We collected four datasets of tweets: Obama dataset, Trump dataset, La La Land dataset, The Voice dataset and Samsung dataset by querying Twitter with respective strings. In the context of the describing the dataset characteristics, we define two notions: -Density of NE -Density of Named Entities. It expresses the average number of Named Entities linked to a tweet -Coverage of NE -Coverage of Named Entities. It represents the percentage of the tweets in the dataset that contain at least one Named Entity. The average parameter values for each of the datasets are presented in Table  1. When it comes to The Voice , the parameters of interest are satisfying; for instance, the average number of retweets is considerably higher than all other four datasets. However, it should be noted that sometimes retweets are a consequence of a marketing or advertising, not a real interest parameter; as if we compare it to the favorite count, it is a lower than Obama or Trump but still higher than La La Land.