Search NASA⌕ Search

SEARCH · Search NASA

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.

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

At least 325 records · Page 18
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

HEASARC Software Archive

(1) Chandra Archive: SAO has maintained the interfaces through which HEASARC gains access to the Chandra Data Archive. At HEASARC's request, we have implemented an anonymous ftp copy of a major part of the public archive and we keep that archive up-to- date. SAO has participated in the ADEC interoperability working group, establishing guidelines or interoperability standards and prototyping such interfaces. We have provided an NVO-based prototype interface, intending to serve the HEASARC-led NVO demo project. HEASARC's Astrobrowse interface was maintained and updated. In addition, we have participated in design discussions surrounding HEASARC's Caldb project. We have attended the HEASARC Users Group meeting and presented CDA status and developments. (2) Chandra CALDB: SA0 has maintained and expanded the Chandra CALDB by including four new data file types, defining the corresponding CALDB keyword/identification structures. We have provided CALDB upgrades for the public (CIAO) and for Standard Data Processing. Approximately 40 new files have been added to the CALDB in these version releases. There have been in the past year ten of these CALDB upgrades, each with unique index configurations. In addition, with the inputs from software, archive, and calibration scientists, as well as CIAO/SDP software developers, we have defined a generalized expansion of the existing CALDB interface and indexing structure. The purpose of this is to make the CALDB more generally applicable and useful in new and future missions that will be supported archivally by HEASARC. The generalized interface will identify additional configurational keywords and permit more extensive calibration parameter and boundary condition specifications for unique file selection. HEASARC scientists and developers from SAO and GSFC have become involved in this work, which is expected to produce a new interface for general use within the current year. (3) DS9: One of the decisions that came from last year's HEADCC meeting was to make the ds9 image display program the primary vehicle for displaying line graphics (as well as images). The first step required to make this possible was to enhance the line graphics capabilities of ds9. SAO therefore spent considerable effort upgrading ds9 to use Tcl 8.4 so that the BLT line graphics package could be built and imported into ds9 from source code, rather than from a pre-built (and generally outdated) shared library. This task, which is nearly complete, allows us to extend BLT as needed for the HEAD community. Following HEADCC discussion concerning archiving and the display of archived data, we extended ds9 to support full access to many astronomical Web-based archives sites, including HEASARC, MAST, CHANDRA, SKYVIEW, ADS, NED, SIMBAD, IRAS, NVRO, SAO TDC, and FIRST. Using ds9's new internal Web access capabilities, these archives can be accessed via their Web page. FITS images, plots, spectra, and journal abstracts can be referenced, down-loaded, and displayed directly and easily in ds9. For more information, see: http://hea-www.harvard.edu/saord/ds9. Also after the HEADCC discussion concerning region filtering, we extended the Funtools sample implementation of region filtering as described in: http://hea-www.harvard.edu/saord/funtools/regions.html. In particular, we added several new composite regions for event and image filtering, including elliptical and box annuli. We also extended the panda (Pie AND Annulus) region support to include box pandas and elliptical pandas. These new composite regions are especially useful in programs that need to count photons in each separate region using only a single pass through the data. Support for these new regions was added to ds9. In the same vein, we developed new region support for filtering images using simple FITS image masks, i.e. 8-bit or 16-bit FITS images where the value of a pixel is the region id number for that pixel. Other important enhancements to DS9 this year, include supporor multiple world coordinate systems, three dimensional event file binning, image smoothing, region groups and tags, the ability to save images in a number of image formats (such as JPEG, TIFF, PNG, FITS), improvements in support for integrating external analysis tools, and support for the virtual observatory. In particular, a full-featured web browser has been implemented within D S 9 . This provides support for full access to HEASARC archive sites such as SKYVIEW and W3BROWSE, in addition to other astronomical archives sites such as MAST, CHANDRA, ADS, NED, SIMBAD, IRAS, NVRO, SA0 TDC, and FIRST. From within DS9, the archives can be searched, and FITS images, plots, spectra, and journal abstracts can be referenced, downloaded and displayed The web browser provides the basis for the built-in help facility. All DS9 documentation, including the reference manual, FAQ, Know Features, and contact information is now available to the user without the need for external display applications. New versions of DS9 maybe downloaded and installed using this facility. Two important features used in the analysis of high energy astronomical data have been implemented in the past year. The first is support for binning photon event data in three dimensions. By binning the third dimension in time or energy, users are easily able to detect variable x-ray sources and identify other physical properties of their data. Second, a number of fast smoothing algorithms have been implemented in DS9, which allow users to smooth their data in real time. Algorithms for boxcar, tophat, and gaussian smoothing are supported.

