Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “input files”

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

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

At least 253 records · Page 14

Software for Refining or Coarsening Computational Grids

A computer program performs calculations for refinement or coarsening of computational grids of the type called "structured" (signifying that they are geometrically regular and/or are specified by relatively simple algebraic expressions). This program is designed to facilitate analysis of the numerical effects of changing structured grids utilized in computational fluid dynamics (CFD) software. Unlike prior grid-refinement and -coarsening programs, this program is not limited to doubling or halving: the user can specify any refinement or coarsening ratio, which can have a noninteger value. In addition to this ratio, the program accepts, as input, a grid file and the associated restart file, which is basically a file containing the most recent iteration of flow-field variables computed on the grid. The program then refines or coarsens the grid as specified, while maintaining the geometry and the stretching characteristics of the original grid. The program can interpolate from the input restart file to create a restart file for the refined or coarsened grid. The program provides a graphical user interface that facilitates the entry of input data for the grid-generation and restart-interpolation routines.

Daines, Russell↗

Software for Refining or Coarsening Computational Grids

A computer program performs calculations for refinement or coarsening of computational grids of the type called structured (signifying that they are geometrically regular and/or are specified by relatively simple algebraic expressions). This program is designed to facilitate analysis of the numerical effects of changing structured grids utilized in computational fluid dynamics (CFD) software. Unlike prior grid-refinement and -coarsening programs, this program is not limited to doubling or halving: the user can specify any refinement or coarsening ratio, which can have a noninteger value. In addition to this ratio, the program accepts, as input, a grid file and the associated restart file, which is basically a file containing the most recent iteration of flow-field variables computed on the grid. The program then refines or coarsens the grid as specified, while maintaining the geometry and the stretching characteristics of the original grid. The program can interpolate from the input restart file to create a restart file for the refined or coarsened grid. The program provides a graphical user interface that facilitates the entry of input data for the grid-generation and restart-interpolation routines.

Daines, Russell↗

Titan Global Reference Atmospheric Model (Titan-GRAM): User Guide

This Technical Memorandum summarizes the atmospheric data model in Titan-GRAM and provides a guide for the user to obtain, set up, and run the code in various configurations. Section 2 describes the input atmospheric data files and how they are used in Titan-GRAM. Section 3 explains the process to obtain the Titan-GRAM code and data files and how to set up and run the program. Appendices A through E provide additional details regarding the Titan-GRAM input and output files. Appendix F provides a history of Titan-GRAM revisions.

Titan Global Reference Atmospheric Model,↗

Uranus Global Reference Atmospheric Model (Uranus-GRAM) 2024: User Guide

Engineers and mission planners designing vehicles that pass through Uranus’ atmosphere require an atmospheric model that calculates the mean values and variations of atmospheric properties. The Uranus Global Reference Atmospheric Model(Uranus-GRAM)is an engineering- oriented model that provides this information based on data from Voyager observations. Uranus- GRAM is designed to offer mission planners the flexibility to select input parameters such as time, latitude, and longitude. Uranus-GRAM outputs atmospheric constituent data and mean values for atmospheric density, temperature, pressure, and zonal wind along a user defined path. Uranus-GRAM also provides dispersions of density and zonal wind. Uranus-GRAM is one option in the GRAM Suite that shares a common software core with the other planetary GRAMs while maintaining Uranus specific models. Additionally, documentation, including this User Guide, a Programmer’s Manual, and trajectory code interfaces has been made available with the software release. This Technical Memorandum summarizes the atmospheric data model in Uranus-GRAM and provides a guide for the user to obtain, set up, and run the code in various configurations. Section 2 describes the input atmospheric data files and how they are used in Uranus-GRAM. Section 3 explains the process to obtain the Uranus-GRAM code, the data files, and how to set up and run the program. Appendices A through E provide additional details regarding the Uranus-GRAM input and output files. Appendix F provides a history of Uranus-GRAM revisions.

atmospheric models↗

Text File Comparator

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.

Kotler, R. S.↗

Terminal Area Simulation System User's Guide - Version 10.0

