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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS1988

Permanent-File-Validation Utility Computer Program

Errors in files detected and corrected during operation. Permanent File Validation (PFVAL) utility computer program provides CDC CYBER NOS sites with mechanism to verify integrity of permanent file base. Locates and identifies permanent file errors in Mass Storage Table (MST) and Track Reservation Table (TRT), in permanent file catalog entries (PFC's) in permit sectors, and in disk sector linkage. All detected errors written to listing file and system and job day files. Program operates by reading system tables , catalog track, permit sectors, and disk linkage bytes to vaidate expected and actual file linkages. Used extensively to identify and locate errors in permanent files and enable online correction, reducing computer-system downtime.

Derry, Stephen D.↗
NASA NTRS1998

Long-Term file activity patterns in a UNIX workstation environment

As mass storage technology becomes more affordable for sites smaller than supercomputer centers, understanding their file access patterns becomes crucial for developing systems to store rarely used data on tertiary storage devices such as tapes and optical disks. This paper presents a new way to collect and analyze file system statistics for UNIX-based file systems. The collection system runs in user-space and requires no modification of the operating system kernel. The statistics package provides details about file system operations at the file level: creations, deletions, modifications, etc. The paper analyzes four months of file system activity on a university file system. The results confirm previously published results gathered from supercomputer file systems, but differ in several important areas. Files in this study were considerably smaller than those at supercomputer centers, and they were accessed less frequently. Additionally, the long-term creation rate on workstation file systems is sufficiently low so that all data more than a day old could be cheaply saved on a mass storage device, allowing the integration of time travel into every file system.

Gibson, Timothy J.↗
NASA NTRS2000

Infrastructure for Training and Partnershipes: California Water and Coastal Ocean Resources

The purpose of this project was to advance the existing ICESS/Bren School computing infrastructure to allow scientists, students, and research trainees the opportunity to interact with environmental data and simulations in near-real time. Improvements made with the funding from this project have helped to strengthen the research efforts within both units, fostered graduate research training, and helped fortify partnerships with government and industry. With this funding, we were able to expand our computational environment in which computer resources, software, and data sets are shared by ICESS/Bren School faculty researchers in all areas of Earth system science. All of the graduate and undergraduate students associated with the Donald Bren School of Environmental Science and Management and the Institute for Computational Earth System Science have benefited from the infrastructure upgrades accomplished by this project. Additionally, the upgrades fostered a significant number of research projects (attached is a list of the projects that benefited from the upgrades). As originally proposed, funding for this project provided the following infrastructure upgrades: 1) a modem file management system capable of interoperating UNIX and NT file systems that can scale to 6.7 TB, 2) a Qualstar 40-slot tape library with two AIT tape drives and Legato Networker backup/archive software, 3) previously unavailable import/export capability for data sets on Zip, Jaz, DAT, 8mm, CD, and DLT media in addition to a 622Mb/s Internet 2 connection, 4) network switches capable of 100 Mbps to 128 desktop workstations, 5) Portable Batch System (PBS) computational task scheduler, and vi) two Compaq/Digital Alpha XP1000 compute servers each with 1.5 GB of RAM along with an SGI Origin 2000 (purchased partially using funds from this project along with funding from various other sources) to be used for very large computations, as required for simulation of mesoscale meteorology or climate.

Siegel, David A.↗
NASA NTRS1984

A real-time, portable, microcomputer-based jet engine simulator

Modern piloted flight simulators require detailed models of many aircraft components, such as the airframe, propulsion system, flight deck controls and instrumentation, as well as motion drive and visual display systems. The amount of computing power necessary to implement these systems can exceed that offered by dedicated mainframe computers. One approach to this problem is through the use of distributed computing, where parts of the simulation are assigned to computing subsystems, such as microcomputers. One such subsystem, such as microcomputers. One such subsystem, a real-time, portable, microcomputer-based jet engine simulator, is described in this paper. The simulator will be used at the NASA Ames Vertical Motion Simulator facility to perform calculations previously done on the facility's mainframe computer. The mainframe will continue to do all other system calculations and will interface to the engine simulator through analog I/0. The engine simulator hardware includes a 16-bit microcomputer and floating-point coprocessor. There is an 8 channel analog input board and an 8 channel analog output board. A model of a small turboshaft engine/control is coded in floating-point FORTRAN. The FORTRAN code and a data monitoring program run under the control of an assembly language real-time executive. The monitoring program allows the user to isplay and/or modify simulator variables on-line through a data terminal. A dual disk drive system is used for mass storage of programs and data. The CP/M-86 operating system provides file management and overall system control. The frame time for the simulator is 30 milliseconds, which includes all analog I/0 operations.

