SEARCH · Engineering Papers

Results for “File System”

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

SourceResearch connectionFrom yearThrough year

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

At least 1,441 records · Page 80

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Ground Segment Operations Concept for the Orion Artemis-2 Optical Communications System

The ACCESS Project (formerly Space Network) will implement an optical communications ground segment to support the Orion Artemis II Optical Communications (O2O) demonstration as part of the next manned human spaceflight mission to the moon, Artemis II. O2O implements laser communication (lasercomm) technology for operational use on the Orion series of spacecraft, as a development test objective (DTO), in order to demonstrate the feasibility and operational utility of lasercomm for human spaceflight missions. O2O consists of three segments: Space Segment, Ground Segment, and Operations Segment. The Space Segment consists of the Space Terminal Element and the Orion spacecraft. The Space Terminal Element effort is managed by the GSFC Laser-Enhanced Mission Communications Navigation and Operational Services (LEMNOS) project in collaboration with MIT Lincoln Laboratory. The Ground Segment consists of an optical ground terminal (GT) at the White Sands Complex (WSC), which is being developed in collaboration with MIT Lincoln Laboratory, the Ground Segment Operations and Analysis (GSOA) element and Ground Data Element (GDE), and a second optical GT in the Optical Communications Telescope Laboratory (OCTL) at the JPL Table Mountain Facility. The Operations Segment consists of the Artemis II Mission Control Center (MCC), the Lasercomm Space Terminal Console (LSTC), and the Lasercomm Link Planning & Analysis Center (LPAC), all located at the Johnson Space Center (JSC). O2O utilizes pulse-position modulation (PPM) direct-to-earth services resulting in an 80 Mbps downlink data rate from lunar orbit. The O2O concept of operations is to provide optical services for a minimum of 1 hour per day for each day of the Artemis II mission. O2O will utilize a 10-20 Mbps uplink data rate and 40-260 Mbps downlink data rate, depending on the Artemis II mission phase. The ACCESS project will also provide a centralized mission data interface for user data distribution and storage to the MCC and perform planning and scheduling of services in coordination with the Operations Segment for the O2O Ground Segment. The O2O Ground Segment will support the following O2O mission phases: Pre-Mission Planning; Daily Operations Planning; Event Execution; and Post-Pass Reporting. O2O will be used to exchange data files between Orion and the MCC and to distribute real-time video through the optical downlink service to the MCC; which would not be possible without the high-bandwidth link that O2O will provide to Orion. In this paper, I will discuss the O2O Ground Segment development approach and how it will support these critical O2O functions: plan and schedule the contact; acquire and track the optical link; flow information bidirectionally; distribute information; and control and accommodate the system.

optical communications↗

NASA NTRS1992

Development of the FITS tools package for multiple software environments

The HEASARC is developing a package of general purpose software for analyzing data files in FITS format. This paper describes the design philosophy which makes the software both machine-independent (it runs on VAXs, Suns, and DEC-stations) and software environment-independent. Currently the software can be compiled and linked to produce IRAF tasks, or alternatively, the same source code can be used to generate stand-alone tasks using one of two implementations of a user-parameter interface library. The machine independence of the software is achieved by writing the source code in ANSI standard Fortran or C, using the machine-independent FITSIO subroutine interface for all data file I/O, and using a standard user-parameter subroutine interface for all user I/O. The latter interface is based on the Fortran IRAF Parameter File interface developed at STScI. The IRAF tasks are built by linking to the IRAF implementation of this parameter interface library. Two other implementations of this parameter interface library, which have no IRAF dependencies, are now available which can be used to generate stand-alone executable tasks. These stand-alone tasks can simply be executed from the machine operating system prompt either by supplying all the task parameters on the command line or by entering the task name after which the user will be prompted for any required parameters. A first release of this FTOOLS package is now publicly available. The currently available tasks are described, along with instructions on how to obtain a copy of the software.

Pence, W. D.↗

NASA NTRS1997

Application of Modular Modeling System to Predict Evaporation, Infiltration, Air Temperature, and Soil Moisture

