Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “code portability”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
DOE OSTI2019

HALA: Handy Accelerated Linear Algebra

Accelerated linear algebra libraries often come with C-style of interfaces or even older Fortran77 standards, which makes it difficult to use within generic template programming environment of modern C++. For example, the BLAS and derived standards such as cuBLAS do not accept overloads and a different functions have to be called for each input type, thus it is very challenging to write a single template that handles multiple precision modes and works well with different C++ containers. HALA offers a series of templates that wrap around the BLAS/cuBLAS and other similar methods, automatically infer the relevant types and call the appropriate back-end. The templates work out-of-the-box with all C++ standard vector-like containers and can be easily extended (with template specializations) to handle user-provided containers. The HALA API is also overloaded to handle both GPU and CPU cases with a single "engine" class, thus a single high-level algorithms can utilize both CPU or GPU backends, i.e., the HALA API is unified and handles the variations between cuBLAS and BLAS. In addition to BLAS and cuBLAS, wrapper templates are provided for subset of LAPACK, cuSparse, and Cholmod methods. Work is in progress to complete as many of these standards as possible. HALA also includes a module for low-level extended register vectorization for complex number arithmetic and several simple solvers that build on the basic linear algebra capabilities. A single unified C++ API will benefit fast prototyping and easily writing code that is portable across GPU/CPU platforms as well as precision types and user containers. Note that HALA does not provide any accelerated algorithms, it simply serves as a "handy" front-end to other standards.

Stoyanov, MiroslavK.↗
DOE OSTI2019

NEAMS Workbench and Bison Fuel Performance Remote Application Configuration

The mission of the US Department of Energy (DOE) Nuclear Energy Advanced Modeling and Simulation (NEAMS) Program is to develop, apply, deploy, and support state-of-the-art predictive modeling and simulation tools for the design and analysis of current and future nuclear energy systems. This is accomplished using computing architectures that range from laptops to leadership class facilities. The NEAMS Workbench [1,2,3] initiative will facilitate the transition from conventional computer codes to high-fidelity ones by providing a common analysis environment and interface for model creation, review, execution, output review, and visualization for integrated codes. The BISON fuel performance code [4] is a finite element method (FEM)-based software being developed by multiple organizations led by the Idaho National Laboratory for the US Department of Energy Office of Nuclear Energy. BISON can simulate a variety of fuel and cladding compositions and geometries in varying dimensionalities, depending upon the problem type and complexity, including one-dimensional (1D), 1.5D, 2D axially symmetric (2D-rz), 2D radial-azimuthal (2D-rθ), or 3D models. The NEAMS Workbench allows execution of the BISON fuel performance code on local and remote compute resources. In this report, the detailed instructions of configuring the NEAMS Workbench for remote execution of the BISON fuel performance code on a portable batch system (PBS)-scheduled compute resource, as well the transfer of associated Bison files, is illustrated.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2017

ECP Milestone Report: Identify initial kernels, bake-off problems (benchmarks) and miniapps (CEED-MS6)

The CEED co-design center is developing a number of kernels, bake-off / benchmark problems (BPs) and mini-applications (miniapps) that capture the unique requirements of high-order finite element algorithms and use them to influence standards, best practices and vendors to generate more portable, better performing code across diverse hardware designs. This is a main activity in CEED’s Hardware, Applications and Finite Element thrusts. CEED’s miniapps, a.k.a. CEEDlings, are small, standalone applications - surrogates for sub-components of interest from the selected first wave of applications (the MARBL/LLNLApp and ExaSMR projects). The BPs are even smaller standalone programs that solve a simple physical problem, including discretization, linear and/or nonlinear solve, and potentially a relatively small number of time steps. A BP may be a proxy/surrogate for part of a miniapp or another problem of general interest. In CEED, both miniapps and BPs will be used extensively in the project to evaluate and compare the performance of algorithms in specific contexts. The parts of the miniapps and BPs that play an important role in their overall performance will be identified and separated as standalone kernels. These kernels and their interaction inside BPs, miniapps and the actual applications, will be the main focus of our optimization efforts. All three standalone pieces of software (miniapps, BPs, and kernels) will serve as a basis for engaging and collaborating with hardware vendors and software technologies (ST) projects. These partners can start at the bottom of the hierarchy, e.g. with the kernels, and easily transition to BPs and miniapps as all three families will be produced in the same CEED environment. In this milestone we identified the initial kernels, bake-off problems and miniapps and delivered software and documentation for them through the new CEED website, http://ceed.exascaleproject.org. We specifically identified the Nekbone miniapp for the ExaSMR application and developed a new miniapp, Laghos, for the MARBL/LLNLApp application. We also formulated four initial benchmark problems (BP1- BP4) with clearly defined performance metrics and performed an initial bake-off comparison between the Nek5000 (spectral element) and MFEM (high-order finite element) technologies. As part of the milestone, we also engaged vendors (AMD) and ST projects (MPICH, STRUMPACK). In this document we are reporting some details and results from these R&D activities, as well as additional project-wide activities performed in Q3 of FY17, including: making CEED software available on GitHub, developing the project website, and the preparation of CEED’s first annual meeting.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Initial CEED API (CEED-MS10)

