Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software interfaces”

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 1,225 records · Page 68
All sourcesNASA NTRSDOE OSTI
DOE OSTI2021

Enabling Scalable and Extensible Memory-mapped Datastores in Userspace

Exascale workloads are expected to incorporate data-intensive processing in close coordination with traditional physics simulations. These emerging scientific, data-analytics and machine learning applications need to access a wide variety of datastores in flat files and structured databases. Programmer productivity is greatly enhanced by mapping datastores into the application process's virtual memory space to provide a unified “in-memory” interface. Currently, memory mapping is provided by system software primarily designed for generality and reliability. However, scalability at high concurrency is a formidable challenge on exascale systems. Also, there is a need for extensibility to support new datastores potentially requiring HPC data transfer services. In this article, we present UMap , a scalable and extensible userspace service for memory-mapping datastores. Furthermore, through decoupled queue management, concurrency aware adaptation, and dynamic load balancing, UMap enables application performance to scale even at high concurrency. We evaluate UMap in data-intensive applications, including sorting, graph traversal, database operations, and metagenomic analytics. Our results show that UMap as a userspace service outperforms an optimized kernel-based service across a wide range of intra-node concurrency by 1.22-1.9 × . We performed two case studies to demonstrate UMap 's extensibility. First, a new datastore residing in remote memory is incorporated into UMap as an application-specific plugin. Second, we present a persistent memory allocator Metall built atop UMap for unified storage/memory.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

Extremum Seeking Library (ESL) v1.0

The software developed is a library for the Modelica language. The library includes different extremum seeking control algorithms and examples of possible usecases. It is also intended to export the models as so called Functional Mock-up Units, which are models supported by any kind of software which supports the Functional Mock-up Interface standard.

Mueller, Joscha↗
DOE OSTI2021

Building Performance Database API (BPD API) v2.1

The Building Performance Database (BPD) is the largest publicly-available source of measured energy performance data for buildings in the United States. It contains information about the building's energy use, location, and physical and operational characteristics. The BPD can be used by building owners, operators, architects and engineers to compare a building's energy efficiency against customized peer groups, identify energy efficiency opportunities, and set energy efficiency targets. It can also be used by energy efficiency program implementers and policymakers to analyze energy efficiency features and trends in the building stock. The BPD compiles data from various data sources, converts it into a standard format, cleanses and quality checks the data, and provides users with access to the data in a way that maintains anonymity for data providers. This software is the database and the Application Programming Interface (API). Users can utilize the BPD's data to develop their own applications using the API. Version 2.1 included a major update for multiple years of data and refactoring of code for faster queries.

Mathew, Paul↗
DOE OSTI2018

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↗
DOE OSTI2022

VizBrick

