Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “file transfer”

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 181 records · Page 10

Big-data Efficient and Automated Science Transfer (BEAST): An Open-Source Software Architecture for Arc Jet Data Management, Modeling, and Automation

Big-data Efficient and Automated Science Transfer (BEAST) was conceived to address the existing ground testing data management of the NASA Ames arc jet facilities (e.g., manually entered Excel files and USB drive data transfers). These data management practices were seen as a choke point for future thermal protection system (TPS) development as they limit statistical tracking, resolution of diagnostics, coordination between video/time series, data throughput, and data processing speed/efficiency. Consequently, BEAST was developed to provide a new data infrastructure with streamlined data collection, processing, transfer, and analysis. This new framework also seeks to implement the FAIR principles of data stewardship: Findable, Accessible, Interoperable, and Reusable. The BEAST framework is based on a combination of the Python Django web framework and the Python data stack to provide a monolithic, open-source platform for data management, automation, and machine learning. This architecture was chosen for maintainability and scalability for a small, in-house development team. This paper will describe the application framework, deployment, and discuss the benefits and future plans for the system.

Data management↗

Big-data Efficient Automated Science Transfer (BEAST): an open-source software architecture for arc jet data management, modeling, and automation

Big-data Efficient and Automated Science Transfer (BEAST) was conceived to address the existing ground testing data management of the NASA Ames arc jet facilities (e.g., manually entered Excel files and USB drive data transfers). These data management practices were seen as a choke point for future thermal protection system (TPS) development as they limit statistical tracking, resolution of diagnostics, coordination between video/time series, data throughput, and data processing speed/efficiency. Consequently, BEAST was developed to provide a new data infrastructure with streamlined data collection, processing, transfer, and analysis. This new framework also seeks to implement the FAIR principles of data stewardship: Findable, Accessible, Interoperable, and Reusable. The BEAST framework is based on a combination of the Python Django web framework and the Python data stack to provide a monolithic, open-source platform for data management, automation, and machine learning. This architecture was chosen for maintainability and scalability for a small, in-house development team. This paper will describe the application framework, deployment, and discuss the benefits and future plans for the system.

Data management↗

Mars Interoperability 2008-2015: Options for Relay Orbiter Support to Mars Bound Assets

The current relay orbiter infrastructure at Mars, in support of the user assets presently at Mars and those scheduled for the 2008 to 2015 time frame, only have a need to store-and-forward the returned data collected by an asset to Earth as a single non-prioritized data file. In the forward direction, the relay orbiters are only required to relay the forward link data, i.e., command sequences, software and configuration information assembled on the ground, to the Asset. There are currently no requirements for status/control messages or files to be sent in the return direction from an Asset to an application located on the Relay, nor are there requirements in the forward direction to send status/control messages or files originating on a Relay to an Asset. In addition there are currently no networking requirements at Mars where data originally sent by an Asset is to be delivered to another user asset. However, we foresee the day when standard services for 1) on-board file prioritization of user asset data by a Relay, 2) control/status message transfer between assets and a Relay, and 3) networking between assets i.e., Asset to Asset message/file transfer via a Relay will be required. Each of these services will require the Relay to be capable of understanding the data type and routing needs of the user asset data and be capable of processing it for these purposes. This paper will focus on the innovative enhancements required to the existing communications infrastructure at Mars to enable these future services.

File Transfer↗

Storage system architectures and their characteristics

Not all users storage requirements call for 20 MBS data transfer rates, multi-tier file or data migration schemes, or even automated retrieval of data. The number of available storage solutions reflects the broad range of user requirements. It is foolish to think that any one solution can address the complete range of requirements. For users with simple off-line storage requirements, the cost and complexity of high end solutions would provide no advantage over a more simple solution. The correct answer is to match the requirements of a particular storage need to the various attributes of the available solutions. The goal of this paper is to introduce basic concepts of archiving and storage management in combination with the most common architectures and to provide some insight into how these concepts and architectures address various storage problems. The intent is to provide potential consumers of storage technology with a framework within which to begin the hunt for a solution which meets their particular needs. This paper is not intended to be an exhaustive study or to address all possible solutions or new technologies, but is intended to be a more practical treatment of todays storage system alternatives. Since most commercial storage systems today are built on Open Systems concepts, the majority of these solutions are hosted on the UNIX operating system. For this reason, some of the architectural issues discussed focus around specific UNIX architectural concepts. However, most of the architectures are operating system independent and the conclusions are applicable to such architectures on any operating system.

