A data schema for exchanging information between urban building energy models and urban microclimate models in coupled simulations
Not Available
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
SEARCH · Search NASA
Results for “data schema”
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.
Genesis Data Card Schema, Template and Supporting Tools
Genesis Data Cards provide a standardized template and schema for documenting scientific datasets in support of discovery, access, interoperability, reusability, governed use, and AI usability. This release of the Genesis Data Card repository includes a versioned Markdown template, a LinkML schema with generated Pydantic and JSON artifacts, schema documentation, and example completed data cards. Validation tooling is provided to ensure that completed data cards conform to the schema prior to submission. Accompanying documentation for the structured metadata is provided as a Field Reference Guide. The schema and accompanying template provided in this repository address the call for actionable context that enables humans and AI systems to find, access, interpret, cite, and reuse data, and, when appropriate, integrate it into AI and machine learning workflows. The data card is intended to serve as a common metadata artifact intended to support standardized, cross-program dataset documentation across Department of Energy (DOE)-aligned efforts, including but not limited to Genesis Mission-related implementations, the Office of Science, National Nuclear Security Administration (NNSA), and Advanced Simulation and Computing (ASC) data governance and stewardship initiatives.
data card↗
Comparing simulated demand flexibility against actual performance in commercial office buildings
Commercial building energy benchmarking has been used as a mechanism to evaluate energy use of a single building over time, relative to other similar buildings, or to simulations of a reference building conforming to various energy standards. Lack of empirical demand flexibility data and consistent flexibility metrics has limited the ability to compare demand flexibility performance with estimated demand flexibility in buildings. In this study, we collected demand response performance data for a total of 831 demand response events from 192 sites as a first step to build such a building demand flexibility dataset, and propose a standard core data schema to consolidate field data from different sources. We also performed parametric simulations of a control strategy called “global temperature adjustment” using commercial office prototype building models. We then compared the simulated demand flexibility performance against the actual data for offices with global temperature adjustment strategy implemented. During demand response events with an average outside air temperature of 34 °C (range 23 °C–42 °C), the measured demand decrease intensity of the demand flexibility metrics were 6.1 watts per square meter (W/m 2 ), 10.0 W/m 2 , 11.1 W/m 2 , 7.1 W/m 2 , and 4.7 W/m 2 for small, small–medium, medium, medium–large, and large office buildings, respectively. Compared to the measured data in medium- and large-size buildings, the simulated demand decrease intensity was 0.7 W/m 2 (17%) lower on average. The discrepancy between simulated and measured peak demand intensities fell within one standard deviation of the mean measured data. Here, the comparison results validate the credibility of simulations in capturing real building data for assessing the technical potential of building demand flexibility.
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
Digital Archive Issues from the Perspective of an Earth Science Data Producer
Contents include the following: Introduction. A Producer Perspective on Earth Science Data. Data Producers as Members of a Scientific Community. Some Unique Characteristics of Scientific Data. Spatial and Temporal Sampling for Earth (or Space) Science Data. The Influence of the Data Production System Architecture. The Spatial and Temporal Structures Underlying Earth Science Data. Earth Science Data File (or Relation) Schemas. Data Producer Configuration Management Complexities. The Topology of Earth Science Data Inventories. Some Thoughts on the User Perspective. Science Data User Communities. Spatial and Temporal Structure Needs of Different Users. User Spatial Objects. Data Search Services. Inventory Search. Parameter (Keyword) Search. Metadata Searches. Documentation Search. Secondary Index Search. Print Technology and Hypertext. Inter-Data Collection Configuration Management Issues. An Archive View. Producer Data Ingest and Production. User Data Searching and Distribution. Subsetting and Supersetting. Semantic Requirements for Data Interchange. Tentative Conclusions. An Object Oriented View of Archive Information Evolution. Scientific Data Archival Issues. A Perspective on the Future of Digital Archives for Scientific Data. References Index for this paper.
Barkstrom, Bruce R.↗
Extending the Brick schema to represent metadata of occupants
Here, energy-related behaviors of occupants constitute a key factor influencing building performance; accordingly, the measured occupant data can support the objective assessment of the indoor environment and energy performance of buildings, which can inform building design and operational decisions. Existing data schemas focus on metadata of sensors, meters, physical equipment, and IoT devices in buildings; however, they are limited in representing the metadata of occupant data, including occupants' presence in spaces, movement between spaces, interactions with building systems or IoT devices, and preference of indoor environmental needs. To address this gap, an extension to the widely adopted metadata schema, Brick, is proposed to represent the contextual, behavioral, and demographic information of occupants. The proposed extension includes four parts: (1) a new “Occupant” class to represent occupants' demography and energy related behavioral patterns, (2) new subclasses under the Equipment class to represent envelope system and personal thermal comfort devices, (3) new subclasses under the Point class to represent occupant sensing and status, and (4) new auxiliary properties for occupant interactable equipment to represent the level of controllability for each piece of equipment by occupants. The extension is implemented in the Brick schema and has been tested using multiple occupant datasets from the ASHRAE Global Occupant Database. The extension enables Brick schema to capture diverse types of occupant sensing data and their metadata for FAIR data research and applications.
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
The National Microbiome Data Collaborative Data Portal: an integrated multi-omics microbiome data resource
Explore the source record for details and available documents.
Eloe-Fadrosh, Emiley A↗
A Python Module for Storing CCD Images with openPMD (openPMD-CCD) v0.1.0
openPMD is an open meta-data schema that provides meaning and self-description to data sets in science and engineering. The openPMD-CCD software module adds interfaces to organize camera (CCD) images in hierarchical data files. This software provides modern I/O storage formats from high-performance computing and provides bindings for integration into experimental control systems, e.g. via Python 3 and LabView 2020.
Gonsalves, AnthonyJ↗
Developing Deep Learning Models for System Remaining Useful Life Predictions: Application to Aircraft Engines
Prognostics and health management (PHM) is an important part of ensuring reliable operations of complex safety- critical systems. System-level remaining useful life (RUL) estimation is a much more complex problem than making estimations at the component level, and system-level RUL methodologies remain sparse in the literature. Model-based approaches have traditionally worked in the past for components such as capacitors, MOSFETs, batteries, or hard-drives (to name a few examples), but developing high fidelity dynamics models of cyber physical systems that can be used to study the effects of multiple degrading components in the system remains a challenging task. Some initial work on model-based System RUL predictions was demonstrated in Khorasgani, et al [1], but, to generalize the system-level prognostics problem, we have to resort to pure data driven and hybrid approaches. In this work, we propose an end-to-end data- driven framework for developing deep learning models to predict remaining useful life of cyber physical systems operating under unknown faulty conditions. The raw data is organized with a data schema that improves the model development process and down stream data analysis tasks. Due to the unknown faulty conditions, the raw sensor data is transformed into signals that expose the underlying degradation processes, which are then used for model development. Bayesian Optimization is used to tune the model parameters prior to training and validation. We show that this approach results in accurate predictions within 3 cycles to end of life (EOL). We demonstrate the effectiveness of our approach by applying it to the N-CMAPSS turbofan engine dataset recently released by NASA, which includes high fidelity degradation modeling, real world operating conditions, and a large set of fault operating modes.
Prognostics↗
BEAST: Expanding Sustainable Data Infrastructure for High-Enthalpy Facilities
Reproducible, data-driven thermal protection system (TPS) research requires that experimental records from high-enthalpy testing be consistently structured, traceable, and accessible across campaigns and institutions. In practice, however, arcjet and plasma facilities data remain largely fragmented: raw diagnostics are stored in ad hoc formats, material sample histories are disconnected from test conditions, and metadata standards are absent, precluding systematic cross-campaign analysis and long-term reuse. BEAST (Backend for Experiment Analysis, Storage, and Traceability) is an open-source, web-based platform that addresses these limitations by providing a unified, queryable infrastructure for high-enthalpy ground-test data [1]. First presented at the 15th Ablation Workshop [2], BEAST has since undergone significant development. The platform ingests and structures multi-channel time-series diagnostics, facility configurations, and material property records within a common provenance model, ensuring end-to-end traceability from raw sensor acquisition to reduced experimental quantities. A versioned material library links specimen identity and processing history to the specific runs in which each sample was tested. An integrated modeling workbench enables training and evaluation of regression models directly on archived experimental data, supporting condition interpolation and the construction of empirical material response databases. Beyond its original deployment at NASA Ames Research Center, BEAST has been designed to be facility-agnostic, with ongoing efforts to extend its adoption to other facilities. Its modular architecture accommodates heterogeneous diagnostic setups and facility types, and its future open-source distribution allows institutions to build on a common data standard rather than maintaining isolated, bespoke solutions. BEAST is further integrated within a broader ecosystem of companion tools: arcjetCV [3] extracts recession rates and shock standoff distances from high-speed video using computer vision, and miniSTARscan [4] provides sub-minute, portable photogrammetric surface reconstruction of test articles before and after exposure. All tools share a common data schema, enabling seamless ingestion of surface geometry, imagery, and time-series data into a single, coherent experimental record.
Database↗
BEAST: Expanding Sustainable Data Infrastructure for High-Enthalpy Facilities
Reproducible, data-driven thermal protection system (TPS) research requires that experimental records from high-enthalpy testing be consistently structured, traceable, and accessible across campaigns and institutions. In practice, however, arcjet and plasma facilities data remain largely fragmented: raw diagnostics are stored in ad hoc formats, material sample histories are disconnected from test conditions, and metadata standards are absent, precluding systematic cross-campaign analysis and long-term reuse. BEAST (Backend for Experiment Analysis, Storage, and Traceability) is an open-source, web-based platform that addresses these limitations by providing a unified, queryable infrastructure for high-enthalpy ground-test data [1]. First presented at the 15th Ablation Workshop [2], BEAST has since undergone significant development. The platform ingests and structures multi-channel time-series diagnostics, facility configurations, and material property records within a common provenance model, ensuring end-to-end traceability from raw sensor acquisition to reduced experimental quantities. A versioned material library links specimen identity and processing history to the specific runs in which each sample was tested. An integrated modeling workbench enables training and evaluation of regression models directly on archived experimental data, supporting condition interpolation and the construction of empirical material response databases. Beyond its original deployment at NASA Ames Research Center, BEAST has been designed to be facility-agnostic, with ongoing efforts to extend its adoption to other facilities. Its modular architecture accommodates heterogeneous diagnostic setups and facility types, and its future open-source distribution allows institutions to build on a common data standard rather than maintaining isolated, bespoke solutions. BEAST is further integrated within a broader ecosystem of companion tools: arcjetCV [3] extracts recession rates and shock standoff distances from high-speed video using computer vision, and miniSTARscan [4] provides sub-minute, portable photogrammetric surface reconstruction of test articles before and after exposure. All tools share a common data schema, enabling seamless ingestion of surface geometry, imagery, and time-series data into a single, coherent experimental record.
Database↗
UAS Reports (UREPs): EnablingExchange of Observation Data Between UAS Operations
As the volume of small unmanned aircraft systems (UAS) operations increases, the lack of weather products to support these operations becomes more problematic. One early solution to obtaining more information about weather conditions is to allow operators to share their observations and measurements with other airspace users. This is analogous to the AIREP and PIREP reporting systems in traditional aviation wherein pilots report weather phenomena they have observed or experienced to provide better situational awareness to other pilots. Given the automated nature of the small (under 55 lbs.) UAS platforms and operations, automated reporting of relevant information should also be supported. To promote automated exchange of these data, a well-defined data schema needs to be established along with the mechanisms for sending and retrieving the data. This paper examines this concept and offers an initial definition of the necessary elements to allow for immediate implementation and use.
UAS↗
Playing with DIRT: Building the Framework for a Comprehensive In-Situ Soil Materials Testing Database
Long-term, sustainable planetary exploration will require the ability to "live off the land," relying on In-Situ Resource Utilization (ISRU) and In-Situ Construction as core capabilities. Reduction of both risk and launch mass for lunar construction will require evaluating and comparing regolith materials for use as feedstocks suitable for in-situ beneficiation and fabrication of building components. These material assessment capabilities will inform lunar infrastructure design decisions, with co-benefits for terrestrial construction using in-situ materials. Current planetary construction technology development relies on lunar mapping and orbital data, Apollo-era sample analyses, current simulant inventories, and tests conducted using analog site soils. Requirements for lunar infrastructure design decisions and construction systems will be determined based on specific environmental conditions, mission architectures, and the materials available within traverse range of lunar feedstock processing depots. Critical for success is the capability to identify, evaluate and make effective use of a wide range of materials as they are found in-situ on the lunar surface. This paper discusses the development of a digital repository for data on soil and regolith properties, beginning with their structural performance in both cementitious and non-cementitious building material formulations. The Database for In-situ Resource Testing (DIRT) compiles a catalog of raw materials, additives, and formulations, with notations pertaining to material sources and preparation techniques entered via a web-based user interface. Design of consistent data schemas for site-sourced materials evaluation will facilitate linkage with relevant terrestrial and planetary materials databases while enabling guided data input via templates for participation by broader groups of collaborators. Results of these analyses are compiled in a centralized repository to generate insights applicable for regolith resources and landing sites yet to be precisely defined. Collection of thorough records of material characteristics, applications and performance will support innovative construction solutions not only for space infrastructure but for sustainable, resilient design in the terrestrial built environment.
Sarah Joey Seitz↗
Integrated System Planning: Emerging Software Requirements in the Power Industry
Power system planning software remains fragmented across organizational boundaries, with specialized tools for capacity expansion, production cost modeling, power flow, and dynamic analysis operating on incompatible data models and assumptions. This article argues that the fragmentation is not merely a technical problem but a predictable consequence of Conway's law: software architectures mirror the departmental structures within which they are developed. Regulatory milestones like Federal Energy Regulatory Commission (FERC) Order 888 formalized these divisions, but the roots trace back to the distinct engineering disciplines-mechanical, chemical, and electrical-that staffed generation and transmission planning departments in vertically integrated utilities. As the industry moves toward integrated system planning (ISP) that coordinates generation, transmission, and distribution investment decisions, the software ecosystem must evolve accordingly. We identify five categories of software requirements to enable this transition: coherent data inputs decoupled from individual applications, unified and extensible data schemas, modular component representations that support multiple abstraction levels, lifecycle management of planning datasets, and well-defined application programming interface (API) contracts that separate data exchange from algorithmic control. We examine how these requirements interact with three common workflow patterns-serial gate clearing, sequential multiapplication, and convergence oriented-and discuss the interface design principles each demands. We then outline a vision for platform-based planning architectures where specialized analytical services compose through standardized interfaces and where artificial intelligence (AI)/machine learning (ML) tools augment decision support within a disciplined software infrastructure. The practices proposed here offer a path from today's siloed tool collections toward collaborative planning ecosystems capable of handling the complexity of modern power system transformation.
24 POWER TRANSMISSION AND DISTRIBUTION↗
A multiphysics coupling framework for exascale simulation of fracture evolution in subsurface energy applications
Predicting the evolution of fractured media is challenging due to coupled thermal, hydrological, chemical and mechanical processes that occur over a broad range of spatial scales, from the microscopic pore scale to field scale. We present a software framework and scientific workflow that couples the pore scale flow and reactive transport simulator Chombo-Crunch with the field scale geomechanics solver in GEOS to simulate fracture evolution in subsurface fluid-rock systems. This new multiphysics coupling capability comprises several novel features. An HDF5 data schema for coupling fracture positions between the two codes is employed and leverages the coarse resolution of the GEOS mechanics solver which limits the size of data coupled, and is, thus, not taxed by data resulting from the high resolution pore scale Chombo-Crunch solver. The coupling framework requires tracking of both before and after coarse nodal positions in GEOS as well as the resolved embedded boundary in Chombo-Crunch. We accomplished this by developing an approach to geometry generation that tracks the fracture interface between the two different methodologies. The GEOS quadrilateral mesh is converted to triangles which are organized into bins and an accessible tree structure; the nodes are then mapped to the Chombo representation using a continuous signed distance function that determines locations inside, on and outside of the fracture boundary. The GEOS positions are retained in memory on the Chombo-Crunch side of the coupling. The time stepping cadence for coupled multiphysics processes of flow, transport, reactions and mechanics is stable and demonstrates temporal reach to experimental time scales. The approach is validated by demonstration of 9 days of simulated time of a core flood experiment with fracture aperture evolution due to invasion of carbonated brine in wellbore-cement and sandstone. We also demonstrate usage of exascale computing resources by simulating a high resolution version of the validation problem on OLCF Frontier.
97 MATHEMATICS AND COMPUTING↗
Evolution of the ROOT Tree I/O
The ROOT TTree data format encodes hundreds of petabytes of High Energy and Nuclear Physics events. Its columnar layout drives rapid analyses, as only those parts (“branches”) that are really used in a given analysis need to be read from storage. Its unique feature is the seamless C++ integration, which allows users to directly store their event classes without explicitly defining data schemas. In this contribution, we present the status and plans of the future ROOT 7 event I/O. Along with the ROOT 7 interface modernization, we aim for robust, where possible compile-time safe C++ interfaces to read and write event data. On the performance side, we show first benchmarks using ROOT’s new experimental I/O subsystem that combines the best of TTrees with recent advances in columnar data formats. A core ingredient is a strong separation of the high-level logical data layout (C++ classes) from the low-level physical data layout (storage backed nested vectors of simple types). We show how the new, optimized physical data layout speeds up serialization and deserialization and facilitates parallel, vectorized and bulk operations. This lets ROOT I/O run optimally on the upcoming ultra-fast NVRAM storage devices, as well as file-less storage systems such as object stores.
72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
Development and Application of Schema Based Occupant-Centric Building Performance Metrics
Occupant behavior can significantly influence the operation and performance of buildings. Many occupant-centric key performance indicators (KPIs) rely on having accurate counts of the number of occupants in a building, which is very different to how occupancy information is currently collected in the majority of buildings today. To address this gap, the authors develop a standardized methodology for the calculation of percent space utilization for buildings, which is formulated with respect to two prevalent operational data schemas: the Brick Schema and Project Haystack. The methodology is scalable across different levels of spatial granularity and irrespective of sensor placement. Moreover, the methods are intended to make use of typical occupancy sensors that capture presence level occupancy and not counts of people. Since occupant-hours is a preferable metric to use in KPI calculations, a method to convert between percent space utilization and occupant-hours using the design occupancy for a space is also developed. The methodology is demonstrated on a small commercial office space in Boulder, Colorado using data collected between June 2018 and February 2019. A multiple linear regression is performed that shows strong evidence for a relationship between building energy consumption and percent space utilization.
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
Future Concepts for Realtime Data Interfaces for Control Centers
Existing methods of exchanging realtime data between the major control centers in the International Space Station program have resulted in a patchwork of local formats being imposed on each Mission Control Center. This puts the burden on a data customer to comply with the proprietary data formats of each data supplier. This has increased the cost and complexity for each participant, limited access to mission data and hampered the development of efficient and flexible operations concepts. Ideally, a universal format should be promoted in the industry to prevent the unnecessary burden of each center processing a different data format standard for every external interface with another center. With the broad acceptance of XML and other conventions used in other industries, it is now time for the Aerospace industry to fully engage and establish such a standard. This paper will briefly consider the components that would be required by such a standard (XML schema, data dictionaries, etc.) in order to accomplish the goal of a universal low-cost interface, and acquire broad industry acceptance. We will then examine current approaches being developed by standards bodies and other groups. The current state of CCSDS panel work will be reviewed, with a survey of the degree of industry acceptance. Other widely accepted commercial approaches will be considered, sometimes complimentary to the standards work, but sometimes not. The question is whether de facto industry standards are in concert with, or in conflict with the direction of the standards bodies. And given that state of affairs, the author will consider whether a new program establishing its Mission Control Center should implement a data interface based on those standards. The author proposes that broad industry support to unify the various efforts will enable collaboration between control centers and space programs to a wider degree than is currently available. This will reduce the cost for programs to provide realtime access to their data, hence reducing the cost of access to space, and benefiting the industry as a whole.
Kearney, Mike W., III↗
Retaining Systems Engineering Model Meaning Through Transformation: Demo 2
Digital engineering strategies typically assume that digital engineering models interoperate seamlessly across the multiple different engineering modeling software applications involved, such as model- based systems engineering (MBSE), mechanical computer-aided design (MCAD), electrical computer-aided design (ECAD), and other engineering modeling applications. The presumption is that the data schema in these modeling software applications are structured in the familiar flat- tabular schema like any other software application. Engineering domain-specific applications (e.g., systems, mechanical, electrical, simulation) are typically designed to solve domain-specific problems, necessarily excluding explicit representations of non-domain information to help the engineer focus on the domain problems (system definition, design, simulation). Such exclusions become problematic in inter-domain information exchange. The obvious assumptions of one domain might not be so obvious to experts in another domain. Ambiguity in domain-specific language can erode the ability to enable different domain modeling applications to interoperate, unless the underlying language is understood and used as the basis for translation from one application to another. The engineering modeling software application industry has struggled for decades to enable these applications to interoperate. Industry standards have been developed, but they have not unified the industry. Why is this? The authors assert that the industry has relied on traditional database integration methods. The basic issue prohibiting successful application integration then is that traditional database-driven integration does not consider the distinct languages of each domain. An engineering models meaning is expressed through the underlying language of that engineering domain. In essence, traditional integration methods do not retain the semantic context (meaning) of the model. The basis of this research stems from the widely held assumption that systems engineering models are (or can be) structured according to the underlying semantic ontology of the model. This assumption can be imagined from two thoughts. 1) Digital systems engineering models are often represented using graph theory (the graph of a complex systems model can contain millions of nodes and edges). When examining the nodes one at a time and following the outbound edges of each node one by one, one can end up with rudimentary statements about the model (i.e., node A relates to node B), as in a semantic graph. 2) Likewise, from the study of natural languages, a sentence can be structured into unambiguous triples of subject-predicate-object within formal and highly expressive semantic ontologies. The rudimentary statements about a systems model discerned with graph theory closely mimic the triples used in the ontologies that try to structure natural languages. In other words, a systems models semantic graph can be (or is) structured into an ontology. Additionally, it is well established in industry that through natural language processing (NLP), which provides the means to create language structures, that computers can interpret ontological graphs. Therefore, the authors hypothesized that if the integrity of the underlying semantic structure of a systems model is retained, the contextual meaning of the model is retained. By structuring system models into the triples of the underlying ontology during the transformation from one MBSE application to another, the authors have provided a proof of the concept that the meaning of a system model can be retained during transformation. The authors assert that this is the missing ingredient in effective systems model-to-model interoperability. ACKNOWLEDGEMENTS The authors would like to thank the FY19 Model Interoperability team members who provided a solid foundation for the FY20 team to leverage: John McCloud, for the work he did to guide us toward the right use of technology that will appropriately discover and manipulate ontologies. Carlos Tafoya, for the work he did to develop an application programming interface (API)/Adapter that would export ontology-based data from GENESYS. Peter Chandler, for the work he did to architect our overall integration solution, with an eye toward the future that would influence a large-scale federated production-level systems engineering digital model ecosystem.
42 ENGINEERING↗