Search NASA⌕ Search

SEARCH · Search NASA

Results for “Compiler”

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 1,279 records · Page 71

Architecture Adaptive Computing Environment

Architecture Adaptive Computing Environment (aCe) is a software system that includes a language, compiler, and run-time library for parallel computing. aCe was developed to enable programmers to write programs, more easily than was previously possible, for a variety of parallel computing architectures. Heretofore, it has been perceived to be difficult to write parallel programs for parallel computers and more difficult to port the programs to different parallel computing architectures. In contrast, aCe is supportable on all high-performance computing architectures. Currently, it is supported on LINUX clusters. aCe uses parallel programming constructs that facilitate writing of parallel programs. Such constructs were used in single-instruction/multiple-data (SIMD) programming languages of the 1980s, including Parallel Pascal, Parallel Forth, C*, *LISP, and MasPar MPL. In aCe, these constructs are extended and implemented for both SIMD and multiple- instruction/multiple-data (MIMD) architectures. Two new constructs incorporated in aCe are those of (1) scalar and virtual variables and (2) pre-computed paths. The scalar-and-virtual-variables construct increases flexibility in optimizing memory utilization in various architectures. The pre-computed-paths construct enables the compiler to pre-compute part of a communication operation once, rather than computing it every time the communication operation is performed.

Dorband, John E.↗

Dynamically Alterable Arrays of Polymorphic Data Types

An application library package was developed that represents data packets for Deep Space Network (DSN) message packets as dynamically alterable arrays composed of arbitrary polymorphic data types. The software was to address a limitation of the present state of the practice for having an array directly composed of a single monomorphic data type. This is a severe limitation when one is dealing with science data in that the types of objects one is dealing with are typically not known in advance and, therefore, are dynamic in nature. The unique feature of this approach is that it enables one to define at run-time the dynamic shape of the matrix with the ability to store polymorphic data types in each of its indices. Existing languages such as C and C++ have the restriction that the shape of the array must be known in advance and each of its elements be a monomorphic data type that is strictly defined at compile-time. This program can be executed on a variety of platforms. It can be distributed in either source code or binary code form. It must be run in conjunction with any one of a number of Lisp compilers that are available commercially or as shareware.

James, Mark↗

The Updated IAU MDC Catalogue of Photographic Meteor Orbits

The database of photographic meteor orbits of the IAU Meteor Data Center at the Astronomical Institute SAS has gradually been updated. To the 2003 version of 4581 photographic orbits compiled from 17 different stations and obtained in the period 1936-1996, additional new 211 orbits compiled from 7 sources have been added. Thus, the updated version of the catalogue contains 4792 photographic orbits (equinox J2000.0) available either in two separate orbital and geophysical data files or a file with the merged data. All the updated files with relevant documentation are available at the web of the IAU Meteor Data Center. Keywords astronomical databases photographic meteor orbits 1 Introduction Meteoroid orbits are a basic tool for investigation of distribution and spatial structure of the meteoroid population in the close surroundings of the Earth s orbit. However, information about them is usually widely scattered in literature and often in publications with limited circulation. Therefore, the IAU Comm. 22 during the 1976 IAU General Assembly proposed to establish a meteor data center for collection of meteor orbits recorded by photographic and radio techniques. The decision was confirmed by the next IAU GA in 1982 and the data center was established (Lindblad, 1987). The purpose of the data center was to acquire, format, check and disseminate information on precise meteoroid orbits obtained by multi-station techniques and the database gradually extended as documented in previous reports on the activity of the Meteor Data Center by Lindblad (1987, 1995, 1999 and 2001) or Lindblad and Steel (1993). Up to present, the database consists of 4581 photographic meteor orbits (Lindblad et al., 2005), 63.330 radar determined orbit: Harvard Meteor Project (1961-1965, 1968-1969), Adelaide (1960-1961, 1968-1969), Kharkov (1975), Obninsk (1967-1968), Mogadish (1969-1970) and 1425 video-recordings (Lindblad, 1999) to which additional 817 video meteors orbits published by Koten el al. (2003) were

