Search NASA⌕ Search

SEARCH · Search NASA

Results for “checking”

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 397 records · Page 22
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink (R)

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the vali-dation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aero-space Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and as-cent. The GLASS framework utilizes the off-the-shelf Mathworks ® Simscape Multibody® toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparisons demonstrate that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check cases and verifies the GLASS core framework dynamics and the correct implementation of the check case scenario models.

6-Dof↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the validation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aerospace Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and ascent. The GLASS framework utilizes the off-the-shelf Mathworks (R) Simscape (TM) Multibody (TM) toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparison demonstrates that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check-cases and verify the GLASS core framework dynamics and the implementation of the check case scenario models.

6-Dof↗
DOE OSTI2021

Address-based filtering for load/store speculation

Address-based filtering for load/store speculation includes maintaining a filtering table including table entries associated with ranges of addresses; in response to receiving an ordering check triggering transaction, querying the filtering table using a target address of the ordering check triggering transaction to determine if an instruction dependent upon the ordering check triggering transaction has previously been generated a physical address; and in response to determining that the filtering table lacks an indication that the instruction dependent upon the ordering check triggering transaction has previously been generated a physical address, bypassing a lookup operation in an ordering violation memory structure to determine whether the instruction dependent upon the ordering check triggering transaction is currently in-flight.

Kalamatianos, John↗
DOE OSTI2023

Address-based filtering for load/store speculation

Address-based filtering for load/store speculation includes maintaining a filtering table including table entries associated with ranges of addresses; in response to receiving an ordering check triggering transaction, querying the filtering table using a target address of the ordering check triggering transaction to determine if an instruction dependent upon the ordering check triggering transaction has previously been generated a physical address; and in response to determining that the filtering table lacks an indication that the instruction dependent upon the ordering check triggering transaction has previously been generated a physical address, bypassing a lookup operation in an ordering violation memory structure to determine whether the instruction dependent upon the ordering check triggering transaction is currently in-flight.

Kalamatianos, John↗
DOE OSTI2021

Initial plant community responses to hardwood control treatments in restoration of remnant longleaf pine (Pinus palustris) woodlands

Changes in land use over the past century have contributed to substantial losses of longleaf pine (Pinus palustris) woodlands in the southeastern USA and replacement with higher density, mixed pine and hardwood stands that suppress understory development and limit application of prescribed fire. To increase understanding of limiting factors and identify potential approaches for restoring longleaf pine woodlands, we studied in this work initial availability of light and soil water and 2-year (2018–2019) plant community responses after controlling overstory hardwoods in five remnant longleaf pine woodlands having no evidence of previous agriculture at the Savannah River Site near Aiken, SC, USA. Seven hardwood control treatments and a non-treated check were compared in a randomized compete block experiment: cutting, cutting + shredding of logging residues, stem injection with imazapyr herbicide, cutting + basal spray with imazapyr herbicide, cutting + basal spray with triclopyr herbicide, cutting + directed foliar spray with a mixture of glyphosate and imazapyr herbicides, and cutting + broadcast foliar spray with the same herbicide mixture. In the year prior to hardwood cutting (2016), understory light availability averaged 23% of full sun. Throughout the year of treatment installation (2017), average soil water content (SWC) was below permanent wilting point (5.5% SWC) where overstory hardwoods were retained; whereas, it was above wilting point (7.5%) where they had been cut. Thus, combined effects of shade and root competition from overstory hardwoods probably limited cover of herbaceous species in the non-treated check. In the 2 years following treatment, hardwood survival averaged > 99%, 62%, 42% and < 1% for the non-treated check, cutting, shredding, and herbicide treatments, respectively. Relative to the non-treated check, herbaceous species richness was increased by shredding, stem injection, basal spray, or directed foliar treatments; herbaceous cover was increased by basal spray or directed foliar treatments; and woody cover was decreased by directed or broadcast foliar treatments. The directed foliar spray was the most effective treatment for achieving many of the desired understory characteristics of a longleaf pine woodland, including a diverse understory dominated by herbaceous vegetation capable of supporting periodic prescribed fires. Although the imazapyr basal spray treatment increased cover of remnant woodland indicator species, none of the treatments increased richness of this species group, suggesting that restoration of native species composition will be expedited by enrichment seedings or plantings.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2021

Consistency testing for robust phase estimation

