Search NASA⌕ Search

SEARCH · Search NASA

Results for “File Transfer 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.

205 records · Page 12

The ILRS: Approaching 20 Years and Planning for the Future

The International Laser Ranging Service (ILRS) was established by the International Association of Geodesy (IAG) in 1998 to support programs in geodesy, geophysics, fundamental constants and lunar research, and to provide the International Earth Rotation Service with data products that are essential to the maintenance and improvement in the International Terrestrial Reference Frame (ITRF), the basis for metric measurements of changes in the Earth and Earth–Moon system. Other scientific products derived from laser ranging include precise geocentric positions and motions of ground stations, satellite orbits, components of Earth’s gravity field and their temporal variations, Earth Orientation Parameters, precise lunar ephemerides and information about the internal structure of the Moon. Laser ranging systems are already measuring the one-way distance to remote optical receivers in space and are performing very accurate time transfer between remote sites in the Earth and in Space. The ILRS works closely with the IAG’s Global Geodetic Observing System. The ILRS develops (1) the standards and specifications necessary for product consistency, and (2) the priorities and tracking strategies required to maximize network efficiency. The service collects, merges, analyzes, archives and distributes satellite and lunar laser ranging data to satisfy a variety of scientific, engineering, and operational needs and encourages the application of new technologies to enhance the quality, quantity, and cost effectiveness of its data products. The ILRS works with (1) new satellite missions in the design and building of retroreflector targets to maximize data quality and quantity, and (2) science programs to optimize scientific data yield. Since its inception, the ILRS has grown to include forty laser ranging stations distributed around the world. The ILRS stations track more than ninety satellites from low Earth orbit (LEO) to the geosynchronous orbit altitude as well as retroreflector arrays on the surface of the Moon. Applications have been expanded to include time transfer, asynchronous ranging for targets at extended ranges, free space quantum telecommunications, and the tracking of space debris. Laser ranging technology is moving to lower energy, higher repetition rates (kHz), single-photon-sensitive detectors, shorter pulse widths, shorter normal point intervals for faster data acquisition, and increased pass interleaving, automated to autonomous operation with remote access, and embedded software for real-time updates and decision making. An example of pass interleaving is presented for the Yarragadee station (see Fig. 4); tracking of LEO satellites is often accommodated during break in LEO and GNSS passes. New satellites arrays provide more compact targets and work continues on the development of lighter less expensive arrays for satellites and the moon. The service now provides operational ITRF products including daily/ weekly station positions and daily resolution Earth orientation products; the flow of weekly combination of satellite orbit files for LAGEOS/Etalon-1 and -2 has recently been established. New products are under testing through a pilot project on systematic error monitoring currently underway. The article will give an overview of activities underway within the service, paths forward presently envisioned, and current issues and challenges.

Laser retroreflectors↗

Test Cases for the Benchmark Active Controls: Spoiler and Control Surface Oscillations and Flutter

As a portion of the Benchmark Models Program at NASA Langley, a simple generic model was developed for active controls research and was called BACT for Benchmark Active Controls Technology model. This model was based on the previously-tested Benchmark Models rectangular wing with the NACA 0012 airfoil section that was mounted on the Pitch and Plunge Apparatus (PAPA) for flutter testing. The BACT model had an upper surface spoiler, a lower surface spoiler, and a trailing edge control surface for use in flutter suppression and dynamic response excitation. Previous experience with flutter suppression indicated a need for measured control surface aerodynamics for accurate control law design. Three different types of flutter instability boundaries had also been determined for the NACA 0012/PAPA model, a classical flutter boundary, a transonic stall flutter boundary at angle of attack, and a plunge instability near M = 0.9. Therefore an extensive set of steady and control surface oscillation data was generated spanning the range of the three types of instabilities. This information was subsequently used to design control laws to suppress each flutter instability. There have been three tests of the BACT model. The objective of the first test, TDT Test 485, was to generate a data set of steady and unsteady control surface effectiveness data, and to determine the open loop dynamic characteristics of the control systems including the actuators. Unsteady pressures, loads, and transfer functions were measured. The other two tests, TDT Test 502 and TDT Test 5 18, were primarily oriented towards active controls research, but some data supplementary to the first test were obtained. Dynamic response of the flexible system to control surface excitation and open loop flutter characteristics were determined during Test 502. Loads were not measured during the last two tests. During these tests, a database of over 3000 data sets was obtained. A reasonably extensive subset of the data sets from the first two tests have been chosen for Test Cases for computational comparisons concentrating on static conditions and cases with harmonically oscillating control surfaces. Several flutter Test Cases from both tests have also been included. Some aerodynamic comparisons with the BACT data have been made using computational fluid dynamics codes at the Navier-Stokes level (and in the accompanying chapter SC). Some mechanical and active control studies have been presented. In this report several Test Cases are selected to illustrate trends for a variety of different conditions with emphasis on transonic flow effects. Cases for static angles of attack, static trailing-edge and upper-surface spoiler deflections are included for a range of conditions near those for the oscillation cases. Cases for trailing-edge control and upper-surface spoiler oscillations for a range of Mach numbers, angle of attack, and static control deflections are included. Cases for all three types of flutter instability are selected. In addition some cases are included for dynamic response measurements during forced oscillations of the controls on the flexible mount. An overview of the model and tests is given, and the standard formulary for these data is listed. Some sample data and sample results of calculations are presented. Only the static pressures and the first harmonic real and imaginary parts of the pressures are included in the data for the Test Cases, but digitized time histories have been archived. The data for the Test Cases are also available as separate electronic files.

