Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “file format”

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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS1998

Advanced Data Format (ADF) Software Library and Users Guide

The "CFD General Notation System" (CGNS) consists of a collection of conventions, and conforming software, for the storage and retrieval of Computational Fluid Dynamics (CFD) data. It facilitates the exchange of data between sites and applications, and helps stabilize the archiving of aerodynamic data. This effort was initiated in order to streamline the procedures in exchanging data and software between NASA and its customers, but the goal is to develop CGNS into a National Standard for the exchange of aerodynamic data. The CGNS development team is comprised of members from Boeing Commercial. Airplane Group, NASA-Ames, NASA-Langley, NASA-Lewis, McDonnell-Douglas Corporation (now Boeing-St. Louis), Air Force-Wright Lab., and ICEM-CFD Engineering. The elements of CGNS address all activities associated with the storage of data on external media and its movement to and from application programs. These elements include: 1) The Advanced Data Format (ADF) Database manager, consisting of both a file format specification and its 1/0 software, which handles the actual reading and writing of data from and to external storage media; 2) The Standard Interface Data Structures (SIDS), which specify the intellectual content of CFD data and the conventions governing naming and terminology; 3) The SIDS-to-ADF File Mapping conventions, which specify the exact location where the CFD data defined by the SIDS is to be stored within the ADF file(s); and 4) The CGNS Mid-level Library, which provides CFD-knowledgeable routines suitable for direct installation into application codes. The ADF is a generic database manager with minimal intrinsic capability. It was written for the purpose of storing large numerical datasets in an efficient, platform independent manner. To be effective, it must be used in conjunction with external agreements on how the data will be organized within the ADF database such defined by the SIDS. There are currently 34 user callable functions that comprise the ADF Core library and are described in the Users Guide. The library is written in C, but each function has a FORTRAN counterpart.

Smith, Matthew↗
NASA NTRS1990

PLOT3D user's manual

PLOT3D is a computer graphics program designed to visualize the grids and solutions of computational fluid dynamics. Seventy-four functions are available. Versions are available for many systems. PLOT3D can handle multiple grids with a million or more grid points, and can produce varieties of model renderings, such as wireframe or flat shaded. Output from PLOT3D can be used in animation programs. The first part of this manual is a tutorial that takes the reader, keystroke by keystroke, through a PLOT3D session. The second part of the manual contains reference chapters, including the helpfile, data file formats, advice on changing PLOT3D, and sample command files.

Walatka, Pamela P.↗
NASA NTRS1992

Enhancements to the GRIDGEN structured grid generation system for internal and external flow applications

GRIDGEN is a government domain software package for interactive generation of multiple block grids around general configurations. Though it has been freely available since 1989, it has not been widely embraced by the internal flow community due to a misconception that it was designed for external flow use only. In reality GRIDGEN has always worked for internal flow applications, and GRIDGEN ongoing enhancements are increasing the quality of and efficiency with which grids for external and internal flow problems may be constructed. The software consists of four codes used to perform the four steps of the grid generation process. GRIDBLOCK is first used to decompose the flow domain into a collection of component blocks and then to establish interblock connections and flow solver boundary conditions. GRIDGEN2D is then used to generate surface grids on the outer shell of each component block. GRIDGEN3D generates grid points on the interior of each block, and finally GRIDVUE3D is used to inspect the resulting multiple block grid. Three of these codes (GRIDBLOCK, GRIDGEN2D, and GRIDVUE3D) are highly interactive and graphical in nature, and currently run on Silicon Graphics, Inc., and IBM RS/6000 workstations. The lone batch code (GRIDGEN3D) may be run on any of several Unix based platforms. Surface grid generation in GRIDGEN2D is being improved with the addition of higher order surface definitions (NURBS and parametric surfaces input in IGES format and bicubic surfaces input in PATRAN Neutral File format) and double precision mathematics. In addition, two types of automation have been added to GRIDGEN2D that reduce the learning curve slope for new users and eliminate work for experienced users. Volume grid generation using GRIDGEN3D has been improved via the addition of an advanced hybrid control function formulation that provides both orthogonality and clustering control at the block faces and clustering control on the block interior.

Steinbrenner, John P.↗
NASA NTRS2000

BOREAS RSS-14 Level-2 GOES-7 Shortwave and Longwave Radiation Images

