Engineering PapersSearch

SEARCH · Engineering Papers

Results for “scientific workflows”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records

ScyFlow: An Environment for the Visual Specification and Execution of Scientific Workflows

With the advent of grid technologies, scientists and engineers are building more and more complex applications to utilize distributed grid resources. The core grid services provide a path for accessing and utilizing these resources in a secure and seamless fashion. However what the scientists need is an environment that will allow them to specify their application runs at a high organizational level, and then support efficient execution across any given set or sets of resources. We have been designing and implementing ScyFlow, a dual-interface architecture (both GUT and APT) that addresses this problem. The scientist/user specifies the application tasks along with the necessary control and data flow, and monitors and manages the execution of the resulting workflow across the distributed resources. In this paper, we utilize two scenarios to provide the details of the two modules of the project, the visual editor and the runtime workflow engine.

McCann, Karen M.

Earth Science Data Processing With Nextflow

Earth science data processing tasks present many challenges. These tasks often process large input datasets and require scores of CPU-hours to generate results. All but the simplest tasks will be decomposed into a series of computational or data manipulation steps, also known as a scientific workflow. In order to reduce the burden of orchestrating and running the dependent processing steps, a workflow execution engine is required. This poster describes the lessons learned by the CLARREO Pathfinder (CPF) team while developing multiple scientific workflows and utilizing the open-source Nextflow engine to execute them in a cloud computing environment. The Nextflow engine is designed with the following stated goals: first, the engine does not dictate how individual steps in the task are implemented (i.e. it is language and interface agnostic); second, the engine supports easy configuration and modularity at the workflow level so that others can easily execute our workflows to reproduce results; lastly, the engine eases development by transparently scaling execution from local to remote environments. Nextflow was developed for the bioinformatics domain but is a good fit for other scientific workflows where the overall task is well-described by a dataflow diagram. The CPF team has developed Nextflow pipelines (i.e. scientific workflows) to simulate CLARREO radiance, generate large look-up tables for inter-calibration algorithms, and generate L4 intercalibration data products. These pipelines consume from single-digits to hundreds of thousands of CPU-hours. In the development and evolution of these pipelines we have discovered many design patterns, pitfalls, and solutions to common problems. Our goal is to demonstrate important aspects of how to design, implement, run, and ultimately share Nextflow pipelines in the domain of Earth science.

Aron D Bartle

LaRC SmartLab Apps For Instrument Control And Data Processing: Optical Micrometer Data Visualizer

The LaRC Smart Lab applications are a series of software tools to greatly enhance researcher efficiency by streamlining and automating workflows. Python scripts and applications are increasingly being used in scientific workflows, including for instrument control and data processing. Interactive Python scripting environments such as Jupyter Lab provide powerful tools for using Python. In some use cases, the development of standalone applications with dedicated graphical user interfaces (GUIs) can enhance the utility of the code and open it up to more users, including non-programmers. Here, we describe a GUI based optical micrometer data visualization application developed as part of the LaRC SmartLab project. We highlight its use in visualizing experimental data and briefly discuss its implementation to give pointers to programmers who wish develop work based on this application's or similar co de.

LaRC SmartLab

LaRC SmartLab Apps For Instrument Control and Data Processing: Laboratory Environment Monitor

The LaRC SmartLab applications are a series of software tools to greatly enhance researcher efficiency by streamlining and automating workflows. Python scripts and applications are increasingly being used in scientific workflows, including for instrument control and data processing. Interactive Python scripting environments such as JupyterLab provide powerful tools for using Python. In some use cases, the development of standalone applications with dedicated graphical user interfaces can enhance the utility of the code and open it up to more users, including non-programmers. Here, we describe a Python based application for communicating with, and displaying data from, iTHX Temperature, Humidity, and Dew Point probes. We discuss the set up and use of the application as well as its implementation. We also highlight the use of Simulated probes to enable users and developers to familiarize with or debug the application, even when they do not have access to the physical hardware in the laboratory.

