dataesr/scientific-paragraphs-categorization huggingface dataset:
Conclusions To our knowledge, iSARAH is the first Web-based learning resource for therapists on an evidence-based hand exercise program. A systematic design approach by using the ADDIE model and involving end users has been successful in developing a user-centered iSARAH. Our ongoing work on the impact evaluation among therapists who completed iSARAH and a service evaluation in people treated by SARAH-trained therapists will provide more insights on the uptake of the SARAH program in actual practice.
Acknowledgments We thankfully acknowledge the therapists who took part in the SARAH online survey, iSARAH development day meeting, and usability evaluation sessions. Our special thanks to the Patient & Public Involvement contributor who participated in the exercise demonstration videos. This research was funded by the  National Institute for Health Research (NIHR) Collaboration for Leadership in Applied Health Research and Care Oxford at Oxford Health NHS Foundation Trust. This work was supported by the  NIHR Biomedical Research Centre, Oxford, UK. The views expressed are those of the authors and not necessarily those of the  UK National Health Service , the  NIHR , or the  Department of Health.
PrEstoCloud Framework PrEstoCloud aims to address the challenge of cloudbased self-adaptive real-time Big Data processing, including mobile stream processing. The envisioned PrEstoCloud solution is driven by the microservices paradigm that is the use of a software architecture style in which complex applications are composed of small, independent processes communicating with each other by using language-agnostic APIs. As such, the approach used by PrEstoCloud is superior to any other monolithic solution, since each of the PrEstoCloud components can be instantiated as many times it is needed in order to cope with the scalability requirements of such dynamic environments and satisfy all the availability constraints. The conceptual architecture of PrEstoCloud is presented in Figure  1  and is briefly discussed below.
We note that with respect to real-time data-intensive processing, this solution envisions an architecture inspired by the STORM computational system (i. e. real-time, stateless, stream processing), enhanced in such way that exploits the advantages of multi-cloud environments and Edge computing (i. e. a topology for real-time adaptive and stateful stream processing). In addition, we consider using appropriate models for enabling developers to perform annotations on cloud applications, in order to define their meaningful fragments that may be deployed in a distributed way. The PrEstoCloud architecture has been structured across 5 different layers: i) Meta-management; ii) Control; iii) Cloud infrastructure; iv) Cloud-edge communication and v) Devices layers. The first four layers are discussed below while the fifth one consolidates any kind of device that can be used as a Big Data stream source or as a mobile computational node at the extreme edge of the network.
The Meta management layer mainly consists of decision logic capabilities required for enhancing the PrEstoCloud Control layer (e. g. Autonomic Resources Manager, Autonomic Data-Intensive Application Manager). This layer involves the following modules: Resources Adaptation Recommender that will use as input the situation details, the variation of the Big Data streams and the context of the mobile devices at the extreme edge of the network in order to recommend at the appropriate time, the necessary adaptations of used resources in the real-time processing network (RTPN). These input details will be provided by the Situation Detection mechanism and the Mobile Context Analyser respectively. In addition, these recommendations will be enhanced with the necessary proactiveness based on the envisioned interaction with the Workload Predictor.
Data-Intensive Application Fragmentation & Deployment Recommender that will assist in the appropriate fragmentation of data-intensive applications into smaller parts that can be efficiently deployed over network resources. Specifically, it will be based on the interpretation of the code level annotations (provided by the cloud application developer), in order to recommend meaningful operations of a cloud application to be distributed and deployed over a STORM-like topology on multiclouds and Edge resources, for resilience and performance reasons. Different properties like response time, security and locality constraints or other quantitative or qualitative attributes, will be used for deciding on the most optimal configuration at run-time. Situation Detection Mechanism which will provide the necessary situation awareness for detecting interesting situations by considering Big Data streams and RTPNs deployed on cloud resources or at the extreme edge of the network (i.
The detected or inferred contextual information will be propagated to the Situation Detection Mechanism. Workload Predictor for fusing proactiveness to the PrEstoCloud solution. Specifically, this module will be able, given an appropriate model and method, recent monitoring information and workload evolution over time to predict the workload that may be experienced in the near future. In addition, it will be also able to predict possible failures because of the overuse of certain processing nodes, thus enhancing the reliability of the processing topology and minimizing any chances for down time incidents. The second layer of PrEstoCloud architecture is the Control layer that manages resources of the Cloud infrastructure layer and contains the following modules: Autonomic Resources Manager which involves monitoring and management of cloud resources capabilities that can be extended to the edge of the network.
Specifically, this module is considered as a master-node that involves "Nimbus-like" (http://storm. apache. org/) functionalities, i. e. enhanced nodes with advanced capabilities for reliably (multi-cloud support) and adaptability, dealing additionally with resources management at the edge of the network. This STORM-like approach uses Coordinator Servers (i. e. Zookeper-like functionality for managing stateful nodes across multi-clouds) and Supervisors for coordinating the real-time processing network (RTPN) clusters (deployed on the Cloud infrastructure layer). This component will interact with Resources Adaptation Recommender and will exploit the spatio-temporal processing capabilities of the respective module. It is composed of the following microservices: i) Smart monitoring, ii) Multi-Iaas manager and connector, iii) Manager of the resources at the edge, iv) Hybrid cloud deployment manager that implements TOSCA (https://www.
oasis-open. org/committees) interfaces, v) Resources adaptation manager. Autonomic Data-Intensive Application Manager which is responsible for the scheduling of big data applications execution. This module also constitutes a "Nimbus-like" node as a master-node which is responsible for distributing meaningful fragments of data-intensive applications across clusters and launching the appropriate workers for controlling the processing workflow (deployed on the Cloud infrastructure layer). In this STORM-inspired approach the notion of a Bolt is uplifted into a Processing Node in the sense that it doesn't only address data/event processing using small stateless processing units but it may cover more complex operations of a cloud service that should be distributed across different cloud infrastructures for failover and performance issues.
The four PrEstoCloud layer is the Cloud-Edge communication which refers to the following components: Inter-site network virtualization orchestrator for coping with the need of virtualizing hardware resources situated in multi-cloud environments, managing their orchestration and provisioning across different and heterogeneous providers. This also includes the control of the inter-sites network virtualization process in a secure way, through a close interaction with the Security Enforcement Mechanism. We note that we are examining the provision of a Virtual Network Orchestrator, which will rely on Software Defined Networking (SDN) technology. Communication Broker which will undertake the responsibility of relaying data streams on and off the PrEstoCloud platform providing standard publish/subscribe event brokering capabilities.
Applications To investigate the bias induced by stationarity assumption, we use stochastic mapping to compute relevant dN , dS and dN dS estimates on simulated and empirical sequence datasets, both of which are subject to changes in GC content. The same model has been used, aka the model proposed in  Yang and Nielsen (1998)  (denoted "YN98"), both in homogeneous and non-homogeneous (or branch) modelings. To model a non-stationary process, it is necessary to introduce root codon frequencies. To reduce the number of parameters to estimate, root and equilibrium codon frequencies are computed as products of position nucleotide frequencies instead of a full parametrization of the codon frequencies (61 parameters). In simulations, nucleotide frequencies are considered as identical for all positions (denoted "F1X4", with 2 × 3 parameters).
For real dataset analyses, nucleotide frequencies are position specific inside codons (denoted "F3X4", with 2 × 9 parameters, because of 3 equilibrium frequencies), and normalized as stop codon frequencies are set to 0. In a first step, parameter ω is estimated through maximum likelihood computation of model, root frequencies and branch lengths on each alignment. Then, in a second step, dN and dS are computed using normalized stochastic mapping as described in Method section, from this optimized model and tree. This procedure has been implemented in the Bio++ program suite  (Guéguen et al. , 2013). It can then easily be used on the numerous models that are available in this suite, and most importantly in any non-homogeneous modeling. Moreover, it can output both site-specific and/or branch-specific estimates.
Simulated dataset To study the influence of the non-stationarity in G+C content on the maximum likelihood estimate of ω, we simulated the evolution of 100 coding sequences of 3000 codons. Each simulation started from an ancestral sequence with determined proportion of G+C, noted θroot, and ran along the tree depicted in Figure  1 , using an homogeneous YN98+F1X4 model with determined G+C equilibrium frequency, noted θeq. Each θ value (θeq and θroot) ranged from 0. 1 to 0. 9 per step of 0. 1. We simulated negative, weakly negative, neutral, and weakly positive selection (resp. ω = 0. 1, ω = 0. 9, ω = 1, ω = 1. 1).
Conclusion Our analyses, both on simulated and empirical datasets, show that estimates of dN , dS and ω can be biased when using standard methods, which assume sequence stationarity. The strength of the bias depends on the gap between the equilibrium and the actual base composition. Generally, estimates of ω are more robust to this bias than those of dN or dS (Fig. 3 ), but in extreme cases, our simulations showed a two-fold difference between the true and estimated value of ω. This bias can have a profound impact for analyses aiming at comparing average values of ω among large gene sets. For instance, to investigate the parameters that explain variations in the efficacy of selection, many studies have compared the genome-wide average ω across different taxa (e. g. Galtier (2016) ). The genome-wide average of ω varies from 0.
Availability Our method has been implemented in the Bio++ suite  (Guéguen et al. , 2013). The maximum likelihood program is called bppml, and is available at the address http://biopp. univ-montp2. fr/BppSuite. The stochastic mapping program is called mapnh, and is available at the address http://biopp. univ-montp2. fr/forge/testnh. A short tutorial about model inference and stochastic mapping as described in this article is available there: https://github. com/BioPP/supp-mat/tree/selection_vs_GC.
Due to its electrical and optical interesting properties, InGaN alloy is being intensively studied to be combined with silicon in order to achieve low-cost high-efficiency solar cell. However, a relatively thick monophasic layer of InGaN is difficult to grow due to the relaxation issue in material. This issue can be avoided by semibulk structure. In this work, we present an InGaN/Si double-junction solar cell modeled using Silvaco-ATLAS TCAD software. We have taken into account polarization effect in III-N materials. We have shown that 50% of indium is needed to ensure the current matching between the top cell and the bottom cell in 2-terminal configuration. Such high indium composition is technologically challenging to grow. Thus, we have modeled a 4-terminals solar cell with relatively low indium composition (In = 25%) where current matching is not needed.
7 and 1. 8 eV in order to achieve the current matching  [1]. For this reason, we have varied the indium composition from 45% to 55%. Using SILAVCO-ATLAS TCAD software, we have optimized this structure and we show, in Figure  2 , that the maximal efficiency of about 28% is obtained with 50% of indium and with 400-nm thickness of InGaN absorbing layer. These values, which are needed to fulfill the current-matching condition and to extract the optimal photogenerated current density, are not technologically attainable today. Using XPS analysis, we have studied the interface between ZnO and Si. Figure  3  shows the atomic concentration for detected elements in function of sputter time. According to energy positions, we have distinguished between the oxygen (O) that is related to Zn and the O that is related to Si.
Fieldbus communications employ RS-485, RS-422, and RS-232 as the physical layer interface, with protocols specified by the IEC 61158 standard, for example, DeviceNet, CANopen, and Profibus. However, as Ethernet matures in the SCADA segment, many fieldbus installations are being replaced or redesigned with real-time Ethernet protocols augmented with deterministic communication profiles and mechanisms. In order to meet the real time, low latency, and the deterministic capabilities required for industrial applications, many of these Ethernet protocols use specialized Ethernet Media Access Control (MAC) modules (hardware accelerators present in the FPGA, Block (D)), in tandem with specialized data packaging stacks for high-speed encoding and decoding. Reconfigurable devices support many of these protocols, which can be mapped onto the programmable logic and easily accessed and controlled by the processor through a lightweight IP stack or be present as hardened modules.
This issue stems from the fact that the Profibus link limited the speed at which the triggers could operate, forcing the system to decelerate in order to wait for new commands. Therefore, a reduced response time was deemed necessary to alleviate the above-mentioned issues, leading to a higherperformance solution (in terms of the deposition precision), which could potentially help in attaining higher fabrication throughput. A distributed and networked IED implementation for managing this process seemed like the most viable choice, since this could be optimized for coping with the real-time requirements of the application directly into the robot head, discharging the main PLC from some of the time-consuming duties and enabling a higher degree of intelligence and data efficiency. A more detailed description of the initial distributed control architecture will be provided in the next section, pointing at its limitations and outlining the requirements for the IEC control system in more detail, in order to gain greater understanding of the benefits of using reconfigurable devices in this industrial application.
This PLC contains the general fiber placement software, generating the necessary commands to control the 6 axes and position the robot's head in the required coordinates. The control program, in the BoxPC (4), constantly monitors the speed and position of the robot via a high-precision encoder in order to determine at which points a set of actions over the fibers need to take place. Whenever an action has to be undertaken, the appropriate command (  5 ) is sent to the deposition head by a real-time BoxPC (a WinAC RTX  [41] ) via a Profibus link. These events (referred to as triggers thereafter) control the Head Electronic-Pneumatic (6) subsystem (containing internally a very large number of actuators (  7 )) used for deposing the fiber over a surface (typically a mould (8)), using the mechanism of Figure  5(a).
In order to make this passage more straightforward, a SoC FPGA has been chosen (the Zynq EPP 7000) in order to port the FreeR-TOS implementation previously developed while gaining in customization capabilities using programmable logic and the increased number of I/Os. In the next subsections, we will first briefly discuss the benefits of using SoC FPGAs. Then, we will detail the proposed architecture and software implementation of the real-time control system. Finally, we will discuss initial tests performed using a mechatronic platform for validating the design before moving to the actual system. Then, in the next section, a comparison between the various systems will be carried out.
For tackling the technological shortcomings briefly discussed above, the main FPGA vendors have made some major strides in adapting to the needs of the markets by introducing new capabilities, both technological and methodological  [44]. Examples of the former are the increased integration of specialized functions such as Digital Signal Processing (DSP) blocks, distributed and configurable memory blocks (i. e. , distributed BRAMs), and, more recently, large memory banks for data intensive applications, as well as the support of a plethora of communication protocols for moving large amounts of data. On the other hand, and in order to address the hardware/software divide typically associated with FPGA-based SoCs, FPGA vendors have made major strides in introducing application grade processors, such as the ARM Cortex A9, capable of running full operating systems such as Linux, with the aim of simplifying the specification, implementation, and validation of heterogeneous embedded systems.
This new kind of devices (which can be dubbed SoC FPGAs and depicted in Figure  7 ) couples a pair of high-performance ARM processors with a programmable logic extension block to promote a software-centric approach first and foremost. Following this rationale, these Extensible Processing Platforms (as Xilinx has named their Zynq devices  [42] ) take a processor-first approach, in which the ARM processor development flow is emphasized over the traditional FPGAbased design approaches. This entails that software designers can start developing new applications right away, using the well-known and well-regarded ARM Cortex architecture, taking advantage of a fixed number of standards modules and interfaces, which were briefly discussed in Section 3. 3 and shown in Figure  3. In many instances, when developing a new product or project, the first step entails developing a proof of concept.
Thus, the designers are thus less concerned about customizing the system requirements for specific customer or niche market. The most important concern at this phase is to have the maximum amount of flexibility to determine which functions are needed for the basic prototype in terms of the constituent components required for the embedded application. Then, in a second phase, the design team can finetune the application to meet specific constraints (i. e. , power consumption and real-time performance) by using profiling tools, which can help them to decide whether any segments of the applications can be sped up exploiting hardware implementation, discharging the main processor of some timeconsuming processes. SoC FPFAs like the Zynq integrate a tightly coupled programmable logic extension block that allows designers to partition their hardware and software functions based on system requirements and to customize the device for a given application scenario  [45].
The fiber deposition path is generated using a couple of pieces of software, CATFiber and CADFiber, which in tandem produce CAD data for a workpiece. This code is encompassed, on one hand, by the orientations of the carbon plies for each layer and, on the other hand, by the actions to be performed upon each fiber (Figure  5 ). The CAD tools enable importing and visualizing surface and geometry information of the manufacturing tools and jigs, allowing the generation of ply sequences (defined by their contour and a reference curve or ply direction). Moreover, the tools are tightly coupled with quality assessment analyses of draped laminated complex surfaces and augmented with fiber covering simulation tools, which cater for fiber angle deviation and steering. If necessary, a ply can be cut automatically into smaller sections in order to fulfill maximum angle deviations.
On the other hand, the Composites Manufacturing Module of the CAD tools allows the automatic generation actions for the tapes, that is, bands of several fibers that are deposed over the surface in a computer-controlled manner. Premanufacturing checks can be performed thanks to various analysis tools including fiber compaction, roller crush, and tool path viewing. The design process for a given piece is as follows: (i) a laminate piece is designed with the required number of plies and orientations, (ii) subsequently, plies are generated for a mould surface based on the CAD data from the piece, (iii) afterwards, a deposition program for the tapes is generated depending on the number of fibers to be used for a particular scenario (current systems support 16 fibers simultaneously), and finally (iv) tool paths are created in Kuka Robot Language (KRL) as a succession of linear movements or spline based displacements.
Once a piece has been created and simulated, the program is stored in an XML format and the program is executed by the BoxPC module described in Section 4. 3 (Figure  6 ). As discussed above, the control for the robot is independent of that for the pneumatic actuators in the deposing head: the main PLC caters for positioning the robot along the trajectories generated by CADFiber, while a real-time OS running on the BoxPC controls the actions associated with the fiber deposing subsystem, introducing the previously discussed performance bottleneck. Indeed, in spite of the capabilities of the BoxPC, a control loop encompassed by the position and speed signals coming from the robot limited the attainable speed at which the robot head could react, since this information is vital to trigger the control signals for the actuators in the head (Figure  5(a) ).
This is because the code generated by CADFiber for triggering the actuators in the head is dependent upon the robot position information, and in order to improve the accuracy of the finished pieces, all the encompassing actuators per fiber have to react very fast in a highly synchronized and repeatable manner. Additionally, the internal calculations by the BoxPC and the latencies introduced by the Profibus link only made matters worse. Therefore, it was decided early on to substitute the BoxPC with a dedicated real-time embedded controller, which could satisfy the requirements briefly discussed at the end of Section 4. 3. First, real-time connectivity is achieved by implementing an Ethernet client on the hybrid reconfigurable device, taking advantage of the integrated MAC controller. In this manner, we are able to communicate order to the deposing system, but the totality of the program resides now in the embedded platform, reducing the communication latency.