Blech, R. A.↗
NASA NTRS1986

A design for a new catalog manager and associated file management for the Land Analysis System (LAS)

Due to the larger number of different types of files used in an image processing system, a mechanism for file management beyond the bounds of typical operating systems is necessary. The Transportable Applications Executive (TAE) Catalog Manager was written to meet this need. Land Analysis System (LAS) users at the EROS Data Center (EDC) encountered some problems in using the TAE catalog manager, including catalog corruption, networking difficulties, and lack of a reliable tape storage and retrieval capability. These problems, coupled with the complexity of the TAE catalog manager, led to the decision to design a new file management system for LAS, tailored to the needs of the EDC user community. This design effort, which addressed catalog management, label services, associated data management, and enhancements to LAS applications, is described. The new file management design will provide many benefits including improved system integration, increased flexibility, enhanced reliability, enhanced portability, improved performance, and improved maintainability.

Greenhagen, Cheryl↗
NASA NTRS1996

The medium is NOT the message or Indefinitely long-term file storage at Leeds University

Approximately 3 years ago we implemented an archive file storage system which embodies experiences gained over more than 25 years of using and writing file storage systems. It is the third in-house system that we have written, and all three systems have been adopted by other institutions. This paper discusses the requirements for long-term data storage in a university environment, and describes how our present system is designed to meet these requirements indefinitely. Particular emphasis is laid on experiences from past systems, and their influence on current system design. We also look at the influence of the IEEE-MSS standard. We currently have the system operating in five UK universities. The system operates in a multi-server environment, and is currently operational with UNIX (SunOS4, Solaris2, SGI-IRIX, HP-UX), NetWare3 and NetWare4. PCs logged on to NetWare can also archive and recover files that live on their hard disks.

Holdsworth, David↗
NASA NTRSDate not supplied

Coupled Reactor and Engine Nuclear Thermal Propulsion Modeling Methodology

The design and development process of a Nuclear Thermal Propulsion (NTP) system requires extensive multiphysics modeling to couple the neutron physics and thermal feedback effects to determine the reactor’s power shape. Propulsion system performance codes utilize this power shape to determine NTP key performance parameters. While the power shape is heavily dependent on the temperature profile and geometry of the reactor, many analyses either assume a constant power shape, or use neutronics analysis to determine a power shape for a specific reactor configuration. The development of a coupling interface for a propulsion system performance code and a Monte Carlo neutron transport code (OpenMC) allows for the reactor power shape to be calculated in an iteration loop. The interface utilizes a file share system to transfer geometry dimensions, temperatures, and material identifiers to OpenMC, which is used to perform a neutron transport simulation of a design like the government Testing Reference Design reactor. The interface is then able to post-process the results from OpenMC and use the same file share system to share a power shape and other important neutron transport parameters to the system performance code. Initial results show that neglecting the changes to power shape when comparing reactor configurations can yield inaccurate results. Furthermore, utilizing propellants other than hydrogen gas can cause significant changes to the power shape, and thus, the thermal performance of a specific reactor design. This methodology is being expanded to allow for multiple families of NTP reactors to be analyzed, including block moderator, particle bed, and NERVA-derived reactors.

multiphysics coupling↗
NASA NTRSDate not supplied

Coupled Reactor and Engine Nuclear Thermal Propulsion Modeling Methodology

