SEARCH · Engineering Papers

Results for “Python codes”

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.

105 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Deterministic Design Optimization of Structures in OpenMDAO Framework

Nonlinear programming algorithms play an important role in structural design optimization. Several such algorithms have been implemented in OpenMDAO framework developed at NASA Glenn Research Center (GRC). OpenMDAO is an open source engineering analysis framework, written in Python, for analyzing and solving Multi-Disciplinary Analysis and Optimization (MDAO) problems. It provides a number of solvers and optimizers, referred to as components and drivers, which users can leverage to build new tools and processes quickly and efficiently. Users may download, use, modify, and distribute the OpenMDAO software at no cost. This paper summarizes the process involved in analyzing and optimizing structural components by utilizing the framework s structural solvers and several gradient based optimizers along with a multi-objective genetic algorithm. For comparison purposes, the same structural components were analyzed and optimized using CometBoards, a NASA GRC developed code. The reliability and efficiency of the OpenMDAO framework was compared and reported in this report.

Coroneos, Rula M.↗

NASA NTRS2012

Deterministic Design Optimization of Structures in OpenMDAO Framework

Coroneos, Rula M.↗

NASA NTRS2017

A Dose of Reality: Radiation Analysis for Realistic Human Spacecraft

INTRODUCTION As with most computational analyses, a tradeoff exists between problem complexity, resource availability and response accuracy when modeling radiation transport from the source to a detector. The largest amount of analyst time for setting up an analysis is often spent ensuring that any simplifications made have minimal impact on the results. The vehicle shield geometry of interest is typically simplified from the original CAD design in order to reduce computation time, but this simplification requires the analyst to "re-draw" the geometry with a limited set of volumes in order to accommodate a specific radiation transport software package. The resulting low-fidelity geometry model cannot be shared with or compared to other radiation transport software packages, and the process can be error prone with increased model complexity. The work presented here demonstrates the use of the DAGMC (Direct Accelerated Geometry for Monte Carlo) Toolkit from the University of Wisconsin, to model the impacts of several space radiation sources on a CAD drawing of the US Lab module. METHODS The DAGMC toolkit workflow begins with the export of an existing CAD geometry from the native CAD to the ACIS format. The ACIS format file is then cleaned using SpaceClaim to remove small holes and component overlaps. Metadata is then assigned to the cleaned geometry file using CUBIT/Trelis from csimsoft (Registered Trademark). The DAGMC plugin script removes duplicate shared surfaces, facets the geometry to a specified tolerance, and ensures that the faceted geometry is water tight. This step also writes the material and scoring information to a standard input file format that the analyst can alter as desired prior to running the radiation transport program. The scoring results can be transformed, via python script, into a 3D format that is viewable in a standard graphics program. RESULTS The CAD model of the US Lab module of the International Space Station, inclusive of all the racks and components, was simplified to remove holes and volume overlaps. Problematic features within the drawing were also removed or repaired to prevent runtime issues. The cleaned drawing was then run through the DAGMC workflow to prepare for analysis. Pilot tests modeling transport of 1GeV proton and 800MeV/A oxygen sources show that reasonable results are converged upon in an acceptable amount of overall computation time from drawing preparation to data analysis. The FLUKA radiation transport code will next be used to model both a GCR and a trapped radiation source. These results will then be compared with measurements that have been made by the radiation instrumentation deployed inside the US Lab module. DISCUSSION Early analyses have indicated that the DAGMC workflow is a promising toolkit for running vehicle geometries of interest to NASA through multiple radiation transport codes. In addition, recent work has shown that a realistic human phantom, provided via a subcontract with the University of Florida, can be placed inside any vehicle geometry for a combinatorial analysis. This added functionality gives the user the ability to score various parameters at the organ level, and the results can then be used as input for cancer risk models.

Barzilla, J. E.↗

NASA NTRSDate not supplied

Py MILab: Capturing, Analyzing and Storing Test Data

