SEARCH · Engineering Papers

Results for “Python software”

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.

SourceResearch connectionFrom yearThrough year

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

At least 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRS2023

PCLAM: a Python Module for Computing Surface Lineloads and Moments

Lineloads serve a unique and important role in aerodynamic database development as well as configuration design and analysis. A new software suite was constructed which can compute lineloads rapidly enough that the calculations can run in tandem with high-fidelity fluid flow solvers. This enables the calculation of iteration- or time-dependent lineloads, which have thus far been too computationally costly to create for complicated systems like launch vehicles. The suite is organized into a standalone Python module named PCLAM (PCLAM Computes Lineloads And Moments) which can be imported into other software with minimal restructuring by the user or developer. The computed lineloads are integrated with a $C^0$ numerical quality and exhibit the expected sensitivity to underlying grid resolution. Even at low grid and lineload resolutions, the computed lineloads were found to be in strong agreement with several analytical test cases.

sectional loads↗

NASA NTRS2019

An Automated Detection Methodology for Dry Well-Mixed Layers

The intense surface heating over arid land surfaces produces dry well-mixed layers (WML) via dry convection. These layers are characterized by nearly constant potential temperature and low, nearly constant water vapor mixing ratio. To further the study of dry WMLs, we created a detection methodology and supporting software to automate the identification and characterization of dry WMLs from multiple data sources including rawinsondes, remote sensing platforms, and model products. The software is a modular code written in Python, an open source language. Radiosondes from a network of synoptic stations in North Africa were used to develop and test the WML detection process. The detection involves an iterative decision tree that ingests a vertical profile from an input data file, performs a quality check for sufficient data density, and then searches upward through the column for successive points where the simultaneous changes in water vapor mixing ratio and potential temperature are less than the specified maxima. If points in the vertical profile meet the dry WML identification criteria, statistics are generated detailing the characteristics of each layer in the profile. At the end of the vertical profile analysis, there is an option to plot analyzed profiles in a variety of file formats. Initial results show that the detection methodology can be successfully applied across a wide variety of input data and North African environments and for all seasons. It is sensitive enough to identify dry WMLs from other types of isentropic phenomena such as subsidence layers and distinguish the current day’s dry WML from previous days.

Stephen D. Nicholls↗

NASA NTRS2016

A Flexible Method for Producing F.E.M. Analysis of Bone Using Open-Source Software

This project, performed in support of the NASA GRC Space Academy summer program, sought to develop an open-source workflow methodology that segmented medical image data, created a 3D model from the segmented data, and prepared the model for finite-element analysis. In an initial step, a technological survey evaluated the performance of various existing open-source software that claim to perform these tasks. However, the survey concluded that no single software exhibited the wide array of functionality required for the potential NASA application in the area of bone, muscle and bio fluidic studies. As a result, development of a series of Python scripts provided the bridging mechanism to address the shortcomings of the available open source tools. The implementation of the VTK library provided the most quick and effective means of segmenting regions of interest from the medical images; it allowed for the export of a 3D model by using the marching cubes algorithm to build a surface mesh. To facilitate the development of the model domain from this extracted information required a surface mesh to be processed in the open-source software packages Blender and Gmsh. The Preview program of the FEBio suite proved to be sufficient for volume filling the model with an unstructured mesh and preparing boundaries specifications for finite element analysis. To fully allow FEM modeling, an in house developed Python script allowed assignment of material properties on an element by element basis by performing a weighted interpolation of voxel intensity of the parent medical image correlated to published information of image intensity to material properties, such as ash density. A graphical user interface combined the Python scripts and other software into a user friendly interface. The work using Python scripts provides a potential alternative to expensive commercial software and inadequate, limited open-source freeware programs for the creation of 3D computational models. More work will be needed to validate this approach in creating finite-element models.

gravitational physiology↗

NASA NTRS2020

Dynamic IT Security Database and Analytics for Launch Control Systems Software