White, Nicholas↗
NASA NTRS1978

Associative programming language and virtual associative access manager

APL provides convenient associative data manipulation functions in a high level language. Six statements were added to PL/1 via a preprocessor: CREATE, INSERT, FIND, FOR EACH, REMOVE, and DELETE. They allow complete control of all data base operations. During execution, data base management programs perform the functions required to support the APL language. VAAM is the data base management system designed to support the APL language. APL/VAAM is used by CADANCE, an interactive graphic computer system. VAAM is designed to support heavily referenced files. Virtual memory files, which utilize the paging mechanism of the operating system, are used. VAAM supports a full network data structure. The two basic blocks in a VAAM file are entities and sets. Entities are the basic information element and correspond to PL/1 based structures defined by the user. Sets contain the relationship information and are implemented as arrays.

Carol Price↗
NASA NTRS1982

Feature Identification and Location Experiment

The Feature Identification and Location Experiment (FILE), which was flown on the second Space Shuttle flight to test a technique for real-time, autonomous classification of water, vegetation and bare land as well as clouds, snow and ice, senses earth radiation in spectral bands centered at 0.65 and 0.85 microns. The radiance ratio classification algorithm has successfully made automatic data selection decisions. A classification image obtained on the mission is providing data needed to evaluate the FILE algorithm and overall system performance.

Sivertson, W. E., Jr.↗
NASA NTRS1991

Radar simulation program upgrade and algorithm development

The NASA Radar Simulation Program is a comprehensive calculation of the expected output of an airborne coherent pulse Doppler radar system viewing a low level microburst along or near the approach path. Inputs to the program include the radar system parameters and data files that contain the characteristics of the microbursts to be simulated, the ground clutter map, and the discrete target data base which provides a simulation of the moving ground clutter. For each range bin, the simulation calculates the received signal amplitude level by integrating the product of the antenna gain pattern and the scattering source amplitude and phase of a spherical shell volume segment defined by the pulse width, radar range, and ground plane intersection. A series of in-phase and quadrature pulses are generated and stored for further processing if desired. In addition, various signal processing techniques are used to derive the simulated velocity and hazard measurements, and store them for use in plotting and display programs.

Britt, Charles L.↗
NASA NTRS2004

Development of an Optical-Real Time Polarimetric Imaging System for Aerospace Applications

The design of an optical polarimetric imaging system, aimed to detect cracks or structural defects on the surface of rotating aircraft engine shafts, is presented. The experimental results have been processed by a real time wavelet denouncing system implemented by a Filed Programmable Gate Arrays (FPGA), which has been designed for this purpose. The experimental results clearly indicate that high signal-to-noise ratio signals can be obtained.

Giakos, George C.↗
NASA NTRS2007

Development of a Prototype Automation Simulation Scenario Generator for Air Traffic Management Software Simulations

A technique for automated development of scenarios for use in the Multi-Center Traffic Management Advisor (McTMA) software simulations is described. The resulting software is designed and implemented to automate the generation of simulation scenarios with the intent of reducing the time it currently takes using an observational approach. The software program is effective in achieving this goal. The scenarios created for use in the McTMA simulations are based on data taken from data files from the McTMA system, and were manually edited before incorporation into the simulations to ensure accuracy. Despite the software s overall favorable performance, several key software issues are identified. Proposed solutions to these issues are discussed. Future enhancements to the scenario generator software may address the limitations identified in this paper.

Khambatta, Cyrus F.↗
NASA NTRS2007

Definition and maintenance of a telemetry database dictionary

A telemetry dictionary database includes a component for receiving spreadsheet workbooks of telemetry data over a web-based interface from other computer devices. Another component routes the spreadsheet workbooks to a specified directory on the host processing device. A process then checks the received spreadsheet workbooks for errors, and if no errors are detected the spreadsheet workbooks are routed to another directory to await initiation of a remote database loading process. The loading process first converts the spreadsheet workbooks to comma separated value (CSV) files. Next, a network connection with the computer system that hosts the telemetry dictionary database is established and the CSV files are ported to the computer system that hosts the telemetry dictionary database. This is followed by a remote initiation of a database loading program. Upon completion of loading a flatfile generation program is manually initiated to generate a flatfile to be used in a mission operations environment by the core ground system.

Knopf, William P.↗
NASA NTRS2008

Effect of Surface Traffic Count on Taxi Time at Dallas-Fort Worth (DFW) International Airport

