Engineering PapersSearch

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 19 records

Interoperable Map Services with Performance Tuning for Earth Science Data through API-Tiles and Dynamic API-Styles

NASA’s Goddard Earth Sciences Data and Information Services Center (GES DISC) provides access to a wide range of global climate data from various satellite missions and models. However, the visualization and analysis of these data can be challenging due to their large volume, complex structure, and diverse formats. This study presents the implementation of interoperable map services (API-Maps) with performance tuning using API-Tiles and dynamic API-Styles. API-Maps is a standard for defining and exposing map services through RESTful (representational state transfer) APIs (application programming interfaces). API-Tiles is a technique for generating and delivering map tiles on demand from any data source. API-Styles is a method for dynamically applying styles to map tiles based on user preferences or data attributes. The use of API-Tiles and dynamic API-Styles enhances the performance and scalability of the map services, allowing for smooth and interactive visualization of large datasets. Two types of Earth Science data sources from the NASA GES DISC are used in the experiment: regularly gridded data, such as Global Precipitation Measurement (GPM) precipitation data, and low processing level data, such as low-level data of atmospheric composite measurements from the TROPOspheric Monitoring Instrument (TROPOMI) mission. Re-gridding of swath data (low level data - e.g. Level 2) of atmospheric composites (e.g. TROPOMI products, such as nitrogen dioxide, ozone and aerosol optical depth) is applied to enable the Web-based, interoperable, tiled, and styled mapping (rendering) services of such data. The results demonstrate the effectiveness of the proposed approach in providing fast and efficient access to Earth science data through interoperable map services.

Geographic Information System

rcsb-api : Python Toolkit for Streamlining Access to RCSB Protein Data Bank APIs

The Protein Data Bank (PDB) was founded in 1971 as the first open-access digital data resource in biology to serve as the single global archive for three-dimensional (3D) macromolecular structure data. Current PDB holdings exceed 230,000 experimentally determined structures of proteins, nucleic acids, viruses, and macromolecular machines. The RCSB Protein Data Bank RCSB.org research-focused web portal facilitates search, analyses, and visualization of every PDB structure along with more than one million Computed Structure Models from AlphaFold DB and the ModelArchive. It is powered by a set of publicly available Application Programming Interfaces (APIs) that both support RCSB.org users and provide programmatic access to PDB data. Given the breadth and levels of granularity encompassed in this rich data collection, efficiently accessing the information programmatically may be challenging for new users. RCSB PDB has developed a Python software package, rcsb-api , that facilitates easy and efficient use of RCSB PDB APIs within a Python environment. This software tool is designed to streamline access to the extensive corpus of data housed within the PDB, enabling researchers to search, retrieve, and analyze 3D biostructure data seamlessly. Its use will accelerate research in structural biology, molecular biology and biochemistry, drug discovery, and bioinformatics by providing more efficient tools for data integration and analysis. The new toolkit is available on GitHub (github.com/rcsb/py-rcsb-api) and published to the public Python package repository (PyPI) to foster wider usage and support basic and applied research in fundamental biology, biomedicine, and the energy sciences.

FAIR principles

Use of Assistive Technology to Augment API Capabilities

Application Programming Interfaces (APIs) allow for access to data and capabilities of computer applications by developers or users with experience in computer programming. Recent development with both Thermal Desktop and ESATAN-TMS have provided APIs to allow users to develop their own capabilities that interface with the Graphical User Interfaces (GUI) or manipulate the thermal model data. However, these APIs are only as good as the breadth of features in the native code accessible through the API. If a particular code’s feature is not accessible through the API, then users have very limited options besides waiting for updates to the API that expose the necessary functionality, particularly if model data access or user action, such as a button click, is required. However, Assistive Technology features that allow for users with a disability to more fully experience a software’s capabilities may be creatively utilized to gain further access to data and capabilities not yet exposed by the API. This paper describes the process to augment the features of the OpenTD API via assistive technology and describes how to identify the application instance, navigate GUI elements, updates values on forms, and execute actions such as selecting a listbox item or clicking a button. It concludes with identifying some of the pitfalls to avoid and describes methods to best implement this approach.

Application Programming Interface

Use of Assistive Technology to Augment API Capabilities

Application Programming Interfaces (APIs) allow for access to data and capabilities of computer applications by developers or users with experience in computer programming. Recent development with both Thermal Desktop and ESATAN-TMS have provided APIs to allow users to develop their own capabilities that interface with the Graphical User Interfaces (GUI) or manipulate the thermal model data. However, these APIs are only as good as the breadth of features in the native code accessible through the API; if a particular code’s feature is not accessible through the API, then users have very limited options besides waiting for updates to the API that expose the necessary functionality, particularly if model data access or user action, such as a button click, is required. However, Assistive Technology features that allow for differently-abled users to more fully experience a software’s capabilities may be creatively utilized to gain further access to data and capabilities not yet exposed by the API. This paper describes the process to augment the features of the OpenTD API via assistive technology and describes how to identify the application instance, navigate GUI elements, updates values on forms, and execute actions such as selecting a listbox item or clicking a button. It concludes with identifying some of the pitfalls to avoid and describes methods to best implement this approach.