Porubcan, V.↗

MicroShell Minimalist Shell for Xilinx Microprocessors

MicroShell is a lightweight shell environment for engineers and software developers working with embedded microprocessors in Xilinx FPGAs. (MicroShell has also been successfully ported to run on ARM Cortex-M1 microprocessors in Actel ProASIC3 FPGAs, but without project-integration support.) Micro Shell decreases the time spent performing initial tests of field-programmable gate array (FPGA) designs, simplifies running customizable one-time-only experiments, and provides a familiar-feeling command-line interface. The program comes with a collection of useful functions and enables the designer to add an unlimited number of custom commands, which are callable from the command-line. The commands are parameterizable (using the C-based command-line parameter idiom), so the designer can use one function to exercise hardware with different values. Also, since many hardware peripherals instantiated in FPGAs have reasonably simple register-mapped I/O interfaces, the engineer can edit and view hardware parameter settings at any time without stopping the processor. MicroShell comes with a set of support scripts that interface seamlessly with Xilinx's EDK tool. Adding an instance of MicroShell to a project is as simple as marking a check box in a library configuration dialog box and specifying a software project directory. The support scripts then examine the hardware design, build design-specific functions, conditionally include processor-specific functions, and complete the compilation process. For code-size constrained designs, most of the stock functionality can be excluded from the compiled library. When all of the configurable options are removed from the binary, MicroShell has an unoptimized memory footprint of about 4.8 kB and a size-optimized footprint of about 2.3 kB. Since MicroShell allows unfettered access to all processor-accessible memory locations, it is possible to perform live patching on a running system. This can be useful, for instance, if a bug is discovered in a routine but the system cannot be rebooted: Shell allows a skilled operator to directly edit the binary executable in memory. With some forethought, MicroShell code can be located in a different memory location from custom code, permitting the custom functionality to be overwritten at any time without stopping the controlling shell.

Werne, Thomas A.↗

Computer-Aided Parallelizer and Optimizer

The Computer-Aided Parallelizer and Optimizer (CAPO) automates the insertion of compiler directives (see figure) to facilitate parallel processing on Shared Memory Parallel (SMP) machines. While CAPO currently is integrated seamlessly into CAPTools (developed at the University of Greenwich, now marketed as ParaWise), CAPO was independently developed at Ames Research Center as one of the components for the Legacy Code Modernization (LCM) project. The current version takes serial FORTRAN programs, performs interprocedural data dependence analysis, and generates OpenMP directives. Due to the widely supported OpenMP standard, the generated OpenMP codes have the potential to run on a wide range of SMP machines. CAPO relies on accurate interprocedural data dependence information currently provided by CAPTools. Compiler directives are generated through identification of parallel loops in the outermost level, construction of parallel regions around parallel loops and optimization of parallel regions, and insertion of directives with automatic identification of private, reduction, induction, and shared variables. Attempts also have been made to identify potential pipeline parallelism (implemented with point-to-point synchronization). Although directives are generated automatically, user interaction with the tool is still important for producing good parallel codes. A comprehensive graphical user interface is included for users to interact with the parallelization process.

Jin, Haoqiang↗

ESAS-Derived Earth Departure Stage Design for Human Mars Exploration

