Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “computer languages”

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 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

PySolate : A Python‐Based Thresholding Tool to Denoise or Designal Seismic Waveforms Based on the Continuous Wavelet Transform

PySolate is a Python‐based toolset that implements the continuous wavelet transform and nonlinear thresholding operations to denoise or designal seismic data, following Langston and Mousavi (2019). This filtering approach can remove microseismic noise to isolate intermediate‐period seismic signals that are key to enabling full‐waveform modeling and analysis of smaller‐magnitude regional events. This approach is best for the application to signals with frequency or time separation of signal and noise, in contrast to Fourier analysis, which is effective when signal and noise are separated in frequency. We demonstrate the Python toolset using the six announced Democratic People’s Republic of Korea declared nuclear tests, showing the effectiveness of isolating the seismic signal compared to standard bandpass filtering. In conclusion, we also demonstrate the ease of using the toolset with any Python processing tools.

Asia↗
DOE OSTI2025

Improving the Capabilities and Computational Efficiency of the RTE+RRTMGP Radiation Code (Final Report)

This report details progress on the RTE+RRTMGP radiation codes made during the period of performance. RTE+RRTMGP is a set of codes for computing radiative fluxes in planetary atmospheres. RRTMGP uses a k-distribution to provide an optical description (absorption and possibly Rayleigh optical depth) of the gaseous atmosphere, along with the relevant source functions, on a pre-determined spectral grid given temperatures, pressures, and gas concentration. RTE computes fluxes given spectrally-resolved optical descriptions and source functions. Spectrally-resolved fluxes are summarized (“reduced”) via a user extensible class. The initial release of the code and the design choices are described in Pincus et al. 2019; the codes are available on Github. Although RRTMGP was based on current (at the time) empirical spectroscopic data, RTE and RRTMGP were developed in large part to modernize software practices. The design focused on flexibility broadly interpreted: by separating code from data and allowing data to drive computation; in coupling to the host model (e.g. the coupling of clouds to radiative fluxes is user-controlled); with respect to programming languages (computational tasks are accessed via widely-compatible C interfaces); and with respect to hardware (the codes run on a range of CPU and GPU architectures). The code also puts an emphasis on modularity and clarity. RTE+RRTMGP v1.0 was released in September 20219. This award supported the evolution of the RTE+RRTMGP code base to support greater flexibility, accuracy, and efficiency.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2020

The Rodinia Benchmark Suite in SYCL

As opposed to the Open Computing Language (OpenCL) programming model in which host and device codes are generally written in different programming languages, SYCL can combine host and device codes for an application in a type-safe way to improve development productivity and performance portability. Rodinia is a widely used benchmark suite for heterogeneous computing. Hence, we port the OpenCL implementations of the benchmark suite to SYCL manually. The SYCL benchmark suite is an opensource project for tracking the development of the mainstream SYCL compilers, and for developers and researchers interested in programming productivity, performance analysis, and portability across different computing platforms. We organize the remainder of the report as follows. Section II introduces the SYCL programming model, shows the major differences between an OpenCL program and a SYCL program, and gives a summary of the benchmark suite. In Section III, we describe our SYCL implementations in more details. We evaluate the SYCL benchmarks on the Intel® central processing units (CPUs) and graphics processing units (GPUs) in Section IV. Section V concludes the report.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

A Case Study on the HACCmk Routine in SYCL on Integrated Graphics

As opposed to the Open Computing Language (OpenCL) programming model in which host and device codes are generally written in different languages, the SYCL programming model can combine host and device codes for an application in a type-safe way to improve development productivity. In this paper, we chose the HACCmk routine, a representative compute-bound kernel, as a case study on the performance of the SYCL programming model targeting a heterogeneous computing device. More specifically, we introduced the SYCL programming model, presented the OpenCL and SYCL implementations of the routine, and compared the performance of the two implementations using the offline and online compilation on Intel (R) Iris (TM) Pro integrated GPUs. We found that the overhead of online compilation may become significant compared to the execution time of a kernel. Compared to the performance of OpenCL implementations, the SYCL implementation can maintain the performance using the offline compilation. The number of execution units in a GPU are critical to improving the raw performance of a compute-bound kernel.