The design and development process of a Nuclear Thermal Propulsion (NTP) system requires extensive multiphysics modeling to couple the neutron physics and thermal feedback effects to determine the reactor’s power shape. Propulsion system performance codes utilize this power shape to determine NTP key performance parameters. While the power shape is heavily dependent on the temperature profile and geometry of the reactor, many analyses either assume a constant power shape, or use neutronics analysis to determine a power shape for a specific reactor configuration. The development of a coupling interface for a propulsion system performance code and a Monte Carlo neutron transport code (OpenMC) allows for the reactor power shape to be calculated in an iteration loop. The interface utilizes a file share system to transfer geometry dimensions, temperatures, and material identifiers to OpenMC, which is used to perform a neutron transport simulation of a design like the government Testing Reference Design reactor. The interface is then able to post-process the results from OpenMC and use the same file share system to share a power shape and other important neutron transport parameters to the system performance code. Initial results show that neglecting the changes to power shape when comparing reactor configurations can yield inaccurate results. Furthermore, utilizing propellants other than hydrogen gas can cause significant changes to the power shape, and thus, the thermal performance of a specific reactor design. This methodology is being expanded to allow for multiple families of NTP reactors to be analyzed, including block moderator, particle bed, and NERVA-derived reactors.

multiphysics coupling↗
NASA NTRS2020

What Can We Learn from One Billion Ground System Log Messages?

Shortage of log-based data in a ground system they have traditionally been the under achievers in a satellite ground system. This is due to several factors: Once log messages scroll out of view on the TTC event console window they are soon forgotten. Application and system log files are scattered across directories within a system, across a multitude of servers, and across one or more databases making access cumbersome. Typical tools to perform log file content searching are generally crude and typically only employed as part of trouble-shooting exercises.As we move towards satellite constellations and fleets and add even more status information, the number of messages keeps growing. One mission now estimates that they could generate 3,000,000 messages per day 1 billion per year - for the life of their mission. What to do with those 1 billion messages? That is the challenge. With the recent technological advances in the management of large data sets, text-based processing, and data analytics, there are now capabilities that we can provide to the ground system engineers and satellite operators to address what we postulate are missed opportunities. Advanced real-time log analysis can allow us to be less reactionary in favor of being more proactive. Analytics goals include the ability to: Identify root cause of unexpected events, failures or error conditions enabled by correlating disparate data. Detect security breaches attempts before they are successful. Help admins ensure IT resources continue running optimally. Identify trends and patterns that may indicate impending failures or error conditions for valuable assets before they happen. Compare satellites in a fleet or constellation in terms of number of alarms, number of command sent to them, etc.. Answer questions like "Are the operations support needs increasing over the past year?" or "Have we seen this combination of alarm conditions before?" But really, once the tools are readily available the users will start realizing what can be done with their new powers. In this presentation we will show the results of analyzing millions of actual mission operations log messages, how the results can be displayed to the user, and how new products now available as open source can be applied to the challenges of large scale time-tagged text-based mission operations messages. Flight operations team members believe that this is a powerful new option for how they assess overall system and space asset health. Technical descriptions of the design, tools, and storage will be provided. One billion messages? Bring'em on!

Orsborne, Sharon↗
NASA NTRS1985

Planetary image conversion task

The Planetary Image Conversion Task group processed 12,500 magnetic tapes containing raw imaging data from JPL planetary missions and produced an image data base in consistent format on 1200 fully packed 6250-bpi tapes. The output tapes will remain at JPL. A copy of the entire tape set was delivered to US Geological Survey, Flagstaff, Ariz. A secondary task converted computer datalogs, which had been stored in project specific MARK IV File Management System data types and structures, to flat-file, text format that is processable on any modern computer system. The conversion processing took place at JPL's Image Processing Laboratory on an IBM 370-158 with existing software modified slightly to meet the needs of the conversion task. More than 99% of the original digital image data was successfully recovered by the conversion task. However, processing data tapes recorded before 1975 was destructive. This discovery is of critical importance to facilities responsible for maintaining digital archives since normal periodic random sampling techniques would be unlikely to detect this phenomenon, and entire data sets could be wiped out in the act of generating seemingly positive sampling results. Reccomended follow-on activities are also included.

Martin, M. D.↗
NASA NTRS1984

Asynchronous file transfer to IBM PC's

