Engineering Papers⌕ Search

SEARCH · Engineering Papers

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.

414 records · Page 23

Global-Address Space Networking for Exascale

GASNet-EX is a portable, open-source, high-performance communication library designed to efficiently support the networking requirements of Partitioned Global Address Space (PGAS) runtime systems and other alternative models in future exascale machines. The library is an evolution of the popular GASNet communication system, building upon over 15 years of lessons learned. GASNet is a language-independent, networking middleware layer that provides network-independent, high-performance communication primitives including Remote Memory Access (RMA) and Active Messages (AM). It has been used to implement parallel programming models and libraries such as UPC, Co-Array Fortran, Titanium, Legion, Chapel, and many others. The interface is primarily intended as a compilation target and for use by runtime library writers (as opposed to end users), and the primary goals are high performance, interface portability, and expressiveness. GASNet stands for "Global-Address Space Networking".

ECP↗

UPC++ V1.0

UPC++ is a C++11 library providing classes and functions that support Partitioned Global Address Space (PGAS) programming. We are revising the library under the auspices of the DOE's Exascale Computing Project, to meet the needs of applications requiring PGAS support. UPC++ is intended for implementing elaborate distributed data structures where communication is irregular or fine-grained. The UPC++ interfaces for moving non-contiguous data and handling memories with different optimal access methods are composable and similar to those used in conventional C++. The UPC++ programmer can expect communication to run at close to hardware speeds. The key facilities in UPC++ are global pointers, that enable the programmer to express ownership information for improving locality, one-sided communication, both put/get and RPC, futures and continuations. Futures capture data readiness state, which is useful in making scheduling decisions, and continuations provide for completion handling via callbacks. Together, these enable the programmer to chain together a DAG of operations to execute asynchronously as high-latency dependencies become satisfied.

ECP↗

Umpire

The Umpire library consists of a collection of software components that provide memory and resource management capabilities that can be used by diverse high performance computing (HPC) applications. The current set of capabilities that Umpire provides Includes: • Flexible allocators to provision memory In the range of available memory resources on a target system. • An extensible allocation strategy model, allowing custom algorithms to be used to allocate memory resources in a scalable and high­performance fashion. • Memory-location aware operations that can be used to migrate and modify memory using specialized functions dependent on source and target data locations • A set of Introspection capabilities to allow the user to query the state of the different allocators and memory allocations.

ECP↗

FAODEL

FAODEL is a collection of libraries for implementing data management services on high-performance computing (HPC) platforms. It is composed of several components: (1) an RDMA portability library called NNTI for transporting data, (2) an in-application, restful API service, (3) a memory management library for network memory named Lunasa, (4) an asynchronous communication engine, and (5) a distributed key/blob service names Kelpie. Application developers may use these libraries to move data between the distributed nodes of one job to another, as well as to distributed storage resources. FAODEL is different than other communication libraries in that it supports both intra- and inter-job communication, features event-driven mechanisms, and provides high-level primitives for developers to reason about a platform’s distributed resources.

ECP↗

Modular Finite Element Methods

MFEM is a free, lightweight, scalable C++ library for finite element methods. The goal of MFEM is to enable research and development of scalable finite element discretization and solver algorithms through general finite element abstractions, accurate and flexible visualization, and tight integration with the hypre library. Conceptually, MFEM can be viewed as a finite element toolbox that provides the building blocks for developing finite element algorithms in a manner similar to that of MATLAB for linear algebra methods.

ECP↗

MPICH

MPICH is a high-performance and widely portable implementation of the MPI-4 standard from the Argonne National Laboratory. This release has all MPI 4 functions and features required by the standard with the exception of support for the user-defined data representations for I/O.

ECP↗

Kokkos Kernels v. 0.9

Linear Algebra Kernels and Graph Kernels are foundational technologies for scientific simulations. These foundational kernels need to run on several computer platforms that are popular for scientific simulations. KokkosKernels provides an implementation of different kernels that is portable to different architectures.

ECP↗

ForTrilinos

'ForTrilinos' is related to The Trilinos Project, which contains a large and growing collection of solver capabilities that can utilize next-generation platforms, in particular scalable multicore, manycore, accelerator and heterogeneous systems. Trilinos is primarily written in C++, including its user interfaces. While C++ is advantageous for gaining access to the latest programming environments, it limits Trilinos usage via Fortran. Sever ad hoc translation interfaces exist to enable Fortran usage of Trilinos, but none of these interfaces is general-purpose or written for reusable and sustainable external use. 'ForTrilinos' provides a seamless pathway for large and complex Fortran-based codes to access Trilinos without C/C++ interface code. This access includes Fortran versions of Kokkos abstractions for code execution and data management.