Compilation modes↗
DOE OSTI2019

A Case Study with the HACCmk Kernel in SYCL

The SYCL standard specifies a cross-platform abstraction layer that enables programming of heterogeneous computing systems using standard C++ [1]. In the Open Computing Language (OpenCL) programming model, host and device codes are written in different languages [2 ]. To improve development productivity and performance portability, the SYCL programming model combines host and device codes for an application in a type-safe way. In this report, we are interested in applying the SYCL programming model to a computationally intensive routine derived from the Hardware Accelerated Cosmology Code (HACC) framework for a study on performance portability on a heterogeneous computing device. We use Intel® OneAPI toolkit [3] to build the OpenCL and SYCL programs, and evaluate the performance of both implementations on Intel® integrated GPUs. We find that the SYCL implementation can achieve the same performance as the OpenCL implementation after we specify a target backend for the compiler to build the SYCL program in offline compilation. Without the specification of a target backend, the runtime will have to compile intermediate device codes for a target platform. Such runtime overhead may become significant compared to the execution of a kernel on a target device. As the kernel routine is compute-bound, we evaluate the impact of the number of compute units upon the kernel’s raw performance using two GPUs. When the hardware resource is not underutilized, we can obtain almost linear performance speedup from 48 compute units to 72 compute units in offline compilation, which indicates that the number of compute units on a GPU are important to improving the raw performance of a compute-bound kernel. The experimental results show that SYCL is a promising programming model for heterogeneous computing. The remainder of the report is organized as follows: In Section II, we describe the SYCL programming model, the steps to map an OpenCL program to a SYCL program, and the architecture of an integrated GPU. Section III introduces the kernel routine, and presents the OpenCL and SYCL implementations of the kernel. In Section IV, we evaluate the performance of the implementations on the GPUs. Section V concludes the report.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

Improving the Performance of Medical Imaging Applications using SYCL

In this report, we are interested in applying the SYCL programming model to medical imaging applications for a study on performance portability and programming productivity. The SYCL standard specifies a cross-platform abstraction layer that enables programming of heterogeneous computing systems using standard C++. As opposed to the Open Computing Language (OpenCL) programming model, in which host and device code are generally written in different programming languages [1], SYCL can combine host and device code for an application in a type-safe way to improve development productivity and performance portability.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Improving the performance of medical imaging applications using SYCL

As opposed to the Open Computing Language (OpenCL) programming model, in which host and device codes are generally written in different programming languages, SYCL can combine host and device codes for an application in a type-safe way to improve development productivity and performance portability. Hence, this report shows the experimental results of applying the SYCL programming model to medical imaging applications for a study on performance portability and programming productivity between OpenCL and SYCL. Rodinia is a widely used open-source benchmark suite for heterogeneous computing. We choose two medical imaging applications (Heart Wall and Particle Filter) in the benchmark suite, migrate the OpenCL implementations of the applications to the SYCL implementations, and evaluate their performance and productivity on Intel® microprocessors that contain a central processing unit (CPU) and an integrated graphics processing unit (GPU). The maturing SYCL compilers, which are based on a conformant implementation of the SYCL 1.2.1 Khronos specification, have been actively optimized for Intel® computing platforms. The experimental results are promising in terms of the raw performance and productivity. Although the SYCL implementation of the Heart Wall application does not execute successfully on a CPU, the SYCL implementations of the application can achieve comparable or better performance than the OpenCL implementation on Intel® integrated GPUs. For the Particle Filter application, the performance difference between the SYCL and OpenCL implementations is comparable on the GPUs for most cases, but the SYCL implementations are on average 4X faster than the OpenCL implementations on Intel® Xeon® CPUs. For programming productivity, we arguably use lines of code as a way to measure programming productivity in software. The SYCL programs reduce the lines of code of the OpenCL programs by 52% and 38% for the Heart Wall and Particle Filter, respectively. The results indicate that SYCL is a promising programming model for heterogeneous computing with the maturing compilers. We organize the remainder of the report as follows. Section II introduces the SYCL programming model, compares the major differences between an OpenCL program and a SYCL program, and describes the characteristics of the two applications. Section III describes the SYCL programming model in more details, and shows the SYCL implementation of a kernel function in the Particle Filter application as an example. In Section IV, we evaluate the performance of the applications on the CPUs and GPUs. Section V concludes the report.