In this work, we present an extension to the robust phase estimation protocol, which can identify incorrect results that would otherwise lie outside the expected statistical range. Robust phase estimation is increasingly a method of choice for applications such as estimating the effective process parameters of noisy hardware, but its robustness is dependent on the noise satisfying certain threshold assumptions. We provide consistency checks that can indicate when those thresholds have been violated, which can be difficult or impossible to test directly. We test these consistency checks for several common noise models, and identify two possible checks with high accuracy in locating the point in a robust phase estimation run at which further estimates should not be trusted. One of these checks may be chosen based on resource availability, or they can be used together in order to provide additional verification.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗
DOE OSTI2020

Sierra/SolidMechanics Verification Report

This document presents the Sierra/SolidMechanics (Sierra/SM) verification plan. This plan centers on the tests in the Sierra/SM verification test suite, a subset of which are documented in the Sierra/SM Verification Tests Manual. Most of these tests are run nightly with the Sierra/SM code suite, and the results of the tests are checked against analytic solutions. For each of the tests presented in the Verification Tests Manual, the test setup, a description of the analytic solution, and comparison of the Sierra/SM code results to the analytic solution is provided. Mesh convergence is also checked on a nightly basis for several of these tests. This verification plan discusses these various types of tests and what they mean for Sierra/SM verification. Many other activities also contribute to Sierra/SM quality. These address code and solution quality and range from low-level unit tests, run nightly, up to full-fidelity acceptance tests, used to verify release stability. This acceptance test suite checks that new versions of Sierra/SM continue to yield the same answers for high-resolution analyst problems. Further code quality measures include an extensive suite of intermediate-size regression tests and automated nightly code quality checks. While these additional activities do not fall under a strict definition of verification, they greatly add to the quality, stability, and reliability of Sierra/SM, and are discussed here as well.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1988

Solutions to time variant problems of real-time expert systems

Real-time expert systems for monitoring and control are driven by input data which changes with time. One of the subtle problems of this field is the propagation of time variant problems from rule to rule. This propagation problem is even complicated under a multiprogramming environment where the expert system may issue test commands to the system to get data and to access time consuming devices to retrieve data for concurrent reasoning. Two approaches are used to handle the flood of input data. Snapshots can be taken to freeze the system from time to time. The expert system treats the system as a stationary one and traces changes by comparing consecutive snapshots. In the other approach, when an input is available, the rules associated with it are evaluated. For both approaches, if the premise condition of a fired rule is changed to being false, the downstream rules should be deactivated. If the status change is due to disappearance of a transient problem, actions taken by the fired downstream rules which are no longer true may need to be undone. If a downstream rule is being evaluated, it should not be fired. Three mechanisms for solving this problem are discussed: tracing, backward checking, and censor setting. In the forward tracing mechanism, when the premise conditions of a fired rule become false, the premise conditions of downstream rules which have been fired or are being evaluated due to the firing of that rule are reevaluated. A tree with its root at the rule being deactivated is traversed. In the backward checking mechanism, when a rule is being fired, the expert system checks back on the premise conditions of the upstream rules that result in evaluation of the rule to see whether it should be fired. The root of the tree being traversed is the rule being fired. In the censor setting mechanism, when a rule is to be evaluated, a censor is constructed based on the premise conditions of the upstream rules and the censor is evaluated just before the rule is fired. Unlike the backward checking mechanism, this one does not search the upstream rules. This paper explores the details of implementation of the three mechanisms.

Yeh, Show-Way↗
NASA NTRS1988

Development of an expert planning system for OSSA

This paper presents concepts related to preliminary work for the development of an expert planning system for NASA's Office for Space Science and Applications (OSSA). The expert system will function as a planner's decision aid in preparing mission plans encompassing sets of proposed OSSA space science initiatives. These plans in turn will be checked against budgetary and technical constraints and tested for constraint violations. Appropriate advice will be generated by the system for making modifications to the plans to bring them in line with the constraints. The OSSA Planning Expert System (OPES) has been designed to function as an integral part of the OSSA mission planning process. It will be able to suggest a best plan, be able to accept and check a user-suggested strawman plan, and should provide a quick response to user request and actions. OPES will be written in the C programming language and have a transparent user interface running under Windows 386 on a Compaq 386/20 machine. The system's sorted knowledge and inference procedures will model the expertise of human planners familiar with the OSSA planning domain. Given mission priorities and budget guidelines, the system first sets the launch dates for each mission. It will check to make sure that planetary launch windows and precursor mission relationships are not violated. Additional levels of constraints will then be considered, checking such things as the availability of a suitable launch vehicle, total mission launch mass required vs. the identified launch mass capability, and the total power required by the payload at its destination vs. the actual power available. System output will be in the form of Gantt charts, spreadsheet hardcopy, and other presentation quality materials detailing the resulting OSSA mission plan.

