Results for “Software Test Tool” — Page 68

NASA NTRS2011

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.↗

DOE OSTI2016

The Safe Guards Analysis Toolbox for Non-Proliferation Modeling

As nuclear technology becomes more widely available outside of nuclear weapon armed nations, the importance of preventing the illicit development of nuclear weapons has increased dramatically. A system of nuclear safeguards prevents proliferation; stopping the diversion of nuclear material from civilian facilities for the construction of nuclear weapons. These safeguards function through a combination of accountancy measurements that confirm the locations and amounts of nuclear material, and physical security at every nuclear facility. Safeguards Analysis (SGA) is a computational tool-kit developed using the MATLAB Simulink software suite that simulates a system of nuclear safeguards. The code allows users to examine current safeguards systems for weaknesses and to pinpoint the best locations for improvement. Developed as a modular framework, SGA does not directly model material flows, and relies on an outside code for this information. Instead, it represents a series of safeguards measurements that represent the values inspectors would see. Furthermore, SGA is designed to be modular in design, allowing the user to construct as complex or simple a model as needed: simulating an entire fuel-cycle comprising multiple facilities to a single measurement. SGA's use of outside codes for its material flow information makes it applicable to any model available to the user, as opposed to previous work that applied only to a single scenario. This paper discusses the initial development of SGA and the testing of these modules. The tests described in this paper demonstrate that the different pieces of SGA currently work as intended. Future work on the toolbox will develop and test SGA against a more realistic and complicated scenario using the various tools available in SGA. SGA currently has the pieces to perform analysis on safeguards systems, but needs to be tested on large, multi-MBA, systems to ensure the code is capable of handling such large models, to see the effect large models have on calculation speed, and if further work is needed to improve code efficiency. (authors)

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2010

Plots, Calculations and Graphics Tools (PCG2). Software Transfer Request Presentation

This slide presentation reviews the development of the Plots, Calculations and Graphics Tools (PCG2) system. PCG2 is an easy to use tool that provides a single user interface to view data in a pictorial, tabular or graphical format. It allows the user to view the same display and data in the Control Room, engineering office area, or remote sites. PCG2 supports extensive and regular engineering needs that are both planned and unplanned and it supports the ability to compare, contrast and perform ad hoc data mining over the entire domain of a program's test data.

Richardson, Marilou R.↗

DOE OSTI2024

Innovating the next generation of commercial smart building software

Nearly 30% of commercial building energy use is wasted due to equipment faults and HVAC controls problems. The result is increased emissions, compromised comfort and productivity, and less reliable coordination of building power needs with a clean grid. The energy impact alone represents $17 billion in potential savings. Today’s smart building software provides a robust solution to address these operational deficiencies. Energy management and information systems (EMIS) are saving up to 9% on average, with two-year paybacks. They are being incorporated into energy management processes, commissioning services, and utility programs. As effective as they are, two barriers prevent even deeper benefits; limited personnel to fix problems once they are identified, and the expense and time to manually implement changes in control systems. In partnership with the research community, the EMIS industry is developing new capabilities to overcome these barriers. Moving beyond siloed products for either fault detection and diagnostics, or optimal control, these new capabilities empower users to not only automatically identify faults, but also to push corrective action, and control improvements to their buildings. In this paper, several areas for enhancements are documented: ‘one-time’ correction of faults such as setpoints, schedules, and economizer lockouts; short-term active testing for automated proportional integral derivative (PID) loop tuning and functional testing; and continuous supervisory control for demand flexibility and year-round efficiency. Results are presented from a pair of partner implementations out of a dozen providers integrating these enhancements into their products, including field tests from across the country, and insights into operator acceptance and integration into operations and maintenance practices.

Casillas, Armando↗

DOE OSTI2023

Efforts to enhance reproducibility in a human performance research project

Background: Ensuring the validity of results from funded programs is a critical concern for agencies that sponsor biological research. In recent years, the open science movement has sought to promote reproducibility by encouraging sharing not only of finished manuscripts but also of data and code supporting their findings. While these innovations have lent support to third-party efforts to replicate calculations underlying key results in the scientific literature, fields of inquiry where privacy considerations or other sensitivities preclude the broad distribution of raw data or analysis may require a more targeted approach to promote the quality of research output. Methods: We describe efforts oriented toward this goal that were implemented in one human performance research program, Measuring Biological Aptitude, organized by the Defense Advanced Research Project Agency's Biological Technologies Office. Our team implemented a four-pronged independent verification and validation (IV&V) strategy including 1) a centralized data storage and exchange platform, 2) quality assurance and quality control (QA/QC) of data collection, 3) test and evaluation of performer models, and 4) an archival software and data repository. Results: Our IV&V plan was carried out with assistance from both the funding agency and participating teams of researchers. QA/QC of data acquisition aided in process improvement and the flagging of experimental errors. Holdout validation set tests provided an independent gauge of model performance. Conclusions: In circumstances that do not support a fully open approach to scientific criticism, standing up independent teams to cross-check and validate the results generated by primary investigators can be an important tool to promote reproducibility of results.

