Search NASA⌕ Search

SEARCH · Search NASA

Results for “Distributed Software Development”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 451 records · Page 25

Requirements, Verification, and Compliance (RVC) Database Tool

This paper describes the development, design, and implementation of the Requirements, Verification, and Compliance (RVC) database used on the International Space Welding Experiment (ISWE) project managed at Marshall Space Flight Center. The RVC is a systems engineer's tool for automating and managing the following information: requirements; requirements traceability; verification requirements; verification planning; verification success criteria; and compliance status. This information normally contained within documents (e.g. specifications, plans) is contained in an electronic database that allows the project team members to access, query, and status the requirements, verification, and compliance information from their individual desktop computers. Using commercial-off-the-shelf (COTS) database software that contains networking capabilities, the RVC was developed not only with cost savings in mind but primarily for the purpose of providing a more efficient and effective automated method of maintaining and distributing the systems engineering information. In addition, the RVC approach provides the systems engineer the capability to develop and tailor various reports containing the requirements, verification, and compliance information that meets the needs of the project team members. The automated approach of the RVC for capturing and distributing the information improves the productivity of the systems engineer by allowing that person to concentrate more on the job of developing good requirements and verification programs and not on the effort of being a "document developer".

Rainwater, Neil E., II↗

Information architecture for a planetary 'exploration web'

'Web services' is a common way of deploying distributed applications whose software components and data sources may be in different locations, formats, languages, etc. Although such collaboration is not utilized significantly in planetary exploration, we believe there is significant benefit in developing an architecture in which missions could leverage each others capabilities. We believe that an incremental deployment of such an architecture could significantly contribute to the evolution of increasingly capable, efficient, and even autonomous remote exploration.

middleware messaging IT infrastructure web service↗

Results of an Automated GPS Tracking System in Support of Topex/Poseidon and GPSMet

A fully automated near real-time GPS tracking system has been developed around JPL's GIPSY/OASIS II software. The system produces <25 cm (3D rms) GPS orbits and one-half nanosecond (15 cm) clock estimates. The process starts automatically when a favorable global distribution of ground data from the IGS network (International GPS Service for Geodynamics) becomes available. Ionospherically corrected phase and pseudorange data are optimally combined to remove satellite and ground receiver clock errors, including selective availability. After the GPS orbits are determined within the data arc, they are then propagated with empirically determined dynamic force models. Real-time <2 meter (3D rms) GPS orbits are always available. As a by-product of this process, other calibration estimates such as station clocks, troposphere estimates, and Earth orientation parameters are also produced. For daily arc fits, the process requires 7-8 hours of CPU time on an HP9000/735 workstation.

GPS↗

Initial Development of A Digital Twin Model for an Electrified Aircraft Propulsion Emulation Rig

In support of aviation fuel burn and emission reduction goals, NASA is pursing high-payoff research investments that promise to transform aviation. This includes investments in Electrified Aircraft Propulsion (EAP), which relies on the generation, storage, transmission, and use of electrical power for producing thrust and optimizing propulsion system efficiency. Multiple technology challenges must be addressed to unlock the full potential of EAP. This includes advances in propulsion controls, which will be vital for ensuring coordinated efficient operation of the complex integrated subsystems that comprise EAP architectures. To support EAP controls research, the NASA Glenn Research Center has developed the Hybrid Propulsion Emulation Rig (HyPER). The HyPER laboratory hardware includes shaft-mounted electric machines, power converters, power supplies, power distribution cables, and an energy storage device that can be reconfigured to represent a variety of EAP architectures. It also includes an integrated real-time computer system that hosts developed EAP control software and turbomachinery simulations. This enables the electrical system and rotating shafts of EAP designs to be implemented in actual hardware and integrated with turbomachinery simulations and system-level EAP control logic implemented in software. In this form, the HyPER laboratory provides a partially simulated, partially hardware-in-the-loop test environment enabling the initial development and evaluation of EAP control technology. A prerequisite for the development of EAP control designs is the availability of a system model that accurately reflects the operation of the electrical system hardware. To support this need, a digital twin model of the HyPER electrical system hardware is under development. This model is being coded in the MATLAB Simulink environment and uses the NASA-developed Electrical Modeling and Thermal Analysis Toolbox (EMTAT) to construct a digital twin framework. EMTAT contains generic electrical component building blocks that are simulated at turbomachinery timescales. Associated inputs and outputs allow the blocks to be combined to model complete electrical systems. The EMTAT blocks also contain adjustable internal maps and parameters that can be set to reflect the operation of a specific electrical component. For the HyPER digital twin, the settings of these EMTAT block internal maps and parameters is determined through machine learning approaches applied to characterization run data collected from the laboratory. During characterization runs the laboratory electrical system hardware is subjected to a full range of torque, speed, and power settings. Acquired data is then used to estimate EMTAT block parameters using a variety of machine learning techniques. The resulting digital twin model is found to match the operation of actual HyPER hardware with an accuracy suitable for control development purposes. It also holds promise for other applications including modeling the performance of HyPER laboratory reconfigurations and model-based anomaly detection. Planned follow-on work to automate post-processing of acquired laboratory data to update the HyPER digital twin model will also be presented and discussed.