Key components of CEED software development involve fast finite element operator storage and evaluation, architecture optimizations, performant algorithms for all orders, global kernels for finite element operators, efficient use of the memory sub-system, optimal data locality and motion, enhanced scalability and parallelism, and fast tensor contractions. As ultimate goals of the project, CEED is exploring and identifying the best algorithms for the full range of discretizations and applying algorithmic and software development to support ECP applications’ needs. In this milestone, we initiated the development and implementation of a common CEED API consisting of two main components: low-level and high-level APIs. We accomplished the goal of having the low-level component ready for the release of CEED v1.0 in the next quarter, see CEED-MS13. In this report we also provide a highlight from CEED’s integration with the MARBL app and the corresponding Laghos miniapp. A main theme in this work has been the systematic transition of advanced algorithms, developed and tested in Laghos, to the large-scale multi-physics settings of the MARBL code. The low-level CEED API provides a set of FE kernels and components for writing new low-level kernels. Examples include: vector and sparse linear algebra, element matrix assembly over a batch of elements, partial assembly and action for efficient high-order operators like mass, diffusion, advection, etc. The main goal of the low-level API is to establish the basis for the high-level API. Also, identifying such low-level kernels and providing a reference implementation for them serves as the basis for collaboration with vendors and STs. Another goal for the low-level API is to make it easy for applications with their own discretization infrastructure, who do not want to switch directly to using the high-level CEED API, to still evaluate and use the core operations provided by the low-level API. One of the challenges with high-order methods is that a global sparse matrix is no longer a good representation of a high-order linear operator, both with respect to the FLOPs needed for its evaluation, as well as the memory transfer needed for a matvec. Thus, another important question we tried to address while developing the low-level API is: is it possible to abstract out in a natural and efficient way the different implementations and data structures that arise when dealing with various computational device types: CPUs, GPUs, etc. Fully answering this question is beyond the scope of this particular milestone, since that requires longer time as we develop and expand the devices we support. The future high-level API will be the frontend provided by CEED consisting of high-level abstractions such as meshes, finite element spaces and solutions, bilinear forms, solvers, etc. At this high-level, an important aspect of the API will be to provide a uniform abstraction layer for writing code in a portable manner. To achieve that, we plan to utilize the MPI programming model combined with a device abstraction layer (DAL) for finite element computations that we will develop. The DAL will serve as the bridge between the low- and the high-level APIs, allowing a variety of programming models to be used for the low-level kernel implementations. The software artifacts delivered as part of this milestone include an initial CEED API software implementation (libCEED) provided through the CEED website, http://ceed.exascaleproject.org and the CEED GitHub organization, http://github.com/ceed. In addition to details and results from the above R&D efforts, in this document we are also reporting on other project-wide activities performed in Q1 of FY18, including: the Nek5000 v17.0 MFEM v3.3.2 and PETSc v3.8 releases, collaborations with ECP/ST and SciDAC projects, the inaugural Nek5000 hackathon and various outreach activities.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1978

Environment parameters and basic functions for floating-point computation

A language-independent proposal for environment parameters and basic functions for floating-point computation is presented. Basic functions are proposed to analyze, synthesize, and scale floating-point numbers. The model provides a small set of parameters and a small set of axioms along with sharp measures of roundoff error. The parameters and functions can be used to write portable and robust codes that deal intimately with the floating-point representation. Subject to underflow and overflow constraints, a number can be scaled by a power of the floating-point radix inexpensively and without loss of precision. A specific representation for FORTRAN is included.

