Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “application programming interface”

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 181 records · Page 10

Portals Reference Implementation v. 1.0

The Portals reference implementation is based on the Portals 4.X API, published by Sandia National Laboratories as a freely available public document. It is designed to be an implementation of the Portals Networking Application Programming Interface and is used by several other upper layer protocols like SHMEM, GASNet and MPI. It is implemented over existing networks, specifically Ethernet and InfiniBand networks. This implementation provides Portals networks functionality and serves as a software emulation of Portals compliant networking hardware. It can be used to develop software using the Portals API prior to the debut of Portals networking hardware, such as Bull’s BXI interconnect, as well as a substitute for portals hardware on development platforms that do not have Portals compliant hardware. The reference implementation provides new capabilities beyond that of a typical network, namely the ability to have messages matched in hardware in a way compatible with upper layer software such as MPI or SHMEM. It also offers methods of offloading network operations via triggered operations, which can be used to create offloaded collective operations. Specific details on the Portals API can be found at http://portals4.org.

Grant, RyanE.↗

Developer Network

NREL's Developer Network, developer.nrel.gov, provides data that users can access to provide data to their own analyses, mobile and web applications. Developers can retrieve the data through a Web services API (application programming interface). The Developer Network handles overhead of serving up web services such as key management, authentication, analytics, reporting, documentation standards, and throttling in a common architecture, while allowing web services and APIs to be maintained and managed independently.

Source record↗

Home Energy Management System - VOLTTRON Integration

In most Home Energy Management Systems (HEMS) available in the market, different devices running different communication protocols cannot interact with each other and exchange information. As a result of this integration, the information about different devices running different communication protocol can be accessible by other agents and devices running on VOLTTRON platform. The integration process can be used by any HEMS available in the market regardless of the programming language they use. If the existing HEMS provides an Application Programming Interface (API) based on the RESTFul architecture, that API can be used for integration. Our candidate HEMS in this project is home-assistant (Hass). An agent is implemented which can communicate with the Hass API and receives information about the devices loaded on the API. The agent publishes the information it receives on the VOLTTRON message bus so other agents can have access to this information. On the other side, for each type of devices, an agent is implemented such as Climate Agent, Lock Agent, Switch Agent, Light Agent, etc. Each of these agents is subscribed to the messages published on the message bus about their associated devices. These agents can also change the status of the devices by sending appropriate service calls to the API. Other agents and services on the platform can also access this information and coordinate their decision-making process based on this information.

Zandi, Helia↗

Commercial Building Energy Saver, API (CBES API) v2.0

The CBES API provides Application Programming Interface to a suite of functions to improve energy efficiency of buildings, including building energy benchmarking, preliminary retrofit analysis using a pre-simulation database DEEP, and detailed retrofit analysis using energy modeling with the EnergyPlus simulation engine. New capabilities in version 2.0 include renewable technologies (PV, storage), advanced HVAC systems, demand response measures, TDV (Time Dependent Valuation energy) metrics, as well as shading from adjacent buildings, trees or roof obstructions. The CBES API is used to power the LBNL CBES Web App. It can be used by third party developers and vendors.

Hong, Tianzhen↗

Sandia Cloud Forensics and Incident Response Platform v 1.0

