SEARCH · Search NASA

Results for “processing scripts”

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.

SourceResearch connectionFrom yearThrough year

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

At least 163 records · Page 9

All sources NASA NTRS DOE OSTI

DOE OSTI2026

Model Data Archive for Manuscript Titled "Evaluation of a Coupled Surface–Subsurface Hydrologic Model Using Dense Water‑Level Sensors in a Mixed Urban–Rural Watershed"

This archive provides scripts, input files, and datasets used for the implementation and evaluation of a fully coupled surface–subsurface hydrologic model in the Neches River Basin, southeast Texas. The study uses the Advanced Terrestrial Simulator (ATS) to simulate coupled surface–subsurface hydrologic processes over a mixed urban–rural watershed and evaluates model performance using a dense network of 136 in situ water-level sensors, nine U.S. Geological Survey (USGS) stream gauges, and SSEBop-derived evapotranspiration estimates during the period October 2014–June 2024. The workflow is implemented primarily in Python 3 using the Watershed Workflow package. The Jupyter notebooks can be executed using open-source software such as Anaconda JupyterLab or Visual Studio Code. Other data files include TXT, CSV, XML, SHP, TIF, NetCDF, HDF5, and ExodusII files, which can be processed using the provided Python scripts. ATS input files are provided in XML format and can be edited using any commonly used text editor. This archive contains: *Scripts and input files used to generate the ATS model setup, including watershed discretization, mesh generation, parameter mapping, and model configuration. *Jupyter notebooks used for preprocessing observational data, evaluating streamflow, water levels, and evapotranspiration, computing performance metrics, and generating the figures presented in the manuscript. *ATS simulation outputs and processed observational datasets, including OneRain and DD6 water-level sensors, USGS streamflow observations, GIS data, and supporting spatial datasets used throughout the study.

Dense water-level sensor network↗

DOE OSTI2022

Verification and Validation of START: A Spent Nuclear Fuel Routing and Decision Support Tool

The Stakeholder Tool for Assessing Radioactive Transportation (START) is a web-based geospatial decision-support tool being developed by the US Department of Energy’s Office of Integrated Waste Management (IWM) to support federal interim storage for spent nuclear fuel (SNF) and associated transportation. START provides many functions for the IWM program including: serving as a communications tool for conveying geospatial data and information, an options analysis tool for exploring potential transport modes and routes for transporting SNF from nuclear power plants to future federal interim storage facilities, an emergency response planning tool for Tribes and States to identify training needs along potential SNF transport corridors, an environmental analysis tool for estimating potential radiation dose exposure from incident-free and incident-case SNF transport conditions, and a systems analysis support tool providing route-related inputs for system throughput analysis. As part of the START development process, a verification and validation (V&V) effort is being undertaken. In the initial V&V phase, several outputs of the START tool were checked such as the total distance, population and population densities within the buffer zone, and incident free dose. The V&V process is fluid as it will be utilized after each version change to ensure that the core functionalities of the tool are maintained and the results are consistent with the previous versions. Efforts have also been put into developing scripts to aid in the process of automating certain sections of the V&V work. As some of the V&V efforts use Environmental Systems Research Institute’s (ESRI) tools upon which the START framework is built, the START data were compared against outputs from tools like Quantum Geographic Information System (QGIS) for buffer zone populations and route lengths to ensure independence of the V&V process. Good agreement was observed between the START results and the independent V&V studies with the majority of the differences falling between 1% and 5% for populations within the buffer zone and route distance. This presentation describes the development and design of the START tool, V&V methods employed for various metrics of interest and their respective results, and future plans.

START, transportation, GIS, V&V↗

NASA NTRS1992

The ALEXIS data processing package: An IDL based system

