dataesr/scientific-paragraphs-categorization huggingface dataset:
The divertor plasma behaviour and VT heat loading in different operating conditions have been extensively studied during the past years using the SOLPS4. 3 code package, see e. g. [10]  for burning plasma conditions and  [11]  for lower power operation. Conversely, for the RPs the only detailed study carried out so far has focussed on the heat loading from photons in a highly radiative divertor  [12] , showing that the maximum heat flux on the plates is typically lower than 1 MW m -2. However, during tokamak operation, the strike points can move from their baseline location due to inaccuracies in the control of the vertical plasma position or may need to be permanently displaced in order to avoid damaged regions of the targets. As shown in a previous analysis with the SOLPS-4. 2 code  [13] , upward displacements may be problematic due to weaker pumping, whilst downward movements, if they are sufficiently large, could even result in strike point excursions onto the RP, particularly at the inner divertor.
SOLPS-ITER simulation setup The SOLPS-ITER code suite  [15, 16] , comprising the B2. 5 plasma fluid code and the EIRENE Monte Carlo neutral kinetic code, has been adopted to perform the steady-state plasma-edge simulations reported here. SOLPS-ITER is the successor to the SOLPS4. 3 package used extensively to guide the design of the ITER divertor. The main differences between their physics and numerical models, as described in  [15, 17] , are in the plasma solver, with SOLPS-ITER adopting the most recent version B2. 5 which includes drifts and currents, and the most recent version of the Monte Carlo EIRENE code for the neutral transport, with a wide set of neutral-neutral collisions. The two codes were benchmarked against each other in  [15] , showing good general agreement but with some deviations in the cases at higher power and low throughput, where SOLPS-ITER predicts up to a factor 2 higher heat flux density at the outer target.
3 T. This is the baseline Type I ELMing H-mode scenario, established by decades of tokamak R&D within the ITER partners and on the basis of which the ITER confinement time scaling was derived  [19]. Deuterium (D) gas puffing at 1. 14 × 10 23 s -1 (corresponding to pumping speed of ~38 m 3 s -1 , since puffing and pumping are balanced in these steady state simulations) gives a subdivertor neutral pressure of ~6 Pa. Extrinsic seeding of Ne is added for detachment control. In the simulations, both fuel and impurity are introduced from a puffing slot at the top of the main chamber (see figure  2 ). This gas puffing location has been chosen consistently with that adopted so far in the ITER SOLPS database. Unpublished studies have demonstrated that the choice of gas introduction position has no impact on the results of steady state modelling, as performed here.
The outflow of the inner monoblocks is fed to the IRP hypervapotron channels, with the inlet near the corner with the VT and the outlet towards the dome, which is the next component in the loop, passing through the SS supporting tubes. Finally, the outlet of the dome is connected to the inlet of the outer RP having a flow direction from the dome towards the outer VT. A simplified model of the PFCs has been developed here based on FreeFEM++  [32] , an open-source software package for 2D/3D finite element computations. The package includes a mesh generator and allows the choice among a wide range of finite elements, integrated linear solvers and visualization tools. The simplified model developed has been made  Beginning with the VT monoblocks, the first simplifying assumption made is to split the 3D problem into a series of 2D problems on the monoblock cross-section (figure  6 ), along the poloidal direction (see figure  7 ); on each section the heat diffusion in the solid is studied and the presence of the coolant is considered only as a boundary condition for the 2D conduction problem, i.
In the poloidal direction (figure  7 (b)), the surface heat flux density, q ⊥ , is assumed to be constant on any given discrete poloidal element. Toroidally, the top surface bevel introduces magnetically shadowed and plasma wetted regions (figure  6 ). Photonic radiation and neutral particles will contribute to the heat load across the whole toroidal extent, but the charged particle loads occur only on the plasma wetted portion (red line in figure  6 ). These latter loads are dominant in anything but the most detached conditions. As mentioned earlier, the thermal plasma loads obtained from the SOLPS-ITER code must also be corrected for the VT tilt angle, α, and the monoblock toroidal bevel angle, β, so that along the toroidal surface of each monoblock, q ⊥ varies according to: q ⊥ = ® q neutr + q rad for non wetted areas q ⊥,plasma + q neutr + q rad for wetted areas.
Conclusions The ITER divertor plasma performance has been studied for the first time in conditions in which magnetic equilibrium displacements place the strike points near or onto the divertor reflector plates as a consequence of an off-normal transient or as the result of a deliberate requirement. The SOLPS-ITER code in its coupled fluid plasma-kinetic neutral version has been adopted to perform a parametric study in which a baseline ITER scenario at Q DT = 10 and partially detached divertor conditions has been used as a starting point to obtain, through rigid downward equilibrium displacements, a series of steady-state solutions with different strike point positions up to the limit at which the inner dome wing intercepts the inboard divertor leg separatrix. The inner strike point falls on the reflector plate well before this limit while the outer strike point always remains on the vertical target.
As shown in  [6] , if λ q were to be reduced further below the ~2 mm value adopted in this study (through the choice of lower perpendicular heat diffusivity), the power dissipated through radiation (mainly from impurities) in the near SOL would increase, driven by the increased density. Partially detached conditions can thus still be achieved and similar heat flux densities can be reached on the targets, albeit at the price of higher upstream density. A simplified 2D finite element heat transfer model, successfully benchmarked against a 3D ANSYS model in the case of the vertical target monoblocks, has been developed here for the ITER divertor components and is now included in the SOLPS-ITER code suite. It permits a rapid estimation of the thermal response of the vertical targets and reflector plates (each using different cooling techniques) under different operating scenarios and now allows routine estimates for the vertical plate surface temperature distributions from within the SOLPS-ITER code, without recourse to the more complex and time-consuming 3D simulations typically used in engineering studies.
Acknowledgments The views and opinions expressed herein do not necessarily reflect those of the  ITER Organization. ITER is the nuclear facility INB 174. The study reported in this paper was started when the first author, at that time a PhD student in the NEMO group at the  Politecnico di Torino , was seconded to the  ITER International Organization , before he moved to his current position at  KU Leuven , where the work was completed.
Within this paper, we intend to address this issue via the following contributions: 1. A model-based architecture for XaaS modeling in order to support generic autonomic management; • Including the connection with a constraint solver (Choco  (Jussien et al. , 2008) ) and a partial mapping to/from a Cloud standard (TOSCA) for interoperability with external solutions; 2. A related XaaS core modeling language, possibly supporting any of the possible Cloud layers; 3. An Eclipse-based tooling support, that has been applied on a realistic multi-layer Cloud system. The paper is structured as follows. In Section 2, we introduce the general context and objectives of our approach. In Section 3, we illustrate and motivate further our work via a practical use case. Then, in Section 4, we present the overall model-based architecture we propose, including its relation with the Choco constraint solver and mapping to/from the TO-SCA Cloud standard.
As a consequence, the application should be able to adapt itself by adjusting the required compute capacity. The objective is to keep the service response time at acceptable levels as defined in related SLA contracts. An overview of this use case is depicted in Figure  2. Students, as the main end-users of the offered Elearning facilities, are the clients of a Software-as-a-Service (SaaS) provider. At the upper level, this SaaS provides a Cloud-based version of the Moodle learning management system 3  , i. e. , an elastic Moodle. The SaaS provider is a Infrastructure-as-a-Service (IaaS) client, i. e. , it needs compute resources in order to run the E-learning services. Thus, at the lower level, a IaaS provides the required services by means of available VMs. The datacenters of the IaaS provider need electrical power in order to be able to operate.
A Constraint Solver for an Automomic Loop As introduced before, the proposed architecture integrates the use of a constraint solver (Choco  (Jussien et al. , 2008)  in our case) in order to realize the decision-making of the autonomic loop allowing to automatically compute system re-configurations. A corresponding CP requires three different elements to find a solution (i. e. , in our case a new configuration): a fixed set of problem variables, a domain function (associating each variable to a domain) and a set of constraints. Our XaaS architecture and its two metamodels allow expressing these elements as required by the constraint model we currently rely on (provided to us by  (Lejeune et al. , 2017) ). From a Topology model, the implementation code is automatically generated for the various node and relationship types.
We started from this syntax and complemented it with our language-specific elements, notably concerning expressions and constraints as not supported in YAML (cf. Section 5. 1). We also ignored some constructs from TOSCA YAML that are not required in our language (e. g. , related to interfaces, requirements or capabilities). We can still rely on other existing notations via our XaaS-TOSCA bridge (cf. Section 4. 2). For instance, by translating a configuration definition from our language to TOSCA, users can benefit from the GUI offered by external tooling such as Eclipse Winery (Eclipse Foundation, 2017). We show below how the Cloud experts and administrators can write the IaaS layer of the motivating example from Section 3. Listing 1: Topology excerpt from our motivating example (IaaS level).
Implementation The proposed model-based architecture has been designed to be deployed by Cloud experts and administrators in any context requiring some Cloud modeling (e. g. , independently from the autonomic aspects). To this intent, they come with a corresponding tooling support. Based on our own experience and the rich available ecosystem, we decided to work on developing tooling based on Eclipse/EMF  (Steinberg et al. , 2008)  for our architecture and corresponding XaaS language. This choice was reinforced by the fact that the Choco constraint solver  (Jussien et al. , 2008) , a reference solver in the Constraint community (and for which we have access to a solid expert), has a compatible Java API. All the corresponding source code is available from a Git repository 6. As it can be seen from Figure  6 , we made the choice of using our language as the core representation in our approach.
The abstract syntax of our XaaS language has been defined via an Ecore  (meta)model  (Steinberg et al. , 2008) , while its concrete syntax has been defined via an Xtext grammar  (Bettini, 2016). Thanks to Xtext, we have also been able to produce a dedicated editor coming with useful features such as syntax highlighting, code completion, static checks, etc (cf. Figure  7 ). The connection with the constraint solver has been implemented via corresponding code generator, in Xtend (Bettini, 2016), from our language to 1) the Java API provided by Choco and 2) the XML format currently expected by the CP program. In addition to this language and constraint support, we developed the required ATL  (Jouault and Kurtev, 2005)  model-to-model transformations so that our XaaS models can be partially transformed into TO-SCA ones (and vice-versa).
Application on our Motivating Example As a validation of the proposed technical solution, the presented Eclipse tooling has been deployed based on our motivating example (cf. Section 3). A complete video-demonstration of this application is available online 7. It shows 1) the design of the SaaS layer with our XaaS modeling language, 2) the interoperability between the obtained XaaS models and a TOSCA-based tool (Eclipse Winery (Eclipse Foundation, 2017)) and 3) an illustration of a given adaptation, i. e. a reconfiguration, via our decision-making architecture (based on the Choco solver). In the scenario from the video-demo, the modeled system (more precisely its SaaS-level) evolves from a current state to another one, both represented as configuration models in our language. In the initial configuration model, described graphically in Figure  8 , a client WebApp is connected to a single instance of the Moodle application.
APIs enable IaaS provider abstraction, therefore easing the control of many different Cloud services, and generally focus on the IaaS client side. DevOps tools, in turn, provide scripting language and execution platforms for configuration management. They rather provide support for the automation of the configuration, deployment and installation of Cloud systems in a programmatical/imperative manner. The Cloudify 12  platform overcomes some of these limitations. It relies on a variant of the TOSCA standard (OASIS, 2017) to facilitate the definition of Cloud system topologies and configurations, as well as to automate their deployment and monitoring. In the same vein, Apache Brooklyn 13  leverages Autonomic Computing  (Kephart and Chess, 2003)  to provide support for runtime management (via sensors/actuators allowing for dynamically monitoring and changing the application when needed).
However, both Cloudify and Brooklyn focus on the application/client layer and are not easily applicable to all XaaS layers. Moreover, while Brooklyn is very handy for particular types of adaptation (e. g. , imperative eventcondition-action ones), it may be limited to handle adaptation within larger architectures (i. e. , considering many components/services and more complex constraints). Our approach, instead, follows a declarative and holistic approach which is more appropriated for this kind of context. The European project 4CaaSt proposed the Blueprint Templates abstract language  (Nguyen et al. , 2011)  to describe Cloud services over multiple PaaS-/IaaS providers. The Cloud Application Modeling Language  (Bergmayr et al. , 2014)  studied in the AR-TIST EU project  (Menychtas et al. , 2014)  suggests using profiled UML to model (and later deploy) Cloud applications regardless of their underlying infrastructure.
, 2009). In the PaaSage EU project  (Rossini, 2015) , CAMEL  (Achilleos et al. , 2015)  extended CloudML and integrated other languages such as the Scalability Rule Language (SRL)  (Domaschka et al. , 2014). The framework Saloon  (Quinton et al. , 2016)  was also developed in this same project, relying on feature models to provide support for automatic Cloud configuration and selection. However, contrary to our generic approach, in these cases the adaptation decisions are delegated to 3rd-parties tools and tailored to specific problems/constraints  (da Silva et al. , 2014). Recently, the ARCADIA EU project proposed a framework to cope with highly adaptable distributed applications designed as micro-services  (Gouvas et al. , 2016). While in a very early stage and with a different scope than us, it may be interesting to follow this work in the future.
Among other existing   (Nguyen et al. , 2011)  ARTIST-CAML  (Bergmayr et al. , 2014)  mOSAIC  (Sandru et al. , 2012 ) ∼ Stratus ML  (Hamdaqa and Tahvildari, 2015)  CloudMF  (Ferry et al. , 2013; Ferry et al. , 2014)  ∼ PaaSage-CAML  (Achilleos et al. , 2015)  ∼ SRL  (Domaschka et al. , 2014)  ∼ Saloon  (Quinton et al. , 2016)  ARCADIA  (Gouvas et al. , 2016)  ∼ Descartes  (Kounev et al. , 2016)  MODAClouds  (Pop et al. , 2016)  (García-Galán et al. , 2014) CoMe4ACloud ∼ ∼ approaches, we can cite the Descartes modeling language  (Kounev et al. , 2016)  based on high-level metamodels to describe resources, applications, adaptation policies, etc. A generic control loop is proposed on top of it to fulfill some requirements for qualityof-service and resource management. Quite similarly, Pop et al.
Thus, the defined architecture and modeling language will have to be reevaluated in the light of this new Fog context. We foresee their needed evolution in order to be able to efficiently model and support Fog characteristics such as a higher geographic distribution, the diversity of the involved resources/services, their reliability, etc. Finally, we are aware that specifying constraints for the considered systems and their SLAs can be a difficult and time-consuming activity. Moreover, the quality of the produced contraints highly depends on human knowledge and experience (e. g. , from the Cloud Experts/Administrators). To limit potential errors and improve the efficiency of our approach, it would be interesting to be able to exploit automatically the historical data of the modeled systems.
The objective is to build present, progressive or hypothetical urban scenarios in which we heighten the role of the built environment, and that of political and economic forcing, in the exposure of people to atmospheric pollutants. OLYMPUS is an emission modelling platform based on the simulation of the behavior (mobility, energy consumption) of individuals within an urban space. That is, it considers every single individual and the impact of their daily choices for activities, mobility and energy consumption practices on combustion emissions. In this paper, an overview is made of the characteristic features of the model. The main modules composing OLYMPUS will be presented individually. An application on the Greater Paris will be shown in the last section. The results and uncertainties of the model are discussed.
Main characteristics In its current version, OLYMPUS models the pollutant emissions due to road transport and combustion processes from the residential and tertiary sector. It is composed of 6 calculation modules, supporting 4 main tasks (see Figure  1 ). One first specificity of OLYMPUS is that it relies on a synthetic population for the calculation of emissions and constitutes the first task. (a) This synthetic population is designed to be representative of the population living on the territory considered, and is characterized by the agents' age, gender, principal activity and situation in a household. The creation of such a synthetic population is based on the reconstitution of surveys in the GAIA module. The second task of OLYMPUS is the provision of a road transportation database, calculated by considering individuals' lifestyle.
This database is obtained from successive diagnoses about individual trip generation -based on zonal attractions, travel distribution, modal split and route choice. In the OLYMPUS modelling process, this task relies on 3 modules. (b) A first module (THEMIS) defines the accessibility and attractiveness of the different administrative units of the city, as well as the average time travels between them. (c) The Activity-Based Travel Demand (ABTD) module called MOIRAI computes the daily activity patterns of all agents. It also describes their temporal and spatial daily mobility. (d) The assignment module HERMES provides spatialized daily trips by computing the shortest path between the origin and the destination of a trip (OD matrices). In parallel, OLYMPUS tackles the third task by computing the building energy demand.
(e) For this purpose, the HESTIA module computes the average household energy consumption per square meter, the dwelling size of the household and the energy mix of the city in order to produce a spatialized building energy demand, including a climate correction specific to the simulated period. In the fourth task, OLYMPUS generates emissions from both road transport and small combustion heating systems. (f) Those emissions are calculated using reference methodologies. The computation of pollutant emissions is carried out by the VULCAN module. All the OLYMPUS running scripts are based on a shell interface, programmed in Python 2. 7 and compiled in C for faster execution speed. For graph networks and spatialized data analysis, NetworkX  (Hagberg et al. , 2008) , GeoPandas and NetCDF's libraries have been included to the Python interpreter.
The synthetic population generator (GAIA) The synthetic population generator GAIA is the first OLYMPUS module to be run. It allows the generation of a synthetic population that is representative of a given urban area. The synthetic population generator mainly uses urban-level census data to attribute age, gender and main activity -as well as socio-economics parameters such as the possession of a driver's license -to each agent in this population. The module spatializes this synthetic population through an urban zoning based on household densities in the urban area, an exogenous variable provided to the model. In the end, a synthetic population based on data census or demographic scenarios is obtained, with an individual description of its agents. There are several techniques to estimate a population in a small area based on statistical approaches, as listed in  (Rahman, 2017).
Then, a unique value of this characteristic is assigned to each agent of the population using a random distribution that follows the identified probability law. The approach makes it possible to create (on the basis of a representative sample) a database that distinguishes each individual (disaggregated data) as well as each household and dwelling, by attributing them to their own characteristics. These two methods differ in how to generate the dummy population but the results are admittedly identical. In terms of outputs, one of the major interests of the IPF procedure is its ability to generate greater variability in populations than conditional probabilities. However, the use of this approach in a region such as Ile-de-France requires a significant amount of work to structure the input data.
In parallel, the structure of households varies according to the distance from the urban center, following  (Hulchanski, 2010). These hypotheses provide a larger spatial distribution variability of agents than a simple conditional probability distribution would. The UDI is defined in Eq. (1) This is the result of the classification of the dataset following 3 large sets by applying a linear cut from sparse to very dense areas. It is based on population density and the population is digitized as a function of the population density logarithm.
All these data will be analyzed at a local level called travel analysis zones (TAZ) which may be districts, sub-districts, municipalities or any other city division. The degree of precision of the zones imposes the refinement of population mobility. Urban road transport modelling is organized in 3 steps: (a) Determination of the attractiveness and accessibility of the different zones that constitute the domain. (b) Restitution of the agent movements based on the realization of the programmed activities. (c) Assignment of motorized displacements on the road network.