dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments Authors warmly thank,  Olivier Jaillon  and  Thomas Vannier  from  Genoscope  ( CEA -IG -LAGE ) and  Stéphane Robin  from  INRA AgroParisTech  for providing their technical, biological and statistical expertise, as well as feedback during the conception of this manuscript. We thank the  GenOuest BioInformatics Platform  that provided the computing resources necessary for benchmarking.
According to the latest studies, the French population witnesses a high level of elderly. It follows from this phenomenon health troubles, fragility, and for some people suffering from cognitive problems, a daily need of monitoring and tracking in the fugues cases. It is in this context that comes our research program SACHA (Search and Computerize Human Acts). Our ambition is to develop an electronic patch able to trigger alarms, detect falls and provide geolocation service. Our studies were focused on the conception and the integration of different antennas and functionalities of this system in aim to ensure a good compromise "integration/performances". Several prototypes have been tested and validated in a nursing home.
For our design, it was chosen to ensure both high integration with acceptable performances. For a PIFA, The length of the radiating arm must be equal to the quarter of the wave length (λ/4). This criterion is not compatible with the miniaturization constraints of the patch for the ISM and L1 GPS bands: λ/4 = 8. 64 cm @ 868 MHz and λ/4 = 4. 76 cm @ 1575. 42 MHz. To resolve this technological challenge, a miniaturization technique based on the use of meanders was adopted (Figure  4 ). This method consists of folding the radiating arm many times to minimize the area occupied by the antenna. Modeling works using RF software ADS (Advanced Design System) [13] and HFSS (High Frequency Structural Simulator) [14] were conducted to design the antennas and study the influence of different physical parameters: layers stacking, type of materials, dimensions, meanders form, distance between meanders, coupling phenomena… The ISM and GPS antennas designs using HFSS software are presented in Figure  4.
Design of a Printed Coil for Wireless Power Transfer The proposed coil is composed of two layers of copper with a thickness of 17 µm separated by a 50 µm of polyimide substrate. The coil dimensions were chosen to meet the battery area (40 × 18 mm 2 ). The Cu tracks have a width of 520 µm and they are separated by a spacing of 80 µm. Figure  11  presents a 3D view of the proposed printed coil obtained using ADS software. The two layers of copper are connected in series using vias. From Figure  12 , we can notice that simulations predict a self-resonance frequency of 5. 3 MHz obtained with ADS and 4. 9 MHz computed using HFSS. These values are compatible with the frequency operating range used by the protocol Qi (110 -205 kHz): they are much greater than the maximum value (205 kHz) and this property ensures constant values of the electrical performances (L, R, and Q) in this range.
For the charging frequency interval, the model simulated with ADS presents an inductance of 10. 74 µH, a resistance of 3 Ω, and a quality factor of 3. 37 @ 150 kHz. Concerning the results obtained with HFSS software, the coil has an inductance of 10. 71 µH, a resistance of 3. 25 Ω, and a quality factor of 3. 1 @ 150 kHz.
This operation was preceded by an evaporation phase of a seed layer Ti/Cu (100 nm/100 nm) needed for the electrolytic deposition of copper. The different technological steps of this process are presented in Figure  13. A prototype of the printed coil is presented in Figure  14  The printed coil was characterized using an impedance analyzer Agilent 4294A (Figure  15 ) to study the variations of the electrical performances (inductance, resistance, and quality factor) in function of frequency in aim to validate the simulated values computed using RF softwares. The measured results are plotted in the Figure  16 , the resonance frequency is shifted (3. 9 MHz) compared to the simulation results (5. 3 MHz obtained with ADS and 4. 9 MHz computed with HFSS). This frequency shift does not disturb the coil performances because it is still far from the frequency range used by the Qi wireless charger (110 kHz -205 kHz).
In  (Mehiaoui et al. , 2013; Woźniak, ) , the authors are interested in the optimization of deployment techniques from functional and platform models of realtime systems by using mixed integer linear program-ming (MILP). An MILP formulation is easily extensible, re-targetable to a different optimization metric and can easily accommodate additional constraints or legacy components  (Mehiaoui et al. , 2013). There are many programming languages designed for the development of real-time systems such as POSIX (Portable Operating System Interface)  (Lewine, 1991). The POSIX standard promotes portability of applications across different operating system platforms. The authors  (Obenland, 2000)  use POSIX in the development of software for real-time and embedded systems. The synthesis of a valid and optimal implementation model consists in building the set of tasks implementing the applicative functions while meeting all related real-time constraints.
There are also related approaches which generate complete real-time systems. In  (Pillai and Shin, 2012) , the authors deliver an approach called TASTE to enable the generation of a complete real-time distributed system. The authors in  (Pagetti et al. , 2011)  provide a framework that allows designers to automatically generate by the Prelude language, a set of real-time tasks that can be executed on a uniprocessor architecture. Nowadays, many research works have been proposed to develop reconfigurable systems. The authors in  (Gharsellaoui et al. , 2012)  propose an approach that deals with reconfigurable systems to be implemented with different tasks under deadline constraints according to user requirements. In  (Krichen et al. , 2010) , the authors aim to provide an automated development process from modeling to implementation for the dynamic software part of reconfigurable systems.
There are many programming languages designed for the development of real-time systems. Among the most used real-time languages, we cite real-time java (RT-java) which aims to support the programming of real-time codes from different directions used by other software development platforms. POSIX (Portable Operating System Interface) is a standard written in terms of the C programming language. (Lewine, 1991). This standard facilitates the application portability that is why we adopt it as a target language to implement a reconfigurable real-time system in the current paper. The main contributions of this paper are four-fold. The first part consists in ensuring the respect of timing properties before the effective implementation of the real-time system (i. e. at the design level). Second, we are interested in the reconfiguration of realtime systems where the addition and removal of tasks are applied at run-time.
Third, we propose a multioptimization metric. Indeed, the proposed approach aims to minimize the reconfiguration time by avoiding a redundancy between the different implementations from one side. From the other side, it aims to minimize the response times of the real-time tasks in order to maintain the performance of the system. The fourth part, this work automatically generates a complete reconfigurable real-time system from the specification level by using the programming language POSIX. None of the existing works is solving all the four problems together.
PROPOSED APPROACH In this section, we present an overview on our approach and detail the structure of different modules involved in this work. We deliver an approach which automatically converts a high-level specification of a reconfigurable real-time system into an executable running on POSIX platform. Figure  1  shows the process of the proposed approach. As entry, the designer provides the specification model which defines the reconfiguration conditions, the applicative functions that must be executed under a considered condition and the temporal parameters of each function. This model presents the input of the task generator step which aims to produce an initial task model. Then,.
CONCLUSION In this paper, we have proposed an approach to support the development of reconfigurable real-time sys-  tems. This approach consists in defining the specification such as reconfigurable conditions, functions and temporal constraints, then it generates an initial task model. After that, a MILP integral formulation is provided to compute the optimal solution for minimizing redundancy. Finally, the proposed approach generates a POSIX-based program describing the reconfigurable real-time system. We have evaluated the performance of the three-step approach. The numerical results show that the integer programming model allows to minimize the reconfiguration time and response times. As a future work, we aim to extend our approach by considering multiprocessor systems and other optimization metrics.
The particular function and specificity of each protease are defined by their binding to a characteristic amino acid motif that forms a cleavage site in the protein target  [4]. Knowledge about proteases and their substrates and cleavage sites is scattered across publications and databases. These different resources do not permit cleavage site information to be retrieved from peptide sequence input automatically and thus elucidating the proteases implied in peptide production is difficult. The Proteasix tool  [5, 6] , is an open-source peptidecentric tool that can be used to predict automatically the proteases involved in the generation of proteolytic cleavage fragments (peptides). Proteasix is a tool that uses protease/cleavage sites (CS) associations established by either observations or predictions to suggest the proteases implicated in the generation of a peptide.
Proteasix does this by using the N-and C-terminal sequences of peptides that are reconstructed using information from the UniProt knowledge base  [7]  to identify the possible proteases that were involved in their generation  [5]. Observations of protease/CS combinations were extracted from CutDB  [8] , UniProt and the literature. When a previous observation has not been established, Proteasix calculates the probability of protease/CS association by using the MEROPS  [9]  and BRENDA  [10]  databases. Proteases exhibit varying binding affinities for amino-acid sequences, ranging from strict restriction to one or few critical amino-acids in given positions, to generic binding with little discrimination between different amino acids  [5]. The predictions currently made by Proteasix are agnostic as to the taxon of the organism whence the peptides come, the cellular location of the predicted proteases and the proteins they may cleave.
Competency questions for the PxO The PxO is written in the Web Ontology Language (OWL)  [11]  using the Protégé  [12]  version 5. 0. 0 beta 17 editor. In creating PxO we wished to undertake as little de novo ontology development as possible and to take advantage of the work already done in annotating gene products with the Gene Ontology (GO)  [13]. This implied a strategy of re-using relevant Open biomedical Ontologies Consortium  [14]  (OBO) ontologies where possible, together with relevant annotations. The choice of which of the OBO to use was driven by a set of competency questions (CQ) that the PxO should fulfil. Once chosen, relevant portions of the ontologies were taken and extended in a way that accommodated the CQ, making appropriate commitments to the ontology used. The resulting PxO was then evaluated against the CQ.
Reuse of ontologies from OBO To enable these competencies to be answered the PxO reuses parts of some of the OBO; PxO uses the OWL  [11]  versions. After downloading the OWL files, a selection of class names (without deprecated classes); class expressions; class definitions; and annotation assertions were extracted. Where only a portion of the source ontology was required to support the CQ in PxO, we programmatically extracted a top-module  [16]. A top-module is used as in the PxO only a restricted query supporting a CQ needs to be answered, rather than a query that necessitates all entailments from a signature to be preserved. The following OBO or their parts were used in PxO: 1. The Protein Ontology (PRO)  [17]  -Reuse of Protein(PR:000000001) and proteolytic cleavage product(PR:000018264) that are both subclasses of PRO's amino acid chain (PR:000 018263).
Annotation assertionsprovide the means to associate aditional information with an entity, like an exact synonym (oboInOwl:hasExactSynonym), a database cross reference (oboInOwl:hasDbXref ), or a definition (IAO:0000115). When a protein taken from the UniPro-tKB has a MEROPS specificity matrix, annotation assertion axioms are used in PxO to represent this data. However, the probability for a protease to cleave a protein substrate is calculated outside of the PxO, although using the annotation properties and values in the PxO.
PxO in use There are two methods to find the protease classes in the PxO: 1) use an automated reasoner like ELK  [31]  to infer which proteins are proteases (see the Protease defined class in the previous section); or 2) use the SPARQL 1. 1 query language  [32]  to create a SELECT query (Q0) that retrieves the OWL protein classes with a GO assertion for peptidase activity (GO:0008233) or any of it's children. Likewise, using DL queries with ELK or SPARQL SELECT queries, the proteins that are endopeptidase, aminopeptidase or carboxypeptidase can be obtained. The essence of the Proteasix algorithmis given below, which exploits the PxO ontology, and uses the competency questions CQ. The algorithm assumes that protease cleavage of substrate proteins is directed by short amino acid motifs, from two to eight amino acids of the type (Pn.
)P1 -P1'(. Pn'), with the scissile bond between P1 and P1' residues  [5]. Residues towards the N-terminus of the substrate are on the non-prime side and numbered as P1 P2 P3 P4 and so on; while residues towards the C-terminus are on the prime side and numbered as P1' P2' P3' P4' and so on  [33]. STEP 1: User input -For each peptide, the end-user provides: a) the peptide identifier; b) the UniProt Accession Number (AC) or identifier (ID) of the parent protein from which the peptide is derived; c) the start amino acid position with respect to the parent protein's sequence, i. e. P1' of the N-terminus CS; and d) the end amino acid position with respect to the parent protein's sequence, i. e. P1 of the C-terminus CS. STEP 2: Reconstruct N-and C-terminus CS -Each OWL protein class created from the UniProtKB (Swiss-Prot/TrEMBL) has among others the following annotation properties: oboInOwl:id for AC; oboInOwl: hasAlternativeId for ID; and PxO:hasSequence where the amino acid sequence (sequence for short) of the protein is stored.
Nevertheless, if PxO can help give confidence to Proteasix's predictions then it is a help. A further limitation comes in the ability to predict cleaveage sites in Proteasix. Proteases exhibit varying binding affinities for amino-acid sequences, ranging from strict restriction to one or few critical amino-acids in given positions, to generic binding with little discrimination between different amino acids. The MEROPS database  [9]  lists such information. When available, MEROPS specificity weight matrices were added to PxO. The MEROPS specificity matrix shows how frequently each amino acid occurred at each position in the cleavage site. Matrices were further transformed into Probability Matrices, by dividing the number of occurrences for each amino acid in each position with the total number of observations.
Acknowledgements This work was supported by a grant from the  European Union Seventh Framework Programme  ( FP7/2007-2013 ) for the sysVASC project under grant agreement number  603288  and by Pretreat  H2020-MSCA-RISE-2015  (grant agreement number  690966 ). Original development of Proteasix was supported by the grant ProteasiX  FP7-PEOPLE-2011-IEF (300582 ), Pretreat  H2020-MSCA-RISE-2015 (690966 ) and the  Fondation du Rein sous égide de la Fondation pour la Recherche Médicale  et ses partenaires, grant number GENZYME 2014 FDR-SdN/FRM. The work reported here was also supported by the  EPSRC  project:  WhatIf: Answering "What if. " questions for Ontology Authoring, EPSRC reference  EP/J014176/1.
Static auto-tuning performance is target-specific. In average, the performance portability of statically auto-tuned code is poor when migrating between different micro-architectures  [1]. Hence, static auto-tuning is usually employed when the execution environment is known. On the other hand, the trends of hardware virtualization and software packages in general-purpose processors result in applications underutilizing the hardware resources, because they are compiled to generic micro-architectures. Online auto-tuning can provide better performance portability, as previous work showed in server-class processors  [2]. Ahead-of-time auto-tuning. In recent Android versions (5. 0 and later), when an application is installed, native machine code is generated from bytecode (ahead-of-time compilation).
With deGoal  [9] , in an offline setting, we generated various kernel versions, by specializing the dimension and auto-tuning the code implementation for an ARM Cortex-A8 and A9. The auto-tuned parameters mainly affect loop unrolling and pre-fetching instructions, and are detailed in Section 3. 1. Figure  1  shows the speedups of various generated kernels in the two core configurations. By analyzing the results, we draw several motivating ideas: Code specialization and auto-tuning provide considerable speedups even compared to statically specialized and manually vectorized code: Auto-tuned kernel implementations obtained speedups going up to 1. 46 and 1. 52 in the Cortex-A8 and A9, respectively. The best set of auto-tuned parameters and optimizations varies from one core to another : In both cases in Figure  1 , there is a poor performance portability of the best configurations between the two cores.
Parametrizable function generator New versions of functions are generated by a tool called deGoal. It implements a domain specific language for run-time code generation of computing kernels. It defines a pseudo-assembly RISC-like language, which can be mixed with standard C code. The machine code is only generated by deGoal instructions, while the management of variables and code generation decisions are implemented by deGoal pseudo-instructions, optionally mixed with C code. The dynamic nature of the language comes from the fact that run-time information can drive the machine code generation, allowing program and data specialization. deGoal supports high-performance ARM processors from the ARMv7-A architecture, including FP and SIMD instructions. A set of C functions were also created to be called in the host application or inside a function generator to configure the code generation, allowing the evaluation of the performance impact of various code generation options.
Longer vectors may benefit code size and speed, because instructions that load multiple registers instructions may be generated. • Data pre-fetching stride (pldStride): Defines the stride in bytes used in hint instructions to try to pre-fetch data of the next loop iteration. Given that the dimension is specialized (run-time constant), we know exactly how many elements are going to be processed in the main loop. Hence, between the lines 5 and 21, the pair of deGoal instructions loop and loopend can produce three possible results, depending on the dimension and the unrolling factors: 1. No code for the main loop is generated if the dimension is too small. The computation is then performed by a leftover code (not shown in Figure  3 ). 2. Only the loop body is generated without any branch instruction, if the main loop is completely unrolled.
In the lines 10 to 13, the last auto-tuned parameter affects a data pre-fetching instruction: if pldStride is zero, no pre-fetching instruction is generated, otherwise deGoal generates a hint instruction that tries to pre-fetch the cache line pointed by the address of the last load plus pldStride. Besides the auto-tuning possibilities, which are explicitly coded with the deGoal language, a set of C functions can be called to configure code generation options. In this work, three code optimizations were studied: • Instructions scheduling (IS): Reorders instructions to avoid stall cycles and tries to maximize multi-issues. • Stack minimization (SM): Only uses FP scratch registers to reduce the stack management overhead. • Vectorization (VE): Generates SIMD instructions to process vectors. Most of the explanations presented in this section were given through examples related to the Streamcluster benchmark, but partial evaluation, loop unrolling and data pre-fetching are broadly used compiler optimization techniques that can be employed in almost any kernel-based application.
Previous work proposed online auto-tuning in DSCPs, usually regenerating code in idle cores or machines. ADAPT, IODC and SiblingRivalry required several minutes, hours or runs to obtain performance gains over static compilation. Active Harmony obtained speedups after only two minutes, but using idle cores in a cluster of computers. Instead, our work is the first to focus on embedded processors, implementing online auto-tuning in short-running kernels, and obtaining positive speedups after hundreds of milliseconds, without extra cores to regenerate code and including all overheads. UNIDAPT has also a very low run-time overhead, because good code versions are statically found through iterative compilation, however with radical changes of micro-architecture or input data size, static multi-versioning may not be able to obtain the desired performance with a small number of versions or may lead to code size explosion.
In this chapter we present the MODAClouds Model-Driven Development approach to support the design of multi-Cloud applications with guaranteed QoS. The proposed approach relies on a set of tool-supported domain-specific languages (DSLs) collectively called MODACloudML. MODACloudML enables managing multi-Cloud applications in a Cloud provider-independent way while still exploiting the peculiarities of each IaaS and PaaS solution. By supporting both IaaS and PaaS, MODACloudML enables several levels of control of multi-Cloud applications by the Models@runtime engine (see Chap. 9): (i) in case of executing on IaaS or white box PaaS solutions; full control with automatic provisioning and deployment of the entire Cloud stack from the infrastructure to the application, or (ii) in case of executing on black box PaaS solutions; partial control of the application (note that if parts of the multi-Cloud application executes on IaaS or white box PaaS, MODACloudML provides full control of those parts).
3. 1. First, users specify, through the IDE, the application architecture and all its functional aspects as well as QoS requirements. In the next stage, designers may decide to refine these models, for instance, by selecting a certain class of database services and certain kinds of computational resources. In MODAClouds, this process is achieved by QoS engineers supported by the Line and SPACE 4Clouds tools (see Chap. 4). Line can be used to estimate the performance of the identified solution (e. g. , response time and throughput), whilst SPACE 4Clouds can be used to find the minimum-cost multi-Cloud deployment configuration. At this stage, an iterative process may be started to tune the models of the application until a suitable solution is identified. The output of this process is a CloudML deployment model that can then be used by the application provider to automatically deploy the multi-Cloud application.