dataesr/scientific-paragraphs-categorization huggingface dataset:
The result of this search, including the objective values, the execution time and the number of instances, as well as the best found configuration for each rts are then stored in an RTS database. Finally, a classifier groups the rts's with similar or identical best found configurations into scenarios using a similarity score that is computed by aggregating the closeness of system configurations. The clustering limits the number of scenarios and thus reduces the associated runtime overhead. A selector then chooses the best configuration for each scenario for the specified objective. The knowledge obtained during DTA, such as the best-found system configurations for individual scenarios is encapsulated in a tuning model (TM). For production runs, the tuning model is forwarded to the READEX Runtime Library (RRL), which performs runtime tuning by detecting the scenarios and dynamically switching to the best configurations for upcoming rts's.
The library updates a timer counter every 10 seconds to collect energy measurements. This is a static tuning approach where the CPU frequency remain unchanged for a whole program region. In the READEX approach, both the CPU frequency and uncore frequency can be configured dynamically for all the program regions. The MATE  12  framework implemented a tuning environment to tune applications dynamically during runtime. Here, the application monitoring takes place as well as detecting performance bottlenecks. Then, the application is adapted dynamically due to the behavior changes without recompiling or re-running. The tuning is driven by aspect-specific tuning components. For example, in master/worker type applications, the number of workers is adapted to the number of tasks. However, the framework only limits the tuning approach to MPI processes.
In contrast to READEX, the MATE framework focuses on performance improvements. It is the responsibility of the expert to provide the aspect-specific tuning components. READEX provides a general tuning strategy independent of the application structure. Calore et al  13  used a static Dynamic Voltage and Frequency Scaling (DVFS) to tune modern processors, namely, an NVIDIA K80 Graphics Processing Unit (GPU) and an Intel Haswell CPU. They target the energy costs of HPC applications by tuning CPU and GPU frequencies. In this work, they focused on a hardware tuning approach. Although they considered a few software tools for energy optimization, they preferred to avoid the software approach, and thus could not exploit, eg, application tuning parameters. The ANTAREX project 14 uses a domain-specific language (DSL) for tuning applications targeting energy-efficiency on multi-core CPUs and accelerators.
This DSL approach uses adaptive and auto-tuning strategies to enforce runtime application tuning. The DSL template interacts with the runtime resource and power manager to configure software tuning parameters (such as application parameters, code transformations, and code variants) for the application regions. The additional compilation step is required to translate from the DSL template into the target language. This DSL approach is imposed only on ARM-based multi-cores and GPGPUs, while the READEX tuning approach targets different HPC platforms. Furthermore, READEX targets standard HPC applications, while ANTAREX requires applications to be programmed in the DSL. The use of domain knowledge in the READEX methodology for energy efficiency significantly extends our current dynamic tuning approach.
As the first step, the application expert specifies the application structure, which includes the phase region and additional program regions that should be considered for tuning. Then, the application dynamism is detected with the help of a tool called readex-dyn-detect. Based on the result of the dynamism detection, READEX tuning is either stopped in case of no available dynamism, or the application expert may identify application characteristics to support DTA in case there is enough dynamism. These characteristics are marked by identifiers, such as region identifiers, phase identifiers, and input identifiers. The identifiers will allow DTA to generate a more sophisticated application tuning model by using a specific setting of the tuning parameters for certain application characteristics.
While the region and phase identifiers are specified in the source code via Score-P macros, input identifiers are added in files accompanying the original input file. Finally, the Application Tuning Parameters (ATPs) are specified in the application source files via Score-P macros calls to the ATP library. When the application is executed, the ATPs are written to the ATP description file and are then read by PTF at the start of the analysis. Separate tuning model files are generated for each input specification, which are then merged into the final application tuning model. DTA terminates after processing all the inputs. The generated merged tuning model is then read during the runtime tuning stage.
Region and phase specification The READEX approach is based on tuning program regions. The decomposition of the program into program regions is typically defined by the syntax of the programming language. Common types of regions are subroutines, loops, and structured blocks. Besides standard regions, the application expert might be able to identify additional regions that are not represented as a standard region but may have interesting characteristics or tuning potential. Typical use-cases for user regions are as follows. • User regions can combine several calls to different functions, which belong together and are too fine granular for switching the configuration individually. • They can identify certain parts of an algorithm that would otherwise not be a target of tuning because this part is not represented by a standard region type of the programming language.
• If instrumentation is too fine granular and leads to a lot of overhead, automatic instrumentation can be switched off and significant regions can be manually instrumented. The READEX tuning approach targets applications that have a central progress loop, called a phase region that iteratively performs some computation. The phase region is a program region that defines the phases of execution. Although this loop can be implemented by a standard loop construct of the programming language, automatic detection of the phase region is difficult. Score-P 7 offers an online access phase region to enable external tools to configure Score-P dynamically when a phase is started. This configuration mechanism is used in DTA to perform experiments for evaluating different system configurations. Both the start and the end of the phase region entail a barrier synchronization of all participating processes when an online tool like PTF is connected to Score-P.
The phase region and user regions are defined in READEX using Score-P macros. These macros can enclose arbitrary code and are instrumented automatically. As a result, the annotated regions can be handled by the READEX tool suite like any other program region. First, the region handles are defined with the macro SCOREP_USER_REGION_DEFINE. Then, the start and end of the user region are marked with the macros SCOREP_USER_REGION_BEGIN and SCOREP_USER_REGION_END, while the phase region is enclosed in the macros SCOREP_USER_OA_PHASE_BEGIN and SCOREP_USER_OA_PHASE_END.
Application Tuning Parameters In addition to hardware and system tuning parameters, READEX also targets application level parameters, ie, parts of the code itself, which could be used as tuning parameters. The simplest example of this is the case where different implementations of the same algorithm are available, each having its own impact on performance and energy. Some examples of application tuning parameters include, ie, choosing between different decomposition algorithms, preconditioners, or also blocking factors. The aim of using Application Tuning Parameters (ATPs) is to exploit the possibility to switch between the different implementations or, in a more general sense, the possibility for READEX to choose between code level alternatives at runtime. In order to optimize energy efficiency by choosing the best settings for ATPs, the application developer needs to pass the knowledge on to the tuning system.
Domains An application source code may contain several ATPs. Ideally, these would be independent from each other, enabling independent tuning. In practice, this is not always the case; the values of a parameter may depend on those of another one, and hence, this would translate into the notion of constraints between parameters. Therefore, the application developer may indicate to READEX that a number of parameters have constraints between them by putting them in the same domain. In the API, domain declaration is included within the parameter declaration call, where both parameter name and domain name need to be supplied. In addition, if no domain name is supplied, the parameter is assigned to the default domain. LISTING 3 ATP library API functions.
Use-Case Listing 4 illustrates how the ATP library API functions can be used to declare control variables from the code as application tuning parameters. It also shows how constraints between these variables can be declared. Lines 4 to 7 and 25 to 29 in Listing 4 provide examples of ATP declaration and value retrieval where the ATP mesh is declared and tied to the control variable atp_cv. The same is done for the ATP solver with the control variable atp_ms.
Score-P After the pre-analysis steps, the significant regions are annotated using Score-P macros (Section 4. 1. 1), and if needed, region identifiers are specified (Section 4. 2. 1). Score-P provides a measurement infrastructure for profiling, event trace recording, and online analysis of HPC applications. The Periscope Tuning Framework (PTF) then executes one phase of the application and requests for objective values with the default setting of the tuning parameters. The measurements for each rts are returned to the PTF analysis agents from Score-P via the Online-Access Interface. The Online Access Interface allows online tools like PTF to connect to the Score-P monitoring infrastructure linked to the application processes, when the phase region is touched the first time. The important program regions are then stored in PTF.
ATP Library The ATP library provides an annotation API to the application expert. The API allows to mark specific chosen control variables in the source code as application parameters. It also provides the instrumentation interface, which allows to assign the parameter values generated by PTF and prepared by the runtime library to the right control variable. At the end of the first phase of the application execution, the ATP library generates the ATP description file in the JSON format, which consists of details about the declared application parameters. rts's as different scenarios, they can be merged into one scenario to reduce the overhead of scenario detection and switching at runtime. For each scenario, a selector is generated that returns the best configuration for that scenario with respect to the chosen objective.
Specifically, one of the main hurdles to overcome is combining the categorical data from genetic markers with the continuous data from most other markers (e. g. otolith chemistry, morphometrics)  13. On the other hand, Bayesian approaches dealing with probabilities are able to define realistic models that incorporate uncertainty at various levels  26, 36, 60  , and handle scenarios with unknown sources to a mixed population  26  , as seen here with the infinite mixture model. To date, studies have combined the information resulting from independent analysis of different datasets  31  , synthesized multiple marker information in quantitative or qualitative indices  32  , and developed approaches that allow integration in specific contexts or add information in a priori classification-based methods  11.
We used multidimensional scaling (MDS) analysis to visualize data in reduced space and examine the occurrence of potential groupings, using Vegan package in R. Second, we adapted the unconditional Bayesian mixture model approach (PopR package, https://github. com/Philipp-Neubauer/ PopR) from Neubauer, et al. 26. This approach implements a Dirichlet process mixture that allows unknown (infinite) sources and estimates the most likely number of sources represented in a mixed sample. However, the core functions of PopR are implemented in Julia, which brings gains in computation time but opens up a number of issues. In particular, Julia is a recent programming language and is still being actively developed rendering its functionality and synchronization with R unstable. Thus, to address these issues, the unmixR package was developed translating and updating all of PopR's Julia components to C++, making extensive use of the Rcpp and RcppArmadillo packages.
This removed the need for an external interpreter and the creation of intermediate files (unmixR package, https://github. com/zeloff/unmixR). No changes were made to the original PopR algorithms. Preliminary analysis of the otolith chemical data indicated that best results were obtained by using both elemental and isotopic variables therefore the full set of variables was used for subsequent analyses. All data treatment and statistical analyses were made in R  66. Simulation parameters for the unmixR analysis were 2000 iterations and thinning was set to 1. Microsatellite markers and genotyping. Total genomic DNA was extracted from fin clips using a standard phenol-chloroform extraction protocol  67. Twelve microsatellites (Nplaf8, Nplaf14, Nplaf15, Nplaf23, Nplaf24, Nplaf25, Nplaf27, Nplaf28, Nplaf30, Npalf33, Npal35, Nplaf51) were grouped into 3 multiplex PCR and genotyping groups  68.
PCR reactions were run with the Type-it Microsatellite PCR Kit (Qiagen TM) containing 5 µl of Master Mix, 1 µl Q-solution, 2 µl RNase-free water, 1 µl of primer mix and 1 µl genomic DNA (c. 50 ng). Amplification conditions were: 95 °C for 10 min followed by 40 cycles of 95 °C for 30 s, 55 °C for 30 s and 72 °C for 1 min and an extension step of 10 min at 72 °C68. Samples were genotyped in an ABI PRISM 310 Genetic Analyzer and fragments were sized with GeneScan-500 LIZ Size Standard using GeneMapper 3. 7 (Applied Biosystems), and blindly scored by at least two readers to minimize genotyping errors. Microsatellite markers data analysis. Microsatellite loci were first tested for the presence of null alleles and genotyping errors like null alleles, stuttering and large allele dropout using MICRO-CHECKER 2.
2. 3  69. Genetic diversity was measured as the mean allelic richness (AR) calculated and corrected for sample size by rarefaction using HP-Rare 70 ; observed heterozygosity (H o ), unbiased expected heterozygosity (H e )  71  both per loci and multilocus, mean number of alleles across loci (N A ) using ARLEQUIN 3. 11  72  ; and fixation index within samples (F IS ), inferred using GENETIX 4. 05. 2  73. Deviations from HWE and linkage disequilibrium were tested using ARLEQUIN per locus and Genepop 3. 1  74  for all loci, using 100 000 Markov chain and 1000 dememorization steps. ARLEQUIN software was also used to calculate population differentiation through pairwise comparisons of F ST (fixation index between samples and 100 000 steps for Exact tests) and p-value significance was assumed using the Bonferroni correction for multiple comparison tests.
Isolation by distance (IBD) was tested by comparing pairwise F ST values against the shortest waterway distance between collection locations of P. flesus using a Mantel-test implemented in the Vegan package in R. Statistical significance was assessed with 1000 permutations of the data. Patterns of differentiation were visualized by principal coordinates analysis (PCoA), a multivariate technique that allows major patterns within a multivariate dataset of multiple loci and samples to be discerned. This analysis was computed using GenAlEx 6. 5  75. A Bayesian clustering method (STRUCTURE 2. 3. 4)  76 was used to infer possible genetic clusters, with parameters of 1000000 Monte Carlo Markov Chain interactions following a burn-in period of 1000000 for K = 1-7, as number of tested clusters, and replicated 20 times.
Evanno's index AK  77  was evaluated using STRUCTURE HARVESTER 0. 6. 93  78. Integrating genetic and chemical markers. Due to the differing nature of otolith chemistry data and genetic data, a straightforward integration of the datasets is challenging  11, 36. The potential benefits of integrating the two markers were evaluated graphically with a three-dimensional scatterplot combining the probability of each individual belonging to one of the identified genetic clusters and the MDS matrix scores from individual otolith data. Thus, the data used for each individual originated from the results obtained using the full data sets for each marker. One advantage of this integrated graphical approach relies on the combination of results from continuous and categorical data without requiring re-analysis of the data.
Acknowledgements The authors wish to thank all who donated samples and were involved in sampling and fish collection, in particular  Audrey Geffen ,  Zuzanna Mirny ,  Ann-Britt Florin ,  Peter Wright ,  Jan Jaap Poos ,  Gianna Fabi  and  Efe Uluturk. We also thank  José Loff  ( phiStat, Statistical Consulting ) for his contributions to the development of the unmixR package and  Niall Slowey  for the isotopic analysis. We would also like to thank the two reviewers for their input to improve previous versions of this manuscript. This study had the support of the  Fundação para a Ciência e a Tecnologia (FCT)  via  UID/MAR/04292/2013 ,  PTDC/AAG-GLO/5849/2014  and  PTDC/MAR-EST/2098/2014. PRS and SET were funded with FCT postdoctoral grants ( SFRH/BPD/95784/2013  and  SFRH/ BPD/84278/2012 , respectively), and RPV via the  Investigador FCT Programme 2013  ( IF/00058/2013 ) and the  "Programa Nacional de Amostragem Biológica " (Data Collection Framework, namely for the fisheries sector).
This decreasing of the ratio of offloaded tasks is due to the wireless bandwidth in the AP. We also note that the ratio of the offloaded tasks depends on the application characteristics when the applications require a lot of computing resources and transmit a huge amount of data (Linpack and PIBENCH) the ratio of offloaded tasks is lower. As a result, choose the placement of the tasks, remote cloud or cloudlet, depends on many factors, in the figures we noticed that the computing resource allocation in the remote cloud, the computing resource allocation in the cloudlets and the characteristics of the application affect directly the placement of the offloaded tasks.
Inspired by the offloading platforms from literature  [15, 18, 17, 28] , our offloading middleware uses component-based design pattern  [29]. For instance, the client offloading middleware has three main functions: the profiler function, the offloading decider function and the communication function. The objective of the profiler is to collect the information related to the application (i. e. task), such as the hardware usage and the network bandwidth. This information is stored in a local database in order to be used by a second function, which is the offloading decider function. The main objective of the offloading decider function is to decide whether the task should be executed locally or offloaded to the edge or to the remote Cloud. We implemented our offloading policy within this function.
The task handler is also in charge of maintaining an isolated execution environment between the received tasks by executing each task in a separated and the possibility to execute these applications by setting some parameters might explain such a gap. Notice also that due to our implementation of these three bench applications as fragments within the same Java Android application, the quantity of the downloaded data is always equal to the size of the APK source file (5427. 2 bytes). Among the three bench applications, Linpack is the one that generates the lowest number of CPU cycles. Under Full configuration, it is also the one that leads to the highest number of CPU cycles. that we have varied from 1. 2 Kbps to 8 Mbps. Notice that logarithmic scale is used for x and y axis. As one can see, when the offered bandwidth is restricted to less than 500Kbps, the lowest energy consumption is obtained for local execution.
We can deduce that the local edge offers higher CPU capacity than those provided at the clouds, despite the fact that both have allocated 2vCPU resources. This discrepancy illustrates the impact of the heterogeneity of the hardware and the software technologies, which are used in a multi-tier mobile edge computing infrastructure. This observation holds for Linpack and CPU-Bench, as well 1. The corollary to this finding is that in case of offloading, the remote location that minimizes 1 To save space, we choose not to show the completion time for Linpack and CPU-Bench     When a task is executed locally, the measured energy is also quasistationary during the processing time. However, as illustrated in figures 6, 7, 9, 10, 11, 12 13, 14 and 15 the difference of consumed energy between local and remote execution is of several order of magnitude.
Conclusion In this paper, we propose a new computation offloading policy in twotier MEC environment. The proposed offloading policy decides which users should offload, to which offloading server and allocated the wireless bandwidth accordingly. First, we formulate the problem as a Non-Linear Binary Integer Program (NLBIP). Then, we propose an efficient heuristic to solve the problem using Lagrangian decomposition approach. The proposed heuristic uses a branching algorithm to maximize the bandwidth allocation and minimize the energy consumption. The numerical results show performance improvements in terms of the energy consumption compared to existing offloading policies under different scenarios. Finally, we implemented our offloading policy on a real testbed. Using this testbed, we were able to evaluate our offloading decision policy for three real Android OS applications, with different traffic patterns, resource demands and multi-users context.
Discussion The first purpose of the experiments was to characterize the benchmark applications: Linpack, CPU-Bench and PI-Bench. Each of these applications was parameterized in order to study the system under three CPU resource requirement situations: 1) Light, 2) Medium and 3) Full. Precisely, Linpack is a software that performs matrix calculations. To generate light processing requirements, we parameterized Linpack with 17 square matrix sizes, ranging from 1 to 17. Medium and full configurations were generated by multiplying the above matrix sizes by a factor of 40 and 70, respectively. CPU-Bench is a software that generates a random floating point and a random integer of a predefined size n. To generate light, medium and full configurations, we set n = 10 6 , 10 7 and 10 8 , respectively.
e. by allowing some forms of diet disobedience, and persuade the user to minimize such acts of disobedience  (Anselma et al. , 2017)   modules (Fig. 1 ), that are a mobile app (described in Section 2), a numerical reasoner that decides the compatibility of a specific dish in some point of the diet  (Anselma et al. , 2017) , an information extraction module used to compute the nutrient values of a specific recipe, a NLG service that converts the results of the computing to textual form  (Anselma and Mazzei, 2017). The reasoning module of MADiMan overcame reasonable baselines in different simulation experiments  (Anselma et al. , 2017 (Anselma et al. , , 2018)). We realized the CheckYourMeal! app in order to evaluate the performance and the usability of the whole architecture with human-evaluation into a realistic context.