The Array of Low Energy X-ray Imaging Sensors (ALEXIS) experiment consists of a mini-satellite containing six wide angle EUV/ultrasoft x-ray telescopes. Its purpose is to map out the sky in three narrow (approximately 5 percent) bandpasses around 66, 71, and 93 eV. The 66 and 71 eV bandpasses are centered on intense Fe emission lines which are characteristic of million degree plasmas such as the one thought to produce the soft x-ray background. The 93 eV bandpass is not near any strong emission lines and is more sensitive to continuum sources. The mission will be launched on the Pegasus Air Launched Vehicle in the second half of 1992 into a 400-nautical-mile, high inclination orbit and will be controlled entirely from a small ground station located at Los Alamos. The project is a collaborative effort between Los Alamos National Laboratory, Sandia National Laboratory, and the University of California-Berkeley Space Sciences Laboratory. The six telescopes are arranged in three pairs. As the satellite spins twice a minute they scan the entire anti-solar hemisphere. Each f/1 telescope consists of a spherical, multilayer-coated mirror with a curved, microchannel plate detector located at the prime focus. The multilayer coatings determine the bandpasses of the telescopes. The field of view of each telescope is 30 degrees with a spatial resolution of 0.5 degree, limited by spherical aberration. The data processing requirements for ALEXIS are large. Each event is one of the six telescopes is telemetered to the ground with its time of arrival and position on the detector. This information must be folded with the aspect solution for the satellite to reconstruct the direction on the sky from which the photon came. Because of the way the six telescopes scan the sky, the effective exposure calculation is also very computationally intensive. ALEXIS may generate up to 100 megabytes of raw data per day, which are converted into a gigabyte per day of processed data. While the processing job for ALEXIS is sizable, the programming staff is small. To maximize programming efficiency, and to make the best use of tools available in the public domain, we chose IDL as our software development platform. IDL was used from the start of instrument development through flight. We use IDL as a top-level executive for the processing tasks (replacing Unix shell scripts), as a device independent graphics engine, as a database manager, and as a final data manipulator. IDL routines spawn special purpose C programs to perform detailed telemetry deconvolution and other specialized functions. We discuss the use of IDL and C within the processing and archiving strategy for the ALEXIS data anlaysis system as implemented on a SPARCstation platform. We also show results from our End-to-End software simulation capability as processed by our analysis codes.

Bloch, J. J.↗

NASA NTRS2001

Simple, Scalable, Script-Based Science Processor (S4P)

The development and deployment of data processing systems to process Earth Observing System (EOS) data has proven to be costly and prone to technical and schedule risk. Integration of science algorithms into a robust operational system has been difficult. The core processing system, based on commercial tools, has demonstrated limitations at the rates needed to produce the several terabytes per day for EOS, primarily due to job management overhead. This has motivated an evolution in the EOS Data Information System toward a more distributed one incorporating Science Investigator-led Processing Systems (SIPS). As part of this evolution, the Goddard Earth Sciences Distributed Active Archive Center (GES DAAC) has developed a simplified processing system to accommodate the increased load expected with the advent of reprocessing and launch of a second satellite. This system, the Simple, Scalable, Script-based Science Processor (S42) may also serve as a resource for future SIPS. The current EOSDIS Core System was designed to be general, resulting in a large, complex mix of commercial and custom software. In contrast, many simpler systems, such as the EROS Data Center AVHRR IKM system, rely on a simple directory structure to drive processing, with directories representing different stages of production. The system passes input data to a directory, and the output data is placed in a "downstream" directory. The GES DAAC's Simple Scalable Script-based Science Processing System is based on the latter concept, but with modifications to allow varied science algorithms and improve portability. It uses a factory assembly-line paradigm: when work orders arrive at a station, an executable is run, and output work orders are sent to downstream stations. The stations are implemented as UNIX directories, while work orders are simple ASCII files. The core S4P infrastructure consists of a Perl program called stationmaster, which detects newly arrived work orders and forks a job to run the appropriate executable (registered in a configuration file for that station). Although S4P is written in Perl, the executables associated with a station can be any program that can be run from the command line, i.e., non-interactively. An S4P instance is typically monitored using a simple Graphical User Interface. However, the reliance of S4P on UNIX files and directories also allows visibility into the state of stations and jobs using standard operating system commands, permitting remote monitor/control over low-bandwidth connections. S4P is being used as the foundation for several small- to medium-size systems for data mining, on-demand subsetting, processing of direct broadcast Moderate Resolution Imaging Spectroradiometer (MODIS) data, and Quick-Response MODIS processing. It has also been used to implement a large-scale system to process MODIS Level 1 and Level 2 Standard Products, which will ultimately process close to 2 TB/day.

Lynnes, Christopher↗

DOE OSTI2022

Test and extraction methods for the QC parameters of silicon strip sensors for ATLAS upgrade tracker

