Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Interoperability”

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 469 records · Page 26

Mojo: MLIR-based Performance-Portable HPC Science Kernels on GPUs for the Python Ecosystem

We explore the performance and portability of the novel Mojo language for scientific computing workloads on GPUs. As the first language based on the LLVM’s Multi-Level Intermediate Representation (MLIR) compiler infrastructure, Mojo aims to close performance and productivity gaps by combining Python’s interoperability and CUDA-like syntax for compile-time portable GPU programming. We target four scientific workloads: a seven-point stencil (memory-bound), BabelStream (memory-bound), miniBUDE (compute-bound), and Hartree–Fock (compute-bound with atomic operations); and compare their performance against vendor baselines on NVIDIA H100 and AMD MI300A GPUs. We show that Mojo’s performance is competitive with CUDA and HIP for memory-bound kernels, whereas gaps exist on AMD GPUs for atomic operations and for fast-math compute-bound kernels on both AMD and NVIDIA GPUs. Although the learning curve and programming requirements are still fairly low-level, Mojo can close significant gaps in the fragmented Python ecosystem in the convergence of scientific computing and AI.

Godoy, William [ORNL] (ORCID:0000000225905178)↗

pnnl/oedisi_dopf

OpenEDI - System Integration (OEDI-SI) - PNNL Distributed Optimal Power Flow (DOPF)

Slay, Tylor↗

NEPATEC2.0: NEPA Text Corpus v2.0

The National Environmental Policy Act of 1969, as amended (NEPA), is a major environmental law in the United States, requiring Federal agencies to consider and document potential environmental impacts before deciding on a proposed action. Modernization of NEPA and permitting processes faces significant challenges due to the lack of standardized formats and interoperable systems for organizing and sharing NEPA-related information across agencies. Much of the information gathered during NEPA reviews is written into documents such as categorical exclusions, environmental assessments, and environmental impact statements, then filed in predominately independent agency file stores that may or may not be publicly accessible. The application of metadata and data standards, such as those recommended by the Council on Environmental Quality (CEQ), to NEPA documents offers a shared vocabulary and structure for key entities like projects, processes, and documents that can streamline information exchange and enhance collaboration across systems. In this work, we publicly release NEPATEC2.0, an expanded corpus of NEPA documents with associated metadata. NEPATEC2.0 encompasses approximately 120,000 documents from 60,000 projects prepared by more than 60 different agencies. Modeled to align with CEQ metadata standards, NEPATEC2.0 promotes consistency in environmental reviews and supports the ongoing effort to modernize permitting technologies by facilitating more transparent, efficient, and data-driven decision-making. Importantly, NEPATEC2.0 demonstrates the possibilities and limitations of large language model-based prompting to extract information from NEPA documents at scale.

environmental review↗

ForTrilinos v 10.1

ForTrilinos stands for interfaces to Trilinos. It effectively replaces common practices for interfacing Fortran codes with Trilinos C++ packages. Common practices include writing user-specific drivers and exploiting the name-mangling schemes of specific compilers. ForTrilinos improves portability and robustness by exploiting the C interoperability constructs of Fortran 2003. These constructs facilitate binding Fortran interface bodies to their equivalent C function prototypes, providing for name resolution independent of the compiler™s underlying mangling scheme and guaranteeing compatible type bit representations. Furthermore, ForTrilinos maintains the overall design philosophy and architecture of Trilinos by creating a derived type structure in Fortran similar to the class hierarchy in the underlying C++.ForTrilinos can be applied wherever the underlying Trilinos packages can be applied.

SciDAC↗

UPC++

UPC++ is a Partitioned Global Address Space (PGAS) extension for C++, with three main objectives: 1) to provide an object-oriented PGAS programming model in the context of the popular C++ language; 2) to add useful parallel programming idioms unavailable in UPC, such as asynchronous remote function invocation and multidimensional arrays, to support complex scientific applications; 3) to offer an easy on-ramp to PGAS programming through interoperability with other existing parallel programming systems (e.g., MPI, OpenMP, CUDA). UPC++ includes two main features beyond UPC: 1) One of the major limitations of UPC in the context of DOE application is the relatively weak notion of multidimensional arrays, which it inherited from C. To remedy this problem in UPC++, we included a multidimensional domain and array library based on that of Titanium. Titanium's library is similar to Chapel's dense and strided domains, as both were inspired by the dense and strided regions and arrays in ZPL. 2) Another feature provided by UPC++ but not by UPC is remote function invocation, which is inspired by Phalanx, X10, Habanero-C, and C++11. The user may start an asynchronous remote function invocation with the following syntax: "async(place)(function, args...);". UPC++ provides two programming constructs for specifying dynamic dependencies among tasks: 1) event-driven execution as in Phalanx and Habanero-C; 2) finish-async as in X10. We implemented UPC++ with a "compiler-free" approach using C++ templates and runtime libraries. The UPC++ front-end consists of a set of C++ header files that enables the C++ compiler to "translate" UPC++ features in a user program to runtime library calls. In particular, we use templates and operator overloading to customize the behavior of UPC++ types. This software package has been replaced with UPCC++ V 1.0

