dataesr/scientific-paragraphs-categorization huggingface dataset:
The paper proposes an original architecture to execute discrete-event simulations using mobile devices (in particular smartphones) and cloud. The originality of the proposed approach is highlighted by the way the connection between modeling and simulation environment, cloud and smartphones is performed via a solid web services oriented architecture. This approach has led to a software implementation based on the discrete-event system specification formalism which allows an explicit separation between the modeling aspect and the simulation features. Thanks to this explicit separation, the discrete-event models defined and validated by simulation are remotely accessible from smartphones via web services. With this new approach, a smartphone is part of the simulation model and it can be used for real data acquisition or to control the model during the simulation.
Problems and background The proposed approach deals with a set of research questions involved by the connection between simulation, cloud and smartphones: • How to interface simulation software with mobile application programming interfaces (APIs)? • How to combine discrete-event simulation, cloud storage (with web services interfaces) and mobile terminals? • How to use a generic approach to deal with these problems? To address the three previous questions, a new web-based simulation approach including a collaborative discrete-event M&S environment associated with a mobile app in order to remotely simulate discrete-event models libraries via web services can be envisioned. A possible approach can be defined from the domain of the design of SoS  [9, 10]  based on web based discrete-event simulation.
The generic proposed approach (Fig. 1 ) allows to automatically deploy a simulation model built by a team of engineers on a mobile terminal via web services (smartphone, tablet, etc. ). When the system is modeled and validated (by simulation) in a M&S software, it can be proposed to the end-users to remotely simulate the resulting model of the studied system with data acquired from mobile terminal sensors immersed in a real physical environment. The benefit of the approach and its motivation are mainly highlighted through the ability (i) to perform data acquisition from mobile terminal sensors in order to simulate a system in a real physical environment (ii) to interact dynamically with the model from the mobile app during simulation. The introduction of two previous capabilities needs a discreteevent framework based on an explicit separation between modeling and simulation parts.
Software architecture According to Fig. 1 , engineers use the DEVSimPy environment to implement DEVSimPy simulation models (in. yaml format) that they will store on the libraries file server (on the left part of Fig. 2 )). These simulation models, which may depend on DEVS model libraries and plugins, can be simulated via the web using a command line version of DEVSimPy (DEVSimPy-nogui) software which is accessible through the REST (Representational State Transfer)  [17, 18]  interface of a DEVSimPy-Rest server 1  (see  2 in Fig. 2 ). This interface is implemented in the mobile app DEVSimPy-mob and is accessible to all users (not necessarily experts of the M&S) wishing to exploit the simulation models. From a technical point of view, the DEVSimPy-mob mobile app allows first of all to interact with web services provided by a REST web server.
2 ). A first use of this communication is to send the progress of the simulation. Another use is to send the simulation results while simulation running. For this purpose, two new models have been created. The first directly transmits the results to DEVSimPy-mob via Pusher and the mobile app is then responsible for making these data accessible. The second uses a web service for the scientific representation of data: the Plotly  [20]  service. This collector sends to the Plotly server not only the data but also their representation mode (line, bars, 2D, 3D, etc. ) and the server provides in return a URL where the data are accessible for visualization (see 6, 7 in Fig. 2 ). This URL, received at the collector level, is transmitted to the mobile app via Pusher. When a simulation is created, an identifier (ID) is associated and stored in a database (see 8 in Fig.
Implementation and empirical results The DEVSimPy-mob mobile app is a hybrid application developed using the Apache Cordova©  [21]  technology that allows you to write a cross-platform application based on JavaScript, HTML5 and CSS  [22]  languages, and automatically generate the versions corresponding to the desired platforms (Android or IOS). In order to facilitate the evolution of the application, we chose to use Google's Angular framework which optimizes the structure and modularity of the code. We realized the development with the Ionic  [23, 24]  platform which facilitates the integration of Angular with Cordova  [25]  that produces a browser version in addition to a mobile version. It provides basic graphical interface elements that are adaptable and compliant with the graphic charters of the different platforms.
The mobile app has been designed, modeled and implemented using the Ionic v2 framework and the architecture of the code is given in Fig. 6(a). The Ionic v2 framework integrates Angular and Cordova but it redefines also a new syntax and additional services: in particular the Page, Tabs and Tab components and the NavController service to facilitate navigation (managed as a stack of pages). Likewise, Ionic, via the ionic-native library, facilitates the integration of Cordova plugins. We can point out that Ionic offers a useful feature for sharing an application in development. The user-testers install the IonicView  [24]  app and access the latest version of the application uploaded by the developers. The browser version of the DEVSimPy-mob (used in the development phase) can be obtained with the command 'ionic serve' (Fig.
6(b) ). The www directory which contains the index. html file is completed by a www/build directory which contains the compiled code (all. ts files and 1 app. bundle. js file) and the html files. Then the command 'ionic run android' allows to create the version for Android that can be installed on the mobile terminal. Finally, the 'ionic upload' command can be used to upload the DEVSimPy-mob app to the Ionic platform and thus makes it available to users of the IonicView app. The web services provided by the DEVSimPy-Rest server has been developed in Python language thanks to the Bottle  [26]  framework and respects the principles of REST architecture  [27]. If, for example, the URL of the service DEVSimPy-Rest is http: //ticproject. univ-corse. fr on port 8080, then: • The GET request: http://ticproject.
) in a Mongo  [29]  database. The unique identifier assigned to the simulation by the database server is embedded in the POST request. This identifier allows to access to the simulation simu_id by using the web service (http://ticproject. univ-corse. fr:8080/simulations/simu_id). All of the API resources are listed in Appendix and are available to external client including the DEVSimPy-mob mobile app. SoapUI  [30]  has been used to test them and the test suite is fully described by a single xml file available from https://github. com/ CelineBateauKessler/DEVSimPy_rest/tree/master/test. 4 ) Services (  5 ) Each service has an associated. ts file (  6 ) app. ts allows to define services that will be included in the pages and to define the first page of the mobile app. (b) Code structure after a build from Ionic serve command.
Once the decision algorithms have been validated using simulation data, the next step is to integrate the real data and the interaction (command) with the simulation model via DEVSimPymob. To do this, each model of the experimental framework is replaced by its interface model -the Phidgets© SBC that embeds humidity and solenoid valve sensors (Single Board Computer)  [36]  for the SensorActuator model and a weather web service for the ''WeatherWebService'' which have been already implemented in libraries. The Phidgets is an embedded system with a Linux OS of Debian type and a connection interface that can accept sensors. It is part of the family of components like ©, 2  Raspberry© 3  or Gad-geteer©  4  allowing to build communicating object systems. The Phidgets embeds a DHC (Dynamic Host Configuration Protocol) client, a web services server, an SSH server and can be accessible in ''Remote'' mode thanks to its ip address and a port which is by default port 5001.
It is also possible to make it a wifi access point. There is an API in Python language which allows among other things to access the Phidgets in ''Remote'' mode and therefore to the sensors/actuators connected to it. It is this API which is used in the yaml models simulated by DEVSimPy-mob. In addition, we goes into real time simulation mode instead of simulated time and the simulation model works as an infinite simulation loop. The integration of the interaction with DEVSimPy-mob is automatic: once ported to the DEVSimPy-Rest server, the model is accessible to the user in bi-directional mode. DEVSimPy-mob allows you to view the activity of the sprinkler model using the collector (Fig. 5(i) ) and allows the user to force watering by modifying the mode parameter of the ''Arroseur'' model during the simulation (Fig.
Discussion M&S is a discipline first of all oriented towards engineering and research, but it tends since the very last years to be used more and more by users and developers of mobile apps through cloud storage and web services  [3, 7]. Recent developments in the cloud computing field and service-oriented architectures offer advances to better utilize M&S capabilities. The proposed approach in this paper can be compared to the MATLAB © Apps one  [37]  that are web apps designed and compiled into the MATLAB software suite in order to propose browser-based web apps to end-users which are not MATLAB developers. MATLAB Compiler lets you share MATLAB Web apps with end-users who do not have MATLAB software. The Fig. 8  shows the workflow proposed by the MATLAB software suite dedicated to create a MATLAB web app.
First off all, the MATLAB App Designer is used to implement the web app interface. Then, the code is compiled with a MATLAB compiler in order to deployed the complied package in a MATLAB Web App Server. The web app is available through an url and it can be shared via a classic browser. This approach needs to install previously the web app server. The proposed approach differs from MATLAB by the possibility to inject real data to the simulation model settings using mobile terminal sensors. This is not possible with the MATLAB Web App solution which is browser-based. Concerning the development software development aspect, MATLAB needs to compile the Web App design in order to build an archive compatible with the MATLAB Web Server. With the proposed approach, there is no compilation phase, the model is automatically exported without transformation (compilation) into the Web server.
The only thing that is required is to import all dependencies with the libraries of models. This task is achieved only once. Also when the Web App is developed, one need to have in mind some user features such as ability to change parameter values during running, etc. These difficulties in making changes are proposed by MATLAB but they do not depend on the real data coming from sensors as proposed by our approach. Moreover, displaying graphics in MATLAB App Designer requires a different workflow which can be included only in the MATLAB command line. With the proposed approach, the user can implement a large kind of observers (collector, QuickScope, etc. ) in order to visualize its specific simulation results. The DEVSimPy-mob proposed approach improves the use of simulation models and makes them more available to a large scale of non-specialist users.
Conclusion This paper presents DEVSimPy-mob mobile app associated with the M&S DEVSimPy environment as a software suite for web-based discrete-event simulation from mobile app. Thanks to this approach, the DEVS models defined and validated by simulation using the DEVSimPy framework are remotely accessible by the DEVSimPy-mob mobile app. DEVSimPy-mob is based on bidirectional communication based on the use of web services that allow a user to control models before and during their simulation. This mobile app simulates DEVSimPy models -defined in a DEVS experimental framework -from real data that can come from platforms embedding sensors. Actually, the DEVSimPy-mob is available from GitHub  [13]. It has been used to design, validate and interact with the ubiquitous system which is presented in the paper.
Furthermore, the DEVSimPy-mob has also been used in the context of the problematic raised in the framework of Ballistic Missile Defence System in the United States  [38]. We plan to evolve the DEVSimPy-Rest server by replacing the REST API with the new open source GraphQL  [39]  universal language in order to build a back-end and integrate it into the front-end more easily but also to make quick changes with less risk of crash. GraphQL is based on a simple idea: to move the assembly of a query from the server to the client. The interest is that DEVSimPy-mob sees the whole strongly typed graph of services instead of a multitude of REST services and builds the required request according to its needs.
Their performances have been benchmarked on a standardized image dataset (the Brain Tumor Image Segmentation, BraTS  [32, 34] ), using a diagnostic accuracy approach with human rater segmentations as reference. In this approach, the spatial overlap of segmented voxels is typically reported as a Dice score, and the distance of segmentation surfaces as a Hausdorff metric. Nevertheless, this strictly determines the voxel-wise resemblance between an automated segmentation and the reference segmentation. This does not address the clinical utility of these segmentations, and the curated standardized image dataset is not representative for routine scans, which are often of suboptimal quality due to motion artefacts, missing sequences, and other image degradation. Furthermore, in routine scans, brains are not extracted, as is the case in the BraTS dataset.
Patients gave their informed consent for scientific use of their data, as required for each participating hospital. The study was conducted in accordance with the Declaration of Helsinki, and the protocol was approved by the Medical Ethics Review Committee. Data and images for analysis were pseudonymized for analysis. Patients were identified at each hospital by prospective electronic databases. Part of this cohort was reported earlier to address resectability and comparison of surgical decisions between institutes  [46, 47]. Descriptive information was collected from the electronical medical records, including age and gender. Preoperative MR scans were acquired from the hospitals' archival systems and included a 3D heavily T1-weighted gradient-echo pulse sequence at 1 mm isotropic resolution, obtained before and after administration of intravenous gadolinium, and a T2/FLAIRweighted gradient-echo pulse sequence.
Automated Tumor Segmentations A segmentation model was trained following a leave-one-hospital-out cross-validation strategy over the 1596 MRI volumes featured in our dataset, using the AGUNet architecture  [50]. The model was trained from scratch, using the Dice Loss as cost function  [51]  and an Adam optimizer with an initial learning rate of 1e -3 and stopped after 30 epochs without validation loss improvement. Data augmentation was performed during training to improve generalization, such as random horizontal and vertical flip, rotation, and translation transforms.
Software Module and Standard Report The proposed GSI-RADS software (https://github. com/SINTEFMedtek/GSI-RADS, accessed on 3 June 2021) enables the extraction of the described tumor features from a patient's preoperative MR scan locally. The software has been developed in Python 3 and is compatible for use on Windows 10 (Microsoft Corp. , Redmond, WA, USA), macOS (≥10. 13; Apple Inc. , Cupertino, CA, USA), and Ubuntu Linux 18. 04 (Canonical Group Ltd. , London, UK). A minimalistic GUI is provided to the user for specifying the required parameters and running the process. The input for the software consists of a 3D T1weighted gadolinium-enhanced MRI volume provided as a DICOM sequence or NIfTI format. A manual segmentation of the tumor can be provided by the user (e. g. , NIfTI format); if not, an automatic segmentation will be generated using the trained model.
Participants have applied more than 200 models over the years. Many models were updated versions of previous submissions. As far as we are aware, none of these models has been used to generate tumor characteristics for neurosurgical practice. Therefore, the quest for the best performance in a common dataset by ranking of Dice score is not necessarily representative for clinical practice. In this study, we sought to address whether automation could replace manual labor without compromising validity in terms of tumor features and to make the software readily available for others to use and validate further, both clinically and technically. Future improvements of automated methods can be easily integrated in updated software. A strength of this study is good external validity given the mixture of institutions, scanners, scan protocols, and patients.
Until standardized scan acquisition protocols are implemented in neuro-oncological care  [77] , automated segmentation methods should resolve this practice variation. Another strength is the relatively large dataset for training the automated method. A limitation is that we used manual segmentations from one trained rater per tumor, although this probably represents current practice in neurosurgical reports of tumor characteristics. A practical implication is that standard reports for glioblastoma surgery can now be generated by GSI-RADS. Obviously, improved patient outcomes cannot be expected from better reporting in itself. Indirectly, improved outcomes may result from more accurate data-driven decisions on the use of preoperative techniques such as DTI-based tractography, functional MRI, transcranial stimulation, and intraoperative stimulation mapping.
Conclusions Automated segmentations are in excellent agreement with manual segmentations and are practically equivalent regarding tumor features that are potentially relevant for neurosurgical purposes. A standard GSI-RADS report is proposed for these tumor features, including the laterality, volume, multifocality, location, and resectability (https://github. com/SINTEFMedtek/GSI-RADS, accessed on 3 June 2021).
Data Availability Statement: The manual segmentation data can be found as a publicly archived dataset (https://doi. org/10. 17026/dans-xam-j5aw, accessed on 3 June 2021). The data and code for analysis can be found as a public archive (https://gitlab. com/picture/gsi-rads, accessed on 3 June 2021). The open access software can be found as a public archive (https://github. com/ SINTEFMedtek/GSI-RADS, accessed on 3 June 2021).
Experimental Setup The experiment took place using a fixed-base driving simulator that was run using SCANeR Studio TM software (AVSimulation, France). This driving simulator provides visibility of 120 • thanks to three screens (see Figure  3A ). During the simulation, the participants were informed that the vehicle was fully automated and that they did not need to use the controls. In order to record physiological responses during the simulation, the participants' skin conductance was measured according to recommendations of the Society for Psychophysiological Research (Society for Psychophysiological Research Ad Hoc Committee on Electrodermal Measures, 2012, p. 6-7). Two electrodes were placed on the distal phalanges of the participants' index and middle fingers on their non-dominant hands.
To improve the skin-electrode electrical conductivity and the accuracy of the data collection, the electrodes were covered with isotonic gel. No skin preparation was done before the electrodes were placed. Data recording began at least 5 min after establishing electrode-skin contact to create better electrical contact and stabilize the baseline (that is, the skin conductance level). The data were collected at 625 Hz on a dedicated computer using the software AcqKnowledge 5. 0 (BIOPAC Systems, Inc. , USA), which was coupled with an acquisition module (16 bits analogue to digital converter; MP160 system, Systems, Inc. , USA). To enable the participants to assess perceived risk throughout the simulation, an analogue device (a potentiometer that was connected to an Arduino TM Uno board) was developed for onehanded use, which is illustrated in Figure  3B.
Skin Conductance Response The data were initially processed using the software program AcqKnowledge 5. 0 (BIOPAC Systems, Inc. , USA); MATLAB (MATLAB, 2018) and R (R Core Team, 2020) were then used to extract the indicators. Several manipulations had to be conducted to calculate the indicators. First, the raw data were pre-processed using AcqKnowledge according to the recommendations made by  Braithwaite et al. (2013)  and  Findlay (2017). These included resampling at 78 Hz, moving median smoothing at 1 s and low-pass filtering at 1 Hz. The pre-processed data were then analyzed using the Ledalab application, specifically Version 3. 4. 8 from  Benedek and Kaernbach (2010). This application is a MATLAB toolbox that was designed for isolating the tonic and phasic components of EDA. The method used was based on the following two steps: 1.
For all node distributions, the parameters were estimated using the R software. More specifically, as in the method presented by  Denis and Scutari (2015) , the parameters of the factors TTC and offset were set as the actual frequency in the experiment (cf. Table  1 ), and the parameters of the Gaussian distribution were estimated by fitting linear models. The parameters of the compound Poisson distribution were estimated using the R package cplm  (Zhang, 2013). Following the method presented by  Denis and Scutari (2015) , when a factor influenced a dependent node's (SA or SCR) distribution, the parameters were estimated for each value of the factor. For instance, eight parameters were estimated for the distribution of a Gaussian node that was influenced exclusively by the factor TTC (i. e.
With the increasing popularity of long-read technologies, public databases now contain a large collection of very contiguous assemblies, but even if the overall reported quality seems sufficient, local errors can critically affect protein prediction  (10). Aware of this issue, the bioinformatic community has developed several tools over the past two years  (11) (12) (13) (14) (15). Most of the tools (Pilon, Racon, NextPolish, HyPo and POLCA) are based on short-read alignment , ntEdit is the only method that uses a kmer approach and NextPolish combines both strategies (Table  1 ). After aligning the short reads, the algorithms detect errors by examining the pileup of bases from the reads (Pilon, NextPolish), by generating a consensus using Partial Order Alignment (Racon, HyPo) or by detecting variants (POLCA).
Usage and parallelisation of Hapo-G The polishing step of Hapo-G is wrapped in a python script which manages the pre and post processing steps. First, the wrapper indexes the genome and maps the short reads on the draft assembly using bwa mem. The polishing step, written in C using the htslib, is not multithreaded but can be easily parallelized by splitting the input fasta file as well as the alignment file. This divide and conquer strategy makes it possible to speed up the polishing step, and allows to take advantage of a wide range of computing architectures.