Electrified Aircraft Propulsion↗

Countermeasure Evaluation and Validation Project (CEVP) Database Requirement Documentation

The initial focus of the project by the JSC laboratories will be to develop, test and implement a standardized complement of integrated physiological test (Integrated Testing Regimen, ITR) that will examine both system and intersystem function, and will be used to validate and certify candidate countermeasures. The ITR will consist of medical requirements (MRs) and non-MR core ITR tests, and countermeasure-specific testing. Non-MR and countermeasure-specific test data will be archived in a database specific to the CEVP. Development of a CEVP Database will be critical to documenting the progress of candidate countermeasures. The goal of this work is a fully functional software system that will integrate computer-based data collection and storage with secure, efficient, and practical distribution of that data over the Internet. This system will provide the foundation of a new level of interagency and international cooperation for scientific experimentation and research, providing intramural, international, and extramural collaboration through management and distribution of the CEVP data. The research performed this summer includes the first phase of the project. The first phase of the project is a requirements analysis. This analysis will identify the expected behavior of the system under normal conditions and abnormal conditions; that could affect the system's ability to produce this behavior; and the internal features in the system needed to reduce the risk of unexpected or unwanted behaviors. The second phase of this project have also performed in this summer. The second phase of project is the design of data entry screen and data retrieval screen for a working model of the Ground Data Database. The final report provided the requirements for the CEVP system in a variety of ways, so that both the development team and JSC technical management have a thorough understanding of how the system is expected to behave.

Shin, Sung Y.↗

Investigation of the effects of external current systems on the MAGSAT data utilizing grid cell modeling techniques

The feasibility of modeling magnetic fields due to certain electrical currents flowing in the Earth's ionosphere and magnetosphere was investigated. A method was devised to carry out forward modeling of the magnetic perturbations that arise from space currents. The procedure utilizes a linear current element representation of the distributed electrical currents. The finite thickness elements are combined into loops which are in turn combined into cells having their base in the ionosphere. In addition to the extensive field modeling, additional software was developed for the reduction and analysis of the MAGSAT data in terms of the external current effects. Direct comparisons between the models and the MAGSAT data are possible.

Klumpar, D. M.↗

The IRAS project organisation and mission operations

The project organisation of IRAS is described, showing the tasks assigned to each project group during post-launch operations. The satellite is described, emphasizing the detectors. In the task division, the role of the U.S. is to construct the telescope and survey instrument, launch the satellite, process final science data for the survey instrument, and provide certain standard satellite items. The Netherlands construct the spacecraft and three additional instruments, integrates and tests the overall satellite, and designs and participates in the development of the operational system. The U.K. provides the operational control center and primary tracking station, generates a system for preliminary science analysis of the survey data, provides housekeeping analysis software and science data distribution software, and staffs the control center operations. The teams involved in mission planning and operations, and their roles, are identified, and a block diagram of the operations organisation is presented.

Van Holtz, R. C.↗

A Facility and Architecture for Autonomy Research