Integrated Computational Materials Engineering (ICME) has recently received widespread attention due to its promises in reducing dependence on physical testing for engineering design by relying on simulation, reducing both time and cost to market for various applications. ICME however requires validated multiscale material models, which is heavily dependent on available test data with full material and test pedigree, including material processing, test and measurement equipment, raw data collection, and analysis methodology and results. Populating searchable information management systems with such rich data sets is often burdensome for data producers, resulting in a lack of findable data for modelers to validate and verify their models. To overcome these cultural barriers to ICME, NASA has developed of various database-integration toolsets that perform both data management activities within the organization’s best practices with additional functionality that relieves the effort of the data producer and promotes adoption of information management system. One such tool currently under development is Py MILab, an automatic framework for automatic capturing, analysis, maintenance, and storage of material test data. Py MILab uses a modular approach for capturing raw data, analyzing the data, and storing the data in a database, interfaced by neutral file structures, to promote plug-and-play capabilities for various analysis types. TMAnalysis is a Python-based tool that performs automatic data reduction and analysis of uniaxial thermomechanical test data. The TMAnalysis toolset can be implemented within the Analysis module of Py MILab, and thus requires a populated neutral file form the Raw Data Module of Py MILab and outputs a Analysis neutral file compatible with the Database Module of Py MILab. TMAnalysis is able to perform automatic segmentation of multistage tests and perform data analysis and reduction, including determination of point-wise properties in tension, compression, and shear, analysis of stress relaxation tests, creep analysis and zone identification, and combination of these stage types for tests with complex loading histories. The TMAnalysis code is accompanied with a graphical user interface (GUI) that allows users to easily analyze test data in bulk, verify the automatic, consistent analysis performed by the backend code, and edit stage segmentation if necessary before producing the output neutral files, ensuring data is properly analyzed and maintained with full traceability.

Data management↗

NASA NTRS2012

Mission Analysis, Operations, and Navigation Toolkit Environment (Monte) Version 040

Monte is a software set designed for use in mission design and spacecraft navigation operations. The system can process measurement data, design optimal trajectories and maneuvers, and do orbit determination, all in one application. For the first time, a single software set can be used for mission design and navigation operations. This eliminates problems due to different models and fidelities used in legacy mission design and navigation software. The unique features of Monte 040 include a blowdown thruster model for GRAIL (Gravity Recovery and Interior Laboratory) with associated pressure models, as well as an updated, optimalsearch capability (COSMIC) that facilitated mission design for ARTEMIS. Existing legacy software lacked the capabilities necessary for these two missions. There is also a mean orbital element propagator and an osculating to mean element converter that allows long-term orbital stability analysis for the first time in compiled code. The optimized trajectory search tool COSMIC allows users to place constraints and controls on their searches without any restrictions. Constraints may be user-defined and depend on trajectory information either forward or backwards in time. In addition, a long-term orbit stability analysis tool (morbiter) existed previously as a set of scripts on top of Monte. Monte is becoming the primary tool for navigation operations, a core competency at JPL. The mission design capabilities in Monte are becoming mature enough for use in project proposals as well as post-phase A mission design. Monte has three distinct advantages over existing software. First, it is being developed in a modern paradigm: object- oriented C++ and Python. Second, the software has been developed as a toolkit, which allows users to customize their own applications and allows the development team to implement requirements quickly, efficiently, and with minimal bugs. Finally, the software is managed in accordance with the CMMI (Capability Maturity Model Integration), where it has been ap praised at maturity level 3.

Sunseri, Richard F.↗

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↗

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

Developing a Multi-Lingual Autocoding Interface for the MAVERIC-II Dynamics Simulator

Simulation model development in certain high-level languages such as Python, MATLAB, or Simulink are unparalleled by their convenience and rapid turnover time. However, legacy simulation engines often depend on more traditional languages such as FORTRAN or C/C++. The NASA Marshall Aerospace Vehicle Representation in C version II (MAVERIC-II) is a modular, legacy-derived computer program used for high-fidelity, 6 degree-of-freedom (6dof) simulation for aerospace vehicle flights and analyses of guidance and control performance with built-in mathematical modeling of environmental effects such as wind, atmosphere, and gravity as well as dispersion capability for Monte Carlo analysis. MAVERIC-II is modular in the sense that each component software element of the simulation engine may be supplanted for a higher or lower fidelity version. The design flow of the development of these models is often performed in high-level languages as mentioned previously, which must then be translated into C or C++ code to be integrated into MAVERIC-II. We propose a unified method of autocoding and interfacing between several languages and MAVERIC-II, which may be generalized further to any type of 6dof simulation engine.

