dataesr/scientific-paragraphs-categorization huggingface dataset:
For other cases of PSF, NLR performed better than the rest of the methods. In this tutorial, LR 2 A has been presented as a generalized approach for any optical field along with MATLAB codes for reconstruction of any image when the PSF is known. The common problems and pitfalls in using LR 2 A has been discussed. Simulation and experimental studies for common optical fields such as spherical, Bessel, vortex beams and exotic optical fields such as Airy, scattered and self-rotating beams have been presented. From this study, it can be seen that it is possible to transfer the 3D imaging characteristics from non-imaging type exotic fields to indirect imaging systems faithfully using LR 2 A. The application of LR 2 A to medical images such as colonoscopy images and cone beam computed tomography images with synthetic PSF has been demonstrated.
In this tutorial, we discuss the procedure for transferring the exotic 3D characteristics of the above special beams for imaging applications using LR 2 A. For the first time, the optimized computational MATLAB codes for implementing LR 2 A are also provided. The manuscript consists of five sections. The methodology is described in the second section. The third section contains the simulation studies. The experimental studies are presented in the fourth section. In the fifth section, an interesting method to tune axial resolution is discussed. The conclusion and future perspectives of the study are presented in the final section.
Any function convolved with a Delta function creates the replica of the function. Therefore, the complex amplitude obtained after the first operation is equivalent to 𝑒𝑥𝑝 𝑖𝜋(𝜆𝑧 ) 𝑅. In the next step, the above complex amplitude is multiplied to 𝜓 by an element wise multiplication operation. In the final step, the resulting complex amplitude is propagated to the sensor plane by a convolution operation expressed as three Fourier transforms ℱ ℱ 𝑒𝑥𝑝 𝑖𝜋(𝜆𝑧 ) 𝑅 ×𝜓 ×ℱ 𝑒𝑥𝑝 𝑖𝜋(𝜆𝑧 ) 𝑅. The intensity distribution IPSF can be obtained by squaring the absolute value of the complex amplitude matrix obtained at the sensor plane. The steps in MATLAB software can be found in the supplementary files of  [45]. The simulation was carried out by shifting zs from 0. 2 to 0. 6 m in steps of 4 mm and the IPSF(zs) was accumulated into a cube matrix (x, y, z, I).
6 cm) are shown in columns -2 and 3 respectively, IO is shown in column -4, IR (zs = 5 cm) and IR (zs = 5. 6 cm) are shown in columns -5 and 6 respectively. Once again, it can be seen that the 3D characteristics of the beams have been faithfully transferred to the indirect imaging system faithfully. To demonstrate the application of LR 2 A to real applications in day-to-day life, medical images were obtained from surgeons. A 65-year-old patient, male with a known case of prostrate cancer had radiotherapy about a year ago. He developed bleeding and mucous discharge from the anus. The colonoscopy finding shows mucosal pallor, telangiectasias, edema spontaneous hemorrhage and friable mucosa. It can be noted that the mucosa was congested with ulceration stricture. The images were captured using colonoscope Olympus system and CaptureITPro medical imaging software.
Polygeist Polygeist is a C/ C++ frontend for MLIR based on Clang  [40]. It is capable of translating a broad range of C++ programs into a mix of MLIR dialects that preserve elements of the high-level structure of the program. Specifically, Polygeist preserves structured control flow (loops and conditionals) as MLIR SCF dialect operations and simplifies analyses by preserving multi-dimensional array constructs whenever possible by relying on the MLIR's multi-dimensional memory reference (memref) type. Finally, Poylgeist is able to identify parts of the program suitable for polyhedral optimization  [16]  and represent them using the Affine dialect.
Barrier Semantics A CUDA __syncthreads function guarantees that all threads in a block have finished executing all instructions prior to the function call, before any threads executes any instruction after the call. Traditionally, compilers represent such functions as opaque optimization barriers that could touch all memory, and forbid any transformation involving them. In our system, we chose to represent thread-level synchronization through a new polygeist. barrier operation. Unlike other approaches, polygeist. barrier (hence referred to as simply barrier) aims to only prevent transformations that would change externally visible behavior. Rather than disallowing any code motion across a barrier, we can successfully achieve the desired semantics by defining barrier to have specific memory properties, represented as a collection of memory locations (including unknown), and memory effect type (read, write, allocate, free), as is standard within MLIR.
Evaluation We demonstrate the advantages and applicability of our approach on two well-known GPU benchmark suites: a subset of the GPU Rodinia benchmark suite  [5]  and a PyTorch implementation of a Resnet-50 neural network. These benchmarks were chosen to 1) provide a rough performance comparison of our GPU to CPU compilation on a benchmark suite (Rodinia) that has hand-coded CPU versions and 2) demonstrate a successful end-to-end integration of our system into a useful and real application (PyTorch Resnet-50) on Supercomputer Fugaku, which does not have any GPUs. Additionally, we compare the performance of our approach to the existing MCUDA  [58]  tool on a CUDA matrix multiplication. For Rodinia, we compare our translated CUDA to CPU code against OpenMP versions of the benchmarks, where they exist, as well as a run on a GPU.
11 (right). While there is some variation from benchmark to benchmark, overall our approach is on par with the hand-coded versions of the benchmarks, and even nets a 58% geomean performance improvement, when the inner serialization optimization is enabled. Without inner serialization, we still see a geomean speedup of 34%. The speedup for myocte is largely due to fewer instruction and data cache misses on the transcompiled code, which comes from optimizations which specialize the (parallel) to kernel call context, as well as the CUDA version employing fewer branches. The speedup for backprop is partially due to parallel optimizations (see Fig. 11(left) ) and partially due to the CUDA code being implemented with a linear array, as required by CUDA, instead of the double-pointer used in the OpenMP code.
Use case 2: Pytorch/Resnet50 Test To evaluate the PyTorch Resnet-50, we execute a full nodeparallel training run on one TofuD unit of the Fugaku FX1000 supercomputer, comparing against the native PyTorch CPU backend and the optimized oneDNN backend, as available. We replaced the functions related to computing log-likelihood with Polygeist-transpiled functions as their CUDA kernels use barriers and their CPU versions contain naive implementations, and dispatched other calls to relevant libraries. We ran multiple forward and back propagation passes of Resnet-50 on 224×224 ImageNet in a data-parallel fashion. We employ Horovod's synthetic benchmarking script  [52]. We build Horovod v0. 19. 5 with CUDA, LLVM, and Fujitsu's MPI library to enable multi-node, distributed deep learning on top of Pytorch.
GPU to CPU Synchronization One of the first tools for emulating GPUs on a CPU was provided directly by NVidia for debugging purposes and emulated each thread on the GPU with a distinct CPU thread. While functional, the large gap in the number of available threads makes the emulation inefficient. MCUDA  [58]  (2008) performs an AST transformation of C GPU code to generate new C CPU code that calls a threadindependent parallel for routine. MCUDA pioneered the use of "deep fission" to handle synchronization, which splits parallel loops and other constructs at synchronization points in order to eliminate them. This fission technique is also applied in other tools: Ocelot  [9]  (2010), a binary-translation tool that parses PTX assembly into LLVM and just-in-time compiles kernel functions; POCL  [29]  (2015), a Clang/LLVM compiler pass for OpenCL; COX  [23]  (2021), another LLVM transformation pass for translation of CUDA that uses fission, and handles warp-level primitives; and even this work.
While the intuition behind the fission approach is similar to that used here, we apply fission inside of a high-level compiler, rather than either source or a low-level IR. As demonstrated in Section 3. 1, performing fission on structured programs enables more efficient code transformations. While applying fission at a source-level misses the opportunity to run optimizations before fission (like barrier elimination) and applying fission at a low-level requires attempting to reconstruct the high-level structure, operating within MLIR allows us to both apply optimization and preserve high-level structure. Moreover, source-level tools tend to be quite fragile as they must re-implement parsing and semantics or the target language (e. g. C++), and as a result only operate on a limited subset of the input language, requiring re-engineering effort to replace unsupported constructs (like pointer arithmetic).
Parallel Portablity/IR, & OpenMP Optimizations Several tools define new abstractions in the host language that are amenable to CPU or GPU execution. Examples include ISPC  [46] , RAJA  [2] , Kokkos  [15] , or MapCG  [27]  (limited to map-reduce code) in C++, Loo. py  [31]  in Python, and KernelAbstractions. jl  [6]  in Julia. These approaches provide performance portability for any new code written with them. However, existing code must be rewritten in said framework and may not compose with other frameworks/languages. Several pieces of prior art discuss parallel intermediate representations, such as Tapir  [50]  for representing Cilk  [18]  in LLVM; OpenMPIR  [56]  for representing OpenMP in LLVM, PPIR  [51]  for pattern trees, and the MLIR OpenMP Dialect; as well as SDf3  [59]  for visually representing concurrency as a control-flow graph.
Conclusion By extending Polygeist/MLIR, we developed an end-to-end system capable of representing, optimizing, and transpiling CPU and GPU parallel programs. A key component of our framework is the development of a high-level barrier operation, key to representing GPU programs, whose semantics can be fully defined by its memory behavior. Unlike prior representations of parallel barriers, our semantics enable direct integration of barriers within optimization. As efficacy validation, we demonstrated GPU to CPU transpilation of a subset of the Rodinia benchmark suite on a commodity CPU and transpile Resnet-50 from the PyTorch CUDA source to run on A64FX CPU. The Rodinia benchmarks achieve a 58% geomean speedup of the transpiled GPU code over handwritten OpenMP versions. Similarly, we observe a ≈ 2× speedup of transpiled kernels over the native PyTorch CPU backend.
Acknowledgment $ cd $HOME/rodinia/common $ ln -s ubuntu. polygeist. host. make. config host. make. config $ ln -s ubuntu. polygeist-clang. openmp. host. make. config \ openmp. host. make. config To configure the benchmark run, one should edit the file rodinia/scripts/run_all_benches. sh. The HOST variable should be set to the hostname of the machine (ubuntu above). The NRUNS and NRUNS_SCALING variables should denote the number of runs of the ablation analysis and scaling analysis benchmarks, respectively. The variables THREAD_NUMS and THREAD_NUMS_OPENMP should contain a list of the number of threads to run the CUDA and OpenMP scaling tests, respectively. Rodinia. The Rodinia benchmarks can be compiled and executed by running the following script. Note that the script assumes a specific machine size, but can be edited.
$ cd $HOME/rodinia $. /scripts/run_all_benches. sh # The timing results are now at $HOME/rodinia_results/ The correctness of the generated code can be validated as follows. Note that this requires access to a GPU machine to run the GPU-versions of the programs. On a GPU machine with relevant configuration set up (see rodinia/common/ kiev0. nvcc. host. make. config for an example): $ cd $HOME/rodinia $ make MY_VERIFICATION_DISABLE=0 cuda $. /scripts/dump_cuda_correctness_info. sh # Now. /verification_data contains the data Ensure that the verification data is available on the machine used to test GPU to CPU. If this is the same machine, no action is required. Otherwise, one can copy the verification folder. Restore the configuration for Polygeist as outlined above in the configuration section, and execute the following: $ cd $HOME/rodinia $ make MY_VERIFICATION_DISABLE=0 cuda $.
/scripts/check_cuda_correctness. sh Verification is successful if no FAIL can be seen in the output of the final script. Matrix Multiplication (MCUDA). The following commands will compile and execute the matrix multiplication tests for both Polygeist and MCUDA. The arguments to the script are a list of matrix sizes, a list of thread numbers, and the number of runs. The timing data will be output in mm_results. py. $ cd $HOME/rodinia/mcuda-test $ make $. /run-scaling. sh "128 256 512 1024 2048" \ "1 2 4 8 16 24" 10 > mm_results. py MocCUDA. This section describes how to build the Moc-CUDA layer for Fugaku. To build MocCUDA for another system, one can edit the files in. /scripts/ to reflect the environment of their system. MocCUDA dependencies, including PyTorch and benchmarker can be built as follows.
A Artifact The evaluation of our results consists of three parts: • A performance comparison of a CUDA matrix multiply code on CPU, as transpiled by our pipeline (Polygeist) and an existing tool (MCuda). • An evaluation of CUDA benchmarks from the Rodinia suite on CPU, as transpiled by our pipeline (Polygeist), and a comparison to the native CPU versions of the same benchmarks when available. • An evaluation of the GPU kernels within PyTorch being replaced with CPU versions of the kernels. Obtaining the code. A meta repository containing dockerfiles and source for our set up is available at https://github. com/wsmoses/PolygeistGPU-Docker with DOI 10. 5281/zenodo. 7508499. The remainder of this section will describe the individual components of our system. Code for our tool is available at https://github.
, 2004 , Rochetin et al. , 2014). Longwave radiation is modeled using the Rapid Radiation Transfer Model (RRTM;  Mlawer et al. , 1997) , and shortwave radiation uses a 6-band code derived from  Fouquart and Bonnel (1980). The dynamical core of LMDZ is a mix of a finite difference and finite volume discretization on the sphere of the primitive equations of meteorology and of transport equations  (Hourdin et al. , 2006 (Hourdin et al. , , 2013)). Water and other tracers are advected with a scheme from  Van Leer (1997) , and angular momentum is conserved numerically. This full configuration was previously evaluated for CO transport by  Remaud et al. (2018). ₂ The dynamical core of LMDZ is parallelized in latitude using distributed memory with the Message Passing Interface standard (MPI) and in the vertical with shared memory using the Open Multi-Processing interface (OpenMP).
ICOLMDZORINCA -unstructured grid configuration ICOLMDZORINCA is a novel configuration of our coupled model that integrates the previously described ORCHIDEE land surface model, the INCA chemistry model, and the physics module of the LMDZ model. The previous dynamical core in LMDZ has been replaced by a new one, known as DYNAMICO  (Dubos et al. , 2015) , which operates on a quasi-uniform icosahedral Cgrid for its horizontal mesh. In the following, we will refer to this DYNAMICO-LMDZ-INCA-ORCHIDEE coupled model as ICO for simplicity. The hydrostatic and shallow-atmosphere non-hydrostatic Euler equations can be solved using the DYNAMICO dynamical core  (Ullrich et al. , 2017). The mesh is based on a tessellation of the sphere into triangles, which when joined, creates the primal hexagonal-pentagonal mesh.
Observational data To compare our simulated tracer concentrations to observations, we sampled the concentration fields at the nearest cell center, model level and timestamp for each data point. We used the high-quality measurements of the CO GLOBALVIEWplus ₂ v8. 0_2022-08-27 ObsPack database  (Schuldt et al. , 2022). In this dataset, observations were calibrated according to the WMO CO X2019 scale  (Hall et al. , 2021). Like for inverse ₂ modeling with LMDZ  (Chevallier et al. , 2010) , only afternoon non flagged data from 12:00 to 16:00 local time were selected for continuous in-situ surface stations under 1000 m above sea level (a. s. l. ), and only night time data from 00:00 to 4:00 local time were kept for in-situ stations above 1000 m a. s. l. All flask data, and all upper-air data (aircraft data and AirCore measurements) were kept.
This selection accounts for the usual failure of transport models to well represent the accumulation of tracers at low altitude during the night as well as the inability to model the phenomenon in mountain stations where air masses are advected during daytime through updrafts on the sun-exposed slopes  (Geels et al. , 2007). We divided the observations into three groups: surface in situ and flask data, aircraft observations and observations from AirCore flights. We used the aircraft measurements and AirCore data to obtain vertical profiles of CO concentration. AirCore  (Karion et ₂ al. 2010 ) is an atmospheric sampling system consisting of an open ended steel tube launched from an aerial platform and that collects many successive samples of the ambient air when descending. For surface data, 107 stations have been selected from the Obspack dataset out of the original 222 stations.
Surface stations with less than 5000 measurement points that passed the initial data selection described above over the entire duration of the study were excluded from the analysis. For aircrafts, we have selected 33 sites and campaigns out of a possible 51, only keeping those with more than 2000 measurement points. For the AirCore data, we kept all observations. The full list of sites and datasets used is presented in Table  1  and Table  2  as a supplement. The uncertainty of the reference CO mixing ratio measurements used here is on the order of 0. 1 ppm (see, e. altitude, and is on the order of 250 m below 20 km and up to 1 km above that altitude  (Wagenhäuser et al. , 2021 ). We discuss the potential impact of these uncertainties on our model evaluation in section 3. 5. 2.
Acknowledgements This work was granted access to the HPC resources of TGCC under the allocation  A0130102201  made by  GENCI. It was funded by the  Copernicus Atmosphere Monitoring Service , implemented by  ECMWF  on behalf of the  European Commission  (Grant:  CAMS2 55 ). We thank  Olivier Boucher  for fruitful discussions on vertical temperature profiles and the LMDZ model, and  Sakina Takache  for discussions on Dynamico. We also thank  Julien Derouillat  for his help in the implementation of XIOS for our application. We also gratefully acknowledge the many people who contributed atmospheric observations (aircraft, AirCore and surface air sample measurements). Measurements at Jungfraujoch were supported by  ICOS Switzerland , which is funded by the  Swiss National Science Foundation , in-house contributions and the  State Secretariat for Education, Research and Innovation.
Code and data availability The source code for the REG and ICO configurations is freely available online via the following address: https://forge. ipsl. jussieu. fr/igcmg/browser/CONFIG/publications/ICOLMDZORINCA_CO2_Transport_GMD_2023 under the CeCILL v2 Free Software License (http://www. cecill. info/index. en. html, last access: 11 September 2023, CECILL, 2020). The exact version of the model used to produce the results used in this paper is archived on Zenodo, as are input data and scripts to run the model and produce the plots for all the simulations presented in this paper  (Lloret et al. , 2023).
Introduction In recent decades, next-generation sequencing technologies have significantly impacted human microbiome research, allowing for a better understanding and characterization of microbiome-host interactions  (Hadrich, 2020). Numerous 16S rRNA sequencing datasets are extended further by metagenomic sequencing of the whole microbial genome. The staggering increase in publications and datasets with an ever-increasing number of samples increased the need for more performant analysis approaches, such as advanced statistical methods and machine learning (ML) algorithms that can handle large-scale microbiome datasets and extract meaningful patterns, relationships, and associations. Before entering ML analysis microbiome raw data is preprocessed through several steps shown in Supplementary Figure  S1.
(2021). Papers included in the final review were published in peer-reviewed journals from January 2011 to January 2022 and specifically analyzed human microbiome 16S rRNA and shotgun metagenomic data through ML algorithms. As of December 2022, 3 reviewers had extracted findings on data preprocessing and transformation techniques from 95 published studies (Supplementary Table  S1 ). In the subsequent sections, we present and discuss the findings and outcomes of our investigation.
, 2016). A frequently used tool for shotgun aligning and taxonomic profiling is MetaPhlAn  (Thomas et al. , 2019; Blanco-Míguez et al. , 2023). Shotgun metagenomics preprocessing generally requires a complex sequence of programs merged into pipelines to be used since there is no one-in-all software solution yet. The solution is usually found in automated pre-defined bioBakery Workflows  (Beghini et al. , 2021)  or Bbtools, namely, BBMerge and BBDuk  (Bushnell et al. , 2017; Galkin et al. , 2020). Before entering the feature selection step, additional filtering is performed on the raw data to reduce noise while keeping the most relevant taxa. In this step, microbiome low abundance features (e. g. , <500 reads) and/or prevalence (e. g. , <10%) per sample group or in the entire sample, are filtered out.
Based on the resulting count matrix, the taxonomic level under consideration (i. e. , family, genus, species) can be chosen at this stage, considering that going down to the species level would lead to strong zero inflation. Feature selection is approached by many studies through predictive feature selection strategies that encompass statistical methods for assessing the significance of the associations between the microbiome features and the disease condition. These methods include univariate and multivariate statistical methods, and different ML algorithms  (Chen et al. , 2021; Jiang et al. , 2022). Network-based methods have also been employed for selecting hub strains from co-occurrence networks before entering the ML task  (Xu et al. , 2021). It is crucial to keep in mind that when using these predictive feature selection methods, if the training dataset is not kept distinct from the test dataset throughout all preprocessing, modeling, and assessment phases, the model gains access to test set information prior to performance evaluation, resulting in data leakage  (Kapoor and Narayanan, 2022).
In Figure  1 , we present a TreeMap chart illustrating the frequencies of transformation methods applied across the analyzed papers. Within the reviewed studies, a subset dedicated to problems of disease diagnosis and risk prediction  (Fabijanić and Vlahoviček, 2016; Wu et al. , 2020; Ruuskanen et al. , 2021; Liu et al. , 2022). Data analyzed in these studies, 16S rRNA sequencing data and shotgun data, are transformed through relative abundance, log transformations, z-score normalization, and CLR. In the following subsections, we briefly discuss the normalization-based and compositional methods applied to microbiome data before ML analysis across the reviewed papers.