Application Programming Interface

PrismTech Data Distribution Service Java API Evaluation

My internship duties with Launch Control Systems required me to start performance testing of an Object Management Group's (OMG) Data Distribution Service (DDS) specification implementation by PrismTech Limited through the Java programming language application programming interface (API). DDS is a networking middleware for Real-Time Data Distribution. The performance testing involves latency, redundant publishers, extended duration, redundant failover, and read performance. Time constraints allowed only for a data throughput test. I have designed the testing applications to perform all performance tests when time is allowed. Performance evaluation data such as megabits per second and central processing unit (CPU) time consumption were not easily attainable through the Java programming language; they required new methods and classes created in the test applications. Evaluation of this product showed the rate that data can be sent across the network. Performance rates are better on Linux platforms than AIX and Sun platforms. Compared to previous C++ programming language API, the performance evaluation also shows the language differences for the implementation. The Java API of the DDS has a lower throughput performance than the C++ API.

Riggs, Cortney

Standardized Protocol for Real-Time APIs as Required by Title 23 CFR 680.116(c)

Improving the ability of drivers to easily locate working and available chargers is key to improving the public charging experience. Electric vehicle charging providers who are recipients of federal funds through the National Electric Vehicle Infrastructure (NEVI) Formula Program, Charging and Fueling Infrastructure (CFI) Discretionary Grant Program, and other funding programs as identified under Title 23 of the U.S. Code must deploy and maintain an application programming interface (API) to access information about charging stations they operate.1 This includes information about individual charging ports, pricing, and availability in accordance with the Federal Highway Administration’s National Electric Vehicle Infrastructure Standards and Requirements, 23 CFR 680.116(c), herein referred to as the minimum standards (Federal Highway Administration 2023). Specifically outlined in the minimum standards, states and other designated recipients are required to ensure that charging station information including location, connector type, power level, real-time status, and real-time price to charge are available free of charge to third-party software developers through an API. These requirements are intended to enable effective communication with consumers about available charging stations and help consumers make informed decisions about trip planning, including when and where to charge. This document provides a standardized protocol for how to structure data, data update frequency, and practices for making the data required to be shared via API usable for improving public transparency and the customer experience. These are recommendations only and do not modify the Federal Highway Administration’s minimum standards in any way.

33 ADVANCED PROPULSION SYSTEMS

Improving Access to the GEOS Composition Forecast Model with API Development and Ingestion into Google Earth Engine

The GEOS Composition Forecast (GEOS-CF) model produces forecast and historical estimates of atmospheric composition and meteorology fields, which provide useful insight into air quality issues and events. In a year for which Canadian wildfires created adverse air quality conditions in the eastern United States, access to model fields such as PM2.5 are in high demand. The GEOS-CF team at the NASA Global Modeling and Assimilation Office (GMAO) first developed in-house solutions to improve data access via the CF API, and recently partnered with Google to ingest a collated set of model diagnostics into the Google Earth Engine (GEE) data repository. GEOS-CF model output is also being ingested into AWS storage. Creating these various open access points to GEOS-CF model diagnostics provides the public with an opportunity to easily interact with air quality information. Users are able to use a temporally consistent global grid of air quality fields in machine learning applications, mapping tools, and data informatics. Hosting GEOS-CF forecasts and the historical timeseries of these chemistry and meteorology fields in GEE allows users to create dynamic JavaScript-based air quality applications in the GEE code editor. GEOS-CF users can also access the model output via the GEE Python application programming interface (API), making it easy to perform various analyses with Python. This presentation will show two examples of accessing the GEOS-CF model through GEE. The first is an example application made in the GEE code editor which allows users to view time series plots and downscaled maps of surface level NO2. The second example exhibits using the GEE Python API to create a machine learning model to temporally gap-fill between air quality observations. These examples are an introduction to the many possible benefits of having open access to the GEOS-CF model through multiple platforms.

Callum Wayman

The TOLNet 2.0 Website: How an API Can Promote Open Science and FAIR Principles

