dataesr/scientific-paragraphs-categorization huggingface dataset:
criteria can be very important in practice. In particular, MCDC coverage is mandated by the DO-178 standard that dictates the development process of avionics software. On the other hand, the practical applicability of the tool remained barely illustrated and assessed, as  [5]  only reported preliminary results, on small-scale benchmarks. The goals of the present work are  (1)  to enable a better support of (almost) all existing criteria in LTest, and  (2)  to provide a more realistic view on its practical applicability, by studying its efficiency and scalability on realworld code. Test automation in LTest relies on annotating the tested code with the considered test objectives using a generic (i. e. criterion independent) test objective specification language: labels  [8]. The limitations of this language prevent LTest from handling criteria like MCDC or dataflow criteria.
Very recently, we have provided a conceptual extension of the label language, called HTOL  [11] , that overcomes previous limitations of labels and allows for encoding almost all criteria from the literature (except strong mutations). HTOL can also be used to test important software security properties. An additional goal of this work is to provide a tool support for the HTOL language. • As a first contribution of this paper, we report on significant advances made in an extended version of LTest that now offers a support for HTOL test objectives, and detail the new technical capabilities of some of its modules. We show how these new features can be exploited in practice, by illustrating how one can use the new LTest API to add support for new testing criteria.
A. Main Features Given a C program to be tested according to the test objectives defined by a code coverage criterion, the LTest toolkit  [5]  offers the following services: Uncoverability detection tries to detect which of the test objectives cannot be covered by any test datum (e. g. in dead code). Its results are primarily used by the other two services, but can also be exported for external use. Coverage measurement replays an existing test suite and reports which of the test objectives have been covered, which have not and which are uncoverable. Test generation creates a test suite tailored to cover as many test objectives as possible. It can skip objectives known to be uncoverable, or those already covered by a given test suite in order to complete its coverage. The following criteria are supported and can be combined with each other: decision coverage (DC), function coverage (FC), condition coverage (CC), multiple-condition coverage (MCC), weak mutation (WM, operators AOR, ROR, COR, ABS) and input domain partition (IDC).
C. Internal Architecture LTest comes as a series of four plugins of the Frama-C  [9]  platform, mostly written in OCaml: LAnnotate, LReplay, LUncov and LGenTest. These modules interact through shared information made of the annotated program and a status database mapping each label to its current status: covered, uncoverable or uncovered. The whole architecture is depicted in Figure  2. We provide hereafter the main clues about the role of each module. The LTest code is open source (LGPL), except the LGenTest module, and available online 1. LAnnotate acts as a front-end: it annotates the program with labels according to the chosen criteria and creates the status database. The module implements the idea of labelling functions and provides one for each supported criterion. In addition, users can extend the module by writing their own labelling functions.
To facilitate this task, LAnnotate provides an API to easily insert labels into the code and to register inserted labels in the shared status database. Given an annotated program and its status database, the LUncov module runs static analysis to identify uncoverable labels and mark them as uncoverable in the database  [10]. Provided with a test suite and an annotated program, the LReplay module executes each test case in order to update the label statuses in the status database. In addition, it computes coverage statistics for the given test suite. The LGenTest module provides the test generation service of LTest, by implementing a flavour of Dynamic Symbolic Execution (DSE)  [6] ,  [7]  tailored to cover labels and called DSE  [8]. The tool is based on a modified version of the PathCrawler test generator  [7].
III. A PRACTICAL INTRODUCTION TO HTOL We recently introduced HTOL  [11] , a major extension of the label language used in LTest. HTOL makes it possible to emulate all white-box criteria defined in the Ammann and Offutt's book  [4] , except strong mutations. Compared to labels, HTOL notably adds support for all the variants of the MCDC criterion, call coverage and all the dataflow and path-based criteria. Moreover, HTOL enables encoding test objectives to find violations of important software security properties, such as non-interference  [12]. Concretely, HTOL introduces five operators to combine (now referred to as atomic) labels into hyperlabels, specifying more complex test objectives: Bindings save the value of well-defined expression(s) at the state at which an atomic label is covered; Guard | • expresses a constraint over the binding values of several atomic labels; Sequence • -→ requires atomic labels to be covered sequentially by a single constrained test run; Conjunction • and Disjunction + are the logical AND and OR operators, for combining test objectives together.
IV. UPGRADING LTEST FOR WIDER CRITERION SUPPORT We describe in this section how we have upgraded LTest in order to support the whole HTOL specification language, lifting LTest into an (almost) universal testing tool. Such an upgrade requires major changes in the LAnnotate and LReplay modules, to be able to instrument code with hyperlabels and to measure hyperlabel coverage (as a function of label coverage and coverability). Updates to the LGenTest and LUncov modules are less necessary, as they can already be used (in a suboptimal way) to find tests that will cover the atomic labels composing the hyperlabels and to detect that some of these atomic labels (hence the hyperlabels that are built upon them) are uncoverable. Experiments evaluating the upgrade of LTest are provided in Section V. The source code of the upgraded LAnnotate and LReplay modules is available on the companion website 2.
A. Upgrading LAnnotate: Instrumenting Code with HTOL Code annotation and status database format. As a first step of the upgrade process for LAnnotate, we redesigned the output format that it uses for annotating the code with (hyper)labels and generating the (hyper)label status database. Figures  3  and 4  illustrate this new format, considering the same examples as in Section III. From a given C source file, LAnnotate produces two resulting files: • a C file with the annotated code, containing specific macros at the places where an atomic label should be put, and which are no-ops by default. • an. hyperlabel file, which represents the initial state of the status database, where no hyperlabel has been covered, hence no binding is associated to any label. We detail in section IV-B how LReplay uses these files and updates the information contained in the.
A single seq_cond can thus constrain several sequence sections if they share the same tag name. This is useful as many sequence sections are often constrained by the same condition in practice. API for developing hyperlabelling functions. As a second step of the upgrade process for LAnnotate, we have redesigned its API so that it can be used to create and store hyperlabeling functions. Hyperlabelling functions are pieces of code dedicated to the handling of a particular coverage criterion. Once developed, they can be plugged into LAnnotate to provide support for additional criteria. Practically, an hyperlabelling function is responsible, for a given C source file received as input, to generate the corresponding macro-annotated and. hyperlabel files, populated with the test objectives defined by the considered criterion.
The main primitives offered by the new LAnnotate API for developing and registering hyperlabelling functions are presented hereafter: Registration Service -Register a new hyperlabelling function. -Fetch an hyperlabelling function by criterion name. Code Annotation Service (notably relying on the API of the Frama-C platform) -Parse a C file into a standardized abstract syntax tree (AST) and output such an AST as code in a file. -Extract useful information out of some specific AST nodes, using a visitor pattern. -Extract the control-flow graph (CFG) from the AST of a C file. Navigate this CFG and obtain syntactic and semantic information about the navigated code. These primitives are particularly useful for generating adequate hyperlabels for criteria specifying complex set of paths to be covered in the CFG.
-Insert a dedicated macro node for label and sequence annotation before or after some specific AST nodes, using a visitor pattern. Status Database Creation Service -Save a set of label definitions as a CSV file. -Save a set of hyperlabel definitions into a file, following the syntax of a LALR(1) grammar for HTOL. Built-in hyperlabelling functions. The labelling functions built in the original version LTest were adapted to this new API, while new hyperbelling functions were developed for some important criteria not encodable with labels. The current version of LAnnotate is released with 14 built-in hyperllabeling functions, for the following criteria: strong, masking and weakened MCDC, all-definitions and all-uses coverage, weak mutations, function and call coverage, condition, decision, multiple condition and n-wise condition coverage, general inactive clause coverage, input domain partition coverage.
Test suites generated by LGenTest are automatically encoded into such test drivers. Once the tested code has been annotated with labels and sequences by LAnnotate, LReplay can compile and run it with the test driver and some instrumentation code. This last code is a set of C macro definitions of the form # d e f i n e l a b e l ( / * some p a r a m e t e r s * / ) c a l l _ l r e p l a y ( / * same p a r a m e t e r s * / ) which overwrite the label and sequence annotations in the tested code so that, every time the test execution reaches an annotation, the corresponding coverage info is sent to LReplay. Computing hyperlabel coverage. Given the file_annotated. c and file. hyperlabel files produced by LAnnotate as inputs, as well as a set of test drivers, LReplay follows a three step procedure: normalization First, file.
As an example, the GACC variant of the MCDC criterion can be encoded with labels only, while the CACC and RACC variants require constraining the same labels with conjunctions and guards. The test suites generated by LGenTest for GACC (or even for a weaker but less demanding criterion such as CC) can be naturally used for trying to cover CACC and RACC. We provide experiments evaluating this approach in Section V-B. LUncov is able to detect labels that are not coverable, as they may be part of a dead portion of code or because their predicate might be infeasible. Such information can be directly propagated by LReplay to prune out uncoverable hyperlabels, using the following rules: a binding is uncoverable if the bound label is uncoverable, a sequence is uncoverable if at least one label is uncoverable, a (guarded) conjunction is uncoverable if at least one conjunct is uncoverable, a (guarded) disjunction is uncoverable if all the disjuncts are uncoverable.
A. Assessing LAnnotate and LReplay Objective. In this section, we want to assess the efficiency of the newly redesigned LAnnotate and LReplay modules for unit testing. More precisely, we seek to answer the following research question: how do LAnnotate and LReplay scale with large test suites on criteria using hyperlabel operators? Protocol. We consider 13 C functions split up into 3 groups: • 5 functions, mainly from Siemens  [13] , Verisec  [14]  & MediaBench  [15] , as already used in  [8] ; • 5 functions from OpenSSL 1. 0. 2 [16] , a 250 kloc opensource application. We focus on modules of about 1 kloc. • 3 functions from SQLite 3. 13  [17] , a 215 kloc open-source application. We focus on modules of a few kloc. The C files automatically annotated with HTOL test objectives are available on the companion website.
A set of up to 10,000 test cases is randomly generated for each C function. Our tool is successively run with an increasing number of these unit test cases, also available from the companion website. Each tool run is repeated 7 times. First, tests are executed without measurement (baseline). Then, we measure coverage for the CC and GACC criteria encodable in labels (used as a witness). Finally, we measure coverage for the CACC, RACC, FCC and all-defs criteria, which involve the five operators from hyperlabels. All experiments are performed under Ubuntu Linux 14. 04 on an Intel Core i7-4712HQ CPU at 2. 30GHz, with 16GB of RAM. Results and discussion. Detailed results are on the companion website. Figure  5  plots, for each criterion and the baseline (nocov), the mean measurement time for all programs, as a function of the test suite size.
We can notice that: (1) the measurement time grows linearly with the number of test cases, (2) the time overhead is very reasonable for all criteria but all-defs (between 1. 1x and 2x), and still not so high for all-defs (between 2x and 4x), and (3) these results hold on the three benchmarks, regardless of program size. Note that all-defs yields a tangible time overhead on some programs, due to the higher number of test objectives that are defined. However, many objectives are trivial or redundant, which could be detected using some static analysis techniques in an optimized version of the tool. Conclusion. These results indicate that upgraded versions of LAnnotate and LReplay provide both practically applicable and (almost) criterion-independent testing capabilities. The measurement time for criteria beyond labels is acceptable and remains linear with the size of the test suite.
VI. RELATED WORK A large number of automatic testing tools are available. However, they often offer a limited scope of services (test coverage measurement or automatic test generation) and are restricted to few coverage criteria. On the contrary, LTest is an integrated and generic toolkit for automated white-box testing. Coverage measurement tools. Code coverage is used extensively in the industry. As a result, there exists a lot of tools that embed some sort of coverage measurement. For instance, in 2007, a survey  [18]  found ten tools for programs written in the C language: Bullseye  [19] , CodeTEST, Dynamic  [20] , eXVantage, Gcov (part of GCC)  [21] , Intel Code Coverage Tool  [22] , Parasoft  [23] , Rational PurifyPlus  [24] , Semantic Designs  [25] , TCAT  [26]. To this date, there are even more tools, such as COVTOOL  [27] , LDRAcover  [28] , and Testwell CTC++  [29].
As a rule of thumb, these tools support a limited number of test criteria in a hard-coded, non-generic manner. Table  I  summarizes implemented criteria for some popular tools. However, to be fair, these code coverage tools also aim at causing as little overhead as possible. In contrast, as a first step, we only aim at getting a reasonable overhead. Test generation tools. Many test generation tools only handle basic coverage criteria, such as bounded path coverage or decision coverage. Three interesting exceptions to be compared with our work are Fshell  [30] , FAJITA  [31]  and Apex  [32]. Fshell enables encoding code coverage criteria into an extended form of regular expressions, whose alphabet is composed of elements from the control-flow graph of the tested program. It then takes advantage of an off-the-shelf model-checker to automatically generate a test suite satisfying such a specification.
The scope of criteria that can be encoded in FShell is incomparable with the one offered by LTest, but the tool cannot encode neither MCDC nor weak mutations. The FAJITA tool proposes to encode a testing criterion as a set of disjoint boolean constraints, which partition the input space of the tested program. These constraints are then solved using a SAT solver to build a test suite satisfying the criterion. The paper demonstrates how basic white-box criteria (statement, branch and path coverage) can be handled in this way. As our tool, Apex also relies on dynamic symbolic execution, but adds additional predicates to the path conditions, where LTest annotates the code itself. However, LTest makes use of    [4]  IN COVERAGE MEASUREMENT TOOLS a DSE tailored to labels, which strongly limits the overhead observed with Apex.
VII. CONCLUSION LTest has been briefly introduced two years ago as a toolkit for white-box testing. It could have been presented as a coherent combination of various advanced techniques within a testing tool, able to automate most aspects of testing, for various classes of coverage criteria. In this work, we have described a major conceptual upgrade of the core design of LTest and provided a deeper insight into its practical applicability. The extended capabilities of the code instrumentation and coverage measurement modules make LTest able to handle all existing white-box criteria but strong mutations, and to do it in a generic way. Any technique for test automation built in LTest (like DSE or static analysis) is thus immediately available for all criteria. At the same time, genericness makes it easy to add support for new criteria (such as test objectives detecting violations of common security properties).
Simulation set-up The model is artificially spatially explicit so that the individuals can move, in what the NetLogo software refers to as a "world", which is a torus divided into patches. Two persons are considered to be in contact if they coincide on the same patch at a given time. The dimension of the patchesand thus of the worldis set in order to have, on average, 13 contacts per person and per day as reported by the Polymod study and its French equivalent  [31, 32]. The individuals move in this world each day in a randomly chosen direction at a distance ranging from 1 to 10 patches. The individuals are initially healthy and uniformly distributed at random around the world, with uniformly distributed ages. By default, birth and death rates are fixed in order to keep the population size constant at 100,000 individuals.
Discussion We developed a novel simulator of influenza virus in interaction with a second pathogen. The SimFI framework successfully reproduces the co-circulation of influenza and other pathogens, either epidemic or endemic. We obtained realistic simulated datasets in terms of weekly incidence, epidemic size and timeframe, and carriage rate. The effects of the different influenzapneumococcus-interaction mechanisms implemented were assessed. For the endemic pathogen, the effects of the acquisition and transmission mechanisms on the dynamics were similar and could not be discriminated visually on the incidence series; the pathogenicity mechanism also had similar dynamics but the incidence series more closely paralleled the influenza epidemics than for the former two. We used the SimFI framework to evaluate the influenza-attributable PI burden in a series of simulations, characterized by different interaction hypotheses.
Based on French pneumococcal meningitis cases over 2001-2004, Opatowski et al. [28]  found transmissibility increased by a factor of 8. 7 for co-infected individuals and pathogenicity by 92. Based on two distinct US pneumonia Fig. 4  Computed influenza-induced PI burden. Average percentages and 95% confidence intervals of influenza-attributable PIs over the 1000 iterations of the model (y-axis), according to the acquisition-, transmission-or pathogenicity-interaction mechanism, and for the range of interaction-strength values tested (x-axis). Global burden of PIs over the entire simulated year (a), direct and indirect number of PIs for the (b) acquisition-interaction mechanism or (c) transmission-interaction mechanism datasets, Shrestha et al. [45]  found that influenza infection increased susceptibility to pneumococcal pneumonia by factors 85 and 115.
Funding HA received a PhD grant from  University of Versailles-Saint-Quentin-en-Yvelines. This work was supported directly by internal resources of the  French National Institute for Health and Medical Research , the  Institut Pasteur , the  University of Versailles-Saint-Quentin-en-Yvelines , and the  Assistance Publique-Hôpitaux de Paris. This study has received funding from the  French Government 's " Investissement d'Avenir" program, Laboratoire d'Excellence "Integrative Biology of Emerging Infectious Diseases " (grant n°ANR-10-LABX-62-IBEID). This work was supported by a grant from  Région Ile-de-France (Domaine d'Intérêt Majeur Maladies Infectieuses)  attributed to LO.
Introduction In contrast to the 'bottom-up' approach to quantifying CO 2 emissions, which involves compiling and estimating the characteristics of known emission sources into a quantitative database such as the US Environmental Protection Agency (EPA) Greenhouse Gas (GHG) Inventory 1 or the high resolution inventory Hestia  (Gurney et al. 2012 ), the 'top-down' approach involves measuring CO 2 concentrations in the atmosphere and then using an atmospheric transport model to infer emissions (e. g. ,  Enting and Mansbridge 1989; Bréon et al. 2015). The top-down approach can be effective in cases for which a source has a known location (e. g. ,  Davoine and Bocquet 2007) , but in situ source magnitude characterization is unavailable or unreliable, in which case concentration measurements in the vicinity of the source can help provide the missing information.
Then K Z is passed to the chemistry module for the vertical turbulent tracer transport prediction. An advantage of using WRF-Chem to predict tracer transport is that the chemistry is fully inline with the atmospheric flow field prediction, so both can mutually evolve each model timestep. To study near-field dispersion, we use WRF to model the evolution of the plume emitted from the location of the Harding St. power plant (39. 71°N, 86. 20°W), located in the southwestern sector of Indianapolis. The Noah land surface model was used for the simulation, with some tiles re-classified based on the 2006 version of the 30-m National Land Cover Database (NLCD)  (Homer et al. 2015; Sarmiento et al. 2017). Time-dependent emission data from the plant in 2013 were supplied by data obtained from the EPA Clean Air Market Division (CAMD) Emission Tracking System/Continuous Emissions Monitoring system (ETS/CEMs) for electrical generation, also used in the Hestia database over Indianapolis  (Gurney et al.
Acknowledgements The Hestia inventory product for Indianapolis and the hourly CAMD emission data were provided to us by  Kevin Gurney  and  Jian-Hua Huang  at  Arizona State University. Daniel Sarmiento  adapted and provided a high-resolution urban fraction land cover product for the Indianapolis region that was used in these model simulations. the turbulent dispersion in the atmospheric convective boundary layer. J. Atmos. Sci. , 62:  1175-1191. DOI: https://doi. org/10. 1175/JAS3393. 1 Enting, IG and Mansbridge, JV 1989 Seasonal sources and sinks of atmospheric CO 2 : Direct inversion of filtered data. Tellus, 41B:  111-126. DOI: https://doi. org/10. 1111/j. 1600-0889. 1989. tb00129. xGaudet, BJ, Deng, A, Stauffer, DR and Seaman, NL 2012 Eddy seeding for improved WRF-LES simulations using realistic lateral boundary conditions, Preprints, 13th WRF Users' Workshop, 7.