dataesr/scientific-paragraphs-categorization huggingface dataset:
MBE has been supported by a broad set of tools that are available to achieve a proper level of automation using transformation tools, such as Xtend  [45]  and Acceleo  [46]. Model transformations are the heart of MBE  [44]. Model transformations are a well-accepted approach that aids software engineers in establishing correspondences between models  [47]. It consists of a program, often written in a declarative manner, that transforms an input model in an output model  [44]. MBE can be exploited to generate stimuli generators. Next section details our approach.
SoS software architecture specificities and precision, including environment modeling Table  1  summarizes the comparison between potential formalisms to support SoS software architecture representation, simulation, and stimuli generator derivation. We decided to search for a software architecture notation, an ADL or modeling notation, that could support all the concepts necessary to represent SoS and that could be simulated. The following modeling languages have been identified as the key ones used for SoS architecture description: Darwin (semi-formal)  [50] , Wright (formal)  [51] , π-ADL (formal)  [52] , UML 2 (semi-formal), SySML 3 (semi-formal), and SoSADL  [8]   [49]. Wright and Darwin were not designed to model SoS architectures. The aforementioned requirements are not covered as these ADL were created to model monolithic systems.
SysML was the backbone of two European Table  1  Comparison between formalisms for SoS simulation and software architecture specification considering the aforementioned language requirements projects (COMPASS 4 and DANSE 5 ) for which they developed extensions for SoSs. DANSE did not develop an ADL, but used SysML for semi-formally describe executable architectures that are then tested against contracts. However, SysML is a UML Profile, and not necessarily an ADL. Moreover, the adoption of SysML to model SoS would require multiple models, each one being simulated individually, and the simulations being interoperated, what is costly. Then, SysML does match our approach requirements, and despite being adopted for software architecture modeling, is not strictly an ADL. UML shares the same drawbacks.
COMPASS developed a formal approach, in contrast to DANSE that extended a semi-formal one. In COM-PASS, CML was specifically designed for SoS modeling and analysis. However, CML is not an ADL. It is a contract-based formal specification language to complement SysML: SysML is used to model the constituent systems and interfaces among them in a SoS, and CML is used to enrich these specifications with contracts. A CML model is defined as a collection of process definitions (based on CSP/Circus), which encapsulate state and operations written in VDM as well as interactions via synchronous communications. CML is a low-level formal language, of which a key drawback is that SysML models when mapped to CML results in huge unintelligible descriptions (it was one of the lessons learned from COMPASS)  [8].
Finally, π-ADL is a formal language to model distributed architectures. However, despite π -ADL providing architectural description models for concurrent and communication processes, it does not provide straightforward abstractions for some SoS' particular concepts, such as mediator, coalition, and environment modeling, and it does not support modeling of abstract architectures and simulations. SoSADL is more expressive than π -ADL for the description of SoS software architectures, with additional elements, such as gates, duties, guarantees, properties, and mediators. In SoSADL, architectural descriptions are intentional and abstract, whereas in π-ADL, such descriptions are declarative and concrete. In addition, from a formal point of view, SoSADL includes other formalisms besides the π-calculus, which is the only one that π-ADL possesses.
Hence, only SoSADL matched the majority of requirements we raised. SoSADL is a language formally founded on π-calculus for SoS, a novel process calculus extended from original π-calculus, conceived for enabling the formal architecture description of software-intensive SoS. It can be considered correct by construction, as the formal semantics of such calculus is defined by means of a formal transition system, expressed as labeled transition rules, which are formulated as proof rules  [53]. In short, SoSADL describes SoS, which can be expressed as a combination of architecture, systems, and mediators declarations 6. Each architecture declaration is expressed in terms of its intrinsic behavior, data types, and gates, i. e. , abstractions that enable the establishment of connections. A connection is established to receive stimulus from or act on the environment, or to simply communicate with other constituents.
SosADL holds the environment description, whilst a simulation formalism run the stimuli generators created. Simulation formalisms (or notations subject to simulation) such as Simulink/MATLAB 8 , Executable UML  [54] , or SySML 9 do not support any one of the aforementioned requirements. Even if such formalisms could represent SoS constituents by means of multiple models, each one representing one individual constituent; hence, simulating them would require interoperability between individual simulations (known as distributed simulations), which demands further adaptations and costly implementations. DEVS, in turn, was developed specially to represent SoS architectures. Hence, we chose DEVS as the formalism to simulate our SoS software architectures. However, even DEVS lacks important characteristics for expressing SoS software architectures, such as (i) the language only deals with the notion of ports; there is no notion of connections and gates separately that is a remarkable paradigm of software architectures (Components, Connections, and Values/Constraints define a software architecture  [48, 55] ) used by SoS modeling  [56] , (ii) in DEVS, every major entity of an architecture is represented as the same type of model (called atomic model).
Even though DEVS supports dynamic reconfiguration, i. e. , the modeling and simulation of architectures of SoS that adapt themselves at runtime, the language still lacks support for abstract architectures, thus requiring all constituents that take part in the simulation to be known. Therefore, it is not allowed for a new constituent, i. e. , a constituent that has not been predicted at design time, to join the coalition at runtime. We thus harmonize both formalisms SoSADL and DEVS, by means of a model transformation (SoSADL2DEVS), to automatically derive the stimuli generators from the SoS software architectural descriptions documented in SoSADL. Figure  1  illustrates how the transformation is carried out. A SoSADL model is Fig. 1  SoSADL2DEVS transformation  [77]  used as input to an Xtend script that materializes a model transformer.
In our approach, there is an Xtend script that materializes the Code Generator. A functional code written in DEVS is generated as output, establishing a SoSADL2DEVS transformation. Considering a broad view of the transformation, the concepts of system and mediator in SoSADL are transformed into atomic models in DEVS. Behaviors are materialized into labeled state diagrams in DEVS that configures the constituents operations. Architecture, coalition, and SoS become coupled models. Connections and gates become ports, and data types and functions are mapped, respectively, in data types and functions in DEVS.
Model transformation All SoSADL elements must be mapped to DEVS to create a functional simulation. In SoSADL, there is a special type of connection called environment, which abstracts interaction of a SoS with the surrounding environment, emitting outputs to the environment, or receiving stimuli from it, e. g. , when the system is a sensor. However, there are no straightforward elements in DEVS to automatically produce environment stimuli. Thus, it is necessary to create a stimuli generator that delivers the expected inputs the constituents wait to perform transitions and to start their execution. Listing 1 shows an excerpt of a code in SoSADL that depicts part of the specification of one constituent: in this case, a sensor Additional file 1. Some parts are hidden because they do not influence in the derivation of stimuli generation.
These state transitions are assembled in sequence to form an entire state diagram that will drive the stimuli generator operation. Then, each state transition will deliver one of the expected data to the correspondent constituent whose architectural specification model was used to create that stimuli generator. Each stimuli generator is associated to a data flow that receives data from a textual file. That file holds the data that feeds the constituent. Then, these data are read from the text file and sent to the constituent, triggering the simulation to run. This happens in a periodic and constant rhythm so as to keep the simulation running. The following steps are followed by the transformation chain that produces stimuli generators: Listings available externally 11 show and bring explanations about the Xtend code that materializes the model transformation.
Data preparation We obtained data collected by the sensors that are under supervision of a Brazilian entity responsible for monitoring natural disasters (Brazilian Center for Monitoring and Warnings of Natural Disasters -CEMADEN)  [59]. These data were parsed and stored in a text file. Stimuli generator are fed with them, emitting them to the simulation, stimulating it until the end of the execution. The input of data triggers the constituents operation, cause their interoperability, reach the gateway, are processed creating new data that correspond to positive or negative flood alerts. We also collect these data to analyze results. We chose a large sample of data collected by the real FMSoS from November 23, 2015, to December 31, 2015. This interval was important because during these months a number of floods occurred.
This enabled us to establish whether or not our simulation results in a diversity of situations. We sent 1000 samples for each sensor, being sent every 5 min, and 1000 for crowdsourcing systems. Considering that we only had data to feed sensors in a simulation, we adapted them so to have similar data for stimuli generators for crowdsourcing systems and drones. For crowdsourcing systems, the aforementioned scale was used to classify risk between 0 and 6. So we could simulate how people would react and behave due to the changes in water level registered before by sensors. Then, we created a dataset correspondent to the data used to feed sensors. This dataset is available externally 17. For drones, we used 5000 drone data, since the drone receives every 500 m a measurement and 2500 m flown every 5 min, totaling this amount for the entire days that we consider in our sample.
SoS software architecture specification The specification of the software architectural description of the FMSoS was conceived as a joint work between SofTware ARchitecture Team (START/ICMC) at University of São Paulo and ArchWare (IRISA) at University of South Britanny, in France. Such specification was conducted by a team of four people using SoSADL language. This step was accomplished after 2 months of work and received four iterations to perform refinements on the SoSADL syntax, to cover some gaps that were not identified before and to refine the software architectural description itself until reaching an acceptable format. We specified an FMSoS architecture with 42 sensors, 9 crowdsourcing systems, and 18 drones, as described in Fig. 3. Such specification was validated by a peer-review procedure composed by the SoSADL creator and other SoS experts.
Inclusion of stimuli generators in the target simulation model After the automatic derivation, the stimuli generator must be deployed in the simulation code specified in DEVS and already deployed in MS4ME environment. This step consists of moving the stimuli generator file to the simulation project in MS4ME environment. MS4ME environment automatically generates a Java file that corresponds to the execution entity of each stimuli generator. The SoS architectural description in DEVS is also adapted to include stimuli generators and to specify that they must emit data to their corresponding constituents, that is, those that hold environment connections that were used as input to produce the respective stimuli generators. Figure  3  illustrates an example of FMSoS architecture during simulation.
Simulation execution and monitoring The simulation took for 6 h and 20 min (6. 20 h) in Processor Intel core i5-3230M 2. 60 GHz (×64), with 4 GB of RAM Memory, HD of 1 TB, and running Ubuntu 16. 04 64 bits. The data corresponds to 38 days of monitoring data from the Monjolinho River. Data were stored in text files and delivered by the stimuli generators along the FMSoS, feeding the simulation. This step was evaluated according to the metrics established in research questions two and three (efficiency and number of problems during simulation execution). We established a four-window strategy implemented at the gateways that receive data from constituents to confirm floods. For each four data that subsequently arrives, the gateway checks it by pairs (three possible combination of pairs of four data that arrives).
If at least one pair that arrived have both their depth levels equals to or major than 100 cm (the threshold established for that city), a flood alarm is triggered. Experts remarked that one sensor could trigger a false alarm due to the possibility of sediment accumulation, which can increase the measured collected in a location, but that does not represent a flood. Hence, taking pairs was considered a valid strategy. Table  2  illustrates an example. It corresponds to real data that arrived sequentially at the gateway. Each four data that arrive are chronologically ordered, and pairs of data given by (S2,S3), (S1,S3), and (S3,S4) are analyzed. If at least one of the pairs has two measures equal or greater than 100 cm, a flood is confirmed. We did allow the sum of four measures that generate false alarms (for example, S1 = 90 cm, S2 = 90 cm, S3 = 90 cm, S4 = 130 cm).
Next, we discuss the answers to the research questions. Yes. The stimuli generators were analyzed by a specialist that agreed that it contains all necessary structures to deliver the expected behavior. Moreover, we observed their behavior during the simulation execution, and the data that arrived in the gateways. Of the data, 100% were correctly delivered to the simulation. RQ2: Are the stimuli generators capable of triggering a simulation correctly? Yes. We followed the entire cycle of operation of the simulation. The stimuli generators were capable of receiving the input data from the database and generating the expected stimuli for the constituents, triggering the SoS interoperability. Hence, the stimuli generator was well succeeded. Three types of stimuli generators were derived from the specifications in SoSADL, as available externally 21.
Related work Recent studies have investigated the adoption of simulation in software engineering  [63] , and simulation has certainly been applied for SoS development  [16, 36, 64]. Additionally, initiatives have invested in the simulation of software architectures, but not specifically for software architectures of SoS, such as SySML  [65] , MatLab/Simulink  [66] , Palladio 22 [67], Bogado et al. [36] , and Alexander et al. [68]. Other initiatives invested in modeling and simulating SoS, but with no support for software architecture concept  [15]. The development of stimuli generators for simulation purposes is not a new trend  [35, 37, 38]. Initiatives have investigated the adoption of stimuli generators for hardware benchmarking. For example, Al-Hashimi  [37]  describes the use of stimuli generators to produce digital input signals for simulation purposes of analogic-digital systems.
Kewley et al. claim that constituents should be simulated by isolated simulations and that such simulations should be federated, that is, they should interoperate in a synergistic way to form the whole simulation of a SoS  [69]. They adopt a framework called SySHub to play the role of glue that enables federations of models to support SoS simulation. However, they do not work on the level of software architecture (simulation or representation), despite the fact that they consider distributed interactive simulation (DIS) and high-level architecture (HLA) as potential architectural and interoperability methods for description and federated simulations of SoS  [71]. However, even these notations do not tackle the concepts we address in our approach related to software architecture. They consider environment modeling as a potential forthcoming contribution of the SySHub system.
However, we did not find continuity at this research topic or more recent papers that report supporting environmental modeling in SySHub context. Therefore, automatic derivation of stimuli generator is not currently covered in that approach. Soyez et al. propose an agent-based tool to support modeling of static and dynamic aspects of SoS  [70]. Their formalism is based on the multi-level agent-based model IRM4MLS, which allows the representation of multiple entities that can interoperate at different levels, i. e. , a constituent can be itself an SoS, hence supporting different levels of granularity  [72]. To evaluate their approach, they implemented a co-simulation of a directed SoS coping with a reconfiguration problem in the domain of intelligent autonomous vehicles. Despite the use of cosimulation, they do not provide any evidence of concerns with the notion of software architecture, nor automatic code generation or stimuli generators.
Currently, this type of data is collected from other sources, and inserted via Java code into the body of the stimulus generator. Nonetheless, there is an important contribution towards environmental modeling in SoS engineering. In this stage of the contribution, we automatically create a virtual entity for the simulation capable of delivering the data in a rhythmic rhythm, imitating the surrounding environment from the data provided to the stimulus generator to feed the simulation. In a next step, we intend to invest in the automatic creation of these data by a more accurate description of the environment. The next section brings final remarks and potential for future research.
Final remarks and forthcoming steps This article presented Stimuli-SoS, an approach to systematically and automatically derive stimuli generators to support the execution of simulation of SoS. We established the following research question to be answered: How is it possible to automatically obtain a functional stimuli generator that reproduces environmental conditions to the simulation of a SoS? We concluded that the stimuli generators automatically created: 1. conform with the expected format. The transformation derived is what was expected; 2. were capable of receiving input data from the database and generating expected stimuli for the constituents, triggering the SoS; 3. were capable of correctly supporting an entire simulation execution; and 4. reproduce the environmental conditions of an SoS to become simulations functional without manual intervention.
X-ray analysis-CXO We obtained four epochs of deep X-ray observations of ASASSN-15lh with the Chandra X-ray Observatory (CXO) on November 12, 2015 (exposure of 10 ks),  December 13, 2015 (10 ks), February 20, 2016 (40 ks)  and  August 19, 2016 (30 ks, PI Margutti) , corresponding to δt=129. 4 days, δt=154. 6 days, δt=210. 5 and δt=357. 8 days rest frame since optical maximum light, which occurred on June 5, 2015  (Dong et al. 2016). CXO data have been reduced with the CIAO software package (version 4. 8) and corresponding calibration files. Standard ACIS data filtering has been applied. ASASSN-15lh is not detected in our first epoch of observations (ID 17879), with a 3σ count-rate upper limit of 9. 98 × 10 -5 c s -1 (0. 5-8 keV). The Galactic column density in the direction of the transient is 3.
2 days rest-frame since maximum light), six days after our first CXO epoch, which yielded a non-detection. From the XMM-Newton observations  Leloudas et al. (2016)  infer a 95% confidence level flux limit F x < 2 × 10 -16 erg s -1 cm -2 (0. 3-1 keV). We do not confirm the results from  Leloudas et al. (2016). Adopting their inferred count-rate limit of 11 source counts in 9 ks of exposure time with EPIC-MOS2, their assumed blackbody spectrum with T = 18 eV, and following the flux calibration procedure outlined in  Leloudas et al. (2016) , we infer a flux limit which is ∼ 100 times larger. We re-analyzed the XMM data using standard routines in the Scientific Analysis System (SAS version 15. 0. 0) and the relative calibration files. We employ a source region of 32 radius and extract the background from a source-free region on the same chip.
• 3, which was close to the parallactic angle  (Filippenko 1982). This setup covered the range 3800-10500 Å with a resolution of 8. 1 Å. Standard IRAF 16  tasks were used to perform two-dimensional image processing. We used custom IDL scripts to perform flux calibration and correction for telluric absorption using observations of EG131 obtained immediately prior to the object. We took particular care to mitigate the effects of second-order light contamination by combining observations of the standard star taken both with and without an order-blocking filter. However, small residual contamination at long wavelengths (λ>8000 Å) is possible. The resulting spectrum is shown in black in Figure  5. Numerous stellar absorption features from star light in the host galaxy are visible, as well as two emission peaks near Hα (observed wavelengths ∼8100 Å).
BDM gratefully acknowledges support from the NSF (AST-1410950, AST-1615084), NASA Astrophysics Theory Program (NNX16AB30G), the Alfred P. Sloan Foundation, and the Research Corporation for Science Advancement. G. M. acknowledges the financial support from the UnivEarthS Labex programof Sorbonne Paris Cite (ANR10LABX0023 and ANR11IDEX000502). The scientific results reported in this article are based on observations made by the Chandra Xray Observatory under program GO 17500103,  PI Margutti, observations IDs 17879, 17880, 17881, 17882. This paper includes data gathered with the 6. 5 meter Magellan Telescopes located at Las Campanas Observatory, Chile. Facilities: Magellan:Clay.
Introduction By their ability to gather multiple physics from plasma transport, neutral physics to plasma wall interaction, transport codes remain key tools to interpret experiments and extrapolate observations to future machine like ITER or DEMO. In that perspective, a dedicated effort has been paid in the last few years to develop the code SOLEDGE2D-EIRENE  [1]  focusing on treating the plasma wall interaction with all the plasma facing components including the first wall. This contribution describes recent progress to include the effect of transport due to drifts velocities. Besides, solving drifts velocities also requires revisiting perpendicular momentum balance in order to derive an equation for the electric potential. Inclusion of drifts in transport codes  [2, 3, 4, 5]  is often reported as being challenging and we find appropriate giving motivations and justifications for the model we use to solve electric potential (currents) equation.
Acknowledgements This work was granted access to the  HPC resources of Aix-Marseille Université  financed by the project  Equip@Meso  ( ANR-10-EQPX-29-01 ) of the program " Investissements d'Avenir " supervised by the  Agence Nationale pour la Recherche. This project has received funding from the Figure 4: ExB velocity field in Forward and Reverse B configuration. European Union's  Horizon 2020 research and innovation programme  under grant agreement number  633053. The views and opinions expressed herein do not necessarily reflect those of the European Commision.