SEARCH · Search NASA
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.
The invention is a self contained software utility that is deployed on the computer controlling a mass spectrometer. The purpose of the software is to monitor a given directory for files matching a user specified criteria and automatically upload matching files to a remote server as well as trigger a request that the data be processed by the cloud based CoreMS software
The data catalog market is currently flooded with a myriad of different products, but none serve the scientific community well. There are cloud-native tools like Databricks, Snowflake,to on-premise solutions like Collibra and Datahub. The common failing of all these tools however, is their inability to serve the scientific data community directly. Most catalogs are targeted towards financial, health, or user data - not sensor or scientific domain data. They also prioritize integrations that often don’t exist or are just starting to be used in the scientific realm - all while ignoring common scientific tools and file types. Datum is a catalog which targets the scientific data directly, including the tools and networks in which those tools are used. We work with the producers and consumers of the data where they are, targeting cloud and on-premise with a focus on classified networks. Datum is an Erlang/Elixir application. Technical Features Note: The features listed below are still under development and may change, slightly, upon final delivery of the product. File Formats - Datum has the ability to read additional metadata and provides processing pipelines for the following file formats: Plain Text, PDF, LaTeX, HTML, Open Document Format (.odt), XML, CSV/TSV (and other standard delimiters), OpenDocument Database and Spreadsheets, Geo-Referenced TIFF, Common Data Format, HDF/HDF5, LabView TDMS, Excel, DeltaTables, Parquet, Apache Iceberg, Apache Hudi and many others. Metadata Collection - Scanners for the local and networked file systems and cloud storage providers. Network integration with common databases such as MSSQL and MySQL. User Plugin System - Users are able to provide either file processing, metadata extraction, or sampling plugins in the programming language of their choice. Authentication/Authorization -: OIDC integration, SCIM provisioning and EntraID integration out of the box. Full user and group management system with a “least privilege” operating mode. Governance - Customizable data governance platform; dictate and enforce required metadata, enforce data embargos, and enforce user agreements and NDAs before data access. Ability to create health checks on data, rejecting abandoned or poorly curated data and automatically removing it from the search index. Ability for users to submit corrections. Search - Semantic search is a first class citizen. No licenses to expensive, external software required. Integrated use of vectors and vector-based search allows for AI agent integration at all levels of operation. Metadata Model - Display and control data’s lineage and connections to other data and data directories. Data is modeled after a filesystem - an organization instantly recognizable and navigable by most any user. CLI and SDK - Ships with a Command Line Interface (CLI) tool and with a fully-featured Python SDK. This allows for rapid and programmatic use of Datum by every level of user. Minimal Infrastructure - Datum ships as a single executable file and can be run on any operating system and most CPU architectures. Datum has no reliance on external databases, search indexing tools, or other outside services - and it runs equally well on edge computing devices, cloud services, or in a clustered HPC environment.
The software generates and maintains daily work journal entries in text format, via a web browser. The journal entries are saved in a structured directory file tree on the system running the software. The software also incorporates a database so that it can track the location of files in the file system and various other metadata. The software allows the users to access their journal entries either through the browser or as discrete text files, facilitating sharing and open science. Additionally, to assist with the yearly PMP process, this tool connects to LLM APIs to provide summarization of the journal entries on a month-by-month or weekly basis. The advantage over similar technologies such as Apple Notes (extremely popular for notetaking) is that the instant software does not force the user to stay inside the Apple ecosystem, since it allows for export of the user's text files. This facilitates open science, so that researchers who use the tool can easily transfer their research notes to any other system. The WebJournalMaker repository is here: https://github.com/lbnl-science-it/WorkJournalMaker The WebJournalMaker repository is forked from the JournalSummarizer: https://github.com/tyfong-lbl/JournalSummarizer and builds on its code. I wrote the code for both of these software repos, using generative AI.
Laser capture microdissection (LCM) derived stem cell-type transcriptome (Jie et al.) How to run on your system Install R on your system. Install the required packages shiny, shinyjs, ggplot2, dplyr, formattable, rcartocolor Download the RShiny app code (ui.R and server.R) and RDS files from the GitHub repository to the same directory. Usage: Run the R code file (ui.R) in the RStudio. The app will open in the default web browser.
This repository contains data and code related to the study on cutting height and its effects on Miscanthus x giganteus (mxg) stem mass and density. The data is organized into several directories, each containing specific types of data and scripts.
MOOSEenger is an open-source, terminal-first chat application for the MOOSE ecosystem that couples specialized parsing of MOOSE documentation and “.i” input files with retrieval-augmented generation to deliver grounded answers about multiphysics modeling and workflows. It includes dedicated readers for MOOSE-style HTML and a pyhit-based parser that uses the MOOSE syntax tree to preserve block structure and attach retrieval metadata. A data-ingestion pipeline performs semantic chunking into atomic facts and stores them hierarchically in a local Chroma vector database that maintains parent–child relationships across documents; the system can ingest directories, individual files, and single-page web content, and it provides CRUD operations (insert, update, delete) to manage the corpus. At query time, relevant chunks are embedded, retrieved, and fused into the model context, with interactive features such as token streaming, persistent chat history, and dynamic RAG (retrieval triggered by user input or intermediate model output). Deployment is flexible: MOOSEenger runs with local Ollama models or remote Hugging Face/OpenAI backends—typically coordinating generation, lightweight tagging/summarization, and embeddings across three models—and it also supports a server mode and integration with the VS Code Continue interface.
The code is written in Python and consists of the following pipeline that is implemented in Apache Airflow. This pipeline intends to understand the companies that are directly or indirectly involved with a type of critical infrastructure system at some point in that system's lifecycle. The pipeline takes a configuration file that specifies a list of initial companies to consider, a geographic region of interest, and a set of SEC form types as well as other data sources (e.g. CrunchBase) from which to extract entities and relations. There are four main components to this pipeline as currently implemented: Entity Extraction, Network Construction, Analysis, and Visualization. First, Entity Extraction, is implemented as the `topear-extract_organizations` Apache Airflow workflow. Given an initial query that specifies a geographic region of interest and a time interval, the software will extract CI facilities of interest and organizations that have a direct influence relationship to those facilities (e.g. ownership). During the course of the LDRD, we focused on Electric Vehicle charging stations and this information is available via the Department of Energy (DOE) database on fueling stations maintained by NREL. Within the context of the DOE CESER project, we have focused on Battery Energy Storage Systems (BESS). Second, the Network Extraction component will iteratively construct a social network graph given the set of organizations and people extracted in the previous step. Organizations (and eventually People if desired) are then fed as a query to the `topgear-construct_social_network` Apache Airflow workflow which given a set of initial companies and data sets (e.g. SEC EDGAR form types, OpenCorporates, Crunchbase). This Airflow workflow will iteratively query such data sources to discover relationships with new organizations and people. For example, this module can iteratively query SEC EDGAR for metadata that documents the number of each type of form for the given set of companies and their location. This forms metadata represents a catalog of data sources from SEC EDGAR for the extracted social network knowledge graph. The pipeline then downloads these forms from the website and saves them in a build directory for further processing. These documents are then parsed for entities and relations. Again, we note that in additional to SEC data sources, this step can also pull in information on organizations via API services such as CrunchBase and OpenCorporates or bulk data sources. At the end of this step, the resultant social network, the Critical Infrastructure network, and the edges that encode relationships between organizations and CI facilities, form the Adversarial Socio-Technical Network (ASTN) that informs the analysis. Third, the Analysis component processes these generated ASTN. Previously, that has included the ability to compare prevalence of different vendors for a given infrastructure component type across different regions as well as identify common public and private investors across those vendors. This was demonstrated for EV Charging Stations across several different metropolitan areas within an IEEE PES GridEdge publication. More recently, we have looked at ways to identify infrastructure owners and operators of BESS with the most nameplate capacity across different states as well as other indictors of risk resulting from changes in ownership over time. Finally, the Visualization component consists of an HTML/CSS/JS framework by which users can interact geospatial, operational, and organizational relationships across a given portfolio of Critical Infrastructure facilities. The objective is to provide a library of UI/UX modules that can be repurposed for stakeholder-specific dashboards. All of the modules are related via a common event model that enables UI actions in one view to percolate across the other views.
SF-26-086 CodeScribe introduces a structured, multi-stage pipeline that combines deterministic program analysis with LLM-powered translation to enable incremental, testable Fortran-to-C++ migration. First, `code-scribe index` traverses the project directory tree and produces `scribe.yaml` metadata files recording all modules, subroutines, and functions at each level, giving the LLM accurate structural context instead of a hallucinated codebase model. Second, `code-scribe draft` performs the deterministic portion of translation — converting Fortran types to C++ equivalents, replacing `use` statements with `#include` and `using namespace` directives, and detecting constructs requiring special handling — while embedding`scribe-prompt` annotations that guide the LLM through non-trivial cases such as statement-function-to-lambda conversions and `extern "C"` wrapper generation. Third, `code-scribe translate` applies project-specific TOML-based few-shot prompt templates and submits the composed prompt to a pluggable LLM backend (OpenAI, Anthropic, Argonne ARGO, any OpenAI-compatible endpoint, or local Hugging Face checkpoints), producing a C++ source file, a header, and a Fortran-C++ interface file for each translated routine so the codebase compiles and runs correctly throughout the migration. Beyond translation, CodeScribe includes a tool-using coding agent (`code-scribe agent`) with read, bash, edit, and write capabilities, and a bounded loop mode (`code-scribe loop`) that runs repeated stateless agent sessions over a task file with restricted tool access — enabling sustained, auditable software development workflows for broader scientific computing tasks.
These trajectories, scripts, and analysis performed on Summit underly the work published as 'Data-guided Multi-Map variables for ensemble refinement of molecular movies'. The trajectories include equilibrium and non-equilibrium sampling of ADK, CODH, and FLPP3, the scripts used to build the systems, and the scripts used to analyze the output. The directory structure is explained further in an internal README file.
Vegetation and land cover maps at 1km x 1km resolution across North America. The vegetation map was generated by the scripts in nalcms2daymet_script directory in the repository at `https://github.com/daliwang/NALCMS2Daymet_ELM`.
This dataset contains 636,246 profile images of vehicles representing 13,963 unique vehicles. The data was collected by a set of roadside sensors over the course of three years. Each time a vehicle passed by one of the sensors, a series of images was collected. The images were processed to detect and localize each vehicle, and a license plate reader collocated with the sensor was used to provide a unique ID for the vehicle. Actual license plate numbers have been obfuscated by replacing with an arbitrary numerical ID for each vehicle. After localizing the vehicle in each image, the original RGB image was rotated, scaled, and shifted to produce a new RGB image of size 234x234 pixels such that the outermost two wheels are located at predetermined pixel locations in the image. In this way, all vehicle images are aligned to one another. This registration process occasionally results in a portion of certain vehicles being cutoff at the edges of the image. The dataset has been partitioned into two sets called training and validation. The two partitions no common vehicles, i.e., a vehicle present in one partition is guaranteed not to be present in the other. In this way, an algorithm can be validated against a set of new vehicles that were not seen during the training process. The training set contains 543,926 images from 64,440 vehicle passes representing 11,918 unique vehicles, while the validation set contains 92,320 images from 10,991 vehicle passes representing 2,045 unique vehicles. Vehicle images are organized by directories corresponding to unique vehicles. The file naming scheme is as follows: veh_{vehID}_tr_{passID}_{frameID}_{elevation}_{timeofday}.jpg where {vehID} is the vehicle ID (unique across the entire dataset), {passID} is an identifier for each tracked vehicle pass (unique across the entire dataset), {frameID} is the index of the frame within the given vehicle pass starting at 0, {elevation} is a two-letter string indicating whether the sensor was elevated (el) or at ground-level (gl), and {timeofday} is a two-letter string indicating whether the image was captured during daytime (dt) or nighttime (nt).
This release consists of six datasets which together include multi-modal layer-wise powder bed images from two different powder bed printing technologies. These datasets are designed primarily to facilitate the development and testing of new computer vision and machine learning based anomaly and defect detection algorithms. The authors provide both training data with corresponding ground truth pixel masks and evaluation data with corresponding baseline prediction pixel masks made by a trained neural network. The laser powder bed fusion (L-PBF) datasets are sourced from EOS M290 and AddUp FormUp 350 printers and the binder jet (BJ) dataset is sourced from an ExOne M-Flex printer. The materials represented in these datasets include 17-4 PH Stainless Steel, GammaPrint-700, Inconel 718, Maraging Steel, and H13 Steel. The sensor imaging modalities represented include visible-light (VL), temporally-integrated (i.e., long duration exposure) near-infrared (TI-NIR), and wide-band infrared (IR). To download the dataset: (1) Create a Globus account. (2) Create a Globus Endpoint on your computer. (3) Transfer the dataset from the OLCF DOI-DOWNLOADS Collection to your Collection. Common troubleshooting steps: (a) Confirm that the transfer is going from OLCF DOI-DOWNLOADS to your Collection. (b) Create an exception for Globus in your antivirus software so that it can create an Endpoint. (c) Manually create a Globus access directory (where the data will be downloaded) by going to the Preferences > Access tab.
This dataset contains input, output, and sensitivity data files for computational simulations with the SCALE code system as part of the Verified, Archived Library of Inputs and Data (VALID). The simulations cover critical benchmark experiments from the International Criticality Safety Benchmark Evaluation Project. The files are to be housed in a public directory for distribution. The information contained in the files have been approved for release by the Organisation for Economic Co-operation and Development Nuclear Energy Agency (NEA). Users wanting to reproduce results from this dataset are required to obtain a license to the SCALE code system for which details on the distribution can be found here: https://www.ornl.gov/scale/releases.
This dataset provides links to daily RINEX files for two GPS stations at Brady's Hot Springs as of December 20, 2014. The data is formatted as compressed GNSS RINEX observation files and is accessible through CSV files containing metadata such as file size, data type, and publication dates. The dataset includes FTP links for downloading the individual RINEX files and covers data collected through 2012. The CSV files serve as a directory for navigating to the correct FTP locations to access the desired data. Users are advised to cross-reference the filenames and station identifiers (BRAD or BRDY) when downloading files. The files were generated by the UNAVCO GSAC Repository, and all data-related timestamps and units are specified within the CSV structure. Links to additional resources, including the original database for direct downloads and a more recent dataset with data as of March 26, 2015, are also provided.
This dataset provides links to daily RINEX files for two GPS stations at Brady's Hot Springs as of March 26, 2014. The data is formatted as compressed GNSS RINEX observation files, accessible through formatted CSV files, as well as in links to the complete daily time series data. The CSV files serve as a directory for navigating to the correct FTP locations to access the desired data. Users are advised to cross-reference the filenames and station identifiers (BRAD or BRDY) when downloading files. The files were generated by the UNAVCO GSAC Repository, and all data-related timestamps and units are specified within the CSV structure. Additional Resources, including the original database for direct downloads and links to the previous and following set of RINEX data (as of 12-2-14 and 9-17-2015, respectively), are also provided.
This dataset includes links to the PoroTomo DAS data in both SEG-Y and hdf5 (via h5py and HSDS with h5pyd) formats with tutorial notebooks for use. Data are hosted on Amazon Web Services (AWS) Simple Storage Service (S3) through the Open Energy Data Initiative (OEDI). Also included are links to the documentation for the dataset, Jupyter Notebook tutorials for working with the data as it is stored in AWS S3, and links to data viewers in OEDI for the horizontal (DASH) and vertical (DASV) DAS datasets. Horizontal DAS (DASH) data collection began 3/8/16, paused, and then started again on 3/11/2016 and ended 3/26/2016 using zigzag trenched fiber optic cabels. Vertical DAS (DASV) data collection began 3/17/2016 and ended 3/28/16 using a fiber optic cable through the first 363 m of a vertical well. These are raw data files from the DAS deployment at (DASH) and below (DASV) the surface during testing at the PoroTomo Natural Laboratory at Brady Hot Spring in Nevada. SEG-Y and hdf5 files are stored in 30 second files organized into directories by day. The hdf5 files available via HSDS are stored in daily files. Metadata includes information on the timing of recording gaps and a file count is included that lists the number of files from each day of recording. These data are available for download without login credentials through the free and publicly accessible Open Energy Data Initiative (OEDI) data viewer which allows users to browse and download individual or groups of files.