dataesr/scientific-paragraphs-categorization huggingface dataset:
This paper presents an overview of the foreseen ImageCLEF 2019 lab that will be organized as part of the Conference and Labs of the Evaluation Forum -CLEF Labs 2019. ImageCLEF is an ongoing evaluation initiative (started in 2003) that promotes the evaluation of technologies for annotation, indexing and retrieval of visual data with the aim of providing information access to large collections of images in various usage scenarios and domains. In 2019, the 17th edition of Image-CLEF will run four main tasks: (i) a Lifelog task (videos, images and other sources) about daily activities understanding, retrieval and summarization, (ii) a Medical task that groups three previous tasks (caption analysis, tuberculosis prediction, and medical visual question answering) with newer data, (iii) a new Coral task about segmenting and labeling collections of coral images for 3D modeling, and (iv) a new Security task addressing the problems of automatically identifying forged content B.
Introduction The ImageCLEF evaluation campaign was started as part of the CLEF (Cross Language Evaluation Forum) in 2003  [4, 5]. It has been held every year since then and delivered many results in the analysis and retrieval of images  [17, 15]. Medical tasks started in 2004 and have in some years been the majority of the tasks in ImageCLEF  [14]. The objectives of ImageCLEF have always been the multilingual or languageindependent analysis of visual content. A focus has often been on multimodal data sets, so combining images with structure information, free text or other information that helps in the decision making. Since 2018 ImageCLEF uses the crowdAI  17  platform to distribute the data and received the submitted results. The system allows having an online leader board and gives the possibility to keep data sets accessible beyond competition, including a continuous submission to the leader board.
Introduction In order to handle massive Monte Carlo productions on the EGI (European Grid Initiative [1]) grid for the CTA Consortium  [2] , we have developed a production setup based on the DIRAC framework  [3] [4] (CTA-DIRAC setup). The main DIRAC systems in use in our setup are: 1) the Workload Management System (WMS) for the job submission, scheduling and distribution; 2) the Data Management System (DMS) dealing with all data operations; 3) the Transformation System to automate tasks for large productions. Additionally, we rely on the DIRAC File Catalog as replica and meta-data catalog for the different datasets stored on the grid. The DIRAC hardware infrastructure is composed of 5 servers distributed among 3 computing centers: CC-IN2P3 (Centre de Calcul de l'IN2P3), PIC (Port d'Informació Científica) and DESY (Deutsches Elektronen-Synchrotron).
For the software deployment and access by grid jobs we rely on the CVMFS  [5]  system with a Stratum-0 server hosted at CC-IN2P3 and two Stratum-1 servers at CC-IN2P3 and DESY. Finally, we have developed a CTA specific software extension to DIRAC, mainly to simplify the job configuration and submission of several CTA applications. More details on the CTA-DIRAC setup can be found in  [6]. The only recent infrastructure evolution in this setup concerns the migration of the DIRAC databases hosted at CC-IN2P3 to a MariaDB/Galera cluster [7] with a master server and two slaves. From the point of view of the accessed computing resources, we have also integrated for the first time some cloud resources in the CTA-DIRAC setup. The details of this integration and the first scalability tests are presented in Section 2.
In our tests, cloud jobs are identical to standard CTA grid jobs. They execute CTA applications and interact with grid storage elements to access input data and upload their output. In order to enable cloud jobs to access CTA software in the same way as grid jobs, we have added to the contextualization process the installation of the CVMFS client. Concerning the CTA software applications, we have tested two different types of jobs: 1) MC simulation; 2) MC analysis. The first class of jobs is CPU-intensive and well adapted to be executed on clouds. Several experiments already use clouds as extra resources to absorb CPU peaks in large MC simulation campaigns. On the other hand, jobs of the second class require access to input data that are external to the cloud. The efficiency of these jobs is thus affected by the network connectivity between clouds and the storage systems hosting the data.
In our case, MC analysis jobs access CTA official datasets, distributed in 3 storage elements. On average, each job downloads about 5 GB of input data. In the first phase of our tests, we have submitted a limited number of jobs to the different cloud sites. For both categories of jobs, these functional tests have been successful. In particular, we have been able to perform all job management tasks (e. g. submission, monitoring and output retrieval) using the standard DIRAC client interfaces (command line, python API and web portal). In the second phase, we have performed preliminary scalability tests using all the resources available. LUPM and CC-IN2P3 each allocated 50 4-cores virtual machines, while the commercial cloud site allocated 250 4-cores virtual machines. Since each virtual machine can host 1 job per core, we have been able to ramp up to 200 concurrent jobs at LUPM and CC-IN2P3 sites and up to 1000 concurrent jobs on the commercial cloud.
In Figure  1 , we report the number of concurrent running jobs since January 2018 classified by type, i. e. centrally managed MC productions (simulation and analysis) and users jobs. Peaks up to 8000 concurrent jobs were observed this year, and in total more than 2. 2 million jobs were executed for a cumulative normalized CPU time of 150 million CPU hours. As shown in Figure  1 , another significant part of our computing activities this year corresponds to the reprocessing of our legacy Prod3(b) datasets with the final version of the analysis software in order to get a perfectly coherent view of the instrument performance. Data analysis is very demanding in terms of data access as shown on Figure  2. In 2018, the overall data transfer volume is around 7. 4 PB with a corresponding throughput of 200-600 MB/s.
The current total storage occupancy has reached about 3. 7 PB, distributed in 6 main storage elements. For all data operations we have relied on the DIRAC DMS and the Dirac File Catalog (DFC), that has proven good scalability and flexibility. Today, our DFC contains more than 30 million registered files, about 260 datasets characterized by a dozen meta-data items and has shown no sign of performance limitations. The next step in terms of simulations corresponds to specific productions with updated telescope and camera models in order to support the analysis of proposed hardware designs by the CTA Observatory. This is also a preliminary step toward a new large-scale production of instrument response functions with the final telescope and camera designs.
Production management To manage and automate as much as possible our large-scale productions we heavily rely on the DIRAC Transformation System (TS). The TS is a data-driven system designed to handle large productions (i. e. typically hundreds of thousands jobs) processing large datasets  [6]  through the concept of transformation. A transformation is essentially a 'recipe' to create jobs plus a 'filter' to select input data that jobs must process. The 'recipe' contains the job description (i. e. the application to be executed and its parameters) as well as plugins to define how jobs should be distributed among sites and how input files should be grouped. The 'filter' is a query on the file meta-data to select the data to be processed by the jobs. The relevant meta-data to characterize the different datasets are defined by the production manager in the DFC.
Moreover, it should allow the management of a production as a single entity rather than as a set of individual transformations. This includes the possibility to perform global actions (e. g. status monitor, start, stop, clean, delete) on all the transformations composing a production ('production transformations'). Finally, the validity of a production should be checked by the system before launching any transformation, i. e. before submitting hundreds of thousands of jobs processing large datasets as in typical productions. In order to fulfill these requirements, we have developed a data-driven Production System, where transformations are 'linked' on the basis of their input and output meta-data characterization. A production is essentially defined as a set of transformations with their associations (or links).
Architecture The architecture of the Production System is similar to that of any other DIRAC System and is composed of: 1) the Production database (DB); 2) the Production Manager Service; 3) the Production Client. The Production DB permanently stores the production descriptions and the links between the transformations. It is accessed by the Production Client through the Production Manager Service. Three utilities accomplish specific tasks and interact with the TS and the DFC: 1) ProdValidator; 2) ProdTransManager; 3) StateMachine. The typical behavior of the PS is schematized in Figure  3. First, the user provides a production description through the Production Client. Then, the ProdValidator utility checks the description validity by verifying the links between the different parent-child production steps.
This utility also interacts with the DFC to ensure that the meta-data used in the Input/OutputMetaQueries are well defined. If the description is validated, the corresponding production is inserted into the Production DB, otherwise an error is returned. This mechanism prevents human errors that may occur when the user has to manually create several transformations composing a production. Once the production is created, the user actually activates it using the Production Client, thus triggering the creation of the corresponding transformations by the ProdTransManager utility. The main actions on productions that are supported by the Production Client are: start, stop, clean and delete. The ProdTransManager utility manages all the interactions with the TS to perform the corresponding action on the production transformations.
So far, no significant issue of flexibility or scalability has arisen with any of the DIRAC components that we use. The plan is hence to propose the current DIRAC setup as a prototype for the official CTA Computing Resource Management System, with the exception of the data management part in the case another solution is proposed. With the Production System almost ready, a major piece still missing in our prototype is a specific system to better handle failed jobs and/or missing data. Indeed, so far, we have run only simulations for which a missing job or data file is not an issue, but that is clearly not acceptable when processing real data.
But clearly, deciding whether a cost functional encodes competing goals or whether it penalizes sufficiently strong unstable behavior is not easy and requires a good knowledge in both the physical background and the mathematics of optimal control. Optimal control is not an auto pilot, but is capable to leverage considerably the tokamak physicists intuition. To illustrate the power of the proposed optimal control approach to scenario design we developed an extension of the MATLAB/Octave library FEEQS. M. This library is based on the methods for axisymmetric free boundary plasma equilibria that where described in  [3]  and  [14]  and utilizes in large parts vectorization. Therefore, the running time is comparable to C/C++ implementations. FEEQS. M is publicly available 1 and a forthcoming release will contain the methods introduced in this work.
However, the DiRICH uses a similar system already so that switching to SODANET can be achieved by adapting the firmware and does not require adding new functionality. Another important requirement imposed by the PANDA DAQ architecture is the data reduction in the FEE by feature extraction and zero suppression. The Barrel DIRC, however, does not require zero suppression since it has a clear signal characteristic due to the MCP PMT properties (see section 5. 2. 3). Furthermore, data reduction is already implemented through the TOT implementation. Processing of the recorded hits for the online event reconstruction requires the appli cation of walk correction and time offset parameters that are stored in a calibration database which is part of the DAQ system  [1]. Subsequently the pattern recognition and PID can be performed.
Muons can be identified by the muon chambers and provide a clean source of β=1 0 particles. Decays from pair production of ff, LL or K K S 0 can be used to obtain, after a few S weeks of data taking, clean samples of pions, kaons and protons according to the decays: + -+ - p p  ff  K K K K + - p p  L  p p p L p 0 0 + -+ - p p  K K  p p p p. S S The geometric reconstruction is then used to determine the Cherenkov angle per photon and for each track and sensor pixel. Any deviation of the measured Cherenkov angle in each of the calibration samples from the expected Cherenkov angle is then used to build a correction function or multi-dimensional LUT in the configuration database to remove the effect of residual misalignments on the Barrel DIRC performance. This is similar to the procedure used by the BaBar DIRC counter, where a 10% improvement of the Cherenkov angle resolution was achieved by using a per-photon correction of the Cherenkov angle, calculated from a muon calibration sample  [106].
The QA measurements will be performed in parallel with the MCP-PMT fabrication and the position dependent parameters of each MCP-PMT will be stored in a database to be included in the detector simulations. 5. 6. 6. QA for the FEE. An important aspect of testing the FEE is the proper communication with the DCS, which is essential for any further checks. The assembled units will be characterized using analog signals comparable to signals from single photons. These signals can be supplied by a fast signal generator or an attached MCP-PMT illuminated by a fast laser pulser. This test allows for establishing noise levels present in the FEE, which have an adverse impact on the detection efficiency, and detecting faulty channels either 'hot' or 'cold'. Depending on these results individual cards or the entire unit can be accepted for installation.
1 mrad) is approximately equivalent to the pion/kaon separation at 3. 5 GeV/c (8. 5 mrad), the 3s. d. separation performance goal of the Barrel DIRC designs. For systematic studies data was taken with beam momenta between 2 GeV/c and 10 GeV/c. The timing calibration was provided by two laser pulsers: a PiLas PiL040SM  [72]  with 405 nm wavelength and a trigger jitter of 27 ps and a PicoQuant PDL 800-D [113] with a wavelength of 660 nm and a trigger jitter of 80 ps. The laser pulsers were coupled into optical fibers, which were routed into the dark box covering the bar/plate and connected to an opal glass diffuser to illuminate the entire MCP-PMT plane. Laser calibration runs were performed daily and after each configuration change. 6. 2. 1. Simulation of the prototype. The simulation of the prototype was an important element of the 2015 beam tests, both during the preparation phase, when it was used to determine the optimum layout of the MCP-PMTs on the focal plane and the proper location of the laser pulser fiber for calibration, and for the data analysis, to create the LUT for the geometrical reconstruction.
The exact value of the delay varies for each channel and, therefore, has to be calibrated using the internal TRB3 pulser. Figure  92  shows the leading edge time resolution for channel 640 for data taken with the PicoQuant laser pulser. The two histograms and corresponding fits to the data show the results before and after a time walk correction using the TOT measurement, demonstrating the significant improvement from the TOT information. Pixel-to-pixel time offsets due to differences in cable lengths and internal delays on the readout cards were corrected using data recorded with the PiLas and PicoQuant laser pulser. For each pixel the photon arrival time spectrum in laser data was fitted and the mean values stored in a database. These time constants were determined for each prototype configuration and subtracted from the leading time values to align all pixels in time space.
The resulting proton-pion log-likelihood difference distributions are shown in figure 105 for the beam data taken at 7 GeV/c and 25°polar angle with the narrow bar and the 3-layer spherical lens. The separation power determined from the Gaussian fits is 3. 6 s. d. The results of applying the time-based imaging reconstruction to two sets of data, polar angle scans with 5 and 7 GeV/c momentum, are summarized in figure 106. The separation power from the proton-pion log-likelihood difference distributions for proton-tagged and pion-tagged beam events is shown as a function of the polar angle for the narrow bar and the 3-layer spherical lens. The value of the separation power is proportional to the number of detected photons. Therefore, the distributions roughly follow the typical shape of the photon yield in the Barrel DIRC.
Acknowledgments This work was supported by the  Bundesministerium für Bildung und Forschung (BMBF) ,  HGS-HIRe ,  HIC for FAIR , the  European Community FP6 FAIR Design Study: DIRAC secondary-Beams , contract number  515873 , the  European Community FP7  Integrated Infrastructure Initiative:  Hadron Physics2 , contract number  227431 , and by the  EIC detector R&D  ( eRD14 ) fund, managed by  Brookhaven National Lab. We thank  GSI  and  CERN  staff for the opportunity to use the beam facilities and for their on-site support.
The fluid-dynamic calculations are coupled with ArcelorMittal thermodynamic software CEQCSI to get the evolution of the local concentration of dissolved species and non-metallic inclusions assuming local thermodynamic equilibrium. Industrial trials have been performed at one of ArcelorMittal's facilities with the aim of obtaining data to validate the model. Samples of steel were taken before, during, and after the Ca injection treatment. The total Ca content and the inclusion populations in the steel samples can be compared against the results given by the model, as well as the measured and calculated Ca yield.
For the calculation of inclusion modification, the CFD calculations are coupled with thermodynamic calculations performed with the dedicated software CEQCSI, which allows us to estimate the content of calcium-aluminates, spinels and sulfide type inclusions. Hence, one of the objectives of this study is to evaluate qualitatively the extent of the effect of Ca evaporation on the bath stirring by means of fluiddynamics simulations. The second objective is to gain insight into the process of inclusion modification due to calcium treatment. This numerical work is then an original one since calcium mass transfer is taken into account at the bubble scale, the thermodynamic equilibrium is calculated at each location into the ladle and matter transport is simulated at the scale of the industrial ladle.
Methods A fluid-dynamic model within the framework of the CFD code Ansys Fluent V17. 1 was developed in order to simulate the two-phase gas-liquid flow inside a steel ladle using a Euler-Euler approach. The model has previously been described and more detailed information is available in references  [15, 16]. The CFD calculations are coupled with the thermodynamic software CEQCSI (Chemical EQuilibrium Calculation for the Steel Industry) developed at ArcelorMittal Research in order to estimate the nature of the non-metallic inclusions in the steel as a function of the local steel composition.
Coupling of CFD and thermodynamic calculations The approach for coupling CFD and thermodynamic calculations is similar to that presented in a previous publication  [22] : Fluent computes the transport of all dissolved elements and non-metallic inclusions in the liquid steel. Once computation is complete, the data necessary to perform thermodynamic calculations with CEQCSI are transferred, i. e. for each finite volume cell, the contents of dissolved elements and non-metallic inclusions, temperature, pressure. The new distribution of species for each cell is calculated by CEQCSI and transferred back to Fluent, after which the fluid flow calculation is resumed. The coupling between CEQCSI and Fluent is consequently a weak coupling, and is handled through a set of Fluent UDFs. Efforts were pursued to reduce the calculation time of both Fluent and CEQCSI by using parallel computation.
Procedures CAE Vimedix high-fidelity simulator was used for the workshop. This simulator facilitates engaging and intuitive learning in cardiac, pulmonary, abdominal, and OBGYN US-all in 1 common platform. With its state-of-the-art manikin-based system and innovative software tools, CAE Vimedix accelerates the development of essential psychomotor and cognitive skills for ultrasound probe handling, image interpretation, diagnoses, and clinical decision making (CAE Healthcare, Corp, 2019). The workshop was divided into 4 modules. All modules started with a short didactic presentation of the theoretical basis to ultrasound relating to that specific module (10 min). The first module contained adult cardiology scenarios (pulmonary stenosis, cardiac tamponade, heart failure, and aortic regurgitation).
Analysis Data collected from the evaluations were entered, coded, and analyzed via the Statistical Package for Social Sciences version 24 (IBM Corp). Descriptive analyses were performed using the number and percentage for categorical variables or mean and SD for continuous ones. To avoid redundancy, the 5-point Likert scale was collapsed into 3 points: strongly agree and agree were combined under "agree," and similarly, strongly disagree and disagree were combined under "disagree;" therefore, analyses were performed on the scale agree-neither agree nor disagree-disagree.
The collapse of Terminal 2E Roissy at Charles de Gaulle Airport that failed eleven months after its inauguration in 2004 and left four casualties is investigated in this paper by performing deterministic and reliability analyses using the finite element software Ansys. The aim of this study is to assess the accuracy of the terminal design by comparing the calculated reinforcement ratio required with the existing ratio and to evaluate the reliability of Terminal 2E to know if the collapse could be predicted during the design phase. Reliability analysis is performed using a combination of Response Surface Method (RSM) and Monte Carlo Simulation (MCS) and taking into account the nonlinear properties of material and the complexity of geometry to investigate the nonlinear behavior of the structure in order to reduce computational costs and obtain reliable results.
The Committee also commented on the hasty construction way, in particular, the fact that the project construction phase was delayed one month due to technical problems failing to respect the normal construction rules without genuine monitoring of the technical provided options  [11]. Raphael et al. [9]  studied the terminal using the finite element software ST1 to examine the real reasons of its failure. They proved that an inadequate modeling was carried out by the design office and that the long term concrete creep caused excessive unpredicted deformations that resulted in excessive forces in the struts that led to shear punching in the shell. Furthermore, the reliability assessment performed in terms of the short-term creep deflection by coupling ST1 and Phimeca (reliability analysis software) showed that the terminal presented deficiencies and highlighted the importance of reliability assessment taking into account the long-term strains of materials to prevent such an incident.