The BOREAS RSS-14 team collected and processed several GOES-7 and GOES-8 image data sets that covered the BOREAS study region. This data set contains images of shortwave and longwave radiation at the surface and top of the atmosphere derived from collected GOES-7 data. The data cover the time period of 05-Feb-1994 to 20-Sep-1994. The images missing from the temporal series were zero-filled to create a consistent sequence of files. The data are stored in binary image format files. Due to the large size of the images, the level-1a GOES-7 data are not contained on the BOREAS CD-ROM set. An inventory listing file is supplied on the CD-ROM to inform users of what data were collected. The level-1a GOES-7 image data are available from the Earth Observing System Data and Information System (EOSDIS) Oak Ridge National Laboratory (ORNL) Distributed Active Archive Center (DAAC). See sections 15 and 16 for more information. The data files are available on a CD-ROM (see document number 20010000884).

Hall, Forrest G.↗
NASA NTRSDate not supplied

New Features of the NEQAIR Radiation Code

The longest-lived code for predicting shock layer radiation, NEQAIR, is now in its 5th decade of service. Substantial changes to the code have been made over the previous decade, the most recent report of which was at the 5th Workshop on Radiation in High Temperature Gases in 2014, for the version referred to as NEQAIR14. This paper will review some of the improvements made to the NEQAIR code since then, which is now at v15.2. Some of these features are discussed briefly below. NEQAIR15 and subsequent versions have enabled parallel evaluation of multiple lines of sight. This is accomplished by utilizing the HDF5 file format and placing multiple lines into a single file, LOS.h5, which is used for both input and output. This approach enables straightforward parallel execution both over the number of lines of sight and the number of points per line. For large problems, runtime reduces linearly with the number of nodes deployed since each line is processed independently by a subset of MPI ranks. Three applications of the multi-line solver are discussed. The first has to do with performing loosely coupled radiation-flowfield solutions. In this case the computed absorption and emission coefficients are used to evaluate the total energy absorbed or emitted at each point, allowing evaluation of the volumetric source term in the flowfield. The second computation is for obtaining heat flux from nonuniform flows, which require integration over spherical co-ordinates. These are of particular interest for evaluating radiation on the vehicle backshell. This 3D option improves the angular integration scheme and allows adaptive line selection that together reduce the number of lines required by about an order of magnitude. The final application is for remote observation, which is essentially the 3D integration problem over a small solid angle. For all three of these computations, data can be stored in the HDF5 file which allows a NEQAIR run to be restarted when it times out, or to add atmospheric absorption or instrument scan functions. An additional level of parallelism is enabled in NEQAIR15.2 using GPU routines. The GPU parallelism has realized up to 8x speed-up when running on a single core but diminishes as CPU parallelism is increased. For running multi-line simulations, it may be easier to reserve a large number of CPU nodes than to obtain the number of GPU nodes required for similar performance. A GUI, known as NEQTPY, allows for reading and creating input files, running NEQAIR, and displaying results. A significant feature of NEQTPY is the ability to perform spectral fits to data. The fits can operate on a single line spectrum (radiance vs. wavelength) or a 3D input file with multiple columns of data. Other new features include improved constants, additional species, more detailed non-Boltzmann modelling, advanced user controls, the ability to read and calculate spectra from HITRAN datafiles, photodissociation and photoionization cross-sections. A “fast” automatic grid option may reduce the size and time of spectral calculations while still maintaining good accuracy for total heat flux.

Brett A Cruden↗
NASA NTRS2013

Application Program Interface for the Orion Aerodynamics Database

The Application Programming Interface (API) for the Crew Exploration Vehicle (CEV) Aerodynamic Database has been developed to provide the developers of software an easily implemented, fully self-contained method of accessing the CEV Aerodynamic Database for use in their analysis and simulation tools. The API is programmed in C and provides a series of functions to interact with the database, such as initialization, selecting various options, and calculating the aerodynamic data. No special functions (file read/write, table lookup) are required on the host system other than those included with a standard ANSI C installation. It reads one or more files of aero data tables. Previous releases of aerodynamic databases for space vehicles have only included data tables and a document of the algorithm and equations to combine them for the total aerodynamic forces and moments. This process required each software tool to have a unique implementation of the database code. Errors or omissions in the documentation, or errors in the implementation, led to a lengthy and burdensome process of having to debug each instance of the code. Additionally, input file formats differ for each space vehicle simulation tool, requiring the aero database tables to be reformatted to meet the tool s input file structure requirements. Finally, the capabilities for built-in table lookup routines vary for each simulation tool. Implementation of a new database may require an update to and verification of the table lookup routines. This may be required if the number of dimensions of a data table exceeds the capability of the simulation tools built-in lookup routines. A single software solution was created to provide an aerodynamics software model that could be integrated into other simulation and analysis tools. The highly complex Orion aerodynamics model can then be quickly included in a wide variety of tools. The API code is written in ANSI C for ease of portability to a wide variety of systems. The input data files are in standard formatted ASCII, also for improved portability. The API contains its own implementation of multidimensional table reading and lookup routines. The same aerodynamics input file can be used without modification on all implementations. The turnaround time from aerodynamics model release to a working implementation is significantly reduced