LaRC SmartLab

Climate Analytics as a Service

Exascale computing, big data, and cloud computing are driving the evolution of large-scale information systems toward a model of data-proximal analysis. In response, we are developing a concept of climate analytics as a service (CAaaS) that represents a convergence of data analytics and archive management. With this approach, high-performance compute-storage implemented as an analytic system is part of a dynamic archive comprising both static and computationally realized objects. It is a system whose capabilities are framed as behaviors over a static data collection, but where queries cause results to be created, not found and retrieved. Those results can be the product of a complex analysis, but, importantly, they also can be tailored responses to the simplest of requests. NASA's MERRA Analytic Service and associated Climate Data Services API provide a real-world example of climate analytics delivered as a service in this way. Our experiences reveal several advantages to this approach, not the least of which is orders-of-magnitude time reduction in the data assembly task common to many scientific workflows.

big data

Addressing User Needs through the Stakeholder Engagement Program

Every two years, the Satellite Needs Working Group (SNWG), an initiative of the U.S. Group on Earth Observations (USGEO), surveys federal agencies to pinpoint their satellite Earth observation needs. For each expressed need, NASA-led assessment teams coordinate with the agencies to devise solutions. Solutions can include existing or modified data products as well as the construction of new data products and technologies, such as the Harmonized Landsat Sentinel-2 (HLS) product and the Catalog of Archived Sub-Orbital Earth Science Investigations (CASEI). To facilitate adoption of new data products and technologies, the SNWG Management Office’s Stakeholder Engagement Program (SEP) was established. The program’s primary goals are to respond to training and capacity building needs expressed by agencies and to encourage engagement from stakeholders as SNWG solutions are developed. To serve these needs, SEP has developed the following: an SNWG Solutions Earthdata webpage, an SEP Earthdata webpage, and an Earthdata Search Portal for SNWG products. These avenues provide assistance to users from all backgrounds and levels of expertise as well as publicize the ongoing efforts of SNWG solutions. In addition, the SEP is also collaborating with NASA’s Short-term Prediction Research and Transition (SPoRT) Center to develop user-driven applications for SNWG products leveraging stakeholder input. This presentation will provide an overview of the SEP, highlight the resources currently available to users, and describe ongoing efforts to address the needs of users, so SNWG products can be better implemented into scientific workflows.

Jenny Wood

Hydrology Copilot: A Cloud-Native Ai System for Hydrological Data Analysis

The emergence of AI-driven Earth observation systems promises to broaden access to petabyte-scale geospatial data beyond domain specialists. However, translating this vision into operational scientific infrastructure requires addressing fundamental challenges in data virtualization, code transparency, and domain-specific reasoning. We present Hydrology Copilot, a cloud-native AI framework for natural-language-driven analysis of Earth observation data. To demonstrate operational capabilities at scale, we implement the system using NASA's North American Land Data Assimilation System version 3 (NLDAS-3), which provides surface meteorological forcing and land-surface model output across North and Central America at 1-km resolution, from which drought diagnostics are derived. The system integrates five core contributions: (1) scalable data virtualization using Kerchunk-based cloud optimized access, achieving a 1.5 to 4.6 times improvement in I/O latency across benchmark queries spanning regional single-day extractions (4.6 times speedup) to continental monthly aggregations (1.5 times speedup); (2) transparent code generation through Microsoft Azure AI Foundry agents that expose executable Python workflows for scientific verification; (3) persistent conversational memory enabling multi-turn analytical discourse across sessions; (4) intelligent query validation that enforces dataset boundaries and resolves ambiguous requests before execution; and (5) a multi-agent architecture coordinating query parsing, code generation, and visualization. We evaluate the system through drought-monitoring workflows, demonstrating reliable code generation, accurate results validated against reference computations and the operational U.S. Drought Monitor, and efficient operation across increasingly complex tasks. By bridging natural-language interfaces with rigorous hydrological analysis, Hydrology Copilot advances beyond proof-of-concept demonstrations to provide a deployable framework for operational Earth science applications.

