Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “STEP file”

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.

413 records · Page 23
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

Potential State Regulatory Pathways to Facilitate Low-Carbon Fuels

States and the federal government are increasingly engaged in the challenges around decarbonizing the electric grid. In particular, regulators, consumers, stakeholders, and utilities recognize the need to carefully consider the role natural gas will play in a decarbonized future. A variety of technology and policy options to reduce greenhouse gas emissions associated with natural gas use are available, including energy efficiency programs, demand reduction tools, strategic electrification, and strategies to reduce emissions from natural gas production, transportation, and consumption. Low-carbon fuels – mainly renewable natural gas (RNG) and clean hydrogen – are being considered an important component of decarbonization goals. RNG and hydrogen may be able to meaningfully reduce emissions from processes independent of geologic natural gas, displacing emissions of methane, a powerful greenhouse gas. Although RNG and hydrogen are not cost-competitive today with geologic natural gas and are smaller in scale and potential than other decarbonization options, they can be explored as potential critical tools to decarbonize sectors that are difficult to electrify or shift off of natural gas entirely, such as air travel, industrial processes, maritime transport, long-distance trucking, space heating on cold days, and railroads (Nadel, 2022). The role of this report is to provide informational context for state utility regulators to understand the impacts of and challenges associated with broader integration of low-carbon fuels, followed by examples of state regulatory actions taken to date to facilitate the development of low-carbon fuels. Setting clear guidance to calculate the environmental benefits of low-carbon fuels and continuing federal and state investments in research and development to reduce costs relative to fossil fuels will be important steps to take to signal the desire to grow the market for these fuels. State public utility commissions may play a key role in setting regulatory frameworks for low-carbon fuels and ensuring that ratepayer funds, if utilized, are done so to further the public interest. This report is intended to summarize decisions that states have made to date on low-carbon fuels. In the spirit of understanding the current market and sharing information, this report provides success stories, and lessons learned across states as regulators implement varying strategies to achieve decarbonization objectives while maintaining their focus on affordability, safety, and reliability of the energy system. The report begins with an introduction of the role of natural gas in the U.S. economy (Section I) and background information on natural gas use, decarbonization, and low-carbon fuels (Section II). Next, the report describes the current market by discussing the scale of current production, emissions intensity, resource potential, and costs of low-carbon fuels compared to geologic natural gas (Section III). Following these sections, the report describes four strategies states have employed to facilitate low-carbon fuels: opening exploratory dockets, approving voluntary tariffs for customers, approving interconnection tariffs for producers, and considering portfolio-wide procurement targets (Section IV). This section lists states that have taken actions in each category, citing utility filings, commission decisions, stakeholder comments, and other relevant sources. Finally, the report concludes with suggested questions regulators may wish to consider regarding low-carbon fuels, in the interest of preparing to make decisions in the future (Section V). These questions include: Are there existing regulatory or technical barriers to voluntary purchases of low-carbon fuels? Can customers work with utilities to procure low-carbon fuels; are producers able to interconnect projects without significant barriers to entry? Should the infrastructure and/or commodity costs of low-carbon fuels be socialized among all ratepayers, or borne solely by the large commercial and industrial (C&I) customers currently driving the market? Should regulated natural gas and/or electric utilities own and operate low-carbon fuel production? How should regulators consider the unique decarbonization potential of low-carbon fuels, particularly for hard-to-abate sectors, in decision-making? Is additional direction or clarity from state policymakers needed? What no-regrets approaches can help facilitate both near-term RNG development and long-term development of hydrogen and other zero-carbon fuels? We collectively wish to express our gratitude to the U.S. Department of Energy, Office of Fossil Energy and Carbon Management, for supporting this report and other technical assistance resources for state regulators on natural gas topics. State regulators operate under a variety of policy environments, and states have vastly different types of energy resources, infrastructure, and customers. While there is no optimal regulatory, policy, or technological solution that will be successful in every state, state regulators can benefit by exchanging lessons learned with their peers across the country. We look forward to continued engagement with our fellow commissioners, commission staff, NARUC, the U.S. Department of Energy, and other stakeholders to develop sound regulation in the public interest.

03 NATURAL GAS↗
NASA NTRS1997

Visualization of Unsteady Computational Fluid Dynamics

The current compute environment that most researchers are using for the calculation of 3D unsteady Computational Fluid Dynamic (CFD) results is a super-computer class machine. The Massively Parallel Processors (MPP's) such as the 160 node IBM SP2 at NAS and clusters of workstations acting as a single MPP (like NAS's SGI Power-Challenge array and the J90 cluster) provide the required computation bandwidth for CFD calculations of transient problems. If we follow the traditional computational analysis steps for CFD (and we wish to construct an interactive visualizer) we need to be aware of the following: (1) Disk space requirements. A single snap-shot must contain at least the values (primitive variables) stored at the appropriate locations within the mesh. For most simple 3D Euler solvers that means 5 floating point words. Navier-Stokes solutions with turbulence models may contain 7 state-variables. (2) Disk speed vs. Computational speeds. The time required to read the complete solution of a saved time frame from disk is now longer than the compute time for a set number of iterations from an explicit solver. Depending, on the hardware and solver an iteration of an implicit code may also take less time than reading the solution from disk. If one examines the performance improvements in the last decade or two, it is easy to see that depending on disk performance (vs. CPU improvement) may not be the best method for enhancing interactivity. (3) Cluster and Parallel Machine I/O problems. Disk access time is much worse within current parallel machines and cluster of workstations that are acting in concert to solve a single problem. In this case we are not trying to read the volume of data, but are running the solver and the solver outputs the solution. These traditional network interfaces must be used for the file system. (4) Numerics of particle traces. Most visualization tools can work upon a single snap shot of the data but some visualization tools for transient problems require dealing with time.

Haimes, Robert↗
DOE OSTI2025

NLR HPC Kestrel Jobs Data