As systems and devices become virtualized and deployed in the cloud, the hypervisor becomes an increasingly appropriate place to collect performance data, system state, system landscape, function calls, transaction traces, and other characteristics. We developed a method by which an introspection application may be coupled with a hypervisor to “reach into” the VM with minimal intrusiveness to collect data critical to the reconstruction of events, files, and operations. Such a capability is required to take advantage of the hypervisor as an instrumentation platform and to integrate that data with more traditional collection mechanisms. The concept of a VM serviced by a lightweight hypervisor is a relatively new paradigm for forensic practitioners. Traditional forensic techniques, based on assumptions that the filesystem was directly interacting with the hardware through an abstraction, afforded the forensic practitioner the assumption that there was nothing controlling the application below the filesystem. This is not the case when using virtualized technologies. Hypervisors can covertly monitor, introspect and interact with the guest in a transparent fashion. The problems of storage and collection of actionable data are exhausting. The current challenge is most hypervisors do not expose a useful application programming interface (API) at a sufficient level to do transparent, fine-grained and customizable introspection. Scalable VM instrumentation and introspection at an in-depth level requires fast handling of events, as well as direct access to VM state. Furthermore, deep introspection benefits greatly from the ability to gather data from the hardware during the VM’s exit to the hypervisor. All of this requires identical access to the system as the hypervisor itself; improper use of this ability could easily cause system instability. It is for this reason we believe that the hypervisor developers have been hesitant to grant this much control through their APIs. However, our approach leverages other means to collect and monitor the guests in a targeted fashion. Virtual machine introspection (VMI) is a technique used to monitor the runtime state of a system-level virtual machine. The runtime state can be may include processor registers, memory, disk, network, and any other hardware-level events A review of research literature and current VMI technologies exposed several limitations and tradeoffs in VMI approaches, including: the use of in-guest agents; kernel to user space transitions (dramatically slowing down processing); VMI tool pre-configuration requirements; hypervisor version lock-in or source code patching; reliance on operating system symbols; limited processor features due to hypervisor (even if the hardware could do more). To address these constraints, a VMI tool was envisioned to provide the cloud forensic capabilities while having as few of these limitations as possible. The Kernel-based Virtual Machine Introspection (KVMi) tool was developed for hypervisors on Intel’s x86-64 architecture. To meet performance, scoping and use-case demands, the follow criteria were applied to KVMi to support live, forensic data collection: • Shall not require in-guest agents. • Shall work with any recent version of modern hypervisors. • Shall introspect upon any guest (VM) running modern versions of Windows, Linux and OS X. • Shall have the ability to find and track operating system artifacts • Shall not require operating system symbol files. • Shall be able to fully handle VM-exits, bypassing execution of the hypervisor if necessary, to facilitate new features the hypervisor may not support. • Shall be compilable/loadable on a running system with standard build tools.

Stout, WilliamM.S.↗

Broker for Assimilation, Synthesis and Integration of eNvironmental Diverse, Distributed Datasets v1.1.0

BASIN-3D (Broker for Assimilation, Synthesis and Integration of eNvironmental Diverse, Distributed Datasets) uses a data brokering approach to synthesize diverse earth science data from a variety of remote sources in real-time without the need for additional storage. BASIN-3D is an extendable Django web framework application using a generalized data synthesis model that makes the synthesized data available via REpresentational State Transfer (REST) Application Programming Interface (API). We have currently implemented our data synthesis model to represent sensor-based time series earth science observations across a hierarchy of spatial locations. Supporting our data synthesis model is a plugin framework that allows developers to map data sources of interest to the BASIN-3D synthesis model

Varadharajan, Charuleka↗

LinkShop v.1.0.0

LinkShop is a software tool for applying the method of Linkography to the analysis time-sequence data. LinkShop provides command line, web, and application programming interfaces (API) for input and processing of time-sequence data, abstraction models, and ontologies. The software creates graph representations of the abstraction model, ontology, and derived linkograph. Finally, the tool allows the user to perform statistical measurements of the linkograph and refine the ontology through direct manipulation of the linkograph.

Jarocki, JohnCharles↗

MCR Container Tools

MathWorks' MATLAB is widely used in academia and industry for prototyping, data analysis, data processing, etc. Many users compile their programs using the MATLAB Compiler to run on workstations/computing clusters via the free MATLAB Compiler Runtime (MCR). The MCR facilitates the execution of code calling Application Programming Interfaces (API) functions from both base MATLAB and MATLAB toolboxes. In a Linux environment, a sizable number of third-party runtime dependencies (i.e. shared libraries) are necessary. Unfortunately, to the MTLAB community's knowledge, these dependencies are not documented, leaving system administrators and/or end-users to find/install the necessary libraries either as runtime errors resulting from them missing or by inspecting the header information of Executable and Linkable Format (ELF) libraries of the MCR to determine which ones are missing from the system. To address various shortcomings, Docker Images based on Community Enterprise Operating System (CentOS) 7, a derivative of Redhat Enterprise Linux (RHEL) 7, containing recent (2015-2017) MCR releases and their dependencies were created. These images, along with a provided sample Docker Compose YAML Script, can be used to create a simulated computing cluster where MATLAB Compiler created binaries can be executed using a sample Slurm Workload Manager script.

Haas, NicholasQ↗

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↗

Deep-Lynx-Python-Package