Brick (https://brickschema.org/) is a unified metadata schema to address the problem of building data standardization. Creating Brick models for building datasets means that the contents of the datasets are semantically described using the standard terms defined in the Brick ontology, and it will enable the benefits of data standardization, without having to recollect or reorganize the data. The challenge is that building brick models for building datasets leads to repeated manual trial and error processes, which can be time-consuming. VizBrick is a tool with a graphic/Web-based user interface that can assist users to create Brick models visually and interactively without having to understand the Resource Description Framework (RDF) syntax. VizBrick contains a web server that renders VizBrick web interface pages for browsers. The web server utilizes software components that (1) provide Brick ontology entity mapping to data column suggestions to users so that they can efficiently create their model; (2) provide keyword/Metadata-based search capability for easy find of relevant brick concepts and relations to their data columns

Lee, Sangkeun [Oak Ridge National Lab. (ORNL), Oak↗
DOE OSTI2024

nrelWattileExt (SkySpark Wattile Extension) [SWR-24-73]

The NREL Wattile extension, nrelWattileExt, provides an interface between SkySpark, an energy management and analytics software, and Wattile, an NREL-developed Python package for probabilistic prediction of building energy consumption. Wattile models predict discrete quantiles of the probability distribution of a target quantity (typically energy consumption) using the historical time series data from one or more predictors (typically weather data). Within SkySpark, predictions from Wattile models can be used for measurement & verification of building performance, detection of energy anomalies, and fault detection. Related to: https://github.com/NREL/Wattile

Frank, Stephen↗
DOE OSTI2018

Advanced Energy System Design (AESD): Technical Manual for the Records API

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 further clients. This minimalist API avoids imposing burdensome metadata, structural, or implementation requirements on developers by relying on open-source technologies that is readily available for common programming languages. In particular, the API has been designed to place the smallest 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 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.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

ExaSGD: 2022 Kernel Thrust Activities

The Kernel Thrust milestone ADSE22-407 covers the development of device-capable optimization algorithms and solvers technologies required by the ExaSGD project’s software stack in order to solve security-constrained alternating current optimal power flow (SC-ACOPF) problems on emerging exascale architectures. To this extent, in FY22 the main objective of the Kernel Thrust was (i) provide sparse optimization solver that runs efficiently on hardware accelerator devices (i.e., NVIDIA and AMD GPUs) to perform intra-node computations, (ii) strengthen the reliability and increase the performance of the mixed-dense sparse (MDS) solver of HiOp for deployment on the FY22 target architectures, Summit and Crusher, and (iii) increase performance by improving the mathematical algorithm and refining the parallel MPI-based implementation of the coarse-grain parallel solver HiOp-PriDec for capabilities deployment on the FY22 target architectures, Summit and Crusher. This document presents the developments and contributions done by the Kernels Thrust Team in FY22 toward completion of the above-mentioned objectives. These contributions progressed along four main development (sub)thrusts: (1) Design and implementation of a sparse optimization solver for use on hardware accelerators; (2) Improvement of the mathematical algorithm and of the parallel implementation of HiOp-PriDec to ensure readiness and efficient coarse-grain parallelism for FY23 target exascale machine; and (3) Support Software and Application Development Thrusts of the exaSGD project in their deployment of the project’s software stack on AMD- and NVIDIA-based architectures. The development of the sparse optimization solver (thrust 1 above) was new in FY22 and resulted in a new sparse solver in HiOp (available as of version 0.6). The second development thrust was a continuation of the efforts from FY21 and improved the mathematical algorithm and the communication strategy of the HiOp-PriDec solver. The last developement thrust is a large collaborative effort. Namely, the project’s teams from multiple labs (LLNL, PNNL, ORNL, and NREL) performed large-scale demonstration of the ExaSGD software stack, namely the optimization solvers of HiOp interfaced with the modeling front-end ExaGO and the stochastic sampler PowerScenarios. These demonstration efforts solved large-scale instances of the SC-ACOPF challenge problem of medium network sizes (10, 000-bus system) and large number of contingencies on Summit (NVIDIA accelerators) and Crusher (AMD accelerators) systems at ORNL.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

A Modeling Toolkit for Comparing AC and DC Electrical Distribution Efficiency in Buildings

Recently, there has been considerable research interest in the potential for DC distribution systems in buildings instead of the traditional AC distribution systems. Due to the need for performing power conversions between DC and AC electricity, DC distribution may provide electrical efficiency advantages in some systems. To support comparative evaluations of AC-only, DC-only, and hybrid AC/DC distribution systems in buildings, a new modeling toolkit called the Building Electrical Efficiency Analysis Model (BEEAM) was developed and is described in this paper. To account for harmonics in currents or voltages arising from nonlinear devices, the toolkit implements harmonic power flow, along with nonlinear device behavioral descriptions derived from empirical measurements. This paper describes the framework, network equations, device representations, and an implementation of the toolkit in an open source software package, including a component library and graphical interface for creating circuits. Simulations of electrical behavior and device and system efficiencies using the toolkit are compared with experimental measurements of a small office environment in a variety of operating and load configurations. A detailed analysis of uncertainty estimation is also provided. Key findings were that a comparison of predicted versus measured efficiencies and power losses in the validation testbed using the initial toolkit implementation predicted device- and system-level efficiencies with reasonably good accuracy under both balanced and unbalanced AC scenarios. An uncertainty analysis also revealed that the maximum estimated error for system efficiency across all scenarios was 3%, and measured and modeled system efficiency agreed within the experimental uncertainty in approximately half of the scenarios. Based on the correspondence between simulation and measurement, the toolkit is proposed by the authors as a potentially useful tool for comparing efficiency in AC, DC, and hybrid AC/DC distribution systems in buildings.

DC distribution↗
DOE OSTI2019

Core Cosmology Library: Precision Cosmological Predictions for LSST

The Core Cosmology Library (CCL) provides routines to compute basic cosmological observables to a high degree of accuracy, which have been verified with an extensive suite of validation tests. Predictions are provided for many cosmological quantities, including distances, angular power spectra, correlation functions, halo bias and the halo mass function through state-of-the-art modeling prescriptions available in the literature. Fiducial specifications for the expected galaxy distributions for the Large Synoptic Survey Telescope (LSST) are also included, together with the capability of computing redshift distributions for a user-defined photometric redshift model. A rigorous validation procedure, based on comparisons between CCL and independent software packages, allows us to establish a well-defined numerical accuracy for each predicted quantity. As a result, predictions for correlation functions of galaxy clustering, galaxy-galaxy lensing and cosmic shear are demonstrated to be within a fraction of the expected statistical uncertainty of the observables for the models and in the range of scales of interest to LSST. CCL is an open source software package written in C, with a python interface and publicly available at this https URL: https://github.com/LSSTDESC/CCL

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2019

Integration and Performance of New Technologies in the CMS Simulation [Slides]

CMS upgrade simulation for HL-LHC may be 2–3×slower than Run 2. CMS integration tests of GeantV met all goals: 1. Co-development ensured compatible threading models & interfaces, 2. Similar speedup measured in full experiment software framework, and 3. Efficient path to integration was established. GeantV prototype is a useful demonstrator. The next step is a GeantX project for HPCs w/ GPUs.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗
NASA NTRS1975

Development of the NASA VALT digital navigation system

The research to develop and fabricate a terminal area navigation system for use in the NASA VTOL Approach and Landing Technology (VALT) program. The results of that effort are reported. The navigation system developed and fabricated was based on a general purpose airborne digital computer. A set of flight hardware units was fabricated to create the necessary analog, digital and human interface with the computer. A comprehensive package of software was created to implement the control and guidance laws required for automatic and flight director approaches that are curved in two planes. A technique was developed that enables the generation of randomly shaped lateral paths from simple input data. The lateral path concept combines straight line and elliptical-curved segments to fit a continuous curved path to the data points. A simple, fixed base simulation was put together to assist in developing and evaluating the system. The simulation was used to obtain system performance data during simulated curved-path approaches.

Mcconnell, W. J., Jr.↗
NASA NTRS1976

Computer-aided design and computer science technology

A description is presented of computer-aided design requirements and the resulting computer science advances needed to support aerospace design. The aerospace design environment is examined, taking into account problems of data handling and aspects of computer hardware and software. The interactive terminal is normally the primary interface between the computer system and the engineering designer. Attention is given to user aids, interactive design, interactive computations, the characteristics of design information, data management requirements, hardware advancements, and computer science developments.

Fulton, R. E.↗
NASA NTRS1979

Wind tunnel real-time data acquisition system

The hardware configuration is described for the data acquisition system (DAS) which consists of an analog front end that can process up to 260 channels of data, a multichannel analog-to-digital subsystem that can process up to 50,000 samples of data per second, and a digital computer with standard and nonstandard devices, including graphics capability. Also described are the software configuration of the DAS and complex hardware/software interfaces providing, for example, automatic amplifier gain and offset adjustment for each data channel. Specific DAS applications are summarized, including the real time processing of dynamic deflection data, unsteady pressure measurements, and flutter and buffet data.

Cole, P.↗
NASA NTRS1979

Real-time data acquisition system for the NASA Langley transonic dynamics tunnel

The hardware configuration of the Transonic Dynamics Wind Tunnel Data Acquisition System (DAS) which consists of an analog front end that can process up to 260 channels of data is presented. The DAS also has a multi-channel analog-to-digital subsystem that can process up to 50,000 samples of data per sec, and a digital computer with standard and nonstandard devices, with graphics capability. The software configuration of the DAS and complex hardware/software interfaces are described, which can provide automatic amplifier gain and offset adjustment for each data channel. Finally, a summary of specific DAS applications is given including the real-time processing of dynamic deflection data, unsteady pressure measurements, and flutter and buffet data.

Cole, P. H.↗
NASA NTRS1982

An integrated user-oriented laboratory for verification of digital flight control systems: Features and capabilities

A Digital Flight Control Systems Verification Laboratory (DFCSVL) has been established at NASA Ames Research Center. This report describes the major elements of the laboratory, the research activities that can be supported in the area of verification and validation of digital flight control systems (DFCS), and the operating scenarios within which these activities can be carried out. The DFCSVL consists of a palletized dual-dual flight-control system linked to a dedicated PDP-11/60 processor. Major software support programs are hosted in a remotely located UNIVAC 1100 accessible from the PDP-11/60 through a modem link. Important features of the DFCSVL include extensive hardware and software fault insertion capabilities, a real-time closed loop environment to exercise the DFCS, an integrated set of software verification tools, and a user-oriented interface to all the resources and capabilities.

Defeo, P.↗
NASA NTRS1983

Digitally controlled sonars

Sonars are usually designed and constructed as stand alone instruments. That is, all elements or subsystems of the sonar are provided: power conditioning, displays, intercommunications, control, receiver, transmitter, and transducer. The sonars which are a part of the Advanced Ocean Test Development Platform (AOTDP) represent a departure from this manner of implementation and are configured more like an instrumentation system. Only the transducer, transmitter, and receiver which are unique to a particular sonar function; Up, Down, Side Scan, exist as separable subsystems. The remaining functions are reserved to the AOTDP and serve all sonars and other instrumentation in a shared manner. The organization and functions of the common AOTDP elements were described and then the interface with the sonars discussed. The techniques for software control of the sonar parameters were explained followed by the details of the realization of the sonar functions and some discussion of the performance of the side scan sonars.

Hansen, G. R.↗
NASA NTRS1983

Galileo attitude and articulation control subsystem closed loop testing

In order to ensure the reliable operation of the Attitude and Articulation Control Subsystem (AACS) which will guide the Galileo spacecraft on its two and one-half year journey to Jupiter, the AACS is being rigorously tested. The primary objectives of the test program are the verification of the AACS's form, fit, and function, especially with regard to subsystem external interfaces and the functional operation of the flight software. Attention is presently given to the Galileo Closed Loop Test System, which simulates the dynamic and 'visual' flight environment for AACS components in the laboratory.

Lembeck, M. F.↗