The Asynchronous File Transfer System is used for interactively selecting and tramsmitting text files from the Langley Research Center's Business Data Systems Division (BDSD) host processor to an IBM Personal Computer. The IBM asynchronous communications support package is used for handling the communications on the personal computer. An application program (NATURAL, COBOL, etc.) is used for selecting and formatting the records to be transmitted, and three subroutine modules residing on the BDSD host processor are used for interfacing the application program and the communications software. Each record transmitted to the Personal Computer must be in the standard ASCII format. This record format is directly accessible by BASIC and many of the personal computer software packages provide utility programs for converting them to the format required for the particular package in question.

Hoerger, J.↗
NASA NTRS1988

Archival-System Computer Program

Files stored with various degrees of relative performance. ARCHIVE system provides permanent storage area for files to which infrequent access is required. Routines designed to provide simple mechanism by which users store and retrieve files. User treats ARCHIVE as interface to "black box" where files are stored. There are five ARCHIVE user commands, though ARCHIVE employs standard VMS directives and VAX BACKUP utility program. Special care taken to provide security needed to insure integrity of files over period of years. ARCHIVE written in DEC VAX DCL.

Scott, Peter↗
NASA NTRS1983

User-programmer dialogue: Guidelines for designing menus and help files for interactive computer systems

This document is a set of guidelines to aid a programmer in making the various decisions necessary for a clear user-programmer dialogue. Its goal is to promote an effective and efficient transfer of information between programmer and user. These guidelines are divided into four sections: (1) Format, (2) Sequence, (3) Audience, and (4) Aim. Format, in terms of this study, means the spatial and structural presentation of information. Sequence deals with the procedural aspects of multiple panel displays. This section looks at the issues of timelines of presentation, modularization of information, and patterns of user behavior. Audience looks at the relationship among programmer, user, and message. It covers the issues of analyzing the audience's knowledge, attitudes, and needs, anticipating the audience's inferences, and identifying textual ambiguities. The programmer's aim or intention shows up in everything from tone to format. Aim considers the programmer's purpose.

Carlson, P. A.↗
NASA NTRS2007

Creating Interactive Graphical Overlays in the Advanced Weather Interactive Processing System Using Shapefiles and DGM Files

Graphical overlays can be created in real-time in the Advanced Weather Interactive Processing System (AWIPS) using shapefiles or Denver AWIPS Risk Reduction and Requirements Evaluation (DARE) Graphics Metafile (DGM) files. This presentation describes how to create graphical overlays on-the-fly for AWIPS, by using two examples of AWIPS applications that were created by the Applied Meteorology Unit (AMU) located at Cape Canaveral Air Force Station (CCAFS), Florida. The first example is the Anvil Threat Corridor Forecast Tool, which produces a shapefile that depicts a graphical threat corridor of the forecast movement of thunderstorm anvil clouds, based on the observed or forecast upper-level winds. This tool is used by the Spaceflight Meteorology Group (SMG) at Johnson Space Center, Texas and 45th Weather Squadron (45 WS) at CCAFS to analyze the threat of natural or space vehicle-triggered lightning over a location. The second example is a launch and landing trajectory tool that produces a DGM file that plots the ground track of space vehicles during launch or landing. The trajectory tool can be used by SMG and the 45 WS forecasters to analyze weather radar imagery along a launch or landing trajectory. The presentation will list the advantages and disadvantages of both file types for creating interactive graphical overlays in future AWIPS applications. Shapefiles are a popular format used extensively in Geographical Information Systems. They are usually used in AWIPS to depict static map backgrounds. A shapefile stores the geometry and attribute information of spatial features in a dataset (ESRI 1998). Shapefiles can contain point, line, and polygon features. Each shapefile contains a main file, index file, and a dBASE table. The main file contains a record for each spatial feature, which describes the feature with a list of its vertices. The index file contains the offset of each record from the beginning of the main file. The dBASE table contains records for each attribute. Attributes are commonly used to label spatial features. Shapefiles can be viewed, but not created in AWIPS. As a result, either third-party software can be installed on an AWIPS workstation, or new software must be written to create shapefiles in the correct format.

Barrett, Joe H., III↗
NASA NTRS2001

Registered File Support for Critical Operations Files at (Space Infrared Telescope Facility) SIRTF