As the amount of air traffic increases over the years, most airports simply do not have the means of expanding to handle the intensified traffic on the surface that will ensue. Precise surveillance equipment and automation concepts, as well as advanced surface traffic algorithms are being developed to improve airport efficiency. These surface algorithms require inputs unique to each airport to ensure maximum efficiency, and minimal taxi delay. This study analyzes surface traffic at Dallas-Fort Worth International Airport (DFW) to determine the effect of the number of aircraft on the surface and the amount of stop and go situations they experience to the amount of additional taxi time encountered. If the surface capacity of an airport is known, minimal delay can be accomplished by limiting the number of taxiing aircraft to that capacity. This concept is related to highways, where traffic flow drastically decreases as more cars occupy the road. An attempt to minimize this effect on highways is seen with the use of metering lights at freeway on-ramps. Since the surface traffic at airports is highly regulated, and aircraft are less mobile on the ground, limiting the surface count to a certain number can greatly reduce the amount of additional taxi time encountered, as well as reduce hazardous emissions. This study will also find the regions of an airport that encounter the most additional taxi time when the number of aircraft in that area is increased. This could help surface traffic algorithms avoid congesting that area, or re-route aircraft to different runways when that area reaches its capacity. The relationship between the amount of stop and go situations an aircraft encounters and their effect on the taxi time of that aircraft will also be investigated. This will help to determine the effect of holding an aircraft on the taxiway as opposed to re-routing it. The lesser of the two should be used when developing surface traffic algorithms to further minimize the delay encountered. The fields investigated in this study include taxi time, the number of aircraft on the surface, the number of stop and go situations, and the time stopped for each aircraft. Taxi time is defined as spot to runway for departures, and runway to spot for arrivals. It does not include ramp area taxi time because the ramp area is controlled differently, and surface traffic schedulers do not currently incorporate them. Taxi time is found by finding the difference between take-off time (OFF) and spot crossing time for departures, and spot crossing time and landing time (ON) for arrivals. All surface data was either found directly using the Surface Operations Data Analysis and Adaptation (SODAA), a tool to analyze the Surface Management System (SMS) generated log files, or indirectly from SODAA using Matlab to derive values from SODAA data. The number of aircraft on the surface is found by looping through the ON times, OFF times, and spot times for each aircraft during a particular day. For each departure aircraft, surface counts are taken at its spot crossing and OFF time. The average of these two is used as the surface count for that aircraft. For arrivals, surface counts are taken at its ON time and its spot crossing time. The average of these two is used.

Kistler, Matthew Stephen↗
NASA NTRS2009

Planetary Geologic Mapping Handbook - 2009

Geologic maps present, in an historical context, fundamental syntheses of interpretations of the materials, landforms, structures, and processes that characterize planetary surfaces and shallow subsurfaces (e.g., Varnes, 1974). Such maps also provide a contextual framework for summarizing and evaluating thematic research for a given region or body. In planetary exploration, for example, geologic maps are used for specialized investigations such as targeting regions of interest for data collection and for characterizing sites for landed missions. Whereas most modern terrestrial geologic maps are constructed from regional views provided by remote sensing data and supplemented in detail by field-based observations and measurements, planetary maps have been largely based on analyses of orbital photography. For planetary bodies in particular, geologic maps commonly represent a snapshot of a surface, because they are based on available information at a time when new data are still being acquired. Thus the field of planetary geologic mapping has been evolving rapidly to embrace the use of new data and modern technology and to accommodate the growing needs of planetary exploration. Planetary geologic maps have been published by the U.S. Geological Survey (USGS) since 1962 (Hackman, 1962). Over this time, numerous maps of several planetary bodies have been prepared at a variety of scales and projections using the best available image and topographic bases. Early geologic map bases commonly consisted of hand-mosaicked photographs or airbrushed shaded-relief views and geologic linework was manually drafted using mylar bases and ink drafting pens. Map publishing required a tedious process of scribing, color peel-coat preparation, typesetting, and photo-laboratory work. Beginning in the 1990s, inexpensive computing, display capability and user-friendly illustration software allowed maps to be drawn using digital tools rather than pen and ink, and mylar bases became obsolete. Terrestrial geologic maps published by the USGS now are primarily digital products using geographic information system (GIS) software and file formats. GIS mapping tools permit easy spatial comparison, generation, importation, manipulation, and analysis of multiple raster image, gridded, and vector data sets. GIS software has also permitted the development of project-specific tools and the sharing of geospatial products among researchers. GIS approaches are now being used in planetary geologic mapping as well (e.g., Hare and others, 2009). Guidelines or handbooks on techniques in planetary geologic mapping have been developed periodically (e.g., Wilhelms, 1972, 1990; Tanaka and others, 1994). As records of the heritage of mapping methods and data, these remain extremely useful guides. However, many of the fundamental aspects of earlier mapping handbooks have evolved significantly, and a comprehensive review of currently accepted mapping methodologies is now warranted. As documented in this handbook, such a review incorporates additional guidelines developed in recent years for planetary geologic mapping by the NASA Planetary Geology and Geophysics (PGG) Program s Planetary Cartography and Geologic Mapping Working Group s (PCGMWG) Geologic Mapping Subcommittee (GEMS) on the selection and use of map bases as well as map preparation, review, publication, and distribution. In light of the current boom in planetary exploration and the ongoing rapid evolution of available data for planetary mapping, this handbook is especially timely.