Brown, W. S.↗
NASA NTRS1993

Hierarchical nonlinear behavior of hot composite structures

Hierarchical computational procedures are described to simulate the multiple scale thermal/mechanical behavior of high temperature metal matrix composites (HT-MMC) in the following three broad areas: (1) behavior of HT-MMC's from micromechanics to laminate via METCAN (Metal Matrix Composite Analyzer), (2) tailoring of HT-MMC behavior for optimum specific performance via MMLT (Metal Matrix Laminate Tailoring), and (3) HT-MMC structural response for hot structural components via HITCAN (High Temperature Composite Analyzer). Representative results from each area are presented to illustrate the effectiveness of computational simulation procedures and accompanying computer codes. The sample case results show that METCAN can be used to simulate material behavior such as the entire creep span; MMLT can be used to concurrently tailor the fabrication process and the interphase layer for optimum performance such as minimum residual stresses; and HITCAN can be used to predict the structural behavior such as the deformed shape due to component fabrication. These codes constitute virtual portable desk-top test laboratories for characterizing HT-MMC laminates, tailoring the fabrication process, and qualifying structural components made from them.

Murthy, P. L. N.↗
NASA NTRS2000

Perspectives on the Future of CFD

This viewgraph presentation gives an overview of the future of computational fluid dynamics (CFD), which in the past has pioneered the field of flow simulation. Over time CFD has progressed as computing power. Numerical methods have been advanced as CPU and memory capacity increases. Complex configurations are routinely computed now and direct numerical simulations (DNS) and large eddy simulations (LES) are used to study turbulence. As the computing resources changed to parallel and distributed platforms, computer science aspects such as scalability (algorithmic and implementation) and portability and transparent codings have advanced. Examples of potential future (or current) challenges include risk assessment, limitations of the heuristic model, and the development of CFD and information technology (IT) tools.

Kwak, Dochan↗
NASA NTRS1997

Communication Studies of DMP and SMP Machines

Understanding the interplay between machines and problems is key to obtaining high performance on parallel machines. This paper investigates the interplay between programming paradigms and communication capabilities of parallel machines. In particular, we explicate the communication capabilities of the IBM SP-2 distributed-memory multiprocessor and the SGI PowerCHALLENGEarray symmetric multiprocessor. Two benchmark problems of bitonic sorting and Fast Fourier Transform are selected for experiments. Communication-efficient algorithms are developed to exploit the overlapping capabilities of the machines. Programs are written in Message-Passing Interface for portability and identical codes are used for both machines. Various data sizes and message sizes are used to test the machines' communication capabilities. Experimental results indicate that the communication performance of the multiprocessors are consistent with the size of messages. The SP-2 is sensitive to message size but yields a much higher communication overlapping because of the communication co-processor. The PowerCHALLENGEarray is not highly sensitive to message size and yields a low communication overlapping. Bitonic sorting yields lower performance compared to FFT due to a smaller computation-to-communication ratio.

Sohn, Andrew↗
NASA NTRS2005

A Parallel Processing Algorithm for Remote Sensing Classification

A current thread in parallel computation is the use of cluster computers created by networking a few to thousands of commodity general-purpose workstation-level commuters using the Linux operating system. For example on the Medusa cluster at NASA/GSFC, this provides for super computing performance, 130 G(sub flops) (Linpack Benchmark) at moderate cost, $370K. However, to be useful for scientific computing in the area of Earth science, issues of ease of programming, access to existing scientific libraries, and portability of existing code need to be considered. In this paper, I address these issues in the context of tools for rendering earth science remote sensing data into useful products. In particular, I focus on a problem that can be decomposed into a set of independent tasks, which on a serial computer would be performed sequentially, but with a cluster computer can be performed in parallel, giving an obvious speedup. To make the ideas concrete, I consider the problem of classifying hyperspectral imagery where some ground truth is available to train the classifier. In particular I will use the Support Vector Machine (SVM) approach as applied to hyperspectral imagery. The approach will be to introduce notions about parallel computation and then to restrict the development to the SVM problem. Pseudocode (an outline of the computation) will be described and then details specific to the implementation will be given. Then timing results will be reported to show what speedups are possible using parallel computation. The paper will close with a discussion of the results.

