Search NASA⌕ Search

SEARCH · Search NASA

Results for “ECP”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
DOE OSTI2021

Port and optimize the CEED software stack to Aurora/Frontier EA (ECP Milestone Report)

The goal of this milestone was to port the CEED software stack, including Nek, MFEM and libCEED to the Frontier and Aurora early access hardware, work on optimizing the performance on AMD and Intel GPUs, and demonstrate impact in CEED-enabled ECP applications. As part of this milestone, we also performed a number of other activities, including continued optimizations for CEED applications at scale on Summit, performance evaluation on non-ECP hardware, including the Fugaku’s A64FX chip and the NVIDIA A100 GPU architecture, exploring the use of just-in-time compilations in applications at scale and potential of mixed precision optimizations in the CEED discretization and solver algorithms, and more. During the milestone period, the CEED team released new versions of 6 of its packages, including major releases of MFEM, NekRS and OCCA. We also organized the fifth CEED Annual meeting (CEED5AM) which included nearly 100 researchers from national labs, universities and industry.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

ECP Workflow Survey Report 2017

The ECP applications teams were invited to participate in an online survey from April 10-17, 2017. The survey was hosted on Google Forms and consisted of questions determined by representatives from ECP Software Technology teams and the CODAR codesign center.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

The ECP SICM project: Managing complex memory hierarchies for exascale applications

The Exascale Computing Project (ECP)’s Simplified Interface to Complex Memories (SICM) effort focuses on developing universal interfaces for discovering, managing, and sharing data across complex memory hierarchies. These facilitate the exploitation of emerging memory technologies and support precise control over their various trade-offs such as high-bandwidth versus low-latency, persistent versus ephemeral, high-capacity versus low-capacity, and near-CPU versus near-GPU. SICM comprises three interrelated components: a low-level interface, a high-level interface, and a persistent-heap interface. The low-level SICM interface is intended for system and run-time developers as well as expert application developers who prefer full control of the memory objects used within their application. The high-level SICM interface builds upon the low-level interface, employing application-level profiling and analysis to optimize data management for complex memory hierarchies. The persistent-heap interface provides applications with a persistent memory allocator that can allocate custom C++ data structures in both block-storage and byte-addressable persistent memories.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2018

DARMA-Kokkos Data and Execution Interoperability WBS 2.3.1.04 Milestone 16 (ECP Milestone Report)

DARMA (Distributed Asynchronous Resilient Models for Applications) is a runtime library supporting the Sandia ATDM (Advanced Technology Development and Mitigation) program. The main application drivers fall within the ECP milestone 2.2.5.03 ADNN03-ASC ATDM SNL Application, which includes applications that require load balancing and asynchronous communication for high performance. The DARMA runtime infrastructure has been modified to be compatible with Kokkos/OpenMP parallelization within tasks, which is a critical requirement for high performance for the Sandia ATDM apps. DARMA development has occurred in parallel with a verification milestone for ATDM in FY18. For FY19, DARMA should impact ATDM by enabling dynamic load balancing and communication through only incremental changes to the existing verified MPI codes. DARMA can now support the intra-kernel thread parallelization in the parent MPI apps, allowing DARMA to be easily added without rewriting individual math kernels. The results presented here demonstrate the DARMA results for an MPI mini-app.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2018

ECP Milestone Memo for 2.3.1.04.14

The DARMA many-task framework provides asynchronous communication and load balancing functionality. This functionality is embedded in standard, modern C++ through the use of the template wrapper classes similar to futures. DARMA previously functioned as a single, large repository. This simplified building and installation, but hindered agile development as individual components could not be easily updated or reused in other projects. DARMA components can now be developed independently and reused in other ECP projects. Through Spack and modern CMake, a complete DARMA package can be easily configured and installed with automatic dependency management for each of the configuration options.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2018

ECP ALCC Quarterly Report (Oct-Dec 2017)

The scientific goal of ExaWind Exascale Computing Project (ECP) is to advance our fundamental understanding of the flow physics governing whole wind plant performance, including wake formation, complex terrain impacts, and turbine-turbine-interaction effects. Current methods for modeling wind plant performance fall short due to insufficient model fidelity and inadequate treatment of key phenomena, combined with a lack of computational power necessary to address the wide range of relevant length scales associated with wind plants. Thus, our ten-year exascale challenge is the predictive simulation of a wind plant composed of O(100) multi-MW wind turbines sited within a 100 km2 area with complex terrain, involving simulations with O(100) billion grid points. The project plan builds progressively from predictive petascale simulations of a single turbine, where the detailed blade geometry is resolved, meshes rotate and deform with blade motions, and atmospheric turbulence is realistically modeled, to a multi turbine array in complex terrain. The ALCC allocation will be used continually throughout the allocation period. In the first half of the allocation period, small (e.g., for testing Kokkos algorithms) and medium (e.g., 10K cores for highly resolved ABL simulations) sized jobs will be typical. In the second half of the allocation period, we will also have a number of large submittals for our resolved-turbine simulations. A challenge in the latter period is that small time step sizes will require long wall-clock times for statistically meaningful solutions. As such, we expect our allocation-hour burn rate to increase as we move through the allocation period.

17 WIND ENERGY↗
DOE OSTI2020

CEED-MS34: Improve performance and capabilities of CEED-enabled ECP applications on Summit/Sierra. Exascale Computing Project Milestone Report

