dataesr/scientific-paragraphs-categorization huggingface dataset:
This paper presents a simple and inexpensive docking method utilizing an on-board camera, infrared (IR) sensors and passive base stations. The method benefits from two key concepts: The first is image processing using a camera module for decoding QR codes and defining a four point square. This allows the robot to determine its position relative to the dock. The second concept is the use of infrared sensors to avoid obstacles and perform alignment with the dock. We show that this is wining combination that allows efficient docking. The finality of such an approach is to integrate these robots into the FIT IoT Lab 1  experimental testbed which allows any experimenter to book wireless resources such as wireless sensor remotely and to test their own code. Wifibots holding wireless sensors will be integrated as additional reservable resources of the platform to enlarge the set of possible experimentations with mobile entities.
Actually, there are two QR codes, allowing two dock slots per 80cm bar (see figure  2 ). The QR code is 28 cm wide and high, to be visible from a distance of 4m. In order to be visible from 4 meters distance, the QR codes will be 28cm. edge side length. There are a number of existing libraries for reading data from QR codes. We use the ZBar  [25]  for reading the QR codes, which has been used for similar purposes  [19]  and seems to be highly reliable under normal lighting conditions, and is easy to implement. The library is capable of finding and decoding multiple QR codes in a single image. For each QR code, it returns a set of four points (XY pixel coordinates) representing each corner of the QR code square. This information is then processed to obtain the relative position of the robot in relation with the dock according to the optical distortion of the QR code (Fig:  3 ).
NaS overview Because the accuracy of MinION® reads is not high (more than 30% of errors), we developed the NaS workflow to overcome the limitation of existing assemblers. The ability to successfully align Illumina reads on MinION®   This plot shows the alignment identity and the alignment size of the MinION® 1D (red circles) and 2D (green circles) reads as well as NaS reads (blue circles). MinION® and NaS reads were aligned respectively using LAST  [20]  and BWA mem  [25]  softwares. templates is strongly reduced and as a result we observed that existing methods like proovread  [13]  are not performing well with this new type of data (see Methods). Instead of using Illumina short reads to correct MinION® reads, we propose a method that uses the MinION® read as a template to recruit Illumina reads and, by performing a local assembly, build a high-quality synthetic read (Figure  2 ).
The whole NaS workflow is easy to parallelize, as the processing is the same for each input MinION® template. We used the shell tool, GNU parallel  [15] , for executing jobs. The elapsed time was between 30 min and 3 h for each dataset. For instance, the NaS reads from the 2D reads of the MinION® run2 were produced on a 16-core computer in 34 min. The average CPU time is less than 1 min per NaS read on a single core computer.
Impact of Illumina coverage and read length on NaS reads By sampling randomly the initial Illumina dataset (obtained from a 530-to 630-bp fragment library of the bacterium Acinetobacter baylyi ADP1 genomic DNA), we generated subsets from 10 × to 150 × genome coverage. Furthermore, we trimmed reads to obtain subsets with the corresponding read length: 100 bp, 150 bp, 200 bp, 250 bp and 300 bp. Interestingly, we found that NaS reads were of high quality, even with a coverage as low as 20 × (Additional 1: Figure  S2 ). Additional coverage may be used to generate longer NaS reads, but the method reached a plateau rapidly. For instance, the average size increase of only 4% between 30 × and 150 × when considering 200 bp Illumina reads. Likewise, the error rate was not sensitive to the coverage, and remained above 99.
Acinetobacter baylyi ADP1 dataset To validate our approach, we used our five MinION® runs from the bacterium Acinetobacter baylyi ADP1. NaS was launched using several subsets of Illumina reads and those corrected using 50 × of coverage with 250 bp reads were kept (corresponding to the subset which maximizes the coverage of the reference sequence). We applied the NaS approach using the previously described 66,492 MinION® reads and it generated 11,275 NaS reads (with a cumulative size of 82. 8 Mb, a N50 of 11,292 bp, and a longest read size of 59,863 bp, Table  2 ). Only 17% of the initial MinION® templates lead to a NaS reads, this low success rate is directly correlated with the error rate, indeed this is in agreement with the number of reads we were able to map onto the reference genome (25.
This can be explained by the lower error rate in the 2D reads (25. 5% for 2D vs 43. 4% for 1D, Table  2 ) that makes seed-read capturing easier. To inspect the quality of the NaS reads, they were aligned to the reference genome using BWA mem aligner  [16]. The 11,275 NaS reads cover 99. 96% of the reference genome and align with an average identity of 99. 99%. Ninety-seven percent of the reads align completely with the reference with no error and 99. 2% align when allowing one error. Furthermore, the four NaS reads longer than 50 kb aligned perfectly with no error on the reference genome. Two different regions of the reference genome are not covered, implying two gaps of the following size: 1076 bp and 408 bp. We observed that these two genomic regions contain repeated elements. When comparing the coverage distribution of NaS and MinION® reads, we observed that most of the genome is covered accordingly by the two dataset (Additional 1: Figure  S4 ).
Nanopore 8 kb and 20 kb libraries preparation Acinetobacter baylyi genomic DNA was sheared using G_Tubes (Covaris) according to the following conditions: i) for 8 kb library: 5 μg of genomic DNA in 150 μl Elution Buffer (EB, Tris HCl 10 mM; Qiagen, Hilden, Germany) was centrifuged in a G-Tube at 3. 3 × g for 1 min before inverting the tube and centrifuging again for 1 min; ii) for 20 kb library: 10 μg of genomic DNA in Elution Buffer was loaded in six G-Tubes (100 μl aliquots each) and centrifuged at 1. 1 × g for 1 min before inverting the tubes and centrifuging again for 1 min. Eight kb fragmentations were evaluated using a DNA12000 LabChip kit on an Agilent Bioanalyzer and quantified using a Qubit Fluorometer (Life Technologies, Carlsbad, CA, USA). Then, one microgram of 8 kb sheared DNA was end repaired in 100-μL reactions using the NEBNext End-Repair module (New England Biolabs) according to the manufacturer's instructions.
MinION® sequencing and reads filtering Read event data generated by MinKNOW™ control software (version 0. 45. 3. 9) were base-called using the software Metrichor™ (version 0. 17). The data generated (pores metrics, sequencing, and base-calling data) by MinION® software are stored and organized using a Hierarchical Data Format (HDF5). Three types of reads were obtained: template, complement, and two-directions (2D). Template and complement reads correspond to sequencing of the two DNA strands. Metrichor™ combines template and complement reads to produce a consensus (2D)  [9]. FASTA reads were extracted from MinION® HDF5 files using poretools  [19]. To assess the quality of the MinION® reads, we aligned reads against the A. baylyi ADP1 reference genome using the LAST aligner (version 460)  [20].
Illumina reads processing and quality filtering After Illumina sequencing, an in-house quality control process was applied to reads that passed the Illumina quality filters. The first step discards low-quality nucleotides (Q < 20) from both ends of the reads. Next, Illumina sequencing adapters and primers sequences were removed from the reads. Then, reads shorter than 30 nucleotides after trimming were discarded. These trimming and removal steps were achieved using inhouse-designed software based on the FastX package  [21]. The last step identifies and discards read pairs corresponding to the PhiX genome, using SOAP  [22]  and the PhiX reference sequence (NC_001422. 1). This processing results in high-quality data and improvement of subsequent analyses.
Test of correction-based approach We applied proovread  [13] , a recently available correction tool, to our MinION® reads. We limited our benchmark to the 2D reads of run2, with 100 × of Illumina PE reads. The results showed that correction-based methods do not function satisfactorily with this new type of data. Indeed, proovread produced a corrected version for 344 of the 543 MinION® input reads. However, when mapping these corrected reads to the reference genome using BWA mem  [16]  with the "-x pacbio" parameter, we were able to aligned only 63. 35% of the 344 corrected reads, and we computed an average identity percent of 71. 6%, which is not different from that obtained when aligning non-corrected reads (67. 2%) using the same software and parameters (Additional file 1: Table  S2 ).
Alignment programs comparison The seed-reads capturing represents a critical step, indeed for a given MinION® template we need at least one seed-read to initiate the NaS workflow. A high sensitivity is needed however the specificity is quite important too. Indeed if too many reads are recruited, the micro-assembly step becomes a whole genome assembly. We compared BWA  [16] , BWA mem  [25] , Bowtie2  [26]  and BLAT  [23]  alignment programs performance using 1D and 2D MinION® reads of run2 (Table  1 ). To overcome the high error rate of MinION® reads, we parametrized each program with a lower seed than the one used by default (Additional file 1: Table  S3 ). In these conditions, we found that BLAT was more sensitive and more computationally efficient than others aligners (Additional file 1: Table  S3 ).
The N50 and maximal length of the synthetic reads produced by each program were highly similar, but the quality of synthetic reads is higher with Newbler (Additional file 1: Table  S4 ). Moreover, we showed that Newbler contigs are slightly longer than their CA counterpart (Additional 1: Figure  S8 ). This short elongation is certainly due to the -urt option of Newbler (that avoid contig breaks in low-covered regions as, in this special case, both ends of the synthetic read). One other important aspect is the computational time, as we need to perform numerous micro-assemblies. We observed on our dataset that Newbler is in average 4-5 times faster than MIRA and 18-19 times faster than CA (Additional file 1: Table  S4 ). Finally, Newbler offers a simplify access to the contig graph, through the 454ContigGraph output file which is well-documented.
Acknowledgements This work was supported by the  Genoscope , the  Commissariat à l'Energie Atomique et aux Energies Alternatives (CEA) , and  France Génomique  ( ANR-10-INBS-09-08 ). The authors are grateful to  Oxford Nanopore Technology Ltd  for providing early access to the  MinION® device through the MinION® Access Programme (MAP). The authors acknowledge  Jean Weissenbach  and  Claude Scarpelli  for continuous support.
ABS has a formal semantics  [15]  and is used to model systems based on asynchronously communicating concurrent objects distributed over deployment components that can be seen as containers offering to objects the resources they need to run. The considered use case is given by the Fredhopper Cloud Services, which offer search and targeting facilities on a large product database to e-Commerce companies. Depending on the specific profile of an e-Commerce company Fredhopper has to decide the most appropriate customized deployment of the service. Currently, such decisions are taken manually by an operation team which decides customized, hopefully optimal, service configurations taking into account the tension among several aspects like the level of replications of critical parts of the service to ensure high availability, the costs of the virtual computing resources to acquire, and the necessity of some clients to keep their data private.
Summarizing, the first main contributions of the paper is the extension of ABS with the possibility to annotate class definitions with deployment information. Several deployment scenarios can be considered and, for each of them, it is possible to indicate specific functional and resource-dependent requirements. The second contribution is the definition of DDLang, a domain specific language allowing for the high-level declarative specification of the desired deployment. Moreover, we also provide an implementation of Model-Driven Deployment Engine (MODDE), a tool that given the set of available ABS classes (annotated with their deployment information) and the declarative specification in DDLang of the desired system, computes an ABS main program that creates the needed deploy-ment components and deploys on them the required objects.
The deployment components are taken from a description of the available computing resources (each one with an associated cost) given to MODDE as an additional input. It is worth to mention that in the implementation of MODDE we have taken advantage of two already available tools: the configuration engine Zephyrus  [4]  to support the computation of the optimal allocation of objects over deployment components, and the Metis planner  [17]  for the generation of the sequence of actions to be executed by the generated ABS main program. We have decided to leverage on already available tools that are not tailored to a specific modeling language, to realize an easily portable and adaptable framework for model-driven deployment. In fact, if an alternative modeling language is considered instead of ABS, it will be possible to adapt our approach simply by extending that modeling language with the deployment annotations, and by modifying only those (limited) parts of MODDE that depend on ABS.
Our declarative deployment language DDLang can be indeed applied to any other object-oriented modeling language as it has no particular dependencies on the specific aspects of ABS. The paper structured as follows. In Section 2 we present the extension to the ABS modeling language for the definition of models extended with deployment information. The declarative deployment language DDLang is presented in Section 3 while Section 4 discusses the implementation of MODDE. Section 5 discuss the test of our approach on the Fredhopper Cloud Services use case. Before some concluding presented in Section 7, Section 6 discuss the related literature.
User: the user has to enter the parameter name. This happens when only the user knows how to specify the parameter value. In this case, the automatic deployer leaves the parameter unspecified and the user will have to manually instantiate it. 2. Default( X ): the parameter must be set to the default value X. 3. Req: the parameter is required to be defined by MODDE: here, MODDE is responsible to first create an appropriate object and then pass it as parameter when obj is instantiated. 4. List(X): the parameter requires a list of at least X objects (where X is a natural number) that should be defined by MODDE. Similar to what happens with the Req parameter, X objects should be created and their list passed as parameter when obj is instantiated. Let us now consider the annotated ABS code of Listing 1.
5  DDLang When a system deployment is automatically computed, a user expects to reach specific goals and could have some desiderata. For instance, in the considered Fredhopper Cloud Services use case, the goal is to deploy a given number of Query Services and a Platform Service, possibly located on different machines (e. g. , to improve fault tolerance). All these goals and desiderata can be expressed in the Declarative Deployment Language (DDLang): a language for stating the constraints that the final configuration should satisfy. As shown in Table  2  that reports the DDLang grammar defined using the ANTLR tool, 6  a constraint is a specification spec of basic constraints expr comparisonOP expr (Line 2) combined using the usual logical connectives. These basic constraints specify how many elements (e.
For instance, in the considered case study, we require that an object of class QueryServiceImpl must be always co-installed together with an object of class DeploymentServiceImpl. This can be achieved as follows. 4 Deployment Engine MODDE is the tool that we have implemented to generate an ABS main program realizing a deployment of objects, obtained as instantiations from a set of annotated classes, which satisfies constraints expressed in DDLang. The tool relies on scripts that integrate Zephyrus and Metis. Zephyrus  [4]  is a tool that generates, starting from a description of the target application, a fully detailed architecture indicating which components are needed and how to distributed them. Metis  [17]  is a planner that generates a deployment plan to bring the current state of a deployed application to the new, desired one.
These tools are used following the workflow depicted in Figure  1. More precisely, MODDE takes three distinct inputs: the ABS program annotated as discussed in Section 2, the user desiderata formalized as constraints in the language DDLang defined in Section 3, and the list of available deployment components expressed as described below. INTERFACE The list of components is given as a JSON object having two properties: DC description, which describes the different types of deployment components, and DC availability, that specifies the number of available instances for each of these types. A deployment component type is identified by a name, the list of the resources it provides and a cost that the user has to pay in order to use it. For instance the following JSON object defines the possibility of using 5 c3.
large and 3 c3. xlarge Amazon AWS instances as deployment components. { " DC_description " : [ { " name " : " c3. large " , " cost " : 1 0 5 , " provide_resources " : { " CPU " : 2 , " Memory " : 3 7 5 } } , { " name " : " c3. xlarge " , " cost " : 2 1 0 " provide_resources " : { " CPU " : 4 , " Memory " : 7 5 0 } } ] , " DC_availability " : { " c3. large " : 5 , " c3. xlarge " : 3 } } The c3. large AWS machine is identified as a deployment component type that provides 2 CPUs and 3. 75 GB of RAM. When used, this type of deployment component cost 105 credits per hour. When MODDE is executed, the first step builds an abstract syntax tree of the annotated ABS program, retrieving all the annotations and the class signatures. This step (step 1 in Figure  1 ) is performed by a Java program that outputs a JSON file.
In the second step, the output of the annotation extraction is processed to generate the universe file of components required by Zephyrus  [4]. Zephyrus requires as input a representation of the components to deploy following the Aeolus model specification  [5]. 7 Moreover, to compute the optimal allocation of these components, Zephyrus requires two additional inputs: a description of all locations where components can be installed and the requirements imposed on the final configuration. These two additional inputs are computed in steps 3 and 4 (see Figure  1 ) from the description of the deployment components and the user desiderata. In particular, in step 3, every deployment component available is translated as a Zephyrus location, associated with the resource capacities it provides. In step 4, the constraints in the DDLang input are translated into the specification request language of Zephyrus.
To get this information, in step 6, we launch Metis  [17]. This planner takes in input the final configuration produced by Zephyrus and the universe file obtained at step 2 and computes the actions to be performed in order to reach the final configuration. After the generation of the Metis plan we have all the information to generate the ABS main program. The deployment components to be used are created as computed by Zephyrus. Then, following the order of the state changes computed by Metis, the new objects are created and located in the corresponding deployment components. In case an object requires other objects as initialization parameters, the required objects are passed based on the bindings among the components as defined by Zephyrus. MODDE is written in Python (∼1k lines of code) with the exception of the annotation extractor which is written for convenience in Java (∼500 lines of code).
We defined the capacity of each resource for several AWS instance types in the locations file. 8 The price used in the cost attribute of each AWS instance type concerns on-demand instances in the US East region running Linux. 9 e created several deployment scenarios based on the varying requirements of different customers. For instance, web shops with a large number of visitors require more Query Service instances than smaller web shops. In general, this requires a scalable, and fault tolerant system with a proportionate number of Query Service instances to handle computational tasks and network traffic and return the query results sufficiently quickly. The deployment configuration also has to satisfy certain requirements. For instance, for security reasons, services that operate on sensitive customer data should not be deployed on machines shared by multiple customers.
In this context, one prominent work is represented by the TOSCA (Topology and Orchestration Specification for Cloud Applications) standard  [19] , promoted by the OASIS consortium for open standards. TOSCA proposes an XML-like rich language (or YAML) to describe an application. Deployment plans are usually specified using the BPMN or BPEL notations, i. e. , workflow languages defined in the context of business process modeling. TOSCA specifications, however, still lack proper tooling and technology support for largescale industry cases. Following similar philosophies, but focusing more on cloud aspects, are Terraform  [14] , Apache Brooklyn [2], and other tools supporting the Cloud Application Management for Platforms protocol  [18]. To the best of our knowledge there are no works that deal with deployment at the modeling level, providing a tool that automatically computes optimal target configurations from a declarative specification.
Conclusions In this paper we have proposed a new way to tackle and unify the modeling of a distributed system together with its deployment. We followed a model-driven approach that allows the user to specify the deployment aspects in a declarative way, without requiring in-depth knowledge of the system to be deployed. We focused and used our approach on the ABS modeling language, but we are not restricted to it: other languages such as SmartFrog  [12]  that have primitives to handle the deployment aspects can be used as well, provided that annotations related to the execution costs of the system are used. We tested our approach on an industrial case study from the e-Commerce company Fredhopper. The results are encouraging since the deployment solutions resemble those (manually) devised by the operations team proving their optimality.
Note that the exact population size N does not need to be known to estimate the model parameters as long as the number of cases is small compared to the total population size  [20]. To estimate the parameters of the model, we adapted the initialisation of S and I with the reported data of  [19]  by fitting the actual data of confirmed cases in Liberia. The data that we are studying is the number of individuals with confirmed infection between July 14 and October 12, 2014. The result of fitting is shown in Figure  2. The comparison between the curve of infected obtained by our simulation and the reported data of confirmed cases by WHO shows that the mathematical model (  4 ) fits well the real data by using β = 0. 000318 as the rate of infection and µ = 0. 0175 as the rate of recovery. The initial numbers of susceptible, infected, and recovered groups, are given by S(0) = 460, I(0) = 12, and R(0) = 0, respectively.