The Vision for Space Exploration has set the nation on a course to have humans on Mars as early as 2030. To reduce the cost and risk associated with human Mars exploration, NASA is planning for the Mars architecture to leverage the lunar architecture as fully as possible. This study takes the defined launch vehicles and system capabilities from ESAS and extends their application to DRM 3.0 to design an Earth Departure Stage suitable for the cargo and crew missions to Mars. The impact of a propellant depot in LEO was assessed and sLzed for use with the EDS. To quantitatively assess and compare the effectiveness of alternative designs, an initial baseline architecture was defined using the ESAS launch vehicles and DRM 3.0. The baseline architecture uses three NTR engines, LH2 propellant, no propellant depot in LEO, and launches on the Ares I and Ares V. The Mars transfer and surface elements from DRM 3.0 were considered to be fixed payloads in the design of the EDS. Feasible architecture alternatives were identified from previous architecture studies and anticipated capabilities and compiled in a morphological matrix. ESAS FOMs were used to determine the most critical design attributes for the effectiveness of the EDS. The ESAS-derived FOMs used in this study to assess alternative designs are effectiveness and performance, affordability, reliability, and risk. The individual FOMs were prioritized using the AHP, a method for pairwise comparison. All trades performed were evaluated with respect to the weighted FOMs, creating a Pareto frontier of equivalently ideal solutions. Additionally, each design on the frontier was evaluated based on its fulfillment of the weighted FOMs using TOPSIS, a quantitative method for ordinal ranking of the alternatives. The designs were assessed in an integrated environment using physics-based models for subsystem analysis where possible. However, for certain attributes such as engine type, historical, performance-based mass estimating relations were more easily employed. The elements from the design process were integrated into a single loop, allowing for rapid iteration of subsystem analyses and compilation of resulting designs.

Flaherty, Kevin↗

EMU Lessons Learned Database

As manned space exploration takes on the task of traveling beyond low Earth orbit, many problems arise that must be solved in order to make the journey possible. One major task is protecting humans from the harsh space environment. The current method of protecting astronauts during Extravehicular Activity (EVA) is through use of the specially designed Extravehicular Mobility Unit (EMU). As more rigorous EVA conditions need to be endured at new destinations, the suit will need to be tailored and improved in order to accommodate the astronaut. The Objective behind the EMU Lessons Learned Database(LLD) is to be able to create a tool which will assist in the development of next-generation EMUs, along with maintenance and improvement of the current EMU, by compiling data from Failure Investigation and Analysis Reports (FIARs) which have information on past suit failures. FIARs use a system of codes that give more information on the aspects of the failure, but if one is unfamiliar with the EMU they will be unable to decipher the information. A goal of the EMU LLD is to not only compile the information, but to present it in a user-friendly, organized, searchable database accessible to all familiarity levels with the EMU; both newcomers and veterans alike. The EMU LLD originally started as an Excel database, which allowed easy navigation and analysis of the data through pivot charts. Creating an entry requires access to the Problem Reporting And Corrective Action database (PRACA), which contains the original FIAR data for all hardware. FIAR data are then transferred to, defined, and formatted in the LLD. Work is being done to create a web-based version of the LLD in order to increase accessibility to all of Johnson Space Center (JSC), which includes converting entries from Excel to the HTML format. FIARs related to the EMU have been completed in the Excel version, and now focus has shifted to expanding FIAR data in the LLD to include EVA tools and support hardware such as the Pistol Grip Tool (PGT) and the Battery Charger Module (BCM), while adding any recently closed EMU-related FIARs.

Matthews, Kevin M., Jr.↗

Experiment in Onboard Synthetic Aperture Radar Data Processing

Single event upsets (SEUs) are a threat to any computing system running on hardware that has not been physically radiation hardened. In addition to mandating the use of performance-limited, hardened heritage equipment, prior techniques for dealing with the SEU problem often involved hardware-based error detection and correction (EDAC). With limited computing resources, software- based EDAC, or any more elaborate recovery methods, were often not feasible. Synthetic aperture radars (SARs), when operated in the space environment, are interesting due to their relevance to NASAs objectives, but problematic in the sense of producing prodigious amounts of raw data. Prior implementations of the SAR data processing algorithm have been too slow, too computationally intensive, and require too much application memory for onboard execution to be a realistic option when using the type of heritage processing technology described above. This standard C-language implementation of SAR data processing is distributed over many cores of a Tilera Multicore Processor, and employs novel Radiation Hardening by Software (RHBS) techniques designed to protect the component processes (one per core) and their shared application memory from the sort of SEUs expected in the space environment. The source code includes calls to Tilera APIs, and a specialized Tilera compiler is required to produce a Tilera executable. The compiled application reads input data describing the position and orientation of a radar platform, as well as its radar-burst data, over time and writes out processed data in a form that is useful for analysis of the radar observations.

