SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
LOOK program permits user to examine text file in pseudorandom access manner. Program provides user with way of rapidly examining contents of ASCII text file. LOOK opens text file for input only and accesses it in blockwise fashion. Handles text formatting and displays text lines on screen. User moves forward or backward in file by any number of lines or blocks. Provides ability to "scroll" text at various speeds in forward or backward directions.
File Comparator program IFCOMP, is text file comparator for IBM OS/VScompatable systems. IFCOMP accepts as input two text files and produces listing of differences in pseudo-update form. IFCOMP is very useful in monitoring changes made to software at the source code level.
This slide presentation reviews the use of a simple text file to work with large, multi-component thermal models that present a post-processing challenge. This complexity is due to temperatures for many components, with varying requirements, need to be examined and that false color temperature maps, or rainbows, provide a qualitative assessment of results.
The purpose was to investigate and evaluate the interchange of application- specific data among multiple programs each carrying out part of the analysis and design task. This has been carried out previously by creating a custom program to read data produced by one application and then write that data to a file whose format is specific to the second application that needs all or part of that data. In this investigation, data of interest is described using the XML markup language that allows the data to be stored in a text-string. Software to transform output data of a task into an XML-string and software to read an XML string and extract all or a portion of the data needed for another application is used to link two independent applications together as part of an overall design effort. This approach was initially used with a standard analysis program, Lapin, along with standard applications a standard spreadsheet program, a relational database program, and a conventional dialog and display program to demonstrate the successful sharing of data among independent programs. See Engineering Analysis Using a Web-Based Protocol by J.D. Schoeffler and R.W. Claus, NASA TM-2002-211981, October 2002. Most of the effort beyond that demonstration has been concentrated on the inclusion of more complex display programs. Specifically, a custom-written windowing program organized around dialogs to control the interactions have been combined with an independent CAD program (Open Cascade) that supports sophisticated display of CAD elements such as lines, spline curves, and surfaces and turbine-blade data produced by an independent blade design program (UD0300).
The purpose of grant NCC3-966 was to investigate and evaluate the interchange of application-specific data among multiple programs each carrying out part of the analysis and design task. This has been carried out previously by creating a custom program to read data produced by one application and then write that data to a file whose format is specific to the second application that needs all or part of that data. In this investigation, data of interest is described using the XML markup language that allows the data to be stored in a text-string. Software to transform output data of a task into an XML-string and software to read an XML string and extract all or a portion of the data needed for another application is used to link two independent applications together as part of an overall design effort. This approach was initially used with a standard analysis program, Lapin, along with standard applications a standard spreadsheet program, a relational database program, and a conventional dialog and display program to demonstrate the successful sharing of data among independent programs. Most of the effort beyond that demonstration has been concentrated on the inclusion of more complex display programs. Specifically, a custom-written windowing program organized around dialogs to control the interactions have been combined with an independent CAD program (Open Cascade) that supports sophisticated display of CAD elements such as lines, spline curves, and surfaces and turbine-blade data produced by an independent blade design program (UD0300).
Current research in the area of long term scheduling of the Hubble Space Telescope is being done using Common Lisp and Flavors on Lisp Machines. The planning tools manipulate memory-resident data structures which represent the many entities and relationships that represent planning states. The Lisp Object State Saver (LOSS), a general purpose utility, was constructed which allows one to take a snapshot of memory by storing a representation of the structures in a text file. This text file can later be loaded thus restoring the pre-existing and logically equivalent planning state. A LOSS template must be created for each datatype to be stored and a simple grammar governs the creation of such templates.
Directory Tree Analysis File Generator is a Practical Extraction and Reporting Language (PERL) script that simplifies and automates the collection of information for forensic analysis of compromised computer systems. During such an analysis, it is sometimes necessary to collect and analyze information about files on a specific directory tree. Directory Tree Analysis File Generator collects information of this type (except information about directories) and writes it to a text file. In particular, the script asks the user for the root of the directory tree to be processed, the name of the output file, and the number of subtree levels to process. The script then processes the directory tree and puts out the aforementioned text file. The format of the text file is designed to enable the submission of the file as input to a spreadsheet program, wherein the forensic analysis is performed. The analysis usually consists of sorting files and examination of such characteristics of files as ownership, time of creation, and time of most recent access, all of which characteristics are among the data included in the text file.
This data package contains input files for TOUGHREACT for a modeling study examining the effects of managed aquifer recharge on agricultural lands on nitrate cycling and transport in the Central Valley of CA near Modesto. The files contain all the geochemical species, reactions, and hydrological parameters for the model. The files are text files used for the TOUGH family of code created by LBNL. To use the files a license is required. https://tough.lbl.gov/licensing-download/toughreact-licensing-download/Accompanying Paper Abstract: Agricultural managed aquifer recharge (AgMAR) is a proposed management strategy whereby surface water flows are used to intentionally flood croplands with the purpose of recharging underlying aquifers. However, legacy nitrate (NO3-) contamination in agriculturally-intensive regions poses a threat to groundwater resources under AgMAR. To address these concerns, we use a reactive transport modeling framework to better understand the effects of AgMAR management strategies (i.e., by varying the frequency, duration between flooding events, and amount of water) on N leaching to groundwater under different stratigraphic configurations and antecedent moisture conditions. In particular, we examine the potential of denitrification and nitrogen retention in deep vadose zone sediments (~15 m) using variable AgMAR application rates on two-dimensional representations of differently textured soils, soils with discontinuous bands/channels, and soils with preferential flow paths characteristic of typical agricultural field sites. Our results indicate that finer textured sediments, such as silt loams, alone or embedded within high flow regions, are important reducing zones providing conditions needed for denitrification. Simulation results further suggest that applying water all-at-once rather than in increments for a fixed volume of recharge transports higher concentrations of NO3- deeper into the profile, which has the potential to exacerbate groundwater quality. This transport into deeper depths can be aggravated by wetter antecedent soil moisture conditions. However, applying water all-at-once also increases denitrification within the vadose zone by promoting anoxic conditions. We conclude that AgMAR management strategies can be designed to enhance denitrification in the subsurface and reduce N leaching to groundwater, while specifically accounting for lithologic heterogeneity, antecedent soil moisture conditions, and depth to the water table. Our findings are potentially relevant to other systems that experience flooding inundation such as riparian corridors, floodplains, wetlands, and other managed landscapes like dedicated recharge basins.
This dataset is the raw and processed data for the paper "Simulated plant ‑ mediated oxygen input has strong impacts on fine ‑ scale porewater biogeochemistry and weak impacts on integrated methane fluxes in coastal wetlands". This study investigated how plant-mediated oxygen input affects subsurface biogeochemical reactions of organic carbon degradation and the resulting methane emissions of coastal wetlands by model simulation. We used the subsurface geochemical simulator PFLOTRAN for the modeling, which produced the simulated changes in porewater chemical substances and methane emissions over 10 days under different scenarios of plant-mediated oxygen input.Specifically, this dataset contains: 1) the input files for PFLOTRAN of all simulation runs conducted in this study. Those files are with an extension of ".in", containing information of the biogeochemical reaction network (stoichiometry, reaction rate, Monod constants, etc), fluid flow rate and oxygen concentration in the fluid which together simulated the plant-mediated oxygen input, the configuration of artificial reactions that simulated the methane fluxes, etc. The PFLOTRAN input files are text files, which can be opened by NotePad, but running these input files will require proper installation of PFLOTRAN (instruction: https://documentation.pflotran.org/user_guide/how_to/installation/installation.html). 2) the raw and processed model output from PFLOTRAN of all simulation runs, and 3) the python scripts used to process the raw model output, including random allocation of root cells, converting raw data into organized formats, calculating the methane fluxes based on the model output, data visualization, etc. The raw and processed model output from PFLOTRAN are in .spydata format, which can be viewed with Python. and 3) the python scripts for data processing and analysis are programming scripts, which can be opened with Python.This modeling work, in particular the model parameterization of root density and initial conditions of porewater concentrations of biogeochemical substances, was based on field measurements at the salt marsh of the Upper Parker River Estuary, Massachusetts, United States.
A regression-based analysis quantifies how basin characteristics modulate the snow-to-streamflow signal. First, we use the ERA5-Land reanalysis gridded product (European Centre for Medium Range Weather Forecasts reanalysis 5 -Land component) for 4,655 hydrologic unit code - 10 (HUC10) mountain basins across the western United States (US) for water years 1987–2024. Linear regressions are performed for peak snow water equivalent (SWE) and annual streamflow for each mountain basin. Models use ordinary least squares in Python’s statsmodels package. After which, an Akaike Information Criterion (AIC)–weighted ensemble multiple linear regression (MLR) framework with 47 watershed traits is used to predict the linear regression coefficient of determination (r-squared) defining the ability of peak SWE to predict annual streamflow across all mountain basin. Predictor sets are constrained to avoid multicollinearity by excluding models with variance inflation factors (VIF) greater than 5. Mountain basin traits included in the MLR include seasonal climate, topography, vegetation type and structure, and bedrock geology. Accepted models are considered if their AIC is within 2.0 of the model with the minimum AIC, or best model. To compare predictor influence across acceptable models, we computed standardized regression coefficients. To evaluate structural redundancy among models, we constructed binary inclusion vectors for each acceptable model, denoting whether a predictor was present (1) or absent (0). Core predictor variables are defined as occurring in at least 67% of the acceptable models. For this regional analysis, only one model was found acceptable, with higher snow-to-streamflow translation (higher r-squared) occurring in colder mountain basins with higher relative winter precipitation, more snow accumulation and a lower fraction of annual precipitation that falls in the spring and summer. The second component of the data package uses previously published, high-resolution output from an integrated hydrological model of the East River watershed using the U.S. Geological Survey Groundwater and Surface water Flow model (GSFLOW, doi:10.15485/1998576). East River MLR expands upon the approach described above to explore the response of five streamflow metrics—annual streamflow, runoff efficiency, 7-day minimum flow, low-flow duration, and non-perennial stream fraction to snow system indicators including peak SWE, snow-covered area, snow disappearance date, and the fraction of basin area characterized by low-to-no snow, as well as seasonal precipitation and temperature, and annual hydrologic variables representing soil moisture, evapotranspiration (ET), the partitioning of incoming precipitation to evapotranspiration (ET/P), groundwater storage, and groundwater inflow to streams. MLR was done on all water years (P0: 1987-2024) and for each period as determined in the split analysis using pooled regression techniques (P1: 1987-2011 and P2: 2012-2024) to evaluate shifting predictor variable emphasis on streamflow generation. Results indicate that since 2012, peak SWE has lost statistical strength in its prediction of annual streamflow and runoff efficiency, and the indirect influence of spring temperature has emerged as critically important. Low-flow metrics remain largely influenced by soil moisture, vegetation water use and groundwater inflows with summer precipitation becoming a direct influence on minimum summer flow. Together, these data and Python-based analysis tools provide a framework for identifying the key watershed characteristics that control how streamflow responds to snow from year to year. The package also helps quantify uncertainty in statistical models and assess how snow–streamflow relationships vary across regions and over time. This dataset contains comma-separated values files (.csv), text files (.txt), python code files (.py), figure files (.png), and shapefiles (.cpg, .dbf, .prj, .sbn, .sbx, .shp, .xml). Further details on file contents and MLR execution can be found in the readme file and the FLMD files. Work was 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.
This repository presents HydroSMADE—Hydropower Site-level Monthly Availability Data Ensemble, a new open dataset that provides monthly hydropower availability for 1,593 existing and 124,333 potential sites worldwide over the period 1950–2100. The dataset is generated by using a global hydrologic model (Xanthos) with explicit representation of hydropower operation. Specifically, HydroSMADE distinguishes between storage and diversion sites, applies optimized operating rules, and incorporates site-specific characteristics such as generation capacity, maximum turbine flow, and reservoir storage. Driven by bias-corrected meteorological inputs, the data is provided for 30 alternative future scenarios. The scenarios consist of the full factorial combination of three standard CMIP6 atmospheric forcing pathways (SSP1-2.6, SSP3-7.0, and SSP5-8.5) and ten CMIP6 General Circulation Models (GCMs): GFDL-ESM4, IPSL-CM6A-LR, MPI-ESM1-2-HR, MRI-ESM2-0, EC-Earth3, CanESM5, MIROC6, CNRM-ESM2-1, UKESM1-0-LL, and CNRM-CM6-1. The repository contains a total of 122 files: a text file (readme.txt) containing a brief description of the included data, a CSV file containing site attributes, and the remaining 120 files (in CSV) containing site-level monthly hydropower availability. Example Jupyter Notebooks to explore the HydroSMADE dataset are available on GitHub at https://github.com/kamal0013/HydroSMADE More details on the methods and technical validation of HydroSMADE are available in the following paper by the same authors: Chowdhury, A. K., Abeshu, G. W., Zhao, M., Wild, T. B., Hassan, N., Ying, Z., Kim, G. J., Matthew, B., Jonathan, L., & Li, H.-Y. (Submitted). Hydropower Site-level Monthly Availability Data Ensemble for 1950-2100 at Existing and Potential Global Sites.
C Namelist Facility (CNL) is a package of software that supports the development of data-driven programs that utilize relatively free-form input files (e.g., text files) to control complex operations. The only comparable prior namelist facility is built into Fortran and does not support arrays or records. Newer computing languages, including C and Pascal, do not include built-in namelist facilities. A namelist facility enables a program to utilize relatively free-form input files that contain assignment statements that give values to variables. Variables to which values are not assigned in input files remain unchanged; therefore, it becomes possible to have default values set by static or dynamic initialization of values prior to namelist input and updating of values is optional. Because it is not required to include values of variables in namelist input files, new parameters can be added to evolving programs without rendering old namelist input files obsolete -- provided that the new parameters have useful default values. It should be possible to execute CNL in any operating system that supports the ANSI C programming language. It has been executed in several variants of Unix and in VxWorks.
The decay curve analysis that is done on the short-lived radionuclide gas samples is used to differentiate between gaseous radionuclides that have the same characteristic gamma decay energy, 511 kiloelectron-volts (keV). A sample of stack gas is isolated and the total counts in the 511 keV peak are counted repeatedly in 10-second intervals to evaluate the decay rate of the sample over time. Analysis of this decay data required a series of steps. First, a raw data report is generated by the gamma acquisition system, based on an analysis template within the acquisition software. The data report file was then loaded into Microsoft Word, and a macro was used to perform minor formatting (remove colons and insert tabs between data columns) to allow analysis within Excel. The file is then saved as a text file at this point. The text file is then uploaded into Excel and a series of macros are used to add labels, calculate radioactive decay constants, and analyze the gamma decay data using linear regression techniques. The analysis template has been used since 1998 for stack 53000303 (TA-53, building 0003, exhaust stack 03) and 2000 for stack 53000702. The overall process, including the gamma report format and the macros used in Word and Excel for processing the report, had remained unchanged until 2015. In October of 2015, staff made a change to the report template in the gamma acquisition software which resulted in an error in the calculations later performed by the Excel macro. This error was not caught until a more in-depth review of the analysis took place regarding 2020 data. This report covers a much more complete review of the issue that occurred regarding the decay curve analysis, a review of the calculations completed to correct the issue, a review of the updated decay curve analysis process, and recommendations for moving forward.
This document describes the supplemental materials for the paper: TITLE: "Radiosonde-to-Space (R2S) atmospheric specifications: Bridging observations and models for infrasound propagation" DOI: xxxxxxxxxxx JOURNAL: TBD Written by Loring Schaible, September 17, 2025 This folder contains eight subfolders, each for a specific date and UTC time (in format YYYY-MM-DD_HH). All eight of these dates are exemplified and described in the manuscript. Within each folder is six documents. As an example, consider the folder "2022-12-31_00". The six files are comprised of: - Two text files (extension .txt) that describe the atmospheric specifications of Albuquerque, NM. One is the G2S model, the other is the R2S model. "G2S_2022-12-31_00.txt" "R2S_2022-12-31_00.txt" - Two text files (extension .dat) that contain the ground arrivals predicted by infraGA using the parameters described in the manuscript. One each for the two atmospheric specification models above, G2S and R2S. "G2S_2022-12-31_00.arrivals.dat" "R2S_2022-12-31_00.arrivals.dat" - Two image files (extension .png) that illustrate the predicted arrivals contained in the two files above. One image shows all arrivals as either black (G2S) or red (R2S). The other image shows the same but with arrivals common to both models in gray. "2022-12-31_00_Arrivals.png" "2022-12-31_00_DifArrivals.png"
This data package contains geographic information system (GIS) layers and tabular datasets associated with the study of lithologic controls on denudation, solute export, carbon-scaling relationships, and transient landscape evolution in the East River watershed near Crested Butte, Colorado, USA. The package includes GIS layers used to produce the Figure 2 map, including drainage, hillshade, lithology, sample locations, and basin polygons, together with comma-separated value (CSV) tables and matching CSV data dictionaries. One group of tables reports sample-level and catchment-level information for river-sediment samples analyzed for in situ-produced cosmogenic beryllium-10 (10Be), including sample names, outlet elevations, geographic coordinates, upstream drainage area, rock-type classes, production-rate scaling scheme, analyzed nuclide, catchment-averaged denudation rates, and associated lower and upper analytical uncertainties. Sample and catchment attributes provide the basis for comparing denudation rates across intrusive, shale, sedimentary, and mixed-lithology settings. A second group of tables reports supporting information for landscape-evolution modeling and the mapped geologic framework of the study area. Included files list parameter values and definitions for the two-phase landscape-evolution simulations, summarize full-domain model erosion fluxes and topographic metrics for different simulation configurations, provide a fixed-area carbon-model scaling table, and summarize mapped geologic units within the East River study domain, including geologic code, formation name, lithologic description, mapped area, and lithologic class grouping. Model outputs and geologic summaries support interpretation of transient landscape behavior and its relation to the mapped distribution of shale, intrusive, sedimentary, and surficial units. A third group of tables reports hydrologic and hydrochemical information used to quantify dissolved export from the watershed. Included files provide site-level values for drainage area, mean annual solute export, standard error of annual export, area-normalized solute yield, and equivalent weathering rate for five East River monitoring sites, along with metadata describing the number, sampling cadence, and date range of discharge records and partial and full total dissolved solids observations used in the solute-yield analyses. The package also contains a supplementary daily ion-load time series with daily mean discharge, discharge observation counts, dissolved concentrations, and daily loads for calcium, magnesium, sodium, potassium, chloride, sulfate, nitrate, fluoride, dissolved silica, charge-balance bicarbonate, and total dissolved solids. The package contains GIS files, comma-separated value files (.csv), CSV data dictionaries, a file-level metadata table, a package-tree text file, and a readme text file.
Lewice (LEWis ICE accretion program) is software used by literally hundreds of users in the aeronautics community for predicting ice shapes, collections efficiencies, and anti-icing heat requirements for aircraft. LEWICE performs its analysis in minutes on a desktop PC, allowing the user to run several parameter studies for design purposes. The ice shape predictions have been used to assess performance degradation both as an input to a CFD program or experimentally in flight or in a wind tunnel. This information is important to ensure an airplane s safe passage through an icing cloud. Currently, Lewice runs as a DOS program that accepts many different inputs such as cloud conditions, wing shapes, and thermal deicing inputs. Usually, such experimental data is stored in spreadsheets. However, Lewice inputs are text files; therefore, they must be generated by the user. Lewice s outputs (collection efficiency, ice shapes and thicknesses) are also text files; to plot the data, users must generate a spreadsheet with this output. Because all Lewice J/O is in the form of text files, using Lewice can be tricky and time-consuming. Our goal was to improve Lewice s usability by creating a user interface that would automatically generate Lewice input from a spreadsheet and automatically put Lewice output into spreadsheets with charts. Additionally, this user interface would automatically convert units (as Lewice only accepts input in certain units) and offer several output options. I call this program the Lewice Console. The Lewice Console is an easy to use interface for Lewice written in Visual Basic. It allows users to run Lewice given a spreadsheet listing experimental conditions. It automatically generates the input to Lewice, does necessary unit conversions, runs Lewice, and produces a spreadsheet with charts plotting the data. It allows users to import data from previously generated Lewice inputs into a spreadsheet. It also allows users to batch run Lewice on several different inputs to automatically generate multiple output spreadsheets. You can also generate plots of actual data vs. experimental data. These capabilities are just the beginning for the Lewice Console. Lewice is capable of running a full deicing experiment given a geometry and heating apparatus information. However, users find it difficult to run such experiments due to the number of inputs and the difficult input file format. The Lewice Console would simplify experiment generation by allowing the user to interactively draw a geometry, place heating apparatus, and specify information about each part. The input to Lewice would be automatically generated from the experiment the user draws on the screen. The Lewice Console would simplify the experiment building process. Currently, Lewice runs as a DOS program that accepts many different inputs such as
Many knowledge based software generation methods have been proposed to improve software quality and programmer productivity. Several government and industry initiatives have focused on software reusability as one solution to these problems. DARTS (trademark), a General Dynamics proprietary symbolic processing technology, provides a unique solution to the reuse problem: archtyping. Archtyping is the embedding of high order language statements in text files. An advanced macroprocessor uses the text files to generate new versions of complex software systems. A DARTS program, the Software Generation and Configuration Management (SGCM) System automates the archtyping process and maintenance cycle. The DARTS technology is briefly discussed, archtyping is described, and the SGCM system is presented in detail.
This program examines the source folder on instrument computers to find files and folders. It creates a tab-delimited text file for each instrument, listing the names of the files and folders found. The text files for the instruments are stored in a central location, and are made made visible via the DMS website to allow instrument operators to see the instrument data files on the instrument computer.