Groundwater, B.↗
NASA NTRS1989

Liquid Rocket Booster (LRB) for the Space Transportation System (STS) systems study. Appendix E: Pressure-fed booster test bed for the liquid rocket booster study

The stress analysis/structural design of the Pressure-Fed Booster Engine Test Bed using the existing F-1 Test Facility Test Stand at Huntsville, Alabama is described. The analysis has been coded and set up for solution on NASTRAN. A separate stress program was established to take the NASTRAN output and perform stress checks on the members. Joint checks and other necessary additional checks were performed by hand. The notes include a brief description of other programs which assist in reproducing and reviewing the NASTRAN results. The redesign of the test stand members and the stress analysis was performed per the A.I.S.C. Code. Loads on the stand consist of the loaded run tanks; wind loads; seismic loads; live loads consisting of snow and ice: live and dead loads of steel; and loaded pressurant bottle. In combining loads, wind loads and seismic loads were each combined with full live loads. Wind and seismic loads were not combined. No one third increase in allowables was taken for the environmental loads except at decks 147 and 214, where the increase was used when considering the stay rods, brackets and stay beams. Wind and seismic loads were considered from each of the four coordinate directions (i.e. N,S,E,W) to give eight basic conditions. The analysis was run with the pressurant tank mounted at level 125. One seismic condition was also run with the tank mounted at levels 169 and 214. No failures were noted with mounting at level 169, but extensive deck failure with mounting at level 214 (the loadsets used are included on the tape, but no detailed results are included in the package). Decking support beams at levels 147 and 214 are not included in the model. The stress program thus does not reduce strut lengths to the length between support beams (the struts are attached to the beams at intersection points) and gives stress ratios larger than one for some of the struts. The affected members were therefore checked by hand.

Source record↗
NASA NTRS1990

Hypercubes for critical spacecraft command verification

Interplanetary spacecraft are controlled with sets of onboard commands called 'sequences' that control the spacecraft for hours, days, or weeks depending upon the craft and its current activity phase. The sequence-checking problem, with some examples from practical experience, and the technical challenges of implementing sequence checking on a parallel computer are presented. Hypercube applications including computational-physics problems, 'optimistic' and 'conservative' categories are discussed. Finally, future development and prototype ways of balancing the checking network across the hypercube nodes, handling time dependencies among the checks, and minimizing communication are described.

Horvath, Joan C.↗
NASA NTRS1995

ANSYS duplicate finite-element checker routine

An ANSYS finite-element code routine to check for duplicated elements within the volume of a three-dimensional (3D) finite-element mesh was developed. The routine developed is used for checking floating elements within a mesh, identically duplicated elements, and intersecting elements with a common face. A space shuttle main engine alternate turbopump development high pressure oxidizer turbopump finite-element model check using the developed subroutine is discussed. Finally, recommendations are provided for duplicate element checking of 3D finite-element models.

Ortega, R.↗
NASA NTRS1997

Parallel Proximity Detection for Computer Simulation

The present invention discloses a system for performing proximity detection in computer simulations on parallel processing architectures utilizing a distribution list which includes movers and sensor coverages which check in and out of grids. Each mover maintains a list of sensors that detect the mover's motion as the mover and sensor coverages check in and out of the grids. Fuzzy grids are includes by fuzzy resolution parameters to allow movers and sensor coverages to check in and out of grids without computing exact grid crossings. The movers check in and out of grids while moving sensors periodically inform the grids of their coverage. In addition, a lookahead function is also included for providing a generalized capability without making any limiting assumptions about the particular application to which it is applied. The lookahead function is initiated so that risk-free synchronization strategies never roll back grid events. The lookahead function adds fixed delays as events are scheduled for objects on other nodes.

Steinman, Jeffrey S.↗
NASA NTRS1998

Parallel Proximity Detection for Computer Simulations

The present invention discloses a system for performing proximity detection in computer simulations on parallel processing architectures utilizing a distribution list which includes movers and sensor coverages which check in and out of grids. Each mover maintains a list of sensors that detect the mover's motion as the mover and sensor coverages check in and out of the grids. Fuzzy grids are included by fuzzy resolution parameters to allow movers and sensor coverages to check in and out of grids without computing exact grid crossings. The movers check in and out of grids while moving sensors periodically inform the grids of their coverage. In addition, a lookahead function is also included for providing a generalized capability without making any limiting assumptions about the particular application to which it is applied. The lookahead function is initiated so that risk-free synchronization strategies never roll back grid events. The lookahead function adds fixed delays as events are scheduled for objects on other nodes.