Robinson, Philip E.↗
NASA NTRS1981

As-Built design specification for UNIV4VEC

The UNIV4VEC program which is part of the CLSFYG package is described. This program reads a CLASFYG vector parameter file and converts it to a four channel universal formatted file.

Tompkins, M. A.↗
NASA NTRS1994

SEQ-REVIEW: A tool for reviewing and checking spacecraft sequences

A key component of JPL's strategy to make space missions faster, better and cheaper is the Advanced Multi-Mission Operations System (AMMOS), a ground software intensive system currently in use and in further development. AMMOS intends to eliminate the cost of re-engineering a ground system for each new JPL mission. This paper discusses SEQ-REVIEW, a component of AMMOS that was designed to facilitate and automate the task of reviewing and checking spacecraft sequences. SEQ-REVIEW is a smart browser for inspecting files created by other sequence generation tools in the AMMOS system. It can parse sequence-related files according to a computer-readable version of a 'Software Interface Specification' (SIS), which is a standard document for defining file formats. It lets users display one or several linked files and check simple constraints using a Basic-like 'Little Language'. SEQ-REVIEW represents the first application of the Quality Function Development (QFD) method to sequence software development at JPL. The paper will show how the requirements for SEQ-REVIEW were defined and converted into a design based on object-oriented principles. The process starts with interviews of potential users, a small but diverse group that spans multiple disciplines and 'cultures'. It continues with the development of QFD matrices that related product functions and characteristics to user-demanded qualities. These matrices are then turned into a formal Software Requirements Document (SRD). The process concludes with the design phase, in which the CRC (Class, Responsibility, Collaboration) approach was used to convert requirements into a blueprint for the final product.

Maldague, Pierre F.↗
NASA NTRS2007

Blurring the Inputs: A Natural Language Approach to Sensitivity Analysis

To document model parameter uncertainties and to automate sensitivity analyses for numerical simulation codes, a natural-language-based method to specify tolerances has been developed. With this new method, uncertainties are expressed in a natural manner, i.e., as one would on an engineering drawing, namely, 5.25 +/- 0.01. This approach is robust and readily adapted to various application domains because it does not rely on parsing the particular structure of input file formats. Instead, tolerances of a standard format are added to existing fields within an input file. As a demonstration of the power of this simple, natural language approach, a Monte Carlo sensitivity analysis is performed for three disparate simulation codes: fluid dynamics (LAURA), radiation (HARA), and ablation (FIAT). Effort required to harness each code for sensitivity analysis was recorded to demonstrate the generality and flexibility of this new approach.

Kleb, William L.↗
NASA NTRS2017

Progress Report on the Airborne Composition Standard Variable Name and Time Series Working Groups of the 2017 ESDSWG