59 BASIC BIOLOGICAL SCIENCES↗

NASA NTRS1986

An Ada programming support environment

The toolset of an Ada Programming Support Environment (APSE) being developed at North American Aircraft Operations (NAAO) of Rockwell International, is described. The APSE is resident on three different hosts and must support developments for the hosts and for embedded targets. Tools and developed software must be freely portable between the hosts. The toolset includes the usual editors, compilers, linkers, debuggers, configuration magnagers, and documentation tools. Generally, these are being supplied by the host computer vendors. Other tools, for example, pretty printer, cross referencer, compilation order tool, and management tools were obtained from public-domain sources, are implemented in Ada and are being ported to the hosts. Several tools being implemented in-house are of interest, these include an Ada Design Language processor based on compilable Ada. A Standalone Test Environment Generator facilitates test tool construction and partially automates unit level testing. A Code Auditor/Static Analyzer permits the Ada programs to be evaluated against measures of quality. An Ada Comment Box Generator partially automates generation of header comment boxes.

Tyrrill, AL↗

NASA NTRS1994

Operations automation

This is truly the era of 'faster-better-cheaper' at the National Aeronautics and Space Administration/Jet Propulsion Laboratory (NASA/JPL). To continue JPL's primary mission of building and operating interplanetary spacecraft, all possible avenues are being explored in the search for better value for each dollar spent. A significant cost factor in any mission is the amount of manpower required to receive, decode, decommutate, and distribute spacecraft engineering and experiment data. The replacement of the many mission-unique data systems with the single Advanced Multimission Operations System (AMMOS) has already allowed for some manpower reduction. Now, we find that further economies are made possible by drastically reducing the number of human interventions required to perform the setup, data saving, station handover, processed data loading, and tear down activities that are associated with each spacecraft tracking pass. We have recently adapted three public domain tools to the AMMOS system which allow common elements to be scheduled and initialized without the normal human intervention. This is accomplished with a stored weekly event schedule. The manual entries and specialized scripts which had to be provided just prior to and during a pass are now triggered by the schedule to perform the functions unique to the upcoming pass. This combination of public domain software and the AMMOS system has been run in parallel with the flight operation in an online testing phase for six months. With this methodology, a savings of 11 man-years per year is projected with no increase in data loss or project risk. There are even greater savings to be gained as we learn other uses for this configuration.

Boreham, Charles Thomas↗

NASA NTRS2002

Program Model Checking as a New Trend

This paper introduces a special section of STTT (International Journal on Software Tools for Technology Transfer) containing a selection of papers that were presented at the 7th International SPIN workshop, Stanford, August 30 - September 1, 2000. The workshop was named SPIN Model Checking and Software Verification, with an emphasis on model checking of programs. The paper outlines the motivation for stressing software verification, rather than only design and model verification, by presenting the work done in the Automated Software Engineering group at NASA Ames Research Center within the last 5 years. This includes work in software model checking, testing like technologies and static analysis.

Havelund, Klaus↗

NASA NTRS2007

Community Coordinated Modeling Center Support of Operations: Real-Time Simulations and V & V.

In support of Operations Community Coordinated Modeling Center (CCMC) performing validation and verification of space weather models. To identify suitable metrics the CCMC focus on parameters most useful to operations that CCMC resident models can provide. The real time simulations carried out at CCMC are an essential tool to test model performance and stability by using input conditions that may occur in nature at any time. Since 2001, the magnetospheric MHD model BATSRUS has been run in real time using ACE real time data. CCMC staff developed an experimental real-time system that controls uploading of the real-time ACE data, monitors continuous model execution, initiates automatic recovery procedure in case of data gaps or hardware failures, synchronizes BATSRUS and FRC runs, and periodically runs IDL based visualization software.

Kuznetsova, M.↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

DOE OSTI2017

Human Factors Principles in Information Dashboard Design - 278