Mason Nixon↗

NASA NTRS2023

Easy, Scalable Subsetting of GEDI Point Clouds

The GEDI Subsetter, a Python tool developed for NASA’s Multi-mission Algorithm and Analysis Platform (MAAP), optimizes the accessibility and visualization of GEDI point clouds by enabling users to efficiently subset data in a convenient, scalable manner. Complex science data often requires users to learn new software skills and handle many large files. Handling and cleaning large data sets is tedious and error-prone. These challenges significantly impede analysis. One of the goals of NASA's MAAP is to provide a platform that lowers the barrier to conducting research and analysis at scale. When a group of MAAP users wanted to conduct above-ground biomass estimation using GEDI data, we found that their existing workflow for leveraging GEDI data suffered from the barriers mentioned above. Furthermore, their workflow did not scale easily beyond a small number of granules. We found that existing tools related to GEDI data retrieval and subsetting were too limiting, so the GEDI Subsetter was written to support MAAP users’ needs. Being able to run many subsetting jobs simultaneously in the MAAP, and parallelizing the code itself, has led to significant speed improvements in obtaining relevant data, reducing subsetting time from hours to minutes. MAAP users can now more quickly and easily obtain only the data relevant to their research, by choosing which GEDI collection they want to work with (L1A, L2A, L2B, or L4A), and how they want to subset it, by specifying an area of interest, a temporal range, and relevant attributes. This has significantly reduced the feedback loop for users, allowing them to much more quickly subset GEDI data and begin their analysis. Although the GEDI Subsetter originally targeted users of the MAAP, it is generalized such that it can also be used outside of the MAAP and includes a command-line interface for convenience. Furthermore, with minor modifications, it should be possible to use it with non-GEDI data as the general pattern should be applicable to other sparse/track-based sensors.

Charles Daniels↗

NASA NTRS2020

Multi Model Monte Carlo with Python (MXMCPy)

Multi Model Monte Carlo with Python (\mxmc {}) is a software package developed as a general capability for computing the statistics of outputs from an expensive, high-fidelity model by leveraging faster, low-fidelity models for speedup. Motivated by uncertainty propagation problems where classical Monte Carlo (MC) simulation is computationally intractable, various multi-model MC approaches have recently emerged that yield unbiased estimators with significantly reduced variance relative to MC for the same cost. These existing methods include multi-level Monte Carlo (MLMC), multi-fidelity Monte Carlo (MFMC), and approximate control variates (ACV). Given a fixed computational budget and a collection of models with varying cost/accuracy, each method seeks a sample allocation strategy across the models that results in an estimator with optimal variance reduction. \mxmc {} is a versatile tool that enables convenient access to many existing multi-model MC approaches within one modular and extensible package. With \mxmc {}, users can easily compare existing methods to determine the best choice for their particular problem, while developers have a basis for implementing and sharing new variance reduction approaches. This report introduces the \mxmc {} software, providing a summary of the problem-solving workflow for users as well as a brief overview of the code layout for developers.

Geoffrey F Bomarito↗

NASA NTRS2016

Intern Abstract for Spring 2016