Gualtieri, J. Anthony↗
NASA NTRS2003

Mobile Sensor Technologies Being Developed

The NASA Glenn Research Center is developing small mobile platforms for sensor placement, as well as methods for communicating between roving platforms and a central command location. The first part of this project is to use commercially available equipment to miniaturize an existing sensor platform. We developed a five-circuit-board suite, with an average board size of 1.5 by 3 cm. Shown in the preceding photograph, this suite provides all motor control, direction finding, and communications capabilities for a 27- by 21- by 40-mm prototype mobile platform. The second part of the project is to provide communications between mobile platforms, and also between multiple platforms and a central command location. This is accomplished with a low-power network labeled "SPAN," Sensor Platform Area Network, a local area network made up of proximity elements. In practice, these proximity elements are composed of fixed- and mobile-sensor-laden science packages that communicate to each other via radiofrequency links. Data in the network will be shared by a central command location that will pass information into and out of the network through its access to a backbone element. The result will be a protocol portable to general purpose microcontrollers satisfying a host of sensor networking tasks. This network will enter the gap somewhere between television remotes and Bluetooth but, unlike 802.15.4, will not specify a physical layer, thus allowing for many data rates over optical, acoustical, radiofrequency, hardwire, or other media. Since the protocol will exist as portable C-code, developers may be able to embed it in a host of microcontrollers from commercial to space grade and, of course, to design it into ASICs. Unlike in 802.15.4, the nodes will relate to each other as peers. A demonstration of this protocol using the two test bed platforms was recently held. Two NASA modified, commercially available, mobile platforms communicated and shared data with each other and a central command location. Web-based control and interrogation of similar mobile sensor platforms have also been demonstrated. Expected applications of this technology include robotic planetary exploration, astronaut-to-equipment communication, and remote aerospace engine inspections.

FROM↗
DOE OSTI2020

Towards Generic Parallel Programming in Computer Science Education with Kokkos

Parallel patterns, views, and spaces are promising abstractions to capture the programmer's intent as well as the contextual information that can be used by an underlying runtime to efficiently map software to parallel hardware. These abstractions can be valuable in cases where an algorithm must accommodate requirements of code and performance portability across hardware architectures and vendor programming models. Kokkos is a parallel programming model for host- and accelerator architectures that relies on these abstractions and targets these requirements. It consists of a pure C++ interface, a specification, and a programming library. The programming library exposes patterns and types and maps them to an underlying abstract machine model. The abstract machine model offers a generic view of parallel hardware. While Kokkos is gaining popularity in large-scale HPC applications at some DOE laboratories, we believe that the implemented concepts are of interest to a broader audience including academia as they may contribute to a generic, vendor, and architecture-independent education of parallel programming. In this work, we give an insight into the design considerations of this programming model and list important abstractions. Further, we document best practices obtained from giving virtual classes on Kokkos and give pointers to resources that the reader may consider valuable for a lecture on generic parallel programming for students with preexisting knowledge on this matter.

Ciesko, Jan↗
DOE OSTI2022

MFIX-Exa: Performance prediction of multiphase energy conversion devices

MFIX-Exa targets the high-fidelity CFD-DEM model in which particles are unresolved by the fluid grid (typically using a fluid mesh approximately twice the particle diameter) but discrete particle dynamics including collisions are resolved with a simple linear-spring dashpot model. The fluid field is solved with a modern low Mach number formation of a cell-centered, nodal-pressure approximate projection method using a Godunov scheme . Physics capabilities include: complex geometries via embedded boundaries (EBs), open and closed system ideal gas equations of state, species transport and heterogeneous chemi- cal reactions. MFIX-Exa is built on the AMReX software framework, the ECP Block-Structured Adaptive Mesh Refinement (AMR) Co-Design Center, which allows the code to be portable and performant.Further integration into the ECP ecosystem includes HYPRE linear solvers and Ascent for in situ visualization. Current project efforts focus on scaling up realistic simulations to the KPP of the challenge problem: NETs 50kW chemical looping reactor, shakedown and scaling on JSLE and OLCF TDS systems and reaching for any remaining performance improvements.