The Terminal Area Simulation System (TASS) is a three-dimensional, time-dependent, large eddy simulation model that has been developed for studies of wake vortex and weather hazards to aviation, along with other atmospheric turbulence, and cloud-scale weather phenomenology. This document describes the source code for TASS version 10.0 and provides users with needed documentation to run the model. The source code is programed in Fortran language and is formulated to take advantage of vector and efficient multi-processor scaling for execution on massively-parallel supercomputer clusters. The code contains different initialization modules allowing the study of aircraft wake vortex interaction with the atmosphere and ground, atmospheric turbulence, atmospheric boundary layers, precipitating convective clouds, hail storms, gust fronts, microburst windshear, supercell and mesoscale convective systems, tornadic storms, and ring vortices. The model is able to operate in either two- or three-dimensions with equations numerically formulated on a Cartesian grid. The primary output from the TASS is time-dependent domain fields generated by the prognostic equations and diagnosed variables. This document will enable a user to understand the general logic of TASS, and will show how to configure and initialize the model domain. Also described are the formats of the input and output files, as well as the parameters that control the input and output.

Switzer, George F.↗

HRMA calibration handbook: EKC gravity compensated XRCF models

This document, consisting of hardcopy printout of explanatory text, figures, and tables, represents one incarnation of the AXAF high resolution mirror assembly (HRMA) Calibration Handbook. However, as we have envisioned it, the handbook also consists of electronic versions of this hardcopy printout (in the form of postscript files), the individual scripts which produced the various figures and the associated input data, the model raytrace files, and all scripts, parameter files, and input data necessary to generate the raytraces. These data are all available electronically as either ASCII or FITS files. The handbook is intended to be a living document and will be updated as new information and/or fabrication data on the HRMA are obtained, or when the need for additional results are indicated. The SAO Mission Support Team (MST) is developing a high fidelity HRMA model, consisting of analytical and numerical calculations, computer software, and databases of fundamental physical constants, laboratory measurements, configuration data, finite element models, AXAF assembly data, and so on. This model serves as the basis for the simulations presented in the handbook. The 'core' of the model is the raytrace package OSAC, which we have substantially modified and now refer to as SAOsac. One major structural modification to the software has been to utilize the UNIX binary pipe data transport mechanism for passing rays between program modules. This change has made it possible to simulate rays which are distributed randomly over the entrance aperture of the telescope. It has also resulted in a highly efficient system for tracing large numbers of rays. In one application to date (the analysis of VETA-I ring focus data) we have employed 2 x 10(exp 7) rays, a substantial improvement over the limit of 1 x 10(exp 4) rays in the original OSAC module. A second major modification is the manner in which SAOsac incorporates low spatial frequency surface errors into the geometric raytrace. The original OSAC included the ability to use Legendre-Fourier polynomials to describe deviations from the basic optical prescription. To this we have added bicubic splines to address a deficiency in the handling of the sharper deformations in the areas of mirror support pads. SAO has developed software (TRANS-FIT) to translate the most common finite element analysis models into these forms for incorporation into the raytrace program.

Tananbaum, H. D.↗

Mars Global Reference Atmospheric Model 2010 Version: Users Guide

This Technical Memorandum (TM) presents the Mars Global Reference Atmospheric Model 2010 (Mars-GRAM 2010) and its new features. Mars-GRAM is an engineering-level atmospheric model widely used for diverse mission applications. Applications include systems design, performance analysis, and operations planning for aerobraking, entry, descent and landing, and aerocapture. Additionally, this TM includes instructions on obtaining the Mars-GRAM source code and data files as well as running Mars-GRAM. It also contains sample Mars-GRAM input and output files and an example of how to incorporate Mars-GRAM as an atmospheric subroutine in a trajectory code.

Justh, H. L.↗

LACIE performance predictor final operational capability program description, volume 2

Given the swath table files, the segment set for one country and cloud cover data, the SAGE program determines how many times and under what conditions each segment is accessed by satellites. The program writes a record for each segment on a data file which contains the pertinent acquisition data. The weather data file can also be generated from a NASA supplied tape. The Segment Acquisition Selector Program (SACS) selects data from the segment reference file based upon data input manually and from a crop window file. It writes the extracted data to a data acquisition file and prints two summary reports. The POUT program reads from associated LACIE files and produces printed reports. The major types of reports that can be produced are: (1) Substrate Reference Data Reports, (2) Population Mean, Standard Deviation and Histogram Reports, (3) Histograms of Monte Carlo Statistics Reports, and (4) Frequency of Sample Segment Acquisitions Reports.