The Human Interface Branch - EV3 - is evaluating Organic lighting-emitting diodes (OLEDs) as an upgrade for current displays on future spacecraft. OLEDs have many advantages over current displays. Conventional displays require constant backlighting which draws a lot of power, but with OLEDs they generate light themselves. OLEDs are lighter, and weight is always a concern with space launches. OLEDs also grant greater viewing angles. OLEDs have been in the commercial market for almost ten years now. What is not known is how they will perform in a space-like environment; specifically deep space far away from the Earth's magnetosphere. In this environment, the OLEDs can be expected to experience vacuum and galactic radiation. The intern's responsibility has been to prepare the OLED for a battery of tests. Unfortunately, it will not be ready for testing at the end of the internship. That being said much progress has been made: a) Developed procedures to safely disassemble the tablet. b) Inventoried and identified critical electronic components. c) 3D printed a testing apparatus. d) Wrote software in Python that will test the OLED screen while being radiated. e) Built circuits to restart the tablet and the test pattern, and ensure it doesn't fall asleep during radiation testing. f) Built enclosure that will house all of the electronics Also, the intern has been working on a way to take messages from a simulated Caution and Warnings system, process said messages into packets, send audio packets to a multicast address that audio boxes are listening to, and output spoken audio. Currently, Cautions and Warnings use a tone to alert crew members of a situation, and then crew members have to read through their checklists to determine what the tone means. In urgent situations, EV3 wants to deliver concise and specific alerts to the crew to facilitate any mitigation efforts on their part. Significant progress was made on this project: a) Open channel with the simulated Caution and Warning system to acquire messages. b) Configure audio boxes. c) Grab pre-recorded audio files. d) Packetize the audio stream. A third project that was assigned to implement LED indicator modules for an Omnibus project. The Omnibus project is investigating better ways designing lighting for the interior of spacecraft-both spacecraft lighting and avionics box status lighting indication. The current scheme contains too much of the blue light spectrum that disrupts the sleep cycle. The LED indicator modules are to simulate the indicators running on a spacecraft. Lighting data will be gathered by human factors personal and use in a model underdevelopment to model spacecraft lighting. Significant progress was made on this project: Designed circuit layout a) Tested LEDs at LETF. b) Created GUI for the indicators. c) Created code for the Arduino to run that will illuminate the indicator modules.

Gibson, William↗

NASA NTRS2015

Software Development: 3D Animations and Creating User Interfaces for Realistic Simulations

My fall 2015 semester was spent at the Lyndon B. Johnson Space Center working in the Integrated Graphics, Operations, and Analysis Laboratory (IGOAL). My first project was to create a video animation that could tell the story of OMICS. OMICS is a term being used in the field of biomedical science to describe the collective technologies that study biological systems, such as what makes up a cell and how it functions with other systems. In the IGOAL I used a large 23 inch Wacom monitor to draw storyboards, graphics, and line art animations. I used Blender as the 3D environment to sculpt, shape, cut or modify the several scenes and models for the video. A challenge creating this video was to take a term used in biomedical science and describe it in such a way that an 8th grade student can understand. I used a line art style because it would visually set the tone for what we thought was an educational style. In order to get a handle on the perspective and overall feel for the animation without overloading my workspace, I split up the 2 minute animation into several scenes. I used Blender's python scripting capabilities which allowed for the addition of plugins to add or modify tools. The scripts can also directly interact with the objects to create naturalistic patterns or movements. After collecting the rendered scenes, I used Blender's built-in video editing workspace to output the animation. My second project was to write software that emulates a physical system's interface. The interface was to simulate a boat, ROV, and winch system. Simulations are a time and cost effective way to test complicated data and provide training for operators without having to use expensive hardware. We created the virtual controls with 3-D Blender models and 2-D graphics, and then add functionality in C# using the Unity game engine. The Unity engine provides several essential behaviors of a simulator, such as the start and update functions. A framework for Unity, which was developed in the lab, provided a way to place the different widgets on the virtual console dock and have them resize correctly based on the window dimensions.. My task in this project was to create the controls and visualizations for the data coming in from the simulator for the boat portion of the project. I wrote a class for each control window to handle the functionality of that widget. I implemented 11 widgets that make up the ship portion of the simulator. The members of the lab were each masters of their craft and I'm glad I had the opportunity to learn from them. I learned to plan strategically so I could finish this project on time. I allotted time for storyboarding, development, and refinement. In regards to animating I learned to use modifiers like lattice, boolean and build deformers. I also learned how to animate with drivers, how to use the dope sheet, and how to use the graph editor. In coding I learned to limit the chances for bugs by privatizing functions that should be exclusive to their class. I learned how to use the GIT repository to commit, stash and pull the latest build. I learned a bit of everything because I had the chance to see the entire application development process from the artwork, to the implementation.