This software is a python package that interacts with the Application Programming Interface (API) suite provided by Deep Lynx. A python codebase may import this package in order to have access to these methods for communicating with a Deep Lynx instance.

Browning, JerenM↗

Web of Registries Search (WoRS) v1.0.0

The Web of Registries Search (WoRs) is a web based software application that enables users to search for publicly available biological parts using keywords or sequence fragments. For the initial version (1.0.0) of the application, WoRS targets 10 sources of biological part data: the GenBank NIH genetic sequence database (https://www.ncbi.nlm.nih.gov/genbank/), the iGem parts registry (parts.igem.org), the Addgene plasmid repository (https://www.addgene.org/), and 7 Inventory of Composable Elements (ACS Synbio, JGI, JBEI, JBEI Public, ABF, SynBerc, ABF Public) registry instances. WoRs has built-in automated web scrapers which extract data from sources that do not have a public or well-defined application programming interface (API). They extract as much public data as they can find and create a searchable index to speed up searches. Included in the indexed information is the source of the information.

Plahar, Hector↗

Deep Lynx Javascript Package

This software is a JavaScript package that interacts with the Application Programming Interface (API) suite provided by Deep Lynx. A JavaScript or TypeScript codebase may import this package in order to have access to these methods for communicating with a Deep Lynx instance.

Browning, JerenM↗

Saline

Saline is an Application Programming Interface (API) which provides a useful quality assured interface to data from thermo-physical property data models.

Henderson, ShaneChristopher [Oak Ridge National La↗

DERMS-RT (Distributed Energy Resource Management Solution using Real-Time Optimization) [SWR-20-46]

DERMS-RT provides a distributed energy resource management solution using real-time optimization to control different types of distributed energy resources (DERs) — such as rooftop PVs, battery energy storage systems, HVAC loads, electric water heater loads, and EV charging loads, and use these DERs to provide distribution voltage regulation and peak demand management services. The control approach implemented by DERM-RT is developed based on the real-time optimal power flow and distributed control previously developed by NREL researchers. The software codes are designed to provide modular DER management solution that can be easily applied to control heterogeneous DERs in distribution grids in coordination with centralized utility management systems. Also, DERMS-RT provides application programming interface (API) to extract useful grid model information from an open-source power system simulation software, use the information to solve the optimization problem, and apply the optimal set-points to the controlled DERs. In this way, DERMS-RT provides a plug-and-play function for implementing the real-time DER control on different utility system models, and it can be used as a simulation testbed to demonstrate the impact of real-time DER optimization on improving grid operations.

Ding, Fei↗

OpenTurbine [SWR-23-07]

OpenTurbine is an open-source code designed for the simulation of wind turbine structural dynamics. It is a flexible multi-body dynamics solver wherein the wind turbine is modeled as a collection of beam finite elements, rigid bodies, and constraints. OpenTurbine is equipped with an application programming interface primarily designed for coupling to computational fluid dynamics codes, but it is also suited for coupling to aerodynamics solvers based on blade element momentum theory.

Sprague, MichaelA.↗

ODD (Version 0.X)

The Orthogonal Diffusion Discretizations (ODD) library is a collection of low order (Diffusion, P1, Ray Tracing, and Variable Eddington Factor (VEF)) thermal radiation solvers for orthogonal structured grids driven by an application programing interface (API).

Cleveland, Mathew↗

Deeplynx Rust Sdk

This software is a Rust package that interacts with the Application Programming Interface (API) suite provided by DeepLynx. A Rust codebase may import this package in order to have access to these methods for communicating with a DeepLynx instance.

Browning, JerenM [Idaho National Laboratory (INL),↗

ThunderBoltz API

The ThunderBoltz application programming interface (API) code is written in Python and is comprised of a set of tools to facilitate compilation of the ThunderBoltz code, as well as fast assembly and formatting of input files for the ThunderBoltz code, post-processing tools of ThunderBoltz results, plotting tools, and runs/schedules the ThunderBoltz code executable for calculations. The ThunderBoltz API code is utilized for importing and manipulating input cross section sets, input conditions, and any other simulation settings made available within the ThunderBoltz input deck via user-defined settings or via automatic generation. The API comes with a set of plotting capabilities of input cross sections, results from ThunderBoltz, and post-processed results carried out with the API.

Park, Ryan↗