Overview: Anonymized job-level records from the Kestrel HPC system at the National Laboratory of the Rockies (NLR). Each record represents a Slurm batch job with scheduling metadata, resource requests, utilization, energy estimates, and efficiency metrics. Sensitive fields (user, account, job name, submit line, working directory, submit script, and job type) are replaced with 7-character cryptographic hashes. System & Timeframe: Kestrel is located at the NLR campus. Standard compute nodes have 104 cores and 256 GB RAM; bigmem nodes have 2,000 GB. GPU nodes (gpu-h100 partition) use NVIDIA H100 GPUs. Data covers jobs submitted August 2023 through December 2025. Funding provided by the U.S. Department of Energy, EERE. Files: esif.hpc.kestrel.job-anon.zip — Anonymized job records (Hive-partitioned Parquet) datacard.md — Full dataset documentation ~11 million rows, 50 variables. Readable with PyArrow, pandas, DuckDB, Apache Spark, or any Parquet-compatible tool. Data Collection: Jobs collected via sacct with timezone-aware export (SLURM_TIME_FORMAT="%Y-%m-%dT%H:%M:%S%z"), loaded into PostgreSQL. Calculated columns updated via database triggers and batch functions. All timestamps use timestamptz and correctly handle DST transitions. Preprocessing: Anonymization of name, user, account, submit_line, work_dir, submit_script, and job_type via 7-char hex hashes Derived columns: queue_wait, cpu_eff, max/min/avg_mem_eff, energy estimates Simplified job state mapping (e.g., "CANCELLED by 132357" → "CANCELLED") Boolean flags: python_job, reframe_job Temporal decomposition: year, month, day, day_of_week, hour, minute from submit_time Shared node tracking: shared_job_count, nodes_shared, jobs_shared Key Variables: Scheduling: job_id, partition, state_simple, submit_time, start_time, end_time, queue_wait Resources: nodes_req/used, processors_req/used, memory_req, wallclock_req/used, gpus_requested Efficiency: cpu_eff, max/min/avg_mem_eff Energy: cpu_energy_tdp_estimated_max/used_watt_hours, consumed_energy_raw_joules, consumed_energy_raw_watt_hours Sharing: shared_job_count, nodes_shared, jobs_shared Partitions: short, standard, debug, gpu-h100 Job States: CANCELLED, COMPLETED, FAILED, PENDING, RUNNING QoS Levels: normal, high Important Notes: Timestamps include timezone offsets; DST transitions are handled correctly, though adding intervals across DST boundaries requires offset adjustment shared_job_count reflects physical node co-residency, not use of the shared partition Job step records and raw Slurm JSONB fields are excluded Do not attempt to re-identify individuals from hashed fields

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Model Inputs, Outputs, and Scripts associated with: “Combined effects of stream hydrology and land use on basin-scale hyporheic zone denitrification in the Columbia River Basin”

This data package is associated with the publication “Combined effects of stream hydrology and land use on basin‐scale hyporheic zone denitrification in the Columbia River Basin”, published in Water Resource Research (Son et al.2022) available at https://doi.org/10.1029/2021WR031131. This data package includes the key model inputs/outputs of the river corridor model for the Columbia River Basin (CRB) and the model source codes used in the manuscript. The model is a carbon-nitrogen-coupled river corridor model (RCM), and the model is used to quantify hyporheic zone (HZ) denitrification at the NHDPLUS stream reach scales. The RCM used in this study combines empirical substrate models derived from observations and three microbially driven reactions, including two-step denitrification and aerobic respiration, are considered within the HZ. The key input data of the model are exchange flux, residence time, and stream solute (dissolved organic carbon (DOC), dissolved oxygen (DO), and nitrate concentrations). These inputs are constant over time and represent long-term averaged values. This study uses the RCM to explore the spatial patterns of HZ denitrification across reaches with different sizes and land use in the CRB. Our main objective is to use the RCM as a virtual reality model, and the machine-learning models as surrogates that encapsulate the complexities of the physics-based model while identifying the importance of different variables that are not evident in the model conceptualization. We do not include a direct comparison of the modeled HZ denitrification and measurements; however, the RCM can capture the overall spatial patterns of the HZ denitrification because the model inputs and its reaction networks are based on well-established theory and a physical-based model. The combination of the model-based predictions and a machine-learning approach (e.g., random forest) is used to improve our understanding of what variables of the model are associated with spatial patterns of the modeled denitrification across reaches with different sizes and land uses, and to develop a proxy model using measurable variables to reproduce the simulated patterns.This dataset contains five folders: (1) model_inputs, (2) model_outputs, (3) Rscripts, (4) figures, and (5) model_codes. It also contains a readme, file level metadata (FLMD), and data dictionary (dd). Please see the FLMD for a list of all the files contained in this data package and descriptions for each. The model_inputs folder contains the model inputs used to drive the model simulations. The model_outputs folder contains key model output files from the river corridor model. The Rscripts folder contains the Rscripts for pre- and post- processing model results. The figures folder contains the raw figures associated with the manuscript. The model_codes folder includes key model source codes/input files. All files are .jpg, .jpeg, .out, .e, .od, .dat, .sub, .F90, .0, .R, .sbx, .cpg, .sbn, .shx, .shp, .dbf, .prj, .tfw, .tif, .xml, .pdf, or .csv.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2017

NASA's EOSDIS, Trust and Certification

NASA's Earth Observing System Data and Information System (EOSDIS) has been in operation since August 1994, managing most of NASA's Earth science data from satellites, airborne sensors, filed campaigns and other activities. Having been designated by the Federal Government as a project responsible for production, archiving and distribution of these data through its Distributed Active Archive Centers (DAACs), the Earth Science Data and Information System Project (ESDIS) is responsible for EOSDIS, and is legally bound by the Office of Management and Budgets circular A-130, the Federal Records Act. It must follow the regulations of the National Institute of Standards and Technologies (NIST) and National Archive and Records Administration (NARA). It must also follow the NASA Procedural Requirement 7120.5 (NASA Space Flight Program and Project Management). All these ensure that the data centers managed by ESDIS are trustworthy from the point of view of efficient and effective operations as well as preservation of valuable data from NASA's missions. Additional factors contributing to this trust are an extensive set of internal and external reviews throughout the history of EOSDIS starting in the early 1990s. Many of these reviews have involved external groups of scientific and technological experts. Also, independent annual surveys of user satisfaction that measure and publish the American Customer Satisfaction Index (ACSI), where EOSDIS has scored consistently high marks since 2004, provide an additional measure of trustworthiness. In addition, through an effort initiated in 2012 at the request of NASA HQ, the ESDIS Project and 10 of 12 DAACs have been certified by the International Council for Science (ICSU) World Data System (WDS) and are members of the ICSUWDS. This presentation addresses questions such as pros and cons of the certification process, key outcomes and next steps regarding certification. Recently, the ICSUWDS and Data Seal of Approval (DSA) organizations merged their Core Trustworthy Data Repositories Requirements and require that members be recertified every three years. Given the rigor with which NASA manages the ESDIS Project and the DAACs, the recertification through WDSDSA, while involving some additional work, is a relatively simple process.