Steinman, Jeffrey S.↗
NASA NTRS1999

Quality Control of Meteorological Observations

For the first time, a problem of the meteorological observation quality control (QC) was formulated by L.S. Gandin at the Main Geophysical Observatory in the 70's. Later in 1988 L.S. Gandin began adapting his ideas in complex quality control (CQC) to the operational environment at the National Centers for Environmental Prediction. The CQC was first applied by L.S.Gandin and his colleagues to detection and correction of errors in rawinsonde heights and temperatures using a complex of hydrostatic residuals.Later, a full complex of residuals, vertical and horizontal optimal interpolations and baseline checks were added for the checking and correction of a wide range of meteorological variables. some other of Gandin's ideas were applied and substantially developed at other meteorological centers. A new statistical QC was recently implemented in the Goddard Data Assimilation System. The central component of any quality control is a buddy check which is a test of individual suspect observations against available nearby non-suspect observations. A novel feature of this test is that the error variances which are used for QC decision are re-estimated on-line. As a result, the allowed tolerances for suspect observations can depend on local atmospheric conditions. The system is then better able to accept extreme values observed in deep cyclones, jet streams and so on. The basic statements of this adaptive buddy check are described. Some results of the on-line QC including moisture QC are presented.

Collins, William↗
NASA NTRS1997

A Categorization of Dynamic Analyzers

Program analysis techniques and tools are essential to the development process because of the support they provide in detecting errors and deficiencies at different phases of development. The types of information rendered through analysis includes the following: statistical measurements of code, type checks, dataflow analysis, consistency checks, test data,verification of code, and debugging information. Analyzers can be broken into two major categories: dynamic and static. Static analyzers examine programs with respect to syntax errors and structural properties., This includes gathering statistical information on program content, such as the number of lines of executable code, source lines. and cyclomatic complexity. In addition, static analyzers provide the ability to check for the consistency of programs with respect to variables. Dynamic analyzers in contrast are dependent on input and the execution of a program providing the ability to find errors that cannot be detected through the use of static analysis alone. Dynamic analysis provides information on the behavior of a program rather than on the syntax. Both types of analysis detect errors in a program, but dynamic analyzers accomplish this through run-time behavior. This paper focuses on the following broad classification of dynamic analyzers: 1) Metrics; 2) Models; and 3) Monitors. Metrics are those analyzers that provide measurement. The next category, models, captures those analyzers that present the state of the program to the user at specified points in time. The last category, monitors, checks specified code based on some criteria. The paper discusses each classification and the techniques that are included under them. In addition, the role of each technique in the software life cycle is discussed. Familiarization with the tools that measure, model and monitor programs provides a framework for understanding the program's dynamic behavior from different, perspectives through analysis of the input/output data.

Lujan, Michelle R.↗
NASA NTRS2002

Learning Assumptions for Compositional Verification

Compositional verification is a promising approach to addressing the state explosion problem associated with model checking. One compositional technique advocates proving properties of a system by checking properties of its components in an assume-guarantee style. However, the application of this technique is difficult because it involves non-trivial human input. This paper presents a novel framework for performing assume-guarantee reasoning in an incremental and fully automated fashion. To check a component against a property, our approach generates assumptions that the environment needs to satisfy for the property to hold. These assumptions are then discharged on the rest of the system. Assumptions are computed by a learning algorithm. They are initially approximate, but become gradually more precise by means of counterexamples obtained by model checking the component and its environment, alternately. This iterative process may at any stage conclude that the property is either true or false in the system. We have implemented our approach in the LTSA tool and applied it to the analysis of a NASA system.

Cobleigh, Jamieson M.↗
NASA NTRS2004

Abstraction and Assume-Guarantee Reasoning for Automated Software Verification

Compositional verification and abstraction are the key techniques to address the state explosion problem associated with model checking of concurrent software. A promising compositional approach is to prove properties of a system by checking properties of its components in an assume-guarantee style. This article proposes a framework for performing abstraction and assume-guarantee reasoning of concurrent C code in an incremental and fully automated fashion. The framework uses predicate abstraction to extract and refine finite state models of software and it uses an automata learning algorithm to incrementally construct assumptions for the compositional verification of the abstract models. The framework can be instantiated with different assume-guarantee rules. We have implemented our approach in the COMFORT reasoning framework and we show how COMFORT out-performs several previous software model checking approaches when checking safety properties of non-trivial concurrent programs.

Chaki, S.↗