SEARCH · Search NASA
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.
Lorentz invariant theory for relativistic gravity testing, deriving conservation laws and parameter constraints from parametrized post-Newtonian equations of motion
Metric theories of gravity are compiled and classified according to the types of gravitational fields they contain, and the modes of interaction among those fields. The gravitation theories considered are classified as (1) general relativity, (2) scalar-tensor theories, (3) conformally flat theories, and (4) stratified theories with conformally flat space slices. The post-Newtonian limit of each theory is constructed and its Parametrized Post-Newtonian (PPN) values are obtained by comparing it with Will's version of the formalism. Results obtained here, when combined with experimental data and with recent work by Nordtvedt and Will and by Ni, show that, of all theories thus far examined by our group, the only currently viable ones are general relativity, the Bergmann-Wagoner scalar-tensor theory and its special cases (Nordtvedt; Brans-Dicke-Jordan), and a recent, new vector-tensor theory by Nordtvedt, Hellings, and Will.
The post-Newtonian limit of Rosen's theory of gravity is evaluated and is shown to be identical to that of general relativity, except for the PPN parameter alpha sub 2, which is related to the difference in propagation speeds for gravitational and electromagnetic waves. Both the value of alpha sub 2 and the value of the Newtonian gravitational constant depend on the present cosmological structure of the Universe. If the cosmological structure has a specific but presumably special form, the Newtonian gravitational constant assumes its current value, alpha sub 2 is zero, the post-Newtonian limit of Rosen's theory is identical to that of general relativity--and standard solar system experiments cannot distinguish between the two theories.
The post-Newtonian limit of Rosen's theory of gravity is evaluated and is shown to be identical to that of general relativity, except for the post-Newtonian parameter alpha sub 2 (which is related to the difference in propagation speeds for gravitational and electromagnetic waves). Both the value of alpha sub 2 and the value of the Newtonian gravitational constant depend on the present cosmological structure of the Universe. If the cosmological structure has a specific (but presumably special) form, the Newtonian gravitational constant assumes its current value, alpha sub 2 is zero, the post-Newtonian limit of Rosen's theory is identical to that of general relativity - and standard solar system experiments cannot distinguish between the two theories.
America's electrical grid is currently undergoing a multi-billion dollar modernization effort aimed at producing a highly reliable critical national infrastructure for power - a Smart Grid. While the goals for the Smart Grid include upgrades to accommodate large quantities of clean, but transient, renewable energy and upgrades to provide customers with real-time pricing information, perhaps the most important objective is to create an electrical grid with a greatly increased robustness.
The Advanced Supersonic Parachute Inflation Research Experiment-2 (ASPIRE2) program is designed to test and qualify the supersonic parachute for the Mars entry, descent, and landing stage of the Mars Sample Return campaign. The ASPIRE2 test was planned for early 2026 and would have involved testing the parachute at deployments of Mach 2.1 and higher load conditions than previous Mars missions. The ASPIRE2 simulation builds upon a previous test framework from the ASPIRE tests in 2017-2018 used to qualify the Mars 2020 parachute, but due to new requirements, the modeling and simulation for ASPIRE2 has needed development and characterization of different sensitivities. This paper looks at the mission design as of mid-2024 and presents the trade space for qualifying the parachute in a dynamic environment.
The Advanced Supersonic Parachute Inflation Research Experiment-2 (ASPIRE2) program is designed to test and qualify the supersonic parachute for the Mars entry, descent, and landing stage of the Mars Sample Return campaign. The ASPIRE2 test was planned for early 2026 and would have involved testing the parachute at deployments of Mach 2.1 and higher load conditions than previous Mars missions. The ASPIRE2 simulation builds upon a previous test framework from the ASPIRE tests in 2017-2018 used to qualify the Mars 2020 parachute, but due to new requirements, the modeling and simulation for ASPIRE2 has needed development and characterization of different sensitivities. This paper looks at the mission design as of mid-2024 and presents the trade space for qualifying the parachute in a dynamic environment.
To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket and the Orion capsule, designed to take humans back to the moon in 2024, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the launch. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The messaging software of LCS is responsible for handling the various data types that can be sent between the hardware and software components of the LCS. Since this system is interacting with numerous devices, controllers, and viewports in real time, the distribution of data across the system must be fast, but also reliable and accurate. To verify the accuracy and reliability of the system, developers on the project have created a set of tests to be performed that covers all operations allowed by the system. Given the extensive Application Programming Interface(API) provided by the messaging software, these unit tests are rather time-consuming and costly (in terms of man-hours) to perform. Therefore, an automated testing framework is used to perform supplemental tests automatically when updates are made to the code base.
This tutorial will introduce Fortran developers to unit-testing and test-driven development (TDD) using pFUnit. As with other unit-testing frameworks, pFUnit, simplifies the process of writing, collecting, and executing tests while providing clear diagnostic messages for failing tests. pFUnit specifically targets the development of scientific-technical software written in Fortran and includes customized features such as: assertions for multi-dimensional arrays, distributed (MPI) and thread-based (OpenMP) parallellism, and flexible parameterized tests.These sessions will include numerous examples and hands-on exercises that gradually build in complexity. Attendees are expected to have working knowledge of F90, but familiarity with object-oriented syntax in F2003 and MPI will be of benefit for the more advanced examples. By the end of the tutorial the audience should feel comfortable in applying pFUnit within their own development environment.
Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.
This four part report evaluated the performance of high data rate transmission links using the ACTS satellite, and to provide a preparatory test framework for two of the space science applications that have been approved for tests and demonstrations as part of the overall ACTS program. The test plan will provide guidance and information necessary to find the optimal values of the transmission parameters and then apply these parameters to specific applications. The first part will focus on the satellite-to-earth link. The second part is a set of tests to study the performance of ATM on the ACTS channel. The third and fourth parts of the test plan will cover the space science applications, Global Climate Modeling and Keck Telescope Acquisition Modeling and Control.
This paper presents an analysis of the unit testing approach developed and used by the Core Flight Software (CFS) product line team at the NASA GSFC. The goal of the analysis is to understand, review, and reconunend strategies for improving the existing unit testing infrastructure as well as to capture lessons learned and best practices that can be used by other product line teams for their unit testing. The CFS unit testing framework is designed and implemented as a set of variation points, and thus testing support is built into the product line architecture. The analysis found that the CFS unit testing approach has many practical and good solutions that are worth considering when deciding how to design the testing architecture for a product line, which are documented in this paper along with some suggested innprovennents.
Test-Driven Development (TDD), a software development process that promises many advantages for developer productivity and software reliability, has become widely accepted among professional software engineers. As the name suggests, TDD practitioners alternate between writing short automated tests and producing code that passes those tests. Although this overly simplified description will undoubtedly sound prohibitively burdensome to many uninitiated developers, the advent of powerful unit-testing frameworks greatly reduces the effort required to produce and routinely execute suites of tests. By testimony, many developers find TDD to be addicting after only a few days of exposure, and find it unthinkable to return to previous practices.After a brief overview of the TDD process and my experience in applying the methodology for development activities at Goddard, I will delve more deeply into some of the challenges that are posed by numerical and scientific software as well as tools and implementation approaches that should address those challenges.
An overview of my experiences writing unit tests for various projects with a specific focus on my work unit testing core Flight System (cFS) applications. I recount some of the direct personal experiences I have had that showed me the utility of having done unit testing for my projects. Many of the tips, tricks and pitfalls encountered during my time writing unit tests for the cFS app, CF, are examined. I also compare and contrast my cFS unit testing development with that of a parallel project, in which I write unit tests using RSpec, a testing framework for the Ruby programming language. I impart my complete methodology behind the CF app unit testing effort and the rationale for why I did it that way. Then I give some ideas for how you can do your own unit testing for cFS applications. You will also learn about my hopes for how unit testing cFS applications can be done going forward from where we are now.
Emerging applications in artificial intelligence, such as driverless cars and autonomous aircraft promise to be more efficient, cheaper to operate, and always available. However, ensuring the safety of these systems remains a major challenge to their certification and adoption. These autonomous systems are expected to routinely make safety-critical decisions where failures can have serious consequences including loss of life and property. Testing and validation techniques aim to identify and diagnose potential failures before the system is deployed. However, finding failure scenarios in autonomous systems can be very challenging due to high-dimensional and continuous state spaces, interaction with large environments over many time steps, and the rarity of failures. This talk presents Adaptive Stress Testing (AST), a simulation-based testing framework for finding the most likely path to a failure event of a safety-critical system. The key idea of AST is that stress testing can be formulated as a Partially Observable Markov Decision Process (POMDP), which enables reinforcement learning techniques to be used for finding failure events. Reinforcement learning algorithms can efficiently explore the search space and have been shown to scale to very large systems. We present applications of AST to find failures in various safety-critical systems including the aircraft collision avoidance systems, autonomous cars, and small unmanned aerial vehicles.
This is a tutorial on AdaStress, a tool for finding and analyzing the likeliest failures in a simulated system under test. The presentation outlines the adaptive stress testing framework, provides a demonstration of use, and showcases several examples of failure detection in a complex real-world system.
The influence of the applied loading rate (dK/dt) on the environment-assisted cracking (EAC) behavior of sensitized AA5456-H116 in 0.6 M NaCl at applied potentials ranging from −800 to −900 mV_SCE is assessed via a rising-K testing framework. The applied potential strongly affects the dK/dt-dependence of EAC with results suggesting a minimal influence for potentials more positive than −830 mVSCE and a stronger dK/dt-dependence for potentials more negative than −830 mV_SCE. Crack growth rates measured using rising versus static K testing are compared, which demonstrates that rising K methods consistently yield conservative EAC metrics with increased efficiency.
Introduction: NASA’s VIPER mission presents a unique operational paradigm within the history of robotic spaceflight. The proximity of the Moon to the Earth and the terrain elements (surface characteristics, light/shadow dynamics, communication links) of the lunar South Polar landing site create unprecedented operational conditions between these two planetary bodies. Apollo era lunar science and exploration included humans in situ to operate instruments and assimilate observational inputs in real-time. Previous lunar orbital missions have worked to operational timescales, e.g., decisional timelines and communication exchanges, that were weeks in length. Mars rover missions have worked to operational timescales, e.g., decisional timelines and communication exchanges between Mars and Earth, that were hours, days, and weeks in length. In the case of the VIPER mission, our operational decisioning for rover driving and instrument commanding will be compressed to minute-scale timeframes. These operational conditions directly impact the manner and speed with which the VIPER Science Team (VST) is required to synthesize and analyze data and produce timely science-driven decisions throughout surface mission operations. The VST shall provide mission enhancing scientific input to guide rover traverse planning and drill site confirmation and selection throughout surface operations. Further, the VST input will be of vital importance to the mission’s ability to maximize science return and to meet broader NASA objectives for future lunar in-situ resource utilization (ISRU)and exploration activities. The VST co-located in the Mission Science Center (MSC) will be responsive to the tactical operational cadence of the Mission Operations Center (MOC) and will provide further strategic and Long-Term Planning (LTP) guidance to the mission. The VIPER Science Operations & Integration(SO&I)team has developed an architecture that is focused on the infusion of science-decisioning into the operational framework and execution cadence of VIPER. NASA analog research has played a significant role in the construction of the VIPER science operations systems. As an example, the SO&I team has led analog missions that have focused on bringing together expertise in the sciences (natural, applied and social) and in operations in service of learning how to build and hold together interdisciplinary work environments and what tools are needed to support high tempo, high intensity integrated decisioning. These experiences have provided an essential foundation of knowledge to the VIPER team. Those analogs that specifically influenced the VIPER science operations construct were identified through a process of comparative analysis to prioritize those that offered relevance in whole or in part, and those that did not. The analog research output that provided extensibility to the VIPER science operations architecture included remote teams of humans and robots in cooperation (synchronous and asynchronous) with simulated earthbound systems, engineering and science teams, and the integrated assembly of tools that supported scientific analysis and data synthesis and provided infrastructure for the remote testing framework. Analogs which included real-time data monitoring, synthesis, visualization and access in a democratized and operationalized manner were of particular interest to the development of the VIPER MSC toolset both in terms of the technology and the processes used to develop the supporting infrastructure. We anticipate that each subsequent mission to the lunar south pole, whether with robots or humans, will be able to optimize science and exploration return by evolving strategies to infuse real-time collaborative science-decisioning. Furthermore, these efforts will result in a foundation for science operations development in support of human-robotic exploration of deep space and Mars. NASA analogs can continue to provide the opportunity to prepare, test and iterate on the operational concepts and tools that will support these ever-expanding space exploration efforts. Our presentation will include an overview of the VIPER Science Operations & Integration development process and specifics on what aspects of analog research have had a significant impact on our work systems.