Source record↗

Program Facilitates Distributed Computing

KNET computer program facilitates distribution of computing between UNIX-compatible local host computer and remote host computer, which may or may not be UNIX-compatible. Capable of automatic remote log-in. User communicates interactively with remote host computer. Data output from remote host computer directed to local screen, to local file, and/or to local process. Conversely, data input from keyboard, local file, or local process directed to remote host computer. Written in ANSI standard C language.

Hui, Joseph↗

File-Sectioning And Reducing Program

SPLIT computer program accepts inputs of any large ASCII-type file and splits or rewrites input into smaller, more-easily-managed files. SPLIT written in FORTRAN 77 for IBM PC-series and compatible computers running MS-DOS.

Akian, R. A.↗

Rapid Diagnostics of Onboard Sequences

Keeping track of sequences onboard a spacecraft is challenging. When reviewing Event Verification Records (EVRs) of sequence executions on the Mars Exploration Rover (MER), operators often found themselves wondering which version of a named sequence the EVR corresponded to. The lack of this information drastically impacts the operators diagnostic capabilities as well as their situational awareness with respect to the commands the spacecraft has executed, since the EVRs do not provide argument values or explanatory comments. Having this information immediately available can be instrumental in diagnosing critical events and can significantly enhance the overall safety of the spacecraft. This software provides auditing capability that can eliminate that uncertainty while diagnosing critical conditions. Furthermore, the Restful interface provides a simple way for sequencing tools to automatically retrieve binary compiled sequence SCMFs (Space Command Message Files) on demand. It also enables developers to change the underlying database, while maintaining the same interface to the existing applications. The logging capabilities are also beneficial to operators when they are trying to recall how they solved a similar problem many days ago: this software enables automatic recovery of SCMF and RML (Robot Markup Language) sequence files directly from the command EVRs, eliminating the need for people to find and validate the corresponding sequences. To address the lack of auditing capability for sequences onboard a spacecraft during earlier missions, extensive logging support was added on the Mars Science Laboratory (MSL) sequencing server. This server is responsible for generating all MSL binary SCMFs from RML input sequences. The sequencing server logs every SCMF it generates into a MySQL database, as well as the high-level RML file and dictionary name inputs used to create the SCMF. The SCMF is then indexed by a hash value that is automatically included in all command EVRs by the onboard flight software. Second, both the binary SCMF result and the RML input file can be retrieved simply by specifying the hash to a Restful web interface. This interface enables command line tools as well as large sophisticated programs to download the SCMF and RMLs on-demand from the database, enabling a vast array of tools to be built on top of it. One such command line tool can retrieve and display RML files, or annotate a list of EVRs by interleaving them with the original sequence commands. This software has been integrated with the MSL sequencing pipeline where it will serve sequences useful in diagnostics, debugging, and situational awareness throughout the mission.

Starbird, Thomas W.↗

Engineering description of the ascent/descent bet product

The Ascent/Descent output product is produced in the OPIP routine from three files which constitute its input. One of these, OPIP.IN, contains mission specific parameters. Meteorological data, such as atmospheric wind velocities, temperatures, and density, are obtained from the second file, the Corrected Meteorological Data File (METDATA). The third file is the TRJATTDATA file which contains the time-tagged state vectors that combine trajectory information from the Best Estimate of Trajectory (BET) filter, LBRET5, and Best Estimate of Attitude (BEA) derived from IMU telemetry. Each term in the two output data files (BETDATA and the Navigation Block, or NAVBLK) are defined. The description of the BETDATA file includes an outline of the algorithm used to calculate each term. To facilitate describing the algorithms, a nomenclature is defined. The description of the nomenclature includes a definition of the coordinate systems used. The NAVBLK file contains navigation input parameters. Each term in NAVBLK is defined and its source is listed. The production of NAVBLK requires only two computational algorithms. These two algorithms, which compute the terms DELTA and RSUBO, are described. Finally, the distribution of data in the NAVBLK records is listed.

Seacord, A. W., II↗

