Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “RuN”

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

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

At least 1,405 records · Page 78

GEOS Atmospheric Model: Challenges at Exascale

The Goddard Earth Observing System (GEOS) model at NASA's Global Modeling and Assimilation Office (GMAO) is used to simulate the multi-scale variability of the Earth's weather and climate, and is used primarily to assimilate conventional and satellite-based observations for weather forecasting and reanalysis. In addition, assimilations coupled to an ocean model are used for longer-term forecasting (e.g., El Nino) on seasonal to interannual times-scales. The GMAO's research activities, including system development, focus on numerous time and space scales, as detailed on the GMAO website, where they are tabbed under five major themes: Weather Analysis and Prediction; Seasonal-Decadal Analysis and Prediction; Reanalysis; Global Mesoscale Modeling, and Observing System Science. A brief description of the GEOS systems can also be found at the GMAO website. GEOS executes as a collection of earth system components connected through the Earth System Modeling Framework (ESMF). The ESMF layer is supplemented with the MAPL (Modeling, Analysis, and Prediction Layer) software toolkit developed at the GMAO, which facilitates the organization of the computational components into a hierarchical architecture. GEOS systems run in parallel using a horizontal decomposition of the Earth's sphere into processing elements (PEs). Communication between PEs is primarily through a message passing framework, using the message passing interface (MPI), and through explicit use of node-level shared memory access via the SHMEM (Symmetric Hierarchical Memory access) protocol. Production GEOS weather prediction systems currently run at 12.5-kilometer horizontal resolution with 72 vertical levels decomposed into PEs associated with 5,400 MPI processes. Research GEOS systems run at resolutions as fine as 1.5 kilometers globally using as many as 30,000 MPI processes. Looking forward, these systems can be expected to see a 2 times increase in horizontal resolution every two to three years, as well as less frequent increases in vertical resolution. Coupling these resolution changes with increases in complexity, the computational demands on the GEOS production and research systems should easily increase 100-fold over the next five years. Currently, our 12.5 kilometer weather prediction system narrowly meets the time-to-solution demands of a near-real-time production system. Work is now in progress to take advantage of a hybrid MPI-OpenMP parallelism strategy, in an attempt to achieve a modest two-fold speed-up to accommodate an immediate demand due to increased scientific complexity and an increase in vertical resolution. Pursuing demands that require a 10- to 100-fold increases or more, however, would require a detailed exploration of the computational profile of GEOS, as well as targeted solutions using more advanced high-performance computing technologies. Increased computing demands of 100-fold will be required within five years based on anticipated changes in the GEOS production systems, increases of 1000-fold can be anticipated over the next ten years.

ESMF↗

Total Dust Deposition Flux During Precipitation in Toyama, Japan, in the Spring of 2009: A Sensitivity Analysis with the NASA GEOS-5 Model

We compared the observed total dust deposition fluxes during precipitation (TDP) mainly at Toyama in Japan during the period January - April 2009 with results available from four NASA GEOS-5 global model experiments. The modeled results were obtained from three previous experiments and carried out in one experiment, which were all driven by assimilated meteorology and simulating aerosol distributions for the time period. We focus mainly on the observations of two distinct TDP events, which were reported in Osada et al. (2011), at Toyama, Japan, in February (Event B) and March 2009 (Event C). Although all of our GEOS-5 simulations captured aspects of the observed TDP, we found that our low horizontal spatial resolution control experiment performed generally the worst. The other three experiments were run at a higher spatial resolution, with the first differing only in that respect from the control, the second adding imposed a prescribed corrected precipitation product, and the final experiment adding as well assimilation of aerosol optical depth based on MODIS observations. During Event C, the increased horizontal resolution could increase TDP with precipitation increase. There was no significant improvement, however, due to the imposition of the corrected precipitation product. The simulation that incorporated aerosol data assimilation performed was by far the best for this event, but even so could only reproduce less than half of the observed TDP despite the significantly increased atmospheric dust mass concentrations. All three of the high spatial resolution experiments had higher simulated precipitation at Toyama than was observed and that in the lower resolution control run. During Event B, the aerosol data assimilation run did not perform appreciably better than the other higher resolution simulations, suggesting that upstream conditions (i.e., upstream cloudiness), or vertical or horizontal misplacement of the dust plume did not allow for significant improvement in the simulated aerosol distributions. Furthermore, a detailed comparison of observed hourly precipitation and surface particulate mass concentration data suggests that the observed TDP during Event B was highly dependent on short periods of weak precipitation correlated with elevated dust surface concentrations, important details possibly not captured well in a current global model.

