dataesr/scientific-paragraphs-categorization huggingface dataset:
Some of the most relevant functions suggested by participants are to allow communication with other electronic devices (e. g. , smartphones and smartwatches) and more options enabling remote control of robots. The addition of the two first functions is a trivial task thanks to the modular nature of the proposed software architecture. This integration can be performed by using mobile applications built on top of NEP or the rosbridge suite, which can also enable the streaming of data between desktop PC and Android or iOS devices. Participants suggested also other desired functions especially to be able to manage the Pepper's tablet. This will guide the next iterations in the development of novel programming interfaces based on the RIZE software architecture and tools. A future session of this set of co-design workshops will include the use of the Fetch service robot.
Therefore, future work will focus on exploring novel contexts, such as educational and industrial scenarios. RIZE can also be complemented with a set of pre-built modules for knowledge acquisition using state-of-art deep learning methods, advanced emotional expression, and learning from demonstration. We also plan to explore novel and hybrid approaches between different types of visual languages and decision-making approaches for enabling the easy prototyping of more complex and dynamic robot behaviors. Rather than propose a static or monolithic programming environment, such as most previous works, RIZE is designed as a modular and adaptable EUD research framework for robotics, which can be easily interfaced with code from other HRI projects and new robotics platforms. Open RIZE is an example of a programming environment built on top of the RIZE software architecture and tools.
This paper presents a multi-objective energy management system (EMS) to manage the power dispatch of a hybrid power plant (HPP), consisting of a grid-connected wind farm and a Li-ION battery storage system on the island of Guadeloupe's electrical grid. Via a controller based on Model Predictive Control (MPC), the EMS solves the problem of optimization by considering the production forecast data and managing several operation rules, which ensures meet energy targets considered for a sustainable power dispatching plan. The proposed strategy is tested in a PowerFactory/MATLAB co-simulation environment.
• Through a model predictive control strategy, the EMS proposed allows the BESS to be optimized and, thereby, the power injection into the utility grid, while considering the battery's lifespan. • An evaluation of the proposed Multi-objective EMS by analyzing and comparing the simulation results from several study cases. The EMS is tested in realistic scenarios via a PowerFactory/MATLAB co-simulation environment while taking into account the island grid's real operations. Contrary to the paper by Reference  [31] , our strategy is not economic, but rather technical, which works by evaluating the technical conditions to supply the power commitment while avoiding economic penalties. The organization of this paper is as follows. Section 2 presents a description of the Grid-connected wind-storage hybrid power plant.
Mathematical Modeling of the HPP Subsystems In this paper, a PowerFactory/MATLAB co-simulation methodology was carried out in order to assess the impact of a wind-storage hybrid power plant, injecting power into one of the HTA busbars of the Sainte-Rose substation. Both the hybrid power plant and a basic EMS are considered being part of the system implemented in PowerFactory. The grid model is then validated through simulation by comparison with respect to some literature available data.
Wind Generation System Modeling and Validation The wind generation system's single line diagram described by PowerFactory software is depicted in Figure  5. As shown, this system consists of four 2 MW WTs based on Doubly Fed Induction Generators (DFIG) with their respective rotor-side converters (RSC) and transformers. The DFIG (electrical component) is modeled through the Pulse-Width Modulation (PWM) converter, which allows for flexible and fast control of the machine by modifying the magnitude and phase of the output voltage on the rotor-side  [39, 40]. LV 1 LV 4 LV 3 LV 2 PCC LOCAL WT HTB 4 HTB 3 HTB 2 HTB 1 G DFIG_2MW 4 IG2MW G DFIG_2MW 3 IG2MW G DFIG_2MW 2 IG2MW G DFIG_2MW 1 IG2MW Trf Trf. Trf 4 The power curve of the wind turbine modeled is displayed in Figure  6. This curve presents the steady-state electrical power obtained from simulation for wind speeds ranging from start-up wind speed (3 m/s) up to shut-down speed (29 m/s).
PowerFactory Model Validation The PowerFactory BESS model (i. e. , the controlled system model) is implemented as a standalone storage unit containing a DPL (DIgSILENT Programming Language) script with the Tremblay model equations and parameters to represent the IM20M battery. To validate it, a power reference profile of 1-h duration is imposed on both the Simulink battery block and PowerFactory nonlinear BESS model. The validation test results are presented in Figure  12. Figure  12a  shows the reference power profile is followed by the battery power signals obtained from the two battery models. The resulting BESS current, state-of-charge (SoC), and integral current (it) signals are presented in Figure  12b-d. The state-of-charge limits are set at 20% and 80%. A sampling time of 1 s was used in the simulations.
The HPP linear model for control is then validated via PowerFactory/MATLAB simulations. In Figure  15 , the signals corresponding to the state variables are presented, as well as the battery power obtained in both cases. Figure  15a-c  present the integral current, the filtered current, and the state-of-charge, respectively. The integral current and stateof-charge resulting from the linear model behave as those obtained from the nonlinear modeling (relative errors smaller than 0. 2% and 0. 3%, respectively). While the filtered current plot (Figure  15b ) shows an error smaller than 10% during 97% of the time. Some peaks are presented during the reference changes. In Figure  15d , the linear model storage system's active power was calculated as v (BESS) • i * according to Equation  (6). The voltage signals involved being the same, it can be observed that i * introduced a filter effect reducing the oscillations in the estimation of the active power done through the linear model.
u(k + N p -1)      , ( 13 ) for a total of N p possible future control actions. Finally, Γ can be interpreted as the cost obtained by the evaluation of the future control actions function ũ using the future references P I N Jre f and SoC re f and the present system state x(k) within the time horizon [k, k + N p ]. The cost function described in Equation (  12 ) was derived based on MPC control law while considering the control objectives. An appropriate optimization algorithm is now required to reduce future errors based on such a quadratic function and in the presence of linear constraints. For that, the parametric prediction approach presented in Reference  [47]  is used. The approach is compatible with the quadratic programming solver provided by MATLAB's optimization toolbox (quadprog).
As the penalty system punishes excursions outside the injection band lasting 60 s, it is best to choose an (N p) smaller than 60. Considering all the above, the prediction window was fixed at 10 s. Table  3  displays the algorithm parameters values to be used in these tests. As can be seen, the strategy combines a choice of the relative weights prioritizing the objective of reducing the tracking error instead of the power injection objective over the tracking of the SoC error. To do so, the interaction between the hybrid power plant and the Guadeloupean grid, as well as the control/optimization strategies, are presented in co-simulation in the PowerFactory/MATLAB environment (Figure  21 ). As can be seen, PowerFactory inserts the key signals that are handled by the DigSilent (DSL) control structure into a common workspace that can be accessed by MATLAB.
This way, the simulation takes place in the PowerFactory environment while enabling the use of the different MATLAB functions and toolboxes. The field wind speed and production data to be used in the simulation tests are shown in Figure  22. Wind speed data (Figure  22a ) were generated by a wind farm operator and it was collected every minute using a measurement tower in Sainte Rose, Guadeloupe. The power production data shown in Figure  22b  were obtained using the power curve of a 2 MW Gamesa G90 wind turbine. According to the average of both the wind speeds and the productions obtained, these are classed as:.
Conclusions In this paper, an EMS was designed to manage the power dispatch of a hybrid power plant injecting power into the Guadeloupe's electricity grid. The system combines wind turbines with a Li-ION BESS. The HPP and control structure were modeled using PowerFactory. Moreover, the energy storage system model was validated to be used in the control strategy. Based on this model, the development of an adapted management strategy for predictive control and quadratic programming optimization determined the power flow management of the HPP to comply with the day-ahead commitment according to the WECS output variations. To reach the objectives, a quadratic cost function was formulated that considers the problem's objectives and is attached to several physical and operational constraints. Using PowerFactory/MATLAB co-simulation, it was proven that the proposed EMS has the ability to handles the battery's charge/discharge cycles to inject the power into the grid continuously, fulfilling two aims: minimizing the commitment failures and extending the storage system's lifespan.
Methods Training cohort. The protocol was approved by the institutional review board of the Johns Hopkins Medical Institutions, and all the patients provided written informed consent. All methods were carried out in accordance with relevant guidelines and regulations. We retrospectively analyzed a training cohort with ICM and NICM who underwent CMR at Johns Hopkins Medical Institutions (Baltimore, MD) using 1. 5-Tesla whole body scanners prior to primary prevention ICD implantation (median 3 days) between 2003 and 2015 with a standard imaging protocol (Left Ventricular Structural Predictors of SCD, ClinicalTrials. gov Identifier: NCT01076660). The device type included a single-, dual-chamber ICD, and CRT-D based on current guidelines 1. Patients were evaluated every 6 months and after any ICD shock.
Algorithm development. In this work, the above-mentioned cine CMR dataset was used to train two independent neural networks. First, a probabilistic encoder-decoder neural network  14  was trained to extract cardiac structure and function features from 4cv cine CMR in a form of cine fingerprint in a fully unsupervised fashion (Cine Fingerprint Extractor, Fig. 1A ). Each of the 4cv cine CMR images was cropped to include only the heart within a square of 128 × 128 pixels with a spacing of 2. 2 mm. An L2 reconstruction error term, a regularizer acting on the distributions of the latent space, was used to learn a probabilistic fingerprint space. The network was trained using sixfold cross-validation (using 5/6 of the cases for training and 1/6 for validation for each fold). Second, an autoencoder neural network was trained by regressing disease outcomes as a cine risk score (0 to 1 probability scale) with the cine fingerprint as an input (Risk Predictor, Fig.
1B ). The network was trained using sixfold cross-validation and was re-trained for each outcome separately (VA, heart failure death, and all-cause death). To enable the use of censored data, a partial likelihood loss function derived from Cox' semi-parametric proportional hazards model was utilized  30. To ensure data cannot leak between both networks, the training procedure was repeated 6 times by selecting a different fold as the validation data set. The results of all 6 validation groups from the different trainings were then combined to evaluate the complete dataset. In addition the Risk Predictor network was evaluated using bootstrapping  31  for measuring the performance. Further details of the algorithm development are described in Supplementary Appendix 2 and Supplementary Fig. 2.
Acknowledgements We thank  Prantik Gupta  for his assistance in data management. This work was supported by  NIH/NHLBI   R01HL103812  (to KCW),  NIH/NHBLI   R01HL132181  (to KCW and GFT),  NIH/NHLBI   R56HL138429  (to HA),  Fondation Leducq   16CVD02  (to HA),  3IA Côte d' Azur Investments in the Future  project managed by the  National Research Agency  ( ANR-19-P3IA-0002 ),  AAP Santé 06 2017-260 DGA-DSH , and the  Inria Sophia Antipolis-Méditerranée , "NEF" computation cluster. The concepts and information presented in this paper are based on research results that are not commercially available.
Root traits For each subplot sample, root traits (Table  S2 ) were measured on live absorptive fine roots for each species and soil depth separately (except for the three Quercus species in Italy, which could not be reliably distinguished and were therefore pooled, hereafter referred to as Quercus spec). Root tips colonized by EcM were visually identified and counted on representative subsamples based on the presence or absence of a fungal sheath for the 12 species known to be associated with EcM (Acer pseudoplatanus was associated with arbuscular mycorrhizae). Thereafter, roots were scanned in water with a flat-bed scanner (resolution 800 dpi) and scans analysed with the software WinRhizo  (Regents Instruments, Québec, Canada, 2009)  to obtain root length, area, volume and diameter. Root volume and (average) diameter values were corrected by recalculating them from the sum of all diameter classes' averages  (Freschet et al.
Accepted Article This article is protected by copyright. All rights reserved fungal ITS2, using the primers P5-5 N-ITS4 and P5-6 N-ITS4 together with P7-3 N-fITS7 and P7-4 N-fITS7  (Gardes & Bruns, 1993; Ihrmark et al. , 2012; Leonhardt et al. , 2019)  and produced libraries using the Nextera XT Illumina index Kit (Illumina), based on the manufacturer's instructions. Subsequently, samples were sequenced with the MiSeq Reagent kit v3 on Illumina MiSeq system (Illumina Inc. , San Diego, CA, United States). After bioinformatic analysis, the FUNGuild V1. 0 tool was used to analyse fungal taxonomy and ecological guilds  (Nguyen et al. , 2016). Subsequently, we identified and classified fungal groups and determined fungal richness and diversity using the package phyloseq  (McMurdie & Holmes, 2013)  in R (R Core Team, 2018).
Moreover, bivariate correlations between absorptive root trait pairs that were expected to be significant based on the PCA biplots were checked using simple linear regression analyses to corroborate the interpretation of the PC axes. Linear mixed-effects models (LMMs) were used for testing the hypotheses and accounting for the nested study design (package lme4,  Bates et al. , 2015). Random slopes and intercepts and plot nested within site were used as random effect structure for all models, except for site-level models and models based on plot-level data, where only site was used as random effect. Model assumptions were checked using the package DHARMa  (Hartig, 2019). In case of violations of model assumptions, response variables were transformed (package bestNormalize,  Peterson, 2017).
Accepted Article This article is protected by copyright. All rights reserved the two phylogenetic groups and then modelled each trait for each group separately across sites and for individual sites. We further modelled FRB of both gymnosperms and angiosperms separately in response to total mycorrhizal biomass and diversity as well as the diversity of EcM. In addition, to specifically test for differences in responses of gymnosperms and angiosperms to tree species mixing, we computed models testing each trait in response to the interaction between phylogenetic type and tree species richness using the whole dataset.
This study was funded by the  German Research Foundation  (Grand numbers:  BA 2821/16-1  and  SCHE 695/10-1 ). This research was part of the  SoilForEUROPE  project funded through the 2015-2016 BiodivERsA COFUND call for research proposals, with the national funders  Agence Nationale de la Recherche  ( ANR, France) ,  Belgian Science Policy Office (BELSPO, Belgium) ,  Deutsche Forschungsgemeinschaft (DFG, Germany) ,  Research Foundation Flanders (FWO, Belgium) , and  The Swedish Research Council (FORMAS, Sweden). FB was supported by the  Margarete-von-Wrangell Fellowship of the Ministry of Science, Research and the Arts Baden-Württemberg  and the  European Social Fund. We further thank  Bart Muys  and  Karen Vancampenhout  at  KU Leuven University  for the soil texture data, the site managers  Leena Finér ,  Natural Resource Institute Finland (LUKE) ,.
The datasets used for this study are archived on a data portal associated with the FunDivEUROPE and SoilForEUROPE projects and available after a 1-year embargo (root biomass data: https://data. botanik. uni-halle. de/fundiveurope/datasets/518; root functional trait data: https://data. botanik. uni-halle. de/fundiveurope/datasets/521; plot-level C, N data: https://data. botanik. uni-halle. de/fundiveurope/datasets/520; Soil fungal biomass and diversity data: https://data. botanik. uni-halle. de/fundiveurope/datasets/522).
Most compilers have a single core intermediate representation (IR) (e. g. , LLVM) sometimes complemented with vaguely defined IR-like data structures. This IR is commonly low-level and close to machine instructions. As a result, optimizations relying on domain-specific information are either not possible or require complex analysis to recover the missing information. In contrast, multi-level rewriting instantiates a hierarchy of dialects (IRs), lowers programs level-by-level, and performs code transformations at the most suitable level. We demonstrate the effectiveness of this approach for the weather and climate domain. In particular, we develop a prototype compiler and design stencil-and GPU-specific dialects based on a set of newly introduced design principles. We find that two domain-specific optimizations (500 lines of code) realized on top of LLVM's extensible MLIR compiler infrastructure suffice to outperform state-of-the-art solutions.
INTRODUCTION Domain-specific approaches are revolutionizing the generation of high-performance devicespecific code and sparked the development of powerful domain-specific language (DSL) frameworks, often achieving performance numbers unattainable for general-purpose compilers  [13, 38, 45, 51, 54, 58]. For example, Halide  [44]  automated the generation of high-performance code for image processing, XLA  [31]  exploited domain-specific compilation to accelerate deep learning, and Stella  [24]  was the first to move the weather and climate simulation to GPUs leading to 2. 9× speedup  [17]. The broad success of domain-specific compilers-over time-also exposed their largest weakness: Their one-off implementations mostly separated from general-purpose production compiler pipelines. Halide, XLA, Stella, and others are specialized solutions for their respective domains that are not designed with reusability in mind.
SSA-based IRs allow us to reuse optimizations from general-purpose compilers  [37]. High-level operations concisely encode domain properties and make them readily available as, e. g. , SSA data flow without a need for costly analyses. Progressive lowering makes it natural to preserve domain information, to express transformations as high-level peephole optimizations  [35] , and to introduce reusable lower-level abstractions. The recently introduced MLIR compiler infrastructure  [30]  allows us to instantiate production-quality compiler IRs that follow the practice-proven IR design principles developed in LLVM  [29]  over the past 15 years. The Open Earth Compiler 1  we implemented (Figure  1 ) is one of the first end-to-end compilation flows leveraging multi-level IR rewriting for high-performance code generation.
Its core consists of a set of MLIR dialects, i. e. , collections of domain-specific operations and transformations, and conversions between them. The Open Earth Compiler optimizes programs by progressively converting them from higher-level domain-specific dialects to lower-level platform-specific ones, using peephole-style rewrite patterns. Each dialect defines an abstraction that makes relevant analyses inexpensive and transformations convenient to implement. The compilation process starts from the stencil dialect (Section 4) designed as a target for various user-facing DSLs as well as a data structure for domain-specific transformations such as stencil inlining (Section 5. 1). Stencils are then lowered through a series of IRs featuring index operations (Affine), structured control flow (SCF), and arithmetic operations (Standard), all of which are readily available in MLIR  [30] , together with loop-and value-level transformations such as unrolling or common subexpression elimination.
Our contributions are: • An approach to designing a modular domain-specific compiler using multi-level IR rewriting (Section 2). • A stencil language expressed as an MLIR dialect, which encodes the high-level data flow of a stencil program as SSA def-use chains (Section 4). • A set of transformations to tune stencil programs at a high level using simple peephole optimizations instead of conventional loop transformations (Section 5). • A platform-neutral GPU dialect abstracting the vendor-specific GPU code generation (Section 6). • An evaluation on benchmarks relevant to real climate models: COSMO (Europe) and FV3 (US) (Section 7). • A comparison to the industry-leading stencil compiler and to state-of-the-art solutions for weather and climate (Section 7. 4).
THE MLIR INFRASTRUCTURE MLIR is a recent production compiler infrastructure that is particularly well-suited for multi-level IR rewriting due to its extensibility through dialects and its built-in support for declarative rewrite patterns  [30]. We thus implement the Open Earth Compiler as a set of MLIR dialects and rewrite patterns designed to compose with the existing Standard, Structured Control Flow, Affine, and LLVM IR dialects. Core MLIR concepts include operations, values, types, attributes, (basic) blocks, and regions. An operation is an atomic unit of program description. A value represents data at runtime and is always associated with a type known at compile time. Operations use values (but do not consume them) and define new values. Values can only be defined once, making the IR obey SSA form.
There is no formal or technical restriction on how dialects are structured. Unless prescribed otherwise by the semantics of the operation, a region can contain operations from different dialects, and an operation can reference types and attributes defined by a different dialect. As a result, we can extend the MLIR ecosystem by adding custom dialects. In our compiler, we use this extensibility to make stencil computations first-class by providing custom types, attributes, and operations. The same holds for control flow operations such as loops or data types such as multi-dimensional arrays. Figure  2  illustrates the syntax for an example operation from our Stencil dialect. The stencil. apply operation uses a value %use and defines a value %def. Types and attributes annotate the operation with compile-time information such as the iteration domain.