Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “API,”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

TraceContract: A Scala DSL for Trace Analysis

In this paper we describe TRACECONTRACT, an API for trace analysis, implemented in the SCALA programming language. We argue that for certain forms of trace analysis the best weapon is a high level programming language augmented with constructs for temporal reasoning. A trace is a sequence of events, which may for example be generated by a running program, instrumented appropriately to generate events. The API supports writing properties in a notation that combines an advanced form of data parameterized state machines with temporal logic. The implementation utilizes SCALA's support for defining internal Domain Specific Languages (DSLs). Furthermore SCALA's combination of object oriented and functional programming features, including partial functions and pattern matching, makes it an ideal host language for such an API.

log file analysis↗
NASA NTRS2012

The NASA Tournament Laboratory (NTL): Improving Data Access at PDS while Spreading Joy and Engaging Students through 16 Micro-Contests

NASA PDS hosts terabytes of valuable data from hundreds of data sources and spans decades of research. Data is stored on flat-file systems regulated through careful meta dictionaries. PDS's data is available to the public through its website which supports data searches through drill-down navigation. While the system returns data quickly, result sets in response to identical input differ depending on the drill-down path a user follows. To correct this Issue, to allow custom searching, and to improve general accessibility, PDS sought to create a new data structure and API, and to use them to build applications that are a joy to use and showcase the value of the data to students, teachers and citizens. PDS engaged TopCoder and Harvard Business School through the NTL to pursue these objectives in a pilot effort. Scope was limited to Small Bodies Node data. NTL analyzed data, proposed a solution, and implemented it through a series of micro-contests. Contest focused on different segments of the problem; conceptualization, architectural design, implementation, testing, etc. To demonstrate the utility of the completed solution, NTL developed web-based and mobile applications that can compare targets, regardless of mission. To further explore the potential of the solution NTL hosted "Mash-up" challenges that integrated the API with other publically available assets, to produce consumer and teaching applications, including an Augmented Reality iPad tool. Two contests were also posted to middle and high school students via the NoNameSite.com platform, and as a result of these contests, PDS/SBN has initiated a Facebook program. These contests defined and implemented a data warehouse with the necessary migration tools to transform legacy data, produced a public web interface for the new search, developed a public API, and produced four mobile applications that we expect to appeal to users both within and, without the academic community.

LaMora, Andy↗
NASA NTRS2014

Stability Analysis of ISS Medications

It is known that medications degrade over time, and that extreme storage conditions will hasten their degradation. The temperature and humidity conditions of the ISS have been shown to be within the ideal ranges for medication storage, but the effects of other environmental factors, like elevated exposure to radiation, have not yet been evaluated. Current operational procedures ensure that ISS medications are re-stocked before expiration, but this may not be possible on long duration exploration missions. For this reason, medications that have experienced long duration storage on the ISS were returned to JSC for analysis to determine any unusual effects of aging in the low- Earth orbit environment. METHODS Medications were obtained by the JSC Pharmacy from commercial distributors and were re-packaged by JSC pharmacists to conserve up mass and volume. All medication doses were part of the ISS crew medical kit and were transported to the International Space Station (ISS) via NASA's Shuttle Transportation System (Space Shuttle). After 568 days of storage, the medications were removed from the supply chain and returned to Earth on a Dragon (SpaceX) capsule. Upon return to Earth, medications were transferred to temperature and humidity controlled environmental chambers until analysis. Nine medications were chosen on the basis of their availability for study. The medications included several of the most heavily used by US crewmembers: 2 sleep aids, 2 antihistamines/decongestants, 3 pain relievers, an antidiarrheal and an alertness medication. Each medication was available at a single time point; analysis of the same medication at multiple time points was not possible. Because the samples examined in this study were obtained opportunistically from medical supplies, there were no control samples available (i.e. samples aged for a similar period of time on the ground); a significant limitation of this study. Medications were analyzed using the HPLC/MS methods described in the United States Pharmacopeia (USP) to measure the amount of intact active ingredient, identify degradation products and measure their amounts. Some analyses were conducted by an independent analytical laboratory, but certain (Schedule) medications could not be shipped to their facility and were analyzed at JSC. RESULTS Nine medications were analyzed with respect to active pharmaceutical ingredient (API) and degradant amounts. Results were compared to the USP requirements for API and degradants/impurities content for every FDA-approved medication. One medication met USP requirements at 5 months after its expiration date. Four of the nine (44% of those tested) medications tested met USP requirements up to 8 months post-expiration. Another 3 medications (33% of those tested) met USP guidelines 2-3 months before expiration. One medication, a compound classed by the FDA as a dietary supplement and sometimes used as a sleep aid, failed to meet USP requirements at 11 months post-expiration. CONCLUSION Analysis of each medication at a single time point provides limited information on the stability of a medication stored in particular conditions; it is not possible to predict how long a medication may be safe and effective from these data. Notwithstanding, five of the nine medications tested (56%) met USP requirements for API and degradants/impurities at least 5 months past expiration dates. The single compound that failed to meet USP requirements is not regulated as strictly as prescription medications are during manufacture; it is unknown if this medication would have met the requirements prior to flight. Notably, it was the furthest beyond its expiration date. Only more comprehensive analysis of flight-aged samples compared to appropriate ground controls will permit determination of spaceflight effects on medication stability.