The Quality Control (QC) of pre-production strip sensors for the Inner Tracker (ITk) of the ATLAS Inner Detector upgrade has finished, and the collaboration has embarked on the QC test programme for production sensors. This programme will last more than 3 years and comprises the evaluation of approximately 22000 sensors. 8 Types of sensors, 2 barrel and 6 endcap, will be measured at many different collaborating institutes. The sustained throughput requirement of the combined QC processes is around 500 sensors per month in total. Measurement protocols have been established and acceptance criteria have been defined in accordance with the terms agreed with the supplier. For effective monitoring of test results, common data file formats have been agreed upon across the collaboration. To enable evaluation of test results produced by many different test setups at the various collaboration institutes, common algorithms have been developed to collate, evaluate, plot and upload measurement data. This allows for objective application of pass/fail criteria and compilation of corresponding yield data. These scripts have been used to process the data of more than 3000 sensors so far, and have been instrumental for identification of faulty sensors and monitoring of QC testing progress.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2025

Pyrogenic Organic Matter Laboratory Experiment: Aerobic Respiration and Geochemistry from Variably Inundated Stream Sediments (v3)

This dataset supports a broader study examining the effects of variable inundation and pyrogenic organic matter on ecosystem respiration. The dataset provides data generated from a laboratory batch experiment investigating the interaction between variable inundation conditions (wet and dry sediment) and pyrogenic organic matter (burned and unburned treatments). The contents include time series dissolved oxygen, sediment geochemistry data, and field metadata (including qualitative information on instream and river corridor characteristics). This data package was originally published in November 2025. It was updated in April 2026 (v2; new and modified files) and May 2026 (v3; modified files). See the change history section in the readme for more details For details on how to navigate data packages generated by this project, see https://data.ess-dive.lbl.gov/portals/PNNLRiverCorridorSFA/About. In addition to a readme, this data package also includes a file-level metadata (FLMD) file that describes each file and a data dictionary (DD) that describes all column/row headers and variable definitions. This dataset is comprised of (1) file-level metadata; (2) data dictionary; (3) field metadata; (4) international generic sample number (IGSN) mapping file; (5) readme; (6) field protocol; (7) sample name metadata; (8) an environmental context picture for the dry and inundated sampling locations; and (9) a subfolder with sample data from the sediment incubation experiment. The sample data subfolder contains (1) dissolved organic carbon (DOC, measured as non-purgeable organic carbon, NPOC); (2) total nitrogen (TN); (3) gravimetric moisture; (4) partial pressure and production rates of carbon dioxide, methane, and nitrous oxide; (5) field wet sediment mass, dry sediment mass, water mass, and field wet sediment volume in incubation and sediment NPOC/TN vials; (6) methods codes; (7) respiration rates, pH, and temperature from after the incubation, raw time series dissolved oxygen and temperature, and a subfolder containing associated plots and scripts; (8) ions; (9) FTICR-MS methods; and (10) a subfolder of 12 Tesla (12T) FTICR-MS data. This folder contains the CoreMS processed data and three subfolders, one containing the .xml files, one containing the CoreMS output files, and the other containing instructions and scripts for processing the files in CoreMS (https://github.com/EMSL-Computing/CoreMS). All files are .csv, .pdf, .R, .xml, .html, .Rmd, .py, .cal, .json, or .jpg.

54 ENVIRONMENTAL SCIENCES↗

NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, attitude control, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on previous missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the perceived benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗

NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, knowledge of attitude control, and attitude control hardware, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on other missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗

NASA NTRS2006

Internet Distribution of Spacecraft Telemetry Data

Remote Access Multi-mission Processing and Analysis Ground Environment (RAMPAGE) is a Java-language server computer program that enables near-real-time display of spacecraft telemetry data on any authorized client computer that has access to the Internet and is equipped with Web-browser software. In addition to providing a variety of displays of the latest available telemetry data, RAMPAGE can deliver notification of an alarm by electronic mail. Subscribers can then use RAMPAGE displays to determine the state of the spacecraft and formulate a response to the alarm, if necessary. A user can query spacecraft mission data in either binary or comma-separated-value format by use of a Web form or a Practical Extraction and Reporting Language (PERL) script to automate the query process. RAMPAGE runs on Linux and Solaris server computers in the Ground Data System (GDS) of NASA's Jet Propulsion Laboratory and includes components designed specifically to make it compatible with legacy GDS software. The client/server architecture of RAMPAGE and the use of the Java programming language make it possible to utilize a variety of competitive server and client computers, thereby also helping to minimize costs.