Sarandrea, Bryan M.↗

A Collaborative Analysis Tool for Thermal Protection Systems for Single Stage to Orbit Launch Vehicles

Presented is a design tool and process that connects several disciplines which are needed in the complex and integrated design of high performance reusable single stage to orbit (SSTO) vehicles. Every system is linked to every other system and in the case of SSTO vehicles with air breathing propulsion, which is currently being studied by the National Aeronautics and Space Administration (NASA); the thermal protection system (TPS) is linked directly to almost every major system. The propulsion system pushes the vehicle to velocities on the order of 15 times the speed of sound in the atmosphere before pulling up to go to orbit which results high temperatures on the external surfaces of the vehicle. Thermal protection systems to maintain the structural integrity of the vehicle must be able to mitigate the heat transfer to the structure and be lightweight. Herein lies the interdependency, in that as the vehicle's speed increases, the TPS requirements are increased. And as TPS masses increase the effect on the propulsion system and all other systems is compounded. To adequately determine insulation masses for a vehicle such as the one described above, the aeroheating loads must be calculated and the TPS thicknesses must be calculated for the entire vehicle. To accomplish this an ascent or reentry trajectory is obtained using the computer code Program to Optimize Simulated Trajectories (POST). The trajectory is then used to calculate the convective heat rates on several locations on the vehicles using the Miniature Version of the JA70 Aerodynamic Heating Computer Program (MINIVER). Once the heat rates are defined for each body point on the vehicle, then insulation thicknesses that are required to maintain the vehicle within structural limits are calculated using Systems Improved Numerical Differencing Analyzer (SINDA) models. If the TPS masses are too heavy for the performance of the vehicle the process may be repeated altering the trajectory or some other input to reduce the TPS mass. The problem described is an example of the need for collaborative design and analysis. Analysis tools are being developed to facilitate these collaborative efforts. RECIPE is a cross-platform application capable of hosting a number of engineers and designers across the Internet for distributed and collaborative engineering environments. Such integrated system design environments allow for collaborative team design analysis for performing individual or reduced team studies. The analysis tools mentioned earlier are commonly run on different platforms and are usually run by different people. To facilitate the larger number of potential runs that may need to be made, RECIPE connects the computer codes that calculate the trajectory data, heat rate data, and TPS masses so that the output from each tool is easily transferred to the model input files that need it. This methodology is being applied to solve launch vehicle thermal design problems to shorten the design cycle, and enable the project team to evaluate design options. Results will be presented indicating the effectiveness of this as a collaborative design tool.

Alexander, Reginald A.↗

Structural Modeling Using "Scanning and Mapping" Technique

Supported by NASA Glenn Center, we are in the process developing a structural damage diagnostic and monitoring system for rocket engines, which consists of five modules: Structural Modeling, Measurement Data Pre-Processor, Structural System Identification, Damage Detection Criterion, and Computer Visualization. The function of the system is to detect damage as it is incurred by the engine structures. The scientific principle to identify damage is to utilize the changes in the vibrational properties between the pre-damaged and post-damaged structures. The vibrational properties of the pre-damaged structure can be obtained based on an analytic computer model of the structure. Thus, as the first stage of the whole research plan, we currently focus on the first module - Structural Modeling. Three computer software packages are selected, and will be integrated for this purpose. They are PhotoModeler-Pro, AutoCAD-R14, and MSC/NASTRAN. AutoCAD is the most popular PC-CAD system currently available in the market. For our purpose, it plays like an interface to generate structural models of any particular engine parts or assembly, which is then passed to MSC/NASTRAN for extracting structural dynamic properties. Although AutoCAD is a powerful structural modeling tool, the complexity of engine components requires a further improvement in structural modeling techniques. We are working on a so-called "scanning and mapping" technique, which is a relatively new technique. The basic idea is to producing a full and accurate 3D structural model by tracing on multiple overlapping photographs taken from different angles. There is no need to input point positions, angles, distances or axes. Photographs can be taken by any types of cameras with different lenses. With the integration of such a modeling technique, the capability of structural modeling will be enhanced. The prototypes of any complex structural components will be produced by PhotoModeler first based on existing similar components, then passed to AutoCAD for modification and correction of any discrepancies seen in the Photomodeler version of the 3Dmodel. These three software packages are fully compatible. The DXF file can be used to transfer drawings among those packages. To begin this entire process, we are using a small replica of an actual engine blade as a test object. This paper introduces the accomplishment of our recent work.