Models are used for numerous application including hydrology. The Modular Modeling System (MMS) is one of the few that can simulate a hydrology process. MMS was tested and used to compare infiltration, soil moisture, daily temperature, and potential and actual evaporation for the Elinsboro sandy loam soil and the Mattapex silty loam soil in the Microwave Radiometer Experiment of Soil Moisture Sensing at Beltsville Agriculture Research Test Site in Maryland. An input file for each location was created to nut the model. Graphs were plotted, and it was observed that the model gave a good representation for evaporation for both plots. In comparing the two plots, it was noted that infiltration and soil moisture tend to peak around the same time, temperature peaks in July and August and the peak evaporation was observed on September 15 and July 4 for the Elinsboro Mattapex plot respectively. MMS can be used successfully to predict hydrological processes as long as the proper input parameters are available.

Boggs, Johnny↗

NASA NTRS2011

Development of Monte Carlo Capability for Orion Parachute Simulations

Parachute test programs employ Monte Carlo simulation techniques to plan testing and make critical decisions related to parachute loads, rate-of-descent, or other parameters. This paper describes the development and use of a MATLAB-based Monte Carlo tool for three parachute drop test simulations currently used by NASA. The Decelerator System Simulation (DSS) is a legacy 6 Degree-of-Freedom (DOF) simulation used to predict parachute loads and descent trajectories. The Decelerator System Simulation Application (DSSA) is a 6-DOF simulation that is well suited for modeling aircraft extraction and descent of pallet-like test vehicles. The Drop Test Vehicle Simulation (DTVSim) is a 2-DOF trajectory simulation that is convenient for quick turn-around analysis tasks. These three tools have significantly different software architectures and do not share common input files or output data structures. Separate Monte Carlo tools were initially developed for each simulation. A recently-developed simulation output structure enables the use of the more sophisticated DSSA Monte Carlo tool with any of the core-simulations. The task of configuring the inputs for the nominal simulation is left to the existing tools. Once the nominal simulation is configured, the Monte Carlo tool perturbs the input set according to dispersion rules created by the analyst. These rules define the statistical distribution and parameters to be applied to each simulation input. Individual dispersed parameters are combined to create a dispersed set of simulation inputs. The Monte Carlo tool repeatedly executes the core-simulation with the dispersed inputs and stores the results for analysis. The analyst may define conditions on one or more output parameters at which to collect data slices. The tool provides a versatile interface for reviewing output of large Monte Carlo data sets while preserving the capability for detailed examination of individual dispersed trajectories. The Monte Carlo tool described in this paper has proven useful in planning several Crew Exploration Vehicle parachute tests.

Moore, James W.↗

NASA NTRS2018

Building a Plastics Fabrication Laboratory on the ISS: FabLab, MANTIS, Refabricator, CRISSP, ERASMUS, and MAMBA

The objective of NASA's In Space Manufacturing program is to develop manufacturing technologies and processes necessary to provide "on-demand, sustainable operations for exploration missions." Using the ISS as a test bed, in 2014, NASA installed and successfully tested a 3D printer for in-space operations, demonstrating the 3D printing process as well as sending digital files for printing from earth to the printer. The success of this technology demonstration has shown that on-orbit manufacturing technologies can be used to limit the earth reliance for cis-lunar missions. Because of this success, numerous opportunities have been provided by NASA to further in-space manufacturing by focusing on the development of highly autonomous manufacturing systems, recycling technologies, and robotics with the ultimate goal of building a fabrication laboratory now within reach. From technologies developed for ISS activities and demonstration missions, Tethers Unlimited, Inc. (TUI) is building a Plastics Manufacturing Laboratory capable of fabricating parts on-demand and as-needed while recycling waste plastics with minimal human interaction required. Parts will be manufactured through additive manufacturing. Precision machining will ensure manufactured parts are in tolerance with the end-use requirements. Recycling waste plastics will enable both waste from the crew and waste from processing to be re-processed into something new. In addition, these manufacturing and recycling technologies are supported by part verification/validation technique and robotic servicing, minimizing human interaction with the system and eventually enabling unmanned off-world manufacturing.

Muhlbauer, Rachel↗

NASA NTRS2005

Development and operations of the astrophysics data system

Abstract service - Continued regular updates of abstracts in the databases, both at SA0 and at all mirror sites. - Modified loading scripts to accommodate changes in data format (PhyS) - Discussed data deliveries with providers to clear up problems with format or other errors (EGU) - Continued inclusion of large numbers of historical literature volumes and physics conference volumes xeroxed from the library. - Performed systematic fixes on some data sets in the database to account for changes in article numbering (AGU journals) - Implemented linking of ADS bibliographic records with multimedia files - Debugged and fixed obscure connection problems with the ADS Korean mirror site which were preventing successful updates of the data holdings. - Wrote procedure to parse citation data and characterize an ADS record based on its citation ratios within each database.