Tanaka, K. L.↗
NASA NTRS2010

Planetary Geologic Mapping Handbook - 2010

Geologic maps present, in an historical context, fundamental syntheses of interpretations of the materials, landforms, structures, and processes that characterize planetary surfaces and shallow subsurfaces. Such maps also provide a contextual framework for summarizing and evaluating thematic research for a given region or body. In planetary exploration, for example, geologic maps are used for specialized investigations such as targeting regions of interest for data collection and for characterizing sites for landed missions. Whereas most modern terrestrial geologic maps are constructed from regional views provided by remote sensing data and supplemented in detail by field-based observations and measurements, planetary maps have been largely based on analyses of orbital photography. For planetary bodies in particular, geologic maps commonly represent a snapshot of a surface, because they are based on available information at a time when new data are still being acquired. Thus the field of planetary geologic mapping has been evolving rapidly to embrace the use of new data and modern technology and to accommodate the growing needs of planetary exploration. Planetary geologic maps have been published by the U.S. Geological Survey (USGS) since 1962. Over this time, numerous maps of several planetary bodies have been prepared at a variety of scales and projections using the best available image and topographic bases. Early geologic map bases commonly consisted of hand-mosaicked photographs or airbrushed shaded-relief views and geologic linework was manually drafted using mylar bases and ink drafting pens. Map publishing required a tedious process of scribing, color peel-coat preparation, typesetting, and photo-laboratory work. Beginning in the 1990s, inexpensive computing, display capability and user-friendly illustration software allowed maps to be drawn using digital tools rather than pen and ink, and mylar bases became obsolete. Terrestrial geologic maps published by the USGS now are primarily digital products using geographic information system (GIS) software and file formats. GIS mapping tools permit easy spatial comparison, generation, importation, manipulation, and analysis of multiple raster image, gridded, and vector data sets. GIS software has also permitted the development of projectspecific tools and the sharing of geospatial products among researchers. GIS approaches are now being used in planetary geologic mapping as well. Guidelines or handbooks on techniques in planetary geologic mapping have been developed periodically. As records of the heritage of mapping methods and data, these remain extremely useful guides. However, many of the fundamental aspects of earlier mapping handbooks have evolved significantly, and a comprehensive review of currently accepted mapping methodologies is now warranted. As documented in this handbook, such a review incorporates additional guidelines developed in recent years for planetary geologic mapping by the NASA Planetary Geology and Geophysics (PGG) Program's Planetary Cartography and Geologic Mapping Working Group's (PCGMWG) Geologic Mapping Subcommittee (GEMS) on the selection and use of map bases as well as map preparation, review, publication, and distribution. In light of the current boom in planetary exploration and the ongoing rapid evolution of available data for planetary mapping, this handbook is especially timely.

Tanaka, K. L.↗
NASA NTRS2005

Applying Standard Interfaces to a Process-Control Language

A method of applying open-operating-system standard interfaces to the NASA User Interface Language (UIL) has been devised. UIL is a computing language that can be used in monitoring and controlling automated processes: for example, the Timeliner computer program, written in UIL, is a general-purpose software system for monitoring and controlling sequences of automated tasks in a target system. In providing the major elements of connectivity between UIL and the target system, the present method offers advantages over the prior method. Most notably, unlike in the prior method, the software description of the target system can be made independent of the applicable compiler software and need not be linked to the applicable executable compiler image. Also unlike in the prior method, it is not necessary to recompile the source code and relink the source code to a new executable compiler image. Abstraction of the description of the target system to a data file can be defined easily, with intuitive syntax, and knowledge of the source-code language is not needed for the definition.