Certification↗
DOE OSTI2026

Sensitivity Analysis of Drivers Water Shortage in the Los Angeles Region During Drought

The code and detailed step-by-step instructions for generating the model output data, processing results, and analysis and plotting are provided at https://github.com/IMMM-SFA/Ferencz_et_al_2026_ER_Water. The PyArtes model is a python adaptation of the Artes model. PyArtes uses many of the same input data and optimization model architecture as Artes. Documentation for the PyArtes model is provided in the Supplement to the paper. The primary data product are simulated monthly water shortages for indoor and outdoor demand under a large ensemble of drought scenarios (>13,000). The droughts are hypothetical and are not based on historical time series data of supply sources - though historical data did help inform ranges explored for supply parameters. Demands are informed by recent 2017-2021 water supply data. Demands used for the model can be accessed at https://github.com/IMMM-SFA/Ferencz_et_al_2026_ER_Water. Simulations resolve demand for over 90 water providers in the study region. The results report 36 months of water shortage data for each indoor and outdoor demand node. The study also developed a multilayer perceptron (MLP) neural network trained on a subset of the simulated shortage ensemble to emulate worst annual water shortage for a given set of parameter multipliers -- provided the parameter values fall within the ranges sampled in the ensemble. Emulated water shortages for synthetic ensembles are in the MLP-generated shortages folder. The MLP model was used to generate larger ensembles to support Sobol analysis that would have been extremely computationally expensive to simulate. Datasets provided in this repository*: Simulated shortages. These results are used for the analysis for Figures 5, 8, and 9 in the paper, and also to train the MLP emulator. .zip file containing outputs for the 13,312 scenario ensemble. Separate .csv files for indoor and outdoor shortage for each scenario. Rows = demand ids (~100), Columns = months (36) Units = acre-feet/month of shortage (shortage = monthly demand - supply). 1 acft = 1233.48 m^3 .csv files of aggregated shortages derived from the 13,312 ensemble Rows = scenarios (13,312), Columns = demand ids (~100) Units = acre-feet/year (either worst annual shortage or total shortage over the 3-year drought) .csv file of the parameter multipliers scenarios for the ensemble .csv file of the parameter ranges and baseline values the multipliers were applied to MLP-generated shortages. These results are used for Figures 4, 6, and 7 in the paper. mwd higher folder: scenario ensembles, emulated worst year total shortages (acft), and Sobol results Emulated shortages. Rows = scenarios, columns = demand ids, units acft Sobol results. Rows = demand ids, columns Sobol (S1, ST, or 95% confidence interval) value for each parameter mwd lower folder: scenario ensembles, emulated worst year total shortages (acft), and Sobol results same organization as mwd higher MLP performance: performance metrics (R^2, RMSE, BIAS, MAPE) for the testing subset (20% or 2,662 scenarios) and simulated vs emulated worst year shortage (acre-feet/year) for every demand node, MWD wholesale regions, and the entire study region (LAC). Supporting data for figures. Figure plotting scripts in the associated GitHub repo. These files support analysis and visualization. Geospatial Data used for plotting simulated water shortages and Sobol results. Dictionary of full names for demand nodes in the model and estimates of water supply by source type informed by Artes input files and California Urban Water Management Planning data: https://water.ca.gov/Programs/Water-Use-And-Efficiency/Urban-Water-Use-Efficiency/Urban-Water-Management-Plans *Readme files provided for each folder.

drought↗
DOE OSTI2025

NLR HPC Eagle Jobs Data and Additional Energy Metrics

Overview: Anonymized job-level records from the Eagle high-performance computing (HPC) system at the National Laboratory of the Rockies (NLR). Each record represents a Slurm batch job with scheduling metadata, resource requests, resource utilization, CPU/GPU energy consumption, and efficiency metrics. Sensitive fields (user, account, job name) are replaced with cryptographic hashes. System & Timeframe: Eagle was a 2,000-node, 8-petaflop system operated at NLR from 2019–2024. Data covers the full operational lifetime of the system. Slurm data was processed nightly; timestamps are in Mountain Time. Funding provided by the U.S. Department of Energy, EERE. Files: esif.hpc.eagle.job-anon.zip — Core anonymized job records (Hive-partitioned Parquet) esif.hpc.eagle.job-anon-energy-metrics.zip — Same records with additional iLO and Ganglia energy metrics datacard.md — Full dataset documentation ~13.8 million rows, 62 variables. Readable with PyArrow, pandas, DuckDB, Apache Spark, or any Parquet-compatible tool. Data Collection: Jobs collected via sacct through a pipeline: Eagle Jobs API → Redpanda → StreamSets → HPCMON API → PostgreSQL. Node-level power from iLO (HP Integrated Lights-Out); GPU power from Ganglia monitoring, joined to jobs via node lists and time ranges. Preprocessing: Anonymization of name, user, and account fields via cryptographic hashing Derived columns: queue_wait, cpu_eff, max_mem_eff Simplified job state mapping (e.g., "CANCELLED BY 12345" → "CANCELLED") QoS accounting rules (buy-in, standby, or Slurm QoS value) CPU energy estimated from TDP (200W, Intel Xeon Gold 6154, 18 cores) Timezone-aware columns (_tz) sourced from LEX accounting database to correctly handle DST transitions Key Variables: Scheduling: job_id, partition, state_simple, submit_time_tz, start_time_tz, end_time_tz, queue_waitResources: nodes_req/used, processors_req/used, memory_req, wallclock_req/used, gpus_requested Efficiency: cpu_eff, max_mem_eff Energy: cpu_energy_tdp_estimated_max/used_watt_hours, node_energy_total_watt_hours (iLO), gpu0/1_energy_total_watt_hours (Ganglia) Partitions: bigmem, bigmem-8600, bigscratch, csc, dav, ddn, debug, gpu, haswell, long, mono, short, standard Job States: CANCELLED, COMPLETED, FAILED, NODE_FAIL, OUT_OF_MEMORY, PENDING, RUNNING, TIMEOUT QoS Levels: Unknown, normal, buy-in, debug, penalty, high, standby Important Notes: Non-_tz timestamp columns may be off by one hour across DST boundaries; use _tz columns for time difference calculations Energy fields are null for jobs without monitoring coverage Job step records and raw Slurm JSONB fields are excluded from this extract Do not attempt to re-identify individuals from hashed fields

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2020

