dataesr/scientific-paragraphs-categorization huggingface dataset:
In our study, we found that the SENS2 had higher discriminating power in both classical statistical analysis and ML analysis. However, we did not investigate whether our method is able to classify patients according to their risk of chronicity. The differences between  [12]  and our study are mainly due to the different experimental protocols. Although we use a sagittal plane test, our test is performed over a longer period of time (60 s of recording) with a sensor recording frequency (100 Hz) five times higher than  [12]. The amount of data collected this way allowed us to analyze the complexity of the movement variation. In our study, we did not measure the center of mass motion, and our NLBP population consisted of only 20 subjects, which severely limits the learning ability of the ML process.
However, both studies demonstrate the interest in using ML in spinal kinematic analysis to identify and assess CLBP patients. It remains to be shown that these tools are also useful for the therapeutic follow-up of these patients. As a counterpoint to using biomechanics to better understand LBP conditions, a metamodel created with the help of a panel of 27 multidisciplinary experts is used to illustrate the number of factors that contribute to LBP, disability, quality of life, and other outcomes as well as the number and strength of their interactions  [42]. With a problem as multifactorial and complex as LBP, the authors of this counterpoint emphasize the need to integrate the interactions of biopsychosocial factors into research to improve the management of patients with LBP. This suggests that in future works, it will be essential to integrate these biopsychosocial factors and the state of the internal environment into the raw IMU data and the variability indicators computed from them when performing a b&r test to better understand its discriminating power.
The identification of genetic variation constitutes a central part of population genomics and quantitative genomics studies. Single nucleotide variations (SNVs) are particularly informative for inferences of selective sweeps, demographic history, and phylogeny, as well as for quantitative analyses such as genome-wide association studies and quantitative trait loci. These approaches rely on mathematical models with the assumption that natural selection is not directly acting on the analyzed genetic variations. Therefore, unbiased variant calling from a large quantity of sequencing data is indispensable. The improvement in high-throughput sequencing techniques has enabled the generation of large-scale genomic SNV datasets from multiple samples. Several popular software packages have been developed for variant calling.
GATK HaplotypeCaller provides two ways of filtering. The first option is hard filtering, which discards SNVs if variant scores are lower or higher than certain thresholds, which are typically determined by humans. These variant scores include QD (the variant quality score normalized by read-depth), FS (the phred-scaled probability of strand bias), SQR (strand bias calculated by symmetric odds ratio test), MQ (the root mean square of mapping quality of reads mapped to a nucleotide), MQRankSum (the normalized difference in mapping qualities between reference and alternative alleles), and ReadPosRankSum (the normalized difference in position between reference and alternative alleles within the reads)  5. The second option is VQSR (Variant Quality Score Recalibration). In this method, the threshold of variant scores is determined by machine learning from truth and training resources generated from a reference SNV data set.
Such truth and training resources do not exist in the vast majority of non-human species. In this study, we compared the performance of variant calling from P with varying d in an insect population between GATK HaplotypeCaller and Bcftools mpileup using benchmark analyses. Since a reference SNV data set is not available for most non-human species, we performed benchmark analysis from a simulated insect population, which mimics Drosophila melanogaster.
09-81. 36%). The recovery rate rapidly decreased as d increased (ρ = -0. 984, p = 0. 002369) (Fig. 2B ). Furthermore, the proportion of false positives was 0. 14-0. 1910%, which was much higher than that of Bcftools mpileup (0. 0023-0. 0286%). We also used VQSR filtering, which is based on machine learning with a training dataset to choose optimal criteria on variant scores, to perform filtering from the SNV data of GATK-HaplotypeCaller. For this purpose, we generated different sets of Illumina reads from the same 20 individuals with diploid genomes. The recovery rate was comparable (89. 28-89. 84%) to that of Bcftools mpileup, and it was negatively correlated with d (ρ = -0. 986, p = 0. 002014). However, the proportion of false positives (0. 9906-1. 486%) was much higher than that of Bcftools mpileup, even higher than GATK hard filtering.
f scores calculated from P were highest at the filtered datasets of Bcftools mpileup (0. 9468-0. 9566), intermediate at GATK VQSR (0. 9398-0. 9462), and lowest at GATK hard filtering (0. 2485-0. 8965) (Fig. 2C ). Bcftools and GATK VQSR generated largely invariable f scores across d whereas f scores from GATK hard filtering rapidly decreased as d increased. Variant calling together with bwa-mem. We compared performance between Bcftools and GATK HaplotypeCaller using a different aligner, bwa-mem with high coverage data (40 × for each sample). The recovery rates were comparable between Bcftools mpileup (93. 71-94. 42%) and GATK HaplotypeCaller (94. 02-94. 96%) (Fig. 5A ). After filtering, Bcftools mpileup had the highest recovery rate (93. 29-93. 81%), followed by GATK VQSR (89. 90-91. 57%), and then by GATK hard filtering (86.
49-69. 85%) than Bcftools mpileup (62. 07-65. 21%) in unfiltered SNV datasets (Fig. 6A ). After filterings, the recovery rate was highest in GATK VQSR (66. 75-69. 22%), intermediate in Bcftools mpileup (52. 78-58. 18%), and lowest in GATK hard filtering (14. 03-56. 00%). GATK Haplotycaller had higher proportions of false positives (0. 915-2. 244%) than Bcftools mpileup (0. 058-0. 076%) in unfiltered SNV datasets (Fig. 6B ). After filterings, the proportion of false positives was highest in GATK VQSR (0. 726-1. 39%), intermediate in GATK hard filtering (0. 481-1. 076%), and lowest in Bcftools mpileup (0. 004-0. 02%). After filtering, f score was highest in GATK VQSR (0. 8156-0. 8482), intermediate in BCF mpileup (0. 7356-0. 8039), and lowest in GATK hard filtering (0. 1840-0. 7167) (Fig. 6C ).
Performance of BCFtools and GATK HaplotypeCaller. In the dataset based on the mapping by bow-tie2, when filtering was applied to the SNV data from Bcftools mpileup by discarding SNVs with variant calling scores less than 20, the proportion of false positives was reduced by 35-42% while the recovery rates were largely unchanged. When hard filtering was applied to the SNV data generated by GATK HaplotypeCaller, both the proportion of false positives and the recovery rates were substantially reduced. When VQSR filtering was used, the recovery rate was comparable with the filtering of Bcftools mpileup, while VQSR filtering had much higher proportions of false positives than Bcftools mpileup. The effect of d is slight in all cases with a single exception of GATK-hard filtering, which had severely decreased the recovery rates when d was high.
For example, when d was increased from 0 to 0. 02, the recovery rate was reduced from 0. 8948 to 0. 1809. f statistics show that the best result can be obtained from the filtered SNV dataset from Bcftools mpileup. We also found that repeats are the main source of false positives, especially for GATK HaplotypeCaller. Taken together, Bctfools mpileup performs better than GATK HaplotypeCaller in terms of recovery rate and the correctness at both raw and filtered SNV datasets. When bwa-mem was used for mapping, the same trend was observed with the exception that GATK had lower proportions of false positives (0. 018-1. 271%) than Bcftools mpileup (0. 0101-2. 304%) after filtering. It should be noted, however, that bowtie2 generated much lower proportions of false positives (0. 0023-0. 021%) than bwa-mem when Bcftools mpileup was used for variant calling.
When the coverage was low (5 ×) and bowtie2 was used for mapping, GATK VQSR and Bcftools mpileup had higher recovery rates, lower proportions of false positives, and higher f scores than GATK hard filtering after filtering, implying that GATK hard filtering had the lowest performance. Taken together, these results show that Bcftools mpileup outperforms GATK HaplotypeCaller after hard filtering, regardless of the software used for mapping or the coverage of reads, especially when d was high. GATK VQSR appears to outperform Bcftools mpileup only when coverage is low according to the f score.
Our result may appear to contradict previous papers showing that GATK HaplotypeCaller performs better for human data than Samtools/Bcftools mpileup. A majority of these studies assessed the performance by the comparison of an SNV dataset from a variant caller and another dataset ascertained by previous experiments. As mentioned by Heng Li, this comparison 'would only give us an estimate of the relative accuracy--if two pipelines are affected by the same artifact that a third pipeline does not have, then the third pipeline will appear worse even though it is in fact better. In addition, comparative studies usually measure the accuracy with summary statistics such as the fraction of calls present in dbSNP or the transition-to-transversion ratio. They do not tell us the wrong sites'  6. Indeed, obtaining correct SNVs positions across the whole genome is almost impossible from empirical data, thus evaluation of variant callers can be consequently biased.
Second, SNVs within repeats should be excluded for downstream analysis, especially for GATK Haplotype-Caller. Third, when GATK HaplotypeCaller is used, we strongly advise using reference genome sequences that are not highly diverged from an analyzed population. Fourth, if the QD score from GATK shows a unimodal distribution, hard-filtering according to MQ scores can effectively reduce false positives while the recovery rate is largely unchanged; Fifth, if the QD score from GATK shows a bimodal distribution, VQSR filtering should be used. If a training dataset for VQSR is not available, Bcftools mpileup can be used as an alternative. Sixth, if a researcher wants to minimize the proportion of false-positive SNVs, we recommend using bowtie2 for mapping, rather than bwa-mem.
In order to ease the early verification of uniprocessor real-time systems, the tool Cheddar provides a service that guarantees the applicability of a schedulability analysis method for a given architecture model. This verification service uses a catalog of design patterns. In this article, we propose to extend these patterns to multiprocessor architectures. Designing such extension is a challenge because the knowledge of both the software and the hardware architectures are essential to decide on the schedulability of a task set in that context. Indeed, parallel execution of tasks involves hardware resource sharing, that has in turn an effect on the task execution times. Currently, no general method is able to assess the schedulability of a high-performance multicore system with a limited level of pessimism, except if assumptions or usage restrictions are set to simplify the system analysis.
So, the research community is developing multiple schedulability tests based on various assumptions which constrain the task models and their execution platforms. In this article, we propose a framework based on Prolog that allows engineers to verify the conditions to apply a test are met. Prolog facts model the software and hardware architecture, and the inference engine checks whether these facts conform to a design pattern associated to a given verification method. The design pattern compliance framework is integrated with the Cheddar tool. Three examples of multiprocessor analyses illustrate the proposal. A scalability analysis shows the tool is able to verify the compliance of architectures composed of 600 tasks and 60 cores, in less than 140 s on a desktop computer.
Introduction In  [1] , the NIST has shown that 70% of the anomalies during the engineering of critical real-time systems are detected lately, leading to a high increase of their production cost. In such context, early verification of timing constraints with schedulability analysis can contribute to reduce this cost overhead. Many models and methods of schedulability have been proposed. However, due to the diversity and the rapid evolution of the runtime environments, due to the variability of the task models to deal with, schedulability analysis remains a difficult problem. The Cheddar project  [2]  aims to facilitate the application of schedulability analysis in the engineering practices of critical real-time systems. As part of the Cheddar project, the software framework of the same name aims at helping engineers to apply this analysis.
The framework is based on a set of design patterns. In particular, the design patterns discriminate the systems according to the deployment of tasks on the available computing units, but also according to the additional hardware resources these computing units use. The extension of the Cheddar tool in that way requires more than a simple update of the design patterns, because the modeling of the runtime environment may require to express detailed features about the underlying hardware architecture. We propose to express the software and hardware architecture of the system to verify as a set of Prolog facts, and the design patterns as Prolog rules that can be checked on the set of facts that models the system. The approach allows for easily appending new patterns. This ability is mandatory in a research context characterized by a high variability of the assumptions made in the different contributions.
Formalization of design patterns for schedulability analysis In  [3] , Gaudel formalizes the concept of design pattern previously used in Cheddar. The following sets together define a design pattern: 1. Environmental constraints. This set of constraints characterizes the runtime environment. It describes the hardware part of the architecture model and the software for the exploitation of its resources (operating system, device drivers etc. ). In his work, Gaudel focuses on a uniprocessor environment described by the applicability constraints of Table  1. Relations between design patterns, schedulability analysis methods, and architectures. We note that a given architecture may not be compliant with any model or that no analysis method may be applicable. However a schedulability analysis method may be applicable to an architecture whereas no design pattern is usable to guarantee its applicability.
Task communication and synchronization models Five models of communication and synchronization between tasks have been proposed in  [12, 22]. These models have been specified with aadl  [9] , a standard architecture language used in avionics, or with Cheddar-ADL  [25]  that is the native architecture description language of the Cheddar tool. Each of these models expresses an usual method of synchronization and communication that can be found in languages, standards or operating systems used by the actors of the real-time domain. Below, the parenthesized name associated to each model is defined for the purpose of later reference in this article.
Especially, the design pattern specifies the hardware architecture and/or the interference that the analysis method implemented in the Cheddar tool is able to take into account. From these inputs, the Design Pattern Compliance Checker program, called dp_check in the sequel, produces a list of design patterns the system architecture complies with. Next, this allows for selecting a list of analysis methods that can be applied to the system. Notice that the scheduling analysis by itself is driven only by the specification issued from the scheduling analysis model. The Prolog Mapping program generates a Prolog model from the relevant information of the schedulability analysis model used as Cheddar tool configuration; this information includes the list of the tasks, the list of the execution units, the scheduling parameters and protocols, the allocations of tasks on the execution units, and various parameters that influence the scheduling analysis.
Beyond this mapping, it detects whether the software architecture conforms to one of the software design pattern described in Section 2. 1. 2. The process assumes the consistency of the entity or attribute names extracted from the scheduling analysis model and those coming from the interference model; the hardware entities are considered to be the same if they have the same name in both models. The Prolog Mapping program is written in Ada, and reuses already existing functions from the Cheddar framework to parse the Scheduling Analysis Model and search the software design patterns. Implementing a new method into the scheduling analysis tool, might require additional parameters (e. g. the number of memory accesses of a task and their duration); in this case, the Prolog mapping program might need to be updated to reflect these new parameters as Prolog facts.
The dp_check program is a Prolog implementation based on Prolog facts and inference rules. Then, the set of facts is obtained by merging this Prolog model and the runtime interference model. The inference rules are the predicates dp  defined for each   design pattern (see Sections 4. 3 and 4. 4) and its constraints in the design pattern catalog. The dp_check main predicate sequentially checks the compliance of the system with all the design patterns specified in the catalog.
Multiprocessor analysis functions implemented in cheddar Prior to the redesign of the design pattern checking, the move to multiprocessor systems of the Cheddar analyzer required several updates to support multiprocessor scheduling protocols. First, we completed the modeling language used to express the architecture of the system to be analyzed. We add new entities that represent the multiple execution units, and their basic characteristics (the relative speed for instance). It was also mandatory to extend the communication/synchronization features to support the software interaction between the tasks assigned to different processors. Moreover, some properties have been appended to structurally account for the memory hierarchy (level 1 and 2 caches) which is significant in multiprocessor systems.
A second work was the re-factoring of the Cheddar event-driven scheduling simulation engine. Indeed, the parallel activity of the processors raised issues for a correct computation of the future simulation state. The simulator also had to be able to manage the task/job migrations. To quantify the amount of work done for updating Cheddar, notice that the multiprocessor shift required the creation of about twenty new entities, and as many new types in its internal data structure. These changes impacted both the simulation engine and the Cheddar input language, but were mandatory to support multiprocessor simulations and to configure the multiprocessor feasibility tests. Cheddar analysis functions for multiprocessor real-time systems can be classified in three categories. The first category is based on simulation.
𝐷𝑃 2 ∶= (𝐿𝑂𝐺_𝑈 𝑃 𝐺 ∨ 𝐿𝑂𝐺_𝑅𝐴𝑉 ∨ 𝐿𝑂𝐺_𝑆𝑌 𝑁𝐶) ∧ 𝐷𝐸𝑃 _𝑃 𝐴𝑅𝑇 (𝑇 , 𝑃 𝐸) ∧ 𝐸𝑋𝐸_𝐼𝑁𝐷𝐸(𝑇 , 𝑃 𝐸) ∧ 𝐹 𝐸𝐴_𝐼𝐷(𝑇 ) This pattern defines a partitioned multiprocessor system. Depending on the compliance of the software architecture, this pattern allows to apply many Cheddar implemented analysis methods. For example, if the architecture to check complies with LOG_RAV, LOG_ SYNC or LOG_UPG, we can compute worst case response times  [43].
Design pattern implementation In this section, we present a Prolog implementation of the design patterns and the Design Pattern Checking Algorithm (dp_check) to test the compliance of an architecture model with the different design patterns defined in Section 4. 3. These design patterns are specified as first order logic formulas involving predicates for task communication and synchronization modeling (see Section 2. 1. 2) and predicates representing sets of constraints for runtime environment modeling (see Section 4. 2). Actually, these sets of constraints are themselves specified as first order logic formulas using predicates associated with the different runtime environment model attributes (see  Sections 3. 3, 3. 4 and 3. 5). Prolog is a logic programming language based on the first order logic paradigm  [48].
Example 1: Global scheduling Here we present the analysis of a software architecture made of four periodic tasks 0, 1, 2 and 3, scheduled on a runtime environment including two processors 0 and 1. Both processors are identical and independent. The software architecture complies with LOG_UPG. Here is a Prolog set of facts to represent these first characteristics of the system architecture: s w _ a r c h i ( l o g _ u p g ). The designer of this architecture has chosen a (Proportionate-Fair) global scheduling policy. The Prolog set of facts below represents the deployment rules. These rules show that the designer allows software tasks to run on any processors and define the computing resource sharing protocol, i. e. the scheduling policy. dm_PE_allowed ( t0 , [ c0 , c1 ] ). dm_PE_allowed ( t1 , [ c0 , c1 ] ).
Example 2: Instruction cache impact on scheduling For this second example, we seek to analyze a real-time system implemented on a dual-core runtime environment (0 and 1). The program instructions are stored in a shared memory, and each processor has a level 1 private instruction cache. The Fig. 7  schematizes the expected runtime environment. The Scratchpad Memories (spm) are used to record data and task execution context. So the shared memory only stores the instructions. The bandwidth of the memory bus is fairly allocated to both cores by a tdm (Time Division Multiplexing) bus frame constituted of two slots of equal duration. The list of attributes which characterizes this architecture, and which will be used to set some scheduling analysis parameters, is given below. The interference related to hardware resource sharing is then defined.
Example 3: Memory sharing impact on scheduling In this last example, we reproduce an example of schedulability analysis of a multiprocessor architecture with shared memory units leading to interference at task execution time  [40]. Again, we show we can model both the hardware and software parts. The correctness of those models is assessed by showing that the schedulability test proposed by  [40]  can be applied. From the hardware side, we have a 4 core processor sharing 3 banks of memory (Fig. 9 ). Core 0 may access to any memory bank while any other core  (with  > 0) only access to one memory bank (see the __ and _ _ attributes page 28). The list of attributes which characterizes this architecture, and which will be used to set some schedulability analysis parameters, is given below as a Prolog set of facts: ha_dependent ( c0 ).
ha_dependent ( c1 ). ha_dependent ( c2 ). ha_dependent ( c3 ). Some specific timing parameters configure the test, for example the worst-case service time for consecutive DRAM row-hit requests; the value of these parameters is provided as entries in the schedulability analysis model. Even if dedicated Prolog attributes could easily represent them in the interference model, the interest to adopt these attributes at that level must be considered on case-by-case basis depending on the reusability of the parameters. Thus, in this analyze example, the timing parameters of the DRAM controller are not represented in the interference model, and then the DP checker might not detect an discrepancy between the execution platform and some assumptions on which the schedulability analysis is based. The software architecture is modeling a subset of the parsec benchmark  [49] , composed of 9 independent periodic tasks.