During the Summer 2020 session, I worked with intern Destani S. Van Arsdalen of EGS Software. Together, we co-created a tool to aid the dynamic investigation, updated over time,of the security compliance of LCS COTS and open source software. We originally planned touse spreadsheet software for management and analysis, but through this exploratoryproject, chose to use Python and JSON after receiving feedback on our project’s current anddesired capabilities at that time.At first, the project was solely designed to help on-board new COTS software, based on aquestionnaire that could be filled out for each software package. This, combined with usingthe spreadsheet application’s web-query capabilities to fetch information from the NVD,allowed presentation and analytics cells to automatically populate as elements of themanually-filled questionnaire changed. While this system was promising, we decided tochange technologies for a few reasons. In the spreadsheet, single cells could not hold complexdata like arrays and objects. The automatic population of cells and dynamic updates made itdifficult to manage and add new features. And finally, it had limited extensibility sinceadding new software required significant understanding of how both the spreadsheet wasconstructed, and the more obscure, proprietary scripting languages packaged with it.The pivot to a standard computer science database language of JSON, aided by thescripting capabilities of Python, greatly helped to improve the project’s functionality. First,and most importantly, the script’s import and analysis of database data is easilyreproducible. Additional data analysis can be modularly added without requiringmodification of the script and is capable of routine scheduling. The revised process can besplit into three parts. First, the conversion of LCS asset and software documentation into theJSON hierarchical database format. Second, the merging of this database with the NVD,forming a new data structure, using CPEs of the CVE object as a linking element betweenthem. And third, the automatically performed analytics and analysis of the combined data,in a modular and extensible format, to produce better informed business decisions. The outputted graphs, for example, are automatically generated by the Python script inconnection with the combined database. This allows updated graphs and any analytics to be re-rendered automatically following updates to the LCS’s initial asset documentation. Afinal report can then be programmatically and easily constructed from these sources to allow fully reproducible metrics for heavily evidenced risk management decisions.

it↗

NASA NTRS2013

Simulation of the Microwave Emission of Multi-layered Snowpacks Using the Dense Media Radiative Transfer Theory: the DMRT-ML Model

DMRT-ML is a physically based numerical model designed to compute the thermal microwave emission of a given snowpack. Its main application is the simulation of brightness temperatures at frequencies in the range 1-200 GHz similar to those acquired routinely by spacebased microwave radiometers. The model is based on the Dense Media Radiative Transfer (DMRT) theory for the computation of the snow scattering and extinction coefficients and on the Discrete Ordinate Method (DISORT) to numerically solve the radiative transfer equation. The snowpack is modeled as a stack of multiple horizontal snow layers and an optional underlying interface representing the soil or the bottom ice. The model handles both dry and wet snow conditions. Such a general design allows the model to account for a wide range of snow conditions. Hitherto, the model has been used to simulate the thermal emission of the deep firn on ice sheets, shallow snowpacks overlying soil in Arctic and Alpine regions, and overlying ice on the large icesheet margins and glaciers. DMRT-ML has thus been validated in three very different conditions: Antarctica, Barnes Ice Cap (Canada) and Canadian tundra. It has been recently used in conjunction with inverse methods to retrieve snow grain size from remote sensing data. The model is written in Fortran90 and available to the snow remote sensing community as an open-source software. A convenient user interface is provided in Python.

snowpacks↗

NASA NTRS2018

GMI-IPS: Processing & Visualization Software Used in ATom DC-8 Aircraft Studies

NASA's Atmospheric Tomography Mission (ATom) deployed in each of the four seasons during 2016-2018, the DC-8 aircraft in order to establish global-scale datasets intended to improve the representation of chemically reactive gases in global atmospheric chemistry models (ACMs). The Global Modeling Initiative (GMI) executed simulations for each ATom flight using the GMI Chemistry Transport Model (GMI-CTM) to provide species concentrations of chemical gases along the DC-8 flight transects. To solve the problem of translating the GMI-CTM simulation data to the unique spatial resolutions of each ATom flight, the GMI ICARTT Processing Software (GMI-IPS) was developed.The GMI-IPS is written in Python and provides data processing, flight extraction, and visualization support for aircraft research projects using ICARTT format, which is a standard format for airborne instrument data. Additionally, the GMI-IPS interpolates global gridded model data from Hierarchical Data Format (HDF) to ICARTT compatible flight transects. Software classes for instruments and collections provided by the ATom DC-8 aircraft such as MER10, MMS, etc. are derived from a common base class. Other functionality provided by the GMI-IPS are: deriving missing flight entries along a transect, reading ICARTT entries from file, and providing Python data structures for storing flight and model information, and more.The GMI-IPS is GIT source controlled, has approximately 30,000 lines of code, and supports parallelization across data collections. It delivered GMI-CTM data for more than forty distinct DC-8 aircraft flights that took place under ATom. The output ICARTT files adhere to format standard V1.1, and pass the scan utility provided by NASA LaRC Airborne Science Data for Atmospheric Composition. This presentation will include a software and methods overview, and results from ATom, including assessments using the GMI-CTM showing how well observations from ATom flight transects represent a broader region.