Musser, Jordan↗
DOE OSTI2023

Performance-Portable GPU Acceleration of the EFIT Tokamak Plasma Equilibrium Reconstruction Code

This paper presents the steps followed to GPU-offload parts of the core solver of EFIT-AI, an equilibrium reconstruction code suitable for tokamak experiments and burning plasmas. For this work, we will focus on the fitting procedure that consists of a Grad–Shafranov (GS) equation inverse solver that calculates equilibrium reconstructions on a grid. We will show profiling results of the original code (CPU-baseline), as well as the directives used to GPU-offload the most time-consuming function, initially to compare OpenACC and OpenMP on NVIDIA and AMD GPUs and later on to assess OpenMP performance portability on NVIDIA, AMD and Intel GPUs. We will make a performance comparison for different spatial grid sizes and show the speedup achieved on NVIDIA A100 (Perlmutter-NERSC), AMD MI250X (Frontier-OLCF) and Intel PVC GPUs (Sunspot-ALCF). Finally, we will draw some conclusions and recommendations to achieve high-performance portability for an equilibrium reconstruction code on the new HPC architectures

GPU↗
DOE OSTI2022

Kokkos v.4.0

SAND2023-07883O Kokkos software implements C++ performance portability programming models, tools and math libraries, which enables science and engineering software developers to use single-source codes for a wide range of computer architectures. Kokkos also provides implementations of existing and proposed C++ standard features that support programming model and math libraries that are used for implementing performance-portable scientific and engineering applications. The Kokkos libraries provide algorithms, data structures, and tools to enable high-performance computing developers to write performance-portable code. Capabilities fall into three broad categories: Kokkos Core, Kokkos Kernels, and Kokkos Tools. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

SciDAC↗
DOE OSTI2015

Kokkos Programming Model and Library

High performance computing is in the midst of a many-core revolution driven by rapidly evolving microchips with diverse and heterogeneous architectures, increasing concurrency (thread count), and decreasing memory per thread. Our HPC applications face a major challenge to effectively use these microchips with a single code base that is performance portable across these evolving architectures. Kokkos was developed to enable on-chip concurrency and manage architecture-dependent constraints on memory access patterns. The goal is to maximize the amount of application code that is portable across diverse architectures and still obtain the same (or nearly) performance as a variant of that code written specifically for that architecture. The Kokkos team has ongoing R&D co-design collaborations with Sandia's and vendors' microchip and system engineers to rapidly incorporate evolving computer architecture features into Kokkos. The team is also providing leadership for DOE laboratories' participation on the ISO/C++ language standard committee to subsuming Kokkos features into a future standard.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Performance portable ice-sheet modeling with MALI

High-resolution simulations of polar ice sheets play a crucial role in the ongoing effort to develop more accurate and reliable Earth system models for probabilistic sea-level projections. These simulations often require a massive amount of memory and computation from large supercomputing clusters to provide sufficient accuracy and resolution; therefore, it has become essential to ensure performance on these platforms. Many of today’s supercomputers contain a diverse set of computing architectures and require specific programming interfaces in order to obtain optimal efficiency. In an effort to avoid architecture-specific programming and maintain productivity across platforms, the ice-sheet modeling code known as MPAS-Albany Land Ice (MALI) uses high-level abstractions to integrate Trilinos libraries and the Kokkos programming model for performance portable code across a variety of different architectures. In this article, we analyze the performance portable features of MALI via a performance analysis on current CPU-based and GPU-based supercomputers. The analysis highlights not only the performance portable improvements made in finite element assembly and multigrid preconditioning within MALI with speedups between 1.26 and 1.82x across CPU and GPU architectures but also identifies the need to further improve performance in software coupling and preconditioning on GPUs. We perform a weak scalability study and show that simulations on GPU-based machines perform 1.24–1.92x faster when utilizing the GPUs. The best performance is found in finite element assembly, which achieved a speedup of up to 8.65x and a weak scaling efficiency of 82.6% with GPUs. We additionally describe an automated performance testing framework developed for this code base using a changepoint detection method. The framework is used to make actionable decisions about performance within MALI. We provide several concrete examples of scenarios in which the framework has identified performance regressions, improvements, and algorithm differences over the course of 2 years of development.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2020