Amos, Courtney L.↗

Internet-based transfer of cardiac ultrasound images

A drawback to large-scale multicentre studies is the time required for the centralized evaluation of diagnostic images. We evaluated the feasibility of digital transfer of echocardiographic images to a central laboratory for rapid and accurate interpretation. Ten patients undergoing trans-oesophageal echocardiographic scanning at three sites had representative single images and multiframe loops stored digitally. The images were analysed in the ordinary way. All images were then transferred via the Internet to a central laboratory and reanalysed by a different observer. The file sizes were 1.5-72 MByte and the transfer rates achieved were 0.6-4.8 Mbit/min. Quantitative measurements were similar between most on-site and central laboratory measurements (all P > 0.25), although measurements differed for left atrial width and pulmonary venous systolic velocities (both P < 0.05). Digital transfer of echocardiographic images and data to a central laboratory may be useful for multicentre trials.

NASA Discipline Cardiopulmonary↗

An Evaluation of Protocol Enhancing Proxies and File Transport Protocols for Satellite Communication

NASA is utilizing Global Hawk aircraft in high-altitude, long-duration Earth science missions. Communications with the onboard research equipment and sensors (the science payload) is via Ku-Band radio utilizing satellites in geostationary orbits. All payload communications use standard Internet Protocols and routing, and much of the data to be transferred is comprised of very large files. The science community is interested in fully utilizing these communication links to retrieve data as quickly and reliably as possible. A test bed was developed at NASA Ames to evaluate modern transport protocols as well as Protocol Enhancing Proxies (PEPs) to determine what tools best fit the needs of the science community. This paper describes the test bed used, the protocols, the PEPs that were evaluated, the particular tests performed and the results and conclusions.

Finch, Patrick Eugene↗

Surface-Shading Program

Surface Shading computer program, SURF, developed in support of work of Computational Fluid Dynamics (CFD). Part of CFD graphics software. Accepts input in form of grid and solution files otherwise normally fed to Ames Research Center's version of PLOT3D software from "flow solver" programs. Interactively creates wire-frame, shaded, and function-map parts viewed and then transferred to Ames Research Graphic (ARCGRAPH) standard files, animated with GAS (COSMIC Program ARC-12379). Written in C programming language and requires Silicon Graphics "include" files (e.g., stdio.h, gl.h).

Plessel, Todd↗

Deploying the NASA Meter Class Autonomous Telescope (MCAT) on Ascension Island

NASA has successfully constructed the 1.3m Meter Class Autonomous Telescope (MCAT) facility on Ascension Island in the South Atlantic Ocean. MCAT is an optical telescope designed specifically to collect ground-based data for the statistical characterization of orbital debris ranging from Low Earth Orbit (LEO) through Middle Earth Orbits (MEO) and beyond to Geo Transfer and Geosynchronous Orbits (GTO/GEO). The location of Ascension Island has two distinct advantages. First, the near-equatorial location fills a significant longitudinal gap in the Ground-based Electro-Optical Deep Space Surveillance (GEODSS) network of telescopes, and second, it allows access to objects in Low Inclination Low-Earth Orbits (LILO). The MCAT facility will be controlled by a sophisticated software suite that operates the dome and telescope, assesses sky and weather conditions, conducts all necessary calibrations, defines an observing strategy (as dictated by weather, sky conditions and the observing plan for the night), and carries out the observations. It then reduces the collected data via four primary observing modes ranging from tracking previously cataloged objects to conducting general surveys for detecting uncorrelated debris. Nightly observing plans, as well as the resulting text file of reduced data, will be transferred to and from Ascension, respectively, via a satellite connection. Post-processing occurs at NASA Johnson Space Center. Construction began in September, 2014 with dome and telescope installation occurring in April through early June, 2015. First light was achieved in June, 2015. Acceptance testing, full commissioning, and calibration of this soon-to-be fully autonomous system commenced in summer 2015. The initial characterization of the system from these tests is presented herein.

Lederer, S. M.↗

Data storage and retrieval system