Refueling outages remain one of the largest opportunities for improving capacity factor and reducing costs available to commercial nuclear power plants. Although the nuclear industry has made steady improvement in outage optimization, each day of a refueling outage still represents an opportunity to save millions of dollars and each day an outage extends past its planned end date represents millions of dollars that may have been spent unnecessarily. Reducing planned outage duration or preventing outage extensions requires careful management of the outage schedule as well as constant oversight and monitoring of work completion during the outage execution. During a typical outage, there are typically more than 10,000 activities on the schedule that, if not managed efficiently, may cause expensive outage delays. Management of outages currently relies largely on paper-based resources and general-purpose office software. A typical method currently used to monitor work performance is a burn-down curve, where total remaining activities are plotted against the baseline schedule to track bulk work completion progress. While methods like this are useful, there is still considerable uncertainty during a typical outage whether bulk work progress is adequate and therefore a lot of management time is spent analyzing the situation on a daily basis. This paper is a case study of how new technology, in combination with established human-factors and user-centered design knowledge, can be used to support Outage Control Center (OCC) personnel decision making. In particular, we describe recent advances made in developing a framework for the design of visual outage information presentation, as well as an overview of the human factors principles that informed the development of the visualizations. To test the utility of advanced visual outage information presentation, an outage management dashboard software application was created as part of the Department of Energy's Advanced Outage Control Center project (AOCC). This dashboard is intended to present all the critical information an outage manager would need to understand the current status of a refueling outage. The dashboard presents the critical path, bulk work performance, key performance indicators, outage milestones and metrics relating current performance to historical performance. Additionally, the dashboard includes data analysis tools to allow outage managers to drill down into the underlying data to understand the drivers of the indicators. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

DOE OSTI2014

SU-E-J-124: FDG PET Metrics Analysis in the Context of An Adaptive PET Protocol for Node Positive Gynecologic Cancer Patients

Purpose: To compare PET extracted metrics and investigate the role of a gradient-based PET segmentation tool, PET Edge (MIM Software Inc., Cleveland, OH), in the context of an adaptive PET protocol for node positive gynecologic cancer patients. Methods: An IRB approved protocol enrolled women with gynecological, PET visible malignancies. A PET-CT was obtained for treatment planning prescribed to 45–50.4Gy with a 55– 70Gy boost to the PET positive nodes. An intra-treatment PET-CT was obtained between 30–36Gy, and all volumes re-contoured. Standard uptake values (SUVmax, SUVmean, SUVmedian) and GTV volumes were extracted from the clinician contoured GTVs on the pre- and intra-treament PET-CT for primaries and nodes and compared with a two tailed Wilcoxon signed-rank test. The differences between primary and node GTV volumes contoured in the treatment planning system and those volumes generated using PET Edge were also investigated. Bland-Altman plots were used to describe significant differences between the two contouring methods. Results: Thirteen women were enrolled in this study. The median baseline/intra-treatment primary (SUVmax, mean, median) were (30.5, 9.09, 7.83)/( 16.6, 4.35, 3.74), and nodes were (20.1, 4.64, 3.93)/( 6.78, 3.13, 3.26). The p values were all < 0.001. The clinical contours were all larger than the PET Edge generated ones, with mean difference of +20.6 ml for primary, and +23.5 ml for nodes. The Bland-Altman revealed changes between clinician/PET Edge contours to be mostly within the margins of the coefficient of variability. However, there was a proportional trend, i.e. the larger the GTV, the larger the clinical contours as compared to PET Edge contours. Conclusion: Primary and node SUV values taken from the intratreament PET-CT can be used to assess the disease response and to design an adaptive plan. The PET Edge tool can streamline the contouring process and lead to smaller, less user-dependent contours.

60 APPLIED LIFE SCIENCES↗

NASA NTRS2017

Wearable Biosensor Monitor to Support Autonomous Crew Health and Readiness to Perform