Amir Kamil, YiliZheng↗

xSDKTrilinos v. 1.0

The main purpose of the xSDKTrilinos package is to provide an interoperability layer that enables easy installation and combined usage of the IDEAS libraries, including PETSc, Hypre, and SuperLU. The package can be used for any project that uses or will use different libraries, such as Trilinos, PETSc, HYPRE and SuperLU, together. One particular example is AMANZI code from Los Alamos National Laboratories, that uses PETSc and Trilinos at the same time.

Heroux, MichaelA.↗

GPULife

The code runs the Game of Life among several processors. Each processor uses CUDA to set up the grid's buffer on the GPU, and that buffer is fed to other GPU languages to apply the rules of the game of life. Only the halo is copied off the buffer and exchanged using MPI. This code looks at the interoperability of GPU languages among current platforms.

Kelly, PriscillaN.↗

Building Energy Management Open Source Software

This is the repository for Building Energy Management Open Source Software (BEMOSS), which is an open source operating system that is engineered to improve sensing and control of equipment in small- and medium-sized commercial buildings. BEMOSS offers the following key features: (1) Open source, open architecture – BEMOSS is an open source operating system that is built upon VOLTTRON – a distributed agent platform developed by Pacific Northwest National Laboratory (PNNL). BEMOSS was designed to make it easy for hardware manufacturers to seamlessly interface their devices with BEMOSS. Software developers can also contribute to adding additional BEMOSS functionalities and applications. (2) Plug & play – BEMOSS was designed to automatically discover supported load controllers (including smart thermostats, VAV/RTUs, lighting load controllers and plug load controllers) in commercial buildings. (3) Interoperability – BEMOSS was designed to work with load control devices form different manufacturers that operate on different communication technologies and data exchange protocols. (4) Cost effectiveness – Implementation of BEMOSS deemed to be cost-effective as it was built upon a robust open source platform that can operate on a low-cost single-board computer, such as Odroid. This feature could contribute to its rapid deployment in small- or medium-sized commercial buildings. (5) Scalability and ease of deployment – With its multi-node architecture, BEMOSS provides a distributed architecture where load controllers in a multi-floor and high occupancy building could be monitored and controlled by multiple single-board computers hosting BEMOSS. This makes it possible for a building engineer to deploy BEMOSS in one zone of a building, be comfortable with its operation, and later on expand the deployment to the entire building to make it more energy efficient. (6) Ability to provide local and remote monitoring – BEMOSS provides both local and remote monitoring ability with role-based access control. (7) Security – In addition to built-in security features provided by VOLTTRON, BEMOSS provides enhanced security features, including BEMOSS discovery approval process, encrypted core-to-node communication, thermostat anti-tampering feature and many more. (8) Support from the Advisory Committee – BEMOSS was developed in consultation with an advisory committee from the beginning of the project. BEMOSS advisory committee comprises representatives from 22 organizations from government and industry.

Source record↗

Lua-CLR Bridge

LuaCLRBridge is a library which provides an interface for hosting Lua within .NET applications and facilitating interoperability between the two runtimes.

Reinke, Carl↗

AESD (Advanced Energy System Design) Records API [SWRs-17-50, 17-51, 17-52]

The Records API (application program interface) for Advanced Energy System Design (AESD) enables software that serves multidimensional record-oriented data to interoperate with software than uses such data. In the context of the Records API, multidimensional data records are simply tuples of real numbers, integers, and character strings, where each data value is tagged by a variable name, according to a pre-defined schema, and each record is assigned a unique integer identifier. Conceptually, these records are isomorphic to rows in a relational database, JSON objects, or key-value maps. Records servers might supply static datasets, sensor measurements that periodically update as new telemetry become available, or the results of simulations as the simulations generate new output. Records client software might display or analyze the data, but in the case of simulations the client request the creation of new ensembles for specified input parameters. It is also possible to chain records clients and servers together so that a client consuming data from a server might transform that data and serve it to additional clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that are readily available for common programming languages. In particular, the API has been designed to place the least possible burden on services that provide data. This document defines the message format for the Records API, a transport mechanism for communicating the data, and the semantics for interpreting it. The message format is specified as Google Protocol Buffers and the transport mechanism uses WebSockets. We discuss three major use cases for serving and consuming records data: (i) static data, (ii) dynamically augmented data, (iii) on-demand simulations, (iv) with filters, and (v) with bookmarks. Separate implementations of the API exist in C++, Haskell, JavaScript, Python, and R.

Bush, Brian↗

Joint Genome Institute Analysis Workflow Service (JAWS) v2.7