Holland, Matthew↗

Getting around Antarctica: New High-Resolution Mappings of the Grounded and Freely-Floating Boundaries of the Antarctic Ice Sheet Created for the International Polar Year

Two ice-dynamic transitions of the Antarctic ice sheet - the boundary of grounded ice features and the freely-floating boundary - are mapped at 15-m resolution by participants of the International Polar Year project ASAID using customized software combining Landsat-7 imagery and ICESat/GLAS laser altimetry. The grounded ice boundary is 53 610 km long; 74% abuts to floating ice shelves or outlet glaciers, 19% is adjacent to open or sea-ice covered ocean, and 7% of the boundary ice terminates on land. The freely-floating boundary, called here the hydrostatic line, is the most landward position on ice shelves that expresses the full amplitude of oscillating ocean tides. It extends 27 521 km and is discontinuous. Positional (one-sigma) accuracies of the grounded ice boundary vary an order of magnitude ranging from +/- 52m for the land and open-ocean terminating segments to +/- 502m for the outlet glaciers. The hydrostatic line is less well positioned with errors over 2 km. Elevations along each line are selected from 6 candidate digital elevation models based on their agreement with ICESat elevation values and surface shape inferred from the Landsat imagery. Elevations along the hydrostatic line are converted to ice thicknesses by applying a firn-correction factor and a flotation criterion. BEDMAP-compiled data and other airborne data are compared to the ASAID elevations and ice thicknesses to arrive at quantitative (one-sigma) uncertainties of surface elevations of +/-3.6, +/-9.6, +/-11.4, +/-30 and +/-100m for five ASAID-assigned confidence levels. Over one-half of the surface elevations along the grounded ice boundary and over one-third of the hydrostatic line elevations are ranked in the highest two confidence categories. A comparison between ASAID-calculated ice shelf thicknesses and BEDMAP-compiled data indicate a thin-ice bias of 41.2+/-71.3m for the ASAID ice thicknesses. The relationship between the seaward offset of the hydrostatic line from the grounded ice boundary only weakly matches a prediction based on beam theory. The mapped products along with the customized software to generate them and a variety of intermediate products are available from the National Snow and Ice Data Center.

Bindschadler, R.↗

Simulated Wake Characteristics Data for Closely Spaced Parallel Runway Operations Analysis

A simulation experiment was performed to generate and compile wake characteristics data relevant to the evaluation and feasibility analysis of closely spaced parallel runway (CSPR) operational concepts. While the experiment in this work is not tailored to any particular operational concept, the generated data applies to the broader class of CSPR concepts, where a trailing aircraft on a CSPR approach is required to stay ahead of the wake vortices generated by a lead aircraft on an adjacent CSPR. Data for wake age, circulation strength, and wake altitude change, at various lateral offset distances from the wake-generating lead aircraft approach path were compiled for a set of nine aircraft spanning the full range of FAA and ICAO wake classifications. A total of 54 scenarios were simulated to generate data related to key parameters that determine wake behavior. Of particular interest are wake age characteristics that can be used to evaluate both time- and distance- based in-trail separation concepts for all aircraft wake-class combinations. A simple first-order difference model was developed to enable the computation of wake parameter estimates for aircraft models having weight, wingspan and speed characteristics similar to those of the nine aircraft modeled in this work.

Guerreiro, Nelson M.↗

Energy and Water Management