59 BASIC BIOLOGICAL SCIENCES↗
DOE OSTI2026

Precision of ENDF and ENDL Formatted Data Files

The purpose is to ensure that today’s processing codes produced output to meet today’s accuracy needs. Since 1958 ENDL and about 1965 ENDF have each used a text format to define nuclear and atomic data in 11 columns for each data field. When these formats originated this was judged to be adequate to reproduce the accuracy of data at the time and to meet the needs of our applications. When these formats originated the dominant computer language of the day was FORTRAN and if written using an E11.4 format it would include only 4 or 5 digits of precision, e.g., 0.1234E-03 or 1.2345E-02, varying from one computer/system to another the result was not even unique. In the case of ENDF the 4 digit precision was not even adequate to uniquely define the atomic weight of the target, e.g., U238 = 92238 = 0.9224E+5 = WRONG! From its inceptions the ENDF format had a precision problem. One of my first tasks when in 1967 fresh out of graduate school I joined what later became the National Nuclear Data Center (NNDC), was to address this precision problem. By working with ENDF producers and users throughout the U.S. we verified, 1) E or D is not required to define FORTRAN readable numbers, e.g., E+4 or +4 are both o.k. 2) With ENDF energy eV and cross section in barns, 2 digit exponents are almost never required. 3) Since energy is never negative we could use the first of the 11 columns for a digit. Knowing this allowed us to produce ENDF/B-II to 6 or 7 digit precision, e.g., blank, decimal point, 2 or 3 digit exponent, e.g., ^1.23456-12 or ^1.234567-3. Below is an example of the actual ENDF/B-II data released. Note, the date 1970 and the atomic weight, ZA, uniquely defined to 6-digit accuracy, ^9.22350+ 4.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2023

A Task Based Approach for Co-Scheduling Ensemble Workloads on Heterogeneous Nodes

Scientific workflows consist of multiple, connected applications, with data and results flowing from one to another in a pipeline. Traditionally, such workflows are executed in sequential order, storing intermediate data in storage disks. Co-scheduling application workflows concurrently on the same compute nodes would greatly reduce the cost of moving data to/from storage and allow real-time analysis of intermediate results. Nevertheless, most parallel programming runtimes do not allow seamless integration of various applications in a scientific workflow, in part due to the complexity of managing data and resources. The situation is even more complicated for heterogeneous systems. In this work we extend the Minos Computing Library (MCL) runtime to accelerate pipe-lined and parallel workloads where multiple applications are running in the same system. MCL’s asynchronous task library and runtime dynamically manages resources to allow co-scheduling of multiple processes sharing heterogeneous resources. In addition, we design a custom ex- tension of the Open Compute Language (OpenCL) to enable multiple processes to share device memory. We enable MCL to coordinate these shared buffers to allow for easy, fast data sharing between applications. Using malleable micro-benchmarks and two application workflows that combine scientific simulation and AI-based analysis, we show that our method outperforms traditional approaches.

Index Terms—Parallel systems, Scheduling and Task ↗
DOE OSTI2024

A simple method for obtaining heat capacity coefficients of minerals