Damon, M. R.↗

NASA NTRS2026

Parametric-Based Heat Rejection Trade Study for Lunar and Martian Surface Operations

Establishing and maintaining a sustained presence on the lunar and/or Martian surfaces will require a diverse portfolio of surface elements (e.g., habitation, mobility, power generation, etc.). Many of these systems generate excess heat that must be rejected across a wide range of magnitudes, temperatures, and duty cycles and under variable environmental conditions. To identify the most promising heat rejection approaches for this diverse portfolio, a heat rejection trade study was conducted to evaluate the performance of different technology approaches across a spectrum of surface environments and heat-load requirements. The trade study consisted of three stages: (1) development of a parametric-based modeling framework, (2) creation of a database of heat rejection technologies, surface elements, and environmental conditions for the Moon and Mars, and (3) execution of a quantitative analysis of various heat rejection technologies across different operating conditions and surface elements. The modeling framework is developed in Python and Excel to prioritize small model size and hence low computational cost to enable large parametric sweeps while avoiding the reliance on proprietary software. Individual heat rejection processes are represented as simple Excel models, and a centralized Python script interfaces with the models to coordinate the parametric study. These simple sizing models were developed to take heat load requirements and environmental parameters as inputs and compute mass, power, and volume as outputs. Rather than assess each heat rejection technology separately for each surface element, a unified parametric space was developed to evaluate all technologies across all elements. This parametric space includes factors related to heat load (e.g., magnitude or temperature) and environment (e.g., surface temperature, sky temperature, solar flux). This effort generated a database containing information on over 60 heat rejection technologies and 30 surface elements. For each surface element, the expected heat rejection requirements were documented and analyzed to determine the most common needs shared across all elements. Environmental conditions at various lunar and Martian latitudes were also established for worst-case hot and worst-case cold scenarios. High-fidelity heat rejection models are currently under development. Preliminary trades between heat rejection technologies including radiators, venting technologies, convective coolers, and more have been conducted to identify promising options. This presentation will summarize the preliminary trade results and provide an overview and discussion of the expected heat loads and thermal environments for sustained surface operations on the Moon and Mars.

Heat Rejection↗

NASA NTRSDate not supplied

MLtool++ package for machine learning and its applications to materials data

We are developing Mltool++ package of software programs for machine learning (ML). Given the MLtool Python code, we create a faster C++ code with the potential for parallelization. We have extracted materials data from the literature. One dataset contains melting temperatures of stoichiometric 1:1 metallic compounds XZ, composed by elements X={Al, Ti, V, Cr, Zr, Nb, Mo, Hf, Ta, W} and Z={Co, Ni, Cu, Rh, Pd, Ag, Ir, Pt, Au}, and another contains solid-solid symmetry-breaking phase transition temperatures. We studied dependences of temperatures on composition, found several correlations, and parametrized them by analytical functions. Mltool++ package is generic and applicable to any tabulated numeric data.

Pierce M. Pettit↗

NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗

NASA NTRS2007

Information Metacatalog for a Grid

SWIM is a Software Information Metacatalog that gathers detailed information about the software components and packages installed on a grid resource. Information is currently gathered for Executable and Linking Format (ELF) executables and shared libraries, Java classes, shell scripts, and Perl and Python modules. SWIM is built on top of the POUR framework, which is described in the preceding article. SWIM consists of a set of Perl modules for extracting software information from a system, an XML schema defining the format of data that can be added by users, and a POUR XML configuration file that describes how these elements are used to generate periodic, on-demand, and user-specified information. Periodic software information is derived mainly from the package managers used on each system. SWIM collects information from native package managers in FreeBSD, Solaris, and IRX as well as the RPM, Perl, and Python package managers on multiple platforms. Because not all software is available, or installed in package form, SWIM also crawls the set of relevant paths from the File System Hierarchy Standard that defines the standard file system structure used by all major UNIX distributions. Using these two techniques, the vast majority of software installed on a system can be located. SWIM computes the same information gathered by the periodic routines for specific files on specific hosts, and locates software on a system given only its name and type.

Kolano, Paul↗

NASA NTRS2011

Multidisciplinary Tool for Systems Analysis of Planetary Entry, Descent, and Landing