Flight Mechanics Modeling and Simulation of the Earth Entry System

Introduction: The Mars Sample Return (MSR) Campaign being planned by NASA and ESA has the ambitious goal to return Mars samples back to Earth. This international collaboration had developed a concept of operations that included a ESA-designed Earth Return Orbiter (ERO) and NASA-designed Capture, Containment, and Return System (CCRS). The Earth Entry System (EES), consisting of a protective aeroshell that houses the samples as well as sample containment vessels, would conduct entry, descent, and landing (EDL) on a direct Earth trajectory. The EES would enter on a spin-stabilized ballistic trajectory with the goal to passively achieve aerodynamic stability throughout all regions of flight. The EDL sequence would end with the EES impacting the soft playa soil of the Utah Test and Training Range (UTTR). As of the submission of this abstract, the MSR campaign is undergoing a re-architecture leading to a pause in EES development. However, the novel approaches developed in flight mechanics modeling and simulation can significantly benefit the greater IPPW community in the development of Earth return vehicles. This paper will present the latest state of EES flight mechanics modeling and simulation. The paper will highlight the simulation architecture developed and key lessons learned from understanding of EDL trajectory sensitivities. Modeling and Simulation: Figure 1 provides a high-level concept of operations for the approach, entry, descent, and landing (AEDL) phase of the CCRS-portion of MSR. The objective of EES flight mechanics is to model and simulate the EES trajectory from ERO separation to ground impact at UTTR. A variety of flight mechanics simulation models were utilized to model both exo-atmopsheric and atmospheric portions of flight. 42, a 6-DOF simulation developed at Goddard Space Flight Center, is utilized for propagating the attitude of EES during exo-atmospheric flight. 42 allows for a variety of spin eject mechanism scenarios to be simulated for analysis. 10 minutes prior to entry, the 42 states are handed off to the EDL sims. The prime EDL sim utilized by EES is the Program to Optimize Simulated Trajectories II (POST2), a 6-DOF sim developed at Langley Research Center, and the independent verification and validation EDL sim utilized is DSENDS, a 6-DOF sim developed at Jet Propulsion Laboratory. Figure 2 provides a visualization of the flight mechanics simulation model flow through various points in the AEDL phase. Due to the existence of a variety of sim models, the EES flight mechanics team developed processes for data hand-off. These processes included the development of a centralized coordinate frame document, utilization of a single, centralized simulation input document for all sims to reference, and hand-off files containing both the technical data to be ingested by other flight mechanics sims as well as annotations of modeling assumptions utilized to generate the data. Figure~\ref{fig:post2simarchitecture} provides an overview of the POST2 sim architecture wherein POST2 ingests numerous subsystem models and input files. The dispersed state file generated by MONTE provides the position/velocity state of the trajectory while the 42 Handoff file provides the attitude. The aerodynamics database, delivered by the EES aeroscience team, is utilized to simulate the aerodynamic forces and moments experienced during EDL. A custom atmosphere model, developed by EES atmosphere team, is utilized to simulate the anticipated atmosphere environment around the region of Earth through which the EES trajectory flys. These inputs and subsystem models can be varied depending on the AEDL flight mechanics scenario being simulated. Monte Carlo simulations are utilized to generate statistical AEDL performance metrics in the form of scorecards and violin plots. Furthermore, outputs from the POST2 simulation are utilized for follow-on analyses including aerothermal and landing performance. \section{Flight Mechanics Lessons Learned} Though the EES flight mechanics team uncovered a variety of lessons learned through the analysis conducted to support CCRS through preliminary design review, this paper will highlight the most important lessons. A key AEDL performance goal is to ensure the landing footprint of EES remains on the UTTR south range. A common modeling strategy used in EDL analysis is One-Variable-At-a-Time (OVAT). OVAT analysis provides insight into the key drivers that affect AEDL performance metrics. Figure 3 shows the landing ellipses for single dispersion sources as compared to the baseline aggregate of all dispersions. The figure shows that atmosphere winds alone dominate the size of the footprint ellipse (note: EES does not use a parachute unlike previous Earth-return missions and is in wind-driven free fall for ~5min). The significance of the wind led the EES flight mechanics team to pursue the development of a Custom Atmosphere Model [4], in lieu of EarthGRAM [1], built on actual radiosonde wind measurements around the UTTR-region. This decision was driven by the realism in the generated footprint ellipses and lessons-learned from Stardust [5]. These findings will be invaluable for future Earth-return missions in providing an early understanding of the key drivers affecting footprint size and modeling considerations for which to account. Another lesson learned is tied to the AEDL performance goal of achieving passive stability throughout all regions of flight. It is well understood that blunt-body aeroshells are less stable as they transition from supersonic to subsonic. Eliminating a backshell does help improvestability; however, other phenomena such as roll-induced instability during terminal descent can still arise. The EES flight mechanics team developed stability metrics as tools to better understand the causes of and better predict the onset of dynamic instability. These tools were built upon analytical models developed by Jaffe [3] and Murphy [2]. The tools were shown to both be very accurate in correlation with actual unstable cases and useful in developing stability margin policies based on the vehicle design and simulation considerations (e.g. sphere-cone angle change, mass change, wind turbulence). These tools allowed for the current EES design to demonstrate the ability to achieve passive stability and can be an invaluable tool for consideration in the design of parachute-less Earth-return vehicles.