On Development of Three-Dimensional Visualization Capabilities in Glenn Research Center Communication Analysis Suite

With NASA’s upcoming mission to return to the Moon sustainably by 2024 and using that success as a means to step onto the barren world of Mars, it remains more important than ever to conduct research and planning as thoroughly and efficiently as possible. In a mission as complex as landing humans onto another celestial body, a network of orbiting satellites and ground stations must accurately and reliably communicate with each other, enabling crucial data communications throughout the mission. Visualizing this important data communication increases the understanding of the data and can accelerate analyses efforts. The purpose of this software development is to create an interactive visualization with data taken MATLAB® scripts in the GRC Communication Analysis Suite that is easy to understand, can show all necessary data, and display the data accurately. The main types of data to visualize are from the State Propagation, Line of Sight and Dynamic Link Margin scripts. These all show positions and orbits of satellites and ground stations, while the Line of Sight data shows when they have the ability to communicate with each other based on their respective antenna positions and fields of view. Additionally, the Dynamic Link Margin mode color-codes the communication link performance onto the Line of Sight access lines. Visualization requires a graphics language that is easily accessible, has the needed features, and able to easily read data produced by the GRC Communication Analysis Suite MATLAB® scripts. ThreeJS, a graphics library for Web Graphics Library, coded in JavaScript was selected for the visualization. The next part of the software development was to move the data from MATLAB® to the JavaScript. The best way to accomplish this was to implement a MATLAB® function converting the output data of the scripts to a JavaScript Object Notation file. A key part of the development was creating the visualization within JavaScript and ThreeJS to visualize any combination of planets, moons, orbits, satellites, ground stations, line of sight links, and handle future features without changing major parts of the code. The current visualization capability runs directly from MATLAB®, and can dynamically create any scene. This software development currently supports the lunar communications analysis underway by NASA, and can be easily expanded upon in the future to aid any analysis requirements to help plan current and future space missions.

Visualization↗
NASA NTRS2005

NASA GES DISC On-line Visualization and Analysis System for Gridded Remote Sensing Data

The ability to use data stored in the current NASA Earth Observing System (EOS) archives for studying regional or global phenomena is highly dependent on having a detailed understanding of the data's internal structure and physical implementation. Gaining this understanding and applying it to data reduction is a time-consuming task that must be undertaken before the core investigation can begin. This is an especially difficult challenge when science objectives require users to deal with large multi-sensor data sets that are usually of different formats, structures, and resolutions. The NASA Goddard Earth Sciences Data and Information Services Center (GES DISC) has taken a major step towards meeting this challenge by developing an infrastructure with a Web interface that allows users to perform interactive analysis online without downloading any data, the GES-DISC Interactive Online Visualization and Analysis Infrastructure or "Giovanni." Giovanni provides interactive, online, analysis tools for data users to facilitate their research. There have been several instances of this interface created to serve TRMM users, Aerosol scientists, Ocean Color and Agriculture applications users. The first generation of these tools support gridded data only. The user selects geophysical parameters, area of interest, time period; and the system generates an output on screen in a matter of seconds. The currently available output options are: Area plot averaged or accumulated over any available data period for any rectangular area; Time plot time series averaged over any rectangular area; Hovmoller plots image view of any longitude-time and latitude-time cross sections; ASCII output for all plot types; Image animation for area plot. Another analysis suite deals with parameter intercomparison: scatter plots, temporal correlation maps, GIs-compatible outputs, etc. This allow user to focus on data content (i.e. science parameters) and eliminate the need for expensive learning, development and processing tasks that are redundantly incurred by an archive's user community. The current implementation utilizes the GrADS-DODS Server (GDS), and provides subsetting and analysis services across the Internet for any GrADS-readable dataset. The subsetting capability allows users to retrieve a specified temporal and/or spatial subdomain from a large dataset, eliminating the need to download everything simply to access a small relevant portion of a dataset. The analysis capability allows users to retrieve the results of an operation applied to one or more datasets on the server. We use this approach to read pre-processed binary files and/or to read and extract the needed parts directly from HDF or HDF-EOS files. These subsets then serve as inputs into GrADS analysis scripts. It can be used in a wide variety of Earth science applications: climate and weather events study and monitoring; modeling. It can be easily configured for new applications.

Leptoukh, Gregory G.↗
NASA NTRS2011

General Tool for Evaluating High-Contrast Coronagraphic Telescope Performance Error Budgets