Wotring, V. E.↗
NASA NTRS2019

Prototyping Operational Autonomy for Space Traffic Management

Current state of the art in Space Traffic Management (STM) relies on a handful of providers for surveillance and collision prediction, and manual coordination between operators. Neither is scalable to support the expected 10x increase in spacecraft population in less than 10 years, nor does it support automated manuever planning. We present a software prototype of an STM architecture based on open Application Programming Interfaces (APIs), drawing on previous work by NASA to develop an architecture for low-altitude Unmanned Aerial System Traffic Management. The STM architecture is designed to provide structure to the interactions between spacecraft operators, various regulatory bodies, and service suppliers, while maintaining flexibility of these interactions and the ability for new market participants to enter easily. Autonomy is an indispensable part of the proposed architecture in enabling efficient data sharing, coordination between STM participants and safe flight operations. Examples of autonomy within STM include syncing multiple non-authoritative catalogs of resident space objects, or determining which spacecraft maneuvers when preventing impending conjunctions between multiple spacecraft. The STM prototype is based on modern micro-service architecture adhering to OpenAPI standards and deployed in industry standard Docker containers, facilitating easy communication between different participants or services. The system architecture is designed to facilitate adding and replacing services with minimal disruption. We have implemented some example participant services (e.g. a space situational awareness provider/SSA, a conjunction assessment supplier/CAS, an automated maneuver advisor/AMA) within the prototype. Different services, with creative algorithms folded into then, can fulfil similar functional roles within the STM architecture by flexibly connecting to it using pre-defined APIs and data models, thereby lowering the barrier to entry of new players in the STM marketplace. We demonstrate the STM prototype on a multiple conjunction scenario with multiple maneuverable spacecraft, where an example CAS and AMA can recommend optimal maneuvers to the spacecraft operators, based on a predefined reward function. Such tools can intelligently search the space of potential collision avoidance maneuvers with varying parameters like lead time and propellant usage, optimize a customized reward function, and be implemented as a scheduling service within the STM architecture. The case study shows an example of autonomous maneuver planning is possible using the API-based framework. As satellite populations and predicted conjunctions increase, an STM architecture can facilitate seamless information exchange related to collision prediction and mitigation among various service applications on different platforms and servers. The availability of such an STM network also opens up new research topics on satellite maneuver planning, scheduling and negotiation across disjoint entities.

space traffic management↗
DOE OSTI2026

Flaw Tolerance Assessment for DOE Standard SNF Dry Storage Canisters - 26550