The role of NASA's Earth Science Data Systems Working Groups (ESDSWG) is to make recommendations relevant to NASA's Earth science data systems from users' experiences and community insight. Each group works independently, focusing on a unique topic. Progress of two of the 2017 Working Groups will be presented. In a single airborne field campaign, there can be several different instruments and techniques that measure the same parameter on one or more aircraft platforms. Many of these same parameters are measured during different airborne campaigns using similar or different instruments and techniques. The Airborne Composition Standard Variable Name Working Group is working to create a list of variable standard names that can be used across all airborne field campaigns in order to assist in the transition to the ICARTT Version 2.0 file format. The overall goal is to enhance the usability of ICARTT files and the search ability of airborne field campaign data. The Time Series Working Group (TSWG) is a continuation of the 2015 and 2016 Time Series Working Groups. In 2015, we started TSWG with the intention of exploring the new OGC (Open Geospatial Consortium) WaterML 2 standards as a means for encoding point-based time series data from NASA satellites. In this working group, we realized that WaterML 2 might not be the best solution for this type of data, for a number of reasons. Our discussion with experts from other agencies, who have worked on similar issues, identified several challenges that we would need to address. As a result, we made the recommendation to study the new TimeseriesML 1.0 standard of OGC as a potential NASA time series standard. The 2016 TSWG examined closely the TimeseriesML 1.0 and, in coordination with the OGC TimeseriesML Standards Working Group, identified certain gaps in TimeseriesML 1.0 that would need to be addressed for the standard to be applicable to NASA time series data. An engineering report was drafted based on the OGC Engineering Report template, describing recommended changes to TimeseriesML 1.0, in the form of use cases. In 2017, we are conducting interoperability experiments to implement the use cases and demonstrate the feasibility and suitability of these modifications for NASA and related user communities. The results will be incorporated into the existing draft engineering report.

OGC (Open Geospatial Consortium) WaterML 2 standar↗
NASA NTRS2019

NASA Orbital Debris Engineering Model ORDEM 3.1 - Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.1 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.1. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.1 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.1, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.1 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.1 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Vavrin, Andrew B.↗
NASA NTRSDate not supplied

Cloud Optimized Data Formats

Cloud computing offers the promise of being able to analyze Big Data earth Observations at scale, by allowing scientists to deploy many nodes at once to analyze the data. However, in order to take full advantage of cloud scalability, it is often necessary to reorganize and reformat the data to enable fine-grained, parallel access to the data in Web Object Storage. NASA recently conducted a study of several formats that are optimized for analysis in the cloud: Parquet, zarr, HDF (Hierarchical Data Format) in the Cloud, and Cloud-Optimized GeoTIFF (Tagged Image File Format). They were compared against non-cloud-optimized formats, netCDF (network Common Data Form) and GeoTIFF, with criteria based both on stewardship and analysis performance.

Christopher Lynnes↗
NASA NTRS2023

NASA Orbital Debris Engineering Model ORDEM 3.2 – Software User Guide

This National Aeronautics and Space Administration (NASA) Orbital Debris Engineering Model (ORDEM) 3.2 Software User Guide accompanies delivery of the latest upgraded version of the model, ORDEM 3.2. The user guide also provides a top-level program description and a list of capabilities. It includes descriptions of runtime error and information codes, input/output file formats, runtimes for different orbit configurations, and how to use uncertainty files. ORDEM 3.2 supersedes the previous NASA Orbital Debris Program Office (ODPO) models – ORDEM 3.0 (Stansbery, et al. 2014) and ORDEM2000 (Liou, et al. 2002). The availability of new sensor and in situ data, re-analysis of older data, and development of new analytical techniques has enabled the construction of this more comprehensive and sophisticated model. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. For example, these range from the conventional flux vs. average debris size (or altitude bin) for chosen analysis orbits (or views) to the more complex color-contoured, two-dimensional (2-D) directional flux diagrams in local spacecraft elevation and azimuth. The current model, ORDEM 3.2, supports spacecraft as well as telescope/radar project assessments. ORDEM 3.2 contains updated debris populations covering low Earth orbit (LEO, up to 2000 km altitude) to geosynchronous orbit (GEO, up to 40,000 km altitude) and can assess debris calculations up to year 2050, extending coverage past the previous limit of 2035 in ORDEM 3.0. Although populations differ from its predecessor, ORDEM 3.2 is functionally the same as ORDEM 3.0 and can support ORDEM 3.0 projects through backward compatibility.

Andrew Vavrin↗
NASA NTRS2004

MPT Prediction of Aircraft-Engine Fan Noise

