dataesr/scientific-paragraphs-categorization huggingface dataset:
Given that in the present dataset, N2 and P3 components occur respectively earlier and later than the mean RTs, this pattern fits nicely with the standard interpretation of the inter-trial adaptation effect (Gratton effect). During the baseline blocks in which congruent and incongruent trials are equally likely and not predictable, the processing of a conflicting trial (incongruent) induces a high level of internal conflict reflected in the amplitude of the N2 component. Then after the processing of this conflicting stimulus, control systems increase the level of cognitive control for the next trial to come, as evidenced by the P3 component. This trial-to-trial regulation would explain why immediately after a conflicting trial, the increase of cognitive control causes a reduction of internal conflict induced by an incongruent trial (N2) and a decrease in the behavioral Stoop effect.
Testing the results of model predictions against experimental data, Kakko et al. [6]  highlighted the need for suitable databases of model validation data as these were often difficult to obtain or not presented in a way suitable for model validation. A classic example of a model validation database is the modeller's data archive (MDA) of Hanna et al. [7]  which recognised the need to collate data in a suitable form in a way that could be accessed by model developers. Since then, some other datasets have been produced, such as the Rediphem database  [10]. The SMEDIS (Scientific Model Evaluation of Dense Gas Dispersion Models) project  [11, 12]  brought together the concept of a model evaluation protocol and specialised database. Its main aim was to provide a methodology not only for validation but also scientific review of models.
The project focussed on situations in which complex effects such as aerosols, topography and obstacles were important, as well as simple situations. Ivings et al. [2, 3]  set out a Model Evaluation Protocol for models used to predict the dispersion of vapours from Liquefied Natural Gas (LNG) installations. The protocol is based upon the SMEDIS project but is not confined to the modelling of LNG spills. One of the recommendations of the MEP by Ivings et al. [2, 3]  was that validation should be performed by running models against experiments from a validation database that was constructed for this purpose  [13].
Verification is used to ensure that a mathematical model has been correctly implemented in software i. e. the equations are correctly solved. In validation, model outputs are compared with measurements of physical parameters to demonstrate that the model captures "real world" behaviour across its intended range of applicability. Verification and validation procedures are under development in the project. A database of problems for verification of codes and models against analytical solutions and a Model Validation Database of experiments for validation of simulations covering a range of phenomena relevant to FCH safety are under construction. How changes in model parameters affect the results is evaluated in the sensitivity study. Model predictions may be sensitive to uncertainties in input data, to the level of rigour employed in modelling relevant physics and chemistry, and to the adequacy of numerical treatments.
The validation database The first version of the model evaluation database is available on the project website  [4]  and currently it includes about 30 experiments. Hydrogen safety related experiments that are available in the literature and in reports are considered for the database. An evaluation of the quality of the experiments and their suitability for the validation process is carried out in the project. All experiments are inserted by one group of experts and then evaluated by another group. In the evaluation stage the reviewers evaluate if the experiment can be used for validation (e. g. are enough information available about the geometry, the initial and boundary conditions to simulate the experiment? Are there enough experimental measurements for the purpose?), and assess the quality of the experimental procedure, facility, and the related measurements.
The experiments are grouped together according to the relevant phenomena: release and dispersion, ignition, deflagrations, detonations and DDT. Experiments with fires will be added in the next version. A brief description with the experimental set up and procedure (illustrated by images and drawings where appropriate), the objective of the experiment, the experimental data and references are included for each experiment. In Tables 1e5, the lists of experiments that have been identified as suitable for the model validation database in the first part of the project are described for each physical phenomenon. In the releases and dispersion section, several experiments are available in the database as shown in Table  1. Different relevant configurations are investigated in the selected experiments: indoors and outdoors, small enclosures and garage facilities, and vented configurations.
88 m in width, length and height respectively. Two small openings at the bottom of the front side of the room assured constant pressure conditions. Hydrogen concentration was detected by 16 sensors. NASA-6  [24]  The experiments consisted of ground spills of up to 5. 7 m 3 of liquid hydrogen (402 kg), with spill durations of approximately 35 s. Instrumented towers located downwind of the spill site gathered data on the temperature, hydrogen concentration and turbulence levels. SBEP_1  [25, 26]  A subsonic release of hydrogen in a closed vessel with height 5. 5 m, diameter 2. 2 m and volume 20 m 3. The concentrations of hydrogen are detected by 6 sensors installed at the central line of the vessel. Swain_GARAGE  [27, 28]  The experimental facility represents a full-scale garage with dimensions 6.
Release 2  [33]  A set of experiments involving horizontal high pressure hydrogen jet releases was conducted at HSL. Different release pressures and nozzle diameters were used. Table  2  e List of ignition experiments in the validation database. Ignition PRD (Pressure Relief Device)  [34, 35]  High pressure hydrogen gas was released through a T-shaped pressure relief devices. In the experiment, the tube was filled with different pressure to investigate the relation between the pressure and selfignition. i n t e r n a t i o n a l j o u r n a l o f h y d r o g e n e n e r g y 4 2 ( 2 0 1 7 ) 7 6 3 3 e7 6 4 3 Two sets of experiments of DDT are available in the database. In the first set of experiments DDT with hydrogen in straight pipes of three different diameters and with different gas concentrations are performed  [44]  while in the second set of experiments explosions in an obstructed 12 m long tube are carried out with a 15% hydrogeneair mixture.
Deflagrations HYKA A2  [36]  The experiment was performed in the HYKA A2 experimental facility. A homogeneous mixture of hydrogen (10 vol. %), steam (25 vol. %) and air was established in the vessel. The initial pressure was 1. 49 bar, and the average initial temperature was about 90. 0 C. The mixture was ignited at the bottom. Pressure and temperature were measured at different axial and radial locations. HYCOM-HYC01 HYCOM-HYC12 HYCOM-HYC14  [37]  Experiments of hydrogeneair mixture deflagrations were performed in the large scale RUT facility. Different geometry, different ignition positions in the RUT facility and different initial hydrogen concentrations were considered. Pressure data was collected in the experiment. HYCOM-MC03 HYCOM-MC12 HYCOM-MC43  [37]  Combustion experiments have been carried out in obstructed tube of 174 mm in diameter and 12.
HyIndoor_WP3 Vented 1 m 3 box was filled with 18% hydrogeneair mixture. The ignition was triggered at the centre of the wall opposite to the 50 cm Â 50 cm vent. Pressures along the vented fire were measured. Open atmosphere deflagration  [42, 43]  20 m diameter hemisphere balloon was filled with 29. 5% hydrogeneair mixture. The ignition was located at the center of the balloon and the pressures were measured. Table  4  e List of DDT experiments in the validation database.
Benchmarking activities A number of experiments were selected from the validation database to perform CFD benchmarking activities within the project. In the benchmarking activities the CFD simulations are performed following the best practice guidelines  [16]  and the procedures for validation  [17]. By comparing the simulations results with the experimental measurements, main issues are addressed e. g. the effect of the mesh quality and of the turbulence models on the results accuracy. The CFD benchmark has several purposes. It will provide an indication of the accuracy and the range of applicability of each modelling approach and it will assess the performance of each model for each kind of phenomena. The benchmarking exercise also offers the opportunity to test the stages of the HYMEP and to suggest values for the statistical performance measures.
Release and dispersion In release and dispersion, two experiments were selected by the partners for the first phase of the benchmarking activities: GAMELAN  [19]  and SBEP21  [20, 21]. The GAMELAN experimental set up  [19]  is a parallelepiped enclosure with a square base of 0. 93 m width and 1. 26 m height. The vent has a square shape with a total area of 32 400 mm 2 (180 Â 180 mm). The vent is located in the middle of the wall and 20 mm below the ceiling. Helium is injected in the enclosure through a 5 mm nozzle. The injection point is located in the middle of the floor at a height of 0. 21 m and the release rate is 180 NL/min. For the simulations the ADREA-HF CFD code has been used by NCSRD. The turbulence model is the standard k-ε including the buoyancy terms and the good performance of the k À ε model in simulating similar cases was already demonstrated by Giannissi et al.
Detonations Hemispherical Det  [45]. Detonation of 29. 05% hydrogen-air quiescent mixture in the 53 m 3 hemispherical balloon (diameter 2. 93 m). Central point ignition source. KI_RUT_hyd05  [46]  RUT facility was filled with 20% hydrogeneair mixture. Initiation of the detonation wave was accomplished by the 100 g TNT located at the corner of the RUT facility "canyon". Pressure data was collected by the pressure sensors. KI_RUT_hyd09  [46]  RUT facility was filled with 25. 5% hydrogeneair mixture. Initiation of the detonation wave was accomplished by the 100 g TNT located at the end of round tunnel. Pressure data was collected by the pressure sensors. Table  6  e List of current benchmarking activities. Release and dispersion GAMELAN  [18, 19]  JRC, NCSRD, UU SBEP_21  [20, 21]  HSL, JRC. Ignition PRD (Pressure Relief Device)  [34, 35]  UU Deflagrations HyIndoor_WP3 KIT Open atmosphere deflagration  [42, 43]  NCSRD, UU Detonations KI_RUT_hyd05  [46]  KIT KI_RUT_hyd09  [46]  KIT geometric mean bias (MG) and geometric mean variance (VG).
Given C o as the observed concentration and C p as the predicted concentrations, the statistical performance indicators are defined: FB ¼ 2 C o À C p C o þ C p NMSE ¼ À C o À C p Á 2 C o $C p MG ¼ exp 2 4 ln C o C p 3 5 VG ¼ exp " ln C o C p 2 # (1) where the over-bar stands for the average value over the entire dataset. In statistical analysis, multiple performance measures have to be considered to provide a complete and meaningful description of the situation. Advantages and disadvantages of each performance measure are partly determined by the distribution of the variable. For example, for a log normal distribution, MG and VG provide a more balanced treatment of few extremely high and extremely low values than NMSE and FB. NMSE and VG are measures of scatter and reflect both systematic and unsystematic (random) errors.
FB and MG are measures of mean bias and indicate only systematic errors which lead to always underestimate or overestimate the measured values. FB is based on a linear scale while MG is based on a logarithmic scale. Therefore MG and VG are more appropriate for dataset where the observed and predicted variables vary by many orders of magnitude. However MG and VG are strongly affected by extremely low values and they do not accept zero values. Therefore a minimum threshold has to be set and that represents the limit of detection (LOD). When the observed and predicted values are lower than the threshold, they are set equal to the LOD. FB can accept zero values but both FB and NMSE are strongly affected by few extreme values. FB range goes from À2 (extreme over-prediction) to 2 (extreme under-prediction).
The commercial code ANSYS CFX has been used in this benchmark. Simulations with the SST (Shear Stress Transport) and laminar model have been performed on an unstructured tetrahedral computational mesh and on a structured hexahedral mesh. The CFD results on the unstructured mesh are in good agreement with the experiment during the release phase but the accuracy of the numerical results decreases significantly during the diffusion phase. On the contrary, with the hexahedral grid the agreement with the experiment remains satisfactory also in the diffusion phase, providing a clear indication that the hexahedral mesh is more suitable than the tetrahedral mesh for the conditions of the selected experiment. In Fig. 3  the comparison between the experiment and the JRC simulation on the same hexahedral mesh for the concentration history is shown for a sensor at 2.
Deflagrations The experiment HyIndoor_WP3 was performed by KIT and it has been reproduced numerically with the code COM3D by KIT. The KIT facility is a chamber similar to a garage where a box with glass walls was placed and filled with 18% hydrogeneair mixture. The ignition was triggered at the centre of the wall opposite to a 0. 5 m Â 0. 5 m vent. A photo of the facility is shown in Fig. 6. Pressure transducers are located inside and outside the box. The experiment was repeated three times. For the comparisons between the experiment and the simulation, the maximum, minimum and median values of the measurements have been considered. One of the fundamental choices that CFD modellers have to make in the modelling strategy is the level of simplification of the geometrical model. Including all the details of the geometrical configuration is often not feasible because it would require a computational mesh with a very large number of nodes, producing prohibitively expensive computer run-times.
Conclusions This paper presents some intermediate results from the collaborative SUSANA project whose aim is to develop a Model Evaluation Protocol (HYMEP) for CFD models that are used in safety analyses of hydrogen and fuel cell technologies. The project arose from a recognised need for a framework to support users and developers of CFD software undertaking numerical simulations for the analysis of the safety of FCH systems. The main stages of the HYMEP are: scientific assessment, verification, validation, sensitivity study, statistical analysis according to the quantitative assessment criteria, and finally the assessment report. A verification database and a validation database are under development in the project and part of the project is a benchmarking exercise which involves the   The experiments that were selected from the validation database for the first phase of CFD benchmarking activities included (but are not limited to): Helium release in a vented small box (with a square base of 0.
e. , the fourth-order statistical moment) of the variable being studied. In the small dataset context (around ten points), a precise estimation of the kurtosis might seem to be an unrealistic goal. In another context, that of the quality control domain,  [18]  has developed narrower bounds than the Bienaymé-Chebychev ones, showing at the same time how the three-sigma rule can be justified (based on a unimodality assumption, proven for example in  [19] ). Starting with this statistical literature as a base, along with older results about unimodal and convex distributions (see  [20]  for a more recent example), several useful inequalities have been developed in  [14]. While they also focused on the range of validity of each inequality, their results were preliminary; the present paper extends that work to estimate risk prediction bounds robustly, with several applications to real radiological characterization problems.
Acknowledgments The authors wish to thank  Hervé Lamotte ,  Alexandre Le Cocguen ,  Dominique Carré  and  Ingmar Pointeau  from the  CEA Department of Nuclear Services , and  Thierry Advocat , head of the  CEA GFDM research program , for allowing the use of the H2 flow rates data from drums of radioactive waste. We also thank  Léandre Brault  and  Emmanuel Remy  for many useful comments on this paper. Finally, we are grateful to  Kevin Bleakley  for the English language corrections.
Workflow engines In the last decade, the e-Science community has developed workflow systems to help application developers access distributed infrastructures such as clusters, grids, clouds and web services. These efforts resulted in tools among which Askalon  [5] , Hyperflow  [6] , MOTEUR  [7] , Pegasus  [8, 9] , Swift  [10] , Taverna  [11] , Triana  [12] , VisTrails  [13] , WS-PGRADE  [14]  and WS-VLAM  [15]. Such workflow engines usually describe applications using a highlevel language with specific data and control flow constructs, parallelization operators, visual edition tools, links with domainspecific application repositories, provenance recording and other features. An overview of workflow system capabilities is available in  [16]. At the same time, toolboxes have been emerging in various scientific domains to facilitate the assembly of software components in consistent ''pipelines''.
In neuroimaging, our primary domain of interest, tools such as Nipype (Neuroimaging in Python, Pipelines and Interfaces  [17] ), PSOM (Pipeline System for Octave and Matlab  [18] ), PMP (Poor Man's Pipeline  [19] ), RPPL  [20] , SPM (Statistical Parametric Mapping  [21] ) and FSL (FMRIB Software Library  [22] ) provide abstractions and functions to handle the data and computing flow between processes implemented in a variety of programming languages. Such tools were interfaced to computing infrastructures, in particular clusters, to execute tasks at a high throughput. Some of these tools also support advanced features such as provenance tracking or redundancy detection across analyses to avoid re-computation. A wide array of workflows have been implemented using these pipeline systems and are now shared across neuroimaging groups world-wide, which represents a tremendous opportunity for science gateways to leverage.
Domain-specific engines nicely complement e-Science systems that are more oriented towards the exploitation of distributed computing infrastructures, in particular grids and clouds. In this paper, a workflow engine (also abbreviated engine) is a piece of software that coordinates and submits interdependent 1 http://www. shiwa-workflow. eu. 2 http://www. erflow. eu. computing tasks to an infrastructure (local server, cluster, grid or cloud) based on a workflow description (a. k. a workflow), using input data that may consist of files, database entries or simple parameter values. Although simplistic, this definition covers both e-Science workflow engines and domain-specific pipeline systems. Some workflow engines, usually from the e-Science community, may transfer data across the infrastructure, and others, usually domain-specific ones, may leave this role to external processes.
Infrastructure An infrastructure consists of the computing and storage resources involved in workflow execution, as well as the software services used to access these resources. The infrastructure can be composed of computing or file servers, databases, clusters, grids or clouds. Some workflow engines and science gateways may require specific characteristics, such as the presence of a shared file system between the computing nodes, the availability of a global task meta-scheduler, or the presence of a file catalog. In the analysis presented hereafter, such specific requirements are not discussed. Instead, we consider the infrastructure as an abstract system that can execute tasks and store data regardless of the enabling mechanisms.
Tight integration See Fig. 2 (I). The workflow engine is tightly integrated with the science gateway, which means that it is deployed on the same machine and potentially shares code, libraries and other software components with the science gateway. For instance, the workflow engine might be a portlet in a Liferay portal or a model in a Ruby on Rails application. 3 The workflow engine and the science gateway usually share a database where applications, users and other resources are stored. In this model, task and data control are both initiated from the science gateway. Interactions b and c 2 are initiated from the workflow engine, while c 1 comes from other parts of the science gateway, for instance a data management interface. As in any other model, the installation of new workflows in the science gateway (a 2 ) and infrastructure (a 1 ) is done by an administrator, for security reasons.
We focus on instantiation with the service invocation model (Fig. 2 (V)-Right) as this is the most used architecture. We call this instantiation ''Service+Service'' since both engines are integrated through service invocation. We assume that the parent and child workflow engines are distinct pieces of software that require different workflow services invoked by distinct d interactions. If this is not the case, then workflow services can be collapsed into a single one with a d interaction with itself. An example of such interaction is the use of hierarchical workflows in Pegasus  [9]. Workflow engines communicate with infrastructures using b and c 2. Science gateway transfers user data to infrastructures using c 1. Nested workflows have long been available in workflow engines, for instance in the Taverna workbench  [11].
Workflow conversion See Fig. 2 (VI). This is an abstract model instantiated with the service invocation architecture for consistency. Workflow conversion is presented here as a pattern to integrate workflow engines in a science gateway, through workflow format conversion from a native format to the science gateway format. Workflow conversion is usually an offline process that is not involved in workflow execution. A few systems have implemented workflow conversion. In the SHIWA Simulation Platform, it is implemented through the IWIR language, which provides a common language for portability across grid workflow systems  [37]  and allows conversion among n workflow languages using 2n interactions instead of n 2. Tavaxy  [36]  enables the import, merging and execution of Taverna  [11]  and Galaxy  [46]  workflows; when some workflow parts cannot be imported, workflows are run by Tavaxy as nested workflows using their native engine.
Task encapsulation Task encapsulation is used in the CBRAIN gateway  [1]  to integrate the FSL toolkit  [22]  and the PSOM workflow engine  [18]. The CBRAIN-FSL integration, shown in Fig. 5 (I), allows leveraging FSL pipelines written in low-level workflow languages (Linux executables and scripts) that submit tasks uniformly through a specific tool called fsl_sub. The science gateway is actually split in two services, the CBRAIN portal and the CBRAIN execution server deployed on a head node of the infrastructure. The mapping    of interactions b, c 1 and e to the CBRAIN-FSL interactions is straightforward. The CBRAIN-PSOM integration  [33]  is shown in Fig. 5 (II). The PSOM workflow engine adopts a pilot-job architecture  [44]  where a master coordinates workflow execution by submitting workers and establishing direct communication channels with them.
Workflow conversion with service invocation Fig. 8  shows the architecture of Tavaxy where workflows in various formats (tSCUFL, SCUFL, t2flow and JSON) can be imported. As detailed in  [36] , workflow conversion (interaction g) is implemented through an interactive authoring module where users can check and edit workflow imports, and a mapper module that performs some language substitutions. The workflow engine is a re-engineered version of the Galaxy engine that also includes some components of Taverna.