Abstract Heat capacity data are unavailable or incomplete for many minerals at geologically relevant temperatures. Despite the availability of entropy and enthalpy values in numerous thermodynamic tables (even sometimes at elevated temperatures), there remains need for extrapolation beyond, or interpolation between, temperatures. This approach inevitably results in estimates for entropy and enthalpy values because the heat capacity coefficients required for optimal thermodynamic treatment are less frequently available. Here we propose a simple method for obtaining heat capacity coefficients of minerals. This method requires only the empirically measured temperature-specific heat capacity for calculation via a matrix algorithm. The system of equations solver is written in the Python computing language and has been made accessible in an online repository. Thermodynamically, the solution to a system of equations represents the heat capacity coefficients that satisfy the mineral-specific polynomial. Direct coefficient calculation will result in more robust thermodynamic data, which are not subject to fitting uncertainties. Using hematite as an example, this method provides results that are comparable to conventional means and is applicable to any solid material. Coefficients vary within the traditional large 950 K temperature interval, indicating that best results should instead utilize a smaller 400 K temperature interval. Examples of large-scale implications include the refinement of geothermal gradient estimation in rapidly subsiding sedimentary basins or metamorphic and hydrothermal evolution.

Geochemistry & Geophysics↗
DOE OSTI2025

Cardinal: Seismic and Geoacoustic Array Processing

Data collected via seismic and infrasound array deployments are leveraged in the geosciences to detect and characterize a myriad of natural and anthropogenic sources. These deployments consist of numerous sensors placed in a predetermined configuration to amplify signal strength and improve the efficacy of array processing techniques used to measure signal directionality and waveform coherence. High‐fidelity feature extraction is often predicated on interstation distance as well as the frequency content and wavelength of an incident signal. Numerous array processing softwares analyze data in sequential frequency bands to obtain a more detailed characterization of a signal. However, current algorithms are limited in their ability to determine optimal array configuration for each band. We introduce an open‐source Python code, called Cardinal, to process seismic and infrasound array data in discretized time–frequency space with the option of applying an adaptive array design to determine optimal subarray configuration for each frequency band. To reduce computational time, the array processing step can be run in parallel using multithreading. Furthermore, the software has the capability to aggregate array processing results from different time–frequency pixels to produce separate sets of detections, or families, with added utility via the application of an adaptive semblance threshold, which aids in isolating signals‐of‐interest from coherent background noise. Upon appropriate configuration, Cardinal exhibits the potential to combine distinct seismic and infrasound phases into separate families.

Adaptive Array↗
DOE OSTI2022

Multinode Multi-GPU Two-Electron Integrals: Code Generation Using the Regent Language

The computation of two-electron repulsion integrals (ERIs) is often the most expensive step of integral-direct self-consistent field methods. Formally it scales as O(N 4 ), where N is the number of Gaussian basis functions used to represent the molecular wave function. In practice, this scaling can be reduced to O(N 2 ) or less by neglecting small integrals with screening methods. The contributions of the ERIs to the Fock matrix are of Coulomb (J) and exchange (K) type and require separate algorithms to compute matrix elements efficiently. We previously implemented highly efficient GPU-accelerated J-matrix and K-matrix algorithms in the electronic structure code TeraChem. Although these implementations supported the use of multiple GPUs on a node, they did not support the use of multiple nodes. This presents a key bottleneck to cutting-edge ab initio simulations of large systems, e.g., excited state dynamics of photoactive proteins. We present our implementation of multinode multi-GPU J- and K-matrix algorithms in TeraChem using the Regent programming language. Regent directly supports distributed computation in a task-based model and can generate code for a variety of architectures, including NVIDIA GPUs. We demonstrate multinode scaling up to 45 GPUs (3 nodes) and benchmark against hand-coded TeraChem integral code. Finally, we also outline our metaprogrammed Regent implementation, which enables flexible code generation for integrals of different angular momenta.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
DOE OSTI2023

