SEARCH · Engineering Papers
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.
PDCVOL is an extension software originated from the Proactive Data Containers (PDC) software (LBNL Track Code 2017-098), it is an HDF5 VOL connector that allows HDF5 applications to store and access data with the PDC system without the need to modify their code. The application can take advantage of the PDC optimization features and achieve better I/O performance.
Using parallel file systems efficiently is a tricky problem due to inter-dependencies among multiple layers of I/O software, including high-level I/O libraries (HDF5, netCDF, etc.), MPI-IO, POSIX, and file systems (GPFS, Lustre, etc.). Profiling tools such as Darshan collect traces to help understand the I/O performance behavior. However, there are significant gaps in analyzing the collected traces and then applying tuning options offered by various layers of I/O software. Seeking to connect the dots between I/O bottleneck detection and tuning, we propose DXT Explorer, an interactive log analysis tool. In this paper, we present a case study using our interactive log analysis tool to identify and apply various I/O optimizations. We report an evaluation of performance improvement achieved for four I/O kernels extracted from science applications.
Exascale HPC systems are being designed with accelerators, such as GPUs, to accelerate parts of applications. In machine learning workloads as well as large-scale simulations that use GPUs as accelerators, the CPU (or host) memory is currently used as a buffer for data transfers between GPU (or device) memory and the file system. If the CPU does not need to operate on the data, then this is sub-optimal because it wastes host memory by reserving space for duplicated data. Furthermore, this “bounce buffer” approach wastes CPU cycles spent on transferring data. A new technique, NVIDIA GPUDirect Storage (GDS), can eliminate the need to use the host memory as a bounce buffer. Thereby, it becomes possible to transfer data directly between the device memory and the file system. This direct data path shortens latency by omitting the extra copy and enables higher-bandwidth. To take full advantage of GDS in existing applications, it is necessary to provide support with existing I/O libraries, such as HDF5 and MPI-IO, which are heavily used in applications. In this paper, we describe our effort of integrating GDS with HDF5, the top I/O library at NERSC and at DOE leadership computing facilities. We design and implement this integration using a HDF5 Virtual File Driver (VFD). The GDS VFD provides a file system abstraction to the application that allows HDF5 applications to perform I/O without the need to move data between CPUs and GPUs explicitly. We compare performance of the HDF5 GDS VFD with explicit data movement approaches and demonstrate superior performance with the GDS method.
Summary Parallel I/O is a critical technique for moving data between compute and storage subsystems of supercomputers. With massive amounts of data produced or consumed by compute nodes, high‐performant parallel I/O is essential. I/O benchmarks play an important role in this process; however, there is a scarcity of I/O benchmarks representative of current workloads on HPC systems. Toward creating representative I/O kernels from real‐world applications, we have created h5bench , a set of I/O kernels that exercise hierarchical data format version 5 (HDF5) I/O on parallel file systems in numerous dimensions. Our focus on HDF5 is due to the parallel I/O library's heavy usage in various scientific applications running on supercomputing systems. The various tests benchmarked in the h5bench suite include I/O operations (read and write), data locality (arrays of basic data types and arrays of structures), array dimensionality (one‐dimensional arrays, two‐dimensional meshes, three‐dimensional cubes), I/O modes (synchronous and asynchronous). In this paper, we present the observed performance of h5bench executed along several of these dimensions on existing supercomputers (Cori and Summit) and pre‐exascale platforms (Perlmutter, Theta, and Polaris). h5bench measurements can be used to identify performance bottlenecks and their root causes and evaluate I/O optimizations. As the I/O patterns of h5bench are diverse and capture the I/O behaviors of various HPC applications, this study will be helpful to the broader supercomputing and I/O community.
This report describes the Advanced Research Projects Agency-Energy Performance-Based Energy Resource Feedback, Optimization, and Risk Management (PERFORM) Electric Reliability Council of Texas (ERCOT) dataset consisting of load, solar, and wind deterministic and probabilistic forecasts at three timescales. This dataset consists of 1 year of time-coincident load, wind, and solar actuals and probabilistic forecasts for a region similar to ERCOT. All the data are stored in Hierarchical Data Format 5 (HDF5) files and have been uploaded to an Amazon Web Services repository. The ERCOT data set has 2 years (2017, 2018) of actuals and 1 year (2018) of probabilistic forecasts. These data are provided at various spatial (i.e., site-level, zone-level, and system-level) and temporal scales (i.e., day-ahead, intraday, and intra-hour). Specifically, data are provided for 125 existing wind sites, 22 existing solar sites, 139 proposed wind sites, and 204 proposed solar sites.
We present algorithmic improvements to the loading operations of certain reduced data ensembles produced from neutron scattering experiments at Oak Ridge National Laboratory (ORNL) facilities. Ensembles from multiple measurements are required to cover a wide range of the phase space of a sample material of interest. They are stored using the standard NeXus schema on individual HDF5 files. This makes it a scalability challenge, as the number of experiments stored increases in a single ensemble file. The present work follows up on our previous efforts on data management algorithms, to address identified input output (I/O) bottlenecks in Mantid, an open-source data analysis framework used across several neutron science facilities around the world. We reuse an in-memory binary-tree metadata index that resembles data access patterns, to provide a scalable search and extraction mechanism. In addition, several memory operations are refactored and optimized for the current common use cases, ranging most frequently from 10 to 180, and up to 360 separate measurement configurations. Results from this work show consistent speed ups in wall-clock time on the Mantid LoadMD routine, ranging from 19% to 23% on average, on ORNL production computing systems. The latter depends on the complexity of the targeted instrument-specific data and the system I/O and compute variability for the shared computational resources available to users of ORNL’s Spallation Neutron Source (SNS) and the High Flux Isotope Reactor (HFIR) instruments. Nevertheless, we continue to highlight the need for more research to address reduction challenges as experimental data volumes, user time and processing costs increase.
Oak Ridge National Laboratory (ORNL) experimental neutron science facilities produce 1.2 TB a day of raw event-based data that is stored using the standard metadata-rich NeXus schema built on top of the HDF5 file format. Performance of several data reduction workflows is largely determined by the amount of time spent on the loading and processing algorithms in Mantid, an open-source data analysis framework used across several neutron sciences facilities around the world. The present work introduces new data management algorithms to address identified input output (I/O) bottlenecks on Mantid. First, we introduce an in-memory binary-tree metadata index that resemble NeXus data access patterns to provide a scalable search and extraction mechanism. Second, data encapsulation in Mantid algorithms is optimally redesigned to reduce the total compute and memory runtime footprint associated with metadata I/O reconstruction tasks. Results from this work show speed ups in wall-clock time on ORNL data reduction workflows, ranging from 11% to 30% depending on the complexity of the targeted instrument-specific data. Nevertheless, we highlight the need for more research to address reduction challenges as experimental data volumes increase.
The Los Alamos National Laboratory’s (LANL) Monte Carlo N-Particle (MCNP)1 transport code version 6.3 (also known as MCNP6.3) has the capability for tracking particles on unstructured mesh (UM) geometry models embedded into constructive solid geometry (CSG) cells. This feature has been developed for performing calculations of complex geometry models because manually creating CSG models is time-consuming and error-prone as the complexities of geometries increase. A UM geometry model is a collection of finite elements representing a solid geometry. The first step of the MCNP UM calculation is using other software packages to create a finite element mesh representation of a solid 3D geometry because the MCNP code cannot be used to generate a UM model. Computer-aided design (CAD) software is typically used to create a solid geometry model, which is later imported into mesh generation software to create a UM model. Some mesh generation software packages may also be used to create solid geometries and thus CAD files are not needed. The MCNP UM feature was originally designed for models generated by the Abaqus/CAE software suite. The MCNP code version 6.0 and later can process UM models formatted as Abaqus input files. Starting with a 6.3 version, the MCNP code can process HDF5 mesh input files. We only focus on the UM models formatted as Abaqus input files in this report since currently no external software can be used to generate HDF5 mesh input files for MCNP UM calculations. The MCNP code version 6.3 can be used to convert the Abaqus mesh input files into the HDF5 mesh input files, but this option is typically used by the MCNP code development team to test the HDF5 mesh input file feature. Several software packages (such as Abaqus, Attila4MC, or Cubit) can be used to create the Abaqus input files for MCNP UM calculations. An MCNP UM calculation using an Abaqus model requires two input file types: MCNP and Abaqus input files. The Abaqus input files needed for MCNP UM calcu lations must have the correct Abaqus syntax and meet the additional requirements by the MCNP code. The MCNP code can process only Abaqus input files that make use of part and assembly definitions, where elements in each part must be grouped into one or more element sets (i.e., elset) using *Elset keyword lines with specified naming formats. The MCNP and Abaqus input files required for MCNP UM simulations must be related; pseudo-cells in an MCNP input file must be constructed from mesh model data from an Abaqus input file. For large complex UM models, it is tedious to manually create MCNP UM input files. The um pre op (unstructured mesh pre operations) program with the -m option can be used to create a skeleton MCNP input file from an Abaqus input file [6]. Since the um pre op program was written in Fortran and was not written for optimized performance, this program is a deprecated feature in the MCNP code version 6.3 and may be removed in the next release of the code. To improve calculation flow of multiphysics calculations, a Python3 code called write mcnp um input has been developed to generate an MCNP input file instead of using the um_pre_op -m option. This Python code was initially released to the public in 2020. We have updated this Python code for MCNP6.3 and it was used to generate the MCNP input files used to verify the MCNP6.3 code. The write_mcnp_um_input code is included with the MCNP6.3 code package which will be released to the public through the Radiation Safety Information Computational Center (RSICC) at Oak Ridge National Laboratory. This report is a revision of LA-UR-20-27139 report.