Berthold, Richard T.↗
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRS1995

COMET Progresses Toward First Mission

The COMmercial Experiment Transporter (COMET) is a set of hardware and related infrastructure used to support orbital experiments of the CDD's and their industrial partners. During this year major support contracts were signed, preliminary design reviews conducted, experiments selected for the first mission, and long lead items place on order. The Program Office and CCDS Monitors took an active role in guiding COMET through the activation maze. Launch and recovery sites were selected and licenses for the launch vehicle, recovery system, and recovery operations were filed by the contractors with the Department of Transportation. As the period closed, COMET was preparing for Critical Design Reviews on all major systems and a target launch data was selected. This report deals primarily with the programmatic issues which were resolved as the program matured. At times is is impossible to disassociate the technical from the programmatic and, in such cases the technical material is presented to provide insight into the paths selected by both CCDS and Contractor Management.

Pawlick, J.↗
NASA NTRS2014

Data Albums: An Event Driven Search, Aggregation and Curation Tool for Earth Science

One of the largest continuing challenges in any Earth science investigation is the discovery and access of useful science content from the increasingly large volumes of Earth science data and related information available. Approaches used in Earth science research such as case study analysis and climatology studies involve gathering discovering and gathering diverse data sets and information to support the research goals. Research based on case studies involves a detailed description of specific weather events using data from different sources, to characterize physical processes in play for a specific event. Climatology-based research tends to focus on the representativeness of a given event, by studying the characteristics and distribution of a large number of events. This allows researchers to generalize characteristics such as spatio-temporal distribution, intensity, annual cycle, duration, etc. To gather relevant data and information for case studies and climatology analysis is both tedious and time consuming. Current Earth science data systems are designed with the assumption that researchers access data primarily by instrument or geophysical parameter. Those who know exactly the datasets of interest can obtain the specific files they need using these systems. However, in cases where researchers are interested in studying a significant event, they have to manually assemble a variety of datasets relevant to it by searching the different distributed data systems. In these cases, a search process needs to be organized around the event rather than observing instruments. In addition, the existing data systems assume users have sufficient knowledge regarding the domain vocabulary to be able to effectively utilize their catalogs. These systems do not support new or interdisciplinary researchers who may be unfamiliar with the domain terminology. This paper presents a specialized search, aggregation and curation tool for Earth science to address these existing challenges. The search tool automatically creates curated "Data Albums", aggregated collections of information related to a specific science topic or event, containing links to relevant data files (granules) from different instruments; tools and services for visualization and analysis; and information about the event contained in news reports, images or videos to supplement research analysis. Curation in the tool is driven via an ontology based relevancy ranking algorithm to filter out non-relevant information and data.

Ramachandran, Rahul↗
NASA NTRS1992

Khoros software specification format and interoperability

Khoros defines formats for User Interface Specification (UIS) and Program Specification (PS) files. From such files, its code generator, Ghostwriter, creates source files and documentation. The great advantage of the system is that the code fragments that make up part of the PS file are purely generic. All Khoros-related code is created by the code generator; this includes all user interface code. As a matter of fact, both specification files are very generic in nature. Thus, one could imagine using it as the basis for other software systems. A case is made that writing a code generator that would create IRAF-compatible code from the Khoros UIS and PS files is fairly trivial. Another aspect of the Khoros system conventions concerns the way execution commands are generated by the user interface and the actual syntax of those commands. The protocols are such that interoperability at the level of executable modules is readily possible.

Rots, A. H.↗
NASA NTRS1999

The Evolution of Dust in the Multiphase ISM: Grain Destruction Processes

This proposal covered year one of a long term project in which we acquired the necessary hardware and softwaxe needed to calculate grain destruction processes in the interstellar medium (ISM). The long term goal of this research is to develop a model for the dust evolution in the ISM capable of explaining observations of elemental depletions, the grain size distribution, and the emission characteristics of the ISM from the X-ray through the FIR. We purchased a SUN Ultra 10 workstation and peripheral devices including an Exabyte Tape drive, HP Laser Printer, and Seagate External Hard Disk. The PI installed the hardware and Solaris operating system on the workstation and integrated the hardware into the network. Software was also purchased to enable connections to the workstation from a PC (Hummingbird Exceed). Additional freeware required to carry out the proposed program was installed on the system including compilers (g77, gcc, g++), editors (emacs), a markup language (LaTeX), and display programs (WIP, XV, SAOtng). We have also successfully modified the required plot files to work with our system which display the results of grain processing.

Wolfire, Mark↗