Bennett, Robert M.↗

Developing CORBA-Based Distributed Scientific Applications from Legacy Fortran Programs

Recent progress in distributed object technology has enabled software applications to be developed and deployed easily such that objects or components can work together across the boundaries of the network, different operating systems, and different languages. A distributed object is not necessarily a complete application but rather a reusable, self-contained piece of software that co-operates with other objects in a plug-and-play fashion via a well-defined interface. The Common Object Request Broker Architecture (CORBA), a middleware standard defined by the Object Management Group (OMG), uses the Interface Definition Language (IDL) to specify such an interface for transparent communication between distributed objects. Since IDL can be mapped to any programming language, such as C++, Java, Smalltalk, etc., existing applications can be integrated into a new application and hence the tasks of code re-writing and software maintenance can be reduced. Many scientific applications in aerodynamics and solid mechanics are written in Fortran. Refitting these legacy Fortran codes with CORBA objects can increase the codes reusability. For example, scientists could link their scientific applications to vintage Fortran programs such as Partial Differential Equation(PDE) solvers in a plug-and-play fashion. Unfortunately, CORBA IDL to Fortran mapping has not been proposed and there seems to be no direct method of generating CORBA objects from Fortran without having to resort to manually writing C/C++ wrappers. In this paper, we present an efficient methodology to integrate Fortran legacy programs into a distributed object framework. Issues and strategies regarding the conversion and decomposition of Fortran codes into CORBA objects are discussed. The following diagram shows the conversion and decomposition mechanism we proposed. Our goal is to keep the Fortran codes unmodified. The conversion- aided tool takes the Fortran application program as input and helps programmers generate C/C++ header file and IDL file for wrapping the Fortran code. Programmers need to determine by themselves how to decompose the legacy application into several reusable components based on the cohesion and coupling factors among the functions and subroutines. However, programming effort still can be greatly reduced because function headings and types have been converted to C++ and IDL styles. Most Fortran applications use the COMMON block to facilitate the transfer of large amount of variables among several functions. The COMMON block plays the similar role of global variables used in C. In the CORBA-compliant programming environment, global variables can not be used to pass values between objects. One approach to dealing with this problem is to put the COMMON variables into the parameter list. We do not adopt this approach because it requires modification of the Fortran source code which violates our design consideration. Our approach is to extract the COMMON blocks and convert them into a structure-typed attribute in C++. Through attributes, each component can initialize the variables and return the computation result back to the client. We have tested successfully the proposed conversion methodology based on the f2c converter. Since f2c only translates Fortran to C, we still needed to edit the converted code to meet the C++ and IDL syntax. For example, C++/IDL requires a tag in the structure type, while C does not. In this paper, we identify the necessary changes to the f2c converter in order to directly generate the C++ header and the IDL file. Our future work is to add GUI interface to ease the decomposition task by simply dragging and dropping icons.

Sang, Janche↗

Wireless Acoustic Measurement System

A prototype wireless acoustic measurement system (WAMS) is one of two main subsystems of the Acoustic Prediction/ Measurement Tool, which comprises software, acoustic instrumentation, and electronic hardware combined to afford integrated capabilities for predicting and measuring noise emitted by rocket and jet engines. The other main subsystem is described in the article on page 8. The WAMS includes analog acoustic measurement instrumentation and analog and digital electronic circuitry combined with computer wireless local-area networking to enable (1) measurement of sound-pressure levels at multiple locations in the sound field of an engine under test and (2) recording and processing of the measurement data. At each field location, the measurements are taken by a portable unit, denoted a field station. There are ten field stations, each of which can take two channels of measurements. Each field station is equipped with two instrumentation microphones, a micro- ATX computer, a wireless network adapter, an environmental enclosure, a directional radio antenna, and a battery power supply. The environmental enclosure shields the computer from weather and from extreme acoustically induced vibrations. The power supply is based on a marine-service lead-acid storage battery that has enough capacity to support operation for as long as 10 hours. A desktop computer serves as a control server for the WAMS. The server is connected to a wireless router for communication with the field stations via a wireless local-area network that complies with wireless-network standard 802.11b of the Institute of Electrical and Electronics Engineers. The router and the wireless network adapters are controlled by use of Linux-compatible driver software. The server runs custom Linux software for synchronizing the recording of measurement data in the field stations. The software includes a module that provides an intuitive graphical user interface through which an operator at the control server can control the operations of the field stations for calibration and for recording of measurement data. A test engineer positions and activates the WAMS. The WAMS automatically establishes the wireless network. Next, the engineer performs pretest calibrations. Then the engineer executes the test and measurement procedures. After the test, the raw measurement files are copied and transferred, through the wireless network, to a hard disk in the control server. Subsequently, the data are processed into 1.3-octave spectrograms.