Quantum Programming Paradigms and Description Languages

Here, this article offers perspective on quantum computing programming languages, as well as their emerging runtimes and algorithmic modalities. With the scientific high-performance computing (HPC) community as a target audience, we describe the current state of the art in the field, and outline programming paradigms for scientific workflows. One take-home message is that there is significant work required to first refine the notion of the quantum processing unit in order to integrate in the HPC environments. Programming for today’s quantum computers is making significant strides toward modern HPC-compatible workflows, but key challenges still face the field.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Large language model evaluation for high–performance computing software development

We apply AI-assisted large language model (LLM) capabilities of GPT-3 targeting high-performance computing (HPC) kernels for (i) code generation, and (ii) auto-parallelization of serial code in C ++, Fortran, Python and Julia. Our scope includes the following fundamental numerical kernels: AXPY, GEMV, GEMM, SpMV, Jacobi Stencil, and CG, and language/programming models: (1) C++ (e.g., OpenMP [including offload], OpenACC, Kokkos, SyCL, CUDA, and HIP), (2) Fortran (e.g., OpenMP [including offload] and OpenACC), (3) Python (e.g., numpy, Numba, cuPy, and pyCUDA), and (4) Julia (e.g., Threads, CUDA.jl, AMDGPU.jl, and KernelAbstractions.jl). Kernel implementations are generated using GitHub Copilot capabilities powered by the GPT-based OpenAI Codex available in Visual Studio Code given simple + + prompt variants. To quantify and compare the generated results, we propose a proficiency metric around the initial 10 suggestions given for each prompt. For auto-parallelization, we use ChatGPT interactively giving simple prompts as in a dialogue with another human including simple “prompt engineering” follow ups. Results suggest that correct outputs for C++ correlate with the adoption and maturity of programming models. For example, OpenMP and CUDA score really high, whereas HIP is still lacking. We found that prompts from either a targeted language such as Fortran or the more general-purpose Python can benefit from adding language keywords, while Julia prompts perform acceptably well for its Threads and CUDA.jl programming models. Finally, we expect to provide an initial quantifiable point of reference for code generation in each programming model using a state-of-the-art LLM. Overall, understanding the convergence of LLMs, AI, and HPC is crucial due to its rapidly evolving nature and how it is redefining human-computer interactions.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Potential of the Julia Programming Language for High Energy Physics Computing

Research in high energy physics (HEP) requires huge amounts of computing and storage, putting strong constraints on the code speed and resource usage. To meet these requirements, a compiled high-performance language is typically used; while for physicists, who focus on the application when developing the code, better research productivity pleads for a high-level programming language. A popular approach consists of combining Python, used for the high-level interface, and C++, used for the computing intensive part of the code. A more convenient and efficient approach would be to use a language that provides both high-level programming and high-performance. The Julia programming language, developed at MIT especially to allow the use of a single language in research activities, has followed this path. In this paper the applicability of using the Julia language for HEP research is explored, covering the different aspects that are important for HEP code development: runtime performance, handling of large projects, interface with legacy code, distributed computing, training, and ease of programming. The study shows that the HEP community would benefit from a large scale adoption of this programming language. The HEP-specific foundation libraries that would need to be consolidated are identified.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Trustworthy Physics-Informed Deep Learning for Predictive Scientific Computing

This project has developed powerful trustworthy physics-informed deep learning (TPiDL) models and methods to fundamentally enhance the scale and power of computational modeling in the scientific and engineering domains. Deep learning (DL) has radically advanced the state-of-the-art in machine learning, computer vision, natural language processing, and also scientific computing. Nevertheless, progress has been driven almost entirely by empirical observations, hacks, and tricks. Under the support of this project, the graph operator learning tools and advanced trustworthy physical informed neural networks have been developed. In addition, stochastic gradient replica-exchange Markov Chain Monte Carlo (MCMC) sampling algorithms have been designed to quantify the uncertainties and speed up the training of large-scale neural networks.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

