dataesr/scientific-paragraphs-categorization huggingface dataset:
By adapting the way of comparing the patterns in the TI and in the simulation grid, the algorithm is able to deal with categorical and continuous variables, as well as with the joint simulation of multiple variables. In this work, we use the direct sampling algorithm implemented in the DeeSse code  (Straubhaar, 2019) , It is parallelized and offers many options to constrain the simulation such as continuous rotation/affinity maps or proportion targets. But to model an aquifer at a regional scale, a very important aspect is to account for all the non-stationarities due to the geological process such as the location of the sources of the sediments, their transport, and so on. The application of MPS to a real case, requires more than just an efficient MPS code and a good training image. It requires also to develop a methodology and a workflow to account for all those aspects.
Hence, the specific spatial features displayed in the TI can follow the same orientation everywhere, which facilitates the construction of the conceptual model, whereas the rotation map is used to define the local orientation in the simulation grid. Such map consists of angle values defined on the simulation grid: at each pixel, the given angle specifies a rotation that must be applied to the TI structures. The DeeSse code is used in this project, which is an implementation of the direct sampling method  (Mariethoz et al. , 2010). The algorithm is controlled by three main parameters, e. g. n-number of neighboring nodes, f -scan fraction, t-distance threshold. The first one, n, defines the maximum number of nodes considered when comparing a pattern in the TI and in the simulation grid. At the beginning of the simulation, these n closest points are likely to be located far away from the simulated point.
, 2017). In addition, two continuous rotation maps are used to define the rotation bounds for the simulation with a tolerance of ±10°on the rotation values. Theses rotation maps are obtained by kriging data that constrain the paleo-orientations of the main paleo-rivers. The 3D model is then composed of stacked 2D simulations constrained by 3D auxiliary information. It appears that the creation of a 3D TI would have been too complex in regard of the available knowledge of the facies that compose the plain. To compensate for this choice and to take most of the information of the hard data set, the 3D grid is created with a rather fine resolution along the z axis (2m), which corresponds to the smallest body's dimension encountered in the plain. The vertical transition between facies is controlled by simulating additional conditioning data points between two 2D simulations.
Vertical transition To control the vertical transition from one layer to the next one, we developed a simple sampling approach, illustrated in Fig. 6. The approach starts by simulating the first layer of the transformed grid (layer 0/bottom layer) using only the borehole hard data set as conditioning data. Once this layer is simulated, points are sampled from this simulated layer and propagated as https://doi. org/10. 5194/hess-2020-96 Preprint. Discussion started: 14 May 2020 c Author(s) 2020. CC BY 4. 0 License. additional (or secondary) hard data for the next layer. The facies value assigned to these points is drawn accordingly to the vertical transition probability between two facies, calculated from the boreholes hard data set. Three parameters control this method, the first one defines which facies have to be sampled.
). Analogue data or geophysical inputs could help to better understand these geometries and could help in characterizing the transition zone between braided and meander river. Finally, despite these possible improvements, this work demonstrates the applicability of DeeSse and the proposed workflow to simulate complex internal aquifer heterogeneity at a regional scale. Code and data availability. The codes and data will be available soon on git hub : https://github. com/randlab/MPS_Roussillon.
We introduce the Sparkle family of permutations operating on 256, 384 and 512 bits. These are combined with the Beetle mode to construct a family of authenticated ciphers, Schwaemm, with security levels ranging from 120 to 250 bits. We also use them to build new sponge-based hash functions, Esch256 and Esch384. Our permutations are among those with the lowest footprint in software, without sacrificing throughput. These properties are allowed by our use of an ARX component (the Alzette S-box) as well as a carefully chosen number of rounds. The corresponding analysis is enabled by the long trail strategy which gives us the tools we need to efficiently bound the probability of all the differential and linear trails for an arbitrary number of rounds. We also present a new application of this approach where the only trails considered are those mapping the rate to the outer part of the internal state, such trails being the only relevant trails for instance in a differential collision attack.
Schwaemm and Esch were designed to be consistent across security levels, which facilitates a parameterized software implementation of the algorithms and the underlying permutation. All instances of Schwaemm and Esch can use a single implementation of Sparkle that is parameterized with respect to the block (i. e. , state) size and the number of steps. Such a parameterized implementation reduces the software development effort significantly since only a single function for Sparkle needs to be implemented and tested. The performance of Schwaemm and Esch on processor platforms with vector engines (e. g. , ARM NEON, Intel SSE/AVX) can be significantly increased by taking advantage of the SIMD-level parallelism they provide, which is possible since all 32-bit words of the state perform the same operations in the same order.
Supporting cryptanalysis code can be found at https://github. com/cryptolu/sparkle. Table  5 : This table lists upper bounds on the number of steps for which we found an attack, or for which the differential and linear bounds are too low to guarantee security, breaking a security level of  2 bits, where  denotes the block size, with regard to several attack vectors. The numbers for differential and linear attacks correspond to the bounds given in Table  6  and Table 7.
The bound on the maximum expected absolute linear trail correlation we obtained with this modified program is given in Table  7. As argued in Section 3. 5. 3, the slight clustering observed in the double iteration of Alzette does not mean that the absolute correlation of trails is a bad approximation of the absolute correlations in the permutation. Indeed, in each double iteration of Alzette, either the mask in the middle enters the linear Feistel function or it is XORed with another mask. Hence, the clustering at the double ARX-box level does not really matter (especially as it is low in our case), it is the one at the single ARX-box level (which is negligible here).
Linear Layer It is, of course, possible to implement the branch permutation at the end of the linear layer in a straightforward way via a 1-branch left-rotation of the right half, followed by a swap of the left and right branches. However, it is more efficient to combine both operations and implement them with a single loop as shown in Algorithm 8. The optimized C implementation of Sparkle given in Appendix C follows this approach. Both the rotation and swap can be carried out implicitly (and do not cost any clock cycles) when Sparkle is fully unrolled, though this comes at the expense of significantly increased code size. For example, the linear layer of a fully-unrolled implementation of Sparkle384 has an execution time of only 18 clock cycles on a 32-bit ARM Cortex-M3 microcontroller.
Parameterized Implementations Parameterized implementations, offering support to all instances of the algorithm, are easily done and contribute to a small code size. It also facilitates the writing of macro-based code that compiles binaries for a specific instance. An implementation of Sparkle can be parameterized by the number of rounds and branches. Schwaemm implementations need only the rate, capacity, and round numbers. Similarly, Esch needs only the number of branches and steps. Beyond that, a single implementation of Sparkle is sufficient for all instances of Schwaemm and Esch, making optimization, implementation, and testing easier.
Hardware Implementation Both Esch and Schwaemm have a number of properties and features that facilitate efficient hardware implementation, especially when small silicon area is the main design goal. As already mentioned in Section 1. 2, an important characteristic of Esch and Schwaemm is the relatively small size of their state (e. g. , 256 bits in the case of Schwaemm128-128). A minimalist hardware architecture for Esch or Schwaemm (or both) optimized for small silicon area consists of three main components: (i) a small RAM module (with two 32-bit read ports and a 32-bit write port) that is word-addressable and large enough to hold the state words, (ii) a 32-bit ALU capable to execute all arithmetic/logical operations performed by the Sparkle permutation, and (iii) a control unit, which can, for example, take the form of a hard-wired or a microcode-programmable state machine.
Implementation Results We developed reference and optimized C implementations of all instances of Schwaemm and Esch, as well as assembler implementations of the Sparkle permutation for 8-bit AVR ATmega and 32-bit ARM Cortex-M microcontrollers. The AVR assembler code for Sparkle is parameterized with respect to the number of branches and the number of steps, and complies with the interface of the optimized C implementation. Therefore, the assembler implementation can serve as a "plug-in" replacement for the optimized C code to further increase the performance on AVR devices. Thanks to the parameterization, the assembler implementation of Sparkle provides the full functionality needed by the different instances of Schwaemm and Esch. In contrast to AVR, we developed separate assembler implementations for Sparkle256, Sparkle384, and Sparkle512 for ARM, which are "branch-unrolled" in the sense that the number of branches is hard-coded and not passed as argument anymore.
e. this wrapper is parameterized by both the number of steps and the number of branches). The wrapper simply checks the number of branches and then calls the corresponding variant of the assembler function, i. e. Sparkle256 when the number of branches is 4, Sparkle384 when the number of branches is 6, and Sparkle512 when the number of branches is 8. The execution times and throughputs of our assembler implementations of the Sparkle permutation for AVR and ARM are summarized in Table  10. On AVR, the assembler code is approximately four times faster than the optimized C code (compiled with avr-gcc 5. 4. 0), which is roughly in line with the results observed in  [CDG19]. The main reasons for the relatively bad performance of the compiled code are a poor register allocation strategy (which causes many unnecessary memory accesses) and the non-optimal code generated for the rotations compared to hand-optimized assembler code.
Our AVR assembler implementation is also relatively small in terms of code size (702 bytes) and occupies only 21 bytes on the stack (for callee-saved registers). All execution times for AVR were determined with help of the cycle-accurate instruction set simulator of Atmel Studio 7 using the ATmega128 microcontroller as target device. The performance gap between the compiled C code and the hand-written assembler code is a bit smaller on ARM, namely a factor of roughly 2. 5 when executed on a Cortex-M3. However, it has to be taken into account that the assembler functions are "branch-unrolled," whereas the C version is fully parameterized. The C implementation was compiled with Keil MicroVision v5. 24. 2. 0 using optimization level -O2. Obviously, the large register space and the "free" rotations of the ARM architecture make it easier for a compiler to generate efficient code.
The binary code size of the assembler implementations of Sparkle for ARM ranges between 348 and 628 bytes and they occupy at most 48 bytes on the stack, of which 40 bytes are due to callee-saved registers (see Table  11 ). All execution times for ARM specified in Table  10  were obtained with the cycle-accurate instruction set simulator of Keil MicroVision using a generic Cortex-M3 model as target device 11. It should be noted that these ARM assembler implementations are optimized to achieve a balance between small 11 As mentioned on http://www2. keil. com/mdk5/simulation, the Keil simulator assumes ideal conditions for memory accesses and does not simulate wait states for data or code fetches. Therefore, the timings in Table  10  should be seen as lower bounds of the actual execution times one will get on a real Cortex-M3 device.
Besides Sparkle a multitude of other permutation-based designs were submitted to the NIST lightweight cryptography standardization process. Three of those designs, namely Ascon, Gimli, and Xoodoo, come with optimized (i. e. fully unrolled) assembler implementations of the underlying permutation for the Cortex-M series of ARM microcontrollers. Table  12  compares the execution time and code size of the permutations of Ascon, Gimli and Xoodoo with a fully-unrolled version of Sparkle384, the main instance of Sparkle 12. The full loop unrolling reduces the execution time of Sparkle384 from 935 to 781 clock cycles, but this reduction by 154 cycles comes at the expense of an almost six-fold increase of code size. Also given in Table  12  is the throughput (in cycles per byte) of the permutations, which is simply the execution time of the permutation divided by the rate of the main instance of the corresponding AEAD algorithm (16 bytes for Ascon and Gimli, 32 bytes for Schwaemm256-128, and 24 bytes for Xoodyak).
Sparkle384 achieves the highest throughput, closely followed by Xoodoo and Ascon. Gimli reaches less than half of the throughput of of the other three permutations, but it has to be taken into account that the Gimli AEAD algorithm aims for 256 bits of security. Table  13  shows the AVR execution times and throughputs of the different Schwaemm and Esch instances when processing a small amount (64 bytes) and a large amount (1536 bytes) of data, respectively. As before, all execution times were obtained with the cycle-accurate simulator of Atmel Studio 7 using an ATmega128 as target device. The results in the "C + asm" columns refer to a C implementation that uses the hand-written assembler code for the Sparkle permutation. Table  14  summarizes the corresponding results for an ARM Cortex-M3 device.
The binary code size of Esch256 is 1428 bytes. Table  15  summarizes the implementation results of Esch256, SHA-2, SHA-3, some SHA-3 finalists, as well as Gimli[BKL + 17]. Our hash rate of 578 cycles/byte for Esch256 compares favorably with the results of the SHA-3 finalists and is beaten only by Blake-256 and SHA-256. However, it must be taken into account that the results reported in [BEE + 13] were obtained with "pure" assembler implementations, whereas Esch256 contains hand-optimized assembler code only for the Sparkle permutation. We expect that a fully-optimized implementation of Esch256 with all its components written in assembler has the potential to be faster than Blake-256 and get very close to (or even outperform) SHA-256. Such a "pure" assembler implementation of Esch256 is part of our future work and will be made available on the Sparkle homepage at http://cryptolux.
Acknowledgements Part of the work of  Christof Beierle  was performed while he was at the  University of Luxembourg  and funded by the  SnT CryptoLux RG  budget. Luan Cardoso dos Santos is supported by the  Luxembourg National Research Fund  through grant  PRIDE15/10621687 /SPsquared. Part of the work of  Aleksei Udovenko  was performed while he was at the  University of Luxembourg  and funded by the  Fonds National de la Recherche Luxembourg  (project reference 9037104). Part of the work by  Vesselin Velichkov  was performed while he was at the  University of Luxembourg. The work of  Qingju Wang  is funded by the  University of Luxembourg Internal Research Project (IRP) FDISC. We thank  Mridul Nandi  for answering some questions about the Beetle mode of operation and also  Benoît Cogliati  for helping out with questions about provable security of variations of the Beetle mode.
We took the ARM Assembler source code of Gimli from http://gimli. cr. yp. to/gimli-20170627. tar. gz and converted it from the GNU syntax to the Keil syntax. The source code of Xoodoo contained in the eXtended Keccak Code Package (XKCP) at http://github. com/XKCP/XKCP/tree/master/lib/low/Xoodoo was already in Keil syntax.
Particularly, sraX presents unique features: genomic context analysis, validation of known mutations conferring resistance, illustration of drug classes and type of mutated loci proportions and integration of results into a single hyperlinked navigable HTML-formatted file. Furthermore, sraX also exhibits relevant operational features since the complete analysis is accomplished by executing a singlecommand step. The capacity and efficacy of sraX was demonstrated by re-analyzing 197 strains belonging to Enterococcus spp. , from which we confirmed 99. 15% of all detection events that were reported in the original study. sraX can be downloaded from https://github. com/lgpdevtools/srax.
, 2012). In relation to the type of demanded sequence data, two main methodological approaches have materialized: those capable of processing raw reads-read-based methods-and those requiring contig-assembled genome sequences-assembly-based methods. Ultimately, both procedures exhaustively examine for AMR determinants by aligning the input sequence data to curated antibiotic resistance Abbreviations: AMR, antimicrobial resistance; ARG, antibiotic resistance gene; DB, data base. genes (ARG) from custom or public dedicated reference AMR databases (DB). Essentially, read-based methods are faster and less computationally demanding. However, false positives originated from spurious mapping might arise. Moreover, since the genomic context is generally missed, the arrangement of adjacent genes can not be evinced and it constitutes a major drawback  (Boolchandani et al.
sraX follows this analytical workflow by executing a montage of custom Perl and R scripts that opportunely call external open source software and make use of reference AMR DBs. The main capabilities of sraX and a detailed comparison with other pipelines is shown in Table  1. Apart from the usual strategy of retrieving AMR data from public-or privately owned-repositories, compiling a local DB and detecting resistance determinants in analyzed samples, sraX has unique and noteworthy built-in features, like: gene context exploration, SNP analysis, complete graphical output-including drug classes and type of mutated loci-and integration of results into a fully navigable HTML report file. In addition, sraX is proposed as a single-command tool-envisaging that inexperienced users without any technical or bioinformatic knowledge would run it-and it has been devised for running on desktop computer systems, under limited RAM and processing resources.
Wherefore, sraX operates as a standalone tool and a simple and straightforward deployment is achieved from source code-available at https://github. com/lgpdevtools/srax. In addition, easier instances have been produced in the form of a bioconda package-https://anaconda. org/lgpdevtools/sraxand a docker image-https://hub. docker. com/r/lgpdevtools/srax. The complete procedures for properly installing and using sraX are described in the User Manual, Supplementary Information.
MATERIALS AND METHODS 2. 1. Third-Party Data and Software Requirements 2. 1. 1. Reference Databases sraX depend upon a locally compiled AMR DB, which is obtained by gathering sequence data and extensive metadata from external reference AMR DBs. When launching the default resistome analysis, CARD v3. 0. 7  (Jia et al. , 2016)  constitutes the primary data source of genetic determinants. The reasoning behind our choice is that CARD not only provides regularly updated and curated sequence data, but additional complementary information that is specifically organized into ontology entries. Ultimately, sraX benefits from this level of organization for the straightforward access and retrieval of collected AMR data. Nevertheless, in order to conduct a more extensive and thorough ARG homology search, the ARGminer v1.
1. 1  (Argoty et al. , 2019)  and BacMet v2. 0  (Pal et al. , 2014)  DBs-or even customprovided ARGs-are allowed to be eventually incorporated into the sraX analysis. A noteworthy feature of ARGminer  (Argoty et al. , 2019)  is that it aggregates AMR data from several dedicated repositories, including: ResFinder  (Zankari et al. , 2012) , ARG-ANNOT  (Gupta et al. , 2014) , CARD  (Jia et al. , 2016) , MEGARes  (Lakin et al. , 2016) , ARDB  (Liu and Pop, 2008) , SARG  (Yang et al. , 2016) , NDARO (https://www. ncbi. nlm. nih. gov/ pathogens/antimicrobial-resistance/), and DeepARG  (Arango-Argoty et al. , 2018). In consequence, a larger collection of resistance determinants is acquired by combining curated AMR data from CARD, ARGminer and BacMet that ensures a massive search through a wider space.
Software Dependencies Perl v5. 26. x and the following complementary Perl libraries are required for having operative sraX modules: LWP::Simple, Data::Dumper, JSON, File::Slurp, FindBin, and Cwd. For aligning the ARGs to the analyzed genomes, sraX makes use of DIAMOND dblastx v0. 9. 29  (Buchfink et al. , 2015)  and NCBI blastx/blastn v2. 10. 0  (Altschul et al. , 1990). In addition, prior to validating known polymorphic positions conferring AMR, multiple-sequence alignment (MSA) files are created using MUSCLE v3. 8. 31  (Edgar, 2004a,b) , MAFFT v7. 450  (Katoh et al. , 2002 ), or CLUSTAL v1. 2. 4 (Sievers et al. , 2011). The figures generated during sraX analysis are achieved using R v. 3. 6. 1 and the additional following packages: ggplot2  (Wickham, 2016) , dplyr  (Wickham et al. , 2019) , and gridExtra  (Auguie, 2017).
Acquisition of Data Sources for AMR DB Compilation The core collection of reference ARG sequences and their associated metadata is automatically retrieved only from CARD  (Jia et al. , 2016)  when sraX is executed under default parameters. Nevertheless, a more exhaustive search can be performed by selecting the proper option, for including the ARGminer  (Argoty et al. , 2019)  and BacMet  (Pal et al. , 2014)  DBs into the analysis. Moreover, alternative user-provided and curated ARG (nucleotide or protein) sequences in FASTA format can be added (see the User Manual, Supplementary Information). In order to create the corresponding hyperlinks in the final report file, the header should include the following arrayed metadata: gene name, NCBI Accession ID, gene description, type of evinced AMR (protein homolog, protein variant, protein over-expression or rRNA gene variant), drug class, and species name.
Detection of ARGs A directory containing the assembled genome files in FASTA format is the only requirement for accomplishing the sraX analysis. Prokaryote and eukaryote WGS data at any assembly level (e. g. , complete genome, chromosome, scaffolds, or contigs) can be utilized. The homologous genomic regions are detected by aligning the genome assemblies to previously compiled AMR DB. DIAMOND dblastx  (Buchfink et al. , 2015)  is applied by default for making the procedure faster. However, for a higher detection accuracy, NCBI blastx  (Altschul et al. , 1990 ) can be chosen as well. Importantly, NCBI blastn  (Altschul et al. , 1990)  is regularly used for aligning rRNA gene sequences and subsequently identifying the variants conferring resistance.