Data virtualization

The Science Discovery Engine: Connecting Heterogeneous Scientific Data and Information

Transformative science often occurs at the boundaries of different disciplines. Making interdisciplinary science data, software and documentation discoverable and accessible is essential to enabling transformative science. However, connecting this diverse and heterogeneous information is often a challenge due to several factors including the dispersed and sometimes isolated nature of data and the semantic differences between topical areas. NASA’s Science Discovery Engine (SDE) has developed several approaches to tackling these challenges. The SDE is a unified, insightful search experience that enables discovery of NASA’s open science data across five topical areas: astrophysics, biological and physical sciences, Earth science, heliophysics and planetary science. In this presentation, we will discuss our efforts to develop a systematic scientific curation workflow to integrate diverse content into a single search environment. We will also share lessons learned from our work to create a metadata crosswalk across the five disciplines.

Kaylin Bugbee

Operational Workflow in a Sample Receiving Facility: Input from the MSR Operation Definition Team

The return of scientifically selected samples from Mars would provide a rare opportunity for investigation with the full range of the latest technology available. To take full advantage of this opportunity, it is important to plan ahead to ensure the pristine nature of the samples upon arrival within the Earth environment until scientific investigations can begin. The NASA/ESA science community-driven MSR Science Planning Group – Phase 2 (MSPG2) delivered recommendations and guidance regarding curation (1) and science (2,3) activities to be performed on the samples under containment. High-level requirements for the infrastructure were also developed by MSPG2 (4). In order to prepare infrastructure-targeted input for the ESA and NASA facility studies planned in the 2022-2023 timeframe, the MSR agency-led Operational Scenarios Definition Team (MOSDT) was assembled to conceptualize the sample operations that will inform future architecture teams. Emphasis was placed on the responsibility of MOSDT to use community-defined requirements and to represent the view of the international scientific community. The main deliverable of MOSDT was an operational workflow for a Sample Receiving Facility (SRF). Two other deliverables were produced: a report to narrate the workflow, and a list of instruments (see Hutzler et al., this conference). Activities described in the main sequence of the workflow range from engineering operations to curation to science, with the latter term being used here as the science to be done within a SRF. Side sequences (e.g. engineering inspection of hardware, head gas extraction) were also identified, and detailed when they would have a significant impact on the infrastructure of a SRF. It was necessary for the MOSDT to rely on assumptions for some steps and activities, and though these were kept to a minimum (and are described in both the report supporting the workflow and in the full presentation), in general, the assumptions and overall work were very conservative, as the impact of underestimating the scope of the SRF infrastructure was considered more detrimental than overestimating it. It is expected that future work will be able to confirm or inform these assumptions. The community was consulted during the course of the MOSDT work. This abstract’s aim is two-fold: on one hand, inform the scientific community and overall MSR stakeholders, to make the infrastructure studies and trade-off more understandable; on the other hand, to solicit feedback from a larger community audience for the next iterations planning for SRF design and activities.

Mars Sample Return

Framework for Integrating Science Data Processing Algorithms Into Process Control Systems

