dataesr/scientific-paragraphs-categorization huggingface dataset:
The base VM is then deployed to any platform that will serve as a Cloudlet. We assume that we have a VM overlay in the mobile device side. In the Cloudlet side, a VM instance is rebuilt by this overlay. The mobile device connects to the Cloudlet upon detecting its IP address, using the program "synthesis_client" and supplies the VM overlay. When the mobile device sends the VM overlay to the Cloudlet, the Cloudlet server starts performing the VM synthesis operation. 1 Bring Your Own Device (2) OSGi. For the mobile device, the OSGi framework is installed on an emulator with the following characteristics: Device Nexus S (4. 0", 480 * 800: hdpi)); Android 2. 2 -API level 8; Ram 343; VM Heap: 32; Internal Storage: 60MB Bundle size: 32 KB. In the Cloudlet side, the OSGi framework is hosted in a specific VM.
(3) Docker container. Even though Docker container engine can be installed on Windows operating system, both the mobile device and the Cloudlet operated under Linuxbased OS to run Docker containers. In Docker technology, the application is isolated within a container that is managed by a container engine within the mobile device. Instead of offloading the entire container to the Cloudlet, that can be heavy (600 MB in our experiments) in size and energy consuming, we offload only the layer that hosts the application. To compare the difference among these discussed Cloudlet implementations, we consider calculating the execution time locally by examining four different sizes of programs as presented in table  1. We then compare these programs under OSGi, Elijah and Docker platform to measure their execution time.
Introduction From home automation to smart cities, from amateur weather stations to large deployments of smart power meters in datacenters, Internet of Things (IoT) applications target more and more end-users every day. The link between these users and the IoT is usually provided by applications deployed over a sensor network. A recurring problem concerning sensor networks is the heterogeneity, not only of sensors, but also of the protocols used to access them, often characterized by their low bandwidth and poor reliability. To address this issue, the notion of data streams has emerged, leading to a change of paradigm around data parsing, from traditional DataBase Management Systems (DBMS) to Complex Event Processing (CEP). Instead of processing stored persistent data through volatile queries, CEP parses volatile data stream as it comes through persistent queries.
This allows to reduce lengths of queries an end-user can express as they are able to manipulate nothing more than what he considers to be relevant information. Moreover, decision making can be automated in order to address actuators specific features in addition to sensors data gathering. The remainder of the paper is organized as follows. Section 2 studies existing work about data semantics and CEP. In section 3 we draw up the motivation for integrating CEP with SensorScript. Sections 4 and 5 introduce the model and the language which ensure complex event processing. Section 6 evaluates the language concision and the underlying query management through a demonstration scenario. Finally, section 7 concludes by presenting future work.
Related Work Data identification has been a prominent track of research over the years. We can divide the existing work into two categories: data semantical enrichment on one hand; context aware data stream mining on the other hand. Several publications about context awareness for the IoT are discussed in  [13]. In this paper we will focus on solutions which provide real-time processing of the data stream, as it is a strong requirement for complex event processors. In  [18]  data semantics are provided by a separated knowledge base, which is a Resource Description Framework  [9]  (RDF) store. Thus event queries mix raw events extracted from the data stream and background knowledge retrieved from the knowledge base. That allows to establish relationships between the raw events. RDF knowledge base access is done through SPARQL  [20]  queries.
Thus it uses XQuery  [2]  to express queries that address both real-time and historical data querying. This broadens the use of the DBMS, as it stores both contextual and historical data. These two solutions however rely on pre-existing solutions to bundle both data mining (being real-time or periodic) and context-awareness, which leads to hybrid querying over the data. COPAL  [11]  aims at providing a DSL to broaden the notion of context from sole location to handle processing environments in the case of distributed processing. This DSL provides a complex event processor in order to compose events through a declarative, and quite verbose, developer-centric syntax, in the sense that a user has to learn the underlying model before composing events. A common issue of these solutions remains in the context storage, generally based on a decoupled DBMS, which impacts the simplicity of queries.
The runtime additional cost of addressing the DBMS and couple its information with the raw data is addressed by none of these publications. Concerning CEP languages, other contributions mainly aimed at adapting Structured Query Languages (SQL) to manage data streams and event composition. CQL  [1]  is one of the first to do so. The change of paradigm from relational databases to complex event processing focuses on the notion of a relation. A relation is addressed in the from clause, like tables in SQL, and mapped over time windows to a finite set of data from. Other than time windows, partitioned windows can also be expressed, providing a partition over the data stream similar to the SQL group by clause. TinyDB  [12]  provides time windows with a dedicated additional clause rather than a mapping over data stream.
It also allows to specify a recovery rate for queries execution, jeopardizing efficiency as there is no guarantee that the data will be updated at at least the same rate of the accesses defined in queries. Aiming at providing more flexibility over windows specification, Esper  [6]  provides the notion of pattern which orchestrates both time windows and data filtering with boolean operators. WildCAT  [5]  aims at coupling Esper Processing Language (EPL) with data context awareness through hierarchical contexts definition. However, this semantical enrichment of data operates as on overlay to Esper rather than being fully integrated within EPL. Another track focused on declarative event specification. AmbientTalk  [19]  uses this concept for the actors within mobile ad-hoc networks, as a mean to leverage the problematics specific to these infrastructures.
Motivation SensorScript was based on a previous work: btrScript  [14]. btrScript is a datacenter monitoring DSL inspired by XPath  [3] , in particular its queries which allow implicit pathfinding within a tree. Indeed the DSL is backed to two static trees to address both virtualized and physical aspects of a modern datacenter. In  [7] , we altered the underlying model to manage any number of configurable intricated trees, which allows SensorScript to address the diversity of sensor networks. The trees intrication of the model will be detailed in section 4. The benefits of such a modelling are two-fold. On one hand it offers a good semanticization over the data by integrating it within tree contexts. On the other hand, queries remain concise as the model still relies on trees. Hence, we consider these features make SensorScript a strong candidate to be integrated within a complex event processor, as existing CEP languages suffer from verbose queries.
Language The main objective of the SensorScript language is to allow users to express CEP queries about their own field of expertise, regardless of the complexity of the whole underlying multitree model. As we saw in section 2, existing CEP DSL derive from SQL, thus require users to know more of the underlying model than what should be needed. In contrast, SensorScript comes with a language which leans on the multitree model and takes advantage of the relations between its nodes to provide implicit connections among them, regardless of the distance separating them in the model. As we want to keep the language as concise as possible, we choose to use character operators rather than english words based syntax, which we hope significantly reduces the verbosity of queries. Naturally, the language reflects the selection, access and condition concepts constituting a query as presented in section 4.
Foreach A particular aggregation use case allows to partition the selection to provide a behavior similar to the group by clause in MySQL. This is what we call the foreach aggregation method access, expressed by the colon operator in rule 1. To explain how it is expressed, we will consider this example , and its equivalent in SQL: SensorScript SQL room42/breaker:powermeter. sum(power) SELECT sum(powermeter. power) FROM breaker, powermeter WHERE breaker. room = 42 AND powermeter. brId = breaker. id GROUP BY breaker. id We see here two selections around the colon operator, which are breakers from room 42 for the first one, powermeters for the second one. Besides, the sum method is called on the power attribute from powermeters. De facto, this query will follow power updates for each room 42 powermeter.
Evaluation This section proposes to evaluate the language concision through some examples over the model from figure  1  and compare them with similar examples from the literature. Then we propose a scenario which reflects a more complex yet realistic use of the language. Both approaches focus only on syntactic concision of the language, performance evaluation will be subject to future work. Futhermore, we will specifically look at timed conditions management as they bring an additional constraint over the model dynamicity. Finally, we will highlight the limitations of SensorScript in terms of features, compared to other CEP languages.
These three contexts are directly inspired from the example of CQL  [1]. This example considered an auction system, for which we propose the mapping table 1 in order to stick to our conference tracking system. Table  2  gives a comparison between SensorScript and CQL queries based on the aforementioned mapping. 1. The first query allows to select presentations that occur after noon. It is conceptually very similar to the CQL query, as the condition between braces corresponds to the one declared in the where clause. 2. This second query aims at maintaining a running count of attendees to tracks 1 and 2 over the last hour. There is an important difference here as time windows can only be specified within conditions in SensorScript. This results in two conditions specified over the two sub-selections of the whole selection.
3. With this query we want to maintain a list of the current presentations. The main difference here is that SensorScript relies on attributes updated with the data stream over the nodes of the multitree, where CQL backs to table-like streams to manage the presentation state (ongoing or over ). 4. Given that we want here to list the present attendees, we only need to add a sub-selection to the previous query with SensorScript, considering that a present attendee is an attendee that checked in a current presentation. On the other hand, CQL proposes a whole new, though significantly longer, query, based once again on streams that reflect presence or absence of attendees. 5. As presentations can be rescheduled during the conference, we consider now that speakers check-ins affect directly the state of presentations.
Limitations CQL  [1] , TinyDB  [12]  and Esper  [6]  take advantage of SQL to address both dynamic and persistent data. Considering SensorScript is designed over data streams only and ensures real-time processing of data, we could not afford to keep a history over the data. In fact, even timed conditions do not require a history to be checked. As we only have to make sure that the condition holds for the specified time, this is the unique information to keep during the lifetime of the condition, which is also discarded as soon as the condition is unsatisfied or the time is over. However, we do not aim at replacing traditional DBMS, that can be used in parallel, whether storing the whole data stream or data prefiltered by SensorScript. Languages as AmbientTalk  [19] , REScala  [15]  or EventCJ  [8]  aim at integrating event specification into existing programming paradigms.
Conclusions and Future Work We presented here the evolution of SensorScript towards a language for complex event processing dedicated to sensor networks. While the model mainly relies on previous works, we highlighted how the new language builds on the multitree in order to provide complex event processing mechanisms. We are able to balance the syntactic concision of the language with a real-time complex event processor for sensor networks. By providing flexible selections over the nodes, with the possibility to filter them on complex conditions, possibly over a time window, we offer a strong alternative to traditional SQL used in the literature. Moreover, SensorScript does not focus only on data access. In fact it provides the possibility to widen the scope of the methods accessible on nodes to other features than sensors monitoring, including but not limited to addressing actuators functions.
In this study, we first re-examine the global insect fossil record to account for the changes in family-level insect diversity  [3] [4] [5] 24  and analytical methods  29, 30  that have occurred in the last twenty years. We then re-analyse a recently published molecular phylogenetic dataset using two distinct state-of-the-art diversification analysis methods, which either complement (TreePar 31 ) or outperform (BAMM  32  ) the earlier MEDUSA approach. Both  he analyses of fossil and molecular data are expected to provide additional insights into the pattern of insect diversification over time, especially in relation to the role of (i) mass extinctions, (ii) environmental changes associated with the KTR and (iii) key innovations such as wings and complete metamorphosis.
Inference of speciation rate shifts, key innovations, and diversity-dependence. We used phylogenetic data coupled with the BAMM 32 model, which is designed to automatically detect changes of speciation rates, to assess key innovation and diversity-dependence pattern. The BAMM analyses converged well as indicated by high ESS values (ESS log-likelihood = 365. 7, ESS number of shifts = 494. 2) and the stationarity of the MCMC (Supplementary Figure  S2 ). We recovered eight significant rate shifts (Supplementary Figure  S3 ) according to Bayes factors (BF = 94. 98 over the null model). More specifically, the post burn-in posterior distribution of the number of shifts supported models with six shifts (PP < 0. 02), seven shifts (PP = 0. 24), eight shifts (PP = 0. 36), nine shifts (PP = 0. 24), ten shifts (PP = 0.
e. monophyletic groups). Insect families individually possess discrete, often highly stereotyped life habits, and their morphologies directly reflect their trophic guilds, which are informative in diversity studies. Fossil and phylogenetic data. Fossil occurrence data were downloaded on a recent version of the Paleobiology Database by selecting the 'family level' , 'order level', and 'geological epochs' options (last accessed October 15 th , 2015), mostly compiled by M. E. C. We downloaded 40,046 fossil occurrences, and cleaned the data by checking for synonymies among all taxa. The final dataset contains 38,013 and 39,240 occurrences for the family-level and the order-level fossil record, respectively. The two datasets are available on the website of Scientific Reports (Supplementary Tables  S1, 2 ).
Within a given regime, evolutionary dynamics can involve time-variable diversification rates; in BAMM, the speciation rate is allowed to vary exponentially through time while extinction is maintained constant  32, 50. Subclades in the tree might diversify faster (or slower) than others, and BAMM allows detecting these diversification rate shifts and compare how many and where these shifts might occur. BAMM provides estimates of marginal probability of speciation and extinction rates at any point in time along any branch of the tree. Marginal probabilities of the number of evolutionary regimes can also be computed, allowing comparisons of models with a given number of shifts with Bayes factors. BAMM is implemented in a C ++ command line program and the BAMMtools R-package  51. We set four rjM-CMC running for 50 million generations and sampled every 50,000 generations.
On the contrary, BAMM estimates clade-wise shifts of diversification coupled to time-dependence variation of rates. Here we used TreePar to estimate speciation and extinction rates during a specific time interval (i. e. 50 Myr ago until the crown age of insects at 479 Myr ago), whereas BAMM was used to examine the whole clade evolutionary history; (iii) TreePar takes individual branch as a single lineage, whereas we informed each lineage with the total clade diversity for BAMM analyses; and (iv) both methods also differ in the way they deal with incomplete taxon sampling. TreePar allows the user to specify the fraction of sampled diversity in the dataset while BAMM allows the user to incorporate information on species richness for each sampled lineage.
We used a Bayesian model that simultaneously infers the temporal dynamics of origination and extinction, as well as the preservation  29. This approach, implemented in the program PyRate 30 0. 600 (https://github. com/dsilvestro/ PyRate, last accessed October 15, 2015), uses as input data all fossil occurrences that can be assigned to a taxon, in this case fossil genera, to jointly model the preservation and diversification processes. The preservation process infers the individual origination and extinction times of each taxon based on all fossil occurrences and on an estimated preservation rate, denoted q, and expressed as expected occurrences per taxon per Myr. We followed the PyRate approach as the study that analysed the evolutionary history of vascular plants  55. This approach included appropriate modifications for the fossil data and the aims of this study, which is focused on variation in origination and extinction at global scale and large temporal ranges.
The estimation of origination and extinction rates within fixed time intervals improved the mixing of the MCMC and allowed us to obtain an overview of the general trends of rate variation throughout a long timescale  55. Both the preservation and the birth-death processes are still modelled in continuous time and are not based on boundary crossings. Thus, the origination and extinction rates are measured as the expected number of origination and extinction events per lineage per Myr. A potential issue in fixing a priori the number of rate shifts is over-parameterization. We overcame this issue by assuming that the rates of origination and extinction are part of two families of parameters following a common prior distribution, with parameters estimated from the data using hyper-priors  55. We ran PyRate for 5 millions of MCMC generations on each of the 10 randomly replicated datasets (using the extract.
Acknowledgements We are thankful to  J. Alroy  and  C. Labandeira  for their contributions of palaeoentomological data to Paleobiology Database. We thank  D. Rabosky  for the help on the BAMM approach,  T. Stadler  on several discussions about TreePar inferences, and  D. Silvestro  for the help with PyRate. We thank  C. Labandeira ,  L. H. Liow , and  J. L. Abbate  who provided insightful comments and corrections on the study. This is contribution ISEM 2015-270 of the  Institut des Sciences de l'Evolution de Montpellier  ( UMR 5554 -CNRS ). This is Paleobiology Database contribution no. 247.
We study the dynamics of charged particles under the influence of a strong magnetic field by numerically solving the Vlasov-Poisson and guiding center models. By using appropriate data structures, we implement an efficient (from the memory access point of view) particlein-cell method which enables simulations with a large number of particles. We present numerical results for classical one-dimensional Landau damping and two-dimensional Kelvin-Helmholtz test cases. The implementation also relies on a standard hybrid MPI/OpenMP parallelization. Code performance is assessed by the observed speedup and attained memory bandwidth.
It is well-known (see  [2, 9] ) that when ε goes to zero, this Vlasov model may be approximated by a reduced model: the guiding center equation. However, when solving the Vlasov equation, the small parameter induces fast time oscillations in the solution, thus making classical numerical schemes very expensive. In this context, the aim of this work is twofold. Firstly, we want to compute the numerical solution of a four-dimensional Vlasov-Poisson system and to illustrate a convergence result. Secondly, we aim at implementing classical numerical methods in a sufficiently efficient way that enables us to produce simulations executing in reasonable time. The first aim deals with verifying the results of the computations, i. e. ensuring that the code solves the mathematical model in question. To accomplish this we use known analytical approximations or known conserved quantities.
The second aim is related with code implementation features designed to reduce the computation time. In this regard we deal with issues like optimized data structures, streamlined memory access and parallelization. In addition, we notice that, with the further aim to improve the recent time scheme in  [8]  and to extend it to more general problems than the aforementioned multiscale model, we need to have at our disposal a fast code yielding the reference solution. In the following, we understand by reference solution of a model its numerical solution calculated with classical numerical schemes and small enough numerical parameters. Since a Vlasov model has the structure of a transport equation in phase space, most of the numerical methods are based on the study of its characteristics. In this paper we use a standard Particle-In-Cell (PIC) method to solve the model (see  [1, 11] ).
This yields a very computationally demanding problem. To make the resulting simulations execute in an acceptable time, we choose standard methods of parallelization (using the well-known multiprocess and multithreading libraries MPI and OpenMP) and less widely employed methods of code design using specialized data structures to optimize memory access patterns. See the approach developed in  [3]  and  [4]. We have thus performed simulations able to process, at their best, 265 million particles per second in average, on one node with 16 cores. The implementation was done in the library SeLaLib 1. For verification of the code we have performed simulations of the wellknown Landau damping problem. Additionally, we simulated the Kelvin-Helmholtz instability test case. Finally we have compared the numerical solution of the multiscale four-dimensional Vlasov-Poisson system against the one for the guiding center model: we show the convergence result and assess it in quantitative and qualitative ways (see Section 2.
PIC implementation and simulations The multiscale features of the model above require a large number of particles and small time steps in order to resolve the fine structures in phase space, which makes this an expensive computation. In order to make simulations run in reasonable times, code optimization and parallelization are needed. We test the performance of the PIC implementation only on a standard Landau damping test case, briefly recalled in section 2. 1. Speedup due to parallelization and access to memory curves of the code are given in section 2. 2. Finally, in section 2. 3, we perform four-dimensional simulations and show results that illustrate the convergence result of the Vlasov-Poisson equation  (1)  to the guiding center model  (2). All the simulations in this paper were done at the computing center of the Université de Strasbourg (Mésocentre), on Intel(R) Xeon(R) E5-2670 @ 2.