dataesr/scientific-paragraphs-categorization huggingface dataset:
MicrOmega operation plan As the operations on Ryugu were supposed to last about 12-15 h with very limited real time feedback, the entire automated sequence of MASCOT had been defined, tested and loaded on-board MASCOT. As for all instruments, only highly limited possibility to change the acquisitions parameters during the operations were anticipated. MASCOT operational sequence was controlled by an automaton, with triggers determined by either timeouts or sensors outputs, e. g. day/night cycle  (Ho et al. , this issue). Communication to the mother spacecraft, including data transfer, was only possible during Ryugu's day, since the mother spacecraft remained eclipsed during MASCOT local nights. Since the uncertainties on the thermal environment of MASCOT and thus of MicrOmega were high, it was chosen to acquire in a row two hyperspectral image-cubes of 320 monochromatic images with 2 different integration times, 5 and 15 ms (referred to as double acquisition hereafter).
Overview MASCOT separation occurred on October 3rd , 2018. 6 min later, MASCOT reached the surface. After several bounces, MASCOT went at rest. The first data download indicated that the on board system  (Ho et al. , 2017)  to turn MASCOT instruments toward the surface had failed and that MicrOmega as well as MASCam and MARA were facing the sky  (Jaumann et al. , 2019). Suspecting that a new up-righting would not be necessarily efficient, a relocation was decided, and commanded to be operated as soon as possible, i. e. the next local morning. Since all acquisitions sequences were already planned, the first two MicrOmega observations (during the first day and during the first night) were performed with MicrOmega facing the sky. The next local morning (2nd day), the relocation was indeed performed and this time MASCOT could be successfully pointed with MicrOmega window towards the surface.
The absence of regolith on C-type asteroids is amongst the critical outcomes of both the Hayabusa2 and Osiris-Rex missions: the penalty however for MicrOmega is major! Would MicrOmega front window be in contact with, or at millimetres distance from Ryugu surface, its structure and heterogeneous composition, down its 25 μm spatial sampling, would likely have been straightforwardly characterized. The possibility that MicrOmega window has collected some Ryugu grains during bouncing is however still opened, and requires more investigation to be performed. The profound frustration could be rapidly compensated, as a similar MicrOmega instrument is now implemented within the Hayabusa2 Curation Facility at the Extraterrestrial Samples Curation Center of JAXA (Japan Aerospace Exploration Agency), at ISAS (Institute of Space and Astronautical Science) in Sagamihara.
However, despite the potential benefits offered by the exploitation of Big Data, its usage is still at an early stage in many manufacturing companies  [3]. Centro Ricerche FIAT (CRF) is one of the main private research centres in Italy and represents Fiat Chrysler Automobiles (FCA) in European and national collaborative research projects. In the context of the European Horizon 2020 I-BiDaaS project  [4] , CRF identified two use cases, in which complex datasets are retrieved from real processes. By exploiting Big Data analytics in these two cases, CRF aims to improve the process and product quality in a much more agile way through the collaborative effort of self-organizing and cross functional teams, reducing costs due to further processing and predicting faults and unnecessary actions. This requires solutions that will allow manufacturing experts to interact with Big Data in order to understand how to easily utilize important information often hidden in raw data.
Requirements for Big Data in the manufacturing sector Alignment between business strategy and Big Data solutions is a critical factor for achieving value through Big Data  [6]. Manufacturers must understand how the adoption of Big Data technologies is related to their business objectives in order to identify the right datasets and increase the value of the analytics results. Therefore tailoring Big Data requirements to the business needs is the second-best practice  (2)  reported in this Chapter. In more detail, the I-BiDaaS methodology for eliciting CRF requirements draws on work in the area of early Requirements Engineering (RE), which considers the interplay between business intentions and system functionality  [7]   [8]. In particular, the requirements elicitation followed a (mostly) top-down approach whereby business goals reflecting the company's vision were progressively refined in order to identify the user requirements of specific stakeholder groups (i.
Although it provides only an excerpt of the elicited CRF requirements, it demonstrates the application of the I-BiDaaS way-of-working in the CRF use cases. MES and SCADA sensor data information will be combined and proceed to realtime re-planning (Big Data analytics provider requirement) R10 Line Operators will only visualise the results (data consumer requirement) R11 Data Scientist will customize and then analyse data (data consumer requirement) R12 Process manager will collaborate with the data scientist to decide on the action to actuate as a consequence of the analysis (data consumer requirement) System Requirements R13 The system should enable aggregation of both attribute level and transaction level data coming from a variety of internal data sources and in multiple formats (FR) R14 The system should support multilevel access control at resource and application level (NFR) R15 The system should enable near real-time re-planning (NFR) In more detail, the strategic CRF business goal 'To improve and optimise business processes and operations' (R1), was refined into a number of more operational business goals that need to be satisfied through Big Data analytics (e.
Such KPIs have already been defined at the business level during requirements elicitation (described in Section 2). However, they need to be further elaborated so that they can be mapped onto specific indicators at the Big Data solution level. This ensures that the experiments consider both business and technical requirements, whilst maintaining traceability among business and application performance. The definition of each experiment also involved the specification of the experiment's workload in terms of the use case datasets and type of analysis envisaged, as well as the definition of the experimental subjects that will be involved in the experiment, as reported in the following Sections 3. 1 and 3. 2.
Production Process of Aluminium die-casting The 'Production Process of Aluminium die-casting' use case generates complex datasets from the production process of the engine blocks. During the die-casting process, molten aluminium is injected into a die cavity, mounted in a machine, in which it solidifies quickly. In this case, we have a large number of interconnected process parameters that influence the flow behaviour of molten metal inside the die cavity, and consequently, the productivity and the quality. The fourth-best practice (4) is to identify the type of data generated. Data collected from several sources can be disorganized and in different formats and data may not be exploited. In this use case, the data provided for the analyses consist of a collection of casting process parameters, such as piston speed in the first and second phase, intensification pressures and others.
In addition to the process data, CRF also provided a large dataset of thermal images of the engine block casting process, under a hypothesis that there is a correlation among process data, thermal data and the outcome of the process. For the mentioned complexity of the process, it is important to not only carefully design parameters and temperatures but also to control them because they have a direct impact on the quality of the casting. An excerpt of the structure of the dataset is reported in the table below with some of the key parameters identified for the detection of the quality level: Analysis of the above dataset aims to predict whether an engine block will be produced correctly during the casting process in order to avoid further processing and scraps, which would lead to financial savings for the manufacturers.
Maintenance and Monitoring of production assets For the 'Maintenance and monitoring of production assets' use case, data have been retrieved from sensors mounted on several machines (e. g. , linear stages, robots, elevators) along the production line of vehicles. We focused on welding lines in which robots are used to assembly vehicles' components and flexibility is required for the continual changes of the types of components and vehicles. A data server gathers sensor data, which categorised into two different datasets, namely SCADA and MES. The SCADA dataset contains production, process and control parameters of the daily vehicle production and is structured as follows: There are over 100 sensors and each one is identified by a specific number (id). The other columns report on the value of the specific sensor, the unit of measurement and the timestamp.
The MES dataset contains specific data associated with the type of vehicle being produced and is structured as follows: When OP020. Passo  [20]  changes from 0 to 1, a new vehicle enters into the area provided with sensors and modello_op_020 indicates the model of the vehicle being processed. Analysis of this data aims to the prediction of unnecessary actions and the improvement of the efficiency of manufacturing plants by reducing production losses. Once again, an experiment has been defined in order to test the efficiency of the I-BiDaaS solution in this context. The key points of the 'Maintenance and monitoring of production assets' experiment are shown in Table  6. In particular, data was analysed to obtain thresholds for anomalous measurements for all sensors and to build a foundational database with the history of anomalies.
I-BiDaaS solutions for the defined use cases The final best practice  (5)  reported in the following Sections relates to the development of a solution that satisfies Big Data requirements of specific use cases by mapping the identified functional and non-functional concerns into a concrete software architecture  [12]. In particular, the general requirements reported in Section 2 were further clarified, taking into consideration the specific context of each use case (described in Section 3), resulting in customised solutions per use case described in the following Sections 4. 1 and 4. 2. For both use cases, data gathered from the production lines are sent to CRF, where they are manipulated and masked. After the anonymization, data are sent to the I-BiDaaS Platform, hosted in a Virtual Machine.
Architecture The architecture of this use case can be seen in Figure  2. The architecture consists of several well-defined components. The Universal Messaging component is used for communication with most of the other components. To start with describing the data flow for this use case, we first consider the dataset. Data is transferred from CRF's internal server to the I-BiDaaS platform server. Therein, the data is pre-processed and cleaned -this step is important as the data needs to be prepared for model training and inference tasks. Then, the data is given to the Machine Learning algorithm from the I-BiDaaS pool of ML algorithms. In this use case, the model is a complex neural network implemented in PyTorch  [13]  and trained jointly from thermal images and sensor datasets. The Machine Learning component outputs two results: training metrics/results for visualization purposes -used in the Advanced Data Visualization component, and the trained model used for inference.
Data analytics In this section, we describe in more detail the data analytics solution that corresponds to the four respective modules in Figure  2  (Data pre-processing, PyTorch neural network model, Trained model, and Training results) and that analyzes the thermal images and the sensors datasets. Under the hypothesis that there is a correlation among sensor data, thermal data and the outcome of the process, a further task is to classify combined image and sensor data inputs to see whether the cast engine blocks are without any production faults. Formally, data analytics here corresponds to an M-ary supervised classification task. As the dataset involves image classification, we utilize for this task Deep Convolutional Neural Networks  [15]. The data is first pre-processed and normalized for training.
Results The models described in Subsection 4. 1. 2 were trained on both the original and the newly balanced datasets. Both models converge fully and quickly on the training datasets leading us to believe our architecture choice was correct. We favour the model trained on the balanced dataset as it learns to recognize faulty engine blocks much better than the model trained on the imbalanced dataset, even though the overall accuracy is lower -simply because we have less faultless engines. In Figure  6    When we investigate results per class, it is very clear that the balancing of the dataset is needed for the model to be able to recognize faulty samples better. This can be seen in Figure  7 , especially in the case of class 2 and 3 in which are the most important classes for fault detection.
The correlation between the real parameters and the synthesized parameters was further refined after reiteration of the data analysis. For the initial evaluation of the synthetic data, we performed empirical and analytical validations. The empirical technique consisted of delivering these data to the expert production technicians, which were not able to indicate any difference with the actual production data, as there was no distinguishing factor for them. The second analytical technique was carried out by the CRF research team. They used the K-Means algorithm as their desired technique. Further evaluation was carried out by IBM while striving to perform a qualitative generic evaluation process for the real data compared with the fabricated data. This evaluation was concerned with methods to judge whether the distributions of the fabricated data and the original data were comparable, what is commonly referred to in the literature as the general utility of the datasets.
In addition to the general utility, IBM also considered the specific utility, i. e. , the similarity between the synthetic data and the original data. The propensity mean-squared-error (pMSE)  [19]  was used as a general measure of data utility to the specific case of synthetic data. Propensity scores represent probabilities of group memberships. If the propensity scores are well modelled, this general measure should capture relationships among the data that methods such as the empirical Cumulative Distribution Function (CDF) may miss. The method is a classification problem where the desired result is poor classification (50% error rate), giving better utility for low values of the pMSE. Randomly sampling 5000 datapoints from the real and synthetic datasets, and using a logistic regression to provide the probability for the label classification, we were able to show that the measured mean pMSE score for the 'Production Process of Aluminium die-casting' dataset is 0.
Conclusion The increasing levels of digitalization in the manufacturing sector contribute to generate a large amount of data that often contain a high value of hidden information. This is due to the complexity of real processes that require several interconnected stages to obtain finished goods. Variables and parameters are set for the operation of each digital machine and just like we assembly components, we need to pull together data generated from different sources and levels, if we want to improve the quality of processes and products. I-BiDaaS developed an integrated platform, taking into consideration how complex data can be managed and how to help manufacturers who are not sufficiently enable to analyse complex datasets, by empowering them to easily utilize and interact with Big Data technologies.
C. POTOMAC simulation results In this study, we consider d = 0. 1 mm, and the RF electric field has a frequency of 11 GHz. We sweep the RF electric field amplitude between 4. 3 and 15 kV cm -1. The material is copper as received (without any surface treatment), which TEEY was measured at the ONERA. Experimental data can be found in Ref. 19 and details on the measurements in Ref. 10. The TEEY, as a function of the impact energy of PEs, is represented in Fig. 2. The first cross-over energy, defined as the first energy for which σ = 1, is E c, 1 = 29 eV. The list of the electron emission model parameters is presented in Table  II. All electrons are emitted with the same energy of 3 eV. We take Δx = d/100 and Ne = 100. We showed in another paper  10  that, with POTOMAC and in this geometry, most energetic electrons had an energy of 300 eV.
A. Methodology In Sec. IV, we used the resonance theory to find which multipactor mode appeared at each potential. We injected Ω calculated with POTOMAC in the position equations. In this section, the theoretical multipactor threshold of the structure is calculated without using any data calculated by POTOMAC. For a period-Π multipactor with nφ fixed phases, the multipactor will appear if n φ ∏ k=1 σ k > 1. ( 11 ) E 0 is incremented from 4 to 17 kV m -1 with 121 steps, and V d is swept from 0 to 60 V with 101 steps. For a couple (E 0 , V d ), the resonant phases of the mode under study (cf. Subsection III C) are calculated. We inject these phases in Eq. (5a) to compute the TEEY of each collision and verify if (11) is fulfilled. If it is not, E 0 is incremented. Otherwise, the threshold is found, and the next potential is studied.
However, its very low threshold eases the multipactor measurements. We performed measurements on this system in collaboration with a private company; results will be published in a dedicated article. In this section, we use a slightly different electron emission model that is in 3D and takes EBEs into account. We fitted the TEEY on the same experimental data as for the first simulation; we reported the model parameters in Table  VI. We present in Fig. 12  the TEEY as a function of impact energy; for comparison, we also present the TEEY used in the previous study. Both fits are similar, except the low-energy peak due to EBEs. New TEEY curve is slightly higher than previous at high energies; we do not expect these differences to be of importance, as the majority of PEs impact walls with a low energy.
In order to avoid making subjective appraisals when analysing these factors, we have designed a Python script with a workflow to work directly with 3D models of caverns using GISs, which can be easily replicated and edited by other researchers. Application of this script in the Magdalenian caves of Atxurra, Santimamiñe and Altxerri (Northern Spain) has allowed us to compare them accurately based on their visibility features. This has shown that in some cases, there may have been prior planning to enhance the visibility of some figures. In all cases, the groups of figures are located in deep and hidden parts of the caves, usually in sectors with limited capacity to accommodate people, which would be consistent with a system of restricted communication.
Our method consists of using three-dimensional models of the caves (previously modified to reflect their condition when they were decorated), and entering them in ArcMap™ by ArcGIS® as a. wrl file, to create different raster files  (Scott & Janikas, 2010) , following a defined procedure  (Opitz & Nowlin, 2012). These are analysed using the Lines of Sight technique, obtaining frequency maps for potential observers, and target points (parts of the surface that contain rock art, or the GUs themselves). In addition, we will determine the maximum capacity for each space from which the different figures are visible, based on different levels of visibility. We have summarized this workflow in a Python script for ArcGIS® (see https:// github. com/ inaki intxa urbe/ lineof-sight-and-poten tial-audie nce-analy sis-to-cave-art), including the parameters we used in our analysis.
Exceptionally, these flat surfaces might be extended with the use of scaffolding (e. g. Delluc & Delluc, 1979b) ; however, we have not located any remains attributable to such elements in the caves studied. The script subsequently uses the average human stature during the European Late Upper Palaeolithic (c. 1. 66 m)  (Holt, 2003)  to establish a fixed position for each observation point. Although such inferences should be treated with caution, given the absence and low representativeness of anthropological remains from these chronologies (LUP), we believe that they serve to establish valid criteria, as shown by recent comparisons with ancient DNA  (Cox et al. , 2019). We then established two possibilities, depending on the height of the passages, one when the passages are greater than 1. 66 m in height (upright position), and another Fig.
F 3D model of the current state of the cave. G 3D model modified to show its original state during the Magdalenian when the passage height is between 0. 71 and 1. 66 m (corresponding to a squatting position). The script can be modified to add a third measure (e. g. reclining positions), given that other caves with Magdalenian art, such as Alkerdi 1  (Garate & Rivero, 2015) , are known to contain very narrow areas with high concentrations of figurative GUs. Once the positions of the potential observers have been obtained, a mesh is created with cells of 0. 25 × 0. 25 m, from which the OPs are extracted automatically (in the estimated position of the potential Palaeolithic observers' eyes) (Fig. 4 ). Once the OPs have been obtained, the script delimits the area of analysis creating a buffer (using the "Buffer" tool) from the GUs based on the radius of action of a selected lighting tool (see Supplementary Materials).
Frequency Values The script uses the "Construct Sight Lines" and "Intervisibility" tools to perform the LOS analyses. The first of these establishes all possible sight lines from the observers (OPs) to the targets (TPs). The second directly uses the 3D model of the cave, to determine which LOSs are obstructed by any feature in the cave (stalagmite, cavewall, column, etc. ). If there is direct contact between two points, a value of 1 will be assigned to that LOS. By contrast, if there is an obstacle between the two that prevents direct vision, it will be assigned a value of 0 (Fig. 4 ). The script will also discard any lines that exceed the maximum radius of action of the mobile lighting tools (Fig. 4 ). Using the "Select", "Summary Statistics" and "Count" tools, the script counts all possible interactions between OPs and TPs, thus determining the frequencies of each OP (how many nodes on the canvases-surfaces with rock art-are visible from that point) and each TP (from how many observation points that part of a decorated surface can be seen) (Fig.
4 ). The frequencies are used to elaborate a frequency map (using the "From points to raster" tool), with a grid of 0. 25 × 0. 25 m cells. Prior to this, the values are normalized to obtain the percentages. Thus, a value of 100% corresponds to observation points from which there is total visibility of the target points (and vice versa). At these points, there is no visual obstacle preventing sightlines to the analysed canvases (Fig. 4 ). The script also elaborates Kernel Density maps, to observe where the concentrations of highest values are located (i. e. the zones with greatest visibility range). In our case, we previously geolocated the GUs directly on the geo-referenced point cloud (using the free visor of the laser scanner) or in situ (in the cave) using a DistoX2 device  (Intxaurbe et al.