Dust; Wet deposition; Numerical modeling; Japan; P↗

Kepler Planet Detection Metrics: Per-Target Flux-Level Transit Injection Tests of TPS for Data Release 25

Quantifying the ability of a transiting planet survey to recover transit signals has commonly been accomplished through Monte-Carlo injection of transit signals into the observed data and subsequent running of the signal search algorithm (Gilliland et al., 2000; Weldrake et al., 2005; Burke et al., 2006). In order to characterize the performance of the Kepler pipeline (Twicken et al., 2016; Jenkins et al., 2017) on a sample of over 200,000 stars, two complementary injection and recovery tests are utilized:1. Injection of a single transit signal per target into the image or pixel-level data, hereafter referred to as pixel-level transit injection (PLTI), with subsequent processing through the Photometric Analysis (PA), Presearch Data Conditioning (PDC), Transiting Planet Search (TPS), and Data Validation (DV) modules of the Kepler pipeline. The PLTI quantification of the Kepler pipeline's completeness has been described previously by Christiansen et al. (2015, 2016); the completeness of the final SOC 9.3 Kepler pipeline acting on the Data Release 25 (DR25) light curves is described by Christiansen (2017).2. Injection of multiple transit signals per target into the normalized flux time series data with a subsequent transit search using a stream-lined version of the Transiting Planet Search (TPS) module. This test, hereafter referred to as flux-level transit injection (FLTI), is the subject of this document. By running a heavily modified version of TPS, FLTI is able to perform many injections on selected targets and determine in some detail which injected signals are recoverable. Significant numerical efficiency gains are enabled by precomputing the data conditioning steps at the onset of TPS and limiting the search parameter space (i.e., orbital period, transit duration, and ephemeris zero-point) to a small region around each injected transit signal.The PLTI test has the advantage that it follows transit signals through all processing steps of the Kepler pipeline, and the recovered signals can be further classified as planet candidates or false positives in the exact same manner as detections from the nominal (i.e., observed) pipeline run (Twicken et al., 2016, Thompson et al., in preparation). To date, the PLTI test has been the standard means of measuring pipeline completeness averaged over large samples of targets (Christiansen et al., 2015, 2016; Christiansen, 2017). However, since the PLTI test uses only one injection per target, it does not elucidate individual-target variations in pipeline completeness due to differences in stellar properties or astrophysical variability. Thus, we developed the FLTI test to provide a numerically efficient way to fully map individual targets and explore the performance of the pipeline in greater detail. The FLTI tests thereby allow a thorough validation of the pipeline completeness models (such as window function (Burke and Catanzarite, 2017a), detection efficiency (Burke Catanzarite, 2017b), etc.) across the spectrum of Kepler targets (i.e., various astrophysical phenomena and differences in instrumental noise). Tests during development of the FLTI capability revealed that there are significant target-to-target variations in the detection efficiency.

DR25↗

Program to Optimize Simulated Trajectories II (POST2) Surrogate Models for Mars Ascent Vehicle (MAV) Performance Assessment