ECP ST Project 2.3.1.06-STPM08-RAJA (Final Report)

Modern high-performance computing architectures are diverse, with hardware designs that feature multicore CPUs and CPUs plus accelerators, such as GPUs or FPGAs. Achieving good application performance often requires using a programming model and managing application data in ways that are best suited to a particular platform. For large codes that are used daily in production, and are under continual development, architecture-specific ports are untenable. Maintainability requires single-source code that is performance portable across a range of architectures and programming model back-ends. This report describes RAJA, Umpire, and CHAI, three software libraries that provide complementary capabilities to enable application portability for high performance computing (HPC) platforms. In particular, these libraries provide software abstractions that insulate application source code from hardware architecture and programming model-specific implementation details. These development of these libraries was motivated by the needs of multiphysics applications in the Weapons Simulation and Computing Program (WSC) at Lawrence Livermore National Laboratory (LLNL). Funding though the Exascale Computing Project (ECP) Software Technology (ST) project 2.3.1.06 RAJA has fostered outreach and collaboration with the ECP application and software technology development communities. In this report, we describe ECP adoption and integration of these tools to this point. The larger goal of the report is to describe to the ECP community what these projects offer, how they are used, and how to approach adoption and integration of them.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

An efficient and portable SIMD algorithm for charge/current deposition in Particle-In-Cell codes

In current computer architectures, data movement (from die to network) is by far the most energy consuming part of an algorithm (≈20pJ/word on-die to ≈10,000 pJ/word on the network). To increase memory locality at the hardware level and reduce energy consumption related to data movement, future exascale computers tend to use many-core processors on each compute nodes that will have a reduced clock speed to allow for efficient cooling. To compensate for frequency decrease, machine vendors are making use of long SIMD instruction registers that are able to process multiple data with one arithmetic operator in one clock cycle. SIMD register length is expected to double every four years. As a consequence, Particle-In-Cell (PIC) codes will have to achieve good vectorization to fully take advantage of these upcoming architectures. In this paper, we present a new algorithm that allows for efficient and portable SIMD vectorization of current/charge deposition routines that are, along with the field gathering routines, among the most time consuming parts of the PIC algorithm. Our new algorithm uses a particular data structure that takes into account memory alignment constraints and avoids gather/scat;ter instructions that can significantly affect vectorization performances on current CPUs. The new algorithm was successfully implemented in the 3D skeleton PIC code PICSAR and tested on Haswell Xeon processors (AVX2-256 bits wide data registers). Results show a factor of ×2 to ×2.5 speed-up in double precision for particle shape factor of orders 1–3. The new algorithm can be applied as is on future KNL (Knights Landing) architectures that will include AVX-512 instruction sets with 512 bits register lengths (8 doubles/16 singles). Program summary Program Title: vec_deposition Program Files doi:http://dx.doi.org/10.17632/nh77fv9k8c.1 Licensing provisions: BSD 3-Clause Programming language: Fortran 90 External routines/libraries: OpenMP > 4.0 Nature of problem: Exascale architectures will have many-core processors per node with long vector data registers capable of performing one single instruction on multiple data during one clock cycle. Data register lengths are expected to double every four years and this pushes for new portable solutions for efficiently vectorizing Particle-In-Cell codes on these future many-core architectures. One of the main hotspot routines of the PIC algorithm is the current/charge deposition for which there is no efficient and portable vector algorithm. Solution method: Here we provide an efficient and portable vector algorithm of current/charge deposition routines that uses a new data structure, which significantly reduces gather/scatter operations. Vectorization is controlled using OpenMP 4.0 compiler directives for vectorization which ensures portability across different architectures. Restrictions: Here we do not provide the full PIC algorithm with an executable but only vector routines for current/charge deposition. These scalar/vector routines can be used as library routines in your 3D Particle-In-Cell code. However, to get the best performances out of vector routines you have to satisfy the two following requirements: (1) Your code should implement particle tiling (as explained in the manuscript) to allow for maximized cache reuse and reduce memory accesses that can hinder vector performances. The routines can be used directly on each particle tile. (2) You should compile your code with a Fortran 90 compiler (e.g Intel, gnu or cray) and provide proper alignment flags and compiler alignment directives (more details in README file).

97 MATHEMATICS AND COMPUTING↗