Gordillo, Orlando Enrique↗

NASA NTRSDate not supplied

Biomass Harmonization and SAR Analysis with the Multi-mission Algorithm and Analysis Platform (MAAP)

The Multi‐mission Algorithm and Analysis Platform (MAAP) is a collaborative effort between NASA and the European Space Agency (ESA) to support above ground biomass (AGB) research in an open science framework. MAAP brings together relevant data, algorithms, and computing capabilities in a common cloud environment to address the challenges of sharing and processing data from field, airborne and satellite measurements. MAAP was publicly released in October 2021, providing computing capabilities co-located with the data, a collaborative coding and analysis environment, and a set of interoperable tools and algorithms developed to support the estimation and visualization of data. MAAP has allowed scientists from both North America and Europe to collaborate on the generation and analysis/visualization of data derived from multiple, discipline-adjacent missions in an open, collaborative environment that has reached beyond traditional scientific investigation. MAAP has been used to support multiple scientific activities. To date, existing LiDAR data from multiple platforms has been calibrated with field measurements and combined for more comprehensive and accurate estimates of above ground biomass AGB; these LiDAR platforms include airborne (e.g. LVIS), the International Space Station (NASA’s Global Ecosystem Dynamics Investigation (GEDI), and satellites (e.g. ICESat-2). The current challenge is to effectively and seamlessly combine the aforementioned LiDAR-based data with new data sources such as P-band RADAR from ESA’s upcoming BIOMASS mission, existing ESA Sentinel-1 C-band SAR, and the 30 PB/yr of high cadence global coverage L-band SAR data from the upcoming NASA-ISRO SAR (NISAR) mission. Recent analysis using MAAP merged ICESat-2 and optical data (Harmonized Landsat Sentinel) produced the most comprehensively precise estimate of boreal-wide AGB to date. Another effort using MAAP is the production and open distribution of global comparisons of AGB map estimates, including from ICESat-2 and GEDI, to bolster stakeholder uptake for policy applications. These map estimates will feed into the Intergovernmental Panel on Climate Change (IPCC) database, likely aiding the next Global Carbon Stocktake of the UNFCCC. Furthermore, the biomass retrieval intercomparison exercise BRIX-2 could benefit from the MAAP providing standardized test cases (based on airborne campaign and spaceborne data) allowing the community to develop and apply retrieval algorithms based on these test cases, while forthcoming SAR data training curricula could also use the MAAP as a teaching and learning platform. The MAAP is meeting the challenges inherent in international, open science collaboration and large scale computing with a platform that is entirely open source and cloud native, using open standards for data access, manipulation, protocols, and formats. The MAAP data system consists of a dedicated data store whose data is indexed in an online catalog conforming to established metadata, application programmatic interfaces (APIs), and service interface standards, using an implementation of the open sourced NASA Common Metadata Repository. Federation of user identities allows users from either NASA or ESA to access and consume services from the other using a unified metadata catalog for the data utilized across the ESA and NASA MAAP platforms. Similarly, we are exploring how to increase interoperability to achieve a common approach to packaging, orchestrating and executing algorithms, with interoperable access to data for subsetting, fast browse, and cloud-optimized access, all using interoperable standards such as those from the Open Geospatial Consortium (OGC). Designed for interoperability, ESA and NASA utilize a common architecture for the software platform. It provides a cloud-based algorithm development environment (ADE) that enables scientists to develop algorithms collaboratively with access to the MAAP data catalog as well as other data archives. MAAP provides an Eclipse Che-based ADE supporting both Python and R languages, popular in this biomass community. Algorithms developed and containerized within the ADE can be deployed to run to thousands of computational nodes in the MAAP’s data processing system (DPS), dramatically speeding up processing and giving scientists a rapid, iterative turnaround of results. NASA’s implementation of the DPS is based on the Hybrid Science Data System (HySDS) framework, used by NASA flight projects to produce Earth science standard products.

cloud computing↗

NASA NTRS2018

GMI-IPS: Python Processing Software for Aircraft Campaigns

NASA's Atmospheric Tomography Mission (ATom) seeks to understand the impact of anthropogenic air pollution on gases in the Earth's atmosphere. Four flight campaigns are being deployed on a seasonal basis to establish a continuous global-scale data set intended to improve the representation of chemically reactive gases in global atmospheric chemistry models. The Global Modeling Initiative (GMI), is creating chemical transport simulations on a global scale for each of the ATom flight campaigns. To meet the computational demands required to translate the GMI simulation data to grids associated with the flights from the ATom campaigns, the GMI ICARTT Processing Software (GMI-IPS) has been developed and is providing key functionality for data processing and analysis in this ongoing effort. The GMI-IPS is written in Python and provides computational kernels for data interpolation and visualization tasks on GMI simulation data. A key feature of the GMI-IPS, is its ability to read ICARTT files, a text-based file format for airborne instrument data, and extract the required flight information that defines regional and temporal grid parameters associated with an ATom flight. Perhaps most importantly, the GMI-IPS creates ICARTT files containing GMI simulated data, which are used in collaboration with ATom instrument teams and other modeling groups. The initial main task of the GMI-IPS is to interpolate GMI model data to the finer temporal resolution (1-10 seconds) of a given flight. The model data includes basic fields such as temperature and pressure, but the main focus of this effort is to provide species concentrations of chemical gases for ATom flights. The software, which uses parallel computation techniques for data intensive tasks, linearly interpolates each of the model fields to the time resolution of the flight. The temporally interpolated data is then saved to disk, and is used to create additional derived quantities. In order to translate the GMI model data to the spatial grid of the flight path as defined by the pressure, latitude, and longitude points at each flight time record, a weighted average is then calculated from the nearest neighbors in two dimensions (latitude, longitude). Using SciPya's Regular Grid Interpolator, interpolation functions are generated for the GMI model grid and the calculated weighted averages. The flight path points are then extracted from the ATom ICARTT instrument file, and are sent to the multi-dimensional interpolating functions to generate GMI field quantities along the spatial path of the flight. The interpolated field quantities are then written to a ICARTT data file, which is stored for further manipulation. The GMI-IPS is aware of a generic ATom ICARTT header format, containing basic information for all flight campaigns. The GMI-IPS includes logic to edit metadata for the derived field quantities, as well as modify the generic header data such as processing dates and associated instrument files. The ICARTT interpolated data is then appended to the modified header data, and the ICARTT processing is complete for the given flight and ready for collaboration. The output ICARTT data adheres to the ICARTT file format standards V1.1. The visualization component of the GMI-IPS uses Matplotlib extensively and has several functions ranging in complexity. First, it creates a model background curtain for the flight (time versus model eta levels) with the interpolated flight data superimposed on the curtain. Secondly, it creates a time-series plot of the interpolated flight data. Lastly, the visualization component creates averaged 2D model slices (longitude versus latitude) with overlaid flight track circles at key pressure levels. The GMI-IPS consists of a handful of classes and supporting functionality that have been generalized to be compatible with any ICARTT file that adheres to the base class definition. The base class represents a generic ICARTT entry, only defining a single time entry and 3D spatial positioning parameters. Other classes inherit from this base class; several classes for input ICARTT instrument files, which contain the necessary flight positioning information as a basis for data processing, as well as other classes for output ICARTT files, which contain the interpolated model data. Utility classes provide functionality for routine procedures such as: comparing field names among ICARTT files, reading ICARTT entries from a data file and storing them in data structures, and returning a reduced spatial grid based on a collection of ICARTT entries. Although the GMI-IPS is compatible with GMI model data, it can be adapted with reasonable effort for any simulation that creates Hierarchical Data Format (HDF) files. The same can be said of its adaptability to ICARTT files outside of the context of the ATom mission. The GMI-IPS contains just under 30,000 lines of code, eight classes, and a dozen drivers and utility programs. It is maintained with GIT source code management and has been used to deliver processed GMI model data for the ATom campaigns that have taken place to date.

Damon, M. R.↗