dataesr/scientific-paragraphs-categorization huggingface dataset:
It forwards the requests of the user to the machines that actually hold the data. • The ConfigServer mixin type abstracts the notion of a config server of a MongoDB cluster. A config server stores the metadata, including the state and organization of the data. It is also responsible to store authentication configuration information. • The Shard mixin type abstracts the notion of a shard in the MongoDB cluster. The shards are used to store the actual data of the database. Each shard holds a subset of the overall data. • The Cluster mixin type defines constraints for a MongoDB cluster: A cluster must contain at least one router (i. e. , OneOrMoreRouters), at least one shard (i. e. , OneOrMoreShards), and at least one config server (i. e. , OneOrMoreConfigServer). • The ConfigServerDependency mixin type abstracts the execution dependency between MongoDBComponents and a ConfigServer, to be able to ensure that the ConfigServer is started, before the other components get started.
This second use case addresses LAMP, which is an open source Web development platform that uses Linux as the operating system, Apache as the Web server, MySQL as the relational database management system and PHP, Perl or Python as the objectoriented scripting language. The LAMP Web application can be modeled with help of the following mixins: • The LAMP mixin type abstracts the notion of a LAMP application and depends on MoDMaCAO Application mixin. A LAMP application is accessible via only one ApacheServer as enforced by the OnlyOneApacheServer constraint. It is deployed using one or more Tomcat container (i. e. , OneOrMoreTomcats constraint). Moreover, the persistent data of a LAMP application are stored in only one MySQL database (i. e. , OnlyOneMySQL constraint). • The ApacheServer mixin type abstracts the notion of a LAMP Web server.
It inherits from the Component mixin of the MoD-MaCAO modeling framework. It defines OneOrMoreTomcatDependencies constraint enforcing that the ApacheServer instance cannot run if it is not linked to at least one Tomcat instance. • The Tomcat mixin type abstracts the notion of a LAMP application container. It inherits from MoDMaCAO Component mixin. Each Tomcat instance is executed if it is connected to only one MySQL instance (i. e. , OnlyOneMySQLDependency constraint). • The MySQL mixin type abstracts the notion of a LAMP MySQL database and also inherits from MoDMaCAO Component mixin. • The TomcatDependency mixin type abstracts a LAMP execution dependency by always connecting a Component instance to a Tomcat instance (TargetMustBeTomcat). • The MySQLDependency mixin type abstracts a LAMP execution dependency by always connecting a Component instance to a MySQL instance (TargetMustBeMySQL).
Apache Cassandra Apache Cassandra is an open-source distributed NoSQL database management system. It is designed to handle large amounts of data by offering support for clusters across multiple datacenters. To achieve scalability in Cassandra clusters, the architect adds new nodes to an existing cluster without having to disconnect it first. When a new node is added, the cloud architect has to enter the new node name in the seed component list and then the new node will be part of the Cassandra database architecture, called "ring". Also, unlike other sharded systems like Mon-goDB and other Master/Worker systems like Apache Spark (cf. Section 5. 1. 4), a single point of failure does not affect the whole cluster in Cassandra. Therefore, it is capable of offering continuous availability. To do so, it automatically distributes, replicates and maintains data across the nodes of a cluster.
We detail in the following each element of the Cassandra Model: • The Cluster mixin type abstracts the notion of a clustered Cassandra database. This mixin depends on MoDMaCAO modeling framework by inheriting from its Cluster mixin. It defines two constraints, i. e. , OneOrMoreNodes and OneOrMoreSeeds that enforce that a Cluster contains at least one Node and one Seed, respectively. • The Node mixin type abstracts the notion of a Cassandra component. All nodes play an identical role, they communicate with each other via a distributed, scalable protocol called "gossip". • The Seed mixin type inherits from the Node mixin. The seed node maintains all the nodes list in a cluster.
Apache Spark Apache Spark is an open-source cluster computing platform for big data processing. We define the following extension to be able to model Apache Spark clusters: • The ApacheSparkCluster mixin type abstracts the notion of a Spark application that runs as independent sets of processes on a cluster. The ApacheSparkCluster connects to several types of ApacheSparkComponent instances, i. e. , only one master (OnlyOneMaster) and at least one worker (OneOrMoreWorkers). • The ApacheSparkComponent mixin type abstracts the notion of a Spark component. Each Spark component has apache. spark. port and apache. spark. webui. port attributes representing the port to access the Spark console and the Spark Web interface, respectively. An ApacheSparkComponent instance may be either a Master or a Worker.
• The Master mixin type abstracts the notion of a managing component that has a pool of jobs and assigns them to workers. • The Worker mixin type represents any node that can execute a job, i. e. , run application code in the cluster. Each worker has an apache. spark. worker. cores attribute representing the number of cores in each worker. It also has an apache. spark. worker. memory attribute representing the worker memory in gibibyte (GiB). A Worker instance depends on on the execution of only one Master instance (OnlyOneMasterDependency). We also define WorkerCoresSmallerThanComputeCores and WorkerMemorySmallerThanComputeMemory constraints that enforce that the cores and the memory of each worker are smaller than those of its hosting virtual machine. • The MasterDependency mixin type abstracts a Spark execution dependency by always connecting a Worker instance to a Master instance (SourceMustBeWorker and TargetMustBeMaster).
Roboconf Secondly, we implemented a Roboconf-specific plugin  (Pham et al. , 2015) , which is responsible of managing the application lifecycle via its SoftwareInstanceManager concept. The latter extends the ConfigurationManagementTool interface of MoDMaCAO implementation framework. The SoftwareInstanceManager comprises three connectors for managing the Application instances, their Component instances and the ComponentLink instances, respectively. A Roboconf method deployAndStartAll(), which deploys an application and directly starts its components, is executed by only calling the deploy() method of MoDMaCAO. The start() method of MoDMaCAO is implicit and not implemented in Roboconf. A Mixin will start directly when it is deployed. The same behavior is applied to undeployAll() method of Roboconf which will implicitly stop() the defined Mixin.
In the same vein of this commercial graphical interface, several research projects are providing domain-specific modeling languages and frameworks that enable architects to describe and manage cloud platforms. Among these model-based solutions, we identify OCCIware  (Parpaillon et al. , 2015)   (Zalila et al. , 2017) , which our work is an extension of. OCCIware has been successfully applied for the management of resources from different domains, including the management of Docker containers  (Paraiso et al. , 2016) , and the management of mobile robots  (Merle et al. , 2017). COAPS  (Sellami et al. , 2013)  is a PaaS API for managing cloud applications. It extends the OCCI Core model, i. e. , the Resource and Link concepts, without extending the OCCI Platform extension. Moreover, COAPS complies to the previous, non-enhanced version of the OCCI standard, hence it lacks of the resource state management and the conformance verification provided by the OCCIware tool chain and MoDMaCAO.
SALOON  (Quinton et al. , 2016 ) is a model-driven multi-cloud configurator. It uses feature models to represent infrastructure and platform variability, as well as ontologies to describe the cloud applications requirements. SALOON targets four PaaS providers and the authors claim it can be extensible by adding now provider models that conform to the metamodel they define. However, this can be difficult and errorprone since this framework is not based on a standard, nor on some formal specification. TUNe  (Chebaro et al. , 2009 ) is a management system that is based on the Fractal component model for describing the software encapsulation and on two UML profiles, one for the deployment of legacy distributed applications and one for their reconfiguration using state diagrams. TUNe was applied for the administration of J2EE applications.
INTRODUCTION Practitioners frequently use numerical methods, such as the multigrid and finite-element methods, to solve problems in many domains, such as computer graphics or computational fluid dynamics. Such computations simulate physical processes by iteratively performing a computation on a mesh data graph, denoted G = (V , E). In this graph, vertices have positions in 3D space as well as other computation-specific physical quantities, and edges connect physically-nearby vertices. A common way (e. g. , used in Simit  [24] , a domain-specific language for physical simulations) to express the data-graph computation is via an update function which modifies the data at a given vertex v based on the data contained by its neighbors, denoted N (v). This update function is applied to all vertices over many time steps, until reaching a physical or numerical convergence.
Experimental setup We implemented Laika and the other schedulers with a similar level of performance engineering in Cilk and C++, compiled them with GCC 7. 3. 0 with with these switches: -fcilkplus -std=c++11 -O3 -Wall -m64 -march=native -mtune=native -pthread -ffast-math -fgcse-las. All tests were executed on an Amazon EC2 m5. 24xlarge cloud instance, a dual-socket system consisting of two 2. 5GHz Intel Xeon Platinum 8175 (Skylake) CPU chips with a total of 48 physical processor cores. While we were not able to disable hyperthreading on the system, we used the taskset command to prevent execution of experiment code on hyperthreads. We disabled transparent huge pages system-wide, as the associated kernel activity can introduce measurement errors. Amazon EC2 instances enable dynamic frequency scaling, and unfortunately do not allow this setting to be changed.
Our code is available online  [14]. We intentionally chose an Update function that is difficult to schedule efficiently, since it executes only 2. 22 instructions per byte of data. Such an update function exposes scheduler overheads; in the absence of good cache locality the computation will quickly become memory-bound on even a few cores  [32]. This update function also presents difficulty for in-place execution, as the doublebuffered execution requires only 1. 1-1. 5 times as many iterations compared to an in-place execution. For comparison, this iterations ratio can be as high as 8x for some multigrid method  [6]  computations. Our Update function performs a physical simulation named Mass-Spring-Dashpot  [18] , simulating a set of weights of unit mass (vertices) in 3D space, connected by springs (edges).
Scalability Figure  13  illustrates Laika's superior scalability compared to all other schedulers, even on Hilbert-reordered inputs. Laika continues to achieve linear speedup with as many as 48 cores, whereas BSP with Hilbert inputs is already straining to maintain linear speedup with only 24 cores. It is tempting to extrapolate that Laika would continue to scale well at least in a weak-scaling regime  [15] , while BSP has nearly saturated memory and cross-socket communication bandwidth and will have trouble scaling much further. Figure  13  hints that Chroma is already in this situation: even though Hilbert reordering improves its per-iteration wall-clock speed, it comes at a significant scaling penalty starting at 24 cores. We used the Linux perf stat utility to measure a variety of CPU performance countersand provide further insight into the differences in scalability across schedulers.
We also measured the parallel speedup on 48 cores for unordered (random-order) and Hilbert-reordered inputs, and the relative speedup afforded by the reordering process; Table  14  shows our results. Without reordering, all schedulers show evidence of poor cache utilization as predicted in Section 2 -their parallel speedup is only 23. 49-26. 05x on 48 cores, while incurring 0. 53-1. 27 LLC misses per edge and roughly 0. 5 dTLB misses per edge. The dTLB is a small cache of translations between virtual and physical memory. If the virtual address being loaded is not present in the dTLB, a "page walk" occurs. The page walk traverses a tree structure that resides in memory and is cached in the LLC, just as any other memory state -competing for cache space with the data of the application itself.
4x speedup on 48 cores. Meanwhile, BSP's doubled memory usage, Chroma's high cache miss rate, and JP's expensive atomic instructions cause these three schedulers to only capture less than 60% of the ideal parallel speedup with 48 cores, even on Hilbert-reordered inputs. Hilbert-reordered inputs significantly reduce all schedulers' LLC and dTLB miss rates, as a consequence of the cache advantages examined theoretically in Section 2 and empirically measured as shown in Table  14. For example, Laika with Hilbert ordering incurs 7. 38 times fewer cache misses and 104. 73 times fewer dTLB misses, making it 9. 36 times faster overall. Reordering also appears to render prefetchers more effective, likely due to a more regular memory access pattern. However, the lower miss rates do not benefit all schedulers equally, and may in fact make performance worse! The reordering cannot alleviate JP's execution of expensive atomic decrements: the same recursive structure that improved its reuse of cached data now exacerbates memory contention between those atomic instructions, causing JP on 48 cores with Hilbert inputs to only achieve 77% of the performance of using unordered inputs.
ACKNOWLEDGMENTS We would like to thank  Charles E. Leiserson ,  Tao B. Schardl , and  Tim Kaler  from the  Supertech group at MIT. They continue to be very generous with insights, humor, and technical assistance. We would like to thank  Fredrik Kjølstad  who inspired us to schedule data-graph computations on 3D mesh graphs and provided much needed context on real applications. Thanks to  Leonid Taycher  at  Kensho Technologies  for his patience, support, and understanding while this work was in progress. This work is sponsored in part by the  Direction Générale de l'Armement ,  Kensho Technologies , and  MIT 's  SuperUROP program ; we thank them for their support.
Hardware and Software Description The measurement setup used in the experiment included a PC computer, digital oscilloscope, arbitrary function generator and power amplifier (Figures  6  and 7 ). The function generator was used to provide a sinusoidal signal with constant predefined amplitude in a given frequency range. The power amplifier was used for signal conditioning both for the voltage (20×) and for the current (up to 200 mA) in order to operate PZT actuator in the frequency regime where impedance of the actuator is low, i. e. , close to the resonant frequency of piezo elements used  [2, 18]. The digital oscilloscope was used for measuring the excitation voltage on the PZT actuator-G-as well as induced voltage on the three sensors: S1, S2, S3. The devices were connected to a PC computer with an installed LabVIEW environment.
An application in the LabVIEW environment was developed, which allowed automatization of the measurement process, configuration and synchronization of the devices, as well as visualization and storage of the acquired data. In Figure  8 , the setup panel of the application is presented. The typical laboratory setup (Figures  6  and 7 ) was used for convenience. Instead, it is possible to use an integrated measuring device like a Digital Analog Discovery 2 that combines a dual channel oscilloscope and generator functions into one device (Figure  9 ). It can be connected to a portable computer and controlled from the same LabVIEW application as the main system (Figure  8 ). In such a solution the presence of a power amplifier is still required and since fewer input channels are available, an additional module switching active PZT sensor pairs based on external mux module would be also necessary.
Measurements Scheme The measurements were performed in the following order: (1) Measurement for the pristine state of the structure. (2) Measurement for simulated damage on sensing path G-S1. (3) Measurement for simulated damage on sensing path G-S2. (  4 ) Measurement for simulated damage on sensing path G-S3. The above measurement scheme was repeated six times, thus data from 24 measurements series were obtained for each network. The damage was simulated by a mass element attached to the specimen in the middle of a given sensing path (Figure  5 ). The mass diameter was 22 mm. The mass was attached by a bituminous substrate. The total weight of the mass and the substrate was approximately 6. 4 g. The mass provided local pressure field which can distort elastic waves propagating underneath, e.
The wires connected to actuator G, to which high voltage was applied, runs in parallel to wires connected to the sensor S3, used for low voltage measurement. This could have impact on the voltage induced on the sensor S3 and interfere with the results, resulting in increased spread of data in that case. In Figure  15 , a comparison of the DIs' distribution for different sensing paths is presented. In the comparison, both states of the structure are considered-the case of simulated damage presence as well as undamaged structure condition. All repetitions of measurements are included for the purpose of comparison. For the attached network of PZT sensors, all of the sensing paths are considered (Figure  15a ), whereas for the embedded network the sensing path G-S3 is excluded from the plot (Figure  15b ), due to abovementioned divergence of the results obtained for it.
g. , nearest neighbor algorithm, for damage classification  [44]. In Figure  16  the performance of the attached and embedded sensors in damage indication is compared. For both networks DIs obtained for sensing paths G-S1 and G-S2 were included. The bias of DIs distribution from the point 1 + i0 is similar for attached and embedded sensors, the difference between them is revealed in the separation of data corresponding to undamaged and damaged structure. The separation of data can be quantified by using Hotelling's T-squared distribution (T2)  [45]. It is used for statistical testing of difference between means of multivariate random samples. Higher values of T2 distribution obtained for two groups of multivariate data indicates more significant separation of the two groups. In Figure  17  boxplots of values of T2 distribution obtained for DIs calculated for repetition of measurements are presented.
Acknowledgments : The work presented in this paper has been partially supported by the  European Defence Agency (EDA)  through Contract No B  1404 ESM2  GP entitled "SHM application to Remotely Piloted Aircraft Systems (SAMAS)". The binational  SAMAS  project involves the following partners:  Politecnico di Milano  (consortium leader) and  Leonardo Aircraft Division represent Italy, Air Force Institute of Technology  and Military Aviation Works No. 1 J. S. C represent Poland.
Data collection The quantitative phase began with site selection in 2011. We used Health and Monitoring Information System clinic register data, collected and verified by the Ministério da Saúde (MISAU), to retrospectively identify facilities exhibiting an increase in institutional deliveries in the 2 years preceding  (2009) (2010) (2011). Though most Nampula districts had observed some level of increase in institutional deliveries in their facilities, five facilities in five districts had significant increases  [23]. From these five facilities, three were excluded due to having insufficient clinic register data during the observation period, and poor or absent roads necessary to participate in the study. Institutional deliveries service delivery data in the two remaining primary care facilities continued to be collected from MISAU data sets for the following 3 years, bringing the total years of service delivery observation to five (2009-2014).
Data analysis Institutional delivery data was initially analyzed at the district level. Data from districts representing the observed increase in institutional deliveries was then further examined to identify specific health facilities that demonstrated the trend. Facilities' service delivery data was subsequently cleaned and verified. Institutional delivery coverage was estimated by comparing the number of reported deliveries with the total number of projected live births (estimated using census data) in each facility's catchment area. A time series analysis was then conducted, plotting the number of institutional deliveries and coverage rates over the observation years for the Table  2  The three phases of data collection and analysis, in chronological order according to their implementation.
Data analysis The lead author and an additional analyst who did not participate directly in data collection were responsible for applying CFIR domains for deductive coding, for inductively identifying emerging themes, and for developing a codebook and corresponding code-tree with descriptions of all codes and sub-codes  [30, 31]. A two-phase interrater reliability exercise was conducted: The two analysts used line-by-line coding to independently code identical transcripts. The analysts compared their coded transcripts, discussed codes assigned, and refined working definitions for each code as a reference point within the codebook. The analysts continued coding additional transcripts until 80% reliability was reached. Line-by-line coding was then performed for remaining interview transcripts using ImpactMapper.
Acknowledgements We are sincerely grateful to the  Nampula community members, facility  staff, and  District Coordinators Abdul Rachyd Miguel Jacinto  and  Janeth Abudo  who participated in and supported this study, and  Estêbão Manhiça  who supported data collection. We are also grateful to the  Pathfinder-Mozambique Country Representatives ,  Rita Badiani  and  Riaz Mobaracaly , who helped make this study possible; to  Camille Collins Lovell  and  Joseph Petraglia  for their thought partnership in the early stages of study design and data analysis; and to  Nandini Choudhury  for her support as research assistant during coding. Thanks as well to  Laura Damschroder  and  Julie Lowery  for their early consultation on applying the CFIR to community-, volunteer-based implementation scenarios.
Text in natural images contains rich semantics that are often highly relevant to objects or scene. In this paper, we focus on the problem of fully exploiting scene text for visual understanding. The main idea is combining word representations and deep visual features into a globally trainable deep convolutional neural network. First, the recognized words are obtained by a scene text reading system. Then, we combine the word embedding of the recognized words and the deep visual features into a single representation, which is optimized by a convolutional neural network for fine-grained image classification. In our framework, the attention mechanism is adopted to reveal the relevance between each recognized word and the given image, which further enhances the recognition performance. We have performed experiments on two datasets: Con-Text dataset and Drink Bottle dataset, that are proposed for fine-grained classification of business places and drink bottles, respectively.