Energy efficiency isn't just a good idea; it's a necessity, both for cost reasons and to meet federal regulatory requirements. First, rising energy unit costs continue to erode NASA's mission budget. NASA spent roughly $156M on facility energy in FY 2007. Although that represents less than one per cent of NASA's overall annual budget, the upward trend in energy costs concerns the agency. While NASA reduced consumption 13%, energy unit costs have risen 63%. Energy cost increases counteract the effects of energy conservation, which results in NASA buying less yet spending more. The second factor is federal energy legislation. The National Energy Conservation Policy Act, as amended by the Energy Policy Act of 2005, Executive Order (EO) 13423 (January, 2007), and the Energy Independence and Security Act (December, 2007), mandates energy/water conservation goals for all federal agencies, including NASA. There are also reporting requirements associated with this legislation. The Energy/Water Management Task was created to support NASA Headquarters Environmental Management Division (HO EMD) in meeting these requirements. With assistance from TEERM, HQ EMD compiled and submitted the NASA Annual Report to the Department of Energy FY 2007. The report contains information on how NASA is meeting federally mandated energy and water management goals. TEERM monitored input for timeliness, errors, and conformity to the new energy/water reporting guidelines and helped compile the information into the final report. TEERM also assists NASA Energy/Water Management with proposal and award calls, updates to the energy/water management database, and facilitating communication within the energy/water management community. TEERM is also supporting NASA and the Interagency Working Group (IWG) on Hydrogen and Fuel Cells. Established shortly after the President announced the Hydrogen Fuel Initiative in 2003, this IWG serves as the mechanism for collaboration among the Federal agencies involved in hydrogen-related research, development, and demonstration. TEERM developed a matrix showing all Hydrogen and Fuel Cell activities from the various NASA centers to be included in the Group's extensive hydrogen research taxonomy of past, present, and future hydrogen activities of the Federal government.

Valek, Susan E.↗

Outgassing Data for Selecting Spacecraft Materials

Outgassing data, derived from tests at 398 K (125 C) for 24 hours in vacuum as per ASTM E-595-90, have been compiled for numerous materials designed for spacecraft use. The data presented are the total mass loss (TML) and the collected volatile condensable materials (CVCM). The various materials are compiled by likely usage, and then in alphabetical order.

Campbell, William A.↗

Are Medications Involved in Vision and Intracrancial Pressure Changes Seen in Spaceflight?

The Food and Drug Association Adverse Event Reports (FDA AER) from 2009-2011 were used to create a database from millions of known and suspected medication-related adverse events among the general public. Vision changes, sometimes associated with intracranial pressure changes (VIIP), have been noted in some long duration crewmembers. Changes in vision and blood pressure (which can subsequently affect intracranial pressure) are fairly common side effects of medications. The purpose of this study was to explore the possibility of medication involvement in crew VIIP symptoms. Reports of suspected medication-related adverse events may be filed with the Food and Drug Administration (FDA) by medical professionals or consumers. Quarterly compilations of these reports are available for public download. Adverse Event Reporting System (AERS) reports from 1/1/2009- 6/30/2012 were downloaded and compiled into a searchable database for this study. Reports involving individuals under the age of 18 and older than 65 were excluded from this analysis. Case reports involving chronic diseases such as cancer, diabetes, multiple sclerosis and other serious conditions were also excluded. A scan of the medical literature for medication-related VIIP-like adverse events was used to create a list of suspect medications. These medications, as well as certain medications used frequently by ISS crew, were used to query the database. Queries for use of suspected medications were run, and the nature of the symptoms reported in those cases were tabulated. Symptoms searched in the FDA AERS were chosen to include the typical symptoms noted in crewmembers with VIIP. Vision symptoms searched were: visual acuity reduced, visual impairment, and vitreous floaters. Pressure changes included: abnormal sensation in eye, intracranial pressure increased, intraocular pressure increased, optic neuritis, optic neuropathy, and papilloedema. Limited demographic information is included with the FDA AERS; relevant data were also sorted by age and sex from each report. RESULTS Steroid-containing oral contraceptives had the highest number of reports associated with vision (n=166) and pressure symptoms (n=54). Corticosteroid-containing medications were also high; prednisone, for example, had 137 reports of vision issues and 79 of pressure issues. Pain relievers were also a medication class with vision and pressure-related adverse events reported. Common over-the-counter medications such as acetaminophen, aspirin and ibuprofen each had multiple reports for both vision and pressure symptoms. Antimicrobial medications ciprofloxacin and diflucan were also associated with a number of vision and pressure-related AERS. Unexpectedly, pseudoephedrine and promethazine were mentioned in fewer than 20 reports each over the 3.5 years of data examined. The FDA AERS represents a wealth of data, but there are several limitations to its use. The data are entered by the public or medical professionals, but are not checked for accuracy or completeness and may even be entered multiple times. The causal relationship between a particular adverse event and a particular medication is not tested. The cases represent a broad spectrum of demographics, occupations, and health histories, and thus do not model the astronaut population well. There is no information on the frequency of use of a medication for comparison purposes; it is not possible to assign a rate for any particular adverse event. Nonetheless, there are compelling trends. Use of corticosteroid-containing medications, pain relievers (even over-the-counter), and oral contraceptives were associated with higher numbers of vision- or intracranial pressure-related adverse events. In general, there were more vision problems than pressure problems reported. Certain medications that were once suspected of playing a role in the crew VIIP syndrome, namely pseudoephedrine and promethazine, were found to have extremely low numbers of VIIP-like AERS in the FDA data. However, crew use of corticosteroid-containing medications and pain relievers may warrant additional investigation