The U.S. Department of Energy Joint Genome Institute (JGI) has developed the JGI Analysis Workflow Service (JAWS) as a distributed framework to run computational workflows across diverse high-performance computing (HPC) and cloud environments. JAWS enhances the reusability, scalability, and robustness of scientific workflows by orchestrating data movement, code execution, and results retrieval across multiple DOE facilities. At its core, JAWS integrates the Cromwell workflow engine to run workflows expressed in the Workflow Description Language (WDL), ensuring portability and interoperability. To provide consistent runtime environments, JAWS employs container technologies such as Shifter, Apptainer, and Docker. Workflow tasks are managed via HTCondor on HPC backends, while Globus ensures secure and efficient data transfer between sites. JAWS is deployed as a multi-site workflow manager across national laboratory computing facilities, with dedicated instances supporting community projects such as the National Microbiome Data Collaborative (NMDC) and KBase. This distributed, service-oriented architecture enables users to "write once, run anywhere," providing scalable, production-quality workflow execution.

Kirton, Edward↗

AUTOPERF

AutoPerf is a collection of modules for low-overhead performance monitoring on HPC systems, the modules collect monitoring data such as MPI data, network counter data etc. Autoperf modules interoperate with the Open source Darshan software (xgitlab.cels.anl.gov/darshan/) as submodules and leverages the Darshan's log recording and analysis framework.

CHUNDURI, DEVISUDHEER KUMAR↗

Vulcan Digital Engineering Application

The application is being developed with the goal of preventing the entropy of all the different single purpose applications. This application utilizes a framework that enables different file formats to be read and understood through plugins dynamically loaded to the main application containing the framework. The main application provides interoperability to all the different plugins, this allows each file format to convert to every other file format that has been read. There is no theoretical limit to the number of plugins that can be used by the application. Even though the plugins may be individually written and serve a purpose like single use scripts, the plugins can only be used with the main application, this forces the application and plugins to be linked. In theory this will force better data management, or at least the bundling of the main application with the plugins.

Lehmer, JacobP↗

Memento Protocol Validator Software

The Memento Protocol Validator software provides a suite of tools to validate compliance with the Memento protocol. The Memento protocol is an interoperability solution for accessing web archiving information with the DateTime dimension.

Balakireva, Lyudmila↗

NOODLES [SWR-22-78]

NOODLES is a protocol specification for collaborative visualization. It allows software tools of any type to participate in an analysis or visualization session. Use cases include, but are not limited to, distributed analysis, workflow interoperability, computational steering, etc.

Brunhart-Lupo, Nicholas↗

Inference-Engine v0.1.0

Given a pre-trained neural network, Inference-Engine performs maps network inputs to outputs by executing the forward pass through the provided network. Although the predominant programming language for machine-learning is Python, most high-performance computing (HPC) applications are written in Fortran, C, or C++. Inference-Engine aims to support HPC programs and is written in Fortran, a language with a large feature set supporting interoperability with C. This software exposes concurrency in a portable way by using standard language features that some modern Fortran compilers can exploit with various optimizations, including offloading computation to a Graphics Processing Unit (GPU). In particular, this software makes extensive use of Fortran's "do concurrent" parallel loop construct, implicitly parallel array statements, and pure procedures that can be invoked inside "do concurrent" blocks. Inference-Engine also supports dynamic choice of inference methods at runtime. Two current options include one method that uses Fortran's "dot_product" intrinsic function inside "do concurrent" blocks and another method that instead uses Fortran' "matmul" array intrinsic function. We plan to investigate automatic compiler offloading of "do concurrent" calculations to GPUs and compile-time substitution of optimized libraries such as the Basic Linear Algebra Library (BLAS) for "matmul" invocations. We also envision the potential for the choice of which method to use could happen at program launch based on in situ performance measurements on any given platform.

Rouson, Damian↗

LLNL Automized Surface Titration Model

The LLNL Automized Surface Titration Model (L-ASTM) is a community data-driven surface complexation modeling workflow for simulating potentiometric titration of mineral surfaces. The model accepts raw experimental potentiometric titration data formatted in a findable, accessible, interoperable, and reusable (FAIR) structure. The workflow was coded in Python and coupled to PHREEQC for surface complexation modeling and PEST for data fitting and parameter estimation.

Solchan, Han↗

PowerSystemsData Specification [SWR-25-92]

This repository defines a standardized data format for representing power system datasets, with a focus on supporting time-series visualizations and 3D visualization tools. By providing a consistent and extensible structure, this format aims to streamline the development and interoperability of visualization codebases in the power systems domain. NOODLES is a cross-platform/device/tool protocol for collaborative visualization. NOODLES was Developed at the National Renewable Energy Laboratory (NREL) as a capability of the Insight Center https://www.nrel.gov/computational-science/insight-center.html

Brunhart-Lupo, Nicholas [National Renewable Energy↗