A software framework called PCS Task Wrapper is responsible for standardizing the setup, process initiation, execution, and file management tasks surrounding the execution of science data algorithms, which are referred to by NASA as Product Generation Executives (PGEs). PGEs codify a scientific algorithm, some step in the overall scientific process involved in a mission science workflow. The PCS Task Wrapper provides a stable operating environment to the underlying PGE during its execution lifecycle. If the PGE requires a file, or metadata regarding the file, the PCS Task Wrapper is responsible for delivering that information to the PGE in a manner that meets its requirements. If the PGE requires knowledge of upstream or downstream PGEs in a sequence of executions, that information is also made available. Finally, if information regarding disk space, or node information such as CPU availability, etc., is required, the PCS Task Wrapper provides this information to the underlying PGE. After this information is collected, the PGE is executed, and its output Product file and Metadata generation is managed via the PCS Task Wrapper framework. The innovation is responsible for marshalling output Products and Metadata back to a PCS File Management component for use in downstream data processing and pedigree. In support of this, the PCS Task Wrapper leverages the PCS Crawler Framework to ingest (during pipeline processing) the output Product files and Metadata produced by the PGE. The architectural components of the PCS Task Wrapper framework include PGE Task Instance, PGE Config File Builder, Config File Property Adder, Science PGE Config File Writer, and PCS Met file Writer. This innovative framework is really the unifying bridge between the execution of a step in the overall processing pipeline, and the available PCS component services as well as the information that they collectively manage.

Mattmann, Chris A.

NASA Weather Balloon Demonstration of an Additively Manufactured Antenna

Additive manufacturing (AM) enables low-cost, lightweight, and geometrically flexible antennas for rapid deployment missions. This work reports a left-hand circularly polarized magneto-electric dipole printed on a Radix dielectric with inkjet silver metallization and demonstrated as a process replacement for NASA weather-balloon RF hardware. By combining substrate fabrication and metallization, AM provides value for unrecoverable or field-replaceable systems. A physics based verification workflow links AM-specific material behavior to electromagnetic performance and yields bounded total, radiation, and mismatch efficiencies. Standard surface-impedance and roughness models failed to reproduce the frequency-dependent radiation loss observed in printed inks, underscoring the need for AM-specific conductor parameterization. Mission testing confirmed TDRSS link closure from NASA’s Columbia Scientific Balloon Facility and validated a repeatable print–measure–fly workflow for bounding RF performance and qualifying AM antennas for field use.

Peter Moschetti

NASA Weather Balloon Demonstration of an Additively Manufactured Antenna

Additive manufacturing (AM) enables low-cost, lightweight, and geometrically flexible antennas for rapid deployment missions. This work reports a left-hand circularly polarized magneto-electric dipole printed on a Radix dielectric with inkjet silver metallization and demonstrated as a process replacement for NASA weather-balloon RF hardware. By combining substrate fabrication and metallization, AM provides value for unrecoverable or field-replaceable systems. A physics based verification workflow links AM-specific material behavior to electromagnetic performance and yields bounded total, radiation, and mismatch efficiencies. Standard surface-impedance and roughness models failed to reproduce the frequency-dependent radiation loss observed in printed inks, underscoring the need for AM-specific conductor parameterization. Mission testing confirmed TDRSS link closure from NASA’s Columbia Scientific Balloon Facility and validated a repeatable print–measure–fly workflow for bounding RF performance and qualifying AM antennas for field use.

Peter Moschetti

ncompare: A Python Package for Comparing netCDF Structures