Murray, Stephen S.↗

NASA NTRS1984

Some methods of computing platform transmitter terminal location estimates

A position estimation algorithm was developed to track a humpback whale tagged with an ARGOS platform after a transmitter deployment failure and the whale's diving behavior precluded standard methods. The algorithm is especially useful where a transmitter location program exists; it determines the classical keplarian elements from the ARGOS spacecraft position vectors included with the probationary file messages. A minimum of three distinct messages are required. Once the spacecraft orbit is determined, the whale is located using standard least squares regression techniques. Experience suggests that in instances where circumstances inherent in the experiment yield message data unsuitable for the standard ARGOS reduction, (message data may be too sparse, span an insufficient period, or include variable-length messages). System ARGOS can still provide much valuable location information if the user is willing to accept the increased location uncertainties.

Hoisington, C. M.↗

NASA NTRS1995

Using dark current data to estimate AVIRIS noise covariance and improve spectral analyses

Starting in 1994, all AVIRIS data distributions include a new product useful for quantification and modeling of the noise in the reported radiance data. The 'postcal' file contains approximately 100 lines of dark current data collected at the end of each data acquisition run. In essence this is a regular spectral-image cube, with 614 samples, 100 lines and 224 channels, collected with a closed shutter. Since there is no incident radiance signal, the recorded DN measure only the DC signal level and the noise in the system. Similar dark current measurements, made at the end of each line are used, with a 100 line moving average, to remove the DC signal offset. Therefore, the pixel-by-pixel fluctuations about the mean of this dark current image provide an excellent model for the additive noise that is present in AVIRIS reported radiance data. The 61,400 dark current spectra can be used to calculate the noise levels in each channel and the noise covariance matrix. Both of these noise parameters should be used to improve spectral processing techniques. Some processing techniques, such as spectral curve fitting, will benefit from a robust estimate of the channel-dependent noise levels. Other techniques, such as automated unmixing and classification, will be improved by the stable and scene-independence noise covariance estimate. Future imaging spectrometry systems should have a similar ability to record dark current data, permitting this noise characterization and modeling.

Boardman, Joseph W.↗

NASA NTRS1998

Interfacing with Legacy using Remote Method Invocation

The assignment described was enough to make a neophyte Java developer bolt for the door: provide a remote method for use by an applet which invokes a native method that wraps a function in an existing legacy library. The purpose of the remote method is to return an instance of a class object whose contents reflect the data structure returned by the legacy function. While embroiled in implementation, I would have spent the time wading through their JNI use group archive as well, but I couldn't seem to locate one. Subsequently, I made the decision to try to document my findings in order to assist others. Before we start on the class design, let's look at what the existing legacy code does. The C function to be called, Get-Legacy-Data, consists of two steps: an ASII file is read from the local disk and its contents are parsed into a Legacy_Type structure whose address is passed as an argument by the caller. The legacy code was compiled into a shared object library, legacy. so, using the IRIX 6.2 compiler and then loaded onto the Web server, a Silicon Graphics Indy station loaded with the IRIX 6.4 operating system. As far as the class design is concerned, the first thing required is a class to act as a template for the data structure returned by the legacy function. This class, JLegacy, declares a series of public instance variables which correspond to the members of Legacy_Type and provides a parameterless constructor. This constructor is never called, not even by the native method which allocates the object for return to the remote method. Next, the remote interface declaration for the remote object must be defined. In order for JLegacyRO to implement getJLegacy, JLegacyRO must interface with the existing legacy code through a native method, getn. getn is declared in the JLegacyRO class but implemented in C, just like the legacy code. getn returns a JLegacy instance and is declared static since its implementation is the same for all instances of the JLegacyRO class.

Howard, Scott M.↗

NASA NTRS2000

Atmospheric Boundary Layer Wind Data During the Period January 1, 1998 Through January 31, 1999 at the Dallas-Fort Worth Airport: Quality Assessment - Volume 1