The U.S. DOE has designed four spent nuclear fuel (SNF) dry storage canisters for storing DOE standardized SNFs. The DOE standard canisters are cylindrical shells with a diameter of 24 inches (610 m) or 18 inches (457 m), a wall thickness of 0.5 inches (12.7 m) or 0.375 inches (9.53 m), and a length of 15 feet (4.57 m) or 10 feet (3.05 m). These DOE canister geometries are completely different from commercial canisters. The latter may experience chloride-induced stress cracking corrosion (CI-SCC) because they are stored near coastal regions. The former may not experience CI-SCC but face different challenges because they are stored in the SNF storage facilities. Because of large residual stresses, mechanical flaws may occur in the DOE canisters during long-distance transportation or lifting handling. To date, only limited structural integrity analyses were carried out through drop tests on the DOE canisters, but a more general flaw tolerance assessment has not been performed. Therefore, the failure assessment diagram (FAD)-based fracture mechanics method, as codified by the latest API 579-1/ASME FFS-1-2021 Edition, is adopted in this work to assess surface flaw tolerance for DOE canisters under operation loading and welding residual stresses (WRS), where the new code-recommended WRS distributions are used. To more adequately consider the transverse distribution of WRS, an equivalent WRS distribution is proposed to account for the WRS reduction with distance from the weld centerline. Moreover, the closed-form solutions of stress intensity factor K, which serves as the crack driving force during subcritical crack growth, are developed from the tabular data of the K factors provided in API 579-1/ASME FFS-1 and used to determine more accurate flaw sizes at flaw instability. Subsequently, the Level 2 assessment procedures with 12 assessment steps, as codified and detailed in API 579-1 and ASME FFS-1, are followed to assess the flaw tolerance for the surface flaws in the DOE standard canisters with consideration of normal or accident operation loads combined with WRS. The assessment results show that the four designs of DOE standard canisters can tolerate all surface flaws that meet the code permitted maximum sizes of a flaw length of 8 inches (i.e., 200 mm) and a flaw depth of 80% wall thickness. This demonstrates that all designs of DOE standard canisters are robust and reliable.

DOE standard canister↗
DOE OSTI2026

Associated Particle Imaging of Neutron Inelastic Scatter: 3-D Reconstruction, Capabilities, and Challenges

Associated particle imaging (API) offers unique advantages for 3-D imaging of neutron inelastic scatter, including single-view tomographic imaging and data acquisition when access is limited to only one side of the interrogated object. However, widespread adoption of neutron inelastic scatter imaging has been impeded by several inherent challenges, most prominently spatial resolution, self-attenuation, and statistical noise. Here, in this work, the capabilities and challenges of neutron inelastic scatter imaging are investigated. Instead of focusing on a single imaging application, we identify imaging principles that hold for various neutron inelastic scatter imaging techniques. The primary challenges for 3-D imaging are characterized. The inherent spatial resolution in the time-of-flight (TOF) dimension is derived based on the known system timing resolution and scan geometry. Three reconstruction algorithms are described and demonstrated, including the introduction of modern iterative reconstruction incorporating a physics-based system model. Simulation is leveraged to demonstrate imaging capability with varying coincidence count levels and system timing resolution. An example of measured data with both back-scatter and forward-scatter detector positioning is presented. System design characteristics and their effects on image quality are identified. The imaging framework presented in this article has the potential to facilitate growth of 3-D neutron inelastic scatter API by identifying applications that are a good match for the technique and by targeting system development resources toward the requirements of a specific imaging task.

Associated particle imaging (API)↗
NASA NTRS2018

Accessing Data Stored in Amazon S3 Using the Hyrax OPeNDAP Server

