dataesr/scientific-paragraphs-categorization huggingface dataset:
Evaluation of the methodology and discussion Let us quickly summarize what has been done up to that point. A dataset of 10 4 thermal loadings has been generated with a stochastic model. Its ROM-oriented dissimilarity matrix has been computed. Based on this matrix, the dataset has been split into K = 6 clusters with k-medoids clustering algorithm. An ensemble of DNNs has been trained to assign new unseen thermal loadings to the best clusters using the ensemble averaging method. When considering a new thermal loading, true cluster assignment requires one simplified simulation (5 min) and the computation of six Grassmann distances (less than 1 s). On the other hand, when using the deep classifier F K , preprocessing operations take 5 s and the evaluation of the deep classifier is quasi-instantaneous.
Hence, the computation time for the selection of the best reduced-order model is decreased by a factor of 60 when using the ROM-net's deep classifier F K instead of the true classifier K K. The clustering of the thermal loading database T with the ROM-oriented dissimilarity has defined 6 clusters which can be used to construct a dictionary of 6 local ROMs. Let us compare our methodology with another approach consisting in the construction of a Fig. 13  Distributions of intra-cluster ROM-oriented dissimilarities temperature-based ROM-dictionary D T. Such a dictionary comes from a direct clustering of the input space, that is, a k-medoids clustering of T using distances between the temperature fields evaluated at t = 1. This clustering only considers the input data and does not use simplified simulations to account for mechanical phenomena.
Hence, cluster assignment is directly obtained by taking the minimum distance to clusters' medoids. In this case, there is no need for DNNs since the cost of the classification task is negligible. However, clustering high-dimensional data leads to meaningless results due to the loss of contrast in pairwise distances. This problem is known as the curse of dimensionality  [19]  and appears naturally when dealing with fields defined on a finite-element mesh. To overcome this difficulty, dimensionality reduction techniques must be applied prior to clustering. Distances are calculated in the low-dimensional latent space, whose dimension is a hyperparameter. In this paper, principal component analysis (PCA) is applied for linear dimensionality reduction with 30 principal components, the dimension 30 being a compromise between large dimensions and low dimensions discarding too much information.
Acknowledgement The authors would like to acknowledge the support of the  EU Erasmus+ funding body  under grant number  2018-1-FR01-KA203-047854  and to thank both our colleagues at the  ENSTA Bretagne  and the members of project  A-STEP 2030  for their support, feedback, and intellectual stimulation. The  European Commission  support for the production of this publication does not constitute an endorsement of the contents, which reflect the views only of the authors, and the Commission cannot be held responsible for any use which may be made of the information contained therein.
this work addresses uncertainty propagation in TELEMAC 2D models with respect to two major types of risks in river hydrodynamics: flood hazard and dam failures. The studied case is a TELEMAC 2D model that extends over approximately 14. 4 km 2 with a river length of 41 km including 3 major tributaries to the main river and 3 dams. The implementation of the uncertainty propagation approach would not have been feasible and accomplished without the open source platform SALOME-HYDRO and the TELAPY module (PYTHON API) of the TELEMAC-MASCARET SYSTEM. The first step consisted of quantifying uncertain parameters for the acquired hydraulic model and defining adequate probability distributions based on expert judgment and previous specific studies that have been provided by EDF. A sensitivity analysis based on Morris screening method was then carried out to reduce the number of uncertain factors.
Step C consists in propagating uncertainties on the input through the model. In most cases, a sensitivity analysis (step C´) is required to assess the influence and the importance of input parameters with respect to the randomness of the output. [2]  One objective of this work is to apply the previously defined steps; adopted by EDF R&D  [2] , on a TELEMAC 2D hydraulic model that includes dam failures scenarios through the conception of user-friendly PYTHON scripts. The main methods tested in this work are the classical algorithm of Monte Carlo using different sampling techniques such as Quasi-Monte Carlo with low discrepancy sequences, the Morris screening method for sensitivity analysis and the Polynomial Chaos Expansion to build surrogate models.
A dam failure correspond to the event of exceeding a dam stability threshold defined based on expert judgment. The rating curves are switched once the break occurs via TELAPY PYTHON script and user FORTRAN file. The solution of Ritter is considered to represent the rating curve associated with the break  [4]. The model also includes 7 bridges which are modelled as drag forces in the FORTRAN subroutine Dragfo. The bridges are considered unstable if the water level upstream of the bridge is higher than the bridge deck level. In terms of computation time, one run of the model takes approximately 1h10min on 56 processors. This was found to be the optimal number of processors for the studied model. For this study, the variables of interest are the maximal free surface elevation and the maximal water level (for the flood damages quantification).
D. Dam break scenarios The scenarios considered in this study are: Break scenario: total and instantaneous dam breaks triggered by the break of the 1 st upstream dam. Reference scenario: no dam breaks E. Implementation using the APIs and the Clusters The sensitivity analysis and uncertainty propagation methods were implemented using the C++/PYTHON library OPENTURNS  [9]  designed for the treatment of uncertainties. It coupling with the hydraulic model (i. e. TELEMAC 2D) is facilitated by the use of the TELAPY module  [10]  which allows to set and run TELEMAC instances via PYTHON. Since a large number of simulations are going to be executed, the optimization of the computation time using the available EDF clusters is deemed necessary to accomplish this study. If the TELEMAC model only is parallelized, a minimal time of approximately 48 days 14 hours is required for 1000 simulations.
Hence, one should modify and adapt these criteria based on expert judgment and regulatory requirements. All the methods and the steps of this study were carried out using PYTHON scripts. However, this methodology can be partially implemented using the SALOME-HYDRO platform except for the user FORTRAN and the TELAPY scripts that handle specific aspects of the hydraulic simulation (i. e. dam breaks here). SALOME-HYDRO only lacks the launching parallelization which should be soon available.
V. CONCLUSIONS The implementation of the uncertainty propagation approach would not have been feasible and accomplished without the open source platform SALOME-HYDRO, OPENTURNS and the TELAPY module (PYTHON API) of the TELEMAC-MASCARET SYSTEM. The main difficulty -which is generally common to probabilistic models that treat uncertainty propagation -remains the optimization of computation time with respect to the number of simulations considered and the run-time of the TELEMAC case; whether it is in parallel or sequential mode. The main objectives of this study; which were the application of the uncertainty propagation methods on a hydraulic model at an engineering scale and the conception of user-friendly PYTHON scripts that makes such parametric studies within the reach of any TELEMAC user, were accomplished.
Numerical Study This subsection provides a simulation study, offering a numerical check assessing the behavior of the MLEs for the TOFrE model parameters. We determine the mean squared errors (MSEs), as well as average lower bounds (LBs), average upper bounds (UBs) and average lengths (ALs) (i. e. , defined by the following generic formula: AL = UB -LB), of the asymptotic two-sided confidence intervals of the model parameters (the levels 90% and 95% are considered). The software Mathematica 9 is used. The following scheme is adopted. • We generate 1000 random samples (x 1 ,. , x n ) of size n = 100, 200, 300 and 500 from the TOFrE distribution. • We consider the following values for the "supposed true parameters", with order: (θ, λ, β): Set1(1. 5, -0. 5, 2), Set2(1. 5, -0. 3, 1. 5), Set3(1.
Data Sets I and II (Exponential Tail) Let us now present our two first data sets of interest, both coming from real-life phenomena. Data set I. The first data set, called Data set I, is obtained from  [40]  and comes from a reliability analysis. The data are also available at the following electronic address: https://chesneau. users. lmno. cnrs. fr/DatasetI. txt Data set II. The second data set, called Data set II, contains 72 measurements of excedances of the Wheaton river in Canada, between 1958 to 1984. These data were also considered by  [41] , among others. The data are also available at the following electronic address: https://chesneau. users. lmno. cnrs. fr/DatasetII. txt The basics statistics of these data sets are given in Table  7 , with support of the corresponding boxplots in Figure  4.
Tables  10  and 11  present the values of the criteria of fitness of the models for Data sets I and II, respectively. 6  and 7 , respectively. Visually, in comparison to the competitor models, the blue curves of the estimated fits of the TOFrE model are more close to the empirical pdfs and cdfs. We complete this part by determining the confidence intervals of the TOFrE model parameters in Table  12 , as described in Section 4. We now consider a data set of different nature from insurance losses, called Data set III. It represents the vehicle insurance losses as considered in  [43]. It is fully available at the electronic address: https://chesneau. users. lmno. cnrs. fr/DatasetIII. csv We may refer to  [43]  for all the necessary descriptive statistics. Thus, we aim to apply our statistical methodology to this new data set.
Data provenance refers to records of the inputs, entities, systems, and processes that influence data of interest, providing a historical record of the data and its origins. Secure data provenance is vital to ensure accountability, forensics investigation of security attacks and privacy preservation. In this paper, we propose Prov-Trust, a decentralized and auditable SGX-based data provenance system relying on highly distributed ledgers. This consensually shared and synchronized database allows anchored data to have public witness, providing tamper-proof provenance data, enabling the transparency of data accountability, and enhancing the secrecy and availability of the provenance data. Prov-Trust relies on Intel SGX enclave to ensure a trusted execution of the provenance kernel to collect, store and query provenance records.
The use of SGX enclave protects data provenance and users' credentials against malicious hosting and processing parties. Prov-Trust does not rely on a trusted third party to store provenance data while performing their verification using smart contracts and voting process. The storage of the provenance data in Prov-Trust is done using either the log events of Smart Contracts or blockchain's transactions depending on the provenance change event, which enables low storage costs. Finally, Prov-Trust ensures an accurate privacy-preserving auditing process based on blockchain traces and achieved thanks to events' logs that are signed by SGX enclaves, transactions being registered after each vote session, and sealing the linking information using encryption schemes.
Prov-Trust relies on Intel SGX enclave to ensure a trusted execution of the provenance kernel to collect, store and query provenance records. The use of SGX enclave protects data provenance and users' credentials against malicious hosting and processing parties. The Prov-Trust framework does not rely on a trusted third party to store provenance data while performing their verification using smart contracts and voting process. Indeed, a smart contract is used to monitor the changes performed over a document while implementing access control policies and maintaining all users' accesses/modification to the document. The vote contract allows a set of designated users to vote for/against the change of a set of defined provenance change events, namely "download" and "transfer". The storage of the provenance data in Prov-Trust is done using either the log events of Smart Contracts or blockchain's transactions depending on the provenance change event, which enables low storage costs.
Data Provenance Solutions Data provenance refers to the chain of ownership of a piece of data that covers who created it, who modified and accessed it  (Moreau et al. , 2010). Data provenance is used to investigate security incidents where data provenance is analysed to detect malicious actions, data breaches and access policy violations. Extensive research has been conducted on data provenance in database, file workflow and operating systems  (Suen et al. , 2013)  and many provenance management systems have been proposed  (Zafar et al. , 2017). PASS is one of the first systems that have been designed to provide automatic collection and maintenance of provenance data  (Muniswamy-Reddy et al. , 2006). Improved versions of PASS that supports the integration of multiple levels of abstractions have been introduced after its first release  (Muniswamy-Reddy et al.
, 2008). PASSv2 operates within the three levels of abstraction: the system call boundary, a workflow specification language, and a domainspecific application level. HiFi is a kernel level provenance system that uses Linux Security Modules to gather provenance data  (Pohly et al. , 2012). These generated data can be forensically analysed to detect malicious activities thanks to the tracking of the kernel and application actions within the Linux system. SPADE  (Gehani, 2016 ) is a provenance middleware providing users with a framework to collect, store and query provenance data that are generally data graphs describing the history of processes ran over a piece of data. Open Provenance Model (OPM) is a methodology representing the provenance graphs in three types of nodes: artifacts, processes and agents  (Moreau et al.
, 2011). The emergence of cloud computing created a need to adapt/develop provenance systems to track data changes in such highly distributed systems. Collecting provenance data is particularly challenging in complex systems such as cloud computing that presents multiple layers of interacting software and hardware. Cloud computing systems are dynamic and heterogeneous systems involving several components provided by different providers. Many data provenance systems have been designed for cloud computing. SPADEv2  (Gehani, 2016)  has been introduced as an open source tool supporting both graph and relational database storage and querying in a distributed system which makes it adapted for cloud computing. S2Logger is a solution designed to capture and visualise end-to-end provenance data across all guest and host physical machines in distributed virtualised environments such as cloud computing  (Suen et al.
The unforgeability means that an adversary cannot forge a valid provenance record either by modifying any existing one or directly introducing a new forged provenance record without being detected. Hence, unforgeability guarantees the tamper evidence  (Asghar et al. , 2012; Taha et al. , 2015). A first attempt to use Trusted Platform Module to ensure trust in provenance generation had been introduced by Bock et al. (Böck et al. , 2010). This solution presented a data provenance collection solution using a TPM chip and the AMD Secure Virtual Machine (SVM) technology. This solution has been enhanced further by Taha et al. (Taha et al. , 2015)  by adding the integrity and availability of the provenance data to the solution. In our proposed solution Prov-Trust, we leverage Blockchain technology and trusted hardware; the Intel SGX to provide trustworthy and secure provenance data.
Intel SGX The trusted hardware has been introduced to solve the issue of secure remote computation, which means that a user can securely execute a software on a distant untrusted party. The trusted hardware creates a secure container enabling a user to upload his software and data to the secure container where computations are performed while protecting their confidentiality and integrity. Trusted hardware solutions have been introduced such as TPM  (Main, 2007)  and TXT  (Grawrock, 2009 ). Intel's Software Guard Extensions (SGX) is the latest iteration of designing trusted hardware solutions  (McKeen et al. , 2013). Intel SGX is a set of CPU extensions enabling the creation of a trusted isolated execution environments. This isolated execution environment which is referred to as Enclave, enables running an application residing in the enclave while protecting its confidentiality and integrity from other software including an untrusted operating system.
r. t. associated credentials. Indeed, only authorized PAs can decipher linking information, re-construct the whole provenance graphs and correlate the provenance entry to the data owner. • Validators (V)are participants, also referred to as voters, who vote for/against the change of a set of provenance change events, namely "download" and "transfer", using a vote protocol. We assume that validators may be chosen based on a reputation system. • Blockchain Network (BC)consists of globally participating nodes. All the provenance data will be recorded in form of blocks and verified by blockchain nodes. • SGX Enclaveis responsible for processing user queries and returning results to users without leaking any content and access pattern to the CS. SGX enclave is also considered to be trusted. In particular, both integrity and confidentiality of the code and data inside the enclave are protected with inherent cryptographic mechanisms.
Based on the cryptographic signature provided by the SGX, information provided by SPADE client are certified to be generated by a trusted software. • Cloud Service Provider (CSP)offers a cloud storage service and is responsible for user registration. CSPs can benefit from the Prov-Trust system in the following aspects. First, they are able to audit the publicly available data changes. In addition, through provenance data, they can also detect intrusion from anomalous behaviours, when privileges are granted.
Overview Prov-Trust relies on three main layers, supporting different execution steps (i) the system initialisation, denoted as SYS INIT, (ii) the data provenance storage phase, i. e. , STORAGE, and (iii) the auditing process, referred to as AUDIT. In the following, we provide an overview of different execution layers and detail the interaction flow between entities (Figure  2 ): During the SYS INIT phase, the system is set up and each entity is assigned with a pair public and private keys. Indeed, SGX enclaves are installed on their respective hosting devices and provided with associated keys. The STORAGE phase encompasses two main protocols, namely the Create and Evt. During the Create protocol, the DO has first to create a smart contract (SC), denoted by prov-doc, per data file that he intends to track its change/access events.
The prov-doc contains the Access Control List (ACL) on the data content, i. e. , which actions and/or entities are authorized. It also contains the ACL on the events' logs of the associated smart contract. Note that the creation of prov-doc has to be anchored into a BC transaction. The DO may also -optionally-createa vote smart contract associated with the prov-doc smart contract. The vote SC, referred to as vote-doc, describes the voting protocol associated with the related data file. It specifies the process of voting and the choice of voters. The vote-doc smart contract is mainly required to validate both the download and transfer actions. Note that the vote is not necessary as the data owner may directly grant the permission to the requesting entity. For the Evt, two sub-cases are considered, depending on the design choice of the DO.
On one hand, when a DU wants to perform some actions on a data file, excluding the download and transfer actions, an event log will be added to the thread of the prov-doc smart contract. Note that each event log has to be signed by the SGX enclave of the requesting entity. On the other hand, when DU wants to do ei-ther a download or a transfer action, the vote-doc smart contract is called. At the end of the vote process, a BC transaction needs to be added including the vote result, and signed by a chosen voter. For the AUDIT phase, Prov-Trust considers two auditing processes. In fact, the auditing process can be performed either by the DO or an authorized provenance auditor. As several parts of the event logs and BC transactions are encrypted, the chaining process, permitting the PA to reconstruct the provenance graph associated to a specific data file, is ensured as described in  (Kaaniche and Laurent, 2018).
System Initialisation The SYS INIT phase includes two different algorithms, defined as follows: • Setup(ξ) → (pp, msk) -given the security parameter ξ, this algorithm generates the public parameters pp. • KeyGen(pp, E i ) → (pk E i , sk E i ) -derives the public and private keys of an entity E i , where E ∈ {DO, DU, PA,V }, i ∈ {1, N}; N is the number of actors supported by the system. It takes as input pp and the entity's identifier E i. The KeyGen algorithm returns the entity's pair of keys (pk E i , sk E i ). We assume that each device d i , running the SPADE tool, i. e. , data provenance algorithm, has a private key denoted by k E i. This proprietary key is used to sign events associated to DO's data files. Note that a DO may have several devices, thus running different enclaves on each device.
The Create Process The Create protocol defines the process of creating smart contracts associated to data contents. First, the DO first creates the prov-doc smart contract, per data file that he intends to track its access and processing events. The prov-doc contains two main parts : the Access Control List (ACL) on both the data content, i. e. , which actions and/or entities are authorized, and the events' logs. Note that for ease of presentation, we refer to ACLs to any access control mechanism selected by the DO, to be enforced on his data. ACLs on data contents may be encrypted, however, they have to be accessible to the CSP, the PA as well as voters, if a voting smart contract was created. ACLs on provenance data should ensure the access to involved parties, with respective privileges, as implied by legislation, namely data owners, data processors and controllers, and auditing authorities.
For this purpose, DO establishes a direct secure channel with the CSP, where CSP and DO authenticate each other thanks to their respective (pk E i , sk E i ) pair of keys (cf. Section 5. 1). The creation of prov-doc has to be anchored into a BC transaction. The transaction is identified with a T id parameter. Through this channel, DO might initiate a data storage request to the CSP, to infer some parameters for the smart contract prior to launching the smart contract into the blockchain, up-to the approval of the contract by the CSP and transmission of data to its servers. This process is then registered in the blockchain by the involved CSP, such as a SC creation transaction is added. It is defined as follows: T C = {T id,C ,C, SC id , σ k CSP } • T id,C -denotes the transaction identifier, which contains a unique fresh random and a binary identifier associated with the SC generation process.