The primary purpose of the multiPOST tool is to enable the execution of much larger sets of vehicle cases to allow for broader trade space exploration. However, this exploration is not achieved solely with the increased case throughput. The multiPOST tool is applied to carry out a Design of Experiments (DOE), which is a set of cases that have been structured to capture a maximum amount of information about the design space with minimal computational effort. The results of the DOE are then used to fit a surrogate model, ultimately enabling parametric design space exploration. The approach used for the MAV study includes both DOE and surrogate modeling. First, the primary design considerations for the vehicle were used to develop the variables and ranges for the multiPOST DOE. The final set of DOE variables were carefully selected in order to capture the desired vehicle trades and take into account any special considerations for surrogate modeling. Next, the DOE sets were executed through multiPOST. Following successful completion of the DOE cases, a manual verification trial was performed. The trial involved randomly selecting cases from the DOE set and running them by hand. The results from the human analyst's run and multiPOST were then compared to ensure that the automated runs were being executed properly. Completion of the verification trials was then followed by surrogate model fitting. After fits to the multiPOST data were successfully created, the surrogate models were used as a stand-in for POST2 to carry out the desired MAV trades. Using the surrogate models in lieu of POST2 allowed for visualization of vehicle sensitivities to the input variables as well as rapid evaluation of vehicle performance. Although the models introduce some error into the output of the trade study, they were very effective at identifying areas of interest within the trade space for further refinement by human analysts. The next section will cover all of the ground rules and assumptions associated with DOE setup and multiPOST execution. Section 3.1 gives the final DOE variables and ranges, while section 3.2 addresses the POST2 specific assumptions. The results of the verification trials are given in section 4. Section 5 gives the surrogate model fitting results, including the goodness-of-fit metrics for each fit. Finally, the MAV specific results are discussed in section 6.

Zwack, M. R.↗

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

McComas, David↗

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗

GEOS S2S-2_1 File Specification: GMAO Seasonal and Sub-Seasonal Forecast Output

