dataesr/scientific-paragraphs-categorization huggingface dataset:
Overall System Model We model the Tendermint blockchain network as a dynamic directed graph G = (N, E), where N denotes the dynamic node (vertex) set, E denotes a dynamic directed link (edge) set. A node n can enter and leave G by using its join(G) and leave(G) actions, respectively. Upon joining G, n discovers neighbor nodes to connect to. A link n, m ∈ E represents a directed link n → m, where n, m ∈ N, n is the owner of the link, and n is the neighbor of m. A node n can communicate with a set of recipient nodes R n (where ∀m ∈ R n |{n, m} ∈ E) by exchanging messages of the form n, msg, d , where n is the sender, msg is the type, and d is the data contained. Each node n ∈ N has a list of its neighbors N n , where N n ⊆ N and ∀m ∈ N n | n, m ∈ E. A node n adds and removes another node m as its neighbor using its addNeighbour(m) and removeNeighbour(m) actions, respectively.
The High Performance Computing (HPC) domain aims to optimize code to use the latest multicore and parallel technologies including specific processor instructions. In this computing framework, portability and reproducibility are key concepts. A way to handle these requirements is to use Linux containers. These "light virtual machines" allow users to encapsulate applications within its environment in processes. Containers have been recently highlighted because they provide multi-infrastructure environnement for both developers and system administrators. Furthermore, they offer reproducibility due to image building files. Two container solutions are emerging: Docker for microservices and Singularity for computing applications. We present here the Com-puteOps project which investigates the container benefits for HPC applications.
Pilot applications The pilot applications have been chosen to tackle research in particle physics and gravitation. They have been selected in order to use the specific characteristics of the underlying hardware: • SMILEI 7 : the code is an open-source, particle-in-cell code. As a multi-purpose code, it is designed for and applied to a wide range of plasma physics-related studies: from relativistic laser-plasma interaction to astrophysical plasmas. It is co-developed by both physicists and HPC experts, supported by GENCI 8 and Intel. • CMS MEM 9 : this code uses the Matrix Element Method (MEM) for the analysis of the Higgs boson production with two top quarks (ttH channel) in the CMS experiment. The code, based on OpenCL and CUDA, is adapted for MPI as well as multi-GPU (>20 GPUs) execution.
• electron_capture: this is a code computing electron capture rates, based on finite temperature Hartree-Fock and finite temperature random-phase approximation (RPA) using Skyrme interactions, used for astrophysics computation [2]. The application is coded in Fortran90 with OpenACC directives for running on GPU. • TensorFlow: machine learning applications using the TensorFlow library. • LDC: simulation pipeline for scientific challenges of the LISA gravitational wave detector  11. The application is parallelized with MPI and used the PyMultiNest library for Bayesian analysis. • Geant4: simulation for direct Dark-Matter detection experiments (Xenon & DarkSide). The pilot applications have been containerized in the Singularity container solution (see Section. 2. 1. 1). We will explain this choice in the next Section.
In the context of the ComputeOps project, we have studied the Docker solution for research in the HPC domain (see also [1]). The Docker's paradigm is based on the representation of a container as a lightweight VM that should host a single service. But this idea of containers as miniature VMs is a wrong approach for the HPC community. Indeed, micro-services can not be used on computing clusters due to security constraints or working methods different from the typical Docker use case. For example, on computing clusters and particularly on supercomputers, the container permission has to be set in the unprivileged mode similar to the user's home on the computing infrastructure. Moreover, software solutions should be ready to deploy on existing infrastructure or should be deployed easily without interfering with existing systems.
The software solutions must take advantage of the hardware characteristics. Finally, the Docker container format is not easily transportable and shareable: scientists are looking for simple solutions to share, publish and ensure the reproducibility of codes and calculations. For all these reasons, Docker is not the optimal solution for executing scientific applications in an HPC environment. Fortunately, there are other solutions at this time that take advantage of the benefits of containerization, while adapting to the scientific environment. The ComputeOps team has chosen to focus on four container solutions that are restricting user permissions, fully open source and free. We are presenting them in the next Sections. 11 LISA: https://www. elisascience. org/  12  The Docker company has started to provide an innovative container solution in 2005.
Singularity Singularity 14  is an emerging container solution with an active community. The advantages of this solution are: • Compatibility with Docker: a Docker image can be used to create a Singularity image or can be directly used from the Docker Hub to be run by Singularity; • Security: unprivileged mode; • I/O: transparency allowing a compatibility with MPI processes and X11 graphical export; • Scheduler: native integration with schedulers. Singularity images can be submitted and executed as a job on a computing cluster; • GPU: easy GPU integration in containers; • Mobility of computing: ability to define, create and maintain a workflow and be confident that the workflow can be executed on different hosts, operating systems (as long as it is Linux) and service providers; • Single filesystem: Singularity containers use a single file which is the complete representation of all the files within the container.
uDocker uDocker  16  is a basic user tool to execute simple Docker containers in user space without requiring root privileges. The solution enables to pull and run Docker containers by nonprivileged users in Linux systems where Docker is not available. It can be used in Linux batch systems and interactive clusters that are managed by other entities such as grid infrastructures or externally managed batch or interactive systems. uDocker "executes" the containers by simply providing a chroot like environment over the extracted container. The current implementation supports different methods to mimic chroot enabling execution of containers without requiring privileges under a chroot like environment. uDocker is a simple tool written in Python. The solution has a minimal set of dependencies so it can be executed in a wide range of Linux systems.
Singularity Hub The Singularity private Hub for research 18 allows to manage Singularity images as shown in figure  2. This marketplace for Singularity images is working with (see also Sect. 2. 1. 1): • an authentification mechanism based on a GitLab/GitHub account; • collections of images for specific projects; 16 uDocker: https://www. indigo-datacloud. eu/userspace-container-support 17 CharlieCloud: https://hpc. github. io/charliecloud/ 18 ComputeOps Singularity Hub: https://sregistry. in2p3. fr • manageable workflows; • the ability for users to rate available containers and view recipe sources.
A Comprehensive Software Archive Network In the continuity of the ComputeOps collection, another initiative has been started. Based on the model of the Comprehensive Archive Network like CRAN for R, CPAN for Perl or CTAN for Tex, a Comprehensive Software Archive Network (CSAN) based on container solutions has been initiated. This network of experts will provide pre-packaged versions of scientific tools that are simple to install and simple to use validated by a peer-review process. The pre-packaged tools will be compliant with best practices in terms of security and HPC compliancy (CPU, RAM, and network optimized). Therefore, CSAN should be considered as a trusted third party which allows scientists to focus on their science and not on the tricky software installation process on their laptop or an exascale HPC cluster.
CI with Singularity In order to deliver continuously Singularity images on distributed infrastructures, the team has provided a CI/CD workflow based on GitLab-CI and Singularity components. The workflow, schematized in Figure  3 , has three stages: • Commit: the code hosted on the GitLab-CI starts a pipeline on commit. • Singularity-in-Docker: the next pipeline step automatically builds Singularity images and publishes/updates images on hubs. By using a pre-packaged Docker image with Singularity and SRegistry client, the pipeline builds an image and stores it in GitLab as an artifact. In order to authenticate on the Singularity Hub, the user token is stored in the environment variable settings; • Deploy in production: on computing clusters, the Singularity solution is often available. Automatically build images can be pulled from the Singularity Hub and executed within the scheduler.
• HAhRD 10 : HPC Algorithms for high Resolution Detectors (HAhRD) is a code developed in the context of 2018 Google Summer of Code (GSOC'18). It is a machine-learning application based on TensorFlow libraries for image reconstruction in the CMS High Granularity Calorimeter (HGCAL) optimized for running on extensible processor and GPU platforms. 5 P2IO: http://www. labex-p2io. fr/ 6 CBGP: https://www6. montpellier. inra. fr/cbgp/ 7 SMILEI: http://www. maisondelasimulation. fr/smilei/ 8 GENCI: www. genci. fr/ 9 CMS MEM: https://indico. cern. ch/event/587955/contributions/2937584/ 10 HAhRD: https://github. com/grasseau/HAhRD/wiki.
Experimental protocol The proposed FITS algorithm requires eight parameters: tabu tenure (tt), search depth of FLS (N cons ), shake frequency (δ) and shake strength (η) of FLS, update frequency (λ) of the self-adjustment penalty β in InfLS, update coefficients of β (τ , µ 1 , µ 2 ) in InfLS, and the maximum number of InfLS iterations (M ). MA requires two additional parameters: the population size (|P |) and the number of FITS iterations (Iter). To determine the appropriate  parameter settings for FITS and MA, we run the Iterated F-race (IFR) method  [3] , implemented within the IRACE package  [27] , on a selection of 20 RanReal instances with n = 240 and n = 480. The tuning budgets of FITS and MA are set to 500 runs with the time limit of 1. 0 * n seconds for each run. Table  2  shows the tested and the final values obtained in the tuning process.
For λ, τ µ 1 and µ 2 , we simply adopt the values recommended in  [9, 20]. The proposed algorithms are coded in C++, compiled with the g++ compiler using option "-O3", and executed on an Intel E5-2670 processor (2. 8GHz) with 2GB RAM running under Linux. For time scaling purposes, the execution time of the DIMACS machine benchmark 3  on our system is 0. 19s for graph r300. 5, 1. 17s for graph r400. 5 and 4. 54s for graph r500. 5.
Acknowledgments We are grateful to the reviewers for their valuable comments which helped us to improve the paper. We thank the authors of [7,24] for kindly sharing with us their source codes that enabled fair comparisons with the proposed algorithms. This work is partially supported by the  National Natural Science Foundation Program of China  [Grant No. 71401059 ,  71771099 ,  71810107003 ,  71620107002 ,  71531009 ] and the  Huazhong University of Science and Technology  ( 5001300001 ).
Participants and Procedures To examine employees' usage of enterprise social media and the moderating effect of their private social media experience, this study used an extensive online survey via Prolific, an online platform, where we initially pre-screened participants with pre-screening questions to identify subjects that fulfill our criteria such as being currently employed and using an enterprise social media. Online quantitative self-report questionnaires were used to collect the data from the participants of an online platform. In addition to the questions for social gratification, process gratification, organizational factors, public social media usage, and enterprise social media usage, the questionnaire also collected demographic information, including gender, age, and business demographics such as organizational size, industry, country of location.
Therefore, the first contribution of this study is the introduction of UGT as the theoretical perspective for enterprise social media context and presenting that it is empirically applicable in this context. The second theoretical contribution is the insight that can be drawn from an empirical study. We empirically test the UGT -derived model using data collected through an online survey. However, as previously stated the literature reviews on employee use of social media presented that majority of prior studies focusing on motives of employees are rather conceptual and presents a lack of support from empirical insights  (Baxter & Connolly, 2014; El Ouirdi et al. , 2015). Hence, prior research could not measure the effectiveness of motives on ESM usage. Limited empirical studies on this issue can be related to the novelty of the subject and limited data availability.
Element 4 consists in inferring, from the comparison between simulation model calculations and experimental values, the information related to model input uncertainties. Finally, the validation performed in Element 5 is based on the propagation of all input uncertainties (integrating the quantified model input uncertainties obtained in Element 4) through the simulation model. It also exploits the experimental database identified in Element 2. This last element is interacting with Element 4 (depicted by the two-sided arrow on Figure  1 ) and might be used in a iteration process with Elements 2 to 4 (as indicated by the blue arrow) in case of non-acceptable validation results. For efficient applications, each element is further split in different steps that are summarized in the following sections.
Element 2 -development and assessment of the experimental database The objective of Element 2 is the construction of an adequate experimental database for the problem specified in Element 1. The construction of the experimental database relies on an efficient selection procedure of suitable experiments and associated tests from a large available database that can come from the test matrices used for thermal-hydraulic codes verification and validation. In order to answer these issues, the three following steps (4-6) are identified in the SAPIUM approach (Figure  3 ). The experiments in nuclear thermal-hydraulics are usually split into several categories: basic tests, Separate-Effect Tests (SETs), Combined Effect Tests (CETs), and Integral-Effect Tests (IETs). SETs deal usually with one phenomenon whereas IETs are designed to investigate the overall system behaviors and the related phenomena and processes.
Combined Effect Tests (CETs) are also identified with several interacted phenomena. These tests usually represent several components of a reactor but not the whole system, as the IETs. It may have a lower capability to give information on models than SETs and a lower capability to simulate all system effects but it may address coupled (combined) phenomena in a prototypical geometry  (Mascari et al. , 2015). One possible strategy is to perform the quantification of the input uncertainty of physical models independently from the reactor transient scenario,. However, such strategy is practically impossible to address all possible situations with a unique set of model uncertainties without being systematically overconservative. In practice, a scenario-dependent experimental database should be built according to the important phenomena from a PIRT, as suggested in Element 1.
It has to be specified at the very beginning how detailed the subdivision of the experimental data base is necessary: parts of transient, different geometry or locations in the facility, presence of specific phenomena. It has to be checked if there are enough experimental data and if variations in the code of each uncertain parameter can be easily realized. In order to help at selecting an experiment, a proposal of the standardized description of a test is given in the SAPIUM guide. It provides information on the type of the test: covered phenomena, experimental conditions, instrumentation, available measurements, and so on, which can be used as criteria for the selection. Experimental uncertainties, due for example to inherent limitations of the measurement technique or space and time resolution of the measurement, are one of the criteria to retain in a database.
Step 5 -Assessment of the adequacy of the database The adequacy of the chosen experiment database must be assessed for the intended application. The adequacy of an experimental database includes two main properties that should be checked in the analysis. The first one is related to the ability of an experiment to provide relevant information for model input uncertainty quantification and validation. It is called representativeness. The second one concerns the ability of a set of experiments to fulfill the whole specifications of the problem under study e. g. cover the physical space of interest. It is referred as completeness. The CSNI Code Validation Matrix (CCVM) of SETs and IETs for LOCA application and transients in LWRs gives a part of methodologies for the assessment of representativeness of an experiment and of completeness of an experimental database  (Aksan et al.
, 1994; Annuziato et al. , 1996). The representativeness assessment first relies on the introduction of objective criteria to characterize the different tests of an experiment from the detailed description and with respect to the scenario. In the framework of model IUQ, priority for representativeness characterization should be given to: the phenomena-separable nature of the experiment, the quality of the experimental data, the agreement between experimental and case study conditions with a focus on the geometry and the Boundary and Initial Conditions, the capability of the experiment to address different simulation scales (CFD, component-scale, system scale). In practice, all the previous priorities are not always reachable. It is the case when there are only combined effect tests in the experimental database and no separated effect tests available.
This problem was investigated within PREMIUM project and the answer comes from the development and application methodologies suitable for quantification of model input uncertainties on the basis of CETs (Skorek, 2017). Once criteria have been defined, representativeness evaluation can then be handled by exploiting Multi-Criteria Decision Making (MCDM) outranking approaches (see  (Baccou et al. , 2018)  for an illustration) or Analytical Hierarchical Process (AHP)  (Saaty, 1982)  in order to objectively and automatically rank experiments. Regarding the estimation of the completeness of the experimental database, criteria for assessing the maturity level of various issues within the V&V UQ procedure for nuclear licensing have been already proposed under the terminology Predictive Maturity Indexes (PMI)  (Hemez et al.
, 2010). What emerges is that high level of maturity could contribute to prove the completeness of a database. However, since this SAPIUM element is restricted to the experimental database and not to the whole quantification process, the existing works on PMI need to be adapted. The ratio between the convex hull areas of the validation and application domains as well as the spatial distribution of the experiments within the validation domain can be relevant criteria to be taken into account in the construction of this index. Further discussions are provided in the SAPIUM report.
Step 6 -Selection of the experimental database for the model input uncertainty quantification and validation The last step of Element 2 concerns the selection of the experimental database for the model input uncertainty quantification and the validation taking into account the adequacy assessment (Element 2, step 5). A classical strategy is application of SETs for quantification of model input uncertainties and validation of quantified model input uncertainties on the basis of IETs. The CETs were used in the past rather for validation than for quantification of model input uncertainties. This was mainly due to the fact that quantification of model input uncertainties on the basis of CETs, when several phenomena occurs simultaneously and several models input uncertainties have to be quantified in the same procedure, is a difficult task.
Development of simulation model for all the tests of the experimental database While the computer code and the uncertainty analysis methodology are the key elements of a BEPU approach, the nodalization strategy and model options used to simulate the test facility or plant, i. e. , the simulation model, is also very important, as they connect the code with the physical system to be simulated. It is acknowledged as similar to any physical models or correlations in the code: i. e. system nodalization presents an inherent code uncertainty and like code models and correlations, quantification of nodalization-based code uncertainty is deemed to be equally important to quantify model accuracy and uncertainty. For application to nuclear reactor safety relevant issues, i. e. FSAR Chapter 15 transient analyses, two broad groups of nodalizations shall be distinguished when applying a BE code-nodalization to the analysis of nuclear reactor safety relevant issues.
The development of the process for assessing the applicability of the SM should include:  the establishment of necessary requirements for the different aspects above mentioned, and  the determination of whether or not those requirements are met by the SM for all selected experiments in the database. The goal is to develop and obtain a qualified SM considering the comparison with the hardware data, the BIC and the time trends of relevant quantities. The process should distinguish at least between three main sub-steps: 1) demonstration of the geometrical fidelity of the nodalization, 2) demonstration of the achievement of the steady state, qualitative transient analysis and 3) quantitative accuracy evaluation. Criteria for selecting relevant quantities in each of the above three sub-steps should be defined as well as the definition of the assessment applicability requirements.
If any requirement in any of the three substeps is not fulfilled, the process of assessment of applicability of the SM is not passed and the main elements of the SM should be improved. A new process should be then applied in full, i. e. all three substeps, to the modified SM. It should be also emphasized that the three-steps process for assessing the applicability of the SM apply to all tests of the experimental database used for the input uncertainty quantification and validation and if the process fails for any of the test, the SM should be modified and improved and a new process should be applied to the modified SM for all tests of the experimental database. 2. 4. Leonardi et al. , 1994; Cacuci, 2019). The SAPIUM report provides the description of different types of indicators as well as the requirements for their construction.
Element 4 -model input uncertainty quantification Exploiting the experimental database and the simulation model fully characterized in the previous sections, this fourth element is devoted to the uncertainty quantification of model input parameters, which is the so-called inverse propagation problem (IP). This has been treated in the previous PREMIUM project  (Mendizábal et al. , 2017). The four following steps (Figure  5 ) are identified in this element. 2. 5. 1. Step 10 -Aggregation of the information coming from experiments and simulation model to be used in the "inverse propagation" This step consists in aggregating the information coming from Elements 2 and 3 before performing the IUQ. In practice, it appears that different pairs of simulated/experimental value can have different degrees of importance for the intended use.