Earth science researchers and data engineers have a common problem: they often need to compare data files to see what is different between them. A lot of time is spent developing code to test differences. When it comes to comparing multidimensional data file formats like netCDFs (Network Common Data Form), this is particularly challenging and time-consuming, since there is frequently a need to evaluate the differences between dimension sizes, variable structures, and variable attributes, especially for regression testing. Since netCDFs are widely used in Earth science — with climate models, oceanographic or atmospheric reanalyses, and observational data — improved means of evaluating netCDF files can help enable a wide range of applications. We have developed a reusable open source approach through `ncompare`, which is a Python package for comparing netCDF structures [[https://github.com/nasa/ncompare]]. The `ncompare` tool compares the structure of two Network Common Data Form (NetCDF) files at the command line. It facilitates rapid comparisons by generating a formatted display of the matching and non-matching groups, variables, and associated metadata between two NetCDF datasets. The user has the option to colorize the terminal output for ease of viewing, and `ncompare` can optionally save comparison reports in text, comma-separated value (CSV), and/or Microsoft Excel formats. Despite the availability of tools (such as ncmpidiff or nccmp) that compare the values of variables, there was not previously a readily available, Python-based tool for rapid visual comparisons of group and variable structures, attributes, and chunking. `ncompare` was developed at NASA’s Atmospheric Science Data Center (ASDC) and is a collaboration with NASA Openscapes [[https://nasa-openscapes.github.io]] mentors across 11 of NASA’s data centers. Openscapes’ overarching vision is to support scientific researchers using NASA Earthdata as they migrate their workflows to the cloud. Relevant links: - https://github.com/nasa/ncompare - https://github.com/pyOpenSci/software-submission/issues/146 - https://nasa-openscapes.github.io

Daniel Kaufman

The Nasa SRA Process as It Relates to Open-Source Workflows Developed for GeneLab Data Processing

To release open, standards-compliant processed data sets in the Open Science Data Repository (OSDR), the GeneLab Data Processing team works with the scientific community through the OSDR Analysis Working Groups to design and build open-source data processing pipelines. Once baselined internally, these pipelines are wrapped into workflows and published on the NASA GeneLab Data Processing public GitHub repository along with detailed instructions for installation and use. Each workflow must be approved through NASA's Software Release Authorization (SRA) process prior to publishing. However, the SRA process lacks sufficient documentation and clarity regarding which forms are applicable for new open-source software that utilizes publicly available 3rd party tools, and the SRA process can take several months to complete, making sharing software outside of NASA cumbersome and in contradiction with the concept of Open Science. Furthermore, the SRA process was designed as a one-size fits all approach and thus many of the questions asked are not applicable to our open-source workflows. Here we describe the software provided on the NASA GeneLab Data Processing GitHub repository, summarize our experiences with the SRA process to release these software, and propose a more stream-lined approach for review of open-source projects.

Software Release Authorization

The NASA SRA Process as it Relates to Open-Source Workflows Developed for GeneLab Data Processing

To release open, standards-compliant processed data sets in the Open Science Data Repository (OSDR), the GeneLab Data Processing team works with the scientific community through the OSDR Analysis Working Groups to design and build open-source data processing pipelines. Once baselined internally, these pipelines are wrapped into workflows and published on the NASA GeneLab Data Processing public GitHub repository along with detailed instructions for installation and use. Each workflow must be approved through NASA's Software Release Authorization (SRA) process prior to publishing. However, the SRA process lacks sufficient documentation and clarity regarding which forms are applicable for new open-source software that utilizes publicly available 3rd party tools, and the SRA process can take several months to complete, making sharing software outside of NASA cumbersome and in contradiction with the concept of Open Science. Furthermore, the SRA process was designed as a one-size fits all approach and thus many of the questions asked are not applicable to our open-source workflows. Here we describe the software provided on the NASA GeneLab Data Processing GitHub repository, summarize our experiences with the SRA process to release these software, and propose a more stream-lined approach for review of open-source projects.

Software Release Authorization

Enabling Open and Interoperable Science: Multi-Omics Data Processing Platform with NASA GeneLab Standardized Bioinformatics Workflows for Space and Earth Research

Multi-omics biological data continues to be generated at an astounding pace. Genomics, transcriptomics, metabolomics, and proteomics, or collectively known as multi-omics data, are used to assess biological functions, and provide invaluable insights into human, animal, plant, and environmental health both on Earth and in Space. Despite the abundance of these valuable data, the need for bioinformatics expertise, particularly as it relates to the niche filed of space biology, and a lack of accessible resources for processing these data limit their usefulness in deriving biological insights. The NASA Open Science Data Repository (OSDR) provides access to omics data from various spaceflight and analog studies. To enhance the accessibility and reusability of these data, GeneLab (part of OSDR) designs and implements standardized, community-driven, open-source bioinformatics workflows to transform raw omics data into standardized processed data. Currently, GeneLab-processed data from hundreds of space studies have been reused for meta-analyses. This has led to new insights and scientific publications that extend beyond the initial research, thereby enriching our understanding of molecular-scale biological responses to the space environment. To make these bioinformatics workflows open and accessible, GeneLab teamed up with DOE-funded initiatives, including the National Microbiome Data Collaborative (NMDC), to create the NASA EDGE [Empowering the Development of Genomics Expertise] Bioinformatics web-based platform. NASA EDGE utilizes shared compute resources to run the GeneLab standardized bioinformatics workflows, which eliminates the need for researchers to have their own high performance computing cluster. The web-based platform makes complicated biological analyses incredibly easy to perform, thus expanding the reach of these analyses to bioinformatics novices, students, and even citizen scientists enabling them to contribute to scientific discoveries and progress. The authors will demonstrate how the NASA EDGE platform can be used to process microbial omics data hosted on OSDR as well as user-generated omics datasets using GeneLab’s standard workflows.

Amanda M. Saravia-Butler

A Review of Extra-Terrestrial Regolith Excavation Concepts and Prototypes

Regolith is present on many extra-terrestrial bodies, and the crushed rock material it is made of contains many of the resources that are enabling for In-Situ Resource Utilization (ISRU). When extracted these resources can be used to provide consumables such as rocket propellant, human life support, working fluids and gases for industrial processes and feedstocks for manufacturing. In addition, the regolith can also be very beneficial for construction purposes as an aggregate which can be used for construction materials and shielding for radiation protection and micrometeorite impact. Binders for regolith concrete may also be made from geopolymers that may be in the regolith. The regolith can be melted and drawn out into glass fibers and used as reinforcements in a metal, polymer, or concrete matrix. In addition, there is tremendous scientific and geological knowledge that can only be obtained by studying samples of the regolith. However, none of these valuable activities can proceed without first acquiring the regolith granular material with some type of excavation device and method. Excavation is in the critical path of many workflows that will make up the capabilities required to establish a human and robotic presence in our solar system. While scientific in-situ sampling of regolith in small quantities has been achieved since the dawn of the space age in the 1960’s, large scale excavation for mining and construction on extra-terrestrial bodies has only been contemplated for many decades in works of scientific fact and also in fictional stories, but serious development and prototyping of excavation technologies for use in reduced gravity space environments was only started in the late 1990’s.This paper will review and document the evolution of extra-terrestrial excavation concepts and prototypes based on the available literature and the personal experience of the author who has been working on regolith excavation technology development since 1998.

ISRU

A Review of Extra-Terrestrial Regolith Excavation Concepts and Prototypes

Regolith is present on many extra-terrestrial bodies, and the crushed rock material it is made of contains many of the resources that are enabling for In-Situ Resource Utilization (ISRU). When extracted, these resources can be used to provide consumables such as rocket propellant, human life support, working fluids and gases for industrial processes and feedstocks for manufacturing. In addition, the regolith can also be very beneficial for construction purposes as an aggregate which can be used for construction materials and shielding for radiation protection and micrometeorite impact. Binders for regolith concrete may also be made from geopolymers that may be in the regolith. The regolith can be melted and drawn out into glass fibers and used as reinforcements in a metal, polymer, or concrete matrix. In addition, there is tremendous scientific and geological knowledge that can only be obtained by studying samples of the regolith. However, none of these valuable activities can proceed without first acquiring the regolith granular material with some type of excavation device and method. Excavation is in the critical path of many workflows that will make up the capabilities required to establish a human and robotic presence in our solar system. While scientific in-situ sampling of regolith in small quantities has been achieved since the dawn of the space age in the 1960’s, large scale excavation for mining and construction on extra-terrestrial bodies has only been contemplated, for many decades, but serious development and prototyping of excavation technologies for use in reduced gravity space environments was only started in the late 1990’s. This paper will review and document the evolution of extra-terrestrial excavation concepts and prototypes based on the available literature and the personal experience of the author who has been working on regolith excavation technology development since 1998.

Regolith