dataesr/scientific-paragraphs-categorization huggingface dataset:
A. Background flow Before the initial conditions for the hairpin simulations are discussed, a preprocessing step is carried out on the DNS database analyzed in Harikrishnan et al. 8  to obtain the mean background flow Q 2. In the DNS simulation, the governing equations of an incompressible, rotating, stratified viscous fluid are solved in the Boussinesq limit where density variations are neglected except when acted upon by gravity. The simplified set of equations are 9 @u i @t ¼ Àu j @u i @x j þ @ 2 u i @x 2 j À @p @x i þ f e i3k ðu k À Gd k1 Þ þ bd i3 ; (26a) @b @t ¼ Àu j @b @x j þ H @ 2 b @x 2 j ; (26b) @u i @x i ¼ 0: (26c) Here, u i;i2f1;2;3g are the velocity components, and b ¼ gh=h 0 is the buoyancy, where g is the gravity, and h; h 0 are the potential and reference background temperatures, respectively.
Time integration was carried out with a fourth-order Runge-Kutta algorithm. This simulation database is ideal for our study as global intermittency is simulated without any external triggers, such as low-level jets, internal gravity waves, or surface heterogeneities. 9  Further details regarding the simulation can be found in Ansorge and Mellado 9,10 and Ansorge. 11  In this paper, the hairpins are simulated in a mean background flow composed of two stably stratified cases (S_1, S_2) with different degrees of stratification and a neutrally stratified case (N). By studying the temporal evolution of vertically integrated turbulent kinetic energy (TKE), both S_1 and S_2 are classified under the very stable regime in which large patches of inactive/non-turbulent regions are visible. This can be seen from Figs.
B. Initial conditions As described in Sec. II, the first step of the numerical scheme is to set up the initial configuration of the hairpin by fixing unknown physical and numerical parameters. We inspect the DNS database to inform our choice on the selection of parameters. Three hairpin-like structures identified using the Q-criterion indicator are extracted and examined for case N, S_1, and S_2. The centerlines for the extracted structures are obtained with the blockwise skeletonization method of Fouard et al. 54  At each point on a centerline, the diameter d of the vortex core is estimated by fitting the largest sphere within the structure. Additionally, the radius of curvature R at every point of the parametrized centerline X is given by 55 R ¼ 1 j ¼ jX s j 3 ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi ffi jX s j 2 jX ss j 2 À ðX s Á X ss Þ 2 q ; (30) where X s ; X ss correspond to the first and second derivatives of the space curve along the parameterized centerline.
B. Comparison with filament simulation The hairpin-like structure tracked with MLPT thresholding is visualized in Fig. 16. Since it is clear that this structure exists in the outer layer in the range of 80 < y þ < 180, the filament simulation is also initialized at a higher wall-normal height y þ initial ¼ 125 to enable an appropriate comparison. A larger amplitude A ¼ 80 and, correspondingly, a larger initial width are also chosen. All initial conditions are listed in Table  V. With a spatial discretization of 1500 nodes, the simulation is carried out until the overlap condition (C2) is violated. Since the initial state of the hairpin structure from the DNS dataset is unknown and the structure is tracked from a later point in its lifetime, it is not possible to establish a direct comparison of the tracking results with the filament simulation.
In particular, we note the following: (1) For the initial condition R 3 , which has a relatively thinner core and stronger circulation resulting in a large self-induced velocity, the differences in inclination rate and maximum inclination are negligible for all background flow profiles. (2) For all other initial conditions, it can be seen that an increase in stratification results in a slower inclination rate and a smaller maximum inclination angle. (3) Since the effect of rotation is present in the Ekman flow, it can be seen that the hairpin filament, which is initially symmetric about z þ ¼ 0, becomes asymmetric over time, thereby tilting the vortex. As expected, the degree of tilt increases with an increase in the strength of stratification. Tracking of the Q-criterion structure in the DNS dataset shows that the asymmetry becomes stronger as the structure grows in size.
14, 15  Further probing of the DNS dataset is necessary with hairpin-like structures and their interactions, which need to be tracked in time. Our current efforts are focused in this direction. Further efforts can be directed toward studying the impact of mutual induction of neighboring hairpin filaments (where viscous effects become important) on their orientation. An extension of the M1 KK method incorporating the viscous diffusion has already been presented in Klein et al. 66  This should lead to a straightforward modification of our slender vortex filament code. Additionally, the asymptotic analysis from Sec. VI can be continued to obtain a new core constant C(t), which can be directly implemented in our slender vortex code to quantify the effect of gravity on the self-induced motion of the filament.
ACKNOWLEDGMENTS The authors would like to thank  Professor Omar M. Knio  for lending support and helpful discussions during the initial stages of the work. They would also like to thank  Dr. Cedrick Ansorge , who performed the DNS simulations of the stratified Ekman flows and provided access to the  J€ ulich Supercomputing Center , where the data are stored under the project dns2share. This research is funded by the  Deutsche Forschungsgemeinschaft (DFG)  through Grant No. CRC 1114  " Scaling Cascades in Complex Systems, " Project No. 235221301 , and Project  B07 : Self-similar  structures in turbulent flows  and the  construction of LES closures. Marie Rodal  gratefully acknowledges the support of the  Research Fund of the University of Antwerp.
This COTS requires the use of a high-level language (LabVIEW-FPGA) and the associated integrated development tools to develop the FPGA functionality. Therefore, it is necessary to ensure the required assurance that a COTS device is of sufficient quality, fit for purpose, and can be properly integrated into an investment protection control loop with the necessary level of systematic capability during the development process. This paper describes in detail the method ITER uses to perform the verification and validation according to the IEC 61508 standard recommendations, for the logic configuration generated by LabVIEW-FPGA for these COTS, after the compilation of high-level language sources designed during the development.
The systems are developed using the high-level graphical programming tool LabVIEW FPGA. The IEC 61508 standard has been chosen as the reference for engineering best-practice for ICS  [2]. IEC 61508 is the functional safety standard applicable to all industries. The standard defines methods of designing, deploying, and maintaining Electrical/Electronic/Programmable Electronic (E/E/PE) safety-related systems. Its use in assurance for investment protection requires adaptation but more importantly here; this standard does not define clear guidelines for systems developed using high-level synthesis graphical programming, making it a challenge for ITER. The following paragraphs describe the process carried out by the Interlock ITER team in collaboration with the Instrumentation and Acoustics Research Group team of the Universidad Politécnica de Madrid (UPM) to analyze in-depth the applicability of the IEC 61508 standard on CompactRIO systems and its pluggable adapter modules.
CompactRIO technology offers cost-saving solutions for hardware development and acquisition. It consists of a controller chassis containing a Xilinx 65 nm Virtex-5 and a series of pluggable and configurable Input/Output modules. The controller firmware is developed by means of the LabVIEW FPGA graphical programming tool. The LabVIEW FPGA enables developers to create their designs and translate them directly to configuration stream file (bitfile). The steps for the compilation of a LabVIEW FPGA firmware are described as follows  [4]  (see Fig. Reproduced from  [4]  ITER developed a methodology based on using preconfigured templates to speed up the PIS-FA development process  [5]. As a result, several PIS prototypes were developed. These templates are used as a reference to create systems with specific functionality.
III. CURRENT V&V APPROACH The application of the IEC 61508 standard for this system must be made carefully because it is not completely appropriate for the following reasons. The first reason is that IEC 61508 is oriented to safety environments, and in this paper, the concern is investment protection. The second reason comes from the difficulty of applying a rigorous standard to a COTS system. CompactRIO and its pluggable modules were not developed with safety requirements in mind. The last and most important reason is that the standard offers compliance directives for E/E/PE systems developed with Hardware Description Languages (HDL), not for high-level synthesis languages or graphical languages, such as LabVIEW. A set of independent reviewers performed a Final Design Review of ICS that intensively reviewed the physical and design requirement.
As a result of this process, a concern was raised on insufficient systematic capability that subsequently transitioned into an ITER risk. LabVIEW generates VHDL code through which the FPGA is programmed, but it is not directly accessible by the user. The user only has access to LabVIEW graphics code, and as explained above, the standard does not offer directives for systems developed with high-level synthesis languages or graphical languages. Furthermore, it is complicated to verify the system in-depth without access to the autogenerated VHDL code. ITER responded to the chit by declaring that CompactRIObased interlock systems should allow a verification process through the final code configuring the FPGA. The process should cover the following objectives: -The correct operation of the individual unit function shall be verified.
-The correct integration and communication between the components shall be verified. -The behavior of the complete system shall be validated. To perform this task, it is mandatory to access the intermediate VHDL code generated by the LabVIEW tool and apply test techniques to it. Moreover, this process is recommended to be performed using certified Third Party VHDL compilers. As a result, ITER started a project to investigate in-depth the feasibility of applying the IEC 61508 standard to ICS-FA developed by LabVIEW FPGA tool. The final objective was to develop a process of Verification and Validation (V&V) of the firmware developed through the LabVIEW tool based on CompactRIO. This process shall guarantee the high availability and reliability of the developed systems.
IV. RESEARCH DONE Due to the reasons explained in section III, an in-depth analysis of the LabVIEW behavior and the HDL code resulting from the compilation process was carried out. The main objective was to analyze the feasibility of the LabVIEW-FPGA workflow to implement a development cycle that meets the criteria and requirements of the IEC 61508-2 specification. For this purpose, a preliminary version of a complete IEC 61508compliant V&V cycle was developed. Subsequently, this cycle was implemented on a previously developed system, analyzing the possible limitations and issues that might be encountered. Finally, based on the results obtained, a feasible V&V cycle for the target system was presented. As a use case, a previously developed PIS prototype was chosen. Specifically, a PIS corresponding to the Poloidal Field and Central Solenoid coil's power converter protection system  [5].
This plant system provides a redundant PIS-FA with a Digital TTL input module for receiving action from CIS using a Manchester Code link and two Digital Outputs 24 V actuator interfaces. The PIS includes inter-chassis communication diagnostics via Manchester Code and SPI. Also, it includes output self-diagnostics. Fig. 2  shows the system hardware and its interconnection. To perform this process, the base element was to access the VHDL code autogenerated by the LabVIEW FPGA tool. For this purpose, a Non-Disclosure Agreement was signed between NI/ITER/UPM to obtain access to the NI proprietary code.
B. VHDL Architecture The first task was focused on the IEC 61508 clauses regarding code analysis and the correct use of the compilation tools. First, a detailed study of the steps run by LabVIEW FPGA to produce the firmware through the automatic compilation process was performed. Then, an attempt was made to replicate the FPGA configuration bitstream autogenerated by LabVIEW compilation using Xilinx tools. Finally, it was possible to create a TCL script that could generate exactly the same result using Xilinx ISE tool as the ones obtained by the compilation from LabVIEW. Subsequently, a study was carried out to evaluate the appropriateness of the constraints introduced by LabVIEW to direct the synthesis, place-and-route and timing analysis, such as: clock generation, cells location, IO Blocks, and timing restrictions.
In this first stage, a systematic analysis was performed on the constraints file. In addition, a study of the VHDL code architecture generated by LabVIEW was performed. A blank project was compared to the targeted system. As a result of this analysis, the interface and functionality of every block comprising the structural design were identified and described. Other fundamental aspects of the design were elicited, such as: -Management of clock and reset domains. -Implementation of synchronization mechanisms. -The safe operation of Finite State Machines. -Identification of the design's dependence on encrypted VHDL code and IP cores. -Analysis of "Xilinx advisory" compliance, over and above Design Rules Check (DRC) for Virtex-5 and, in case of non-compliance, it shall be evaluated their importance  [6].
C. Verification Reports The next task was to cover the clauses of IEC 61508 regarding verification activities. The IEC 61508 requires the application of coding guidelines to constrain how VHDL language is used to ensure a safe synthesis. These rules aim at avoiding known vulnerabilities and ambiguities that may have unintended consequences on the system operation  [7]. To achieve this goal two courses of action were proposed. First, static analysis was performed on the VHDL code with Mentor Graphics DesignChecker tool. This tool automates the analysis by using a predefined rule-set or creating a user-defined ruleset. Unfortunately, no rule set related to Nuclear Investment Protection existed, so a customized rule set was designed based on the aeronautical standard DO-254. This analysis covers assignment errors, ensures safe synthesis, and improves the comprehension and portability of the code.
It is important to note that a few changes in code are usually needed to allow successful compilation with Mentor Graphics tools due to slight differences between Xilinx and Mentor synthesizers. Second, the Design Rule Check (DRC) analysis was performed. This analysis is carried out by Xilinx DRC tool and is executed automatically during the different phases of design compilation. The DRC runs mainly two analyses: a logical one immediately after the end of the Synthesis phase and a physical one at the end of the Place and Route (PAR) phase. The IEC 61508 standard considers performing the Static Timing Analysis (STA) mandatory. The purpose of the STA is to check the compliance of the design with the constraints file and the device-specific constraints, and it must be guaranteed that no timing violations arise after the analysis.
The STA is carried out by the TRACE tool available as part of Xilinx ISE Design Suite. The ISE compilation flow led by the LabVIEW compiler performs an STA automatically at several stages of the compilation, but a verbose analysis was additionally performed to achieve a more detailed verification. This analysis is performed after the Mapping and PAR phases. It is important to note that useful and valid results after this analysis relies on the right definition of constraints by the LabVIEW compiler. Likewise, the standard demands compliance with a set of items based on simulations of the firmware. Simulations were performed to check the correct implementation of the low-level functional requirements of the different modules. For designs developed with LabVIEW, modules are understood as the different SubVI and well-differentiated graphic code blocks.
Therefore, unit-like tests focused on the set of inputs and outputs contained in the module to be verified. Implementing this process tested if it is feasible to run functional simulations of the firmware through simulators external to LabVIEW. The third party tool Questa Advanced Simulator by Mentor Graphics was used to run the simulations. The testbenchs were developed using the SystemVerilog language, and advanced testing techniques were incorporated, such as: -Code coverage, -Functional coverage through SystemVerilog assertions, -Stimuli randomization. A SystemVerilog simulation framework was created. It is a library of typical interfaces and transfer agent classes implemented to speed up the development of new tests and apply the verification and validation process to new templates. The structure of the tests can be seen in Fig.
This resource allows complete control over the style of the VHDL code to avoid violating any coding rule. The next step is to develop the LabVIEW VIs and VHDL modules to implement the desired architecture. The module design can also be broken down into a hierarchical module design. For each module, documentation must be generated with the formal definition of the modules, the module properties, the hierarchical composition of the module, and the appropriate test plan and testbench to verify the modules implementation. The final step of the descending branch is developing the logic necessary to integrate the system modules. The ascending branch of the V-Model corresponds to the verification and validation activities. The first step is the verification of the modules. The modules are verified isolated from the rest of the design.
Performing simulations for each module can be extremely time-consuming. This section is recommended to be performed using LabVIEW testing and debugging tools, for the graphical code of the application. The code developed in VHDL must be verified and validated following the conventional flow, using testbenches in System Verilog that test the functional behavior of the design and verifying the formal analysis of the code with Design Checker. However, to finish this task, the proper integration of the VHDL modules in the LabVIEW project must be verified. For this purpose, a LabVIEW project is created with only the VHDL code developed by the user. Then, the project is compiled, and a simulation of the code corresponding to this application is carried out. In this way, it simulates the VHDL code developed by the user plus the additional logic introduced by LabVIEW for its integration.
The following task was to seek tools to analyze and debug the internal operation of the firmware running on the FPGA. The selected way was integrating the ChipScope into a LabVIEW FPGA design and using digital I/O lines (NI 9401 module) to emulate the JTAG interface. It is an embedded logic analyzer to be instantiated inside the FPGA. This logic analyzer allows to probe and trigger the internal signals of the FPGA. This technique was based on the method presented by National Instruments in  [9]  and adapted for use in CompactRIO applications. Afterward, it has been possible to adapt the use of ChipScope for CompactRIO system. This demonstrates the feasibility of introducing an internal logic analyzer in an application developed on NI 9159 and its correct operation. One of the techniques that might be demanded by the design of high reliable systems is to perform physical isolation between the critical parts of the design.
It allows isolating the safe operation and the non-safety parts of the E/E/PE system. However, this process has severe limitations in workflows based on LabVIEW FPGA. Therefore, the possibilities offered by LabVIEW FPGA in the use of user-defined constraints and the implications that would entail were explored. Finally, it was necessary to find and then use a tool able to ensure the correct isolation of an FPGA region, verifying that the design meets the strict isolation requirements needed for high-reliability applications. The tool must verify that the isolated sections of the FPGA implement correctly the corresponding fences and trusted communications with the rest of the logic  [10]. The most challenging part of this process is finding all modules related to the critical part of the design and creating fences and trusted communication with the rest of the system because techniques to implement this communication can require the insertion of code into automatically generated code which is not possible.
Finally, it has been possible to introduce user-defined constraints that affect the placement of LabVIEW graphic code. Therefore, going further in this process, it has been possible to isolate a VHDL module developed by the user and introduced in LabVIEW from the rest of the logic created by LabVIEW. The process is done by implementing fence regions and trusted communications between the different areas. Additionally, the possibility of verifying the correct isolation of an FPGA region by using the Xilinx Isolation Verification Tool (IVT) has been demonstrated.
In particular, the effort required to understand, manage and implement this process for the first time is tremendously high. Even so, the subsequent number of times it is performed also requires a significant effort. Several critical systems in the current baseline, such us the disruption mitigation system or the superconducting magnet protection, are likely to undergo the described extremely cautious V&V process. However, the techniques identified can also benefit lower-criticality systems if applied in a limited & targeted way. Additionally, two necessary aspects of developing safety systems have been considered. First, the research demonstrated the necessity and possibility of integrating an SEU detection and mitigation system in NI 9159-based applications. Second, it discovered how to control the placement of the FPGA and isolate a VHDL module introduced in LabVIEW, exposing where single-chip fault tolerance can be relevant in the CIS-FA design.
Yumoto et al. (2022)  explained the bright spots in the samples and the ones seen by MasCam as specular reflections and Nakamura et al. (  2022 ) identified flat surfaces covered with a 2 µm thick saponite-rich layer that may cause such reflections. However, the large number as well as the variation in colour of the bright spots seen by MasCam make this unlikely to be the sole explanation for the bright spots. It is more realistic that MasCam imaged inclusions  (Schröder et al. 2022). The presence of inclusions in the rock imaged by MasCam and the lack of such features in the returned samples may hint that there are different types of material present on Ryugu, possibly originating from the two impacting parent bodies. (225 ± 45)J m -2 K -1 s -1/2 (Okada The Ryugu Sample Database (Astromaterials Science Research Group (ASRG) 2022) shows microscope images and photos of 704 individual returned particles between 0.