dataesr/scientific-paragraphs-categorization huggingface dataset:
The level of soil moisture that a plant begins to experience water stress at is reduced by the introduction of the variable p0; this is a scaling factor used in the soil moisture stress calculation  (Williams et al. , 2018). The setting of p0 and how this affects GPP at the First ISLSCP Field Experiment (FIFE) site in Kansas is discussed in detail in  Williams et al. (2018). In addition  Williams et al. (2017)  suggest modifying the p0 parameter to be 0. 65 for the Mead site in Nebraska. In the simulations shown here p0 is set to 0. 5 (see Table  2 ) modified from the default setting of 0, as recommended by  Allen et al. (1998). The way that vegetation in JULES uses water and its response to drought conditions is currently under investigation within the wider 11   6 ). On the basis that p0 has a positive impact on some aspects of the Avignon simulations it is likely that water stress is a factor in the simulations shown here.
B5 ), the leaves senescing and therefore not photosynthesizing and the remobilisation of carbon to the harvest pool (see Fig. 9 ). This early decline in NPP could have a direct impact on yield in the model. Figure  7  shows the yields from JULES (asterisks) overlaid on the curve of the harvest pool (solid lines) for each crop together with two observation datasets. The datasets are from  ICRISAT (2015)  shown by the filled circles and  Ray et al. (2012a)  by filled triangles (see Fig. 7 ) highlight that there is a spread between yield estimates for this region. The model (asterisks on Fig. 7 ) tends to underestimate the wheat yield for most years at the WestUP location (average bias across both datasets of -0. 13 kg m -2 ). Rice is more mixed for WestUP, falling within the range of the observations in more than half of the years (average bias -0.
064 kg m -2 ). The average bias across both observation datasets is much smaller for the other locations with rice and wheat yields within the range of the observations for most years for both EastUP and WestBi (average bias across both crops at these locations ranges from -0. 07 to 0. 02 kg m -2 ). During the second half of the simulation the wheat yield is underestimated by the model more often at EastUP but this is just the occasional year for WestBi and does not occur at all for EastBi. For EastBi the rice yields are often toward the top of the range provided by the two observed datasets but still within the range of the observations (see Fig. 7 ), this gives on average a positive bias of 0. 06 for rice and 0. 02 for wheat. However the observed yields at EastBi are lower than the other locations, where the cooler wetter conditions should be more conducive to achieving higher yields but these are neither observed or modelled.
It would be interesting and useful to follow up this study with further simulations which attempt to account for this missing process, for example, by using alternative driving data that includes irrigation and the subsequent surface evaporation. This would demonstrate if the influence of the evaporation of irrigation water from the surface is a large enough effect to increase the modelled yields for WestUP and maintain the yields for EastBi, where the humidity is usually higher and therefore maybe less influenced by this process. The work presented here has shown that sequential cropping is an important addition to JULES providing a closer representation of the land surface where crops are grown in rotation. Therefore the code modifications presented as part of this analysis, currently in a branch of JULES at vn5.
Acknowledgements. The research leading to these results has received funding from the  European Union Seventh Framework Programme   FP7/2007-2013  under grant agreement no. 603864. Camilla Mathison ,  Pete Falloon ,  Andy Wiltshire  and  Karina Williams  were supported by the  Met Office Hadley Centre Climate Programme  funded by  BEIS and Defra. Thanks also to  Kate Halladay  for helping me understand the soil moisture and irrigation implications. The authors thank the  INRA EMMAH laboratory at Avignon (France)  in charge of the "flux.
Code and data availability. The JULES model code used in this paper is available from the Met Office Science Repository Service: https://code. metoffice. gov. uk/trac on registering. The version of the model used in this analysis is branched from the JULESvn5. 2 trunk code and is therefore an enhanced version of the JULES vn5. 2 code: the specific revision including the modifications used in this paper is @13322 which is available from this link: https://code. metoffice. gov. uk/trac/jules/browser/main/branches/dev/camillamathison/vn5. 2_croprotate_irrigtiles. The developments contained in this branch will hopefully be implemented into the trunk of JULES in the near future. The regional climate model datasets used will hopefully be available via the Centre for Environmental Data Analysis (CEDA) catalogue.
Methodology The first step of the workflow allows to design a virtual representation of the hot rolling mill including selection of devices, their location, and configuration parameters. The VirtRoll system supports this step by providing a virtual workplace with a graphical drag and drop editor of the rolling mill and a toolbox of available configurable devices. The user can select a project already stored in the system database or prepare a new mill design. Moreover, the user can save the work at any given moment and return to it in the future. The second step is the numerical simulation of the rolling process in a parameter study manner. The user prepares a space with parameters including the material description, configuration of devices, and process variables. Briefly, the parameter study includes: • Computational tasks scheduling to high performance computational infrastructures; • On-line progress monitoring of the simulations with capability to adjust computing power or extend the parameter study interactively; • Collecting simulation results and further analysis.
Technology of the System Design The technology used in this paper is based on three main elements: the graphical user interface (GUI) of the VirtRoll system, the middleware in form of the Scalarm platform, as well as the numerical simulations of the rolling/cooling processes. The GUI created as a web-based module facilitates access from different operating systems and devices. Application of modern web technologies, e. g. , AJAX and HTML5, fulfills requirements regarding various operating systems, interactivity, and easiness of use. Information about materials and devices available for the rolling mill designers is stored in the database, see  [1]  for details. In contrast to web-based high-level solutions, the VirtRoll computing module, used to simulate rolling cycles, was developed as a high performance parallel application.
Methodology The first step of the workflow allows to design a virtual representation of the hot rolling mill including selection of devices, their location, and configuration parameters. The VirtRoll system supports this step by providing a virtual workplace with a graphical drag and drop editor of the rolling mill and a toolbox of available configurable devices. The user can select a project already stored in the system database or prepare a new mill design. Moreover, the user can save the work at any given moment and return to it in the future. The second step is the numerical simulation of the rolling process in a parameter study manner. The user prepares a space with parameters including the material description, configuration of devices, and process variables. Briefly, the parameter study includes:.
It was designed to be executed on high performance computing (HPC) systems. As it has been mentioned, the Scalarm platform was applied to ensure interoperability between the VirtRoll web-based module and VirtRoll numerical simulations. Both systems follow the lightweight service-oriented architecture (SOA) approach. They are loosely coupled services, deployed on separated hosts, and exchange information with a RESTful-based API (Application Programming Interface) accessible via the HTTP protocol. Security is an important aspect of such integration and HTTPS are used for secure communication between the user and the system and between the system and the Scalarm. Another aspect of the application security is authentication. The OpenID technology was used to provide the single sign-on functionality and to enable users to use their existing accounts.
• Results collecting and exploration-each simulation returns a set of results describing the process. Scalarm aggregates the results from all the simulations and enables data exploration and visualization with various charts. Scalarm provides two user interfaces i. e. , RESTful API and web-based graphical interface. The former supports the integration of other numerical tools with Scalarm by using the basic command of HTTP protocol. The latter is dedicated to scientists who run simulation codes manually on various infrastructures and would like to facilitate this process. The integration of the VirtRoll system with Scalarm was based on the first of these approaches, which is transparent for end users. The following list describes the most important functionalities delivered by the API for delegation of computing tasks from the client side to actual computational infrastructure: (i) Registration of a simulation scenario; (ii) execution of subsequent experiments; (iii) scheduling of computing tasks, (iv) gathering information about experiment including results; (v) further experiment management.
Database The design of the database was prepared to be flexible, thus object-oriented MongoDB engine was used. This choice was dictated by the necessity of a flexible data model of the process, i. e. , support for new materials and devices characterized by different parameters. The material parameters included in the database compose coefficients in the flow stress models, microstructure evolution models, and phase transformation models and they are combined with the chemical composition of steel. Thermo-physical and thermodynamic parameters are gathered in the database, as well. Details of the database design and all the models describing flow stress, microstructure evolution, and phase transformations are presented in  [1]  and are not repeated here. All the parameterized and validated models were saved in the database.
Inverse analysis for the results of the compression tests was performed for each material in the database (Section 3. 1 and  [18] ) and the coefficients in flow stress models were identified. The inverse algorithm described in  [21]  was applied. Relation between the flow stress (σp) and the average pressure (pav) in rolling has to account for the so called "friction hill" and this relation was described by the metamodel, which follows the concept of Sims  [22] , who introduced parameter Q representing average pressure-to-flow stress ratio (Q = pav/(aσp), where a = 2/ 3 ). The data generated by numerous FE calculations for different reductions (r = (h1 -h2)/h1), roll radii (R) and friction coefficients (μ), were used to find the coefficients in the polynomial function Q = f(r,R,μ). Sensitivity analysis showed that by combining together the effect of geometrical variables in one variable Δ, which is the shape factor of the roll gap (Δ = hav/ld, where hav = (h1 + h2)/2-the average thickness, ld = 1 Rh r -the length of the arc of contact, h1 and h2the entry and the exit thicknesses, respectively), the number of the independent variables can be decreased.
Inverse analysis for the results of the compression tests was performed for each material in the database (Section 3. 1 and  [18] ) and the coefficients in flow stress models were identified. The inverse algorithm described in  [21]  was applied. Relation between the flow stress (σ p ) and the average pressure (p av ) in rolling has to account for the so called "friction hill" and this relation was described by the metamodel, which follows the concept of Sims  [22] , who introduced parameter Q representing average pressure-to-flow stress ratio (Q = p av /(aσ p ), where a = 2/ √ 3). The data generated by numerous FE calculations for different reductions (r = (h 1h 2 )/h 1 ), roll radii (R) and friction coefficients (µ), were used to find the coefficients in the polynomial function Q = f (r,R,µ).
Start temperature for precipitation is calculated from the phase transformation model. Coefficient K 1 in Equation (  7 ) is 129. 5 and 286 for 0. 035% Nb steel and 0. 13% Ti steels, respectively. Coefficients K 2 = K 3 = 2 for both steels. Coefficient K 4 is defined as: ∆σ prec = K 1 exp          1 K 2 lg          T 0 dT K 4                   K 3 (7) K 4 = 10 16 T exp 28000 RT (8) All the material models mentioned in this Section were implemented into the VirtRoll system data base and simulations of the selected hot strip rolling processes for the investigated steels were performed.
The models were identified on the basis of experiments described in Section 3. VirtRoll combines the developed models with database, knowledge base, and inverse solution coupled with optimization techniques in one hybrid computer system. The main advantages and unique functionalities of the system can be summarized as follows: • The user friendly interface (GUI), which is usable for engineers who are not IT experts. • Advanced physical and numerical models to predict behavior of advanced steels. • Guidelines for unconventional production methods. • A graphical drag and drop editor that supports flexible design of rolling mill. • Database and knowledge base, which essentially support the design of rolling technology. • Sensitivity and inverse analyses to support flexible design of strip rolling technology.
Stochastic mechanistic epidemiological models largely contribute to better understand pathogen emergence and spread, and assess control strategies at various scales (from within-host to transnational scale). However, developing realistic models which involve multi-disciplinary knowledge integration faces three major challenges in predictive epidemiology: lack of readability once translated into simulation code, low reproducibility and reusability, and long development time compared to outbreak time scale. We introduce here EMULSION, an artificial intelligence-based software intended to address those issues and help modellers focus on model design rather than programming. EMULSION defines a domain-specific language to make all components of an epidemiological model (structure, processes, parameters.
) explicit as a structured text file. This file is readable by scientists from other fields (epidemiologists, biologists, economists), who can contribute to validate or revise assumptions at any stage of model development. It is then automatically processed by EMULSION generic simulation engine, preventing any discrepancy between model description and implementation. The modelling language and simulation architecture both rely on the combination of advanced artificial intelligence methods (knowledge representation and multi-level agent-based simulation), allowing several modelling paradigms (from compartment-to individual-based models) at several scales (up to metapopulation). The flexibility of EMULSION and its capability to support iterative modelling are illustrated here through examples of progressive complexity, including late revisions of core model assumptions.
On the other hand, enhancing reusability requires reproducibility (the capability for others to recode a model) and flexibility (the possibility to adapt it). Though necessary, best practices in software engineering  [9]  cannot settle those issues alone: ad hoc codes can be documented, tested, reproducible, and yet wrong  [10]. A first step to reduce development time and errors is to use simulation platforms, which provide high-level built-in features. In general-purpose platforms such as GAMA  [11] , NetLogo  [12]  or Repast  [13] , a substantial programming effort is still required as algorithms involved in epidemiological models are not provided as platform features. Simulation libraries and platforms dedicated to epidemiological issues are rising, e. g. SimInf  [14] , a R library for data-driven compartment-based models; MicroSim  [15] , an agent-based platform for several kinds of diseases; or GLEaMviz  [16] , a metapopulationoriented platform.
Yet, KENDRICK is designed for compartment-based models only. To the best of our knowledge, none of existing solutions address those methodological challenges simultaneously, the most advanced approaches providing either a flexibility in modelling paradigms at the expense of software development efforts, or an enhanced readability through a DSL limited to a specific modelling paradigm. This article introduces EMULSION, an AI-based framework which tackles those challenges in an integrated approach. EMULSION intends to help modellers develop mechanistic stochastic models of complex systems in epidemiology at several scales using multiple paradigms, and to facilitate the coconstruction and assessment of model components (biological assumptions, model structure, parameters, scenarios, etc. ) with epidemiologists or scientists from other relevant fields, throughout model development.
Design and implementation To address the challenges presented above, EMULSION combines two AI methods  [20]. The first one is a DSL designed for the description of all components of an epidemiological model, to make them explicit in a human-readable form as a structured text file, so that scientists from different fields can better interact with modellers throughout the modelling process, and discuss, assess or revise model structure, assumptions, parameters at any moment without having to read or write any line of simulation code. The second one is the use of a generic simulation engine, whose core architecture relies upon a multi-level agent-based system  [21]. This allows several scales (individuals, groups, populations, metapopulations) and modelling paradigms (compartment-or individual-based models) to be encompassed within a homogeneous software interface, as agents act as wrappers which can be dynamically combined regardless of what they have to compute and the scale at which they operate.
A domain-specific language for epidemiological models The main benefits of the DSL defined in EMULSION are a modular decomposition of the model, which reduces dependencies between model components and facilitates further extensions, and a high readability by non-modeller scientists. When EMULSION simulation engine reads the DSL, it selects the agent classes corresponding to the chosen paradigm and scales, instantiate agents depending on initial conditions, transforms expressions into Python functions (using SymPy, a library for symbolic computation), builds the state machines, and runs the simulations. Hence, the execution of simulations based on an EMULSION model is univocal, all required information being directly usable (yet humanreadable) by the simulation engine. EMULSION comes with several built-in actions (changing the values of variables, creating new individuals, etc.
) which can be used in states and transitions. When the user defines levels, groups, or states, EMULSION automatically provides associated variables (e. g. population counts, individual tests for each state) to make model description as self-sufficient as possible in model files. In very specific cases, processes or actions may require the definition of small code add-ons, as demonstrated below for data-driven events in a metapopulation. But in the majority of situations, no additional code is required. An EMULSION model is a text file based on the YAML format  [33] , which is mainly based on nested lists or key-value pairs, ending with strings, numbers or booleans (yes/no). Each model is composed of several first-level keys (called "sections" in what follows) to provide information by topic: model name, modelling paradigms and scales, processes occurring at each level, structure of state machines, list of parameters and expressions, individual actions, initial conditions, outputs.
The differences introduced in the previous model are highlighted in S3 Text, and Python code add-ons required to handle data are provided in S4 Text. After being used to better understand pathogens spread in a population, epidemiological models are often extended to assess control strategies. Let now assume that the user wants to assess the effect of targeted vaccination, e. g. of juveniles in spring. This obviously involves substantial changes in the infection process, to incorporate a vaccinated state and associated transitions. The modularity of EMULSION allows modellers to change the "health_state" state machine without any impact on the metapopulation structure. First, a new health state "vaccinated" (V) must be added. A calendar is introduced in the "time_info" section to define when "spring" occurs.
Availability and future directions The EMULSION package documentation, with installation instructions (either from PyPI or by cloning the GIT source repository), tutorial and examples, can be found on SourceSup (a forge dedicated to French public research institutes) at: https://sourcesup. renater. fr/www/emulsionpublic. The package comes with 32 examples to illustrate features of EMULSION modelling language, from very simple SIR models declined in compartmental, individual-based, or hybrid approaches, to epidemiological models in structured populations mixing infectious process, demography, seasonality, forcing external variables, and non-exponential distributions of state durations. Examples also demonstrate how to move from within-to between-population models using data-driven movements.
Updates will be released regularly based on the integration on new modelling features or code optimizations. As demonstrated, EMULSION is flexible enough to cover a broad diversity of stochastic and mechanistic epidemiological models at several scales. Current version of the software is fully usable by modellers and currently deployed to develop models for real diseases assuming various propagation pathways (direct contacts, environment contamination, airborne or vector-borne transmission, vertical transmission), demographic and herd management processes, detection methods (observation of clinical signs, sensors, tests), and control measures (vaccination, antibiotics, tests at purchase, selective culling). Specific features in those epidemiological models, requiring for now dedicated add-ons, will be incorporated to the DSL and to the simulation engine as generic modules if recurrent enough among models, to help encompass a broad range of mechanisms within EMULSION.
In the longer term, we plan to use the DSL for optimized code generation (e. g. in C/C++). The choice of Python for implementing EMULSION simulation engine was well adapted to facilitate the modular and incremental development of the software, and its portability on various operating systems and environments. Genericity was also achieved through introspection capabilities of the language, but which came with an additional computational cost. This constitutes a limit of the software when tackling multi-scale models with numerous components (e. g. large number of interacting populations), models which analysis is based mainly on massive simulations. Such models written using EMULSION's DSL then would benefit from being automatically translated into simulation codes generated from templates, allowing for higher computational performances.