Specht, Ted↗

DOE OSTI2025

INS Nuclear Material Accounting and Control Instructional Video Materials- FY 25 Full Scripts

Each section of the Adhesive TID Process Demonstration is broken down into subparts as referenced in the outline contained in the Contents section, these are referenced as Activity Sections. The structure of the Adhesive TID Process Demonstration items is, to the best of the writer’s ability, in the order of events that the NMAC mitigating techniques are performed.

98 NUCLEAR DISARMAMENT, SAFEGUARDS, AND PHYSICAL P↗

NASA NTRS2020

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↗

NASA NTRS2020

TURBOMAT-FR: Turbomachinery Aeroelastic Forced Response Analysis Automation Using MATLAB®: PART 1

The primary aim of this effort is to develop a software tool named “Turbomachinery Aeroelastic Analysis Tool for Forced Response (TURBOMAT-FR)” using MATLAB® (The MathWorks, Inc.) scripts. The tool will aid in performing routine forced response analysis of turbomachinery fan blades with the aid of the modal summation method (MSUM). The MSUM approach requires a modal solution consisting of modal displacements, modal frequencies, and modal stresses. The MATLAB® scripts facilitate easy extraction of the required quantities from the computational fluid dynamics (CFD) and MSC Nastran (Hexagon AB) solution files. These quantities are subsequently utilized by the MSUM approach to perform a complete forced response analysis.The MATLAB® scripts in TURBOMAT-FR are utilized in postprocessing of the MSC Nastran finite element analysis outputs in three types of solutions or steps, namely (1) stresses and displacements from static and steady response solution, (2) unsteady stresses and displacements from direct forced response solution, and (3) modal solution containing modal displacements and modal stresses. In step (4), separate MATLAB® scripts are also developed to read the processed outputs in step (3) and perform forced response analysis using MSUM. The TURBOMAT-FR MATLAB® scripts mentioned previously are presented in two reports designated “Part 1” and “Part 2”. The current report, Part 1, presents the scripts needed to accomplish steps (1) and (2), noted previously. This will be exclusively useful for performing only the static and steady response analysis and the forced response analysis using the direct forced response solution approach. Part 2 contains the TURBOMAT-FR MATLAB® scripts needed to accomplish steps (3) and (4). The MATLAB® scripts given in Part 2 facilitate the calculation of unsteady stresses using MSUM and provide an automated procedure associated with aeroelastic forced response analysis with different pressure files for the same structural model. The unsteady stresses calculated using MSUM in Part 2 can be compared with those presented in Part 1. A cantilevered blade-alone model subjected to a realistic pressure loading to a boundary was used for static and unsteady direct forced response analysis to demonstrate the effectiveness of the TURBOMATFR MATLAB® scripts.

MATLAB-Scripts↗

DOE OSTI2026

STM/S Grid LDOS Data and Analysis Code for Deciphering Majorana Zero Modes in Topological Superconductor

This dataset provides raw millikelvin scanning tunneling microscopy/spectroscopy (STM/S) grid spectroscopy data and Python analysis scripts supporting the manuscript “Deciphering Majorana Zero Modes in Topological Superconductor FeTe0.55Se0.45 with Machine-Learning-Assisted Spectral Deconvolution.” The dataset includes a raw grid spectroscopy file acquired on FeTe0.55Se0.45 at 40 mK under magnetic field, together with Python/Jupytext analysis scripts used for STM/S data processing, visualization, spectral deconvolution, Lorentzian peak fitting, feature extraction, machine-learning-assisted clustering, and figure generation. These files support the analysis of vortex-core local density of states and the identification of zero-bias-peak-related spectral components from complex in-gap states. The dataset is intended to provide a citable archival record of the data and analysis code associated with the published manuscript and to support transparency and reproducibility of the reported STM/S and machine-learning workflow.

75 CONDENSED MATTER PHYSICS, SUPERCONDUCTIVITY AND↗

DOE OSTI2021