Anderson, Paul D.↗

Wireless Acoustic Measurement System

A prototype wireless acoustic measurement system (WAMS) is one of two main subsystems of the Acoustic Prediction/Measurement Tool, which comprises software, acoustic instrumentation, and electronic hardware combined to afford integrated capabilities for predicting and measuring noise emitted by rocket and jet engines. The other main subsystem is described in "Predicting Rocket or Jet Noise in Real Time" (SSC-00215-1), which appears elsewhere in this issue of NASA Tech Briefs. The WAMS includes analog acoustic measurement instrumentation and analog and digital electronic circuitry combined with computer wireless local-area networking to enable (1) measurement of sound-pressure levels at multiple locations in the sound field of an engine under test and (2) recording and processing of the measurement data. At each field location, the measurements are taken by a portable unit, denoted a field station. There are ten field stations, each of which can take two channels of measurements. Each field station is equipped with two instrumentation microphones, a micro-ATX computer, a wireless network adapter, an environmental enclosure, a directional radio antenna, and a battery power supply. The environmental enclosure shields the computer from weather and from extreme acoustically induced vibrations. The power supply is based on a marine-service lead-acid storage battery that has enough capacity to support operation for as long as 10 hours. A desktop computer serves as a control server for the WAMS. The server is connected to a wireless router for communication with the field stations via a wireless local-area network that complies with wireless-network standard 802.11b of the Institute of Electrical and Electronics Engineers. The router and the wireless network adapters are controlled by use of Linux-compatible driver software. The server runs custom Linux software for synchronizing the recording of measurement data in the field stations. The software includes a module that provides an intuitive graphical user interface through which an operator at the control server can control the operations of the field stations for calibration and for recording of measurement data. A test engineer positions and activates the WAMS. The WAMS automatically establishes the wireless network. Next, the engineer performs pretest calibrations. Then the engineer executes the test and measurement procedures. After the test, the raw measurement files are copied and transferred, through the wireless network, to a hard disk in the control server. Subsequently, the data are processed into 1/3-octave spectrograms.

Anderson, Paul D.↗

CEO Sites Mission Management System (SMMS)

Late in fiscal year 2011, the Crew Earth Observations (CEO) team was tasked to upgrade its science site database management tool, which at the time was integrated with the Automated Mission Planning System (AMPS) originally developed for Earth Observations mission planning in the 1980s. Although AMPS had been adapted and was reliably used by CEO for International Space Station (ISS) payload operations support, the database structure was dated, and the compiler required for modifications would not be supported in the Windows 7 64-bit operating system scheduled for implementation the following year. The Sites Mission Management System (SMMS) is now the tool used by CEO to manage a heritage Structured Query Language (SQL) database of more than 2,000 records for Earth science sites. SMMS is a carefully designed and crafted in-house software package with complete and detailed help files available for the user and meticulous internal documentation for future modifications. It was delivered in February 2012 for test and evaluation. Following acceptance, it was implemented for CEO mission operations support in April 2012. The database spans the period from the earliest systematic requests for astronaut photography during the shuttle era to current ISS mission support of the CEO science payload. Besides logging basic image information (site names, locations, broad application categories, and mission requests), the upgraded database management tool now tracks dates of creation, modification, and activation; imagery acquired in response to requests; the status and location of ancillary site information; and affiliations with studies, their sponsors, and collaborators. SMMS was designed to facilitate overall mission planning in terms of site selection and activation and provide the necessary site parameters for the Satellite Tool Kit (STK) Integrated Message Production List Editor (SIMPLE), which is used by CEO operations to perform daily ISS mission planning. The CEO team uses the SMMS for three general functions - database queries of content and status, individual site creation and updates, and mission planning. The CEO administrator of the science site database is able to create or modify the content of sites and activate or deactivate them based on the requirements of the sponsors. The administrator supports and implements ISS mission planning by assembling, reporting, and activating mission-specific site selections for management; deactivating sites as requirements are met; and creating new sites, such as International Charter sites for disasters, as circumstances warrant. In addition to the above CEO internal uses, when site planning for a specific ISS mission is complete and approved, the SMMS can produce and export those essential site database elements for the mission into XML format for use by onboard Earth-location systems, such as Worldmap. The design, development, and implementation of the SMMS resulted in a superior database management system for CEO science sites by focusing on the functions and applications of the database alone instead of integrating the database with the multipurpose configuration of the AMPS. Unlike the AMPS, it can function and be modified within the existing Windows 7 environment. The functions and applications of the SMMS were expanded to accommodate more database elements, report products, and a streamlined interface for data entry and review. A particularly elegant enhancement in data entry was the integration of the Google Earth application for the visual display and definition of site coordinates for site areas defined by multiple coordinates. Transfer between the SMMS and Google Earth is accomplished with a Keyhole Markup Language (KML) expression of geographic data (see figures 3 and 4). Site coordinates may be entered into the SMMS panel directly for display in Google Earth, or the coordinates may be defined on the Google Earth display as a mouse-controlled polygonal definition and transferred back into the SMMS as KML input. This significantly reduces the possibility of errors in coordinate entries and provides visualization of the scale of the site being defined. CEO now has a powerful tool for managing and defining sites on the Earth's surface for both targets of astronaut photography or other onboard remote sensing systems. It can also record and track results by sponsor, collaborator, or type of study.