The quality of the Aircraft Vortex Spacing System (AVOSS) is critically dependent on representative wind profiles in the atmospheric boundary layer. These winds observed from a number of sensor systems around the Dallas-Fort Worth airport were combined into single vertical wind profiles by an algorithm developed and implemented by MIT Lincoln Laboratory. This process, called the AVOSS Winds Analysis System (AWAS), is used by AVOSS for wake corridor predictions. During times when AWAS solutions were available, the quality of the resultant wind profiles and variance was judged from a series of plots combining all sensor observations and AWAS profiles during the period 1200 to 0400 UTC daily. First, input data was evaluated for continuity and consistency from criteria established. Next, the degree of agreement among all wind sensor systems was noted and cases of disagreement identified. Finally, the resultant AWAS solution was compared to the quality-assessed input data. When profiles differed by a specified amount from valid sensor consensus winds, times and altitudes were flagged. Volume one documents the process and quality of input sensor data. Volume two documents the data processing/sorting process and provides the resultant flagged files.

Zak, J. Allen↗

NASA NTRS2003

Implementing an Automated Antenna Measurement System

We developed an automated measurement system using a PC running a LabView application, a Velmex BiSlide X-Y positioner, and a HP85l0C network analyzer. The system provides high positioning accuracy and requires no user supervision. After the user inputs the necessary parameters into the LabView application, LabView controls the motor positioning and performs the data acquisition. Current parameters and measured data are shown on the PC display in two 3-D graphs and updated after every data point is collected. The final output is a formatted data file for later processing.

Valerio, Matthew D.↗

NASA NTRS1976

LACIE performance predictor final operational capability program description, volume 3

The requirements and processing logic for the LACIE Error Model program (LEM) are described. This program is an integral part of the Large Area Crop Inventory Experiment (LACIE) system. LEM is that portion of the LPP (LACIE Performance Predictor) which simulates the sample segment classification, strata yield estimation, and production aggregation. LEM controls repetitive Monte Carlo trials based on input error distributions to obtain statistical estimates of the wheat area, yield, and production at different levels of aggregation. LEM interfaces with the rest of the LPP through a set of data files.

Source record↗

NASA NTRS1977

A procedure for merging land cover/use data from Landsat, aerial photography, and map sources - Compatibility, accuracy and cost

A method is developed to merge land cover/use data from Landsat, aerial photography and map sources into a grid-based geographic information system. The method basically involves computer-assisted categorization of Landsat data to provide certain user-specified land cover categories; manual interpretation of aerial photography to identify other selected land cover/use categories that cannot be obtained from Landsat data; identification of special features from aerial photography or map sources; merging of the interpreted data from all the sources into a computer compatible file under a standardized coding structure; and the production of land cover/use maps, thematic maps, and tabular data. The specific tasks accomplished in producing the merged land cover/use data file and subsequent output products are identified and discussed. It is shown that effective implementation of the merging method is critically dependent on selecting the 'best' data source for each user-specified category in terms of accuracy and time/cost tradeoffs.

Enslin, W. R.↗

NASA NTRS1988

Orbiter Flying Qualities (OFQ) Workstation user's guide

This project was devoted to the development of a software package, called the Orbiter Flying Qualities (OFQ) Workstation, for working with the OFQ Archives which are specially selected sets of space shuttle entry flight data relevant to flight control and flying qualities. The basic approach to creation of the workstation software was to federate and extend commercial software products to create a low cost package that operates on personal computers. Provision was made to link the workstation to large computers, but the OFQ Archive files were also converted to personal computer diskettes and can be stored on workstation hard disk drives. The primary element of the workstation developed in the project is the Interactive Data Handler (IDH) which allows the user to select data subsets from the archives and pass them to specialized analysis programs. The IDH was developed as an application in a relational database management system product. The specialized analysis programs linked to the workstation include a spreadsheet program, FREDA for spectral analysis, MFP for frequency domain system identification, and NIPIP for pilot-vehicle system parameter identification. The workstation also includes capability for ensemble analysis over groups of missions.

Myers, Thomas T.↗

NASA NTRS1993

Rotary engine performance computer program (RCEMAP and RCEMAPPC): User's guide

This report is a user's guide for a computer code that simulates the performance of several rotary combustion engine configurations. It is intended to assist prospective users in getting started with RCEMAP and/or RCEMAPPC. RCEMAP (Rotary Combustion Engine performance MAP generating code) is the mainframe version, while RCEMAPPC is a simplified subset designed for the personal computer, or PC, environment. Both versions are based on an open, zero-dimensional combustion system model for the prediction of instantaneous pressures, temperature, chemical composition and other in-chamber thermodynamic properties. Both versions predict overall engine performance and thermal characteristics, including bmep, bsfc, exhaust gas temperature, average material temperatures, and turbocharger operating conditions. Required inputs include engine geometry, materials, constants for use in the combustion heat release model, and turbomachinery maps. Illustrative examples and sample input files for both versions are included.