Autonomy is a key enabling factor in the advancement of the remote robotic exploration. There is currently a large gap between autonomy software at the research level and software that is ready for insertion into near-term space missions. The Mission Simulation Facility (MST) will bridge this gap by providing a simulation framework and suite of simulation tools to support research in autonomy for remote exploration. This system will allow developers of autonomy software to test their models in a high-fidelity simulation and evaluate their system's performance against a set of integrated, standardized simulations. The Mission Simulation ToolKit (MST) uses a distributed architecture with a communication layer that is built on top of the standardized High Level Architecture (HLA). This architecture enables the use of existing high fidelity models, allows mixing simulation components from various computing platforms and enforces the use of a standardized high-level interface among components. The components needed to achieve a realistic simulation can be grouped into four categories: environment generation (terrain, environmental features), robotic platform behavior (robot dynamics), instrument models (camera/spectrometer/etc.), and data analysis. The MST will provide basic components in these areas but allows users to plug-in easily any refined model by means of a communication protocol. Finally, a description file defines the robot and environment parameters for easy configuration and ensures that all the simulation models share the same information.

Pisanich, Greg↗

Virtual Machine Language 2.1

VML (Virtual Machine Language) is an advanced computing environment that allows spacecraft to operate using mechanisms ranging from simple, time-oriented sequencing to advanced, multicomponent reactive systems. VML has developed in four evolutionary stages. VML 0 is a core execution capability providing multi-threaded command execution, integer data types, and rudimentary branching. VML 1 added named parameterized procedures, extensive polymorphism, data typing, branching, looping issuance of commands using run-time parameters, and named global variables. VML 2 added for loops, data verification, telemetry reaction, and an open flight adaptation architecture. VML 2.1 contains major advances in control flow capabilities for executable state machines. On the resource requirements front, VML 2.1 features a reduced memory footprint in order to fit more capability into modestly sized flight processors, and endian-neutral data access for compatibility with Intel little-endian processors. Sequence packaging has been improved with object-oriented programming constructs and the use of implicit (rather than explicit) time tags on statements. Sequence event detection has been significantly enhanced with multi-variable waiting, which allows a sequence to detect and react to conditions defined by complex expressions with multiple global variables. This multi-variable waiting serves as the basis for implementing parallel rule checking, which in turn, makes possible executable state machines. The new state machine feature in VML 2.1 allows the creation of sophisticated autonomous reactive systems without the need to develop expensive flight software. Users specify named states and transitions, along with the truth conditions required, before taking transitions. Transitions with the same signal name allow separate state machines to coordinate actions: the conditions distributed across all state machines necessary to arm a particular signal are evaluated, and once found true, that signal is raised. The selected signal then causes all identically named transitions in all present state machines to be taken simultaneously. VML 2.1 has relevance to all potential space missions, both manned and unmanned. It was under consideration for use on Orion.

Riedel, Joseph E.↗

Air Traffic Management-eXploration Testbed for Urban Air Mobility Research and Development

The presentation will describe the architecture, current capabilities and some future enhancements of the testbed that is being developed at the National Aeronautics and Space Administration (NASA) to enable benefit, impact, safety and cost assessments for accelerating the deployment of air traffic management concept and technologies in the national airspace system. The testbed will support analysis of operational feasibility of urban air mobility operations, a part of NASA's Air Traffic Management eXploration project, and provide the data needed by regulatory agencies charged with public safety. Introduction of concepts and technologies, especially new concepts and technologies, is difficult and often takes decades because of the inability to assess the operational impact of the interaction between the proposed concept and technology and operationally deployed systems in terms of system-wide safety, traffic flow efficiency, roles and workload of controllers and traffic managers, and impact on airlines and other operators. To overcome these limitations, the testbed is developing infrastructure to enable mathematical modeling, human-in-the-loop evaluations and testing with operational systems in a simulated environment. In addition to the difficulty of establishing communications between geographically distributed systems, downloading/installing software, and management of startup, error-handling and shutdown, a major impediment for conducting simulations and human-in-the-loop testing with operational systems is the tedious manual scenario generation process. Several of these difficulties have been addressed in the current state of the testbed. The testbed can be described in terms of the following elements (1) web-based frontend and backend, (2) Testbed Builder, (3) Data Distribution Service, (4) Component Library, (5) Simulation Management, and (6) Scenario Generation. The web-based frontend and backend enable the user to interact with the testbed for tasks such as composing a simulation, running a simulation and retrieving output data. The Testbed Builder application launched from the web frontend is a graphical user interface for the user to drag-and-drop and connect predefined blocks for composing a simulation/scenario generation task. The Builder writes a set of instructions for Simulation Management based on the links between the blocks and the block properties such as the component (executable) associated with a particular block. Management of the distributed simulation is accomplished by Execution and Component Managers. Execution Manager interprets the instructions provided by the Builder to instruct the Component Managers to download components from the Component Library to specified computers and to start them up. Once started, the components communicate with each other by publishing messages and subscribing to messages that are delivered by the Data Distribution Service. The Scenario Generation capability can be used for creating traffic scenarios for Multi-Aircraft Control System, which has been used extensively at NASA for human-in-the-loop-based concept evaluations. The presentation will provide a testbed enabled example scenario of Multi-Aircraft Control System based simulation in which the urban air mobility pilot using the conflict detection and resolution system would interact with the air traffic controllers for resolving conflicts with other aircraft during terminal area operations.

