dataesr/scientific-paragraphs-categorization huggingface dataset:
Core Analytics Module The queries triggered by the visualisation clients are processed by the Core Analytics Module which retrieves and analyses the data. This module runs on the HPC infrastructure and delivers the query results to the visualisation clients. The data are compressed to avoid overloading the network. Different internal modules are in charge of the different functions: • Query Manager Module. This module is in charge of receiving and decomposing the queries into small and simple queries or operations. These operations can be reused by different queries, facilitating the addition of new queries to the platform. Basically it acts as a multi-user server that is able to process multiple queries at the same time. • VELaSSCo Operations. It provides an abstraction of all the operations.
These operations are shared between the open-and closed-source versions of the platform. • Storage. It is in charge of delivering the results of noncomputationally-intensive operations. This module is directly connected to HBase to read the data without any kind of analytic computation. An example might be an operation to return the velocity value from a particular particle's ID. • Analytics. It executes the computationally-intensive calculations to produce the post-processing results. These calculations are executed as MapReduce jobs distributed over the Hadoop nodes. This module also stores the results of the most useful queries in HBase, so when the users execute these queries for the first time, the results are calculated and stored, providing near-instant results when the query is next called.
Data Layer The Data Layer is the deepest layer which stores and manages the data. The core of this layer is HDFS which is responsible for data storage and distribution across regions. It guarantees data replication across the Hadoop cluster and fault tolerance. HBase is a non-relational database that works on top of HDFS and provides real-time access to the data. As it stores information with a key/value structure, all data can be easily accessed. The simulation data can be received by the system in real-time or via files with the final data stored on disk. The injection module manages both data sources. Apache Flume is used to ingest simulation data into HBase. Once the data are stored in HBase, the injection module is able to perform some post-injection actions, e. g. , execute a set of frequently called queries and store the results data to provide faster results to users in future queries.
Data are provided to the platform in a file format which has been developed as an extension to ISO 10303-209:2014 Application protocol:"Multidisciplinary Analysis and Design"  35, 36. A well-defined input format allows the platform to be used by many different simulation solvers with ease. An example of the standard input for DEM data for spherical particles is presented in Listing 2, which also shows how an optional variable, angular velocity (in a vector format), can be included. Additional variables can be defined as either vectors or scalars. The orientation of non-spherical particles can be accounted for by including the nine-component orientation matrix as the first additional output in the particle file.
Analysis of DEM Simulation Data with the VELaSSCo Platform The VELaSSCo platform has been designed such that using VELaSSCo for analysis of data becomes a relatively trivial task for the end-user, with the complexity of implementation hidden in the background. The user accesses the platform through a simple GUI which allows manipulation of the data using the features of the visualisation client. Currently plug-ins have been written for the popular iFX and GiD visualisation clients that allow these to work seamlessly with the VELaSSCo platform. The Discrete2Continuum (D2C) transformation is one of the advanced analysis tools that has been incorporated within the platform. It applies temporal and spatial coarse graining methods to DEM simulation data to compute bulk quantities (such as solid fraction or stress tensors) that are projected onto a continuum field.
The key parameter here is the coarse graining width, which can typically be related to the particle size in quasi-static simulations  15. • Temporal averaging parameters: Temporal averaging allows the end user to analyse the results over a timeframe that is relevant to the problem being studied -the data output frequency from the DEM solver is not always the most relevant. • Spatial integral parameters: This is a novel function that allows certain problem types to be considered as plane strain (two-dimensional) problems, reducing the computational cost associated with the D2C transformation. Utilising the distributed nature of the data allows significant performance gains to be made. In particular, the default HBase replication factor ensures data blocks are distributed across multiple regions which improves load balancing during a job execution.
Data for one timestep correspond to one data block. During ingestion, a distribution strategy can be specified, e. g. , random timesteps/blocks allocated to random nodes or a range of consecutive timesteps allocated to random nodes. The latter may not be the best for parallel execution. Sometimes manual data relocation is performed to have an optimal distribution of data for a specific simulation. The correctness of the algorithms has been thoroughly checked against a number of unit tests that take in a set of input parameters and expected outputs. The results have also been compared with those produced by other tools such as Particle Analytics software  37. The robustness of the algorithm was tested using a fault injection strategy whereby a set of invalid input parameters or simulation data values were used in order to ensure that exceptional cases are handled in an appropriate manner in the algorithm without failing or creating inconsistent data in the Data Layer.
For these purposes, the Hadoop JobTracker web interface visualisation tool was used. The JobTracker web interface provides a wealth of information on jobs and tasks that are running on the cluster as well as historical information on completed jobs (including ones that failed). The Analyse job history link on the Job details history page displays a summary of task performance statistics and details of individual task attempts can be extracted. The complex queries including the D2C algorithm are implemented as MapReduce jobs. The D2C is heavily optimised to run in parallel. For a given D2C process, a number of mappers are spawned across the nodes. Each mapper works simultaneously on a set of timesteps from the complete datasets to compute results associated to mesh points in the continuum field.
This amounts to the toplevel parallelism present in the algorithm by processing independent timesteps based on where they are located across the nodes. Further parallelisation is exploited within each timestep as computation of results in the mesh can be decomposed into regions. Effectively, the D2C exploits two levels of parallelism: across nodes and within a node by leveraging multiple cores. The reduce phase performs a summary operation for, e. g. , computing averages and storing results back into the database. The two levels of optimisation that can be enabled during a D2C run are: • Op. 1: the default optimisation is enabling parallelism across nodes, i. e. , a parallel task is created for each timestep within the selected simulation time range. This may lead to multiple tasks running on: 1) a single node (if timesteps reside only on that node), 2) multiple nodes (if the data blocks are well distributed).
The results show slightly less than linear speedup, with a speed-up factor of 87% and measured memory ratio 0. 925 showing efficient memory usage on one to three nodes. Due to the problem size, as only 100 or fewer timesteps of data (with each one just over 1 MB in size) are being processed, only three nodes are used as the job set-up time on each node and communication times start to become the limiting factors on performance for such a small problem. While this level of optimisation shows good performance on relatively small datasets, it does not utilise the available resources fully. In order to quickly process much larger datasets, further optimisation of the D2C algorithm is required to exploit all available cores on a node. At a node level, data can be further decomposed into regions and results computed in parallel using multiple processor cores available on that node (Op.
2). The increase in performance from this further optimisation is illustrated by Figure  4 , where the effect of node-level parallelisation and node usage is shown for the large dataset. The data falls into two distinct groups based on the level of optimisation used. Without node-level parallelisation (Op. 1), the processing runtimes using different amounts of level one optimisation (1, 2 & 10 nodes) are significantly higher as reflected by the three top data series. As the number of nodes utilised is increased, the total runtime begins to decrease significantly, to the point where running 10 timesteps of data across 10 nodes is only slightly slower than one timestep on one node. 1  for details) However, by enabling the second level of optimisation, the algorithm effectively takes advantage of all processor cores on the node and shared memory access of the timestep being processed and consequently reduces the time it takes to compute results for all data significantly.
Sample Applications and Post-processed Results Two specific use cases (one small dataset, one large dataset) have been considered for the evaluation of the VELaSSCo platform for DEM data. The smaller dataset is for a simple fluidised bed simulation while the large dataset is for a railway embankment simulation. The details of the use cases are presented in Table  1. Both use cases cover some of the more challenging aspects of dealing with DEM data: large amounts of particle and contact data and many timesteps. Use Case 1: Fluidised Bed Over the years, industries have realised that fluidised systems offer many advantages, and as a result, fluidised bed processes have become commonplace in the pharmaceutical and other chemical industries. They are able to provide high levels of contact between a solid and a gas, which makes them extremely useful as driers; Fluidised-Bed Catalytic Cracking (FCC) is one of the most important and widely used refinery processes for converting low value, heavy oils into more valuable lighter products.
They are also commonly used for particle coating due to both their high gas/solid surface area and high level of mixing. The Fluidised Bed use case presented here (Figure  6 ) is the smaller of the two use cases, although it contains data for a very large number of timesteps. Due to the dynamic nature of fluidised beds, the simulation was sampled at a high frequency, and as a result, a total of 40,800 timesteps of data were generated. The results of interest in this simulation are mass, volume, velocity vector along with the contact force vector. The simulation was carried out on an HPC cluster using the molecular dynamics code LAMMPS 8.
Use Case 2: Railway Embankment Significant demands are being placed on rail networks around the world, with growing traffic pushing the limits of the existing infrastructure. Extra traffic is accommodated through both higher train speeds and larger axle loads. Considering the naturally discrete, inhomogeneous structure that is a ballasted trackbed, DEM is ideally suited to study ballasted railway infrastructure. With advanced analysis tools, the stress distributions and deformation patterns that develop in ballasted track systems can be analysed, providing key scientific insights into ballasted tracks. However, in order for the simulations to provide sufficient insight, the simulations must be carried out on a large scale, which drives the need for a post-processing tool capable of dealing with the large volumes of data generated.
The simulation, which was carried out in the commercial code EDEM  38  , is shown in Figure  9  and produced a dataset of 540 GB for the short duration investigated. The results processed and analysed with this dataset are mass, volume, translational and angular velocity vectors and the contact force vector. The railway embankment simulations are carried out to study the effect of cyclic loading due to many trains passing, and as such, are long-duration simulations which generate large amounts of data. This use case examines the effect of ten cycles of train loading; results from the first cycle are presented here. The train is travelling from left-to-right (positive X direction) with a velocity of 70 km/h. In Figure  10 , the loading is applied by a two-axle bogey. The first axle of the bogey is just approaching the sixth sleeper while the second axle of the bogey is directly located on the second sleeper.
This information is particularly useful to the engineer as the stress levels will typically increase with higher speeds or higher axle loads. Using this simulation information, the safe loading limit of the embankment could be established or the ability of the underlying ground conditions to support such loads could be investigated. The VELaSSCo platform has been developed to store, manage and post-process very large simulation datasets. The results presented in the use cases so far have shown the post-processing capabilities of the platform for interrogating a single timestep of results. However, the platform also provides the ability to query the entire time range of the data, not just the currently loaded timestep. A more typical application of this capability is the creation of animations of the dataset to visualise the dynamic behaviour exhibited, such as the example of a Fluidised Bed 39 from Use Case 1.
Further utilising this ability, the end user can extract some results and see their variation over time such as in Figure  16 , where the evolution of the vertical stress in the rail embankment at three points of interest for the first loading cycle is shown. While analysis like this is trivial for small datasets and could easily be accomplished on a conventional workstation, this sort of analysis would not be possible for large datasets on such a workstation due to the limited memory, storage space and computational power.
Conclusions This paper has described the development of the VELaSSCo platform which is a powerful, flexible tool for the visualisation and analysis of large datasets. The platform is built on top of the open-source Hadoop software stack and utilises the Hadoop Distributed File System (HDFS) to safely and efficiently manage extremely large datasets. The architecture has been designed to allow fast processing of simulation data on the cluster before efficiently transferring the requested result back to the visualisation client on the desktop. Scalability was a key consideration for the architecture and the platform can be deployed on custom clusters consisting of several hundreds or thousands of nodes, and accommodate very large distributed datasets. Key to improved performance is an effective distribution strategy of data across the nodes, and a processing algorithm adapted to take advantage of this.
There are many DEM solvers currently freely available as open-source software, as well as many other commercial codes. In order to make the platform work with such a large group of software a file format for exporting DEM data was developed and this has been accepted as an extension to ISO 10303-209 "Multidisciplinary Analysis and Design"  35. The Discrete2Continuum module is a tool that provides advanced analytics for DEM datasets, far beyond the simple visualisation and querying of particle properties. The module is a highly optimised toolbox that can analyse the particle data across different spatial and temporal length scales and provide key macroscopic properties such as stress, density and velocity. The distributed nature of the architecture means there is a significant performance increase for large datasets from adopting Big Data methodology for importing and storing raw data.
The algorithm has been heavily optimised to run in parallel across both multiple cores on a node and multiple nodes on a cluster, which has led to significant decreases in run time from a simple implementation, as would be common on a conventional workstation. A selection of use cases have been presented to show the VELaSSCo platform at work. These use cases highlight datasets that are typically difficult to process on a standard workstation due to their large size and memory footprint. Using the VELaSSCo platform, these datasets can be processed in the background and then streamed back to the visualisation client on the desktop for viewing of the results. The results highlight both the need and advantage of being able to carry out such spatial and temporal averaging on DEM datasets, as the end user is able to access revealing information that cannot be seen in the particle data alone.
68 that leads to a forgery attack breaking 64-bit security. This implies that the security margin of TinyJAMBU with respect to the number of unattacked rounds is approximately 12%. We also show a differential on full 384 rounds with probability 2 -70. 64 , thus the security margin of full rounds with respect to the data complexity, namely the gap between the claimed security bits and the attack complexity, is less than 8 bits. Our attacks also point out structural weaknesses of the mode that essentially come from the minimal state size to be lightweight.
However, such models involve too many variables and constraints, and thus cannot be solved in practical time. As reported in [SHW + 15a], such a precise trail search is useful to verify the validity of a given trail but not so efficient to find optimal ones. To conclude, the main difficulty of the analysis of TinyJAMBU is to achieve both accuracy and efficiency simultaneously. The designers' approach is relatively fast but inaccurate, while the known accurate methods are too slow. Our Contributions. In this paper, we present the first third-party security analysis of TinyJAMBU by applying differential and linear cryptanalysis. Our attacks in the AEAD setting are valid for all members of TinyJAMBU, because those exploit the computations (nonce-setup, associated data processing, or tag generation) in which the number of rounds of the underlying keyed-permutation is fixed to 384 for all members of TinyJAMBU.
We first present a refined MILP model that takes into account the first-order correlation that naturally occurs in TinyJAMBU. We observe that TinyJAMBU computes an AND operation a • b for two bits a, b in some round, and computes b • c for another bit c in another round. Those two AND operations have a strong correlation. When (∆a, ∆b, ∆c) = (1, 0, 1), the output differences of those two AND gates are either both 0 with probability 2 - 1  or both 1 with probability 2 -1. Namely, two AND gates are controlled with probability 2 -1. 1 We present a model to take into account these correlated AND gates. The refined model hits a balance between accuracy and efficiency. The resulting models can be solved in reasonable time and most of the trails identified are valid. We then apply the refined model to TinyJAMBU such that the input difference to the underlying keyed-permutation is injected from the input data blocks specified in the TinyJAMBU mode, thus the identified trails immediately lead to the forgery attacks.
We evaluate the number of rounds that breaks the claimed 64-bit security against forgery attacks. We find a differential trail with probability 2 -64 for 338 (out of 384) rounds, which involves 76 active AND gates but contains 12 correlated paired AND gates. After evaluating multiple trails with the same input and output differential masks, the differential probability is 2 -62. 68. Hence, the security margin with respect to the number of unattacked rounds is about 12%. Regarding the full 384 rounds, we find a differential trail with probability 2 -74 , which involves 88 active AND gates but contains 14 correlated pairs. The differential probability turns out to be 2 -70. 68. Hence, the security margin with respect to the data complexity for the full rounds is less than 8 bits. We also evaluate TinyJAMBU by removing the constraints on the active-bit positions of the input and output.
Notations and the Specification of TinyJAMBU Let F 2 = {0, 1} be the finite field with two elements. Given a vector or bit string v ∈ F n 2 , |v| = n denotes the size of v in bits. For a and b ∈ F 2 , ā, a ⊕ b, ab denote the logical negation, exclusive-or, and logical AND, respectively. Also, a NAND gate sends its input bits a and b to ab = ab ⊕ 1. Given two vectors u, v ∈ F n 2 , their inner product is denoted by u • v. TinyJAMBU  [WH19] , a small variant of JAMBU  [WH15] , is a family of authenticated encryption with associated data (AEAD) schemes submitted to the NIST Lightweight Cryptography (LWC) Standardization project, and it was selected as one of the 32 round-2 candidates in August, 2019  [Nat19a]. Under the control of a secret key K =   The encryption algorithm of TinyJAMBU can be divided into four phases.
The differential trail is valid if and only if there are actual data pairs following the differential, or equivalently, the system of equations given by Eq. (3) has a solution. In the language of the matrix representation of the system of linear equations, we have γ(M ) = γ( M ), where M is the coefficient matrix of the system of equations, M is the augmented coefficient matrix, and γ(•) computes the rank of a matrix. For this system of equations, we have s = |{x 70+i , x 85+i : 0 ≤ i < l}| independent variables, and thus there are 2 s different input values for the AND gates. The probability of the given differential can be computed as the number of solutions of the system of equations divided by 2 s , that is, 2 s-γ(M ) 2 s = 2 -γ(M ). (5) When we search for differential trails of TinyJAMBU, we can add the constraints describing the system of equations [SHW + 15a, SHW + 15b] into the MILP model and set the objective function to minimize the active AND gates.
Conclusion We presented the refined model to efficiently find highly accurate differential and linear trails of TinyJAMBU. With the refined model, we found a forgery attack with complexity 2 62. 68 on 338 rounds and a differential trail with probability 2 -70. 68 for the full 384 rounds. Those imply that the security margin of TinyJAMBU is smaller than originally expected, which is now 12% with respect to the number of unattacked rounds or less than 8 bits in the data complexity for the full rounds. We also applied the refined model to the linear cryptanalysis and found the better bias for some number of rounds. Though our attacks do not contradict the original security claims, the attacks are generic and the margins are already quite small. One simple solution would be to increase the number of rounds of the small version, P K , from 384 to 512 rounds.
Acknowledgments We would like to thank the anonymous reviewers for their helpful comments. We also would like to thank the attendees of ASK 2019 for having helpful discussions. Siwei Sun ,  Danping Shi , and  Yingjie Zhang  are supported by the  National Key Research and Development Program of China  (Grant No. 2018YFA0704704 ), the  Chinese Major Program of National Cryptography Development Foundation  (Grant No. MMJJ20180102 ), the  National Natural Science Foundation of China  ( 61772519 ,  61802400 ), and the  Youth Innovation Promotion Association of Chinese Academy of Sciences. Ferdinand Sibleyras  is partly supported by the  French DGA.