S4PST: Sustainability for Programming Systems and Tools: May Workshop Report

The US Department of Energy (DOE) Exascale Computing Project (ECP) has fostered and strengthened the use of modern software engineering practices for developing applications and libraries, and this effort has resulted in the coordinated and interoperable E4S1 and xSDK2 ecosystems. Although this approach is cost-effective, it relies on robust programming systems and tools (PST) as the underlying foundation for our HPC software. At present, our primary PST stack consists of traditional high-performance computing (HPC) languages, namely Fortran, C, C++, and the popular Python language for data analysis and AI workflows. These languages support various programming frameworks and run-time abstractions that enable parallelism and concurrency across multiple node architectures and thousands of nodes through a variety of interconnect systems. However, to accommodate users’ diverse needs, certain aspects of the HPC ecosystem are delegated to vendor-specific or third-party implementations that extend beyond a particular scientific domain. This broader scope results in a multitude of specifications and variations, which leads to a complex orchestration of many-ecosystems. Unfortunately, this complexity in the ecosystem imposes additional overhead costs on consumers during the latter stages of the development cycle. In addition to the software ecosystem challenge, the upcoming conclusion of the ECP by December 2023 has raised significant concerns within the HPC programming systems community, from both the economic and social perspectives. The ECP has implemented a management structure for software development and funding decisions across all ECP participants by following a conventional hierarchical and centralized approach. However, this structure has prompted certain considerations within the community, particularly in anticipation of the Software Sustainability initiative by the DOE’s Advanced Scientific Computing Research Program (ASCR). For the success of this new initiative, it is of utmost importance to secure consistent funding and foster close engagement with researchers and core developers of existing programming-system products. This collaboration is vital to maintaining the critical capabilities of the current software during the transition phase while proactively adapting to future technology and workforce trends. The community recognizes the significance of adapting to emerging trends and is aware of the inherent fragility of the HPC software ecosystem, particularly in relation to programming systems that cater to all users. The ability to adapt and evolve is essential to staying relevant and effectively addressing these technical, economic, and social challenges. The S4PST team, which represents one of the six ASCR Software Sustainability seedling projects, is dedicated to tackling these challenges through community-based approaches that go beyond the scope of the DOE. This involves collaboration between national laboratories with academia, non-DOE institutions, hardware and system vendors, and international partners. By fostering these partnerships, we aim to create a robust and sustainable HPC software ecosystem that can effectively meet the needs of the community. This new community effort, driven by the eight DOE labs, will take on the responsibility of guiding funding decisions for programming-systems development and maintenance with transparency and consistency across all decisions. Additionally, the team will offer common technical services to the programming systems community, irrespective of their funding situations, and facilitate community-wide incubation to proactively nurture the software ecosystem. By actively engaging with stakeholders and employing a collaborative approach, we can collectively shape the future of programming systems and ensure a robust and thriving HPC software landscape. On May 11–12, 2023, the S4PST team conducted its inaugural kick-off workshop at the Innovative Computing Laboratory (ICL) in the University of Tennessee, Knoxville, hosted by Hartwig Anzt. The workshop encompassed various sessions dedicated to presentations and discussions, with the aim of comprehending the team members’ perspectives on the vision of software sustainability. Additionally, the workshop aimed to identify the technical, economic, and social requirements for sustaining the programming-systems community in the field of HPC. This report provides a summary of the S4PST effort by highlighting five major thrust areas discussed during the workshop: (i) community, (ii) technical support, (iii) training and diversity, (iv) verification, validation and correctness, and (v) emerging technologies. It also encompasses an overview of the presentations and discussions held throughout the event, our views and potential synergies with other seedling efforts, along with the outcomes and key takeaways from our initial discussions.

97 MATHEMATICS AND COMPUTING↗