Testbed↗

Air Traffic Management-eXploration Testbed for Urban Air Mobility Research and Development

The presentation will describe the architecture, current capabilities and some future enhancements of the testbed that is being developed at the National Aeronautics and Space Administration (NASA) to enable benefit, impact, safety and cost assessments for accelerating the deployment of air traffic management concept and technologies in the national airspace system. The testbed will support analysis of operational feasibility of urban air mobility operations, a part of NASA's Air Traffic Management eXploration project, and provide the data needed by regulatory agencies charged with public safety. Introduction of concepts and technologies, especially new concepts and technologies, is difficult and often takes decades because of the inability to assess the operational impact of the interaction between the proposed concept and technology and operationally deployed systems in terms of system-wide safety, traffic flow efficiency, roles and workload of controllers and traffic managers, and impact on airlines and other operators. To overcome these limitations, the testbed is developing infrastructure to enable mathematical modeling, human-in-the-loop evaluations and testing with operational systems in a simulated environment. In addition to the difficulty of establishing communications between geographically distributed systems, downloading/installing software, and management of startup, error-handling and shutdown, a major impediment for conducting simulations and human-in-the-loop testing with operational systems is the tedious manual scenario generation process. Several of these difficulties have been addressed in the current state of the testbed. The testbed can be described in terms of the following elements- (1) web-based frontend and backend, (2) Testbed Builder, (3) Data Distribution Service, (4) Component Library, (5) Simulation Management, and (6) Scenario Generation. The web-based frontend and backend enable the user to interact with the testbed for tasks such as composing a simulation, running a simulation and retrieving output data. The Testbed Builder application launched from the web frontend is a graphical user interface for the user to drag-and-drop and connect predefined blocks for composing a simulation/scenario generation task. The Builder writes a set of instructions for Simulation Management based on the links between the blocks and the block properties such as the component (executable) associated with a particular block. Management of the distributed simulation is accomplished by Execution and Component Managers. Execution Manager interprets the instructions provided by the Builder to instruct the Component Managers to download components from the Component Library to specified computers and to start them up. Once started, the components communicate with each other by publishing messages and subscribing to messages that are delivered by the Data Distribution Service. The Scenario Generation capability can be used for creating traffic scenarios for Multi-Aircraft Control System, which has been used extensively at NASA for human-in-the-loop-based concept evaluations. The presentation will provide a testbed enabled example scenario of Multi-Aircraft Control System based simulation in which the urban air mobility pilot using the conflict detection and resolution system would interact with the air traffic controllers for resolving conflicts with other aircraft during terminal area operations.

Simulation↗

A Distributed Hierarchical Framework for Autonomous Spacecraft Control

Future human space missions for exploring beyond low Earth orbit are in the conceptual design stage. One such mission describes a habitat in cis-lunar orbit that is visited by crew periodically, others describe missions to Mars. These missions have one important thing in common: the need for autonomy on the spacecraft. This need stems from the latency and bandwidth constraints on communications between the vehicle and ground control. A variable amount of autonomy may be necessary whether the spacecraft has crew on board or not. Spacecraft are complex systems that are engineered as a collection of subsystems. These subsystems work together to control the overall state of the spacecraft. As such, solutions that increase the autonomy of the spacecraft (called autonomous functions) should respect both the independence and interconnectedness of the spacecraft subsystems. This distributed and hierarchical approach to system monitoring and control is a key idea in the Modular Autonomous Systems Technology (MAST) framework. The MAST framework enables a component-based architecture that provides interfaces and structure to developing autonomous technologies. The framework enforces a distributed, hierarchical architecture for autonomous control systems across subsystems, systems, elements, and vehicles. An example autonomous system was implemented in this framework and tested using realistic spacecraft software and hardware simulations. This paper will discuss the framework, tests conducted, results, and future work.

