dataesr/scientific-paragraphs-categorization huggingface dataset:
One way that may demotivate repeated contributions is to make the contributed VGI available to the crowd in real-time or near real-time, enabling citizens to see what was already reported. In the post-acquisition phase, one of the most important findings was that NMAs identified the need to report or highlight the use of VGI in their updated or corrected spatial products quickly after receiving the contributions. Otherwise citizens may become demotivated and less likely to contribute again if they cannot see any tangible use or benefit from the data that they contributed. Establishment of processes and interfaces to the submission of VGI from citizens is a considerable task. A NMA must balance the requirements for robust spatial data collection with easy-touse and intuitive user interfaces that are suitable for web-based environments.
VGI collected by Geo-Wiki Geo-Wiki is a crowdsourcing platform that asks volunteers to examine satellite imagery from Google Earth and determine the land cover type in a given area as well as other related questions, e. g. size of agricultural fields, degree of visible human impact, etc. (See et al. , 2015). In addition to the original Geo-Wiki interface developed in 2009, there have been several branches that have dealt either with a specific land cover type, e. g. Biomass Geo-Wiki  (Schepaschenko et al. , 2012) , or a specific purpose, e. g. Competition Geo-Wiki. This latter branch was developed specifically to launch crowdsourcing campaigns and collect land cover data for the development of new land cover products and the validation of existing products. After running six campaigns, considerable experience was gained, which was then applied to the latest Geo-Wiki tool, called Cropland Capture  (See et al.
Conception Even though Geo-Wiki was designed to allow any volunteer to participate, in the first six Geo-Wiki campaigns the majority of volunteers were either remote sensing / land cover experts or students recruited through this network. To try to create a campaign that would appeal to a wider audience, a gamification approach was used, corresponding to the Cropland Capture game, which was designed for a mobile environment, in addition to a browser. A leader board and weekly prizes are available, to motivate the participants. Media outreach was also used as a way of reaching the widest possible audience. The information collected about the participants is split into mandatory and non-mandatory information. The data that are always collected include: account information (username and password) and e-mail.
The users are asked to provide additional data when they register for a Geo-Wiki account, which includes first name, last name, home town, country of residence and profession (where the allowable answers are: Remote Sensing/Land Cover; Higher Education; Administration; Service Sector; and Other). However, as these fields are not mandatory, some users leave them blank. Moreover, if the players downloaded the game from an app store (regardless of operating system), then registration required only email, username and password. In the cases where additional data were collected about the volunteers, whether local knowledge has any influence on quality will be analyzed, using the Home Town data collected. This analysis is still ongoing but initial results suggest that proximity to the area being classified appears to have little influence when analysed globally.
In previous Geo-Wiki competitions, since the aim was to maximize data collection over a wide geographical coverage, a small degree of redundancy was allowed (e. g. 2 to 3 classifications of the same location). In Cropland Capture, a much greater degree of redundancy was built into the game in order that each classification would have an associated frequency distribution of answers, and confidence could then be determined. Users cannot choose the location for classification during the game. Instead the game guides users to a certain location randomly, revealing only the country in which the area for interpretation is situated, as information. Unlike previous Geo-Wiki competitions, there were no controls or 'gold standard' data used during the running of the game. Instead, majority agreement was employed.
Thus, the first time a new image appeared in the game, users were correct, regardless of the answer they gave. Then as more classifications were gathered for this image, correctness was determined by whether the user agreed with the majority. If correct, users scored one point; if wrong, users lost one point. Initial images were given only to those players who had the most previous correct answers in the past, to avoid having initially wrong classifications. In terms of data accessibility to the crowd, during the time when the game was active, there was no option to see the answers or the profile of others as the game was played. This is mainly due to the goal-driven nature of the game, i. e. to collect as many points as possible through correctly classifying the images. However, as for previous Geo-Wiki competitions, the data will be openly accessible in the near future for other purposes, such as research, from www.
geo-wiki. org as Excel spreadsheets or in CSV format. With each image interpretation, which consists is answering if cropland is present, not present, or maybe present (i. e. yes, no or maybesee Figure  3 ), the following metadata are collected: an image classification number; a user identification number; the date and time of the classification; whether the answer was correct in relation to the majority; and the device used by the player, i. e. browser, tablet, smartphone and the operating system (Android or Apple). Each image classification number has an associated location, the resolution of the pixel for interpretation (in the case of satellite imagery), or a photograph identification number, which is linked back to the source, e. g. the Degree Confluence project identifier.
Acquisition / Post acquisition During the time the game was active, approximately 3,000 players played the game over a 6 month period. From these just under 40% of users had registered via the Geo-Wiki browser version while the remaining went via an app store, providing only the mandatory information about the user. Of those who did register via Geo-Wiki, around 20% left the non-mandatory information blank. Considering that the registration process is not onerous, making more of the information mandatory is one option that should be considered as the data may be of use in quality assessment. No information was specifically collected on the ease of use of the platform. Players did provide feedback about the game via email but no particular comments were received regarding the app itself. During the game users suggested that, based on user location, users should be given images in their neighboring area, which would enable the use of local knowledge.
However, it was not possible to implement this user recommendation during the running of the game but was noted as a potential consideration for future games. An analysis was undertaken by  Sturn et al. (2015)  on the efficiency of the game in collecting data, measured as the time taken by the players in classifying the images. The results showed that 97% of the classifications were completed in less than 4 seconds and 92% in less than 2. 5 seconds per image. Although the mobile versions were designed with a simple touch and swipe mechanic, the browser version, in which the keyboard is used, was actually the most efficient data collection mechanism overall, where roughly 36% of all the classifications were collected in this way. A particular type of volunteer confidence was collected during the game since players could answer 'maybe' when unsure about whether cropland was evident in the image.
CONCLUSIONS This paper presented a framework for assessing the quality of VGI, which highlights different issues that need to be considered during the conception, acquisition and postacquisition phases of VGI creation. Among others, these include making a careful match between the correct type of volunteer for a given mapping job, collecting metadata on the volunteer and the specific mapping contribution, providing suitable training and instructions prior to the commencement of the mapping, providing corrective feedback during the mapping, continuous generation, update and use of control data, active quality control measures (either by other volunteers or by experts), and easy-to-use and well-designed mapping portals or websites. Data collection of VGI by NMAs was then considered, in particular the types of data collection processes that are currently employed.
An analysis of the last Geo-Wiki tool to be developed was then analysed with respect to the proposed framework. These two examples illustrate that platforms with different aims may require very different approaches, but some common needs can be identified, such as the collection of metadata about the volunteers and the need to perform quality control, even though this can be done in very different ways according to fitness-for-purpose. We can conclude that tentative steps are being taken to address quality issues and that good practices are beginning to emerge. It is hoped that work on the topics discussed in this paper will continue to help ensure that the full potential of VGI for environmental monitoring and integration with authoritative mapping is realised.
Since some years, there is a worldwide trend to move towards ''higher-fidelity'' simulation techniques in reactor analysis. One of the main objectives of the research in this area is to enhance the prediction capability of the computations used for safety demonstration of the current LWR nuclear power plants through the dynamic 3D coupling of the codes simulating the different physics of the problem into a common multi-physics simulation scheme. In this context, the NURESAFE European project aims at delivering to the European stakeholders an advanced and reliable software capacity usable for safety analysis needs of present and future LWR reactors and developing a high level of expertise in Europe in the proper use of the most recent simulation tools including uncertainty assessment to quantify the margins toward feared phenomena occurring during an accident.
The works under this roadmap are carried out through three successive projects as shown in Fig. 0. 1. The first project, NURESIM, established the basic architecture of the platform and resulted in a first prototype of a truly integrated multi-physics simulation environment. The NURISP project was conceived as a consolidation of the platform together with an extension of the simulation capabilities towards higher-resolution both in space and time. The current NURESAFE project will achieve the validation of the NURESIM platform, deliver industry-like applications and establish the platform as a reference European tool. The NURESIM simulation platform is a set of codes covering core physics, thermal-hydraulics and fuel thermo-mechanics (Fig. 0. 2). The codes are integrated in a common environment provided by the SALOME open-source software (http://www.
salomeplatform. org/). SALOME provides a generic user-friendly interface and is designed to facilitate the coupling of computing codes in a heterogeneous distributed environment as well as to facilitate interoperation between CAD modeling and codes. The platform includes a tool for uncertainty quantification, sensitivity analysis and model calibration: the URANIE open-source software (http://sourceforge. net/projects/uranie/). URANIE is based on the ROOT software framework developed by CERN and it provides a simple mechanism for interfacing with codes or coupled codes in order to perform studies by analyzing data handled by the codes. Further details on the NURESIM platform and the projects are presented in Sections 2 and 3. The NURISP and NURESAFE projects cover a range of issues: multi-physics, thermal-hydraulics, core physics, fuel thermomechanics, uncertainties assessment and code calibration.
The SALOME platform The NURESIM platform is based upon the software simulation platform SALOME. SALOME is an open-source project (http://salome-platform. org), which implements the interoperability between a CAD modeler, meshing algorithms, visualization modules and computing codes and solvers. It mutualizes a pool of generic tools for pre-processing, post-processing and code coupling. Its supervision module (YACS, Fig. 2 ) provides functionalities for code integration, dynamic loading and execution of components on remote distributed computing systems, and supervision of the calculation. The computing codes are wrapped into a C++ class which provides a coupling interface, and afterward they are integrated in SALOME platform as CORBA components (the CORBA layer being automatically generated by the platform integration module).
This integration technique has the advantage of not requiring an access to the source of the coupled codes. Also it provides an explicit interface to the codes, which enables the coupling in an external coupling scheme, in our case a python script or a graph. This scheme is not implicit and embedded inside the source of the codes being coupled, thus it is clearer, and the debugging is much easier. The data exchange is facilitated by the adoption of a common format for numerical meshes and fields (the MED library, an open standard provided by SALOME platform). This feature is of high importance as it is the basic support for all the coupling schemes that can be implemented between different codes once they are integrated as SALOME components. The MED library also provides a complete set of interpolation algorithms, which has proven to be very useful when codes rely on different meshes.
Within the NURISP project, two neutron kinetics codes, COBAYA3  (Lozano et al. , 2008)  and DYN3D  (Grundmann and Kliem, 2004; Däubler et al. , 2013a,b) , coupled with the thermal hydraulics code FLICA4 in the NURESIM platform  (Kliem et al. , 2011)  were employed to simulate boron dilution transients. For the purpose of coupling verification, a boron dilution benchmark was defined in the NURISP project  (Kliem et al. , 2011). The couplings of COBAYA3 and DYN3D with FLICA4 were tested using these specifications. That test gave the possibility to assign differences in the obtained results to differences in the neutron kinetics methods implemented in DYN3D and COBAYA3 and assess their performance for this kind of transients. Three transients were defined in the project, involving increasing volumes of diluted water entering the core inlet, to test the adequacy of the coupling between the codes.
The boron dilution in all three test cases is enough to have a considerable power peak reaching around 14,000 MW (Slug 1), 45,000 MW (Slug 2) and 60,000 MW (Slug 3). The power peak occurs at the same time for all the codes but it can vary in width. The differences in the calculated power peaks with both the COBAYA3 FLICA and DYN3D FLICA code systems are very small, which builds confidence that the coupling was correctly implemented (Fig. 3 ). In detail the results are described in  Jimenez et al. (2015). As a general conclusion, the boron dilution comparison between the codes was highly appropriate for testing the NK TH coupling within the SALOME platform, as the results are reasonable and similar between implementations. The neutronics codes performed adequately the transients, and several improvements have been done to simulate precisely the boron dilution event.
The link between the two approaches is done by chaining the first to the second through the provision of neutron power and thermal-hydraulic conditions calculated by the global approach to the thermo-mechanical fuel rod code at the local scale. Obviously raises the questions of the interest and the validity of this chaining. To answer this question, one of the tasks of the NURESAFE project aims at coupling of three software CRONOS2/ FLICA/SCANAIR (see Fig. 4 ) via SALOME platform. In practice SCA-NAIR will replace the fuel rod module of FLICA to have more advanced models taking into account the evolution of the properties of the fuel rod (fuel and cladding) with irradiation and the coupling between thermic, mechanics and gas behavior (e. g. fragmentation of the fuel, fuel swelling, fission gases release in the gap between fuel and cladding, cladding deformation, etc.
The main features of the implemented coupling via SALOME are listed below: The single neutron kinetics and thermal hydraulic codes are integrated as components with a coupling interface. YACS graphs or Python scripts are used to link dynamic libraries containing single codes and to express the calculation routes. The data exchange is through the MED library and the MED coupling interface, providing a common format for numerical meshes and fields. The overlay of the neutronic and thermalhydraulic meshes is done making use of the INTERP interpolation tool during the data exchange. Using these features and having the different codes integrated as SALOME components with YACS interface, the coupled execution route of COBAYA3/FLICA4  (Jimenez, 2009)  has been adapted to implement a new coupling of CRONOS2/FLICA4  (Spasov et al.
Coupling schemes for SUBCHANFLOW and DYN3D One of the main advantages of the NURESIM Platform is the fact that any integrated code e. g. a thermal hydraulic one can be coupled with another solver, e. g. a neutronic solver, by adapting the coupling and execution routes without major developments. To show this flexibility, the coupling of SUBCHANFLOW, a subchannel thermal-hydraulic code, with DYN3D or COBAYA3 neutronic codes has been extended and tested within the SALOME platform  (Calleja et al. , 2012 (Calleja et al. , , 2014;; Jimenez et al. , 2013a,b). The integration of SUBCHANFLOW inside the NURESIM platform has been done as an in-kind contribution of KIT. SUBCHANFLOW and COBAYA3 were also coupled via internal memory  (Ochoa et al. , 2012). In addition, DYN3D and FLICA4 were coupled inside the NURESIM platform and successfully used to perform steady state and transient simulations of PWR cores  (Gomez et al.
, 2010). Based on this experience at KIT and taking advantages of the unique features of the NURESIM platform to easily couple codes that are already implemented in the platform, a steady state and transients coupling schemes for DYN3D and SUBCHANFLOW were developed and implemented. In this coupling approach, the spatial mapping is based on the mesh superposition principle, making use of the INTERP interpolation tool during the data exchange (see Fig. 7 ). For a steady state simulation, the dataflow in the developed iterative explicit coupling scheme is depicted in Fig. 8. Each solver  is called independently using the data provided by the other code in a sequential manner using its own numerical scheme. In this coupling approach, DYN3D starts with assumed thermal-hydraulics boundary conditions.
These convergence criteria are set by the user in the input decks of each code based on both the neutronic and thermal-hydraulics parameters. Typical convergence criteria used are 1. 0 À6 (e N ) for the k eff and total power and 1. 0 À4 (e T ) for T Dopp , T mod and q mod. The NURESIM platform offers the possibility to implement a relaxation method to speed-up the convergence of the coupled solution. In the coupling schemes presented here, no relaxation method was implemented since the coupled solution converged after 8-10 iterations. In case of off-initial conditions, the coupled codes may need around 20-30 iteration steps to converge. The coupling code DYN3D-SUBCHANFLOW was applied for the analysis of a rod ejection problem (REA) in a 3 Â 3 FA minicore problem consisting of UOX and MOX fuel assemblies and surrounded by reflector (water) (see Fig.
9 ). Control rods were located only in the central UOX-FA. This problem was derived from the NURISP benchmark problem  (Kliem, 2011)  which is based on the OECD PWR OX/UO2 core transient benchmark definition. For the REA analysis, hot zero power conditions of the minicore are considered; meaning that the core power is 1 W, the mass flow rate around 740 kg/s, the system pressure amounts 15. 4 MPa and the core inlet temperature is 560 K. Once the core is HZP critical conditions, the control rods are ejected within 0. 1 s. This HZP PWR minicore REA transient was calculated with both the COBAYA3-FLICA and the DYN3D-SUBCHANFLOW coupling schemes implemented within the NURESIM Platform. In Fig. 10 , the total power as predicted by the two code systems is shown. It can be observed that the maximal power is achieved before the control rods are fully extracted from the core.
Simulation of ROSA LSTF using ATHLET-CFX coupling Within the FP7 EU project NURISP, the GRS system code ATHLET was coupled with the commercial CFD software package ANSYS CFX. The main objective was to improve the simulation capabilities of the 1D program for flows with pronounced 3D effects like mixing and stratification, being important for particular transients and accidents like pressurized thermal shock, boron dilution or main steam line break. Main efforts were related to the implementation of explicit and semi-implicit schemes, the simulation of different test configurations as well as to the validation on the OECD/NEA Rig of Safety Assessment (ROSA) V Test 1. 1, carried out at the Japanese Large Scale Test Facility (LSTF). This experiment is challenging for any thermal-hydraulic program and even more for coupled codes, because strong buoyancy and mixing effects in natural circulation conditions have to be addressed in a proper manner  (Papukchiev et al.
Analysis and comparison of the simulation results with experimental data In the first step of the comparative analysis, the results from the performed coupled 1D-3D simulations were visualized with the help of ANSYS CFX Post software. The vertically downwards injected cold ECC water hits the bottom of the cold leg and then swashes to the left and right pipe walls. Due to its higher density, the cold water pushes the lighter hot water to the top and gradually stratifies at the bottom of the cold leg (see Fig. 14 ). The maximum temperature difference between top and bottom of the pipe in this cross-section is 12 K. Fig. 15  shows the comparison with data for the thermocouple TE1205 (rake TE3), which is situated centrally at the bottom of the cold leg A. Most of the results for the thermocouple rake TE3, which is close to the RPV inlet, are in good agreement with the experimental data and deviate within the measurement uncertainty.
However, the comparison for the TE2 rake, which is close the ECC injection nozzle showed larger deviations from the experimental data. It was found, that this is due to insufficient RANS turbulence modeling of the impinging ECC injection jet. Nevertheless, for both measurement rakes very good agreement between ANSYS CFX stand-alone and ATHLET-ANSYS CFX calculations can be observed. This result proves the consistency of the coupling methodology. Fig. 16  compares ATHLET stand-alone and coupled ATHLET-ANSYS CFX results for the average pipe cross-section temperatures in the ATHLET control volume downstream of the ANSYS CFX domain near the RPV downcomer inlet. The good agreement among experiment, ATHLET and ATHLET-ANSYS CFX demonstrates that the coupled code system successfully accomplishes the transition from spatially distributed to lumped parameter approximation schemes.