The Coronagraph Performance Error Budget (CPEB) tool automates many of the key steps required to evaluate the scattered starlight contrast in the dark hole of a space-based coronagraph. The tool uses a Code V prescription of the optical train, and uses MATLAB programs to call ray-trace code that generates linear beam-walk and aberration sensitivity matrices for motions of the optical elements and line-of-sight pointing, with and without controlled fine-steering mirrors (FSMs). The sensitivity matrices are imported by macros into Excel 2007, where the error budget is evaluated. The user specifies the particular optics of interest, and chooses the quality of each optic from a predefined set of PSDs. The spreadsheet creates a nominal set of thermal and jitter motions, and combines that with the sensitivity matrices to generate an error budget for the system. CPEB also contains a combination of form and ActiveX controls with Visual Basic for Applications code to allow for user interaction in which the user can perform trade studies such as changing engineering requirements, and identifying and isolating stringent requirements. It contains summary tables and graphics that can be instantly used for reporting results in view graphs. The entire process to obtain a coronagraphic telescope performance error budget has been automated into three stages: conversion of optical prescription from Zemax or Code V to MACOS (in-house optical modeling and analysis tool), a linear models process, and an error budget tool process. The first process was improved by developing a MATLAB package based on the Class Constructor Method with a number of user-defined functions that allow the user to modify the MACOS optical prescription. The second process was modified by creating a MATLAB package that contains user-defined functions that automate the process. The user interfaces with the process by utilizing an initialization file where the user defines the parameters of the linear model computations. Other than this, the process is fully automated. The third process was developed based on the Terrestrial Planet Finder coronagraph Error Budget Tool, but was fully automated by using VBA code, form, and ActiveX controls.

Marchen, Luis F.↗
NASA NTRS2004

Distributive On-line Processing, Visualization and Analysis System for Gridded Remote Sensing Data

The ability to use data stored in the current Earth Observing System (EOS) archives for studying regional or global phenomena is highly dependent on having a detailed understanding of the data's internal structure and physical implementation. Gaining this understanding and applying it to data reduction is a time- consuming task that must be undertaken before the core investigation can begin. This is an especially difficult challenge when science objectives require users to deal with large multi-sensor data sets that are usually of different formats, structures, and resolutions, for example, when preparing data for input into modeling systems. The NASA Goddard Earth Sciences Data and Information Services Center (GES DISC) has taken a major step towards meeting this challenge by developing an infrastructure with a Web interface that allows users to perform interactive analysis online without downloading any data, the GES-DISC Interactive Online Visualization and Analysis Infrastructure or "Giovanni." Giovanni provides interactive, online, analysis tools for data users to facilitate their research. There have been several instances of this interface created to serve TRMM users, Aerosol scientists, Ocean Color and Agriculture applications users. The first generation of these tools support gridded data only. The user selects geophysical parameters, area of interest, time period; and the system generates an output on screen in a matter of seconds. The currently available output options are: Area plot averaged or accumulated over any available data period for any rectangular area; Time plot time series averaged over any rectangular area; Time plots image view of any longitude-time and latitude-time cross sections; ASCII output for all plot types; Image animation for area plot. In the future, we will add correlation plots, GIS-compatible outputs, etc. This allow user to focus on data content (i.e. science parameters) and eliminate the need for expensive learning, development and processing tasks that are redundantly incurred by an archive's user community. The current implementation utilizes the GrADS-DODS Server (GDS), a stable, secure data server that provides subsetting and analysis services across the Internet for any GrADS-readable dataset. The subsetting capability allows users to retrieve a specified temporal and/or spatial subdomain from a large dataset, eliminating the need to download everything simply to access a small relevant portion of a dataset. The analysis capability allows users to retrieve the results of an operation applied to one or more datasets on the server. In our case, we use this approach to read pre-processed binary files and/or to read and extract the needed parts from HDF or HDF-EOS files. These subsets then serve as inputs into GrADS processing and analysis scripts. It can be used in a wide variety of Earth science applications: climate and weather events study and monitoring; modeling. It can be easily configured for new applications.

Leptoukh, G.↗
NASA NTRS2004

Microgravity Spray Cooling Research for High Powered Laser Applications

An extremely powerful laser is being developed at Goddard Space Flight Center for use on a satellite. This laser has several potential applications. One application is to use it for upper atmosphere weather research. In this case, the laser would reflect off aerosols in the upper atmosphere and bounce back to the satellite, where the aerosol velocities could be calculated and thus the upper atmosphere weather patterns could be monitored. A second application would be for the US. Air Force, which wants to use the laser strategically as a weapon for satellite defense. The Air Force fears that in the coming years as more and more nations gain limited space capabilities that American satellites may become targets, and the laser could protect the satellites. Regardless of the ultimate application, however, a critical step along the way to putting the laser in space is finding a way to efficiently cool it. While operating the laser becomes very hot and must be cooled to prevent overheating. On earth, this is accomplished by simply running cool tap water over the laser to keep it cool. But on a satellite, this is too inefficient. This would require too much water mass to be practical. Instead, we are investigating spray cooling as a means to cool the laser in microgravity. Spray cooling requires much less volume of fluid, and thus could be suitable for use on a satellite. We have inherited a 2.2 second Drop Tower rig to conduct our research with. In our experiments, water is pressurized with a compressed air tank and sprayed through a nozzle onto our test plate. We can vary the pressure applied to the water and the temperature of the plate before an experiment trial. The whole process takes place in simulated microgravity in the 2.2 second Drop Tower, and a high speed video camera records the spray as it hits the plate. We have made much progress in the past few weeks on these experiments. The rig originally did not have the capability to heat the test plate, but I did some heat transfer calculations and picked out a heater to order for the rig. I learned QBasic programming language to change the operating code for our drops, allowing us to rapidly cycle the spray nozzle open and closed to study the effects. We have derived an equation for flow rate vs. pressure for our experiment. We have recorded several videos of drops at different pressures, some with heated test plate and some without, and have noticed substantial differences in the liquid behavior. I have also changed the computer program to write a file with temperature vs. time profiles for the test plate, and once the necessary thermocouple comes in (it was ordered last week), we will have temperature profiles to accompany the videos. Once we have these temperature profiles to go with the videos, we will be able to see how the temperature is affected by the spray at different pressures, and how the spray changes its behavior once as the plate changes from hot to cool. With quantitative temperature data, we can then mathematically model the heat transfer from the plate to the cooling spray. Finally, we can look at the differences between trials in microgravity and those in normal earth gravity.

Zivich, Chad P.↗
DOE OSTI2024

Surface elevation, snow depth, vegetation height, and color imagery from multiple UAV surveys from 2018 to 2023 across a watershed near Teller road mile marker 27, Seward Peninsula, Alaska