Faust, K. M.↗

A Guide to Axial-Flow Turbine Off-Design Computer Program AXOD2

A Users Guide for the axial flow turbine off-design computer program AXOD2 is composed in this paper. This Users Guide is supplementary to the original Users Manual of AXOD. Three notable contributions of AXOD2 to its predecessor AXOD, both in the context of the Guide or in the functionality of the code, are described and discussed in length. These are: 1) a rational representation of the mathematical principles applied, with concise descriptions of the formulas implemented in the actual coding. Their physical implications are addressed; 2) the creation and documentation of an Addendum Listing of input namelist-parameters unique to AXOD2, that differ from or are in addition to the original input-namelists given in the Manual of AXOD. Their usages are discussed; and 3) the institution of proper stoppages of the code execution, encoding termination messaging and error messages of the execution to AXOD2. These measures are to safe-guard the integrity of the code execution, such that a failure mode encountered during a case-study would not plunge the code execution into indefinite loop, or cause a blow-out of the program execution. Details on these are discussed and illustrated in this paper. Moreover, this computer program has since been reconstructed substantially. Standard FORTRAN Langue was instituted, and the code was formatted in Double Precision (REAL*8). As the result, the code is now suited for use in a local Desktop Computer Environment, is perfectly portable to any Operating System, and can be executed by any FORTRAN compiler equivalent to a FORTRAN 9095 compiler. AXOD2 will be available through NASA Glenn Research Center (GRC) Software Repository.

Gas Turbine Engines↗

The WIRED Survey. IV. New Dust Disks from the McCook & Sion White Dwarf Catalog

We have compiled photometric data from the Wide-field Infrared Survey Explorer All Sky Survey and other archival sources for the more than 2200 objects in the original McCook & Sion Catalog of Spectroscopically Identified White Dwarfs. We applied color-selection criteria to identify 28 targets whose infrared spectral energy distributions depart from the expectation for the white dwarf photosphere alone. Seven of these are previously known white dwarfs with circumstellar dust disks, five are known central stars of planetary nebulae, and six were excluded for being known binaries or having possible contamination of their infrared photometry. We fit white dwarf models to the spectral energy distributions of the remaining ten targets, and find seven new candidates with infrared excess suggesting the presence of a circumstellar dust disk. We compare the model dust disk properties for these new candidates with a comprehensive compilation of previously published parameters for known white dwarfs with dust disks. It is possible that the current census of white dwarfs with dust disks that produce an excess detectable at K-band and shorter wavelengths is close to complete for the entire sample of known WDs to the detection limits of existing near-IR all-sky surveys. The white dwarf dust disk candidates now being found using longer wavelength infrared data are drawn from a previously underrepresented region of parameter space, in which the dust disks are overall cooler, narrower in radial extent, and/or contain fewer emitting grains.