The SIRTF Science Center's (SSC) Science Operations System (SOS) has to contend with nearly one hundred critical operations files via comprehensive file management services. The management is accomplished via the registered file system (otherwise known as TFS) which manages these files in a registered file repository composed of a virtual file system accessible via a TFS server and a file registration database. The TFS server provides controlled, reliable, and secure file transfer and storage by registering all file transactions and meta-data in the file registration database. An API is provided for application programs to communicate with TFS servers and the repository. A command line client implementing this API has been developed as a client tool. This paper describes the architecture, current implementation, but more importantly, the evolution of these services based on evolving community use cases and emerging information system technology.

file management services↗
NASA NTRS2015

Land Boundary Conditions for the Goddard Earth Observing System Model Version 5 (GEOS-5) Climate Modeling System: Recent Updates and Data File Descriptions

The Earths land surface boundary conditions in the Goddard Earth Observing System version 5 (GEOS-5) modeling system were updated using recent high spatial and temporal resolution global data products. The updates include: (i) construction of a global 10-arcsec land-ocean lakes-ice mask; (ii) incorporation of a 10-arcsec Globcover 2009 land cover dataset; (iii) implementation of Level 12 Pfafstetter hydrologic catchments; (iv) use of hybridized SRTM global topography data; (v) construction of the HWSDv1.21-STATSGO2 merged global 30 arc second soil mineral and carbon data in conjunction with a highly-refined soil classification system; (vi) production of diffuse visible and near-infrared 8-day MODIS albedo climatologies at 30-arcsec from the period 2001-2011; and (vii) production of the GEOLAND2 and MODIS merged 8-day LAI climatology at 30-arcsec for GEOS-5. The global data sets were preprocessed and used to construct global raster data files for the software (mkCatchParam) that computes parameters on catchment-tiles for various atmospheric grids. The updates also include a few bug fixes in mkCatchParam, as well as changes (improvements in algorithms, etc.) to mkCatchParam that allow it to produce tile-space parameters efficiently for high resolution AGCM grids. The update process also includes the construction of data files describing the vegetation type fractions, soil background albedo, nitrogen deposition and mean annual 2m air temperature to be used with the future Catchment CN model and the global stream channel network to be used with the future global runoff routing model. This report provides detailed descriptions of the data production process and data file format of each updated data set.

GEOS-5↗
NASA NTRS1996

A convertor and user interface to import CAD files into worldtoolkit virtual reality systems

Virtual Reality (VR) is a rapidly developing human-to-computer interface technology. VR can be considered as a three-dimensional computer-generated Virtual World (VW) which can sense particular aspects of a user's behavior, allow the user to manipulate the objects interactively, and render the VW at real-time accordingly. The user is totally immersed in the virtual world and feel the sense of transforming into that VW. NASA/MSFC Computer Application Virtual Environments (CAVE) has been developing the space-related VR applications since 1990. The VR systems in CAVE lab are based on VPL RB2 system which consists of a VPL RB2 control tower, an LX eyephone, an Isotrak polhemus sensor, two Fastrak polhemus sensors, a folk of Bird sensor, and two VPL DG2 DataGloves. A dynamics animator called Body Electric from VPL is used as the control system to interface with all the input/output devices and to provide the network communications as well as VR programming environment. The RB2 Swivel 3D is used as the modelling program to construct the VW's. A severe limitation of the VPL VR system is the use of RB2 Swivel 3D, which restricts the files to a maximum of 1020 objects and doesn't have the advanced graphics texture mapping. The other limitation is that the VPL VR system is a turn-key system which does not provide the flexibility for user to add new sensors and C language interface. Recently, NASA/MSFC CAVE lab provides VR systems built on Sense8 WorldToolKit (WTK) which is a C library for creating VR development environments. WTK provides device drivers for most of the sensors and eyephones available on the VR market. WTK accepts several CAD file formats, such as Sense8 Neutral File Format, AutoCAD DXF and 3D Studio file format, Wave Front OBJ file format, VideoScape GEO file format, Intergraph EMS stereolithographics and CATIA Stereolithographics STL file formats. WTK functions are object-oriented in their naming convention, are grouped into classes, and provide easy C language interface. Using a CAD or modelling program to build a VW for WTK VR applications, we typically construct the stationary universe with all the geometric objects except the dynamic objects, and create each dynamic object in an individual file.

Wang, Peter Hor-Ching↗