ECP↗

UnifyFS: A Distributed Burst Buffer File System - 0.1.0

UnifyFS is a user-level burst buffer file system under active development. UnifyFS supports scalable and efficient aggregation of I/O bandwidth from burst buffers while having the same life cycle as a batch-submitted job. While UnifyFS is designed for N-N write/read, UnifyFS compliments its functionality with the support for N-1 write/read. It efficiently accelerates scientific I/O based on scalable metadata indexing, co-located I/O delegation, and server-side read clustering and pipelining.

ECP↗

kokkosSZ (kSZ) A Portable Cellerator Implementation of SZ using Kokkos Programming Model

kSZ is a Kokkos-based implementation of the world-widely used SZ lossy compressor. We use Kokkos because it provides abstractions for both parallel execution of code and data management, which can be used to support portable implementation across different accelerator technologies. Kokkos can support OpenMP/OpenMPTarget, oneAPI, Pthreads, and CUDA as backend programming models.

ECP↗

ornladios/ADIOS2

ADIOS 2: The Adaptable Input Output (I/O) System version 2 is an open-source framework that addresses scientific data management challenges, e.g. scalable parallel I/O, as we approach the exascale era in high-performance computing (HPC). ADIOS 2 bindings are available in C++, C, Fortran, Python and can be used on supercomputers, personal computers, and cloud systems running on Linux, macOS and Windows. ADIOS 2 has out-of-the-box support for MPI and serial environments.

ECP↗

Energy Exascale Earth System Model v2.0.2

Second patch release of v2.0.0 Changes since v2.0.1 [Important change] Add and update SSP370 and SSP585 cases, add tests, fix use-case files, Change ocean and sea-ice IC for ARRM60to10. [EAM] allow thetaxx as a CAM_TARGET, enable northamericax4v1pg2_WC14to60E2r3 for AMIP, fix ndrop initialization, allow up to 15 history files. [EAMxx] allow use of readnl [EAM-MMF] allow transient SST case for C++ MMF, remove specific task/thread count for ESMT test, modify the variance transport diagnostic, reorg tests, [HOMME] Allow optional sponge layer. [ELM] add 2 land-atm compsets, update FATES to API 17.0.0, allow FATES sp mode, allow ELM harvest to drive FATES harvest, fix memleaks, reduce test build times, modified parameters for miscanthus and switchgrass based on calibration [MPAS-Ocean] turn on ocean BGC in BGC cases, fix interface locations for 60L PHC grid, add mode spec to conservation check streams, allow oRRS18to6v3 grid to run with JRA, update ocean and sea ice ICs for ARRM60to10 (needed for v2), GPU port of thickness tendency, add CMPASO-JRA1p4, [MPAS framework] Add new reproducible global sum module for MPAS components, Add mostRecentAccessTime attribute to streams [MPAS-landice] Update MALI version and Greenland mesh [MPAS-seaice] add single-cell test case, fix BGC restart, Adds omp critical directives for ice warnings seen on cori. [CIME] Fix component namelist creation bugs when NINST>1, add OpenACC, OpenMP and CXX GPU tests, fix nonBFB tests, stop using config_compilers, reduce ELM test build times with shared executable, update OpenMPI on Chrysalis. fix baseline handling, provenance handling with update to cime6.0.33, also use component-specific config_pes files and add the ones from master [Machine updates] cori modules after maint, Chrysalis to OpenMPI-4.1.3 [run_e3sm] replace default case name and group. [Externals] update SCORPIO to 1.3.2

ECP↗

Energy Exascale Earth System Model v2.1.0