The main goal of this milestone was to help CEED-enabled ECP applications, including ExaSMR, MARBL, ExaWind and ExaAM, to improve their performance and capabilities on GPU systems like Summit and Lassen/Sierra. In addition, the CEED team also worked to: add and improve support for additional hardware and programming models in the CEED software components; release the next version of the CEED software stack, CEED-3.0; and demonstrate performance of libParanumal kernels in libCEED, Nek and MFEM. These additional tasks contributed directly to the main CEED-MS34 goal and will also play an important role in CEED’s future milestones.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Quantitative Performance Assessment of Proxy Apps and Parents (ECP Proxy App Project Milestone ADCD-504-9)

This report presents highlights of these efforts. Section 2 describes work that has been done to compare the performance of proxy applications on AMD MI60 vs. Nvidia V100 GPUs. So far only a small set of ECP proxies are running on AMD GPUs, but we will continue to expand this analysis as additional proxies become available. We find that although the MI60 and V100 have nearly the same measured memory bandwidth, memory bound proxy app kernels perform 20-30% worse on the MI60. Further work is needed to refine these comparisons to determine whether the root cause is due to differences in the hardware, software stack, platform specific optimization, or some combination of the three. Section 3 describes our continuing effort to find methods to accurately assess the similarity of proxies and parents. We have recently seen very encouraging results using a cosine similarity metric. This technique uses the angle between two vectors of hardware performance counters to characterize the similarity (or difference) between two applications or proxies. We show not only that several widely used proxies are highly similar to their parents, but also that they differ from non-related codes. We also show that cosine similarity can be used to identify gaps and redundancies in suites and even to gain insight into the effects of architectural differences between platforms. Our work on assessing the Exascale toolchain is ongoing. Our successes with performance measurement tools are evident from the data provided in this report. However, our assessments across the broader tool chain are still too incomplete to provide a meaningful report at this time. We will continue to assess tools and work with vendors and third party developers as issues are identified.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

Quantitative Performance Assessment of Proxy Apps and Parents (Report for ECP Proxy App Project Milestone AD-CD-PA-504-5)

Proxy applications are small, simplified codes that allow application developers to share important features of large applications without forcing collaborators to assimilate large and complex code bases. Proxies can also be though of as models for larger codes. Because proxies omit features and capabilities of their parent applications (otherwise they wouldn’t be small), the question naturally arises whether any given proxy is actually a faithful model for its parent application for some particular modeling purpose. This report sets out to answer that question for some of the proxies in the ECP proxy app collection, with particular attention to performance. It also completes the AD-CD-PA-504 Milestone: "We will assess the fidelity of 8 proxy applications with respect to their respective parent applications using the methodology previously developed."

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Five years of ForTrilinos ECP

The ForTrilinos subproject of the Exascale Computing Project (ECP) was initiated to bring the capabilities and scalability of the Trilinos numerical solver collection to Fortran scientific application codes. A novel Fortran extension to the Simplified Wrapper and Interface Generator (SWIG) tool, which automatically generates Fortran bindings from existing C/C++ library code, has been applied to key Trilinos solver libraries to generate the new ForTrilinos libraries. SWIG-Fortran has additionally been used to generate new Fortran compatibility layers for additional scientific libraries and applications. This report summarizes the products and impact of the ForTrilinos subproject.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2007

ECP Bone Workshop Day 2, Session 1: Validation of Exercise Countermeasures

The thesis of this session of the ECP Bone workshop is that computer modeling is required in order to evaluate factor of risk for fracture when considering the uniquely localized bone loss conditions experienced by Astronauts. This session provides an opportunity to introduce the Integrated Medical Model Bone Fracture Risk (IMM-BFxRM) simulation approach and how this and other models improve understanding of the effects of exercise countermeasures. This workshop session also provides an opportunity for the panel to provide recommendations on this and other "complex modeling" approaches, as well as, the importance of funding the IMM-BFxRM and companion efforts by external scientists (Lang and Keyak).

Myers, Jerry G.↗
DOE OSTI2022

ECP SOLLVE: Validation and Verification Testsuite Status Update and Compiler Insight for OpenMP

The OpenMP language continues to evolve with every new specification release, as does the need to validate and verify the new features that have been implemented by the different vendors. With the release of OpenMP 5.0 and OpenMP 5.1, new target offload and host-based features have been introduced to the programming model. While OpenMP continues to grow in maturity, there is an observable growth in the number of compiler and hardware vendors that support OpenMP. In this manuscript, the main focus is on evaluating the conformity and OpenMP implementation progress of various compiler vendors such as Cray, IBM, GNU, Clang/LLVM, NVIDIA, and Intel. More specifically, the 4.5, 5.0, and 5.1 versions of the OpenMP specification are analyzed. For our experimental setup, the Crusher and Summit computing systems hosted by Oak Ridge National Lab’s Computing Facilities are utilized. The effort of vendor agnostic analysis of these implementations is especially valuable for application developers who are using new OpenMP features to accelerate their scientific codes. Insights are presented into the current implementation status of various vendors, the progression of specific compiler’s support for OpenMP overtime, the subset of OpenMP 4.5, 5.0, and 5.1 that is supported by all compilers, and examples of how our test suite has influenced discussion regarding the correct interpretation of the OpenMP specification. By evaluating OpenMP conformity of pre-Exascale computing systems, the aim is to detail progress and status of AMD + Cray ecosystem before the system and their OpenMP implementation is used for mission critical applications when the first Exascale Computer Frontier is made available to applications.

Huber, Thomas↗