The Tropospheric Ozone Lidar Network (TOLNet) has generated over a decade of ozone vertical profile data products over North America. The science value of the TOLNet data has been demonstrated in numerous peer-reviewed publications on air quality and other ozone relevant research. To support the broad spectrum of data use, the TOLNet team launched a major effort to upgrade the web-based data repository aiming to enhance the data discoverability and to enable machine-to-machine data upload and download processes. Specifically, the TOLNet website included an application programming interface (API), which supports machine-to-machine data search and data download. The API also extracts selected variables from the files, which can be retrieved as JSON objects and used to create data displays without having to download or open the underlying files. The TOLNet science team members can also use the API for automated data upload, including a data file scanning feature to ensure data product integrity. To be presented will include a summary of key features of data repositories, an actual use case of machine-to-machine data access/use, as well as our journey to make TOLNet data more FAIR, i.e., more findable, accessible, interoperable, and (re)usable.

Crystal Gummo

Improving Access to the GEOS Composition Forecast Model with API Development and Ingestion into Google Earth Engine

The GEOS Composition Forecast (GEOS-CF) model produces forecast and historical estimates of atmospheric composition and meteorology fields, which provide useful insight into air quality issues and events. In a year for which Canadian wildfires created adverse air quality conditions in the eastern United States, access to model fields such as PM2.5 are in high demand. The GEOS-CF team at the NASA Global Modeling and Assimilation Office (GMAO) first developed in-house solutions to improve data access via the CF API, and recently partnered with Google to ingest a collated set of model diagnostics into the Google Earth Engine (GEE) data repository. GEOS-CF model output is also being ingested into AWS storage. Creating these various open access points to GEOS-CF model diagnostics provides the public with an opportunity to easily interact with air quality information. Users are able to use a temporally consistent global grid of air quality fields in machine learning applications, mapping tools, and data informatics. Hosting GEOS-CF forecasts and the historical timeseries of these chemistry and meteorology fields in GEE allows users to create dynamic JavaScript-based air quality applications in the GEE code editor. GEOS-CF users can also access the model output via the GEE Python application programming interface (API), making it easy to perform various analyses with Python. This presentation will show two examples of accessing the GEOS-CF model through GEE. The first is an example application made in the GEE code editor which allows users to view time series plots and downscaled maps of surface level NO 2 . The second example exhibits using the GEE Python API to create a machine learning model to temporally gap-fill between air quality observations. These examples are an introduction to the many possible benefits of having open access to the GEOS-CF model through multiple platforms.

Callum Wayman

QSPIN: A High Level Java API for Quantum Computing Experimentation

QSPIN is a high level Java language API for experimentation in QC models used in the calculation of Ising spin glass ground states and related quadratic unconstrained binary optimization (QUBO) problems. The Java API is intended to facilitate research in advanced QC algorithms such as hybrid quantum-classical solvers, automatic selection of constraint and optimization parameters, and techniques for the correction and mitigation of model and solution errors. QSPIN includes high level solver objects tailored to the D-Wave quantum annealing architecture that implement hybrid quantum-classical algorithms [Booth et al.] for solving large problems on small quantum devices, elimination of variables via roof duality, and classical computing optimization methods such as GPU accelerated simulated annealing and tabu search for comparison. A test suite of documented NP-complete applications ranging from graph coloring, covering, and partitioning to integer programming and scheduling are provided to demonstrate current capabilities.

Quantu

Evaluation of Maximum Allowable Working Pressure and Svensson Burst Pressure Recommended in API 579-1 2021 Edition

Abstract API 579-1/ASME FFS-1 2021 Edition provides the minimum wall thickness, the maximum allowable working pressure (MAWP), and the membrane stress equations for thin and thick-walled cylindrical shells subject to internal pressure in Section 2C.3.3.1 of Appendix 2C – Thickness, MAWP, and Stress Equations for an FFS Assessment. The minimum wall thickness and MAWP are determined using the hoop stress and the Tresca yield criterion. Section 2C.7 – Estimation of Burst Pressure newly added the Svensson method for calculating burst pressure of cylindrical shells under internal pressure, where the plastic yielding is characterized by the von Mises yield criterion. For thin-walled cylinders, the von Mises flow solution of burst pressure in Equation (2C.179) was recommended. For thick-walled cylinders, an implicit burst pressure solution in an integral equation (2C.176) was recommended. But this integral equation is inconvenient to use in practice. It is well known that the classic plasticity theory includes the Tresca and von Mises yield criteria, with the Tresca criterion predicting a lower bound solution and the von Mises criteria predicting an upper bound solution. In addition, the present author developed an average shear stress yield criterion that can determine more accurate limit and burst pressures for thin and thick-walled cylinders. This work uses these three yield criteria to evaluate the minimum required wall thickness, MAWP and Svensson burst pressure recommended in the API 579 code.

burst pressure

hybridlane (fka CV-DV Quantum Circuit API)

This software package will abstract building a CV-DV quantum circuit for simulation and running on hardware. Existing simulation software each has their own API. This software intends to define a common API to be executed on several simulation and physical hardware backends.