Badger, Julia M.↗

Object-oriented Tools for Distributed Computing

Distributed computing systems are proliferating, owing to the availability of powerful, affordable microcomputers and inexpensive communication networks. A critical problem in developing such systems is getting application programs to interact with one another across a computer network. Remote interprogram connectivity is particularly challenging across heterogeneous environments, where applications run on different kinds of computers and operating systems. NetWorks! (trademark) is an innovative software product that provides an object-oriented messaging solution to these problems. This paper describes the design and functionality of NetWorks! and illustrates how it is being used to build complex distributed applications for NASA and in the commercial sector.

Adler, Richard M.↗

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara↗

Microbial Communities in Microgravity: Simulation in Lab and on the Computer

Microorganisms grow differently in spaceflight than they do on Earth. While much remains unexplained about how microgravity affects microbial growth, one dominant hypothesis is that the lack of density-driven convection in the liquid growth environment makes mixing diffusion-limited, and therefore slower. This is supported by evidence that individual microbial strains experience starvation and acid stress in microgravity. However, if it is true, then microgravity would also have measurable effects on microbes in mixed communities, because many interspecies interactions involve the exchange of soluble metabolites through the medium (cross-feeding). Specifically, cooperative cross-feeding communities would grow more slowly in microgravity, and cooperation would be less stable on evolutionary timescales. Here we describe our efforts to test this hypothesis by simulating microgravity in silico and in the lab, using a model system of Eschericia coli and Salmonella enterica that grow only when they can exchange methionine and acetate. We created CAMDLES (CFD-DEM Artificial Microgravity Developments for Living Ecosystem Simulation) as an extension of CFDEM®coupling software, to carry out computational modeling of biological flows, growth, and mass transfer in microgravity and also in laboratory artificial microgravity devices (rotating wall vessels, RWV). Using CAMDLES, we found distinct differences in growth rates between RWV and true microgravity, and we were able to identify several features, such as spatial distribution, biofilm formation, and product yield parameters, that influence the degree to which RWV growth recapitulates microgravity growth. In addition, we report on the development of a laboratory system for monitoring growth rates and species ratios of the community in RWVs, using fluorescent strains. Pairing CAMDLES with the laboratory model system allows us to generate quantitative predictions about the effects of spaceflight on organisms that will be essential to sustaining human space exploration in the long term.

microbiology↗

ICEG2D: An Integrated Software Package for Automated Prediction of Flow Fields for Single-Element Airfoils with Ice Accretion

An integrated software package, ICEG2D, was developed to automate computational fluid dynamics (CFD) simulations for single-element airfoils with ice accretion. ICEG2D is designed to automatically perform three primary functions: (1) generating a grid-ready, surface definition based on the geometrical characteristics of the iced airfoil surface, (2) generating a high-quality grid using the generated surface point distribution, and (3) generating the input and restart files needed to run the general purpose CFD solver NPARC. ICEG2D can be executed in batch mode using a script file or in an interactive mode by entering directives from a command line. This report summarizes activities completed in the first year of a three-year research and development program to address issues related to CFD simulations for aircraft components with ice accretion. Specifically, this document describes the technology employed in the software, the installation procedure, and a description of the operation of the software package. Validation of the geometry and grid generation modules of ICEG2D is also discussed.

Thompson, David S.↗

Stochastic Reduced Order Models with Python (SROMPy)

Stochastic Reduced Order Models with Python (SROMPy) is a software package developed to enable user-friendly utilization of the stochastic reduced order model (SROM) approach for uncertainty quantification. A SROM is a low dimensional, discrete approximation to a random quantity that enables efficient and non-intrusive stochastic computations. With SROMPy, a user can easily generate a SROM to approximate a random variable or vector described by several different types of probability distributions using the Python programming language. Once a SROM is constructed, the software can be used to propagate uncertainty through a user-defined computational model to estimate statistics of a given quantity of interest. This report is meant to introduce the SROMPy module and brie y demonstrate its capabilities. A simple example of a spring-mass system with a random input is included to illustrate the practicality of the SROM approach to uncertainty quantification and relative ease of applying it with SROMPy. The example includes a comparison with a solution obtained using classical Monte Carlo simulation, demonstrating the similarities and advantages of using the SROM approach.

Warner, James E.↗