The NASA GMAO seasonal (9 months) and subseasonal (45 days) forecasts are produced with the Goddard Earth Observing System (GEOS) Atmosphere-Ocean General Circulation Model and Data Assimilation System Version S2S-2_1. The new system replaces version S2S-1.0 described in Borovikov et al (2017), and includes upgrades to many components of the system. The atmospheric model includes an upgrade from a pre-MERRA-2 version running on a latitude-longitude grid at approx. 1 degree resolution to a current version running on a cubed sphere grid at approximately 1/2 degree resolution. The important developments are related to the dynamical core (Putman et al., 2011), the moist physics (''two-moment microphysics'' of Barahona et al., 2014) and the cryosphere (Cullather et al., 2014). As in the previous GMAO S2S system, the land model is that of Koster et al (2000). GMAO S2S-2_1 now includes the Goddard Chemistry Aerosol Radiation and Transport (GOCART, Colarco et al., 2010) single moment interactive aerosol model that includes predictive aerosols including dust, sea salt and several species of carbon and sulfate. The previous version of GMAO S2S specified aerosol amounts from climatology, which were used to inform the atmospheric radiation only. The ocean model includes an upgrade from MOM4 to MOM5 (Griffies 2012), and continues to be run on the tripolar grid at approximately 1/2 degree resolution in the tropics with 40 vertical levels. As in S2S-1.0, the sea ice model is from the Los Alamos Sea Ice model (CICE4, Hunke and Lipscomb 2010). The Ocean Data Assimilation System (ODAS) has been upgraded from the one described in Borovikov et al., 2017 to one that uses a modified version of the Penny, 2014 Local Ensemble Transform Kalman Filter (LETKF), and now assimilates along-track altimetry. The ODAS also does a nudging to MERRA-2 SST and sea ice boundary conditions. The atmospheric data assimilation fields used to constrain the atmosphere in the ODAS have been upgraded from MERRA to a MERRA-2 like system. The system is initialized using a MERRA-2-like atmospheric reanalysis (Gelaro et al. 2017) and the GMAO S2S-2_1 ocean analysis. Additional ensemble members for forecasts are produced with initial states at 5-day intervals, with additional members based on perturbations of the atmospheric and ocean states. Both subseasonal and seasonal forecasts are submitted to the National MultiModel Ensemble (NMME) project, and are part of the US/Canada multimodel seasonal forecasts (http://www.cpc.ncep.noaa.gov/products/NMME/). A large suite of retrospective forecasts (''hindcasts'') have been completed, and contribute to the calculation of the model's baseline climatology and drift, anomalies from which are the basis of the seasonal forecasts.

Seasonal Forecast↗

Progress Towards Integrating the Finite-Volume Cubed-Sphere (FV3) Dynamical Core Tangent Linear and Adjoint Models into JEDI

The Joint Effort for Data assimilation Integration (JEDI) -- led by the Joint Center for Satellite Data Assimilation (JCSDA) -- is an inter-organizational endeavor to develop a common framework for performing data assimilation. This extensive framework will ultimately provide solvers, observation operators, interpolation and model interfaces using object oriented modeling. Two partners involved in JEDI use or plan to use the Finite Volume Cubed-Sphere (FV3) dynamical core to produce weather forecasts; these are NASA's Global Modeling and Assimilation Office and NOAA's National Center for Environment Prediction. In this work we present an update on ongoing efforts to integrate the FV3 tangent linear and adjoint models into the prototype JEDI framework. We setup and run a simple cycled data assimilation experiment using 4DVAR on the cubed sphere grid and with the FV3 tangent linear and adjoint models. Development of the observation operators for JEDI is separately underway. Instead of using real observations a simplified set of simulated observations will be used. We discuss the steps required to bring the FV3 linearized model into the object oriented framework and consider what would be the computational requirements of running this configuration for an operational system. FV3 uses a small time-step to ensure that small scales are well resolved, however this presents design challenges when running 4DVAR with the adjoint. An approach to storing the FV3 model trajectory has been developed that maintains the flexibility of using automatic differentiation. We discuss how this approach is incorporated into the framework. Other important uses of adjoint models include computing observation impacts and singular vectors, we consider how these tools can be included in JEDI.

Holdaway, Daniel↗

Piloted Full-Motion Simulation with Simulink®

A recent experiment at NASA Ames Research Center’s Vertical Motion Simulator (VMS) successfully combined a real-time, human in-the-loop architecture with the flexibility of operating in the Simulink® graphical model-based engineering environment. The VMS is a large amplitude flight simulator designed to be adaptable to provide rapid integration and development of a wide variety of vehicles and support diverse aeronautical investigations. Math models are often programmed in Simulink. Typically, to run Simulink models in real time, they are converted to C code. However, the conversion and integration process can be time consuming and cumbersome. Thus, the VMS facility capabilities were expanded to allow a Simulink vehicle math model to run in the MathWorks’ MATLAB environment during a piloted full-motion simulation experiment. The MATLAB Simulink based approach to driving the VMS was found to decrease development time by allowing quick integration of math model changes and providing the ability to run the same version of the model on researcher’s desktop computers. This accomplishment demonstrated that the development ease of the graphical Simulink environment could be retained, while working within the real-time environment of the VMS architecture and maintaining the unique flexibility of the VMS.

hardware in-the-loop↗

Methodology and Application of HPC I/O Characterization with MPIProf and IOT

Combining the strengths of MPIProf and IOT, an efficient and systematic method is devised for I/O characterization at the per-job, per-rank, per-file and per-call levels of HPC programs running on the NASA Advanced Supercomputing Center. This method is applied to answer four I/O questions in this paper. A total of 13 MPI programs and 15 cases, ranging from 24 to 5968 ranks, are analyzed to establish the I/O landscape from answers to the four questions. Four of the 13 programs use MPI I/O and the behavior of their collective writes depends on the specific implementation of the MPI library used. The SGI MPT library, the prevailing MPI library for our systems, was found to gather small writes from a large number of ranks to perform larger writes by a small subset of collective buffering ranks. The number of collective buffering ranks invoked by MPT depends on the Lustre stripe count and the number of nodes used for the run. A demonstration of varying the stripe count to achieve double-digit speedup of one program's I/O was presented. Another program, which concurrently opens private files by all ranks and could potentially create a heavy load on the Lustre servers, was identified. The ability to systematically characterize I/O for a large number of programs running on a supercomputer, seek I/O optimization opportunity and identify programs that could cause a high load and instability on the filesystems is important for pursuing exascale in a real production environment.

Characterization↗

Supercomputing in the Age of Discovering Superearths, Earths and Exoplanet Systems

With the Kepler Mission, exoplanet science has entered the era of Big Data and has benefited tremendously from the availability of the NAS (NASA Advanced Supercomputing Division) Pleiades supercomputer. This presentation provides an overview of the history of exoplanet discoveries and highlights the key enabling technologies for Kepler. I provide an overview of the Kepler science pipeline and the algorithms used to analyze the data and detect transiting planets, all of which run routinely on the NAS Pleiades system. The presentation also provides a description of the Blender analysis program used to validate Kepler planet discoveries statistically, and the effort to discover exomoons lurking in Kepler data, both of which also run on Pleiades. Finally, I describe NASA's TESS (Transiting Exoplanet Survey Satellite) Mission, which leverages Kepler heritage to provide a science pipeline similar to that for Kepler and that will also run routinely on the NAS Pleiades supercomputer.

big data↗

Evaluation of Usability and Workload Associated with Paper Strips as Compared to Virtual Flight Strips Used for Ramp Operations

This paper describes a study comparing the use of paper strips with virtual flight strips depicted on a new user interface, the Ramp Traffic Console (RTC), designed for use by ramp controllers to be used in place of paper strips. A Human-In-the-Loop (HITL) experiment was performed as the fifth in a series of six HITL simulation studies designed to evaluate a pushback Decision Support Tool (DST) concept for Charlotte Douglas International Airport (CLT). Workload and usability were assessed in post-run and post-study questionnaires. In the RTC virtual flight strip condition, post-run questionnaire results show lower workload ratings across all aspects of workload; additionally a trend is found toward increased usability ratings. Post-study questionnaire results indicate a preference for RTC over paper strips. Additional research is suggested with more training runs and a greater number of participants to increase statistical power. It is also suggested that this new technology be re-evaluated as a part of the ATD-2 (Airspace Technology Demonstration 2) field testing activities.

Human Factors↗

Computational Performance of Progressive Damage Analysis of Composite Laminates using Abaqus/Explicit with 16 to 512 CPU Cores

The computational scaling performance of progressive damage analysis using Abaqus/ Explicit is evaluated and quantified using from 16 to 512 CPU cores. Several analyses were conducted on varying numbers of cores to determine the scalability of the code on five NASA high performance computing systems. Two finite element models representative of typical models used for progressive damage analysis of composite laminates were used. The results indicate a 10 to 15 times speed up scaling from 24 to 512 cores. The run times were modestly reduced with newer generations of CPU hardware. If the number of degrees of freedom is held constant with respect to the number of cores, the model size can be increased by a factor of 20, scaling from 16 to 512 cores, with the same run time. An empirical expression was derived relating run time, the number of cores, and the number of degrees of freedom. Analysis cost was examined in terms of software tokens and hardware utilization. Using additional cores reduces token usage since the computational performance increases more rapidly than the token requirement with increasing number of cores. The in- crease in hardware cost with increasing cores was found to be modest. Overall the results show relatively good scalability of the Abaqus/Explicit code on up to 512 cores.

Bergan, A. C.↗

Data Mining for Vortices on the Earth's Magnetosphere - Algorithm Application for Detection and Analysis

Unsteady processes in the solar wind– magnetosphere interaction, such as vortices developed at the magnetopause boundary by the Kelvin–Helmholtz instability, may contribute to the process of mass, momentum and energy transfer into the Earth’s magnetosphere. The research described in this paper validates an algorithm to automatically detect and characterize vortices based on velocity data from simulations. The vortex identification algorithm (VIA) systematically searches the 3-D velocity fields to identify critical points where the magnitude of the velocity vector vanishes. The velocity gradient tensor is computed and its invariants are used to assess vortex structure in the flow field. We use the Community Coordinated Modeling Center (CCMC) Runs on Request capability to create a series of model runs initialized from the conditions observed by the Cluster mission in the Hwang et al. (2011) analysis of Kelvin–Helmholtz vortices observed during southward interplanetary magnetic field (IMF) conditions. We analyze further the properties of the vortices found in the runs, including the velocity changes within their motion across the magnetosheath. We also demonstrate the potential of our tool to identify and characterize other transient features (e.g., flux transfer events, FTEs) with vortical internal structures. We find that the vortices are associated with flows on the magnetosheath side of the magnetopause that reach speeds greater than the solar wind speed at the bow shock.

Collado-Vega, Yaireska M.↗

Efficient On-Orbit Singularity-Free Geopotential Estimation

The complexity of the geopotential model can heavily impact the navigation error in satellites and spacecraft. Geopotential models of the accuracy needed for spaceflight are too complicated for flight computers to run at the rate needed by the navigation system. There are methods to make the geopotential model more efficient while maintaining the needed accuracy, which include: using an efficient method for the full model, propagating to avoid singularities, and running the full model at a low rate and propagating to the needed rate. These methods can decrease the computational requirement enough to be run by the flight computer at the rate required of the navigation system.

Amert, Joel↗

Piloted Full-Motion Simulation in Simulink®

A recent experiment at NASA Ames Research Center’s Vertical Motion Simulator (VMS) successfully combined a real-time, human in-the-loop architecture with the flexibility of operating in the Simulink® graphical model-based engineering environment. The VMS is a large amplitude flight simulator designed to be adaptable to provide rapid integration and development of a wide variety of vehicles and support diverse aeronautical investigations. Math models are often programmed in Simulink. Typically, to run Simulink models in real time, they are converted to C code. However, the conversion and integration process can be time consuming and cumbersome. Thus, the VMS facility capabilities were expanded to allow a Simulink vehicle math model to run in the MathWorks’ MATLAB environment during a piloted full-motion simulation experiment. The MATLAB Simulink based approach to driving the VMS was found to decrease development time by allowing quick integration of math model changes and providing the ability to run the same version of the model on researcher’s desktop computers. This accomplishment demonstrated that the development ease of the graphical Simulink environment could be retained, while working within the real-time environment of the VMS architecture and maintaining the unique flexibility of the VMS.

Lewis, Emily K.↗

R2U2: Tool Overview

R2U2 (Realizable, Responsive, Unobtrusive Unit) is an extensible framework for runtime System HealthManagement (SHM) of cyber-physical systems. R2U2 can be run in hardware (e.g., FPGAs), or software; can monitorhardware, software, or a combination of the two; and can analyze a range of different types of system requirementsduring runtime. An R2U2 requirement is specified utilizing a hierarchical combination of building blocks: temporal formula runtime observers (in LTL or MTL), Bayesian networks, sensor filters, and Boolean testers. Importantly, the framework is extensible; it is designed to enable definitions of new building blocks in combination with the core structure. Originally deployed on Unmanned Aerial Systems (UAS), R2U2 is designed to run on a wide range of embedded platforms, from autonomous systems like rovers, satellites, and robots, to human-assistive ground systems and cockpits. R2U2 is named after the requirements it satisfies; while the exact requirements vary by platform and mission, the ability to formally reason about realizability, responsiveness, and unobtrusiveness is necessary for flight certifiability, safety-critical system assurance, and achievement of technology readiness levels for target systems. Realizability ensures that R2U2 is suficiently expressive to encapsulate meaningful runtime requirements while maintaining adaptability to run on different platforms, transition between different mission stages, and update quickly between missions. Responsiveness entails continuously monitoring the system under test, real-time reasoning, reporting intermediate status, and as-early-as-possible requirements evaluations. Unobtrusiveness ensures compliance with the crucial properties of the target architecture: functionality, certifiability, timing, tolerances, cost, or other constraints.

Rozier, Kristin Y.↗

Simulation of AMVs for OSSEs

An algorithm to simulate locations of atmospheric motion vectors (AMVs) for use in observing system simulation experiments (OSSEs) is described and demonstrated. It is intended to obviate likely deficiencies in nature run data [standard meteorological parameters and aerosol tracers] if used to produce images for feature tracking. The algorithm employs probabilistic functions that are tuned based on distributions of real observations and histograms of nature run fields. For distinct observation types, the algorithm produces geographical and vertical distributions, time - mean counts, and typical spacings of simulated locations that are, at least, qualitatively similar to those of real observations and are associated with nature run cloud and water vapor fields. It thus appears suitable for generating realistic atmospheric motion vectors for use in observing system simulation experiments.

Errico, R. M.↗