Rohan Deshmukh↗

Bringing Analysis Closer to Data: Developing a Visualization Tool for L2 Earth Science Satellite Data

Earth Science satellite missions provide a unique opportunity for scientists to visualize complex and multifaceted observations projected geospatially across maps of the Earth. While visualization tools can help scientists comprehend, analyze, and share data, visualizing Level-2 Earth Sciences data poses its own specific set of challenges. Since the geospatial information in Level-2 data files is stored as independent variables, the plotting process involves matching dimensional information from latitude and longitude with a desired variable. Variables are stored in different ways across various Earth Science data file formats, which complicates the process of extracting data and plotting variables from a given file without requiring extensive user input and prerequisite familiarity with the file type variable structure. In coordination with NASA’s Goddard Earth Sciences Data Information Services Center (GES DISC), the team developed a Level-2 Earth Science data visualization tool that aims to address some of the complexities associated with plotting Level-2 data. This tool offers command-line and user interface support for file and variable selection to accommodate varying use cases and degrees of user familiarity with the structure of a given file. The visualization tool is written in Python 3 and utilizes a modular approach to facilitate continued expansion and reuse. In addressing some common complications involved in plotting Level-2 Earth Sciences data, the tool aims to help to link the process of analysis more directly with data acquisition and visualization, bringing analysis closer to data across levels of processing.

Li, Angela W.↗

GMI-IPS: Python Processing Software for Aircraft Campaigns