For future human exploration missions, NASA needs a health monitoring system composed of hardware that is compact, fully interoperable with an integrated data management system, and requires minimal consumables. Such a system will be achieved through the integration of small, easy to use biomedical sensors that will have the ability to measure, store and transmit physiological parameters during operational and ambulatory activity. Since 2012, the Canadian Space Agency (CSA) has been active in funding the development of wearable biomonitoring sensors. The Astroskin is the first prototype and consists of a shirt-based garment and headband with embedded sensors, and associated software and technology that measure vital signs, sleep quality and activity level of the wearer. NASA and CSA have been collaborating since 2014 to test and validate this system in a lab environment at Ames Research Center and more recently in the Human Exploration Research Analog (HERA) located at Johnson Spaceflight Center. Specific objectives of the HERA study were: 1) to assess the performance of the Astroskin biosensor system for long-term health monitoring (24-hours) capabilities and during exercise as a measure of crew fitness; 2) to obtain crew feedback on comfort and usability of the Astroskin system; 3) to demonstrate performance of Bluetooth communication during real-time transmission and for verification of data in this environment; and 4) to obtain baseline data for further development of algorithms and tools that facilitate decision support for diagnosing and monitoring of a sick or injured crewmember. HERA Campaign 3 included four missions (each 30-days in duration) with four crewmembers assigned to each mission. A total of 9 men and 7 women participated in the Astroskin evaluation that included continuous physiological monitoring (24-hours) on mission days MD-11, MD1 (high workload), MD15 (low workload), MD19, MD29, and MD+7. Mission days 19 and 29 also included 30 minutes of sub-maximal exercise on a cycle ergometer. Following each 24-hour monitoring session crew physiological data were downloaded to laptops and each crewmember completed a 28 question survey on their experiences with the Astroskin hardware and software. This presentation will focus on lessons learned from the HERA missions. Specifically it will address Astroskin system performance in terms of data loss and data quality (no comparison to lab standard devices), wireless communication with the onboard mobile device, crew usability and comfort, and future development of a next generation biomonitoring system.

crew fitness↗

NASA NTRS2004

Validation of CFD/Heat Transfer Software for Turbine Blade Analysis

I am an intern in the Turbine Branch of the Turbomachinery and Propulsion Systems Division. The division is primarily concerned with experimental and computational methods of calculating heat transfer effects of turbine blades during operation in jet engines and land-based power systems. These include modeling flow in internal cooling passages and film cooling, as well as calculating heat flux and peak temperatures to ensure safe and efficient operation. The branch is research-oriented, emphasizing the development of tools that may be used by gas turbine designers in industry. The branch has been developing a computational fluid dynamics (CFD) and heat transfer code called GlennHT to achieve the computational end of this analysis. The code was originally written in FORTRAN 77 and run on Silicon Graphics machines. However the code has been rewritten and compiled in FORTRAN 90 to take advantage of more modem computer memory systems. In addition the branch has made a switch in system architectures from SGI's to Linux PC's. The newly modified code therefore needs to be tested and validated. This is the primary goal of my internship. To validate the GlennHT code, it must be run using benchmark fluid mechanics and heat transfer test cases, for which there are either analytical solutions or widely accepted experimental data. From the solutions generated by the code, comparisons can be made to the correct solutions to establish the accuracy of the code. To design and create these test cases, there are many steps and programs that must be used. Before a test case can be run, pre-processing steps must be accomplished. These include generating a grid to describe the geometry, using a software package called GridPro. Also various files required by the GlennHT code must be created including a boundary condition file, a file for multi-processor computing, and a file to describe problem and algorithm parameters. A good deal of this internship will be to become familiar with these programs and the structure of the GlennHT code. Additional information is included in the original extended abstract.

Kiefer, Walter D.↗

NASA NTRS1994

HiRel: Hybrid Automated Reliability Predictor (HARP) integrated reliability tool system, (version 7.0). Volume 4: HARP Output (HARPO) graphics display user's guide

The Hybrid Automated Reliability Predictor (HARP) integrated Reliability (HiRel) tool system for reliability/availability prediction offers a toolbox of integrated reliability/availability programs that can be used to customize the user's application in a workstation or nonworkstation environment. HiRel consists of interactive graphical input/output programs and four reliability/availability modeling engines that provide analytical and simulative solutions to a wide host of highly reliable fault-tolerant system architectures and is also applicable to electronic systems in general. The tool system was designed at the outset to be compatible with most computing platforms and operating systems and some programs have been beta tested within the aerospace community for over 8 years. This document is a user's guide for the HiRel graphical postprocessor program HARPO (HARP Output). HARPO reads ASCII files generated by HARP. It provides an interactive plotting capability that can be used to display alternate model data for trade-off analyses. File data can also be imported to other commercial software programs.

Sproles, Darrell W.↗

NASA NTRS2016

Preliminary Computational Study for Future Tests in the NASA Ames 9 foot' x 7 foot Wind Tunnel

The NASA Advanced Air Vehicles Program, Commercial Supersonics Technology Project seeks to advance tools and techniques to make over-land supersonic flight feasible. In this study, preliminary computational results are presented for future tests in the NASA Ames 9 foot x 7 foot supersonic wind tunnel to be conducted in early 2016. Shock-plume interactions and their effect on pressure signature are examined for six model geometries. Near- field pressure signatures are assessed using the CFD code USM3D to model the proposed test geometries in free-air. Additionally, results obtained using the commercial grid generation software Pointwise Reigistered Trademark are compared to results using VGRID, the NASA Langley Research Center in-house mesh generation program.

Pearl, Jason M.↗