dataesr/scientific-paragraphs-categorization huggingface dataset:
XLVI 2016). In Sect. 2. 2, we have shown how SimAll, the low-EE likelihood approximation used in the reference likelihood, relies heavily on the HFI endto-end part of the FFP10 simulations. The low-parts of the Planck likelihood have been validated through an extensive suite of tests. We find excellent consistency between the different data selection cuts tested (masks, data splits, etc. ). In polarization, we note the pull of the = 5 multipole of the EE spectrum results, which appears quite high and thereby pushes up the best-fit τ value. However, using simulations, we have shown that the τ constraints with and without the = 5 multipole only disagree at about the 1. 6 σ level. We have listed in Sect. 2. 2. 6 the limitations of our low-polarization likelihood approximation. We note that limitations in the systematics corrections (in particular, the analogue-to-digital converter nonlinearities) translate into an overestimation of the variance of the lowest multipoles in our simulations, leading us to suspect that refinements in both the analysis and simulations (such as those carried out in  Delouis et al.
In the case of extended cosmological models, however, the choice of polarization-efficiency correction model does have an impact, modifying by about 0. 5 σ some of the cosmological parameters, as we have reported in Sect. 3. 7. In order to explore the impact of the polarizationefficiency correction model (along with other variations of the choices made in the reference high-likelihood implementation), the CamSpec likelihood (described in Sect. 3. 5. 1 and summarized below) incorporates the spectrum-based correction, and is used in PCP18 to assess the robustness of the constraints to variations of the likelihoods. In the end, the polarizationefficiency estimation will remain one of the limitations of the Planck results. Comparison of the Planck HFI polarized data with future high-precision CMB experiments could help to mitigate this deficiency, but will be ultimately limited by the Planck noise level.
Using the FFP10 simulations we have built an empirical correction template that we include in the data model of the likelihood. Looking at the mean of the retrieved cosmological parameters on our 300 simulations, we have found a 2. 8 ∆ shift 29 on n s in TE, which corresponds to a possible 0. 16 σ systematic shift in a single realization (again when using TE alone). Finally, when comparing the cosmologi-cal parameters obtained for the different levels of complexity of our simulations, we have found a 0. 3 σ disagreement on n s in EE between two versions of the simulations, where we would not have expected such a shift. Given the limitations of the FFP10 simulation suite, it is not possible to determine whether this is due to the particular single sky and foreground realization used in the end-to-end simulations or is an indication of a different problem.
While both CamSpec and Plik T T exhibit the same high A L value, the differences in polarization-efficiency correction models between the two likelihoods shift the value of A L in the joint T T T EEE cosmological constraint, as we have discussed in Sect. 3. 7. Assessment of residual systematics Estimating the level of residual systematics and uncertainty is in many ways an ill-posed problem. Whenever a particular systematic effect has been detected and modelled, we correct for it, and we performed a comprehensive series of tests to identify such residual systematics. That process leaves us with some remaining minor failures of our different robustness and coherence tests, which we summarize in this last subsection. Overall, our validation tests of the high-likelihood demonstrate the robustness of the Planck high-temperature and polarization data analysis.
5 σ level or less. It is for these two reasons that we estimate the robustness of our likelihood validation to be at this level. Note, however, that this does not mean that we are affected by a systematic 0. 5 σ residual effect. The differences between the different PE-correction models can be entirely explained by statistical fluctuations, and in the particular case of CamSpec also by the mask differences. Both likelihood products are available, and the Plik one allows us to test both PEcorrection models and to jointly explore the PE corrections along with cosmology and other nuisance parameters, allowing us to test the sensitivity of any cosmological model constraints to different data modelling choices. We followed this approach in both PCP18 and Planck Collaboration X (2020), and highlighted the cases where some small dependency on the modelling choice was observed.
Future outlook Despite the important tightening of the constraints on the cosmological model and its parameters since COBE, the Planck results are still in excellent agreement with the basic 6-parameter ΛCDM model. However, we do report some "curiosities," consisting of apparent deviations of the data from expectations at between the 2 σ and 3 σ level, such as: the low-power deficit in temperature; the A L deviation; and the mild disagreement between the < 800 and > 800 parts of the T T spectrum. These deviations are not independent from each other, but are tightly correlated, and are different ways of projecting the same power-spectrum fluctuations onto cosmological parameters. Nevertheless, the Planck data by themselves do not give us any compelling reason to extend the cosmological model.
Those small anomalies were already reported in papers accompanying previous Planck releases. They are still present in the power spectra we use for this 2018 release and the new effects that we tested here (e. g. , aberration or beam residuals) cannot explain them. The T T power spectrum carries the bulk of the cosmological information coming from Planck, and those small deviations have an impact on the joint TT,TE,EE likelihood. The constraining power of the polarization data is not yet sufficient to confirm or disprove any physical model for those deviations. The best current explanation for these curiosities is that they are simply statistical excursions in the T T power spectrum. There are a few remaining ways of further improving the constraining power of the Planck data. As we noted above, improvements in both the analysis and simulations (such as the ones carried out in  Delouis et al.
Further improvements might be achievable by reducing the apodization length of the Galactic masks. All of those steps will require significant work on the covariance estimation and thorough validation. Planck has shown how much information can be obtained by combining the temperature and polarization anisotropies of the CMB. Despite the limitations of the data and their analysis (and in particular the accuracy of the polarization efficiency of the detectors), both temperature and polarization data have been found to be in excellent agreement and strongly support the ΛCDM model. Just as COBE and WMAP did in their time, the Planck legacy sets a solid foundation for future CMB experiments and other probes of the cosmological model.
Acknowledgements. The Planck Collaboration acknowledges the support of:  ESA ;  CNES  and  CNRS/INSU-IN2P3-INP (France) ;  ASI ,  CNR , and  INAF (Italy) ;  NASA and DoE (USA) ;  STFC  and  UKSA (UK) ;  CSIC ,  MINECO , JA, and  RES (Spain) ;  Tekes, AoF  and  CSC (Finland) ;  DLR  and  MPG (Germany) ;  CSA (Canada) ;  DTU Space (Denmark) ;  SER/SSO (Switzerland) ;  RCN (Norway) ;  SFI (Ireland) ;  FCT/MCTES (Portugal) ; and  ERC  and  PRACE Planck Collaboration:  Planck likelihoods Gran Sasso Science Institute ,  INFN , viale F. Crispi 7, 67100  L'Aquila ,  Italy HEP Division, Argonne National Laboratory, Lemont, IL 60439, USA Haverford College Astronomy Department, 370 Lancaster Avenue, Haverford, Pennsylvania, U. S. A. Helsinki Institute of Physics, Gustaf Hällströmin katu 2, University of Helsinki, Helsinki, Finland IFPU -Institute for Fundamental Physics of the Universe, Via Beirut 2, 34014 Trieste, Italy INAF -OAS Bologna ,  Istituto Nazionale di Astrofisica -Osservatorio di Astrofisica e Scienza dello Spazio di Bologna ,  Area della Ricerca del CNR ,  Via Gobetti 101 ,  40129 ,  Bologna, Italy INAF -Osservatorio Astronomico di Padova, Vicolo dell'Osservatorio 5, Padova, Italy INAF -Osservatorio Astronomico di Trieste, Via G.
A4IoT comprises a crowdsourcing architecture where deployers can collect and organize fingerprint signals inside smart spaces in a designated localization service running on the Edge (from Raspberry to Datacenter). The service incorporates timeseries databases for tracking targets and deployers can provide accurate room-level localization accuracy (≈ 2 m) on a variety of platforms (e. g. , Android, Linux, Mac, Windows, Robot OS) but also integrate A4IoT through Web 2. 0 endpoints to their software ecosystems.
e. , floor-level) localization combined with modeling and crowdsourcing under the same hood. Even though the open source software stacks have helped to the wider adoption of important scientific findings (enabling the integration of new localization algorithms) but also transparency of what happens behind the service, none of these architectures provide elements for IoT tracking at Internetscale (e. g. , Cloud) and at Minuscale (e. g. , Raspberry). In this paper, we introduce a novel open-source architecture for IoT localization (see Fig. 1 ), coined Anyplace 4. 0 IoT (A4IoT), which exploits signal fingerprinting to organize under the same roof a wide range of different localization technologies (e. g. , Wi-Fi, BLE, Cellular, UWB, Computer Vision). We present the technical requirements of A4IoT inspired by the The localization literature is very broad and diverse as it exploits several technologies.
GPS is obviously ubiquitously available but has an expensive energy tag and is also negatively affected by the environment (e. g. , cloudy days, forests, downtown areas). Besides GPS, the localization community proposed numerous proprietary solutions including: Infrared, Bluetooth, visual or acoustic analysis, RFID, Inertial Measurement Units, Ultra-Wide-Band, Sensor Networks, Wireless LANs, etc. ; including their combinations into hybrid systems  [17]. A4IoT uses a hybrid Radiomap-based indoor localization, which stores radio signals from (like Wi-Fi APs, BLE/UWB/Cellular/CV) in a database at a high density. We next explain the localization subsystem of A4IoT, which utilizes the notion of fingerprinting in order to bring forward a localization technology that works seamlessly on the edge/IoT device with optional extensions for intermittent connectivity  [18]  and privacy  [19].
Section II describes the business requirements of Alstom SA for incorporating Industry 4. 0 in their factories. It is followed by Section III that gives an overview of our new backend architecture. Section V describes our modular library that enables easy deployment of A4IoT in any environment. In Section VI we detail the necessary changes to our data layer to support high-velocity spatio-temporal data, while decreasing our minimum hardware requirements. Our realtime visualization analytics are described in Section VII and our concluding remarks are in Section VIII.
The solution for smart devices used by workers is to utilize a modified version of our Android client for communicating with the Anyplace server. For tools, externally attached modules will augment their functionality to incorporate Wi-Fi, GPS, and/or mobile data. Then, custom scripts embedded into the attached modules will communicate with our service. Those scripts will utilize the Anyplace Java library. No power: Assets like tools or parts may come without a power source. Tools have a lifecycle of many years and are divided according to their size, small or big. Parts, which have a lifecycle of a few months, are also divided into small or big. There is, however, a special third category for consumable parts, like bolts or nuts. Small tools, like hammers or screwdrivers, move quite often and require 0.
Front-end: Architect, Viewer, and Analytics modules are Web Apps built with HTML5, CSS3, and AngularJS. Architect allows users to insert buildings by uploading architectural floorplans and then interactively designing on top of them routes and Point of Interest (POI) elements. Viewer is a search and navigation engine built on top of the crowdsourced data. Analytics is a data visualization dashboard that interacts with the Data Store and is described in Section VII. Logger and Localization are native Android applications that enable fingerprinting and localization, respectively  [25]. Logger in particular, enables users to crowdsource collected Wi-Fi RSSI values by recording them from nearby Wi-Fi Access Points and batch-feeding them to the Server. Localization allows users to view their location inside buildings.
A. Single-node deployment The A4IoT docker image initially installs any software dependencies used by the service. Then, depending on the target environment, development or production, relevant code is pulled from A4IoT's GitHub repository using Jenkins and compiled using the sbt tool. Configuration for all A4IoT components is conveniently managed through a single. env file, removing any sensitive information from the source code. Then, separate container instances are spawned for each database service to enhance security and resource handling. All communication is encrypted even in internal networks, as A4IoT image automatically creates and uses SSL certificates based on the configuration. Also, any relevant database initialization, including bucket and views creation, is automatically handled by the image.
B. Multi-node cluster deployment In the case of a cluster deployment, additional configuration is needed for each node of the cluster that can be passed through the. env files. Specifically, it allows plugging in external database or DFS clusters, and SSL certificate authorities. Finally, on a separate node a HaProxy  [26]  container is spawned and set-up to balance the incoming load and provide protection from attacks like DDoS. A4IoT Cluster: Our production environment uses a 3-node cluster with two replicas, for both the database engines and the DFS. This setup allows for a full operation with just a single node active at any time and clearly adopters of A4IoT can adjust the configuration scale to their requirements. For the DFS in particular, we configured GlusterFS that exposed exceptional performance for a variety of loads.
A. Java library: anyplace-core The anyplace-core Gradle library encapsulates the main functionality for IoT clients. It is as generic as possible to facilitate clients' development for different environments and operating systems. The library emits statically or dynamically generated information to the users. Finally, it allows dynamic switching between different A4IoT backends, and wraps each API endpoint with code that transparently handles communication with the backend. Static Content: It relates mostly to raw, infrequently mutating data, such as buildings. There are endpoints that return buildings to the proximity of a user, buildings that belong to a campus, or the complete list of all the buildings. Given a building, the library can return a list of all the floors and all the POIs. The list of POIs can be further narrowed down to the ones that belong to a particular floor.
B. Command Line Interface (CLI) The anyplace-core library also has a CLI. Instead of including the library JAR file into another Java-based project, it is executed directly from shell applications from either local cache or the A4IoT service. The snippet in Fig. 1  performs a server-side localization using a bash script. The Wi-Fi RSSIs are extracted and fed to the tool along with the user's id, the floor that the user is in, and the localization algorithm. While it works specifically for Linux, with a minor adjustment it can also run on macOS. In particular, the Wi-Fi RSSI scanning should be performed through the Network Manager tool nmcli 5 instead. The CLI is particularly convenient as it allows developing IoT clients with minimal effort. 1 #!/bin/bash 2 ALGO=$KNN 3 interface="wlo1" 4 # Get RSS values (Linux specific) 5 rssi=$(jsonFormat $(iwlist $interface scan)) 6 # Localize 7 CMD=$(java -jar anyplace.
C. Android Library and Demo Client Android provides its own APIs for carrying out tasks for increased security and performance. This additional functionality is included into anyplace-android, another Gradle library that includes the anyplace-core library. 5 NetworkManager: https://linux. die. net/man/1/nmcli Listing 2: Demo client utilizes the anyplace-android library to fetch all floors of a given building id. The anyplace-android library declares any permissions that are necessary for the successful operation of the service. These include Internet access, permissions to read the Wi-Fi RSSI values, ability to run code in the background, and access to storage. Network communications and subsequent computations are wrapped into asynchronous tasks as necessary, since their associated overheads might affect the UI responsiveness.
VI. A4IOT SPATIO-TEMPORAL DATA STORE This section describes the additions to the Data Store component of A4IoT. A spatio-temporal database is integrated into the backend to efficiently consume input streams of IoT sensor data. Additionally, existing views are being migrated to MongoDB  [27]  in an effort to reduce the minimum hardware requirements. Time-Series store: For the efficient consumption of raw IoT data a time-series database is incorporated into the Data Store. This enables real-time analytics and visualizations presented in Section VII, instead of selectively performing them with manual batch operations. In particular, we have implemented controllers for InfluxDB  [28] , which was consistently ranked top for write-intensive workloads. It is also optimized for spatio-temporal queries, in contrast with CouchbaseDB  [29]   that is a more generic document-store.
Document-store: The initial version of our software used CouchbaseDB, which is a document store with a built-in distributed in-memory layer (memcached), enabling easy eventually consistent distributed replication. However, the computational requirements of this approach constitutes this inefficient for edge devices, such as, the popular ARMv7 Raspberry PI. As such, A4IoT is expected to migrate to the less demanding MongoDB document store in the near future. Micro-benchmarking: In Fig. 5  we present the results of our Data Store evaluation by comparing InfluxDB against Couch-baseDB. We have used datasets ranging from 1 thousand to 1 million entries, built from real RM data from Anyplace. Error bars show the standard deviation and results are presented on a logarithmic scale, where appropriate.
Fig. 5  (left) shows data ingestion with different number of insertions. We observe that InfluxDB has almost an order of magnitude less ingestion time for any number of insertions. For 1 million entries, InfluxDB is impressively 7x faster than CouchbaseDB. Fig. 5  (center) shows the performance of InfluxDB against CouchbaseDB over a variety of query operations. The time-series database is consistently faster in all cases. Particularly, for the RANGE query, which filters out about 50% of the tuples over a time-slice, InfluxDB is 28% faster. InfluxDB is 2. 3x faster considering the AGGR query that aggregates the output of the RANGE query. For the EXACT query, which returns a random entry from the database, InfluxDB is 3. 6x faster. Finally, the SCAN query simply emits all the entries and still the InfluxDB is 20% faster.
VIII. CONCLUSIONS AND FUTURE WORK In this paper, we introduce a novel open-source architecture for IoT localization, coined Anyplace 4. 0 IoT (A4IoT), which exploits Fingerprinting principles to organize under the same roof a wide range of different localization technologies (e. g. , Wi-Fi, BLE, Cellular, UWB and CV). We present the technical requirements of A4IoT inspired by the Alstom SA smart factory, operating worldwide in rail transport markets. We have implemented an InfluxDB controller, to consume highvolumes of IoT generated data, and we are gradually migrating the remaining of our data views to the more lightweight MongoDB. This allows our architecture to run on low-end single board computers, placed on the edge, while being able to scale to sophisticated multi-node cluster setups.
Acknowledgements: We would like to thank the researchers at the  Data Management Systems Laboratory of the University of Cyprus  and the  Anyplace Community  at wide that have contributed to this open-source project over the years. The A4IoT extensions are supported in part by  Cyprus' Research Promotion Foundation   RESTART 2016-2020  programme, under project  EnterCY   INTE-GRATED/0609/0020 ;  EU 's  Horizon 2020 research and innovation programme project LASH FIRE  under grant agreement nº  814975 ; and  EU's Marie Skłodowska-Curie Actions  ( MSCA )  H2020-MSCA-RISE-2018  project  ENDORSE , under grant agreement nº  823887. The fifth author is supported by  EU 's  Horizon 2020 research and innovation programme  under grant agreement nº  739551  ( KIOS CoE ) and from the  Republic of Cyprus  through the  Directorate General for European Programmes, Coordination and Development.
25: end while 26: until time() ≥ tmax MAMMDP * is composed of four components: a population initialization procedure, a tabu search based optimization procedure, a crossover operator, and a population updating rule. For the sake of completeness, the pseudo-code of the MAMMDP * algorithm, which closely follows the MAMMDP algorithm in  (Lai and Hao, 2016) , is shown in Algorithm 5, where P OP = {s 1  ,. , s p } denotes the current population, s o denotes the new solution generated by the crossover operator or by the tabu search procedure, s * and s w denote respectively the best solution found so far and the worst solution in P OP , and P airSet represents the set of solution pairs that have not been used by the crossover operator in P OP. MAMMDP * starts with the initial population generated by the initialization procedure in Section 2.
In addition, both MAMMDP * and PBEA were implemented in C and compiled by the g++ compiler with the -O3 option, and the corresponding experiments were carried out on a computing platform with an Intel E5-2670 processor (2. 5 GHz and 2G RAM), running the Linux operating system. The source codes of the proposed MAMMDP * and PBEA algorithms will be available at http://www. info. univ-angers. fr/pub/hao/gmaxmeandp. html.
Experimental Protocol In addition, due to the stochastic feature of both algorithms, PBEA and MAMMDP * were independently run 20 times to solve each instance based on the same time limit t max for each run, where t max was set to 100, 500 and 1000 seconds for the instances with n ≤ 2000, n = 3000 and n = 5000, respectively. Finally, we employed a commercial software called LocalSolver (https://www. localsolver. com/) as our reference algorithm, since no direct reference algorithm is available in the literature for the GMaxMeanDP. In our experiment, we ran LocalSolver once for each instance with the same time limit t max as our proposed algorithms on a computer with a Intel i7-6700 processor (3. 4 GHz CPU and 4G RAM), running Windows 10 operating system, since we only obtained an academic license of LocalSolver on this computer.
Acknowledgments We are grateful to the reviewers for their valuable comments and suggestions which helped us to improve the paper. This work was partially supported by the  Natural Science Foundation of Jiangsu Province of China  (Grant No. BK20170904 ), the  National Natural Science Foundation of China  (Grant No. 61703213 ), six talent peaks project  in Jiangsu Province  (Grant No. RJFW-011 ), and  NUPTSF  (Grant Nos. NY217154  and  RK043YZZ18004 ).