dataesr/scientific-paragraphs-categorization huggingface dataset:
a resolution that overcomes the limitation due to pixel size by at least 2 orders of magnitude. Resolutions of less than 2 nm have been reported, which shows that the technique works in the super resolution regime. It has been used to perform in-plane position determination in various contexts, including robotics  [23] [24] [25]  , machine vision  30  , and microscopy  16, 21, 22. Our group has developed a particular family of machine-readable patterned position scales and associated vision software, termed nanoGPS. We have already reported how to build 3 degrees of freedom absolute encoders using this approach  26. We previously described how small multiscale multimodal nanoGPS-navYX tags can be used for coordinate transfer in correlative microscopy  16, 31. In this paper, we present in detail the capability of machine-readable patterned position scale technology to determine the stability, reproducibility, and accuracy of a microscopy platform.
Methods Two commercially available nanoGPS OxyO kits from HORIBA were used (Fig. 1a ): one evaluation kit containing a scale with the same format as a microscopy slide  32  ; and one 5-inch kit for 10 × vision system, Ultra High Accuracy  33. The OxyO software that determines the positions and orientations from the nanoGPS images is included in each kit. The evaluation kit can be used with a wide variety of magnifications because it contains nanoGPS patterns at different scales (Fig. 1b ). It can also be used with home-built micro or macrovision systems. The patterns are pseudoperiodic, and each pseudoperiod (Fig. 1c ) contains an orientation pattern (A), chess patterns (B), and patterns in which position and scale references are encoded (C,D). The patterns are metallic and can be observed using a microscope either in reflection or transmission.
The scale images have excellent contrast (Fig. 1d ). The OxyO software can be applied to a folder of images to determine the corresponding trajectories. We have previously reported a precision of approximately 1 nm and 10 µrad of the nanoGPS technology when used with a 10 × objective  26  , both for glass and quartz scales. In this study, we carried out stability and bidirectional reproducibility experiments indifferently with both scales, and 1 nm precision is more than enough for both conventional and super-resolution microscopes. The positioning accuracy in X and Y depends on both the registration accuracy of the patterns on the scale and the thermal expansion of the scale between ambient and manufacturing temperatures. Registration accuracy is related to the fabrication technology, and thermal expansion is related to the scale material.
A 10 × objective was used. Observations were carried indifferently with reflective (brightfield) or transmission illumination. High frame rate experiments (> 200 Hz) were carried out with transmission illumination because more light was available and the exposure time could be reduced to 3 ms. This paper describes methods for investigating the in-plane positioning capability of microscopes, not to document this capability for particular setups. Therefore, we do not provide a full description of each microscope, stage, and vibration isolation table, along with their thermal and vibration environments. A Python computer program was created to control stage movements and acquire images. Images were stored as bitmap files (. bmp) in one folder per experiment. After the experiment, the image folder was treated using OxyO software to create a file containing position information as a function of time.
Stability and drift experiments were conducted by taking images at constant time intervals without introducing any voluntary stage movement. The vibration measurements were performed using an image maximum acquisition rate that ranged from 200 to 300 fps, depending on the illumination conditions and image size. The smallest image size required to obtain the nanoGPS position was determined using OxyO software. The trajectory provided by the OxyO software is expressed in the (O, X, Y) coordinate system of the scale. It is often more convenient to express it in the coordinate system of the camera (U,V axes), as shown in Fig. 2. The transformation of scale coordinates into camera coordinates is performed by applying the rotation by an angle φ z. As this angle between the scale and camera is determined by OxyO software anyway, this task could be solved very easily.
Results The experimental results are organized as follows. First, we present investigations on stability performance. Then, we assess the performance of some microscopy stages. Bidirectional reproducibility related to a single position, accuracy, and reproducibility over more elaborate trajectories are reported. Next, we investigate vibration issues. We show that vibrations are not only related to the external environment but can also be intrinsic to the operation of the microscope. We present additional results in the Supplementary Data showing how to quantify the turret reproducibility, how to determine the scale bar in a very simple way, and how angle measurements can be useful.
Other new developments One of the limitations of the work done with the 1D vertical profile version of MOCAGE and presented in  Marécal et al. (2023)  was that OH was a diagnostic species. In the standard version of MOCAGE used by  Marécal et al. (2023) , a chemical family approach is used, meaning that HO x (H + OH + HO 2 ) is the variable explicitly represented, and the OH concentration is then diagnosed from HO x assuming a photochemical equilibrium. This is why  Marécal et al. (2023)   thanks to the implementation of the Rosenbrock solver generated using the Kinetic PreProcessor (KPP) software  (Sandu and Sander, 2006). We use the standard four stages, thirdorder Rosenbrock solver (Rodas3,  Sandu et al. , 1997). This solver is different from the Eulerian backward implicit (EBI) solver which had been used until now in MOCAGE.
3. 2). The concentrations of halogen compounds (bromine and chlorine species) in the troposphere are initialised to zero at the beginning of the simulations for two reasons: (1) the original MOCAGE version does not give reliable tropospheric halogen concentrations since the halogen scheme is designed for the stratosphere only and (2) this allows us to quantify only the effect of the halogens from the volcanic plume. Regarding the emissions, except for the volcanic eruption emissions, we use the same setup as in  Lamotte et al. (2023). The anthropogenic emissions are from the MACCity emissions  (Lamarque et al. , 2010). The volatile organic compounds (VOCs) are from the MEGAN-MACC inventory  (Sindelarova et al. , 2014). The biogenic nitrogen oxide (NO x ) emissions are derived from the GEIA dataset  (Yienger and Levy, 1995) , while NO x from lightning is based on  Price et al.
The authors acknowledge funding from the  ANR  project  VOLC-HAL-CLIM  and the  Le Studium Consortium H'allo Volcano. The authors also thank  Météo-France  and the  Agence Nationale de la Recherche  for funding  Herizo Narivelo 's PhD and the  Centre National de la Recherche Scientifique  for the administration of  Herizo Narivelo 's contract. Partial funding for  Paul David Hamer  was provided by  NILU. Financial support. This research has been supported by the  Agence Nationale de la Recherches  ( ANR  project  VOLC-HAL-CLIM (Volcanic Halogens: from Deep Earth to Atmospheric Impacts) ; grant no. ANR-18-CE01-0018 ), the  Centre National de la Recherche Scientifique  (contract no. 202172 ), and the  Research Council of Norway  (administered by  NILU  under the  EO SIS  project; grant no. B-121004 ).
References are representative of the totality of data and are not meant to be all-inclusive. Limitations of the evidence base are discussed in individual sections. To assess consensus after discussions, the writing committee members participated in surveys. A predefined threshold of 70% approval for each recommendation was required, with a minimum quorum of two-thirds of the writing committee. An initial failure to reach consensus was resolved by subsequent discussions, revisions as needed, and re-voting. Writing committee members with RWI did not vote on recommendations concerning relevant topics. The final mean consensus over all recommendations was 98. 9%, with 46 of 59 recommendations reaching 100% consensus.
A more recent alternative is site-based RM. In this type of RM, a special manufacturer-specific transmitter is provided to a clinical site and can be used to interrogate CIEDs belonging to the associated manufacturer, even if the patient is not individually enrolled in RM. Figure  4  depicts the difference between traditional and site-based RM. These transmitters have no ability to reprogram the device. This tool can be used to expedite CIED device interrogation and patient care when onsite CIED interrogation is not immediately available.
Techniques for incorporating reports into electronic health records Synopsis RM information must be private but also should be available in the patient's health record. The element definitions and report formats should be universally accepted, regardless of the manufacturer, to be compatible with management software that can be incorporated into EHRs. Manual or automatic capability for populating databases is essential both for the regular follow-up and for unscheduled transmission including site-based interrogations that can occur in emergency departments, intensive care units, or even long-distance service.
The staff time required per remote and in-person device check is less when a vendor-neutral CIED management software is used. A recent publication demonstrated that sites using management software reduced, on average, the total staff time to review a remote transmission by 2. 1 minutes (11. 5 vs 13. 6 minutes) and an in-clinic visit by 2. 2 minutes (50. 4 vs 52. 6 minutes). When extrapolated to an average clinic size of 5758 patients, the use of such software was associated with an estimated 10. 1 cumulative staff hours saved during a clinic day (50. 7 hours per week) based on 171 weekly clinic visits and 1335 weekly remote transmissions. Annually, this translates to 2639 hours of staff time saved, equivalent to 1. 4 annual FTEs. 28.
This includes a need to overcome problems related to the telephone network, communication evolution, and the impossibility of using the electromagnetic spectrum band of the CIED already assigned for other uses. As the data reside on servers owned and managed by the manufacturers, the onus lies with the manufacturers to maintain the servers in a secure and encrypted environment. Privacy is of paramount consideration. The minimal standard is to maintain privacy in accordance with local and national laws. The data pooled from the servers are important to industry for quality assurance purposes (eg, tracking device performance and watching for early signs of device trouble) and for making improvements to the CIED technology. The data are also of value to individual CIED programs for improving the quality of their processes.
Adoption of third-party resources into an RM program requires careful thought and consideration to ensure patient safety and optimize communication between the patient and medical team. Third-party resources may be task specific (eg, only reviewing CIED alerts) or encompass the entire RM process. Third-party resources should not include professional decision-making. Some third-party providers act as "middleware services," centralizing data from multiple manufacturers. Others offer comprehensive services that include facilitating patient enrollment on RM, assessing and addressing compliance to transmission, providing review of routine and acute CIED transmissions with accompanying report, notifying the medical team of actionable data, generating a service charge, and integrating report data with the electronic medical record to support patient communication.
Reimbursement reform for remote monitoring There are currently many challenges with the reimbursement model for RM. First, there is a large variability in what the Medicare program pays for RM visits across the United States. This variability makes RM financially challenging in some parts of the United States. This makes little sense, especially since the background structural costs of RM are likely similar for central monitoring services. Second, the co-payments required for RM (mentioned above) serve as a barrier to optimal patient care. In the United States, while copayments are often required for diagnostic care and for treatments, copayments can be waived for preventative care and screening tests. Most CIED RM could be considered a form of preventative care. The remote visits are to ascertain whether there is a problem that might be treated, even in the absence of symptoms, to prevent progression to more serious and potentially life-threatening problems.
A detailed gate-level analysis is not a viable option either because of the extremely long simulation time. To characterize a simple CNN as LeNet on a gate-level GPU simulator would take more than 10,000 days! Inspired by other works in the field  [5, 7, 33, 40, 41] , we adopt a hybrid approach that combines accurate gate-level fault simulations with flexible software-level error injections. The behavior of a permanent fault is evaluated, at the gate level, using an open-source model of an NVIDIA GPU (FlexGripPlus  [8] ). The impact of the permanent faults on the execution of each machine instruction is evaluated and classified, identifying software error models to propagate in a real GPU. Then, to propagate these errors in software, we have crafted a dedicated software-based error injector framework (NVBitPERfi) able to automatically handle the error instrumentation in the kernel, to apply the corruption observed in the low-level evaluation, and to properly corrupt multiple threads and/or warps.
With this approach, we characterize and discuss the reliability with respect to permanent faults of 15 real workloads, including two CNNs (LeNet and YOLOv3). The proposed frameworks, the gate-level analyses, the software-level reports, and the new NVBitPERfi tool are available in a public repository  [18]. The main contributions of this work are: • A method to identify the effects of permanent faults in terms of errors at the instruction level; • The formalization of 13 categories of instruction errors (error models) based on the effects of the permanent faults in the GPU's warp scheduler controller, fetch, and decoder unit; • A new fault injector "NVBitPERfi" built on top of NVBit, to map the 13 error models in software, instrument the code, and evaluate the permanent error effects in applications; • An accurate understanding of why and how permanent faults in the GPU parallelism management units affect the execution of 15 real workloads.
Some permanent fault injectors have also been proposed. In  [17] , the authors proposed a customized software-based error injector to evaluate the effect of permanent faults on the register file and functional units. Additionally, NVBitFI  [46]  allows the user to inject permanent faults. Unfortunately, in all the available permanent fault injectors, the proposed error models consider only limited hardware units (mostly memory resources and functional units). None of the studies on GPUs have focused their evaluations on the parallelism management units, as we do in this paper. Previous works tools can hardly be extended to evaluate more complex and critical units, such as the parallelism management units.
Instruction-level Error Propagation Once the permanent hardware fault effect has been characterized as a visible software effect, we can propagate it through representative applications using fast software-based error injection in real GPUs. To do so, we implemented one software error function for each permanent error model obtained in the error identification and classification experiment (step 3). These error functions are inserted in the application's SASS code to implement the permanent error effect during the application's execution, mimicking in software the equivalent effect of a permanent fault in the GPU unit. We crafted a customized binary instrumentation tool (NVBit-PERfi  [18] ) built over the NVBit framework  [48]  to propagate the instruction-level error through the application software.
To implement the software-level error propagation at the ISA-level, our tool adopts the Hardware-Injection through Program Transformation (HIPT) technique  [46]. NVBitPERfi mimics the behavior of a permanent error during the application's execution considering: i) the error model specifications, ii) the GPU architecture details, and iii) the instrumentation mechanisms offered by NVBit. We addressed two main challenges in the implementation of NVBitPERfi. (1)  The target hardware units corruption can impact one or multiple threads in one or multiple warps. (2) Since we are addressing permanent faults, each instruction mapped to the corrupted hardware unit must be corrupted. Thus, we need to identify all the instructions activating the fault. It is crucial to have detailed hardware error specifications to identify how many threads/warps need to be affected by the permanent hardware fault.
Applications Evaluation Once the permanent fault effect has been characterized as software error models and the procedures to corrupt thread(s)/warps(s) in a real GPU have been implemented, we can effectively evaluate the impact of permanent faults on real workloads by using the NVBitPERfi framework implementing the HIPT technique. This methodology reduces the simulation times by several orders of magnitude compared to the classical logic simulation approach. For example, an entire fault injection campaign for all the error models using our methodology for the GEMM code can be performed in less than 24h, while using only low-level fault injections, the same campaign would take 60,000 hours (i. e. , more than 6 years). We select 15 realistic workloads (listed in Table  1 ) to evaluate the error models implemented on NVBitPERfi.
Error model implementation/propagation We implement, as software procedures, the permanent error models derived from the fine-grain circuit-level analysis in NVBitPERfi to mimic in detail each error according to their specifications. We use the same philosophy of NVBitFI: we devised dedicated instrumentation functions inserted in the assembly source code of the GPU kernels during the instrumentation stage  [48]. Then, the error is injected, propagated and evaluated (at speed) once the faulty kernel is issued on the device. Some error models require only one instrumentation function right before or after the targeted SASS instruction. Other error models are more challenging, since they require modifying an operand before the actual instruction execution and then restoring its content after the execution.
For IAC (CTA) error, the instrumentation function modifies the destination register 𝑅𝑑 of the instructions reading the SR_CTAID special register of one of the thread's three dimensions x, y, or z indexing registers. In this case, when the index of the block changes, the obtained effect leads to incorrect block thread execution. IAL: The software-level implementation of Incorrect Active Lane error requires two different approaches. The first one, the unauthorized inactive lane (Fig. 6. a), ignores the result of all instructions executed on a specific functional unit in one or several lanes (e. g. , Integer or floating point cores). This functionality can be achieved by replacing the result of such instructions with the content of the destination register captured before executing the instructions.
CONCLUSIONS We have proposed a method to understand permanent fault activation and propagation. We exploit a multi-level approach to combine accurate gate-level simulations with efficient software-based error propagation. We focus on the WSC, Fetch and Decoder units and present the first quantitative estimation of their failure in the GPU code execution. We have identify four main groups of errors: (i) Operation, ii) Control-flow , iii) Parallel management, and iv) Resource management errors), corresponding to 13 instruction error categories. We have implemented instrumentation functions for the 13 error categories and used them to propagate the error effects in 15 real applications, resorting to a specially crafted instruction-level error injector (NVBitPERfi). The experimental results show that the permanent fault effect depends on the corrupted unit and executed instruction.
It is important to note that we used commercial logic simulation frameworks, and therefore licenses are required to replicate the profiling, fault injection, error identification, and classification steps. Step 4. Code instrumentation and instruction-level error propagation: To execute the software simulations, it is necessary to clone the GitHub repository 2  following the Artifacts 2 description steps. We have prepared a script that generates the inputs and golden files to be used, which will ensure that the same workloads and input vectors that are used as in the paper. After generating the input and output files, you can run the tool by providing the benchmark to be evaluated and the fault model, which has the same acronym reported in the paper. Please note that the fault injection procedure may take some time (an average of 20 hours per workload) and will depend on the machine being used to simulate and the number of injections specified in the configuration files.
Artifacts 2: NVBitPERfi To use NVBitPERfi, the user can download or clone it from the GitHub repository 5  into the desired directory. Once downloaded, NVBit should be placed in the root directory of the tool. The script to generate the inputs and configure the logging library must be executed to configure the tool to run the same codes as in the paper. However, if the user wants to use different benchmarks than those reported in the paper, this must be done manually. The script can be executed by following these steps: cd test-apps/ # Run to configure the required files python3 configure_real_workloads. py If the default benchmarks are used, it is not necessary to modify the scripts/params. py file. However, if custom benchmarks are used, updating the apps configuration variable in the scripts/params.
It is important to note that each parser has configuration variables in its first lines that must be set prior to execution according to your path directories. The following command can be used to parse the data: cd scripts/parsers/ # -Set the configuration variables # inside the parser and execute it python3 parse_pf_injections. py # Results will be stored in the path # set in the OUTPUT_PARSED_FILE var The CSV files are used to build Figures  8  and 9  in the paper.
Possible issues One possible issue with software tools is related to incorrect paths and compatibility with libraries. These problems can often be resolved by correctly configuring the paths and using the libraries properly. On the other hand, running hardware simulations requires access to paid commercial tools such as ModelSim by Siemens EDA and Z01X by Synopsys. It is worth noting that hardware injections are only necessary if the user wants to characterize new models and injection sites. If the goal is to replicate or inject already evaluated fault models, there is no need to run the hardware simulations.
Understanding the Effects of Permanent Faults in GPU's Parallelism Management and Control Units required repositories. Then open a shell window pointing to such a directory and execute the following commands. # NVBit-v1. 5. 5 wget https:github. comNVlabsNVBitreleasesdownload1. 5. 5nvbit-Linux-x86_64-1. 5. 5. tar. bz2 tar xvfj nvbit-Linux-x86_64-1. 5. 5. tar. bz2 cd nvbit_releasetools # NVbitPERfi git clone https:github. comdivadnauj-GBnvbitPERfi. git cd nvbitPERfi find. -name "*. sh" | xargs chmod +x # Prepare the benchmarks cd test-apps python3 configure_real_workloads. py.