Multiple photogrammetric surveys using an unoccupied aerial system (UAS) were performed across a watershed along Teller road on the Seward Peninsula (Alaska) to investigate terrain, vegetation and snowpack properties. This work was led by the environmental geophysics team from Lawrence Berkeley National Laboratory as part of the Next-Generation Ecosystem Experiments: Arctic (NGEE Arctic). The multiple photogrammetric surveys used mostly a DJI Matrice 210 UAS with a DJI X5S camera, Ground Control Points (GCPs) surveyed with a Real Time Kinematic (RTK)-GPS, and a structure from motion (SfM) technique for photogrammetric reconstruction. Digital Surface elevation Models (DSMs) were inferred at various times of year, including near peak in plant and leaf density (July 19 2017), close to peak in snow depth (April 1 2019 and April 11 2022), and at low plant and leaf density of tall after the first bare-ground date (June 9 2019). Snow and canopy height were obtained by subtracting DSMs from a Digital Terrain Model (DTM) proxy inferred from the June 9 2019 survey. The derived products include ortho-mosaiced RGB map, DSMs, a DTM proxy, snow depth (April 2019 and 2022) and canopy height (July 2017). Unprocessed and processed data products are included in this package (processing levels 0-2). Data and metadata are provided as text (*.csv), image (*.jpg), and GeoTiff (*.tif) formats. This metadata document contains a description of the survey and processing steps and the inferred products.The Next-Generation Ecosystem Experiments: Arctic (NGEE Arctic) was a 15-year research effort (2012-2027) to reduce uncertainty in Earth System Models by developing a predictive understanding of carbon-rich Arctic ecosystems and feedbacks to climate. NGEE Arctic was supported by the Department of Energy’s Office of Biological and Environmental Research. The NGEE Arctic project had two field research sites: 1) located within the Arctic polygonal tundra coastal region on the Barrow Environmental Observatory (BEO) and the North Slope near Utqiagvik (Barrow), Alaska and 2) multiple areas on the discontinuous permafrost region of the Seward Peninsula north of Nome, Alaska. Through observations, experiments, and synthesis with existing datasets, NGEE Arctic provided an enhanced knowledge base for multi-scale modeling and contributed to improved process representation at global pan-Arctic scales within the Department of Energy’s Earth system Model (the Energy Exascale Earth System Model, or E3SM), and specifically within the E3SM Land Model component (ELM).

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2003

Developing a MATLAB(registered)-Based Tool for Visualization and Transformation

An important step in the structural design and development of spacecraft is the experimental identification of a structure s modal characteristics, such as its natural frequencies and modes of vibration. These characteristics are vital to developing a representative model of any given structure or analyzing the range of input frequencies that can be handled by a particular structure. When setting up such a representative model of a structure, careful measurements using precision equipment (such as accelerometers and instrumented hammers) must be made on many individual points of the structure in question. The coordinate location of each data point is used to construct a wireframe geometric model of the structure. Response measurements obtained from the accelerometers is used to generate the modal shapes of the particular structure. Graphically, this is displayed as a combination of the ways a structure will ideally respond to a specified force input. Two types of models of the tested structure are often used in modal analysis: an analytic model showing expected behavior of the structure, and an experimental model showing measured results due to observed phenomena. To evaluate the results from the experimental model, a comparison of analytic and experimental results must be made between the two models. However, comparisons between these two models become difficult when the two coordinate orientations differ in a manner such that results are displayed in an unclear fashion. Such a problem proposes the need for a tool that not only communicates a graphical image of a structure s wireframe geometry based on various measurement locations (called nodes), but also allows for a type of transformation of the image s coordinate geometry so that a model s coordinate orientation is made to match the orientation of another model. Such a tool should also be designed so that it is able to construct coordinate geometry based on many different listings of node locations and is able to transform the wireframe coordinate orientation to match almost any possible orientation (i.e. it should not be a problem specific application) if it is to be of much value in modal analysis. Also, since universal files are used to store modal parameters and wireframe geometry, the tool must be able to read and extract information from universal files and use these files to exchange model data.The purpose of this project is to develop such a tool as a computer graphical user interface (GUI) capable of performing the following tasks: 1) Browsing for a particular universal file within the computer directory and displaying the name of this file to the screen; 2) Plotting each of the nodes within the universal file in a useful, descriptive, and easily understood figure; 3) Reading the node numbers from the selected file and listing these node numbers to the user for selection in an easily accessible format; 4) Allowing for user selection of a new model orientation defined by three selected nodes; and 5) Allowing the user to specify a directory to which the transformed model s node locations will be saved, and saving the transformed node locations to the specified file.

Anderton, Blake J.↗
NASA NTRSDate not supplied

Monitoring Airspace Complexity and Determining Contributing Factors