Systems analysis of a planetary entry (SAPE), descent, and landing (EDL) is a multidisciplinary activity in nature. SAPE improves the performance of the systems analysis team by automating and streamlining the process, and this improvement can reduce the errors that stem from manual data transfer among discipline experts. SAPE is a multidisciplinary tool for systems analysis of planetary EDL for Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune, and Titan. It performs EDL systems analysis for any planet, operates cross-platform (i.e., Windows, Mac, and Linux operating systems), uses existing software components and open-source software to avoid software licensing issues, performs low-fidelity systems analysis in one hour on a computer that is comparable to an average laptop, and keeps discipline experts in the analysis loop. SAPE uses Python, a platform-independent, open-source language, for integration and for the user interface. Development has relied heavily on the object-oriented programming capabilities that are available in Python. Modules are provided to interface with commercial and government off-the-shelf software components (e.g., thermal protection systems and finite-element analysis). SAPE currently includes the following analysis modules: geometry, trajectory, aerodynamics, aerothermal, thermal protection system, and interface for structural sizing.

Samareh, Jamshid A.↗

NASA NTRS2018

Multidisciplinary Conceptual Design for Reduced-Emission Rotorcraft

Python-based wrappers for OpenMDAO are used to integrate disparate software for practical conceptual design of rotorcraft. The suite of tools which are connected thus far include aircraft sizing, comprehensive analysis, and parametric geometry. The tools are exercised to design aircraft with aggressive goals for emission reductions relative to fielded state-of-the-art rotorcraft. Several advanced reduced-emission rotorcraft are designed and analyzed, demonstrating the flexibility of the tools to consider a wide variety of potentially transformative vertical flight vehicles. To explore scale effects, aircraft have been sized for 5, 24, or 76 passengers in their design missions. Aircraft types evaluated include tiltrotor, single-main-rotor, coaxial, and side-by-side helicopters. Energy and drive systems modeled include Lithium-ion battery, hydrogen fuel cell, turboelectric hybrid, and turboshaft drive systems. Observations include the complex nature of the trade space for this simple problem, with many potential aircraft design and operational solutions for achieving significant emission reductions. Also interesting is that achieving greatly reduced emissions may not require exotic component technologies, but may be achieved with a dedicated design objective of reducing emissions.

Rotorcraf↗

NASA NTRSDate not supplied

Development of Physics-Based Transition Models for Unstructured-Mesh CFD Codes Using Deep Learning Models

Predicting transition locations over a vehicle surface is of fundamental importance for many engineering applications. With the transition information, the Reynolds-averaged Navier-Stokes (RANS) computations can turn on the turbulence model at the right locations so that drag, lift and other aerodynamic quantities can be accurately predicted. In contrast to the popularity of RANS-based transition modeling in which transition onset is governed by the turbulence equations, physics-based transition models that account for instability waves within the boundary layer, thus more compliant to flow physics, only gained more attention in recent years. This paper describes the development of a new physics-based transition model based on either the linear stability theory (LST) or parabolized stability equations (PSE). The model is designed to communicate with a structured or unstructured-mesh RANS solver back and forth in order to more accurately compute transition fronts over a three-dimensional body. In the developed model, the Python suite of interface codes in conjunction with the LASTRAC software can be executed autonomously to produce transition onset locations for a given laminar or RANS-computed transitional state. In addition, as a proof of concept, the tool set consists of a deep learning neural network model that has been designed and trained to predict instability wave evolutions inside the boundary layer for various instability wave mechanisms across a selected speed range. A machine-learned intelligent profile interpolation model has also been devised to enable reliable instability-wave spectra predictions with just a few points in the mean flow profiles.

Transition Modeling↗

NASA NTRS2023

Thermal Management System Modeling in the Heat Transport System Simulation (HeaTSSPy) Package

This paper describes the development of a thermal management system (TMS) concept design and analysis software package called Heat Transport System Simulation (HeaTSSPy). Built within Python using the OpenMDAO framework, HeaTSSPy can be used to size and optimize an active (using liquid/air heat exchangers) or passive (using finned heat sinks) TMS. The package makes use of modular TMS elements that allow for the creation of different system architectures and includes components such as heat sinks, heat exchangers, liquid pumps, fans, ducts, air inlets, air nozzles, and liquid pipes. Modeling methods for these components include a combination of physics-based analytical and empirical equations that relate component sizing criteria to system performance. The HeatSSPy heat sink methods are fully detailed within this paper, while the heat exchanger methods are described and referenced from previous work. This paper also uses high-fidelity simulation to validate two different methods of calculating thermal resistance using CFD results. Once the methods are fully described, the code is exercised to compare an active TMS with that of a passive TMS. Design criteria for this study include rejected heat, system altitude, Mach number, and ambient temperature. These criteria are used to develop a TMS system with estimated performance metrics such as weight, drag, and operational power. Results of this paper show the crossover point when a passive system begins to weigh more than an active system for a given heat rejection.

