dataesr/scientific-paragraphs-categorization huggingface dataset:
To the best of our knowledge, we are the first to evaluate this aspect in the context of data offloading. As a summary, the main contributions of this paper are: • Joint offloading strategy. Our strategy employs direct D2D opportunistic communications to assist the cellular distribution via multicast. • RL-based multicast selection. The multicast emission is driven by a RL algorithm. Exploiting the knowledge of past rounds, the algorithm tunes the set of nodes to be reached via multicast, allowing substantial savings at the cellular base stations. • Fine-grained resource consumption analysis. We evaluate resource consumption employing the smallest radio resource unit that can be assigned to users for data transmission. This analysis shows that existing macroscopic techniques fail to capture actual system behaviors.
Accordingly, all UEs that receive the required content send an acknowledgment to the central controller situated at the eNB through LTE. When the reception delay reaches its maximum value D, the central controller instructs the eNB to push all the missing data to UEs that have not been served yet using unicast transmissions. Of course, unicast transmissions represent the last opportunity to assure data reception 3. In this scheme, the cost of disseminating content to interested UEs comes from i) the cost of the initial multicast transmission, and ii) the cost of the unicast transmissions in the panic zone. Fig. 2  offers a representative example of the proposed dissemination strategy. To avoid the penalty due to the 2 D2D communications will be soon possible within the LTE technology (and spectrum).
ns-3 implementation We implemented the multi-armed bandit algorithm using ns-3, a packet-level network simulator which implements the full LTE and Wi-Fi stacks, allowing for very realistic simulations  [6, 5]. Since ns-3 does not natively support cellular multicast, we modified it by implementing an additional module that interacts with the packet scheduler to emulate single-cell multicast. The multicast module decides, upon each transmission, the fraction of UEs to be reached directly, i. e. the I 0 parameter, based on the multi-armed bandit algorithm presented in Section 3. It receives the CQI from the standard LTE modules, and sets the MCS of the multicast transmission to reach the intended UEs. We fix the bandwidth allocated for the multicast service at 5 MHz. 3GPP standard recommends not to reserve more than 60% of RBs to multicast  [16] , so a 5 MHz value could represent respectively 50% or 25% of RBs in a typical 10 or 20 MHz deployment.
The notion of capturing each execution of a script and workflow and its associated metadata is enormously appealing and should be at the heart of any attempt to make scientific simulations repeatable and reproducible. Most of the work in the literature focus in the terminology and the approaches to acquire those metadata. Those are critical but not enough. Since one of the purposes of capturing an execution is to be able to recreate the same execution environment as in the original run, there is a great need to investigate ways to recreate a similar environment from those metadata and also to be able to make them accessible to the community for collaboration. The so popular social collaborative pull request mechanism in Github is a great example of how cloud infrastructures can bring another layer of public collaboration.
Data Driven Cloud Service Platform To support simulation management tools metadata, we propose a cloud platform that implements the reproducible assessable record described previously. This platform has two sides. As shown in the Figure  1 , an API 2 access and a Web Frontend 3 access. These two services are linked to a MongoDB 4 database that contains: the user accounts, the projects, the records, the containers and the differentiation requests. We implemented some restrictions depending on the type of access. The API service exposes endpoints that are accessible by the Simulation management tool from the executing machine. It is a token based credential access that can be activated and renewed only from the Web Frontend access. The API allows the Simulation Management tools to push, pull and search projects and records.
Sumatra Integration Sumatra is an open source event based simulation management tool. To integrate the cloud API into Sumatra we briefly investigate how Sumatra stores the metadata about a simulation execution. To store records about executions, Sumatra implements record stores. It also has data stores that allow the storage of the simulation results. As of today, Sumatra provides three data storage options: • FileSystemDataStore: It provides methods for accessing files stored on a local file system, under a given root directory. • ArchivingFileSystemDataStore: It provides methods for accessing files written to a local file system then archived as. tar. gz. • MirroredFileSystemDataStore: It provides methods for accessing files written to a local file system then mirrored to a web server. Sumatra also provides three ways of recording the simulation metadata: Regarding the visualization of the metadata from a simulation, Sumatra provides a Django 7 tool named smtweb.
It is a local web app that provides a web view to the project folder from where it has been ran. For a simulation management tool like Sumatra there are many advantages in integrating a cloud platform into its record storage options: • Cloud Storage capability: When pushed to the cloud, the data is accessible from anywhere. As presented in the list of record store options, Sumatra already has an HTTP based record store available. Yet it does not suite the requirements of the cloud platform. Firstly because there is no automatic mechanism to push the data in the cloud. The MirroredFileSystemDataStore has to be fully done by the user. Secondly we think there is need for more atomicity. In fact, Sumatra gather the metadata about the execution and store it at the end of the execution, which can have many disadvantages generally when the simulation process dies or the Sumatra instance dies.
To integrate the cloud API and fully comply to the requirement cited before, we had to implement and update some parts of the Sumatra source code: • DataStore: Currently the collect of newly created data happens at the end of the execution. This creates many issues regarding concurrent runs of the same projects because the same files are going to be manipulated. We are investigating two alternatives. The first is about running the simulation in a labeled working directory. This way, many runs can be done at the same time while having a private labeled space to write to. The second alternative consists of writing directly into the cloud. This will most likely break the already implemented data and record store paradigm in Sumatra. • RecordStore: We make the point that the simulation management tool is the one that should comply to as many API interfaces as possible to give the user as many interoperability as possible with cloud platforms that support reproducible records.
Thus, we intend to provide a total new record store that will fully integrate the API into Sumatra. • Recording Mechanism: In Sumatra the knowledge of the final result of the execution combined with atomic state monitoring of the process will allow us to have a dynamic state of the execution. We want to make Sumatra record creation a dynamic many points recorder. In addition to an active monitoring, this feature allows the scientist to have basic informations about its runs may they crash or not. execute the simulation and create the associated record that will be pushed to the cloud API. The interesting part of such a design is that the record image can be ran by any other scientist with the possibility to change the input data. This allows reproducibility at an input data level. For source code level modifications, the other scientist has to recreate an instrumented project.
In the manage script, an API token is required to be able to access the cloud API. The scientist will have to put his own. A further detailed documentation will be provided. The source code of the demo can be found here 10. It has been tested on an Ubuntu 15. 04 machine and will work on any Linux or OsX machine that has docker installed. The instrumented example presented here, has been done from a local development instance of the platform. AWS 11 server instances are being setup to host a public access to a production version of this platform. To reproduce this example demo, the url inside the manage. sh will have to be update accordingly to the location of the API endpoint. Further information will be delivered.
Conclusion and Perspective Scientific computational experiments through simulation is getting more support to enhance the reproducibility of research results. Execution metadata recording systems through event control, workflows and libraries are the approaches that are investigated and quite a good number of softwares and tools implement them. Yet the aspect of having these records discoverable in a reproducible manner is still an unfulfilled need. This paper proposes a container based reproducible record atom and the cloud platform to support it. The cloud platform provides an API that can easily be integrated to the existing Data Driven Simulation Management tools and allow: reproducibility assessments, world wide web exposure and sharing. We described an integration use case with Sumatra and explained how beneficial and useful it is for Sumatra users to link the cloud API to their Sumatra tool.
And from there be able to verify the claims of the project and investigate other execution on different input data. The container based record described here, we hope, will allow a better standard environment control across repeats and reproductions, which is a very hard battle currently for all simulation management tools. Operating systems, compilers and dependencies variations are the nightmare of reproducibility tools because the information is usually not fully accessible and recreating the appropriate environment is not an easy straight forward task. 10. https://github. com/faical-yannick-congo/ddsm-demo 11. Amazon Web Services: http://aws. amazon. com/ Finally it is important to point out that in some cases the five components (source code, inputs, hosting system, dependencies and outputs) cited before are not sufficient because the design of the simulation itself has to follow a rigorous method to better enforce reproducibility.
2. Application ProgrammingInterface. 3. Client browser access. 4. An Agile, Scalable NoSQL Database: https://www. mongodb. org/ 5. HyperText Transfert Protocol. 6. A Data-Interchange format: http://json. org/ 7. Python Web Framework: https://www. djangoproject. com/ • Complexity reduction: There is no need for a local record viewer. The scientist can have access to his records anytime and anywhere. • Discoverability enhancement: Everything about a simulation execution is a click away to being publicly shared.
Acknowledgments This research paper is made possible through the help of my thesis supervisors and colleagues. First and foremost, I would like to thank  Dr. David Hill  and  Dr. Jonathan Guyer  for their most support, encouragements and critics. Second, I would also like to thank  Dr. Daniel Wheeler  for his ideas and brainstorms at the early stage of this investigation and his continuous research for better technologies for computational science. Finally, I would like to thank  Dr. Andrew Reid  and  Dr. Stephen Langer  for their exceptional willingness to help me reshape and bring more lights in this paper. They kindly read my paper and offered invaluable detailed advices on grammar and organization of the paper.
, 2014; Huber et al. , 2006). It thus appears that the way NGRIP was implemented in the Datice tool for the AICC2012 chronology is not optimal. In addition to GICC05 chronological uncertainties that were not taken into account by construction, imposing the DJ-GICC05 accumulation rate and thinning scenarios with artificially reduced variances most probably led to incorrect output scenarios for these glaciological parameters. In this paper, we propose an improvement of Datice to better implement the chronological uncertainties. Markers of duration are integrated in Datice with associated counting error. This allows for the strong constraints on thinning and accumulation rate to be relaxed. It also allows the NGRIP chronology to differ from GICC05 chronology within its error bars. The outline of the manuscript is as follows.
Concerning the age constraint, the absolute age markers deduced from GICC05 were replaced by the duration constraints. The markers of duration are obtained from the GICC05 chronology with adaptive lengths of intervals between 40 and 140 years under the AddMCE assumption (full correlation between annual cycles) and a correlation length of 300 years. In order to constrain the relative gas chronology vs. the ice chronology, we use information derived from δ 15 N of air trapped in ice bubbles. New δ 15 N data on the NGRIP ice core have been published since the AICC2012 chronology  (Kindler et al. , 2014). In particular, these data allow for identification of depths of rapid temperature increases associated with the beginning of Greenland Interstadial (GI) 1 to 7 in the gas phase. The depth differences between peaks of δ 18 O ice and δ 15 N of a concomitant event recorded in the ice and the gas phases are thus used as delta-depth ( depth) constraints.
With the new set of data from  Kindler et al. (2014) , we were thus able to deduce new depth markers that were not available for the construction of AICC2012 (Table  3 ). Their uncertainties depend on the resolution of measure- ments and the difference of depth estimates. Indeed, the depth can be estimated from the difference between midslopes of δ 18 O ice and δ 15 N increases or from the difference between the maxima of δ 15 N and δ 18 O ice. Figure  8  compares the new Datice chronology produced here (NGRIP-free) to AICC2012 for the five sites between 35 and 48 ka. We emphasize that the NGRIP-free chronology discussed here should not be taken as a new official chronology. It is only a test for our methodological development. Moreover, the AICC2012 chronology has the strong advantage of being in exact agreement with the GICC05 chronology and hence facilitating the multi-archive comparison, taking GICC05 as a reference, as has already been done in many studies  (INTIMATE project: Blockley et al.
Acknowledgements. We thank  Eric Wolff  for his comments on a preliminary version of this article. We thank  Paul Blackwell  and the anonymous reviewers for their fruitful comments. This project was funded by the  Fondation de France Ars Cuttoli. This work was supported by  Labex  L-IPSL, which is funded by the  ANR  (grant no. ANR-10-LABX-0018 ). This is LSCE contribution no. 5502. Edited by:  N. Abram.
The MOEA is in fact the heart of a larger application which includes more traditional management modules such as customer billing, customer support, calculation of working hours and payment of ambulance attendants according to the legislation in force, among others. Therefore, the development of the different operators of the MOEA are in a direct relation with the classes and data structures inside the management application. Even if this problem belongs to the family of Vehicle Routing Problems  3  (VRP), it is clear that the solutions proposed in the literature, as specific as they are  4, 5, 6, 7  , were not intended to take into account all the specific constraints of a real problem. Even some very efficient genetic algorithms for the pick-up and delivery problem  8  have not considered all the important details involved in the health care transport area.
Calculating the Quality of Service In the current version of the MOEA, we have focused on the cost associated with being late or early. The idea is to minimize the waiting time of the patient (in the case of being late) as well of the waiting time of the vehicle (in the case of being early). Each Journey J between two PlannedElements p j and p j+1 is represented as a temporal line (cf. Fig. 1 ) with three values: S j , S D j and (T T N j ). S j refers to the time the vehicle should arrive at destination. S D j is the time needed to take care of the patient and T T N j is the estimated time to arrive to destination. For the current implementation, we estimate the S D j value in 15 minutes, whereas information concerning the T T N j is pre-calculated using a third-party software and stored as a three-dimensional matrix (called cubeT T N), where each element represents the travel times between two addresses for a given (discrete) time in the day.
Experiment Setup A first prototype of the algorithm was developed using EASEA  13, 14  a high-level framework for easily developing evolutionary approaches. The framework was extended to support multi-objectives algorithms by including the source code of the NSGA-II 11 algorithm. In order to evaluate the behaviour of the algorithm, we carried out an experiment on an average sized problem. Real data is coming from a small PTS company with a 23 vehicle fleet. The vehicle fleet is composed of VSL (e. g. the French initials for Lightweight Sanitary Vehicle) and Ambulances. For this paper, we are using the data corresponding to the vehicle itineraries for five days (from Monday to Friday). The three first columns of Table  2  show the number of journeys and vehicles used for satisfying the costumer's request for each day.
Solar energy is a green and attractive renewable energy source that can be converted for power generation. The objective of this work is to evaluate the potential of dish Stirling systems if they are used in the fourth worldwide largest island of Madagascar. For that purpose, a theoretical model of the dish Stirling system based on the geometrical configuration and heat transfer was developed and coded on Matlab. Simulations were run to investigate the energy efficiency variation of the system for eight main sites in Madagascar. As results, the proposed model enables to represent the system thermal behaviour to assess its efficiency. Among the eight studied sites, those which are on the coastal zones are more propitious to the dish Stirling system. While, in the north and northwest, the sites of Diego Suarez and Majunga present high efficiencies with, respectively, 31.
Conclusion This paper presents a thermal energy efficiency investigation of dish Stirling system for eight main sites in Madagascar. A theoretical model of dish Stirling based on the geometrical configuration and heat transfer was developed and coded on Matlab 7. 10. While using weather data of the aforementioned sites, it follows from simulation results that the solar radiation varies according to geographic location, that is, Madagascar has various microclimates. Indeed, the model used shows that the system thermal efficiencies according to the studied sites depend on the thermal efficiency rate of the parabolic collector and are influenced by weather conditions on each region of the island. Therefore, the coastal zones are more propitious to the system with an average annual thermal efficiency over 30(%) especially in the North, in Diego Suarez with 31.
C. Implementation of lens controller software for the axial scanning with ETL The magnetic actuator of the ETL was controlled by Lens Driver 4, which delivered a stable current output from 0 to 298 mA with a precision of 12 bits, at a maximum of 5V, provided by Optotune (Switzerland). Our originally implemented software for the controller is written in C programming language and works on Unix based operating systems, for example, Mac OS X, FreeBSD, and Linux. All the source codes of the lens controller are available from the following URL (http:// fun. bio. keio. ac. jp/software).
D. Simulation results of the ETL/OL assemble system We estimated the axial range and optical resolution properties of the ETL-microscope objective combination by building simulation models including a 100× objective using ZEMAX, the optical deign software (ZEMAX Development Corporation, Redmond, WA, USA). Prescription reference data for UPlanSApo, 100× Oil, NA 1. 40 were obtained from the patent literature. 19 igure  2  shows the correlation between ETL control current mA and axial focus shift µm (a), relative magnification (b), and NA values simulated with ZEMAX (c). Simulated axial focus shift and relative magnification are fitted to equations z = 4. 917 × 10 -6 i 3 -0. 0004i 2 + 0. 2491i -8. 9443 with R 2 = 0. 999 and y = -0. 002i +0. 9967 with R 2 = 0. 997, respectively (z: axial focus shift µm, y: relative magnification, and i: current value mA).
D. Evaluation of optical resolution Our simulation predicted the change of NA value dependent on the curvature of ETL (Figure  2(c) ). This prediction let us to estimate the further effects on the optical resolution of total ETL/OL assembly. Now, we evaluated the optical performance of this ETL/OL assembly by analysing point spread function (PSF), and estimated if our ETL/OL assembly is applicable for further intracellular imaging. Fluorescently labeled polystyrene microsphere, 100 nm in diameter (Fluoresbrite, Polyscience, Inc. ) was used as point source. Data analysis was performed with MetroloJ,  20  which is a plug-in software by Fiji. 21 Lateral resolution was defined as FWHM of the PSF. Our application was tested with a conventional fluorescent (wide-field) microscope; therefore, we defined axial resolution as a depth of field.
ACKNOWLEDGMENTS We declare that the research was conducted in the absence of any commercial or financial relation that could be construed as a conflict of interest. We are deeply grateful to  Professor Helge Ewers  of  Institute of Biochemistry, ETH Zurich , and  Dr. Fabian Voigt , in the group of  Fritjof Helmchen  at the  University of Zurich , who kindly offered much advice and scientific support to us. We also thank to  Optotune AG (Switzerland)  for their kind support. We thank  Duccio Conti  for helping with proof reading of manuscript. This work is supported by a  CASIO grant (Japan ),  Konica Minolta (Japan) , award to  N. Hiroi. This work was supported by  Japan Society for the Promotion of Science (JSPS) Grants-in-Aid for Scientific Research (Kiban B)   24300112 , and  Grant-in-Aid for Challenging Exploratory Research (Chousenteki Houga )  26640132 , award to  A.
Our targeted goal: bring DMN to life for automated Decision-making Our targeted long-term goal is to provide a complete computer-aided method going from decision-making models to automatically generated FEEL code, interpreted or executed by a BRMS (Business Rules Management System), as open source Drools  [12]. This BRMS will be interfaced with a business process engine, on which the corresponding BPMN business process model will be executed. This approach is fully aligned with the Model-Driven Architecture (MDA  [13] ), which clearly specifies a system independently from the platform that supports it, with primary goals of portability, interoperability and reusability. With its Decision Requirements Diagram for modeling and its FEEL language for notation, DMN covers the two MDA upper levels CIM and PIM as shown in table  2.
DMN implementation based on Eclipse tools We chose best-of-breed modules for Eclipse Modeling Tools dedicated to model driven engineering: -Sirius  [14]  to create our graphical DMN modeling tool (without programming but with advanced setting), -Acceleo  [15]  to generate FEEL code by using a Model-to-Text transformation (with programming and advanced setting too). Below is a couple of screen captures about what we have done with theses Eclipse modules. DMN graphic elements special shapes are for the moment replaced by colours: it is a temporary solution without Java programming.