dataesr/scientific-paragraphs-categorization huggingface dataset:
Areas under each MT portion were then measured using plot profile from the Gel Analyser ImageJ function. The macro output is a list of quantified areas, which were then normalized and analyzed using Excel (Microsoft) and Prism software (GraphPad Software). An average of 10 portions of MTs have been analyzed in each image. Totals of 270 and 276 measurements have been performed for the control and for the double-mutant genotype respectively. In each data collection, results have been normalized by dividing areas by the smallest area. Hence, this ratio is a relative quantification of the number of MTs in each track analyzed. STED images allowed us to confirm that the number of MTs visible in STED correspond approximately to the ratio value (see Fig. 2A ; Figs  S5  and S6 ). MT density was measured using STED images.
MT network organization Images analyzed came from two biological repetitions for hypocotyl and from three biological repetitions for the root. A minimum of 10 plants were analyzed for each genotype and each organ. 109 cells from the control and 77 cells from the double mutant were analyzed for hypocotyl and 132 cells from the control and 112 cells from the double mutant were analyzed for the root. Data normality was tested using the KS normality test, d'Agostino and Pearson omnibus normality test and Shapiro-Wilcoxon normality test. In the case of the hypocotyl, all three tests concluded that data fit a normal distribution, while all tests concluded that data did not fit a normal distribution for the root. Hence, we decided to use a non-parametric Mann-Whitney U-test with α=0. 01 for both data collections.
MT bundle quantification Data came from three biological repetitions. We analyzed 29 different cells from 10 plants, for each genotype for a total of 270 and 276 MTs analyzed for control and double mutant respectively. To facilitate data comparison, histogram of frequencies distribution upon the whole population with four classes; 1<…<2, 2<…<3, 3<…<4 and >4, has been used to compare the two distributions using a Chi-squared test and it appears that samples are significantly different with P=0. 0006.
Acknowledgements We are very grateful to  Prof. Takashi Hashimoto  for providing us with transgenic and mutant plant lines, to  Dr Fabrice Cordelieres  for the  KymoToolBox ImageJ Plug-In , to  Dr Valeŕie Nicolas  ( Institut Paris-Sud  d'innovation theŕapeutique) for the use of the STED microscope and to  Emilie Gineau  who performed cell-wall biochemical analyses. This work has been performed in the group of  Dr Beátrice Satiat-Jeunemaître  who provided infrastructures needed for the project development. This work has benefited from the facilities and the expertise of  Imagerie-Gif  microscopy platform, which is supported by  France-BioImaging  ( ANR-INBS-04 , 'Investments for the future'), and by ' Saclay Plant Science'  ( ANR-11 IDEX-0003-02 ). We thank  Dr Michele Bianchi  for fruitful advice and for critical reading of the manuscript.
With the wide expansion of multiprocessor architectures, the analysis and reasoning for programs under weak memory models has become an important concern. This work presents MMFilter, an original constraint solver for generating program behaviors respecting a particular memory model. It is implemented in Prolog using CHR (Constraint Handling Rules). The CHR formalism provides a convenient generic solution for specifying memory models. It benefits from the existing optimized implementations of CHR and can be easily extended to new models. We present MMFilter design, illustrate the encoding of memory model constraints in CHR and discuss the benefits and limitations of the proposed technique.
Models are relaxed or weak with respect to SC. On most processors, the previous example can also provide the result r 0 = 0 and r 1 = 0, which is not justifiable by an interleaving. To avoid this behavior, one can use memory barriers or fences that forbid reorderings as illustrated by the program p 1 of Figure  1a. We propose a constraint solving based technique that allows to determine all admissible (i. e. allowed) executions of a program under a memory model. This technique relies on Prolog and CHR (Constraint Handling Rules)  [15]. A CHR program is a list of rules that act on a store of constraints by adding or removing constraints in this store. A rule is activated if a combination of constraints in the store matches the head of the rule (and if an optional Prolog predicate, called the guard, is satisfied).
In our case, constraints express relations between instructions that basically describe their order of execution. Given a set of relations characterizing the instruction ordering in a program execution, such rules are used to propagate information and to deduce new, yet unknown ordering relations for instructions of the execution. The contributions of this paper include a novel CHR-based technique for generation of admissible behaviors under memory models and a constraint solver prototype MMFilter 1  implementing this technique for the SC, Total Store Order (TSO) and Partial Store Order (PSO) models. We discuss the benefits and limitations of this approach, and show how the use of CHR allows us to define our model in a concise and intuitive way, taking advantage of a well-established specification and solving mechanism.
Outline. Section 2 presents some previous work on weak memory models. Section 3 illustrates the usage of MMFilter. Section 4 gives a brief introduction to CHR, defines the considered language and basic relations between memory events used in MMFilter. Section 5 presents the generic model used to define the notion of candidate executions. Section 6 describes how to define allowed executions and illustrates this definition for some simple memory models. Section 7 discusses the termination of the analysis, while Section 8 presents an experimental evaluation of its performance and correctness. Finally, Section 9 concludes and gives some future work.
Axiomatic Approaches to Execution Generation Among the tools used to analyze programs under weak memory models, some tools are dedicated to the generation of executions that are allowed or not for a program with respect to a targeted model. PPCMem  [25]  and CPPMem  [7]  are dedicated to the generation of allowed executions for programs under Power and C++11 models, respectively. From a given program, they can generate all executions allowed by the targeted memory model. For both tools, the implementation relies on the Lem language  [20]  from which HOL code and an executable OCaml code are generated. The Herd solver  [6, 3]  is designed as a generic analyzer. It relies again on an axiomatic formalization. It defines and implements a very weak memory model that allows a lot of relaxations.
The concrete memory models are then provided by the user through a description language that defines: (i) a combination of basic relations of the generic model that are respected by the targeted model, and (ii) the properties these relations must respect. We will further elaborate on this approach later since this is also the one implemented in MMFilter. Constraint-based concurrent memory machines (CCMM)  [23]  provide a formalism for definition of weak memory models as constraints on the order of memory events and the values of variables during a program execution. According to the author it can be adapted to any model. In  [23] , the considered model is the Java memory model, implemented by Schrijvers  [26]  using Prolog and CHR. We also use Prolog and CHR. As there are already numerous optimized implementations of the resolution mechanism for these languages, this design choice allows us to avoid writing a complete resolution process (that is necessary for Herd).
Constraint Handling Rules A program written using CHR  [15]  consists of a set of rewriting rules that manipulate a store of constraints. Each rule application leads to removing some existing constraints and/or adding some new ones. The underlying constraints are terms that do not involve any computation. Figure  3  presents the different types of rules used in CHR. A typical rule contains a head (with a list of CHR constraints), a guard (with a list of Prolog terms) and a body (with a list of CHR constraints and Prolog terms). A rule can have an identifier that is then given before the "@" symbol. The first type (line 5) is simplification: if some subset of constraints of the store match with the given list of constraints Head, and if the list of Prolog predicates Guard is satisfied, then the matching constraints are removed from the store and the constraints defined in Body are added into the store.
In a CHR program, once a rule is applied, the result is committed, that is, there is no backtracking mechanism. Moreover, in the original semantics the order of application of rules is not defined. That can make the design of a correct CHR program rather hard. That is why most CHR implementations, including SWI-Prolog used in the present work, use a refined semantics of CHR  [13]  that specifies the order of application of the rules as the order in which they appear in the program.
Considered Language In the considered language, a program is modeled by • the list of named locations it can access, represented as a list of constant Prolog terms (that can be seen as named addresses of locations in C), and • the list of threads, each thread being represented by the list of instructions it executes. An instruction can be either a memory operation or a barrier. A load (resp. a store) instruction is a tuple (ld, loc, v) (resp. (st, loc, v)), where loc is the read (resp. written) location and v the read (resp. written) value. Both loc and v can be provided as Prolog variables. In such a case, the solver has to unify variables to determine their values (or equality with other variables). We also provide the instruction (rmw, loc, v1, v2), for read-modify-write which atomically reads value v1 at location loc and writes value v2 into it.
In this language, the programs p 0 and p 1 in Figure  1  are implemented by predicates program_0 and program_p1 illustrated in the same figure. The specified parameters are the list of considered variables ([x,y]) and the program instructions given as a list of threads (Thread0 and Thread1, defined respectively on lines 5-6 and 9-10). It is possible to specify a name for the register that stores the read or written value, or containing the accessed location, using the syntax register:Value, where register is a Prolog constant and Value can be either a constant or  a variable. It allows to create data or address dependencies to order some instructions. For example, a program can read a location l from another location and then use l to read the value at this location in the memory, as illustrated by Figure  4.
3) that rejects executions violating atomicity of the instruction. The Prolog predicate enrich_prog(0,THREADS,EnrichedThreads) in Figure  6  produces the translation from original instructions to "identified" ones in a very straightforward way: it visits the different lists of instructions of the program. Then the resulting program is scanned to build the PO constraints between successive (identified) instructions. Inside a thread, besides the PO-relation, we also need to extract two dependencies: data and address dependencies (produced by the Prolog predicate compute_rel_all_threads, respectively parameterized with data and addr). A dependency exists from an instruction i 1 to an instruction i 2 if i 1 reads a value v that is then used by i 2. If i 2 is a store instruction writing a value that depends on v, we have a data-dependency data(i 1 , i 2 ).
Termination of the Analysis This section gives the main principles that ensure the termination of the different parts of the analysis of a program: • generation of candidate executions, • deduction of derived relations, • cycle detection for the relations defined by the model. Each of these steps must terminate to ensure global termination. : -include ( uniproc ). : -chr_constraint rfe /2. : -chr_constraint ppo /2. % TSO implementation does not need addr and data deps : addr (_ , _ ) <= > true. data (_ , _ ) <= > true. ext ( i ( N0 ,_ ,_ ,_ , _ ) , i ( N1 ,_ ,_ ,_ , _ )) : -\+ N0 = N1. rf ( I0 , I1 ) == > ext ( I0 , I1 ) | rfe ( I0 , I1 ). cycle ( tso , L ) <= > false. % po -WR pairs are not preserved by TSO , so we remove them ppo ( i (_ ,_ , st ,_ , _ ) , i (_ ,_ , ld ,_ , _ )) <= > true.
Testing and Performances Our goal was to evaluate the following research questions: (RQ1) Do Herd and MMFilter produce the same results ? (RQ2) What are the performances of MMFilter compared to Herd ? For the experimental evaluation of MMFilter, we used program samples from the test suite of Herd in order to have an oracle. These examples can be found on the Herd tool webpage at http://virginia. cs. ucl. ac. uk/herd/ (record "armed cats"). Regarding (RQ1), on all tested examples, MMFilter produced the same results as Herd, providing a cross validation of both tools. Our models being based on those of Herd, our goal is not to verify them but to verify the validity of the underlying generic solver. Regarding (RQ2), the execution of MMFilter on these small examples is very fast and does not allow to precisely evaluate its performances.
Finally, we have tested the generation of executions for expected read values. For example, the program mp4t4x1_forced illustrated in Figure  23  expects that the message passing is sequenced so that T1 (resp. , T2, T3, T0) receives the message sent by T0 (resp. , T1, T2, T3). Therefore, we use the Prolog variables  speedcheck that allows to generate only executions respecting a constraint on some variables in the program. In this case, it is applied for the values read for the variable m. Again, we do not present the results for the variants of mp3t3 that are executed too fast to be relevant. The goal is to determine all allowed executions for a given program. For each example, we analyze the program with different memory models. We indicate the number of executions allowed by the model. The number indicated for the generic model corresponds to the number of candidate executions.
Again, it increases the chances for early pruning in MMFilter while requiring more computation for Herd. Figure  25  illustrates the results of tests for the variants of the MP4 message passing program with different numbers of variables. Here, we can see that, compared to MMFilter, Herd behaves better as the number of variables grows. The main reason is the fact that the example with a greater number of variables has less dependencies between the read and written values: instead of having a long story about one variable, we have independent short stories about different variables. So for a bigger number of variables, we have less constraints and, consequently, a greater rate of allowed executions with respect to the total number of candidate executions (the rate is indicated in parentheses).
Conclusion and Future Work We have presented MMFilter, an original CHR-based solver for detection of admissible executions of a given program with respect to a given memory model, and illustrated it for SC, TSO and PSO models. The ARM model is also available. It is suitable for a rigorous exhaustive analysis of program executions of small programs that becomes intractable for bigger ones due to the combinatorial explosion of the number of executions. We have presented several optimizations and evaluated the proposed tool on several benchmark programs. The results show that MMFilter can be relatively efficient, especially for strong memory models. We think that seeing memory models as constraints over executions is well adapted. The design of such a solver is convenient and pragmatic. The generation of basic executions and cycle detection rely on careful optimizations in order to be more efficient and to ensure on-the-fly filtering of constraints.
The proposed approach makes the definition of specific models from the generic one very practical and relatively straightforward. In particular, it does not become very hard even when the model becomes more complicated, like ARM for example. CHR provide an easy way to express constraints about execution of programs, they have also been used for detection of incorrect behaviors in imperative program analysis in  [12]. Moreover, the use of a well-established mechanism of constraint specification and solving, like Prolog and CHR, brings the benefit of years of optimization and debugging to handle the considered problem without having to re-develop constraint resolution. We do not claim that our implementation of this problem is most efficient. Dedicated tools like  [6]  could be faster since they are specialized for a precise problem and can implement a solving engine without being as generic as CHR.
The mobilome of A. salmonicida was identified as one of three functional categories that differ most between mesophilic and psychrophilic subspecies; it was subsequently hypothesized as one of the driving forces in mesophilic-to-psychrophilic transition. Their mobilome analysis involved transposons, which our group has identified in the 34mel strain and other completely sequenced Aeromonas genomes with subsequent submission to the ISFinder database in an early phase of the currently described project. However, a precise description of the species' mobilome depends on a complete, circular genome. Here we present the complete, fully assembled genome of A. salmonicida subsp. pectinolytica strain 34mel. We discuss our genome sequencing strategy, which is based on single-molecule real-time long read sequencing (PacBio), the high-quality annotation of the genome and a detailed and comparative analysis of the mobilome in different environmental and pathogenic Aeromonas species with a fully assembled genome.
We next compared the two assemblies using an inhouse developed script for analysis of very closely related genomes  [9]. In order to focus on the relevant regions of the 454 contigs, we replaced poly-N stretches at contig gaps with the sequences occurring at the corresponding positions in the PacBio assembly. Our analysis showed that the original 454 assembly represented nearly all of the unique sequences from the genome. Only 68 differences of one or few bases were detected between the assemblies in the unique regions. We attempted to resolve these discrepancies and thus mapped Illumina reads to each assembly (Additional file 1: Fig. S1 , for details see Methods). All of the 68 differences observed between the PacBio and 454 assembly could be resolved with the Illumina reads. In the majority of cases (60 positions), the Illumina sequences supported the Pac-Bio assembly and thus disproved the 454 assembly.
In such cases, the published characterization data are  not available via SwissProt and we requested to update this missing information in the database. In the majority of cases we could not identify a functionally characterized homolog. Consequently, we considered the specific function assignment an over-annotation error and revised the annotation to only a general protein name. After manual curation, the genome contains 4590 protein-coding genes, 209 of which are disrupted genes (Additional file 1: Table  S4 ). We also improved the annotation of RNA genes, which resulted in a total of 165 RNAs (for details, see Methods and Additional file 1: Text S1). Comparison to the A. salmonicida subsp. pectinolytica strain 34mel draft genome sequence Even though the draft genome of strain 34mel consists of 253 contigs, it represents all of the unique sequences of our finished genome.
In addition to strain 34mel, we also performed an exhaustive transposon analysis of the Aeromonas species, for which a complete genome sequence is available, including A. salmonicida subsp. salmonicida strain A449, A. hydrophila (2 of the 10 available genomes), A. veronii, and A. media (Table  1 , Additional file 1: Table  S5 ). In total, 53 transposons were newly defined during our analysis and have been submitted to and accepted by the ISFinder database  [19]  (Additional file 1: Table  S5 ). Of these 53 transposons, almost half  (21)  were from strain 34mel. One transposon, ISAs29 from the IS21 family, closely matches the characteristics, which are listed for ISAs11 in Table  2  in Reith et al. [17]. However, the name ISAs11 has been reassigned as a synonym for the IS256 family transposon ISAs3 (for more details, see Additional file 1: Text S4).
It consists of a basic transposon of 5. 4 kb (named Tn1722), which is enclosed by left and right inverted terminal repeats. Tn1721 extends beyond the right terminal repeat for another 5. 3 kb, carrying tetracycline resistance genes, a partial highly conserved copy of the transposase gene from Tn1722, and a second right terminal repeat (Fig. 5 , Additional file 1: Fig. S5 E ). In the genome of strain 34mel, we found a variant of Tn1722, which was submitted to ISFinder as TnAs1 (Fig. 5 , Additional file 1: Fig. S5 B ). It is chimeric, being near-identical over half of the transposon and completely unrelated in the other half. The common region encodes the transposase and resolvase, but with a 3415 bp insertion close to the C-terminus of the transposase gene in TnAs1. The unrelated parts of Tn1721 and TnAs1 encode unrelated genes: Tn1722 codes for a methyl-accepting chemotactic protein (MCP), which has been shown to interfere with chemotaxis upon overexpression  [22].
In order to make our knowledge available to the scientific community, we have submitted all the transposons and other mobile genetic elements, which we have identified during our studies to the ISFinder database  [19]. The positive impact of such a submission can be seen by the analysis of Vincent et al. [5] , who compared the mobilome of various draft genomes of Aeromonas strains. Having access to the transposons in ISFinder, many of which have been submitted by us in the course of the current project, they identified the mobilome as one of the key components, which differs between psychrophilic and mesophilic strains. We have focused our analysis on all complete Aeromonas genome sequences, which are available for a fish-pathogenic psychropilic strain, as well as several mesophilic strains that are environmental or human-pathogenic.
Genome sequencing and assembly The genome sequence is primarily based on PacBio SMRT sequencing with 110-fold coverage (raw sequences: 642 Mb, 87215 reads with a mean length of 7358 bp, see Additional file 1: Text S6 for more details). In addition, 454 sequencing data (see below) and Illumina sequencing data (90 bp read length, 4166667 reads) were obtained. After trimming of Illumina raw reads, 666 Mb of reads were obtained, which corresponded to a 133-fold genome coverage. The PacBio sequences were assembled using the HGAP assembler (RS_HGAP_assembly. 2)  [31] , which resulted in two contigs: one represented an untrimmed version of the full genome of Aeromonas salmonicida subsp. pectinolytica, with a size of 5036397 bp and a 110-fold mean coverage. The second, poorly covered contig of 6568 bp in size turned out to be a duplicated version of part of the genome sequence with considerable sequence variation (not considered further).
Comparison of genome assemblies The PacBio and 454 assemblies were compared using an in-house script for analysis of near-identical genomes  [9]. When an extended region of sequence identity was interrupted by poly-N stretches in the 454 assembly, we replaced this region by the corresponding sequence from the PacBio assembly. Similarly, discrepancies within repeat sequences (e. g. rRNA operons or transposons) were resolved. This improved 454 assembly allowed us to identify sequence differences in unique regions of the genome. Illumina reads were mapped to both, the PacBio assembly and the improved 454 assembly (see below). All of the PacBio/454 discrepancies in unique regions were also detected by mapping of Illumina reads to the respective genome assemblies. Potential errors in the Pac-Bio sequence were subjected to frameshift analysis via BLASTx comparison to UniProt.