The national airspace has evolved over many years to accommodate increased traffic demand [1] while simultaneously maintaining one of the safest forms of transportation [2], [3]. One of the reasons for this success is the ability of the system and the operators to adapt and accommodate to situations that routinely disrupt optimal operations. These situations may include: adverse weather, delays, early arrivals, equipment outages, and other factors that are outside the operators ability to control. These factors can lead to states where automation is unable to properly handle these issues and therefore air traffic controllers and pilots have to intervene, ultimately increasing communication between operators resulting in higher workload. As controller workload increases to handle sub-optimal operating conditions this can be viewed as an increase in complexity. The reasoning for this is because humans are now required to make tactical decisions in response to external factors, resulting in a departure from the strategic plan where operations would be more efficiently managed. Human operators control airspace complexity under rigid regulations that are constantly changing. The airspace is divided into sectors and the number of aircraft assigned to each controller is limited for safe handling. There has been past work that devised airspace complexity metrics in commercial aviation and related these metrics to controller workload (e.g., [4],[5]). The upper bounds on the system load are pre-determined. Such bounds on complexity make for a safe system, but the system cannot scale and adapt to autonomous, dense, and heterogeneous traffic, including the many types of Unmanned Aerial Vehicles (UAVs) envisioned to be added to the operations. We hypothesize that, as traffic density and heterogeneity grow, and other key metrics change, there will be phase transitions at which the way traffic should be managed changes significantly [6]. We offer a method for in-time detection of contributing factors that lead to phase transitions, characterized by increased complexity. To the best of our knowledge, there is no tool similar to our proposed effort that identifies such contributing factors or precursor patterns. To define the scope we are proposing to measure complexity from the viewpoint of the Terminal Radar Approach Control Facilities (TRACON) controller’s perspective. In particular we are analyzing arrivals into KSFO. With safety as the top concern for airspace operators, it is important to recognize that as density and heterogeneity grow, the focus of the system will change. Times of the day when the airspace has low density and heterogeneity, the flights will follow more efficient paths where the aircraft move on established routes that are more or less directly to the destination. However, when density and heterogeneity increases, the system will begin changing focus to avoiding conflicts and collisions and route the flights in a more flexible way. Higher flexibility requires more communication and coordination between controllers and pilots which the current automation is unable to handle. This paper proposes a novel approach that monitors airspace complexity at multiple scales, uses a Machine Learning-based tool that predicts when operations will transition to a regime of greater complexity, and identifies actions that can reduce the complexity while still maintaining efficient and safe operations. We demonstrate our proposed approach using data from multiple complementary sources. This includes, but is not limited to: historical aircraft surveillance data from NASA’s Sherlock Data Warehouse [7], METAR weather data, and airport configuration data from Aviation System Performance Metrics (ASPM). The surveillance data flight paths are sampled at a variable sample rate — increasing as the aircraft approaches the airport. This is due to how Sherlock manages flight track stitching between different radar facilities which have different sampling rates. The weather and performance data are logged at defined intervals throughout the day at a courser refresh rate. In addition to the logged data and metrics, we leverage pre-defined Standard Terminal Arrival Routes (STARs) procedures to characterize the path of each flight. Each flight files for one of these routes in the flight plan well before entering the terminal airspace, and approximately follows the route until it leaves the STAR, typically on the final fix of a runway transition. However, most flights do not always fly the full STAR procedure to completion [8], but the majority do adhere to the fixes within the common route of the procedure. Our approach leverages fixes in the common route of each of the STARs to build a reference path to the airport. This allows us to characterize the flight paths in what we are defining as the “maneuvering area” (the airspace between the STAR and before the flight is lined up on the runway’s final approach) to determine how off nominal the flights are to calculate its complexity score. Determining airspace complexity is a concept that does not have a concrete answer. In designing this metric, we consider what increases the workload for the air traffic controllers. Consequently more specialized vectoring maneuvers results in higher workload. Accordingly, we start with a theory: each flight has a direct path it takes from the STAR’s common route to the final approach’s outer marker fix for the flight’s landing runway. It is important to note that the direct path is only used as a reference. If the majority of the flights have a large consistent offset as compared to other routes it does not necessarily mean that those flights have higher complexity. We are merely building a distribution based on this direct path for that particular STAR and runway pair to determine the normal mode of operations for that route. Flights that are in the upper tail of these distributions will result in higher complexity scores and flights that fly in the median will represent the normal mode of operations and therefore will have lower complexity scores. Since flights following each STAR route take different paths to the airport, we have a different distribution for each STAR route and therefore can model these distributions to compute a complexity score from their respective normalized distributions. To evaluate the effectiveness of our proposed airspace complexity metric we will compare against an established approach based on trajectory clustering [9]. This unsupervised learning technique consists of the following steps: (1) identify the general maneuvering areas (waypoints) by performing $\kappa$-means or DBSCAN clustering on locations where aircraft frequently turn based on the surveillance radar track data, (2) map flight trajectories onto sequences of waypoints, and (3) cluster the sequences based on their common subsequences. From a high-level perspective, this baseline model learns nominal operations in the airspace through the sequence of waypoints that are representative of where aircraft change direction and defines deviations from the nominal operations as “complex.” Therefore, more deviations from the nominal operations correspond to higher complexity values. For our validation, we re-implemented this technique and tune model hyper-parameters to correctly detect waypoints for the arrival traffic into the San Francisco bay area. We will compute the complexity measure over a one-year period using our proposed technique as well as the baseline. Our validation will be based on each technique’s ability to detect a set of undesirable outcomes (e.g., go-arounds, holding patterns, average time in the airspace, etc.). Since our current complexity metric is derived from the offset from the direct reference path, it’s important to understand what causes these offsets. In many of the flights with high offset distance, flights performing holding patterns and S turns can be observed. These maneuvering tactics are utilized to add distance between the aircraft and the destination runway to prevent multiple flights from having conflicting arrival times. In order to predict a rise in complexity (or the precursor to complexity), it’s necessary to be able to identify these potential conflicts (which in turn, result in higher offsets). To do this, we define a “representative flight” for each STAR route and runway pair. This flight is approximately the path the flight would take if there was a clear path with no other flights in the airspace — including the time remaining to the airport. We first identify the flights for a given STAR runway pair using the offset to the reference path distributions that fall between the 44-55 percentiles. This yields the flights that conform to the most normal mode of operation. Each of these flights is partitioned based on the percent complete from the entry point into the maneuvering areas from 0\% – 100\% complete. Then for each percent “bin”, we take the median value of the flight’s latitude/longitude coordinates, airspeed, and (non causal) time remaining to the airport to construct a lookup table for each percent complete bin on a given route. As a flight enters the maneuvering area, we can find the estimated arrival time of a flight to the airport by finding the closest point to the representative path’s percent complete bin (relative to the flight’s current position at any snapshot in the airspace) and therefore retrieve the corresponding remaining time left on the “representative path”. We assume that the flight will follow the representative path to completion when deriving these estimates. We can then compare these estimated arrival times against other flights for the same snapshot in time to identify potential conflicts. If more flights are estimated to arrive within a tolerance window than there are runways available, then we have a potential conflict. We can use this derived measure along with other factors expected to add disruption to the operation such as weather and runway configuration changes as an input to machine learning tools to detect precursors that increases in our complexity measure. This novel method will assist in uncovering insights into the contributing factors that lead to increased complexity that may allow for in-time responses to avoid reaching a high complexity state in the airspace.

complexity↗
DOE OSTI2022

Current Progress of the Final Design of a Subcritical Assembly at the Oak Ridge National Laboratory