The iRage Cookbook [Slides]

iRage is a family of Zsh and Python 3 scripts designed to accelerate the process of submitting calculations for the novice xRage user. iRage reduces the time to write a new input deck and submit an xRage problem to the production queue to about 15 minutes, assuming the user has defined the initial geometry using a program like Osito or linked to problem geometries generated by codes such as Abaqus, Flag, or Pagosa. iRage runs on Linux and Mac systems.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2022

Modeling, Performance Assessment, and Nodal Data Analysis of TRISO-Fueled Systems with Shift

This technical report documents several enhancements to the Shift Monte Carlo (MC) code under the US Department of Energy (DOE) Nuclear Energy Advanced Modeling and Simulation (NEAMS) program in fiscal year (FY) 2022. Performance enhancements were added to Shift specifically for tristructural isotropic (TRISO)–fueled reactor systems and guided based on performance analysis in FY 2021. For the pebble performance model developed in previous studies, the runtime improved by ~ 91× compared to the original model and ~ 2× compared to the user-optimized model. Compared to Serpent, Shift is ~ 3× slower if Serpent delta-tracking is enabled but ~ 2× faster when delta-tracking is disabled. The multigroup cross section generation was improved through simplifying tally input definitions, porting several post-processing tally operations from Python scripts into the Shift code base, and accounting for production reactions in the scattering multiplicity. Progress was also made on two emerging capabilities: (1) the development of Titan (a Shift reactor physics user interface) and (2) initial investigation into path-length tallies for computing multigroup scattering matrices.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

NASA NTRS1995

A High Efficiency System for Science Instrument Commanding for the Mars Global Surveyor Mission

The Mars Global Surveyor (MGS) mission will return to Mars to re- cover most of the science lost when the ill fated Mars Observer space- craft suffered a catastrophic anomaly in its propulsion system and did not go into orbit. Described in detail are the methods employed by the MGS Sequence Team to accelerate science command processing by using standard command generation process and standard UNIX control scripts.

mars global surveyor mission science instrument co↗

NASA NTRS2020

Toa Baja Disasters: Utilizing Open-Source Earth Observations to Inform the Toa Baja Municipality’s Flood Mitigation Efforts and Educate the Public

Toa Baja, located just west of San Juan in Puerto Rico, is known as “the underwater city” due to its propensity to flood. The city contains the mouth of the island’s longest river, Río de la Plata, which drains into the Atlantic Ocean on the northern edge of the municipality. Proximity to these major water features and the flat, low terrain contribute to the flood-prone nature of the area. During tropical storm events, such as Hurricane Maria in 2017, Toa Baja experienced inundation of up to 20 feet. Changes in the global climate system are causing more intense and frequent tropical storms, making places like Toa Baja subject to irreparable damage. This NASA DEVELOP project collaborated with the Municipio Autónomo de Toa Baja, ResilientSEE, and the Massachusetts Institute of Technology Urban Risk Lab to supplement recent 2018 Federal Emergency Management Agency Hydraulic Engineering Centers-River Analysis System flood maps, which designated 63% of the area as a flood plain. The analysis provides a high-resolution interpretation of flood susceptibility using a variety of factors that collectively influence the likelihood of flooding. Sentinel-1 C-Band Synthetic Aperture Radar (C-SAR) data processed with Google Earth Engine scripting identified historical inundation and was used for validation purposes. Socioeconomic factors were combined with the inundation layer producing a final risk output. These outputs will improve public understanding of exposure to flood risk in Toa Baja and provide scientific evidence for flood mitigation advocacy.

Disasters↗

NASA NTRSDate not supplied

Exit Presentation - Jared Ruzicka

The exit presentation provides an in depth examination of Spring 2020 NIFS intern, Jared Ruzicka’s, work on POST2 including creation of a module containing heritage aerodatabases and manual automation. The aerodatabase module incorporates a variety of legacy fortran and .dat aerodatabases into a POST2 module with example inputdecks verified by MATLAB mex files for 3 and 6 DOF simulations in nominal and dispersed conditions. The manual automation project discusses the transfer of the POST2 User’s Manual from word documents to text-based markdown files and the process through which a python script converts the manual to a PDF with improved formatting and compliance potential in a fraction of current manual generation time.

Jared Ruzicka↗