dataesr/scientific-paragraphs-categorization huggingface dataset:
FUNDING Genome  Canada Large Scaled Applied Research Grant  [ 174CDE ] (to WWW lab);  Canadian Institute of Health Research (CIHR)   Operating Grant  [ MOP-119586 ] (to WWW lab);  Child and Family Research Institute (CFRI)  (to A. M. );  British Columbia Children's Hospital Foundation  (to A. M. );  Postgraduate Scholarships-Doctoral Program  from  Natural Sciences and Engineering Research of Canada (NSERC) ;  University of British Columbia (UBC)   Four Year Doctoral Fellowship  (to C. Y. C. );  Genome Science And Technology program   NSERC-CREATE scholarship ;  University of Zurich ;  CFRI Jan M. Friedman Graduate Studentship  (to J. L. ); China Scholarship Council  (to W. S. );  UBC Teaching and Learning Enhancement fund  (to W. S. , A. W. Z. );  CIHR Graduate Scholarship [CGSD-GSM  to C.
S. ];  NSERC   Discovery Grant  [ RGPIN 355532-10  to C. S. , R. W. H. ];  UBC MD-PhD program  (to A. W. Z. );  ANR  [Blanc-SVSE2-2011-Charmful to F. P. ];  French MRT PhD Fellowship  (to G. D. );  EU   FP7 large scale  integrated project  ZF HEALTH [HEALTH-F4-2010-242048  to G. T. ];  Medical Research Council UK  (to B. L. ). Funding for open access charge:  Genome Canada Large Scaled Applied Research Grant  [ 174CDE ].
2). Eq. 12 can be written as specied by Buckingham's theorem so that an expression of the MRT is obtained from the dened dimensionless numbers as given in Eq. 13. The variables in Eq. 13 are expressed in the International System of units, therefore the mean residence time obtained is in seconds. The exponents α, β,. , ζ and the constant k are to be determined with the use of experimental data. The length-to-diameter ratio has not been varied in our experimental matrix, therefore the exponent η was xed to the value of 1. 1 which has been determined by Chatterjee et al. [3]  when varying the dimensionless group L D from 3. 3 to 16. To determine the other exponents and the constant k, a MatLab script was written. More specically the program sought to determine the parameters by minimizing the sum of square error between the experimental and predicted values of the MRT.
The comparisons of predicted and experimental values of the MRT are given in Fig. 7. Results show good agreements between the experimental and calculated MRT regardless of the set of parameters used. However, it should be noted that results while using the sand-tted parameters give the lowest value of the performance criterion followed by the rice-tted parameters. Other tests were carried out with data from rotary kilns equipped with dams of dierent height at their outlet end. These rotary kilns were those used by Sai et al. [18]  and Chatterjee et al. [2]  as previously mentioned. Fig. 8  shows the results of the comparison of the experimental and predicted values of the MRT. Looking at the results obtained with the data from Sai et al. [18] , the correlation gives good predictive performance when using either the rice-or sand & rice-tted parameters, but revealed an even better agreement with the experimental MRT with the sand-tted parameters, which gives a signicant low criterion compared with the other results.
g. Singularity  [9] , or in language libraries as in e. g. Java  [24]  and Scala  [13]. When combining the actor model with an object-oriented programming model, two key questions to consider are the exact semantics of message passing, and its efficient implementation, in particular on multiprocessor architectures with shared physical memory. To be efficient, an implementation of message passing on a shared memory architecture ought to use data transfer by reference, where the only data exchanged is a pointer to the part of the memory that contains the message. However, with data transfer by reference, enforcing the share-nothing semantics of actors becomes problematic: once an arbitrary memory reference is exchanged between sender and receiver, how do you ensure the sender can no longer access the referenced data ? Usual responses to this question, typically involve restricting the shape of messages, and controlling references (usually through a reference uniqueness scheme  [19] ) by various means, including runtime support, type systems and other static analyses, as in Singularity  [9] , Kilim  [24] , Scala actors  [14] , and SOTER  [21].
We formally specify the Siaam model, building on the Jinja specification of a Java-like sequential language  [18]. We formally prove, using the Coq proof assistant, the strong isolation property of the Siaam model. We describe our implementation of the Siaam model as a modified Jikes RVM  [16]. We present a novel static analysis, based on a combination of points-to, alias and liveness analyses, which is used both for improving the run-time performance of Siaam programs, and for providing useful debugging support for programmers. Finally, we evaluate the performance of our implementation and of our static analysis. Outline. The paper is organized as follows. Section 2 presents the Siaam machine and its formal specification. Section 3 presents the formal proof of its isolation property. Section 4 describes the implementation of the Siaam machine.
This scheme prevents pathological situations where an object passed in a message m may be sent in another message m by the receiver actor without the latter having dequeued (and hence actually received) message m. Since Siaam does not modify object references in any way, the sender actor can still have references to objects that have been sent, but any attempt from this sender actor to access them will raise an exception. Siaam: model and formal specification. The formal specification of the Siaam model defines an operational semantics for the Siaam language, in the form of a reduction semantics. The Siaam language is a Java-like language, for its sequential part, extended with special classes with native methods corresponding to operations of the actor model, e. g. sending and receiving messages.
The semantics is organized in two layers, the single-actor semantics and the global semantics. The single-actor semantics deals with evolutions of individual actors, and reduces actor-local state. The global semantics maintains a global state not directly accessible from the single-actor semantics. In particular, the effect of reading or updating object fields by actors belongs to the single-actor semantics, but whether it is allowed is controlled by the global semantics. Communications are handled by the global semantics. The single actor semantics extends the Jinja formal specification in HOL of the reduction semantics of a (purely sequential) Java-like language  [18]   5. Jinja gives a reduction semantics for its Java-like language via judgments of the form P e, (lv, h) → e , (lv , h ) , which means that in presence of program P (a list of class declarations), expression e with a set of local variables lv and a heap h reduces to expression e with local variables lv and heap h.
Actor actions also include a special silent action, that corresponds to single-actor reductions (including exception handling) that require no access to the global state. Non silent actor actions are triggered by object creation, object field access, and native calls, i. e. method calls on the special actor and mailbox classes. The global semantics is defined by the rule Global in Figure  2. The judgment, written P s → s , means in presence of program P , global state s reduces to global state s. The global state (xs, ws, ms, h) of a Siaam program execution comprises four components: the actor table xs, an ownership relation ws, the mailbox table ms, and a shared heap h. The projection functions acs, ows, mbs, shp return respectively the actor table, the ownerships relation, the mailbox table, and the shared heap component of the global state.
Siaam: Implementation We have implemented the Siaam abstract machine as a modified Jikes RVM  [16]. Specifically, we extended the Jikes RVM bytecode and added a set of core primitives supporting the ownership machinery, which are used to build trusted APIs implementing particular programming models. The Siaam programming model is available as a trusted API that implements the formal specification presented in Section 2. On top of the Siaam programming model, we implemented the ActorFoundry API as described in  [17] , which we used for some of our evaluation. Finally we implemented a trusted event-based actor programming model on top of the core primitives, which can dispatch thousand of lightweight actors over pools of threads, and enables to build high-level APIs similar to Kilim with Siaam's ownership-based isolation.
In the Jikes RVM, objects are represented in memory by a sequence of bytes organized into a leading header section and the trailing scalar object's fields or array's length and elements. We extended the object header with two reference-sized words, OWNER and LINK. The OWNER word stores a reference to the object owner, whereas the LINK word is introduced to optimize the performance of object graph traversal operations. Contexts. Since the JikesRVM is fully written in Java, threads seamlessly execute application bytecode and the virtual machine internal bytecode. We have introduced a notion of execution context in the VM to avoid subjecting VM bytecode to the owner-checking mechanisms. A method in the application context is instrumented with all the isolation mechanisms whereas methods in the VM context are not.
The two phases of our analysis are independent, it is possible to disable one and replace it with a very conservative approximation. Disabling one phase allows faster computation but less accurate results. We implemented the safe references analysis as a code optimization pass in the Siaam virtual machine, so that intra-procedural owner-check eliminations are performed without the need of a costly whole-program analysis. rithm for withdraw that chains objects that are part of a message through their LINK word. The list thus obtained is maintained as long as the message exists so that the acquire operation can efficiently traverse the objects of the message. The algorithm leverages specialized techniques, initially introduced in the Jikes RVM to optimize the reference scanning phase during garbage collection  [10] , to efficiently enumerate the reference offsets for a given base object.
Each of these analyses exists in many different variants offering various tradeoffs of results accuracy and algorithmic complexity, but regardless of the implementation, they provide a rather standard querying interface. Our analysis is implemented as a framework that can make use of different instances of these analyses. Implementations. The intra-procedural safe reference analysis which is part of the Siaam analysis has been included in the Jikes RVM optimizing compiler. Despite its relative simplicity and its very conservative assumptions, it efficiently eliminates about half of the owner-check barriers introduced by application bytecode and the standard library for the benchmarks we have tested (see  Section 6). The safe reference analysis and the safe object analyses from the Siaam analysis have been implemented in their inter-procedural versions as an offline tool written in Java.
The tool interfaces with the Soot analysis framework  [23] , that provides the program representation, the call graph, the interprocedural pointer analysis, the must-alias analysis and the liveness analysis we use. Programming assistant. The Siaam programming model is quite simple, requiring no programmer annotation, and placing no constraint on messages. However, it may generate hard to understand runtime exceptions due to failed owner-checks. The Siaam analysis is therefore used as the basis of a programming assistant that helps application developers understand why a given program statement is potentially unsafe and may throw an owernship exception at runtime. The Siaam analysis guarantees that there will be no false negative, but to limit the amount of false positives it is necessary to use a combination of the most accurate standard (points-to, must-alias and liveness) analyses.
Siaam Implementation. We present first an evaluation of the overall performance of our Siaam implementation based on the DaCapo benchmark suite  [3] , representative of various real industrial workloads. These applications use regular Java. The bytecode is instrumented with Siaam's owner-checks and all threads share the same owner. With this benchmark we measure the overhead of the dynamic ownership machinery, encompassing the object owner initialization and the owner-checking barriers, plus the allocation and collection costs linked to the object header modifications. We benchmarked five configurations. no siaam is the reference Jikes RVM without modifications. opt designates the modified Jikes RVM with JIT ownerchecks elimination. noopt designates the modified Jikes RVM without JIT ownerchecks elimination.
sopt is the same as opt but the application bytecode has safety annotations issued by the offline Siaam static analysis tool. Finally soptnc is the same as sopt without owner-check barriers for the standard library bytecode. We executed the 2010-MR2 version of the DaCapo benchamrks, with two workloads, the default and the large. Table  1  shows the results for the Dacapo 2010-MR2 runs. The results were obtained using a machine equipped with an Intel Xeon W3520 2. 67Ghz processor. The execution time results are normalized with respect to the no-siaam configuration for each program of the suite: lower is better. The geometric mean summarizes the typical overhead for each configuration. The opt figures in Table  1  show that the modified virtual machine including JIT barrier elimination has an overhead of about 30% compared to the not-isolated reference.
The JIT elimination improves the performances by about 20% compared to the noopt configuration. When the bytecode is annotated by the whole-program static analysis the performance is 10% to 20% better than with the runtime-only optimization. However, the DaCapo benchmarks use the Java reflection API to load classes and invoke methods, meaning our static analysis was not able to process all the bytecode with the best precision. We can expect better results with other programs for which the call graph can be entirely built with precision. Moreover we used for the benchmarks a context-insensitive, flow-insensitive pointer analysis, meaning the Siaam analysis could be even more accurate with sensitive standard analyses. Finally the standard library bytecode is not annotated by our tool, it is only treated by the JIT elimination optimization.
We compare the efficiency of the Siaam whole-program analysis to the SOTER algorithm, which is closest to ours. Table  2  contains the results that we obtained for the benchmarks reported in  [21] , that use Actor-Foundry programs. For each analyzed application we give the total number of owner-checking barriers and the total number of message passing sites in the bytecode. The columns "Ideal safe" show the expected number of safe sites for each criteria. The column " Siaam safe" gives the result obtained with the Siaam analysis. The analysis execution time is given in the third main colum. The last column compares the result ratio to ideal for both SOTER and Siaam. Our analysis outperforms SOTER significantly. SOTER relies on an inter-procedural live-analysis and a points-to analysis to infer message passing sites where a byreference semantics can applies safely.
ClouDiV put the advantages of cloud computing available to forward data packets between VANET nodes in an efficient way, which improve safety and non-safety message transmissions according to various dissemination metrics. Also, digital requests of car drivers and passengers could be satisfied by the various cloud computing services such as processing, storage, and bandwidth. Cloud computing is a new computing model consisted of a pool of physical compute resources such as processor, memory, and network bandwidth, potentially distributed physically across big servers known as data centers. The data centers can be organized on demand into a dynamic logical entity that can grow or shrink over time, to satisfy computational requests of end users including performance, reliability, cost, and security, usually through the Internet against a leased resource fee  [3].
We note that the various vehicular devices such as onboard computers, passenger smartphones and, personal digital assistants could be considered as mobile data centers helping to provide more cloud services  [4]. So that the transmission receives benefits from the Cloud, ClouDiV proposes that all available cloud resources namely, bandwidth of different end users (i. e. car drivers, passengers, traffic authorities, etc. ) contribute to disseminate messages between VANET nodes. Mainly, ClouDiV is considered as a geographic protocol that disseminates messages through an adaptive connectivity process based on data centers of the cloud. Moreover, this protocol uses a particular kind of packet transmission known as stochastic broadcasting  [5]  when it launches the route discovery phase, which is in hybrid mode (proactive and reactive route discovery) as described below.
Cloud Computing for VANET: Definition and Architecture As introduced in  [9] , Cloud Computing for VANET (VANET-Cloud model) is defined as a new cloud computing infrastructure, consisted of an important number of computing nodes including stationary data centers, as well as a set of mobile computing devices installed onboard of vehicles such as onboard computers, passenger PDAs, onboard computers of traffic authorities, and so on. VANET-Cloud takes advantage of cloud computing resources and services to better serve VANET users (i. e. drivers and passengers) in terms of providing digital resources such as processing, storage, bandwidth, with very low cost. As shown in Fig. 1 , the VANET-Cloud model is formed by two sub-models: the permanent (stationary) cloud sub-model consisting of data centers, and the temporary (mobile) cloud sub-model that is composed of vehicles computing resources.
This scheme proposed that each vehicle predicts its future locations by generating way point messages, which describe the trajectory of the vehicle's movement. These way point messages are collected by a decision module established on a cloud infrastructure that is responsible for making routing decisions for inter-vehicle communication. More specifically, this cloud-based module selects paths in terms of message delivery ratio by respecting the constraints of end-to-end delay and communication cost. We can suggest that further routing improvements could be brought if VehiCloud takes advantages of conventional cloud capabilities. In  [11] , another issue has been addressed and solved by making use of the cloud computing infrastructure which is the seamless access to the Internet. To achieve this, a cloud-supported gateway model, named Gateway-as-a-Service (GaaS) was proposed to provide efficient gateway connectivity and to enhance the usage experience of Internet for vehicular networks.
Description of ClouDiV: Our Proposal ClouDiV is a message dissemination protocol proposed for vehicular networks, based on a cloud computing architecture. ClouDiV combines the use a fixed cloud computing infrastructure (i. e. data centers) and a flexible cloud structure based on onboard computers of vehicles. Therefore, the computing powers of both permanent and temporary vehicular cloud structures can be available in benefit of various consumers by offering much higher bandwidth compared to message dissemination schemes based on pure vehicular network infrastructures. In this proposal, we assume that the vehicular network is formed by different VANET nodes (i. e. vehicles and RSUs), as well as the various cloud servers (i. e. data centers) located in the traffic environment. ClouDiV is considered as a hybrid message dissemination protocol, where a proactive approach is suggested to be applied by each data center in order to discover fresh and updated routes toward each node in the network.
2a. : Each VANET node possesses its own routing table, which is consisted of a set of entries, each entry is dedicated to one destination (if requested) that can be a data center or a regular VANET node. More specifically, each entry contains the destination identifier and the identifier of next hop node toward the destination. The idea of saving the next hop instead of saving the entire route is to reduce the memory space of this routing table, since these nodes (onboard computers) possess limited computing resources. Also, each routing table entry includes the link delay and bandwidth information, a hop count field indicating the number of hops to reach the destination, which could be used to choose the shortest path if there is more than one path to the same destination. The routing table of node S is presented in Fig.
2b. This phase aims to ensure an update of routing tables using beacon packets, transmitted periodically. As a result, active links between each VANET node and each data center are updated, by refreshing different transmission parameters such as the available bandwidth and the measured end-to-end delay. Also, routing information between VANET nodes is also saved and updated in order to perform a conventional routing (i. e. without the help of the cloud computing infrastructure) in the case of lacking data centers. We note that a link is marked as invalid in a routing table if a node does not get information from the nodes neighbor for a specified amount of time. Thus, the other nodes are informed of this unavailable link using an error packet.
Significant Results and Discussion In order to measure the quality of message dissemination in a vehicular network, ClouDiV is evaluated following the traffic safety metrics: the average end-to-end delay, the Packet Delivery Ratio (PDR), and the Normalized Overhead Load (NOL). These metrics are explained in  [17]. We have compared the performance of our proposed with the Reliable Inter-VEhicular Routing (RIVER) protocol proposed for VANETs. Simulation results are depicted in Fig. 7 8 9. As shown in Fig. 7 , ClouDiV disseminates data packets with a decreased end-to-end delay. It is due to the time saved by the proactive routing process performed by the data center. In fact, the requested routes are still discovered by the data center and ready to be used, even before that, the source node desires to disseminate packets, this is the reason of reducing the delay, often caused by the discovery process launched after requesting a new path.
Conclusion and Perspectives In this study, we have proposed a new message dissemination protocol for vehicular ad-hoc networks based on cloud computing infrastructure, called Cloud computing-based message Dissemination protocol for VANET (ClouDiV). This protocol is considered as a hybrid protocol that applies on the one hand, a proactive approach in data centers in order to discover routes ready for use in a future message dissemination. On the other hand, a reactive routing is applied by the other nodes, only if these nodes desire disseminating messages. To evaluate the performance of ClouDiV, an extensive experimental study was conducted in terms of the average end-to-end delay, the packet delivery ratio and, the normalized overhead load. These experiments were performed under a cloud computing infrastructure and the obtained results were compared to RIVER protocol proposed for vehicular networks.