Trenchard, Mike↗

Implementation of A New Microwave Scattering Database and A Forward Model for Active Microwave Sensors in CRTM

Radiative transfer models are extensively used for the assimilation of satellite observations into NWP models as well as retrieving geophysical products from satellite measurements. CRTM is a community model developed by NOAA JCSDA and widely used for different purposes requiring RT calculations. CRTM requires bulk scattering lookup tables in order to perform all-sky RT calculations. However, the current CRTM lookup tables for microwave frequencies were generated based on the Mie theory by assuming spherical frozen particles. The scattering lookup tables generated using the DDA technique has shown to largely improve the RT scattering calculations in the MW region. This presentation targets (i) the implementation and validation of a DDA database that was originally developed for the ARTS RT model into CRTM, and (ii) developing the CRTM active sensor module that takes advantage of the backscattering coefficients computed using the DDA method. The DDA database only provides single scattering properties of different habits, while CRTM requires bulk scattering properties. The CRTM cloud coefficients were previously generated based on the effective radius for representing the size of the particles. However, effective radius is neither measurable nor provided by the NWP models, thus need to be estimated from other geophysical variables such as water content. Therefore, in addition to calculating the CRTM bulk scattering properties from the DDA single scattering database, the CRTM was also largely modified to use cloud water content (kg.m-3), instead of effective radius, for performing the interpolation over size/mass of the particles. CRTM already requires water content as input, thus no extra variables are required for performing scattering calculations using the new ARTS DDA database. The CRTM scattering modules search for effective radius in cloud coefficient files and will use the cloud water content if the effective radius dimension is not found in the cloud coefficient files. Figure 1 shows the CRTM simulated brightness temperatures computed using different cloud coefficients versus ATMS observed values over Hurricane Irma on September 7, 2017 at 18:00 UTC. We used all the cloud water content values included in ERA5 with default CRTM/DDA habits for water, rain, snow, ice, hail, and graupel. ERA5 does not provide separate water content values for ice, hail, and graupel, thus the ice water content values were divided between ice, hail, and graupel clouds similar to what was explained in the previous section. In channels with a frequency lower than 90 GHz, emission from water and rain clouds can compensate for cloud scattering so that cloud contaminated Tbs are larger than corresponding clear sky Tbs. The DDA simulations for channels 1-7 largely perform better than the Mie simulations. The DDA simulations show a mix of small negative and positive simulated minus observed values, while the Mie results show large negative biases. The weighting functions for some of the ATMS temperature sounding channels (channels 9-15) peak mostly above the clouds, therefore the measured Tbs become less sensitive to clouds so that the results of both Mie and DDA become very similar. The Mie lookup tables generate excessive scattering for channel 16, but not enough scattering for the water vapor channels. In the specific case of Hurricane Maria, the DDA lookup tables do not generate enough scattering for channel 16, but the DDA results are much more consistent with observations for water vapor channels than for channel 16. It should be noted that the results may vary if we use other habits to represent snow, hail, and graupel in the DDA simulations. Although these results clearly show the advantage of the DDA database over the Mie dataset, different error sources such as error in the observations, displacement of clouds in the ERA5 reanalysis, and also lack of convective clouds or in general errors in the input atmospheric and cloud profiles contribute to the differences between the simulated and observed values. Aside from the improvements in the simulations, a major advantage of the new dataset is a large number of habits that can be used to tune the data assimilation systems to perform well in different weather conditions.

Isaac Moradi↗