First release of version 2.1 of the Energy Exascale Earth System Model. [ATM] The atmosphere component remains EAM. There are no major changes in the default configuration since 2.0. New features include: A semi-lagrangian tracer transport for theta-l dycore, a new algorithm for finding the tropopause, new RRM mesh configurations. Add and update SSP370 and SSP585 cases. Restore the FIDEAL case. [LAND] The land component is ELM. There are no major changes in the default configuration since 2.0. Several option features have been added including: implementation of topography-based subgrid structure (topounits) and accompanying parameterizations and atmospheric forcing downscaling methods; a new plant hydraulics scheme; two-way land-river hydrological coupling through the infiltration of floodplain water; an implementation of perennial crops; updates to the SNICAR-AD snow radiative transfer model; and implementation of soil erosion and sediment yield in ELM-Erosion. Each of these new changes is modular in design and can be turned on or off as the user specifies; they are currently being tested in different “BGC” configurations. [OCEAN] The ocean component remains MPAS-Ocean. Major change since version 2.0 include the addition of the Fox-Kemper et al. 2011 parameterization for submesocale eddies, a correction for barotropic thickness consistency that reduces divergence noise, and the addition of an ocean carbon conservation analysis member. [SEAICE] The sea-ice component remains MPAS-Seaice. Major changes since version 2.0 include: A correction to how shortwave parameters are interpolated in the snicar-ad 5-band radiation scheme, the addition of a sea ice carbon conservation analysis member, updates to the default sea ice biogeochemistry namelist parameters to be consistent with version 2.0 improvements to nitrogen cycling and a correction in the ice-ocean dissolved organic nitrogen coupling. [LAND ICE] The land-ice component remains MPAS-Albany-landIce (MALI). Major changes since 2.0 include an update to the MALI version and the Greenland mesh.[RIVER] The river model is MOSART. There are no major changes in the default configuration since 2.0. A major new optional feature is two-way river-ocean hydrological coupling between MOSART and MPAS-O. This change can be turned on or off as the user specifies, and is being tested in different configurations. [COUPLER] The coupler remains cpl7/MCT. Major changes since version 2.0 include: Carbon budget calculated when heat/water budgets active. Fix a bug in land-atm fluxes for tri-grid configurations. [OTHER] a small bug in the zenith angle calculation was fixed in the data models.

ECP↗

MFIX-Exa: A path toward exascale CFD-DEM simulations

MFIX-Exa is a computational fluid dynamics–discrete element model (CFD-DEM) code designed to run efficiently on current and next-generation supercomputing architectures. MFIX-Exa combines the CFD-DEM expertise embodied in the MFIX code—which was developed at NETL and is used widely in academia and industry—with the modern software framework, AMReX, developed at LBNL. The fundamental physics models follow those of the original MFIX, but the combination of new algorithmic approaches and a new software infrastructure will enable MFIX-Exa to leverage future exascale machines to optimize the modeling and design of multiphase chemical reactors.

97 MATHEMATICS AND COMPUTING↗

The Exascale Framework for High Fidelity coupled Simulations (EFFIS): Enabling whole device modeling in fusion science

We present the Exascale Framework for High Fidelity coupled Simulations (EFFIS), a workflow and code coupling framework developed as part of the Whole Device Modeling Application (WDMApp) in the Exascale Computing Project. EFFIS consists of a library, command line utilities, and a collection of run-time daemons. Together, these software products enable users to easily compose and execute workflows that include: strong or weak coupling, in situ (or offline) analysis/visualization/monitoring, command-and-control actions, remote dashboard integration, and more. We describe WDMApp physics coupling cases and computer science requirements that motivate the design of the EFFIS framework. Furthermore, we explain the essential enabling technology that EFFIS leverages: ADIOS for performant data movement, PerfStubs/TAU for performance monitoring, and an advanced COUPLER for transforming coupling data from its native format to the representation needed by another application. Finally, we demonstrate EFFIS using coupled multi-simulation WDMApp workflows and exemplify how the framework supports the project’s needs. We show that EFFIS and its associated services for data movement, visualization, and performance collection does not introduce appreciable overhead to the WDMApp workflow and that the resource-dominant application’s idle time while waiting for data is minimal.

97 MATHEMATICS AND COMPUTING↗

PETSc/TAO developments for GPU-based early exascale systems

The Portable Extensible Toolkit for Scientific Computation (PETSc) library provides scalable solvers for nonlinear time-dependent differential and algebraic equations and for numerical optimization via the Toolkit for Advanced Optimization (TAO). PETSc is used in dozens of scientific fields and is an important building block for many simulation codes. During the U.S. Department of Energy’s Exascale Computing Project, the PETSc team has made substantial efforts to enable efficient utilization of the massive fine-grain parallelism present within exascale compute nodes and to enable performance portability across exascale architectures. We recap some of the challenges that designers of numerical libraries face in such an endeavor, and then discuss the many developments we have made, which include the addition of new GPU backends, features supporting efficient on-device matrix assembly, better support for asynchronicity and GPU kernel concurrency, and new communication infrastructure. In conclusion, we evaluate the performance of these developments on some pre-exascale systems as well as the early exascale systems Frontier and Aurora, using compute kernel, communication layer, solver, and mini-application benchmark studies, and then close with a few observations drawn from our experiences on the tension between portable performance and other goals of numerical libraries.

Exascale Computing Project (ECP)↗

PELE - Transforming Combustion Science and Technology with Exascale Simulations

This poster presents the status of the Pele Combustion project, an applications project in the Exascale Computing Project. It summarizes the goal of the projects, developments added to the Pele simulation capabilities over the last year, some example performance figures that target ultimate application on the Frontier supercomputer, and show a number of published and in-progress simulation results, by us and our collaborators.

combustion↗