Stavenger, Tim [Pacific Northwest National Laborat

RouteE API

This is the API endpoint for RouteE energy prediction, which can be used to get both single vehicle link or route energy estimates and transportation network-wide energy consumption estimates for a variety of vehicles. This enables external researchers and transportation engineers to access and utilize NLR's growing library of pre-trained vehicle models for prediction of transportation energy consumption. This API provides three endpoints: - /route: Energy estimation of a vehicle over a planning link or sequence of links (route). - /network: Network-wide estimation of energy consumption for all vehicle traffic in the desired area. - /compass: Energy-optimal “eco-routing” between input origin and destination coordinates (Currently in beta for Denver metro area only).

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI

Beginning the 21st century with advanced Automatic Parts Identification (API)

Under the direction of the NASA George C. Marshall Space Flight Center, Huntsville, Alabama, the development and commercialization of an advanced Automated Parts Indentification (API) system is being undertaken by Rockwell International Corporation. The new API system is based on a variable sized, machine-readable, two-dimensioanl matrix symbol that can be applied directly onto most metallic and nonmetallic materials using safe, permanent marking methods. Its checkerboard-like structure is the most space efficient of all symbologies. This high data-density symbology can be applied to products of different material sizes and geometries using application-dependent, computer-driven marking devices. The high fidelity markings produced by these devices can then be captured using a specially designed camera linked to any IBM-compatible computer. Applications of compressed symbology technology will reduce costs and improve quality, productivity, and processes in a wide variety of federal and commercial applications.

Schramm, Fred

Heat Analysis Manager (HAM), a Thermal Desktop API Based Heat Map Generation Software

Thermal engineers often create custom heat maps to analyze their thermal model. However, generating a heat map is difficult because thermal simulation only readily provide attributes of simulated nodes such as temperature, capacitance, heat generation, and a network of conductances. Heat flow values are a derived quantity from the nodal attributes, and the data processing and management of heat flow between nodes quickly become difficult for large models. Deriving a network of heat flow values requires vast amount of calculations and data handling, heat map generation process generally suffers from processing speed, loss of accuracy, and/or presentation of data in a useful format. Heat Analysis Manager (HAM) is a Thermal Desktop (TD) based free multi-purpose tool developed to aid thermal engineers in analyzing their thermal model, including a heat map generation functionality. HAM’s heat map generator retains accuracy and fast processing speed by utilizing TD’s application programming interface (API) and built-in TD’s “Qflow from Results.” Furthermore, HAM’s heat map output is presented in an easily customizable format in Excel, allowing users to create various custom visual heat maps. A full description of how HAM utilizes TD’s API to create a customizable heat map is provided. A simple model demonstration is included along with step-by-step procedures on creating custom heat maps. HAM’s heat map result has been verified against TD’s and other heat map generation software, and verification methods are also included.

Thermal desktop

Evaluation of Maximum Allowable Working Pressure and Svensson Burst Pressure Recommended in API 579-1 2021 Edition

ABSTRACT API 579-1/ASME FFS-1 2021 Edition provides the minimum wall thickness, the maximum allowable working pressure (MAWP), and the membrane stress equations for thin and thick-walled cylindrical shells subject to internal pressure in Section 2C.3.3.1 of Appendix 2C – Thickness, MAWP, and Stress Equations for an FFS Assessment. The minimum wall thickness and MAWP are determined using the hoop stress and the Tresca yield criterion. Section 2C.7 – Estimation of Burst Pressure newly added the Svensson method for calculating burst pressure of cylindrical shells under internal pressure, where the plastic yielding is characterized by the von Mises yield criterion. For thin-walled cylinders, the von Mises flow solution of burst pressure in Equation (2C.179) was recommended. For thick-walled cylinders, an implicit burst pressure solution in an integral equation (2C.176) was recommended. But this integral equation is inconvenient to use in practice. It is well known that the classic plasticity theory includes the Tresca and von Mises yield criteria, with the Tresca criterion predicting a lower bound solution and the von Mises criteria predicting an upper bound solution. In addition, the present author developed an average shear stress yield criterion that can determine more accurate limit and burst pressures for thin and thick-walled cylinders. This work uses these three yield criteria to evaluate the minimum required wall thickness, MAWP and Svensson burst pressure recommended in the API 579 code.

burst pressure

Real World Uses For Nagios APIs

This presentation describes the Nagios 4 APIs and how the NASA Advanced Supercomputing at Ames Research Center is employing them to upgrade its graphical status display (the HUD) and explain why it's worth trying to use them yourselves.

Real World

How to Invoke a REST API with DIP

The Digital Information Platform (DIP) REST API guidance document instructs users how to collaborate with DIP and provide information necessary for sub-project success and fruitful partnership collaboration during data exchange.

Digital Information Platform