During the past decade, the US Department of Energy (DOE)/National Nuclear Security Administration (NNSA) Nuclear Criticality Safety Program (NCSP) has been coordinating nuclear criticality safety (NCS) courses to provide training and qualification to new staff, supervisors, managers, regulators, and other professionals involved with NCS. To address the growing need for more NCS training possibilities, a subcritical assembly was designed at Oak Ridge National Laboratory (ORNL). The Oak Ridge Subcritical Assembly (ORSA), operated at ORNL, could be used in a new course for fissile material handlers/operators or as a backup training facility for currently existing NCSP hands-on NCS training. This paper describes some of the design steps necessary for obtaining a final ORSA design, beginning with a successful feasibility study performed in 2020. Numerous parameters within each main element of the assembly were considered, such as the reflector used, the type of fuel coating or plating used, and the number of fuel plates used. The design choices related to each parametric study described in this paper are detailed and justified at the end of each subsection. An overview of the current final design characteristics of ORSA and the experiments’ possibilities is also provided. ORSA will be built with fuel plates from legacy Aerojet General Nucleonics (AGN)-201M research reactors currently stored at the Y-12 National Security Complex (Y-12). The cylindrical fuel plates comprise UO 2 particles embedded in polyethylene and have a nominal enrichment of 19.5 ± 0.5 wt % 235 U. The basis for the final design was the feasibility study from 2020. In the feasibility study, ORSA achieved k eff = 0.95, corresponding to a multiplication factor of 20, with approximately 620 g of 235 U (four 4 cm plates, three 2 cm plates, and two 1 cm plates) and an 8.5 cm thick graphite reflector radially and on top of the assembly. The bottom of the assembly has a graphite thickness of 5 cm, and the chosen graphite density was 2.3 g/cm 3 . All design calculations were performed using SCALE 6.2.4 KENO-VI and with the ENDF/B VII.1 Continuous Energy cross-section library.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2026

CHESS 2025: Spectrometer orthorectified at-sensor radiance from NEON AOP imaging spectroscopy surveys

This dataset provides Level 1 (L1) orthorectified at-sensor radiance derived from measurements collected by the Imaging Spectrometer-1 (NIS-1) onboard the NEON (National Ecological Observatory Network) Airborne Observation Platform (AOP) for the 2025 Colorado Headwaters Ecological Spectroscopy Study (CHESS). NIS-1 captures light reflected from the Earth’s surface in 426 discrete wavelength bands as raw digital numbers (DNs; Level 0). These data are then calibrated to physical units (uW/cm²·sr·nm) following the processing steps described in the NEON Imaging Spectrometer Level 1B Calibrated Radiance Algorithm Theoretical Basis Document (ATBD; Gallery 2022). The data delivered here are the primary inputs for the surface reflectance product in “Custom surface reflectance, shade masks, and equivalent water thickness maps for the Colorado Headwaters Ecological Spectroscopy Study” (Carroll et al. 2026). For intertemporal comparison, the radiance data here are most directly relatable to the v2 radiance data in “NEON AOP Imaging Spectroscopy Survey of Upper East River Colorado Watersheds: Raw-Space Radiance and Observational Variable Dataset” (Goulden et al. 2018), to which the same processing methodology was applied. Together, the radiance and reflectance data enable users to exploit the unique reflection signatures of different surface objects for land cover classification, foliar trait mapping, plant vigor assessment, water content estimation, trace-element identification, and other scientific applications. The data were acquired over three study domains in the Upper Gunnison river basin: the upper East River watershed (CRBU); Almont Triangle and Taylor Canyon (ALMO); and Upper Taylor River watershed (UPTA) between 2025-06-13 and 2025-07-15. Within each domain, data are delivered by flightline as orthorectified and calibrated hyperspectral rasters in Hierarchical Data Format version 5 (HDF5) format, with radiance values provided in uW/cm²·sr·nm on a fixed, uniform Universal Transverse Mercator (UTM) grid at 1 meter spatial resolution. The radiance rasters include all 426 NIS-1 spectral bands, along with associated quality-assurance (QA) and diagnostic and ancillary layers needed for atmospheric correction workflows. Orthorectified radiance is produced from pushbroom spectrometer observations by applying NEON’s radiometric calibration (including bad pixel masking, dark subtract, dark pedestal shift correction, electronic panel ghost correction, grating ghost correction, deblur correction and flat-fielding) and spectral calibration (using spectral response function band centers and full-width at half-maximum intensity), followed by geolocation and regridding to the fixed grid. CHESS Project Description: The Colorado Headwaters Ecological Spectroscopy Study (CHESS) comprised a multi-week airborne remote sensing and field observation campaign in the Upper Gunnison Basin, Colorado, conducted in June and July of 2025. Airborne remote sensing was conducted by the National Ecological Observatory Network Airborne Observation Platform (NEON AOP), concurrent with a field campaign run by the Rocky Mountain Biological Laboratory (RMBL), the Lawrence Berkeley National Laboratory (LBNL) and SLAC National Accelerator Laboratory Watershed Function Science Focus Area (SFA), and NASA-JPL (Jet Propulsion Laboratory) Earth Surface Mineral Dust Source Investigation (EMIT) program. Between June 10 and July 18, 2025, the NEON AOP flight team collected high-resolution aerial imaging spectroscopy and Light Detection and Ranging (LiDAR) data over three domains: the Upper East River (CRBU), Almont Triangle (ALMO), and the Upper Taylor Basin (UPTA). In coordination with the flights, a field campaign acquired ground-truth observations, including observations of vegetation composition, foliar traits, forest demography, and subsurface properties in 18 core sampling areas within the domains. Additional surface water observations were taken at over 380 point locations. All CHESS campaign datasets can be found within the CHESS ESS-DIVE data portal: https://data.ess-dive.lbl.gov/portals/chess. Funding Acknowledgement: Field and remote-sensing data acquisition was performed under a grant from the National Aeronautics and Space Administration (80NSSC24K1005). This work was also supported by the Watershed Function Science Focus Area at Lawrence Berkeley National Laboratory funded by the US Department of Energy, Office of Science, Biological and Environmental Research under Contract No. DE-AC02-05CH11231.

2018 NEON and 2025 CHESS Campaigns↗