Dwarf↗

Global Characterization and Monitoring of Forest Cover Using Landsat Data: Opportunities and Challenges

The compilation of global Landsat data-sets and the ever-lowering costs of computing now make it feasible to monitor the Earth's land cover at Landsat resolutions of 30 m. In this article, we describe the methods to create global products of forest cover and cover change at Landsat resolutions. Nevertheless, there are many challenges in ensuring the creation of high-quality products. And we propose various ways in which the challenges can be overcome. Among the challenges are the need for atmospheric correction, incorrect calibration coefficients in some of the data-sets, the different phenologies between compilations, the need for terrain correction, the lack of consistent reference data for training and accuracy assessment, and the need for highly automated characterization and change detection. We propose and evaluate the creation and use of surface reflectance products, improved selection of scenes to reduce phenological differences, terrain illumination correction, automated training selection, and the use of information extraction procedures robust to errors in training data along with several other issues. At several stages we use Moderate Resolution Spectroradiometer data and products to assist our analysis. A global working prototype product of forest cover and forest cover change is included.

Global↗

NASA One-Dimensional Combustor Simulation--User Manual for S1D_ML

The work presented in this paper is to promote research leading to a closed-loop control system to actively suppress thermo-acoustic instabilities. To serve as a model for such a closed-loop control system, a one-dimensional combustor simulation composed using MATLAB software tools has been written. This MATLAB based process is similar to a precursor one-dimensional combustor simulation that was formatted as FORTRAN 77 source code. The previous simulation process requires modification to the FORTRAN 77 source code, compiling, and linking when creating a new combustor simulation executable file. The MATLAB based simulation does not require making changes to the source code, recompiling, or linking. Furthermore, the MATLAB based simulation can be run from script files within the MATLAB environment or with a compiled copy of the executable file running in the Command Prompt window without requiring a licensed copy of MATLAB. This report presents a general simulation overview. Details regarding how to setup and initiate a simulation are also presented. Finally, the post-processing section describes the two types of files created while running the simulation and it also includes simulation results for a default simulation included with the source code.

combustion↗

NASA GRC UAS Project - Communications Modeling and Simulation Development Status

The integration of Unmanned Aircraft Systems (UAS) in the National Airspace represents new operational concepts required in civil aviation. These new concepts are evolving as the nation moves toward the Next Generation Air Transportation System (NextGen) under the leadership of the Joint Planning and Development Office (JPDO), and through ongoing work by the Federal Aviation Administration (FAA). The desire and ability to fly UAS in the National Air Space (NAS) in the near term has increased dramatically, and this multi-agency effort to develop and implement a national plan to successfully address the challenges of UAS access to the NAS in a safe and timely manner is well underway. As part of the effort to integrate UAS in the National Airspace, NASA Glenn Research Center is currently involved with providing research into Communications systems and Communication system operations in order to assist with developing requirements for this implementation. In order to provide data and information regarding communication systems performance that will be necessary, NASA GRC is tasked with developing and executing plans for simulations of candidate future UAS command and control communications, in line with architectures and communications technologies being developed and or proposed by NASA and relevant aviation organizations (in particular, RTCA SC-203). The simulations and related analyses will provide insight into the ability of proposed communications technologies and system architectures to enable safe operation of UAS, meeting UAS in the NAS project goals (including performance requirements, scalability, and interoperability), and ultimately leading to a determination of the ability of NextGen communication systems to accommodate UAS. This presentation, compiled by the NASA GRC Modeling and Simulation team, will provide an update to this ongoing effort at NASA GRC as follow-up to the overview of the planned simulation effort presented at ICNS in 2013. The objective of presentation will be to describe the progress made in developing both a NAS-Wide simulation architecture application and the detailed radiocomm system models for this research, and will present interim data and information compiled in the process of developing these simulation capabilities to date.

Modeling and Simulation↗