The Data Storage and Retrieval System (DSRS) consists of off-the-shelf system components integrated as a file server supporting very large files. These files are on the order of one gigabyte of data per file, although smaller files on the order of one megabyte can be accommodated as well. For instance, one gigabyte of data occupies approximately six 9 track tape reels (recorded at 6250 bpi). Due to this large volume of media, it was desirable to shrink the size of the proposed media to a single portable cassette. In addition to large size, a key requirement was that the data needs to be transferred to a (VME based) workstation at very high data rates. One gigabyte (GB) of data needed to be transferred from an archiveable media on a file server to a workstation in less than 5 minutes. Equivalent size, on-line data needed to be transferred in less than 3 minutes. These requirements imply effective transfer rates on the order of four to eight megabytes per second (4-8 MB/s). The DSRS also needed to be able to send and receive data from a variety of other sources accessible from an Ethernet local area network.

Nakamoto, Glen↗

Data storage and retrieval system

The Data Storage and Retrieval System (DSRS) consists of off-the-shelf system components integrated as a file server supporting very large files. These files are on the order of one gigabyte of data per file, although smaller files on the order of one megabyte can be accommodated as well. For instance, one gigabyte of data occupies approximately six 9-track tape reels (recorded at 6250 bpi). Due to this large volume of media, it was desirable to 'shrink' the size of the proposed media to a single portable cassette. In addition to large size, a key requirement was that the data needs to be transferred to a (VME based) workstation at very high data rates. One gigabyte (GB) of data needed to be transferred from an archiveable media on a file server to a workstation in less than 5 minutes. Equivalent size, on-line data needed to be transferred in less than 3 minutes. These requirements imply effective transfer rates on the order of four to eight megabytes per second (4-8 MB/s). The DSRS also needed to be able to send and receive data from a variety of other sources accessible from an Ethernet local area network.

Nakamoto, Glen↗

Data-management and information system

User command language consists of unabbreviated English words. System allows user to create, delete, sort, merge, update, punch, or transfer all or portion of any file in system without programmer assistance.

Long, J. J.↗

PC-based Digital Acoustic Control System (DACS)

The PC-based Digital Acoustic Control System (DACS), which is a closed-loop system capable of precisely controlling the spectrum in real-time mode, is discussed. The system is based on integrated facility hardware including control microphones, signal conditioners, a real-time analyzer (RTA), a shaper, high capacity power amplifiers, and acoustic horns and generators. The DACS provides both an improved spectrum simulation and realtime information of pertinent test parameters that are stored in five separate files. These files can be hard copied and/or transferred to other programs to obtain a specific format of the test data. It is demonstrated that the computer interface with digital RTA and programmable filters are most effective and efficient. This facility runs independently under the control of a computer with an IEEE-488 interface to the facility hardware.

Shah, Kamlesh C.↗

Software for Automated Reading of STEP Files by I-DEAS(trademark)

A program called "readstep" enables the I-DEAS(tm) computer-aided-design (CAD) software to automatically read Standard for the Exchange of Product Model Data (STEP) files. (The STEP format is one of several used to transfer data between dissimilar CAD programs.) Prior to the development of "readstep," it was necessary to read STEP files into I-DEAS(tm) one at a time in a slow process that required repeated intervention by the user. In operation, "readstep" prompts the user for the location of the desired STEP files and the names of the I-DEAS(tm) project and model file, then generates an I-DEAS(tm) program file called "readstep.prg" and two Unix shell programs called "runner" and "controller." The program "runner" runs I-DEAS(tm) sessions that execute readstep.prg, while "controller" controls the execution of "runner" and edits readstep.prg if necessary. The user sets "runner" and "controller" into execution simultaneously, and then no further intervention by the user is required. When "runner" has finished, the user should see only parts from successfully read STEP files present in the model file. STEP files that could not be read successfully (e.g., because of format errors) should be regenerated before attempting to read them again.

Pinedo, John↗

Network issues for large mass storage requirements

File Servers and Supercomputing environments need high performance networks to balance the I/O requirements seen in today's demanding computing scenarios. UltraNet is one solution which permits both high aggregate transfer rates and high task-to-task transfer rates as demonstrated in actual tests. UltraNet provides this capability as both a Server-to-Server and Server-to-Client access network giving the supercomputing center the following advantages highest performance Transport Level connections (to 40 MBytes/sec effective rates); matches the throughput of the emerging high performance disk technologies, such as RAID, parallel head transfer devices and software striping; supports standard network and file system applications using SOCKET's based application program interface such as FTP, rcp, rdump, etc.; supports access to the Network File System (NFS) and LARGE aggregate bandwidth for large NFS usage; provides access to a distributed, hierarchical data server capability using DISCOS UniTree product; supports file server solutions available from multiple vendors, including Cray, Convex, Alliant, FPS, IBM, and others.

Perdue, James↗