For three years we have been investigating data storage and retrieval in the Amazon Cloud, striving to optimize both storage structures and (cache-enhanced retrieval processes. These optimizations are hidden from data users, who simply employ the Data Access Protocol (DAP), a popular, Web-based Application Programmer Interface (API) developed by OPeNDAP. We present our collected findings and their realization in the Hyrax data server. Specific techniques include caching data on spinning disk; accessing sharded data in place; optimizing the organizational structures for data within the flat key-value space of Simple Storage Service (S3); and employing an API extension that permits simultaneous operations on many datasets in a single request.

Data access↗
NASA NTRSDate not supplied

Development of Improved Thermal Analysis Capabilities at the NASA Goddard Space Flight Center

Goddard Space Flight Center (GSFC) has been developing a framework of additional analysis capabilities to aid in the verification, development, and execution of thermal models using the OpenTD Application Programming Interface (API). This paper provides a brief overview of the data structures, properties, methods, and relationships between the objects accessible through the current API and describes some of the algorithms necessary to implement the desired functions at GSFC. Some example code snippets are also provided to aid potential users in the development of their own utilities. Following the overview are descriptions and algorithm methodologies of the new capabilities added to the GSFC framework, including: a new PI heater/controller approach for improved steady state predictions, selective copying of symbol over-rides from one source CaseSet to destination CaseSet(s), comparison of submodel object counts between a source and destination model to verify model integration, comparison of thermo-optical and thermo-physical properties between models, and improved display of extracted thermo-optical and thermo-physical properties for documentation.

ThermalDesktop↗
NASA NTRSDate not supplied

Development of Improved Thermal Analysis Capabilities at the NASA Goddard Space Flight Center

Goddard Space Flight Center (GSFC) has been developing a framework of additional analysis capabilities to aid in the verification, development, and execution of thermal models using the OpenTD Application Programming Interface (API). This paper provides a brief overview of the data structures, properties, methods, and relationships between the objects accessible through the current API and describes some of the algorithms necessary to implement the desired functions at GSFC. Some example code snippets are also provided to aid potential users in the development of their own utilities. Following the overview are descriptions and algorithm methodologies of the new capabilities added to the GSFC framework, including: a new PI heater/controller approach for improved steady state predictions, selective copying of symbol over-rides from one source CaseSet to destination CaseSet(s), comparison of submodel object counts between a source and destination model to verify model integration, comparison of thermo-optical and thermo-physical properties between models, and improved display of extracted thermo-optical and thermo-physical properties for documentation.

ThermalDesktop, API, v6.2, OpenTD↗
DOE OSTI2025

Bridging paradigms: Designing for HPC-Quantum convergence

Here, this paper presents a comprehensive software stack architecture for integrating quantum computing (QC) capabilities with High-Performance Computing (HPC) environments. While quantum computers show promise as specialized accelerators for scientific computing, their effective integration with classical HPC systems presents significant technical challenges. We propose a hardware-agnostic software framework that supports both current noisy intermediate-scale quantum devices and future fault-tolerant quantum computers, while maintaining compatibility with existing HPC workflows. The architecture includes a quantum gateway interface, standardized APIs for resource management, and robust scheduling mechanisms to handle both simultaneous and interleaved quantum–classical workloads. Key innovations include: (1) a unified resource management system that efficiently coordinates quantum and classical resources, (2) a flexible quantum programming interface that abstracts hardware-specific details, (3) A Quantum Platform Manager API that simplifies the integration of various quantum hardware systems, and (4) a comprehensive tool chain for quantum circuit optimization and execution. We demonstrate our architecture through implementation of quantum–classical algorithms, including the variational quantum linear solver, showcasing the framework’s ability to handle complex hybrid workflows while maximizing resource utilization. This work provides a foundational blueprint for integrating QC capabilities into existing HPC infrastructures, addressing critical challenges in resource management, job scheduling, and efficient data movement between classical and quantum resources.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

dCache project status and update

The dCache project delivers an open-source, massively scalable, distributed storage system deployed internationally to satisfy today’s scientists’ ever-demanding storage requirements. Its multifaceted approach supports different use cases with the same storage, from high throughput data ingest, data sharing over wide area networks, efficient access from HPC clusters, and longterm data persistence on tertiary storage. Even though dCache was initially developed for HEP experiments, today, it is used by various scientific communities, including astrophysics, biomed, and life science, each with their specific requirements. To match the needs of these new communities and keep up with the scaling demands of existing experiments, dCache is permanently evolving. With this contribution, we would like to highlight the recent developments in dCache regarding integration with CERN Tape Archive (CTA), advanced metadata handling, token-based authorization support, bulk API for QoS transitions, REST API to control interaction with the tape system, and future development directions.

Mkrtchyan, Tigran [DESY]↗
DOE OSTI2024

Forte: A suite of advanced multireference quantum chemistry methods

Software development plays a critical role in advancing quantum chemistry, enabling the exploration of new fundamental theoretical ideas and modeling systems of ever-increasing complexity. In the past decade, the availability of quantum chemistry packages that use modular designs and provide application programming interfaces (APIs) has enabled the creation of specialized software plugins, enhancing the capabilities of the original codes. Here, the availability of well-documented APIs is particularly beneficial in the context of academic scientific software development because it reduces the entry barrier for new developers and shields them from the complexities of large software projects.

74 ATOMIC AND MOLECULAR PHYSICS↗
DOE OSTI2024

SEAS Communication Engine: An Extensible, Flexible Wrapper for Co-Simulation Agents

When modeling and analyzing the power grid and other large scale systems, researchers often express scenarios as optimization problems and feed them into advanced software solvers. In order to allow multiple solvers to communicate with each other and share data from different domains, the National Renewable Energy Laboratory (NREL) and associated Department of Energy (DOE) labs have developed a software framework called the Hierarchical Engine for Large-scale Infrastructure Co-Simulation (HELICS). HELICS allows cosimulation via a collection of client libraries for different languages that can be called from the appropriate optimization software. However, these client libraries do not provide a higher level of abstraction beyond reading and writing data off of the shared HELICS bus. In this paper, we describe a new software library called the SEAS Communication Engine that exposes a higher-level API for running cosimulation problems. The SEAS Engine provides a class-based abstraction on top of the Python HELICS client, in order to allow users to implement their domain-specific cosimulations without needing to interact with core HELICS primitives. This will make adoption of HELICS and cosimulation in general easier, by exposing a simpler API. In the second part of the paper, we validate our library on a collection of different simulation examples, including the canonical IEEE 13 Bus Feeder. Lastly, we demonstrate using the SEAS Engine to directly call domain-specific code written in the Julia programming language. Our hope is that this will serve as a template for easily calling software in different programming languages via the SEAS Engine, thereby avoiding code duplication and complexity.

co-simulation↗
DOE OSTI2026

Review of Particle Physics

The Review summarizes much of particle physics and cosmology. Using data from previous editions, plus 3,200 new measurements from 903 papers, we list, evaluate, and average measured properties of gauge bosons and the recently discovered Higgs boson, leptons, quarks, mesons, and baryons. We summarize searches for hypothetical particles such as supersymmetric particles, heavy bosons, axions, dark photons, etc. Particle properties and search limits are listed in Summary Tables. We give numerous tables, figures, formulae, and reviews of topics such as Higgs Boson Physics, Supersymmetry, Grand Unified Theories, Neutrino Mixing, Dark Energy, Dark Matter, Cosmology, Particle Detectors, Colliders, Probability and Statistics. Most of the 118 reviews are updated, including many that are heavily revised.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2026

The LCLStream Ecosystem for Multi-Institutional Dataset Exploration

We describe a new end-to-end experimental data streaming framework designed from the ground up to support new types of applications – AI training, extremely high-rate X-ray time-of-flight analysis, crystal structure determination with distributed processing, and custom data science applications and visualizers yet to be created. Throughout, we use design choices merging cloud microservices with traditional HPC batch execution models for security and flexibility. This project makes a unique contribution to the DOE Integrated Research Infrastructure (IRI) landscape. By creating a flexible, API-driven data request service, we address a significant need for high-speed data streaming sources for the X-ray science data analysis community. With the combination of data request API, mutual authentication web security framework, job queue system, high-rate data buffer, and complementary nature to facility infrastructure, the LCLStreamer framework has prototyped and implemented several new paradigms critical for future generation experiments.

Rogers, David [ORNL] (ORCID:0000000251871768)↗
DOE OSTI2025

omni-engineer-lbl (omni) v0.5

This is a fork of the omni-engineer software developed by Pietro Schirano. My collaborators and I are altering the software to work better with our LBNL infrastructure and requirements. The software is a coding agent wrapper around LLM model APIs, and can use any of the APIs provided by LBNL's CBorg service, or any service that uses an OpenAI endpoint(s).

Fong, Timothy [Lawrence Berkeley National Laborato↗
DOE OSTI2025

extapi-acsys

Provides public APIs to the Fermilab control system. This service exposes several GraphQL endpoints for various, logical APIs that clients may use to retrieve control system data and, in some cases, make changes to the control system. This service is currently running on acsys-proxy.fnal.gov on port 8000 with the development instance on port 8001. The middle layer of the control system uses gRPCs for communications. The GraphQL resolvers of this service use various gRPC services to obtain the information that is returned. This uses the async-graphql and warp crates to provide GraphQL over http support. The resolvers use the tonic crate for gRPC client support.

Neswold, Rich [Fermi National Accelerator Laborato↗
DOE OSTI2025

BATMODS-lite [SWR-25-108]

Battery Analysis and Training Models for Optimization and Design Studies (BATMODS) is a Python package with an API for pre-built battery models. The original purpose of the package was to quickly generate synthetic data for machine learning models to train with. However, the models are generally useful for any battery simulations or analysis. BATMODS-lite includes the following: 1) A library and API for pre-built battery models 2) Kinetic/transport properties for common battery materials

Randall, Corey [National Laboratory of the Rockies↗