A collection of computer programs has been developed that implements a procedure for predicting multiple-pure-tone (MPT) noise generated by fan blades of an aircraft engine (e.g., a turbofan engine). MPT noise arises when the fan is operating with supersonic relative tip Mach No. Under this flow condition, there is a strong upstream running shock. The strength and position of this shock are very sensitive to blade geometry variations. For a fan where all the blades are identical, the primary tone observed upstream of the fan will be the blade passing frequency. If there are small variations in geometry between blades, then tones below the blade passing frequency arise MPTs. Stagger angle differences as small as 0.1 can give rise to significant MPT. It is also noted that MPT noise is more pronounced when the fan is operating in an unstarted mode. Computational results using a three-dimensional flow solver to compute the complete annulus flow with non-uniform fans indicate that MPT noise can be estimated in a relatively simple way. Hence, once the effect of a typical geometry variation of one blade in an otherwise uniform blade row is known, the effect of all the blades being different can be quickly computed via superposition. Two computer programs that were developed as part of this work are used in conjunction with a user s computational fluid dynamics (CFD) code to predict MPT spectra for a fan with a specified set of geometric variations: (1) The first program ROTBLD reads the users CFD solution files for a single blade passage via an API (Application Program Interface). There are options to replicate and perturb the geometry with typical variations stagger, camber, thickness, and pitch. The multi-passage CFD solution files are then written in the user s file format using the API. (2) The second program SUPERPOSE requires two input files: the first is the circumferential upstream pressure distribution extracted from the CFD solution on the multi-passage mesh, the second file defines the geometry variations of each blade in a complete fan. Superposition is used to predict the spectra resulting from the geometric variations.

Connell, Stuart D.↗
NASA NTRS2011

Determining the Completeness of the Nimbus Meteorological Data Archive

NASA launched the Nimbus series of meteorological satellites in the 1960s and 70s. These satellites carried instruments for making observations of the Earth in the visible, infrared, ultraviolet, and microwave wavelengths. The original data archive consisted of a combination of digital data written to 7-track computer tapes and on various film media. Many of these data sets are now being migrated from the old media to the GES DISC modern online archive. The process involves recovering the digital data files from tape as well as scanning images of the data from film strips. Some of the challenges of archiving the Nimbus data include the lack of any metadata from these old data sets. Metadata standards and self-describing data files did not exist at that time, and files were written on now obsolete hardware systems and outdated file formats. This requires creating metadata by reading the contents of the old data files. Some digital data files were corrupted over time, or were possibly improperly copied at the time of creation. Thus there are data gaps in the collections. The film strips were stored in boxes and are now being scanned as JPEG-2000 images. The only information describing these images is what was written on them when they were originally created, and sometimes this information is incomplete or missing. We have the ability to cross-reference the scanned images against the digital data files to determine which of these best represents the data set from the various missions, or to see how complete the data sets are. In this presentation we compared data files and scanned images from the Nimbus-2 High-Resolution Infrared Radiometer (HRIR) for September 1966 to determine whether the data and images are properly archived with correct metadata.

Johnson, James↗
NASA NTRS2017

Kepler Fine Guidance Sensor Data

The Kepler and K2 missions collected Fine Guidance Sensor (FGS) data in addition to the science data, as discussed in the Kepler Instrument Handbook (KIH, Van Cleve and Caldwell 2016). The FGS CCDs are frame transfer devices (KIH Table 7) located in the corners of the Kepler focal plane (KIH Figure 24), which are read out 10 times every second. The FGS data are being made available to the user community for scientific analysis as flux and centroid time series, along with a limited number of FGS full frame images which may be useful for constructing a World Coordinate System (WCS) or otherwise putting the time series data in context. This document will describe the data content and file format, and give example MATLAB scripts to read the time series. There are three file types delivered as the FGS data.1. Flux and Centroid (FLC) data: time series of star signal and centroid data. 2. Ancillary FGS Reference (AFR) data: catalog of information about the observed stars in the FLC data. 3. FGS Full-Frame Image (FGI) data: full-frame image snapshots of the FGS CCDs.

Kepler↗
NASA NTRS2019

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.↗
NASA NTRS2010

Development of an e-VLBI Data Transport Software Suite with VDIF

We have developed a software library (KVTP-lib) for VLBI data transmission over the network with the VDIF (VLBI Data Interchange Format), which is the newly proposed standard VLBI data format designed for electronic data transfer over the network. The software package keeps the application layer (VDIF frame) and the transmission layer separate, so that each layer can be developed efficiently. The real-time VLBI data transmission tool sudp-send is an application tool based on the KVTP-lib library. sudp-send captures the VLBI data stream from the VSI-H interface with the K5/VSI PC-board and writes the data to file in standard Linux file format or transmits it to the network using the simple- UDP (SUDP) protocol. Another tool, sudp-recv , receives the data stream from the network and writes the data to file in a specific VLBI format (K5/VSSP, VDIF, or Mark 5B). This software system has been implemented on the Wettzell Tsukuba baseline; evaluation before operational employment is under way.

Sekido, Mamoru↗