dataesr/scientific-paragraphs-categorization huggingface dataset:
Spatial distribution of continuum components in Cassiopeia A We applied our method on Cassiopeia A data between 0. 6 and 2. 3 keV. The number of counts being higher in this energy band, we used data with a finer spectral binning (14. 6 eV instead of 43. 8 eV) and smaller pixels (0. 9 arcsec instead of 1. 8 arcsec). Figure  11  shows that the four components were retrieved. The first corresponds to the synchrotron emission, and is coherent with the image we retrieved between 5 and 8 keV. It is the first time an image of the synchrotron has been extracted in these energy bands, where it is dominated by the ejecta emission. Such a map of the low-energy synchrotron emission is very valuable for the study of the energy dependence of the synchrotron rim width. A second component has a spatial distribution highly similar to that of the Fe K between 5 and 8 keV, and the line emission complex at ∼ 1 keV in the corresponding spectrum seems to indicate that this component may be dominated by the Fe L complex.
It has been applied here to X-ray data for the first time, and we have shown that it provides better results than the usual methods in use in this field. The GMCA needs to be applied to data with a large total number of counts. When such data are available, it can successfully disentangle highly spatially correlated sources, as was shown with our toy models (Sections 4 and 7). A first application to real Chandra data of Cassiopeia A in different energy bands, detailed in Section 8, gave promising results, highlighting the asymmetries in the Si, S, Ar, Ca, and Fe K spatial distributions by retrieving two maps associated to spectra that are slightly redor blueshifted with respect to the rest-frame line. The main conclusions of our study are the following: -Morphological fidelity: In every example we tested, it appeared that the GMCA yields accurate images of the sources it retrieves, very close to the original ones we injected in the toy model.
Acknowledgements. This research made use of Astropy, 4 a communitydeveloped core Python package for Astronomy (Astropy Collaboration et al. 2013, 2018). GWP acknowledges funding from the  European Research Council  under the European Union's  Seventh Framework Programme  ( FP7/2007-2013) / ERC  grant agreement No. 340519. JB acknowledges funding from the  European Community  through the grant LENA ( ERC StG  -contract no. 678282 ).
In the era of new technologies and with the growing need for reliable ecological energy supplies, researchers eyes are diverted towards reducing the energy consumption of buildings which becomes a major concern that requires a variety of actors being involved (e. g. , building owners, energy/facility managers, occupants, data scientist), who have different expertise and need to use different tools This paper introduces BEMServer, an open source Building Energy Management system solution built to ease the integration of data analytic and visualization services into building and energy domain applications. It handles heterogeneous data in a transparent way by providing a clear and unambiguous semantic representation of the modeled resources. To do so, BEMServer integrates the OntoH2G formal ontology at its core.
BEMServer ensures interaction between services, since results generated by different services can be reused by other external modules; this interaction facilitates a better collaborative work between complex modules (for instance, machine learning based services, energy simulation, front-end applications. ), and the power of composing services to deliver the best output; • Data access control. To protect confidential and sensible data, BEMServer implements a security layer that ensures a secure connection in a multi-tenant environment: users can only access data on specific buildings, and from specific services, and can perform operations according to the rights conceded. The paper is structured as follows. We first provide a state of the art of solutions similar to BEMServer, and other ontologies similar to OntoH2G, the core data model used in BEMServer.
Energy building monitoring platforms While many ontologies were developed to describe building monitoring systems, few energy management applications built on top of these models seem to exist. McGibney et al. (2016) , propose OpenBMS as an IoTbased architecture to manage blocks of buildings. An extension of the BASOnt ontology is used at the core of OpenBMS. BASOnt being aligned with ifcOwl, it makes OpenBMS a BIM-compliant system, although the integration of BIM data is not explicitly mentioned as a functionality of the platform. Additionally, there is no reference to the integration of some preprocessing services and how the data quality is handled in OpenBMS. The BOSS (Building Operating System Services) architecture, proposed by  Dawson-Haggerty et al. (2013) , is divided into five layers: (i) the hardware presentation layer, that handles a direct communication with different on-site devices to expose the very same data to some standard REST APIs; (ii) the hardware abstraction layer that semanticizes collected data; (iii) the time series management layer to store and preprocess data points; (iv) the control transaction layer to be used by external services that can control buildings systems through a BOSS implementation; and (v) the authorization layer that handles control access.
The integration of semantic into BOSS is not fully detailed and does not seem to rely on W3C recommendations, both on the technologies used (i. e. SPARQL query language) and on the models used (i. e. SOSA, ifcOwl). While formal ontologies are relevant to associate some semantic to measure points, triple stores performance is low when handling actual time series values. To solve this issue, a hybrid architecture is presented in  Hu et al. (2016) , where both semantic data and actual values of measure points are handled. The architecture is generic in the sense that different storage solutions can be handled and described into an RDF-based ontology (RDF-DB), to ease the integration of new storage solutions; in this work, time series data are stored in relational databases. Other solutions, freely available or commercial, offer services to collect, analyze, and process data for energy management, but they do not implement a semantic data model.
Such are the cases with the open source solutions from Al  Faruque and Vatanparvar (2016)  and  Pan et al. (2015) , and the commercial Skyspark 3 solution, which limits these solutions in terms of interoperability, and evolution. Nevertheless, Skyspark is interesting in many aspects: it has a capacity to handle a huge variety of proprietary protocols (e. g. KNX, BACNet) that are used in building monitoring systems, and to offer the possibility for end users to configure their own data visualization modules. It also integrates a rule-based language to generate alerts. Finally, some initiatives to push the community towards using formal ontologies at the core of building energy monitoring applications exist. For instance, the Brick's consortium encourages to do so, but exposing data through a SPARQL endpoint is a barrier for application developers that would need to develop their own SPARQL queries, instead of using more popular SOAP or REST APIs.
Overall architecture BEMServer aims at being a core solution to deploy smart energy building solutions that are: (i) modular; (ii) extensible; and (iii) secure. A variety of data needs to be stored and exposed to end-users and connected services. Three main categories of data were identified: (i) time series 3https://skyfoundry. com/product BEMServer has been developed to manage all these data in a transparent way for end-users and to connect the two sides of the same smart building coin: the Field Level and the Management Level.
The Semantic Data Model Numerical values returned by sensors are useless without a meaning. In the double-blind architecture proposed through the BEMServer, it is necessary to attach semantic to the data extracted from sensors, smart devices, questionnaires, etc. OntoH2G, the formal ontology used at the core of BEMServer (presented in  Chbeir et al. (2018) ), allows to describe building infrastructure, including physical and digital entities, as well as user-building interactions not only in the form of activities but also comfort requirements, user preferences, and other aspects that motivate users to interact with the building. In order to do so, different domain specific ontologies are aligned, among which: • SOSA (Sensor, Observation, Sample, and Actuator) ontology, a W3C recommendation used to describe sensors, actuators, and measures, while offering various concepts to ease the alignment with other ontologies; • ifcOwl, used to describe building infrastructures and equipment; ifcOwl is the OWL version of usual EX-PRESS formatted IFC files; as such it offers concepts covering many areas of interest in building descriptions, from infrastructure, energy equipment, measurement devices, to the geometry; • Haystack, a tagging system developed by major BMSs vendors, and it is being increasingly adopted by smart building software industries, with the goal of becoming a standard so that new generations of smart measurement devices can integrate tags and attach them to the data points sent.
Services and data preprocessing The Storage level of BEMServer is in charge of attaching a semantic to the data collected on sites. This, in addition to the REST APIs of the Orchestration level, provides an easy access to the data relevant to applications at the top level of the architecture. For instance one can obtain the list of air temperature measures in a certain zone using correct filters in a REST route: https://h2g-platform-core. nobatek. com/api/ v0/measures/?location_id=XXXX&observation_ type=Temperature&medium=Air6. Such a functionality eases the integration of new applications; nevertheless, monitored data can also suffer from different issues that can prevent them from correctly running: sensors can be offline for some periods, can diverge from their initial calibration, or simply be measuring data with some undesired noise.
These situations can cause corresponding time series to contain blanks (i. e. , when no data is erroneously collected) and outliers (i. e. , data that contain abnormal values). Developers of services at the Application Level, may not be energy building experts (for instance, front-end developers) and they should just care about working with values that are as-correct-as possible. In order to assist them in their tasks, the BEMServer embeds some preprocessing services so that: • Data cleansing: blanks and outliers can be detected and corrected; • Resampling: time series data can be resampled at a desired frequency; • Conversion: time series values can be converted to a different value unit; 6The full list of APIs is available at https://h2g-platform-core. nobatek. com/api/v0/api-docs/redoc • Operations: basic arithmetic operations can be performed so as to retrieve the minimum or maximum value of a time series on a given time range; to compute the mean value or the sum of a time series on a given time range; or to sum multiple time series.
Description The Hit2Gap project aims at reducing the energy gap at the exploitation phase of non-residential buildings. Additionally, BEMServer is connected to OpenWeath-erMap7, an external service that provides current and predicted weather data (for buildings that are not equipped with a weather station). Table  2  gives an overview of the amount of data gathered by BEMServer in the Hit2Gap project. Note that more descriptive data (i. e. floors, spaces, walls, windows, surfaces, volumes. ) are available for NUIG's building, than for the other three sites, since the information was extracted from an available IFC file for NUIG, while the other sites were manually described. In particular, information on façades, walls, slabs, windows, and windows covering could be retrieved in a straightforward way, while the same information is not modeled in BEMServer for the other sites.
Feedbacks from the experiment The presentation of all the data handled in the storage layer through REST APIs was of great importance during the integration of the different modules, as the technical complexity was hidden to end users. For BEMServer developers, coding such APIs on top of a triple store is nevertheless time consuming. Several approaches are maturing to solve this issue, like the use of GraphQL for Linked Data in  Taelman et al. (2018)  or the automatic generation of REST APIs on top of Linked Data as presented in  Schröder et al. (2018). Preprocessing services reveal to be an important feature of BEMServer to help software editors to develop services, in particular for those with no expertise on building monitoring. It is important to remark that raw data is still available, so that experts can use their own preprocessing services.
The main efforts when deploying BEMServer is to collect metadata on building infrastructure and sensors. Such a task requires a close cooperation with building managers to get accurate data on measure types, units and locations. Extracting this data from an IFC file is most of the time important, as sensors are often not reported in BIM models, even though the schema offers concepts to do so. The connection with the Field Level is not entirely man-7https://openweathermap. org/ for its ability to connect to the main sensors protocols. Despite these limitations, this use case shows that BEMServer is suitable and adaptable to handle multi-sites and multitenant data in a secure way. A more complete connection to the Field level will be studied in the future, through the use of gateways between local networks protocols and web APIs, such as the one in  Bonino et al.
Conclusion BEMServer is an open source solution to deploy modular, secure, and semantic building energy management solutions. It is based on different standards from the Web (REST APIs, linked data), to ease the work of web services developers and different storage solutions to handle heterogeneous data. BEMServer is based on a semantic data model (OntoH2G), to describe measure points, as well as occupants and user information. Thus it offers a holistic model to represent the building and the human interaction impacting energy consumption. The deployment of the solution in the H2020 project Hit2Gap shows its suitability to monitor non residential buildings, and its robustness in a real case study. Its usage in residential buildings as the use of a semantic layer is perhaps not useful when few measure points are managed.
In the future, some performance issues need to be tackled to make BEMServer more efficient. Additionally, the use of the ifcOwl ontology made queries complex because of the complexity of this model, thus we wish to align our model to ontologies from the Linked Building Data W3C group, in particular the BOT ontology, which is more concise and made of direct relations between concepts, while keeping compliance with the IFC model. Additionally, the connection of BEMServer and Dog-Gateway will be evaluated to handle proprietary protocols. Finally, more preprocessing services will be developed to offer more quality of service to end-users, like blanks and outliers correction based on machine learning techniques.
Additionally, contributors of the model provide a bridge between Brick and Haystack, which is a popular system in commercial applications. More recently, Terkaj et al. (2017) proposed a building au- 2https://w3c-lbd-cg. github. io/bot/ Rasmussen et al. (2017)Morerecently, the Building Ontology Topology (BOT) 2 model was proposed byRasmussen et al. (2017)within the Linked Building Data W3C working group as the angular ontology that could be used to develop building-related domain ontologies on top of it. At the operational level, different models have been proposed to describe sensors and building equipment that are monitored. as SOSA, SSN, and BOT) and offers a detailed representation of automation states and functioning. The CTRLOnt, proposed bySchneider et al. (.
However, they did note that validation results differed among pixels, and pixel 1 has the lowest correlation while pixel 3 has the highest. Deeter et al. (2017)  is the only systematic global validation study of the MOPITT V7 algorithm. They use aircraft measurements from the HIAPER Pole-to-Pole Observations (HIPPO) campaign, and National Oceanic and Atmospheric Administration (NOAA) aircraft flask samples primarily over North America for their validation dataset. They describe the improvements included to create the V7 algorithm. They find the V7J column observations have a smaller bias and larger r (1. 4 ppb and 0. 93 respectively) than the V6J product (3. 8 ppb and 0. 89). While L1 includes radiance bias corrections, there are no empirical bias corrections to the physics-based retrieval in the L2, V7 MOPITT products.
By pulling the air through and measuring concentrations with a calibrated trace-gas analyzer, such as a Picarro, a vertical profile can be obtained. Often AirCores are flown on balloons that can reach a ceiling of around 30 km (∼10 hPa), depending on the type of balloon. Once altitude is reached, the payload is cut away from the balloon. Higher altitude data (during rapid descent) often need to be discarded, hence 22 km (∼40 hPa) is the median highest altitude in this dataset. The vertical resolution depends on tube design, measurement altitude, recovery time, and temperature but is on order of the 200-1000 m. From 2012-2017 there are 36 AirCore profiles available. AirCore profiles are used among other profile measurements to tie TCCON retrievals to the WMO scale  (Wunch et al. , 2015). Here we use them for sensitivity tests when an approximation of the true atmospheric profile is needed.
Small Region Approximation We perform a SRA on the dataset with the preliminary filter for daytime and snow/ice free scenes and preliminary pixel bias correction. In a SRA, data within a specified area and time frame are assumed to be homogeneous, and variation within that area is assumed to be non-physical. There is always some real variation in the atmosphere, however, statistically for a large sample size these variations are expected to average out. If the area is too small then there will be too few points for an unbiased We use small areas that are approximately 89 km×133 km (0. 8 • ×1. 2 • , latitude × longitude at the equator). Region size is a trade off between having sufficient points per region, while keeping regions small enough that real variations in X CO are small. The effects of different region sizes are described in the SM Sect.
Following O'Dell et al. (2018)  we make piecewise linear fits over two regimes, split at 100 ppb. The Multivariate Adaptive Regression Splines (MARS) algorithm could also be used to make a piecewise linear fit over a multidimensional dataset. However, it is more likely to overfit the data. When we applied it to the top three most variable fields the RMS for land soundings was not significantly reduced compared with our piecewise fit so we did not use those results. In addition to the single "feature" bias correction above, we apply a pixel-to-pixel bias correction after the filtering described in Sect. 3. 3. We perform a second SRA on the filtered data without a pixel bias correction. SRA data are binned separately for each pixel and land or water surface type and averaged over 10 days. On July 28, 2009 one of the coolers on MOPITT malfunctioned, which caused a 2 month instrument shut down.
In Fig. 6g  where the TCCON data do not have the standard scaling to aircraft, the bias between the datasets is less than 0. 874 [6. 3, 6. 4, 6. 4, 6. 5   Figure  7  shows boxplots of the MOPITT to TCCON differences for each site for land only and water only soundings. We do not note an overall bias between land and water. For all sites the TCCON-MOPITT bias is positive and usually on order of about 3-10 ppb with a few exceptions. For example, MOPITT observations compared to the AFRC (df) TCCON are particularly high (∼14 ppb). This could be related to the high albedo or high surface temperatures of this desert site. 30 20 10 0 10 20 30 40 X CO , ( M T T ) (%) lh (-45. 0) ll (-45. 0) wg  (-34. 4 ) wg  (-34. 4 ) ra (-20. 9) db (-12. 4) db  (-12. 4) ae (-7. 9) ma (-3.
Model assimilations We assimilate MOPITT observations using the GEOS-Chem model to show how filtering and the bias correction affect estimated emissions inferred from inversion analyses. We conducted three experiments in which we assimilated the following datasets: 1) the original MOPITT data, 2) the filtered and bias-corrected data with a scaling to the standard TCCON data (Fig. 5 ) (referred to as Assim. 2), 3) the filtered and bias-corrected data with a scaling to the TCCON-based data not tied to the WMO scale and without the empirical airmass correction (Fig. 6g ) (referred to as Assim. 3). The assimilation is performed using the GEOS-Chem four-dimensional variational (4D-Var) data assimilation system, employing version 35J of the adjoint model at a horizontal resolution of 4 • × 5 •. The GEOS-Chem 4D-Var system has been used in previous studies for assimilation of MOPITT data (e.
g. ,  Deeter et al. , 2015). A bias correction should be considered when assimilating pixel 1. There is a bias in the SRA for large retrieval errors on X CO above about 8 ppb (SM Fig. S4o, S5o ). This bias suggests that perhaps these data should be excluded or deweighted further, which we did not do here. A bias adjustment field could also be included as a field in future MOPITT files. Such an adjustment could account for empirical biases noted with various parameters, pixel-to-pixel biases (Sect. 3. 4), and an overall bias compared with NDACC  (Buchholz et al. , 2017) , aircraft flights  (Deeter et al. , 2017) , and/or TCCON. For method 0, priors, averaging kernels, and surface pressures are not considered. Subscript T =TCCON, M =MOPITT, a=a priori, the prime symbol represents an adjustment if another prior were used, and the left arrow indicates what would be observed from one system in the absence of error, if the profile from another was taken as truth.
2 inventory, which are overwritten regionally with the following inventories: the Streets 2006 emissions over China and Southeast Asia from Zhang et al. (2009), the annual Canadian anthropogenic emissions from the Criteria Air Contaminants (CAC), the National Emissions 2005 Inventory (NEI2005) from the United States Environmental Protection Agency (EPA), the Co-operative Programme for Monitoring and Evaluation of the Long-range Transmission of Air Pollutants in Europe (EMEP) inventory, and the Big Bend Regional Aerosol and Visibility Observational (BRAVO) inventory in Mexico. The Global Fire Emissions Database version 3 (GFED3) provides the biomass emissions. The biofuel emissions are the Yevich and Logan (2003) inventory. The initial condition of CO states is generated by spinning up the GEOS-Chem model from January 2009.
The Ascension Island TCCON station has been supported by the  European Space Agency (ESA)  under grant  3-14737  and by the  German Bundesministerium für Wirtschaft und Energie (BMWi)  under grant  50EE1711C. The Four Corners and Manaus TCCON stations have been supported by  LANL-LDRD. The Eureka TCCON measurements were made at the  Polar Environment Atmospheric Research Laboratory (PEARL)  by the  Canadian Network for the Detection of Atmospheric Change (CANDAC) , primarily supported by the  CSA ,  NSERC , and  Environment and Climate Change Canada (ECCC). The East Trout Lake TCCON station is supported by the  Canada Foundation for Innovation , the  Ontario Research Fund , and  ECCC. Work at Anmyeondo was funded by the  Korea Meteorological Administration Research and Development Program "research and development for KMA Wheather, Climate , and Earth system services-support to use of  Meteorological Information and Value Crestion " under grant ( KMA2018-00321 ).