Thermal management system↗

NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗

NASA NTRS2019

Quantitative Comparison of Proprietary and Open-Source Georeferencing Tools for Use with Astronaut Photography

The Crew Earth Observations (CEO) Facility within the Earth Science and Remote Sensing Unit at NASA’s Johnson Space Center supports the acquisition, analysis, and curation of astronaut photography of Earth’s surface and atmosphere. Astronauts on the International Space Station (ISS) respond to requests from CEO to acquire imagery of scientific and education targets, to include high profile targets in response to activations from the International Charter for Space & Major Disasters (also known as the International Disaster Charter, or IDC) and NASA’s Disasters Program. CEO facilitates the acquisition of astronaut photography in response to IDC events and delivers georeferenced data products to the United States Geological Survey (USGS) for distribution to the disaster community. Using GeoRef, an internal web-based tool developed in collaboration with NASA’s Ames Research Center, CEO generates data packages of georeferenced imagery, uncertainty images for assessing control and tie point accuracy, and metadata documenting raw and processed data. Operational experience with the Georef software identified vulnerabilities to internal code and server errors that can significantly increase time of data production. As such, CEO developed a backup procedure in case the GeoRef software experiences front-end or back-end errors. A system using OSGEO’s open-source QGIS software combined with a semi-automated pipeline using the object-oriented Python language and the Geospatial Abstract Library for generating metadata is quantitatively compared to GeoRef’s data package for quality and productivity. Root Mean Square Error (RMSE) provides a standard measurement of data quality as it relates to ground error. Assessing RMSE measurements generated from georeferenced astronaut photographs acquired with different obliquity and focal length offers a comprehensive accuracy assessment of the software’s transformation algorithms. This assessment will indicate the software's ability to produce data products with the least ground-error or highest data quality regarding ground accuracy. In addition, a comparison of the software’s efficiency in generating a data package that includes georeferenced images, metadata, and uncertainty images for measuring tie/ground point error was performed. Initial results, based on the comparison of three nadir-facing astronaut photographs acquired with a 95mm focal length, reveal the QGIS-based system's average RMSE is 2.36 (pixels) suggesting its georectification system produces data products that meet and perhaps improve upon Georef solution's average RMSE of 32.99 (pixels). However, the QGIS system was unable to reproduce two unique Georef data products, uncertainty images for measuring tie and control point errors and a translated unwrapped image. In addition, the Georef software is designed to accept handheld camera pose information from a hardware component (Geosens) scheduled for deployment on the ISS in late 2018; this information is intended to provide increased accuracy and auto-registration capability for astronaut photographs. Future work is expected to determine the QGIS-based georectification system’s potential as an open-source alternative (and operational backup) to Georef for georeferencing the full range of resolutions and viewing angles unique to handheld digital camera imagery in support of ISS disaster response activities.

Jagge, Amy M.↗

NASA NTRS2021

Noise Exposure Maps of Urban Air Mobility

A noise exposure map is “a scaled geographic depiction of an airport, its noise exposure contours, noise-sensitive facilities, and land uses in the airport surrounding area” developed in accordance with the FAA’s 14 Code of Federal Regulation Part 150. This paper is the first to explore the applicability of airport noise exposure maps to Urban Air Mobility (UAM). The FAA’s airport noise compatibility planning program is first described. Then the applicability of the noise exposure map to Urban Air Mobility (UAM) is explored. Finally, new airspace infrastructure, including vertiport locations and UAM routes from NASA’s UAM engineering simulations, and local noise-sensitive facility locations and land use information were collected and processed to develop the noise exposure maps of UAM near the Dallas-Fort Worth area. The DNL noise contours resulting from a six-passenger electric quadrotor prototype vehicle are predicted using NASA’s AIRNOISEUAM software. The noise exposure maps of UAM are generated automatically using Python’s data analysis and visualization libraries. The results have applications for UAM’s noise compatibility planning, noise-reducing route planning, and vertiport location selection

Urban Air Mobility↗

NASA NTRS2021

Noise Exposure Map of Urban Air Mobility

Urban Air Mobility↗