dataesr/scientific-paragraphs-categorization huggingface dataset:
USGS After collecting individual responses, the USGS assigns a weighted value to the answers of different questions (i. e. the felt index, shelf index and damage index). The responses are then averaged to reflect a consensus of the grouped answers. DYFI? employs the modified Mercalli intensity scale (MMI). Intensities assigned by the MMI and EMS-98 and other modern scales are found to correspond closely to each other  (Hough, 2013a ) and can thus be merged. We use weighted, one-digit CDI intensities from 1038 people who reported to the USGS to have felt the Goch earthquake. Floor-level in- tensity correction could not be applied due to the absent floor question (Q8, Table  S1 ). However, most people who reported to the USGS live in the Netherlands. Rescaling the KNMI data for floor level hardly affected grid cell intensity due to the low amount of reports from multistorey buildings.
Comparing and merging databases With respect to the epicentre, the 2011 Goch earthquake was felt from Amsterdam (NL) in the northwest, Paderborn (DE) in the east, Darmstadt (DE) in the southeast to Brussels (BE) in the southwest. For the four countries involved, 10 290 people responded to the online questionnaires of seven institutes (Table  1 ). The response submitted from furthest away came from Lille (FR) at 245 km. After geocoding and by using the truncated location provided by the institutes, 8218 entries could be used for intensity analysis. Before merging macroseismic data of all institutes, first the quality of the different macroseismic sources is evaluated. The distribution histograms (Fig. 5 ) shows the individual and grid cell intensity distributions of all entries and for each institute sepa-rately, binned by half-intensity units.
Merging intensities from national agencies results in a denser coverage of the area in which the earthquake occurred (Fig. 4 ). The sum of responses submitted to the national institutes is far larger than the sum of those arriving at international agencies. This illustrates the importance of the national web questionnaires, particularly for moderate magnitudes. The mean intensity of the grid cell distribution of transfrontier inquiries (ROB-BNS, EMSC and USGS) is lower (I = 2. 5) than the mean intensity of national inquiries (I = 3 for KNMI and I = 3. 5 for NRW-GD). It seems plausible that the grid cell distribution of the NRW-GD database is higher than KNMI because more responses are gathered from the epicentral area in Germany, whereas KNMI has no entries from this area. The NRW-GD received many responses, some of which were located more than 150 km from the epicentre.
Because intensity data could not be floor-level corrected, because notfelt responses are absent and because intensities of cities are mostly higher than in the database of other institutes, the NRW-GD intensity distribution is shifted towards higher intensities compared to other institutional distributions (Fig. 4 ). To avoid this systematic intensity overestimation, NRW-GD data were not further used when databases were merged for attenuation analysis but they are used to discuss the felt impact of the Goch earthquake. After geocoding, floor-level correction and the exclusion of NRW-GD data, 7343 entries remained for final grid intensity analysis. In total, 663 people reported not to have felt the earthquake (intensity I; Table  1 ). An intensity could be assigned to 311 grid cells (Fig. 6b ).
This change in slope is related to the underreporting and lack of intensity I reports in the database in this distance range. The underreporting is visible in the histograms (Fig. 7b ) where the frequency of centroids strongly decreases after 100 km, although an increase should be expected because more people (and more grid cells) were affected by the earthquake at this distance range. Overall, 111 responses were submitted from Brussels (population 1 370 000) at a distance of 165 km. Despite this low population response percentage (< 5 responses per 10 000 inhabitants; Fig. 8b ), it is still considerably larger than those from many other populated cities at closer epicentral distance where the Goch event was not perceived. In Belgium, no responses were submitted from the towns of Hasselt (91 km, population 56 000) or Mechelen (135 km, population 117 000), and only two and three were submitted from Turnhout (93 km, population 50 000) and Antwerp (125 km, population 600 000).
The 22 May 2015 Ramsgate earthquake (UK) Six institutes received macroseismic data for the Ramsgate earthquake: BGS, EMSC, USGS, BCSF and ROB-BNS. Although the Ramsgate earthquake occurred at 02:52:17 (local UK time), it was widely reported in the UK, France, Belgium and, to a lesser extent, in the Netherlands. The Ramsgate event (M L 4. 2) was perceived unusually far on the European continent, up to an epicentral distance of 360 km. To analyse ground motion, all macroseismic data were requested from the above-mentioned institutes (Table  2 ). Only the IDPs from the BGS were not provided.
Merging databases With respect to the epicentre, the 2015 Ramsgate earthquake was felt from Liège and Verviers (BE) in the east-southeast to Lille and Calais (FR) in the southeast, Norwich (UK) in the north, Stoke-on-Trent in the northeast, and Brighton in the southwest. For the four countries involved, 6222 people responded to the online questionnaires of five agencies to say they had felt the Ramsgate earthquake (Table  2 ). As with the Goch earthquake, the complex macroseismic situation in Europe is reflected in the fragmented datasets of the Ramsgate earthquake, but the responses submitted to national institutes (Fig. 9 ) cover the whole area in which the earthquake was felt. Numerical azimuthal analysis of the grid cell centroids relative to the epicentre (see Fig. S2 ) quantitatively proved that the Ramsgate intensity distribution is WNW-ESE-oriented with a mean circular azimuth of 112 • on the continent and 306 • in the UK.
Attenuation analysis The Goch intensity assessment showed that deriving an IAR through grid cell intensities leads to an equal-area IAR that is not biased by the concentration of individual responses due to population density. This result offers a great promise for sharing macroseismic data between seismological agencies that all have their own inquiry and their own way of clus-tering data because intensity cells can be exchanged without sharing any personal information. We test this method on the Ramsgate earthquake: an attenuation model is derived through the centroid data from the 25 km 2 cells of the BGS, the clustered and thumbnail data of the EMSC and the 100 km 2 intensity cells generated from ROB-BNS, USGS and BCSF IDPs. The Ramsgate IAR is compared to a CEUS prediction model for an M w 3.
Conclusions Transfrontier macroseismic maps are currently generated in real time in Europe by the EMSC and USGS. The current challenge in Europe, however, is to generate denser and more accurate shaking maps by merging all available intensity datasets from (inter)national agencies. It is necessary to collect the highest possible amount of datasets to ameliorate the uncertainty of the macroseismic intensity analysis. National agencies are best placed to do this as they still gather the highest number of responses (see subtotals in Figs. 5  and 9 ). The variety of questionnaires and the not always transparent intensity determination procedures of the different seismological agencies complicate this task. These differences highlight the importance of the European macroseismic scale for merging data.
The results of this work strongly suggest that a common base in institutional web questionnaires needs to be established in order to generate transfrontier maps in which the full amount of transfrontier collected reports can be used. Only after a careful analysis of the different available ques-tionnaires and their impact on the intensity scale can we exchange and process intensity data in real time reliably. For a reliable transfrontier intensity assessment, we advise starting with the inquiry of the institute that has the best spatial cover. Geocode if possible (if using Google, remember the 2500 addresses per day limit) and make sure a floor-level correction is applied; if not, add the question to your enquiry to avoid intensity overestimation. Create a network of volunteers that can be alerted in real time to increase responses and not-felt entries.
This will allow the integration of the percentage of not-felt responses as the macroseismic scale recommends. Finally, collect and merge other institutional data to obtain the best coverage of the felt effect. We demonstrated the functionality of geocoding and applying a grid cell method for merging (inter)national macroseismic databases. Although less data points are used, geocoding intensity locations minimizes the location uncertainties in a macroseismic map. A grid cell intensity map shows a more conclusive intensity distribution than a ZIP code intensity map. Grid cell maps are self-explanatory and avoid errors on the often subjective contouring for isoseismals. Gridding allows merging multiple macroseismic datasets collected by different seismological institutes in which the individual locations are (made) imprecise.
Figures were created in QGIS (2016). K. Van Noten  was supported by the  Fonds de la Recherche Scientifique (FNRS -Belgium)  under grant  PDR T. 0116. 14 " Influence of site effects in central Belgium on earthquake strong ground motions " and received additional FWO funding under travel grant  K1G6616N. Edited by:  M. Malinowski Reviewed  by:  V. De Rubeis ,  R. Bossu , and one anonymous referee.
Data availability. Topography data in Fig. 3  are from the Shuttle Radar Topography Mission (SRTM) and are available from the US Geological Survey. Macroseismic data were requested from the corresponding seismological institutes (See Appendix A). Bedrock data in Fig. 12  are openly available from Databank Ondergrond Vlaanderen (https://dov. vlaanderen. be) and DINOloket (https://www. dinoloket. nl/). All other data and maps used in this paper came from published sources listed in the references. Shapefiles to regenerate Figs. 6 and 10 are available in the Supplement.
Gammapy is a Python package for high-level gamma-ray data analysis built on Numpy, Scipy and Astropy. It enables us to analyze gamma-ray data and to create sky images, spectra and lightcurves, from event lists and instrument response information, and to determine the position, morphology and spectra of gamma-ray sources. So far Gammapy has mostly been used to analyze data from H. E. S. S. and Fermi-LAT, and is now being used for the simulation and analysis of observations from the Cherenkov Telescope Array (CTA). We have proposed Gammapy as a prototype for the CTA science tools. This contribution gives an overview of the Gammapy package and project and shows an analysis application example with simulated CTA data.
Introduction The Cherenkov Telescope Array (CTA) will observe the sky in very-high-energy (VHE, E > 20 GeV) gamma-ray light soon. CTA will consist of large telescope arrays at two sites, one in the southern (Chile) and one in the northern (La Palma) hemisphere. It will perform surveys of large parts of the sky, targeted observations on Galactic and extra-galactic sources, and more specialized analyses like a measurement of charged cosmic rays, constraints on the intergalactic medium opacity for gamma-rays and a search for dark matter. Compared to current Cherenkov telescope arrays such as H. E. S. S. , VERITAS or MAGIC, CTA will have a much improved detection area, angular and energy resolution, improved signal/background classification and sensitivity. CTA is expected to operate for thirty years, and all astronomers will have access to CTA high-level data, as well as CTA science tools (ST) software.
The ST can be used for example to generate sky images and to measure source properties such as morphology, spectra and light curves, using event lists as well as instrument response function (IRF) and auxiliary information as input. Gammapy is a prototype for the CTA ST, built on the scientific Python stack and Astropy  [1] , optionally using Sherpa  [2, 3, 4]  or other packages for modeling and fitting (see Figure  1 ). A 2-dimensional analysis of the sky images for source detection and morphology fitting, followed by spectral analysis, was first implemented. A 3-dimensional analysis with a simultaneous spatial and spectral model of the gamma-ray emission, as well as background (called "cube analysis" in the following) is under development. A first study comparing spectra obtained with the classical 1D analysis and the 3D cube analysis using point source observations with H.
E. S. S. is presented in  [5]. Further developments and verification using data from existing Cherenkov telescope arrays such as H. E. S. S. and MAGIC, as well as simulated CTA data is ongoing. Gammapy is now used for scientific studies with existing ground-based gamma-ray telescopes  [6, 7] , the Fermi-LAT space telescope  [8] , as well as for CTA  [9, 10, 11]. In this writeup we focus on the software and technical aspects of Gammapy. We start with a brief overview of the context in Section 2, followed by a description of the Gammapy package in Section 3, the Gammapy project in Section 4 and finally our conclusions concerning Gammapy as as CTA science tool prototype in Section 5.
Context Prior to Gammapy, in 2011/2012, a collection of Python scripts for the analysis of IACT data was released as a first test of open-source VHE data analysis software: "PyFACT: Python and FITS Analysis for Cherenkov Telescopes"  [12]. This project is not updated anymore, but it was the first implementation of our idea to build a CTA science tools package based on Python and using Numpy and Scipy, during the first development stages of the CTA project. In 2011, the astronomical Python community came together and created the Astropy project and package  [1] , which is a key factor making Python the most popular language for astronomical research codes (at least according to this informal analysis  [13]  and survey  [14] ). Gammapy is an Astropy affiliated package, which means that where possible it uses the Astropy core package instead of duplicating its functionality, as well as having a certain quality standard such as having automated tests and documentation for the available functionality.
In recent years, several other packages have adopted the same approach, to build on Python, Numpy and Astropy. To name just a few, there is ctapipe (github. com/cta-observatory/ctapipe), the prototype for the low-level CTA data processing pipeline (up to the creation of lists of events and IRFs); Naima for modeling the non-thermal spectral energy distribution of astrophysical sources  [15] ; PINT, a new software for high-precision pulsar timing (github. com/nanograv/PINT), and Fermipy (github. com/fermipy/fermipy), a Python package that facilitates analysis of data from the Large Area Telescope (LAT) with the Fermi Science Tools and adds some extra functionality. We note that many other astronomy projects have chosen Python and Astropy as the basis both for their data calibration and reduction pipelines and their science tools.
Some prominent examples are the Hubble space telescope (HST)  [16] , the upcoming James Webb Space Telescope (JWST)  [17]  and the Chandra X-ray observatory  [2, 18]. Even projects like LSST that started their analysis software developments before Astropy existed and are based on C++/SWIG are now actively working towards making their software interoperable with Numpy and Astropy, to avoid duplication of code and development efforts, but also to reduce the learning curve for their science tool software (since many astronomers already are using Python, Numpy and Astropy)  [19]. For current ground-based IACTs, data and software are mostly private to the collaborations operating the telescopes. CTA will be, for the first time in VHE gamma-ray astronomy, operated as an open observatory. This implies fundamentally different requirements for the data formats and software tools.
Gammapy package Gammapy offers the high-level analysis tools to generate science results (images, spectra, light curves and source catalogs) based on input data consisting of reconstructed events (with an arrival direction and an energy) that are classified according to their types (e. g. gamma-like, cosmicray-like). In the data processing chain of CTA, the reconstruction and classification of events are realized by another Python package, ctapipe  1. Data are stored in FITS format. The high-level analysis consists of: • selection of a data cube (energy and positions) around a sky position from all event lists, • computation of the corresponding exposure, • estimation the background directly from the data (e. g. with a ring background model  [21] ) or from a model (e. g. templates built from real data beforehand), • creation of sky images (signal, background, significance, etc) and morphology fitting, • spectrum measurement with a 1D analysis or with a 3D analysis by adjusting both spectral and spatial shape of gamma-ray sources, • computation of light-curves and phasograms, search for transient signals, • derivation of a catalog of excess peaks (or a source catalog).
For such an analysis, Gammapy is using the IRFs produced by the ctapipe package and processes them precisely to get an accurate estimation of high-level astrophysical quantities. The Gammapy code base is structured into several sub-packages dedicated to specific classes where each of the packages bundle corresponding functionality in a namespace (e. g. data and observation handling in gammapy. data, IRF functionality in gammapy. irf, spectrum estimation and modeling in gammapy. spectrum. ). The Gammapy features are described in detail in the Gammapy documentation (docs. gammapy. org) and many examples given in the tutorial-style Jupyter notebooks, as well as in  [22]. Figure  3  shows one result of the "CTA data analysis with Gammapy" notebook: a significance sky image of the Galactic center region using 1.
5 hours of simulated CTA data. The background was estimated using the ring background estimation technique, and peaks above 5 sigma are shown with white circles. For examples of CTA science studies using Gammapy, we refer you to other posters presented at this conference: Galactic survey  [10] , PeVatrons  [11]  and extra-galactic sources  [9]. Several other examples using real data from H. E. S. S. and Fermi-LAT, as well as simulated data for CTA can be found via docs. gammapy. org by following the link to "tutorial notebooks". The Gammapy Python package is primarily built on Numpy  [23] , and Astropy  [1]  as core dependencies. Data is stored in Numpy arrays or objects such as astropy. coordinates. SkyCoord or astropy. image. write('counts. fits') Figure  2 : An example script using Gammapy to make a counts image from an event list.
This is used in Section 3 to explain how Gammapy achieves efficient processing of event and pixel data from Python: all data is stored in Numpy arrays and passed to existing C extensions in Numpy and Astropy. spectral points or source catalogs), astropy. wcs. WCS for world coordinate systems mapping pixel to sky coordinates, as well as astropy. coordinates. SkyCoord and astropy. time. Time objects to represent sky coordinates and times. Astropy. coordinates as well as astropy. time are built on ERFA (github. com/liberfa/erfa), the open-source variant of this IAU Standards of Fundamental Astronomy (SOFA) C library (www. iausofa. org). In Gammapy, we use astropy. units. Quantity objects extensively, where a quantity is a Numpy array with a unit attached, supporting arithmetic in computations and making it easier to read and write code that does computations involving physical quantities.
As an example, a script that generates a counts image from an event list using Gammapy is shown in Figure  2. The point we want to make here is that it is possible to efficiently work with events and pixels and to implement algorithms from Python, by storing all data in Numpy arrays and processing via calls into existing C extensions in Numpy and Astropy. E. g. here EventList stores the RA and DEC columns from the event list as Numpy arrays, and SkyImage the pixel data as well, and image. fill(events), and all processing happens in existing C extensions implemented or wrapped in Numpy and Astropy. In this example, the read and write methods call into astropy. io. fits which calls into CFITSIO (  [24] ), and the image. fill(events) method calls into astropy. wcs. WCS and WCSLib (  [25] ) as well as numpy.
histogramdd. Gammapy aims to be a base package on which other more specialized packages such as Fermipy (github. com/fermipy/fermipy) for Fermi-LAT data analysis or Naima  [15]  for the modeling of non-thermal spectral energy distributions of astrophysical sources can build. For this reason we avoid introducing new required dependencies besides Numpy and Astropy. That said, Gammapy does import the following optional dependencies to provide extra functionality (sorted in the order of how common their use is within Gammapy). Scipy  [26]  is used for integration and interpolation, Matplotlib  [27]  for plotting and Sherpa  [2, 3, 4]  for modeling and fitting. In addition, the following packages are used at the moment for functionality that we expect to become available in the Astropy core package within the next year: regions (astropy-regions.
Conclusions In the past two years, we have developed Gammapy as an open-source analysis package for existing gamma-ray telescope and as a prototype for the CTA science tools. Gammapy is a Python package, consisting of functions and classes that can be used as a flexible and extensible toolbox to implement and execute high-level gamma-ray data analyses. We find that the Gammapy approach, to build on the powerful and well-tested Python packages Numpy and Astropy, brings large benefits: a small codebase that is focused on gamma-ray astronomy in a single high-level language is easy to understand and maintain. It is also easy to modify and extend as new use cases arise, which is important for CTA, since it can be expected that the modeling of the instrument, background and astrophysical emission, as well as the analysis method in general (e.
Acknowledgements This work was conducted in the context of the  CTA Consortium. We gratefully acknowledge financial support from the agencies and organizations listed here: www. cta-observatory. org/consortium_acknowledgments We would like to thank the  Scientific Python  and specifically the  Astropy community  for providing their packages which are invaluable to the development of Gammapy, as well as tools and help with package setup and continuous integration, as well as building of conda packages. We thank the  GitHub (github. com)team  for providing us with an excellent free development platform, ReadTheDocs (readthedocs. org)for free documentation hosting, Travis (travis-ci. org) and Appveyor (appveyor. com)for free continuous integration testing, and Slack (slack. com)for a free team communication channel.
Introduction Simulink is a widespread tool from Mathworks for modeling and simulating embedded control systems. A plethora of formal verification tools exist for Simulink, both from academia and industry, including Mathwork's own Design Verifier. Formal verification is extremely important, particularly for safety critical systems. Formal verification techniques make steady progress and are increasingly gaining acceptance in the industry. At the same time, we should not ignore more "lightweight" methods, which can also be very beneficial. In this paper, we are interested in particular in type checking and type inference. Type checking is regularly used in many programming languages, as part of compilation, and helps to catch many programming mistakes and sometimes also serious design errors.