NASA's Atmospheric Tomography Mission (ATom) seeks to understand the impact of anthropogenic air pollution on gases in the Earth's atmosphere. Four flight campaigns are being deployed on a seasonal basis to establish a continuous global-scale data set intended to improve the representation of chemically reactive gases in global atmospheric chemistry models. The Global Modeling Initiative (GMI), is creating chemical transport simulations on a global scale for each of the ATom flight campaigns. To meet the computational demands required to translate the GMI simulation data to grids associated with the flights from the ATom campaigns, the GMI ICARTT Processing Software (GMI-IPS) has been developed and is providing key functionality for data processing and analysis in this ongoing effort. The GMI-IPS is written in Python and provides computational kernels for data interpolation and visualization tasks on GMI simulation data. A key feature of the GMI-IPS, is its ability to read ICARTT files, a text-based file format for airborne instrument data, and extract the required flight information that defines regional and temporal grid parameters associated with an ATom flight. Perhaps most importantly, the GMI-IPS creates ICARTT files containing GMI simulated data, which are used in collaboration with ATom instrument teams and other modeling groups. The initial main task of the GMI-IPS is to interpolate GMI model data to the finer temporal resolution (1-10 seconds) of a given flight. The model data includes basic fields such as temperature and pressure, but the main focus of this effort is to provide species concentrations of chemical gases for ATom flights. The software, which uses parallel computation techniques for data intensive tasks, linearly interpolates each of the model fields to the time resolution of the flight. The temporally interpolated data is then saved to disk, and is used to create additional derived quantities. In order to translate the GMI model data to the spatial grid of the flight path as defined by the pressure, latitude, and longitude points at each flight time record, a weighted average is then calculated from the nearest neighbors in two dimensions (latitude, longitude). Using SciPya's Regular Grid Interpolator, interpolation functions are generated for the GMI model grid and the calculated weighted averages. The flight path points are then extracted from the ATom ICARTT instrument file, and are sent to the multi-dimensional interpolating functions to generate GMI field quantities along the spatial path of the flight. The interpolated field quantities are then written to a ICARTT data file, which is stored for further manipulation. The GMI-IPS is aware of a generic ATom ICARTT header format, containing basic information for all flight campaigns. The GMI-IPS includes logic to edit metadata for the derived field quantities, as well as modify the generic header data such as processing dates and associated instrument files. The ICARTT interpolated data is then appended to the modified header data, and the ICARTT processing is complete for the given flight and ready for collaboration. The output ICARTT data adheres to the ICARTT file format standards V1.1. The visualization component of the GMI-IPS uses Matplotlib extensively and has several functions ranging in complexity. First, it creates a model background curtain for the flight (time versus model eta levels) with the interpolated flight data superimposed on the curtain. Secondly, it creates a time-series plot of the interpolated flight data. Lastly, the visualization component creates averaged 2D model slices (longitude versus latitude) with overlaid flight track circles at key pressure levels. The GMI-IPS consists of a handful of classes and supporting functionality that have been generalized to be compatible with any ICARTT file that adheres to the base class definition. The base class represents a generic ICARTT entry, only defining a single time entry and 3D spatial positioning parameters. Other classes inherit from this base class; several classes for input ICARTT instrument files, which contain the necessary flight positioning information as a basis for data processing, as well as other classes for output ICARTT files, which contain the interpolated model data. Utility classes provide functionality for routine procedures such as: comparing field names among ICARTT files, reading ICARTT entries from a data file and storing them in data structures, and returning a reduced spatial grid based on a collection of ICARTT entries. Although the GMI-IPS is compatible with GMI model data, it can be adapted with reasonable effort for any simulation that creates Hierarchical Data Format (HDF) files. The same can be said of its adaptability to ICARTT files outside of the context of the ATom mission. The GMI-IPS contains just under 30,000 lines of code, eight classes, and a dozen drivers and utility programs. It is maintained with GIT source code management and has been used to deliver processed GMI model data for the ATom campaigns that have taken place to date.

Damon, M. R.↗

Procedure for Tooth Contact Analysis of a Face Gear Meshing With a Spur Gear Using Finite Element Analysis

A procedure was developed to perform tooth contact analysis between a face gear meshing with a spur pinion using finite element analysis. The face gear surface points from a previous analysis were used to create a connected tooth solid model without gaps or overlaps. The face gear surface points were used to create a five tooth face gear Patran model (with rim) using Patran PCL commands. These commands were saved in a series of session files suitable for Patran input. A four tooth spur gear that meshes with the face gear was designed and constructed with Patran PCL commands. These commands were also saved in a session files suitable for Patran input. The orientation of the spur gear required for meshing with the face gear was determined. The required rotations and translations are described and built into the session file for the spur gear. The Abaqus commands for three-dimensional meshing were determined and verified for a simplified model containing one spur tooth and one face gear tooth. The boundary conditions, loads, and weak spring constraints were determined to make the simplified model work. The load steps and load increments to establish contact and obtain a realistic load was determined for the simplified two tooth model. Contact patterns give some insight into required mesh density. Building the two gears in two different local coordinate systems and rotating the local coordinate systems was verified as an easy way to roll the gearset through mesh. Due to limitation of swap space, disk space and time constraints of the summer period, the larger model was not completed.

Bibel, George↗

User's guide for a large signal computer model of the helical traveling wave tube

The use is described of a successful large-signal, two-dimensional (axisymmetric), deformable disk computer model of the helical traveling wave tube amplifier, an extensively revised and operationally simplified version. We also discuss program input and output and the auxiliary files necessary for operation. Included is a sample problem and its input data and output results. Interested parties may now obtain from the author the FORTRAN source code, auxiliary files, and sample input data on a standard floppy diskette, the contents of which are described herein.

Palmer, Raymond W.↗