Bartrand, Timothy A.↗

NASA NTRS1996

A General-Purpose Optimization Engine for Multi-Disciplinary Design Applications

A general purpose optimization tool for multidisciplinary applications, which in the literature is known as COMETBOARDS, is being developed at NASA Lewis Research Center. The modular organization of COMETBOARDS includes several analyzers and state-of-the-art optimization algorithms along with their cascading strategy. The code structure allows quick integration of new analyzers and optimizers. The COMETBOARDS code reads input information from a number of data files, formulates a design as a set of multidisciplinary nonlinear programming problems, and then solves the resulting problems. COMETBOARDS can be used to solve a large problem which can be defined through multiple disciplines, each of which can be further broken down into several subproblems. Alternatively, a small portion of a large problem can be optimized in an effort to improve an existing system. Some of the other unique features of COMETBOARDS include design variable formulation, constraint formulation, subproblem coupling strategy, global scaling technique, analysis approximation, use of either sequential or parallel computational modes, and so forth. The special features and unique strengths of COMETBOARDS assist convergence and reduce the amount of CPU time used to solve the difficult optimization problems of aerospace industries. COMETBOARDS has been successfully used to solve a number of problems, including structural design of space station components, design of nozzle components of an air-breathing engine, configuration design of subsonic and supersonic aircraft, mixed flow turbofan engines, wave rotor topped engines, and so forth. This paper introduces the COMETBOARDS design tool and its versatility, which is illustrated by citing examples from structures, aircraft design, and air-breathing propulsion engine design.

Patnaik, Surya N.↗

NASA NTRS2006

Functional Requirements Document for HALE UAS Operations in the NAS: Step 1. Version 3

The purpose of this Functional Requirements Document (FRD) is to compile the functional requirements needed to achieve the Access 5 Vision of "operating High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the national airspace system (NAS)" for Step 1. These functional requirements could support the development of a minimum set of policies, procedures and standards by the Federal Aviation Administration (FAA) and various standards organizations. It is envisioned that this comprehensive body of work will enable the FAA to establish and approve regulations to govern safe operation of UAS in the NAS on a routine or daily "file and fly" basis. The approach used to derive the functional requirements found within this FRD was to decompose the operational requirements and objectives identified within the Access 5 Concept of Operations (CONOPS) into the functions needed to routinely and safely operate a HALE UAS in the NAS. As a result, four major functional areas evolved to enable routine and safe UAS operations for an on-demand basis in the NAS. These four major functions are: Aviate, Navigate, Communicate, and Avoid Hazards. All of the functional requirements within this document can be directly traceable to one of these four major functions. Some functions, however, are traceable to several, or even all, of these four major functions. These cross-cutting functional requirements support the "Command / Control: function as well as the "Manage Contingencies" function. The requirements associated to these high-level functions and all of their supporting low-level functions are addressed in subsequent sections of this document.

Source record↗

NASA NTRS2011

Extensions to the Dynamic Aerospace Vehicle Exchange Markup Language

The Dynamic Aerospace Vehicle Exchange Markup Language (DAVE-ML) is a syntactical language for exchanging flight vehicle dynamic model data. It provides a framework for encoding entire flight vehicle dynamic model data packages for exchange and/or long-term archiving. Version 2.0.1 of DAVE-ML provides much of the functionality envisioned for exchanging aerospace vehicle data; however, it is limited in only supporting scalar time-independent data. Additional functionality is required to support vector and matrix data, abstracting sub-system models, detailing dynamics system models (both discrete and continuous), and defining a dynamic data format (such as time sequenced data) for validation of dynamics system models and vehicle simulation packages. Extensions to DAVE-ML have been proposed to manage data as vectors and n-dimensional matrices, and record dynamic data in a compatible form. These capabilities will improve the clarity of data being exchanged, simplify the naming of parameters, and permit static and dynamic data to be stored using a common syntax within a single file; thereby enhancing the framework provided by DAVE-ML for exchanging entire flight vehicle dynamic simulation models.

Brian, Geoffrey J.↗