Search NASA⌕ Search

SEARCH · Search NASA

Results for “Verification”

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

An Analysis of Extended Reality Mockups for Use in Verification: Phase 2

NASA commercial providers are increasing their use of Virtual Reality (VR) and Hybrid Reality (HR) technologies in their system development process. The use of these technologies, collectively referred to as Extended Reality (XR) technologies, has been limited to the development phase, but there have been requests to integrate VR and HR mockups into verifications. Verifications require, at minimum, a high-fidelity mockup for activities involving human participation (tests, demonstrations, inspections). HR technology shares many of the strengths but may not share some of the critical shortcomings of VR. Specifically, HR allows for integrating physical objects, such as a suit, which may be critical to evaluating a system. Adopting HR technology still has many of the same challenges as VR. Namely, there is little to no data about the validity of evaluations conducted with HR mockups, an established process, or criteria for evaluating the appropriateness of HR mockups. Because verifications are final and only need to happen once, HR mockups must be adequately vetted before being approved for use in verifications. Further hindering the adoption of these technologies is the lack of consensus on what constitutes a high-fidelity XR mockup. Even for physical mockups, there are guidelines and common criteria, but nothing has been formalized. Discussion about when an XR mockup can be used would be greatly helped by clearly defining what a high-fidelity XR mockup is and how it might be measured. The team will engage with relevant stakeholders to learn more about the benefits and challenges of adopting hybrid reality mockups for verification. The team will build upon work from Phase 1 by maturing a framework to guide decisions for evaluating XR mockups for use in verifications. The team will also conduct experimental studies to evaluate advantages and tradeoffs of hybrid/mixed reality relative to physical and virtual reality mockups. Finally, data from Phase 1 and Phase 2 will be synthesized into a set of best practices for developing and validating XR mockups for verification. We will highlight the work conducted to date in Phase 2. We will present the status of the XR for Verification Framework, a summary of best practices identified thus far, and give a synopsis of future work.

verification testing↗
DOE OSTI2024

Verification of RESRAD-OFFSITE Code (V.4)

This report documents the verification of RESRAD-OFFSITE Version 4.0 and describes, where necessary, the verification of the following: • The data comprising the standard dose and risk coefficient libraries in the RESRAD database files Master_dcf_ICRP07.mdb and Master_dcf_2k.mdb. • The extraction and transfer of the data from the selected database file to the computational code by the RESRAD-OFFSITE 4.0 interface, ResOWin.exe. • The different processes that are modeled by the main computational code in RESRAD OFFSITE 4.0, ResOMain.exe. • The data displayed in the graphical and text reports. Many verifications were performed as part of the quality assurance quality control program associated with the development and release of RESRAD-OFFSITE 4.0, namely: • developer testing, • internal independent testing, and • release testing. Some were also performed in response to questions from users regarding the performance of the code. The main text of the report focuses on summarizing a subset of those tests, both independent and developer tests that verified the computations performed by the code. The verifications included in this report served as the basis for the development of the release tests of the computational executables and provided the quantitative results to be compared with the code output. The input and output interfaces and the data transfers between the various executables of the code were tested while performing the verification testing. They were tested intentionally during release testing. This report also provides some basic information to help in understanding the activities that were verified. The report: • outlines the components of RESRAD-OFFSITE 4.0 and the interconnections between these components, • outlines the processes modeled by the computational code, • provides summary figures and tables to offer confirmation of the verification of the computational components of the code, • reproduces the verifiers’ reports, if available, in individual appendices, • refers to the previous verification report (Yu et al. 2011) for more details about some of the verifications, and • reproduces the test cases and the testers’ reports from the release testing in individual appendices, when possible.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS1992

HDL to verification logic translator

The increasingly higher number of transistors possible in VLSI circuits compounds the difficulty in insuring correct designs. As the number of possible test cases required to exhaustively simulate a circuit design explodes, a better method is required to confirm the absence of design faults. Formal verification methods provide a way to prove, using logic, that a circuit structure correctly implements its specification. Before verification is accepted by VLSI design engineers, the stand alone verification tools that are in use in the research community must be integrated with the CAD tools used by the designers. One problem facing the acceptance of formal verification into circuit design methodology is that the structural circuit descriptions used by the designers are not appropriate for verification work and those required for verification lack some of the features needed for design. We offer a solution to this dilemma: an automatic translation from the designers' HDL models into definitions for the higher-ordered logic (HOL) verification system. The translated definitions become the low level basis of circuit verification which in turn increases the designer's confidence in the correctness of higher level behavioral models.

Gambles, J. W.↗
NASA NTRS2011

Requirement Assurance: A Verification Process

Requirement Assurance is an act of requirement verification which assures the stakeholder or customer that a product requirement has produced its "as realized product" and has been verified with conclusive evidence. Product requirement verification answers the question, "did the product meet the stated specification, performance, or design documentation?". In order to ensure the system was built correctly, the practicing system engineer must verify each product requirement using verification methods of inspection, analysis, demonstration, or test. The products of these methods are the "verification artifacts" or "closure artifacts" which are the objective evidence needed to prove the product requirements meet the verification success criteria. Institutional direction is given to the System Engineer in NPR 7123.1A NASA Systems Engineering Processes and Requirements with regards to the requirement verification process. In response, the verification methodology offered in this report meets both the institutional process and requirement verification best practices.

Alexander, Michael G.↗
NASA NTRS2014

Projected Impact of Compositional Verification on Current and Future Aviation Safety Risk

The projected impact of compositional verification research conducted by the National Aeronautic and Space Administration System-Wide Safety and Assurance Technologies on aviation safety risk was assessed. Software and compositional verification was described. Traditional verification techniques have two major problems: testing at the prototype stage where error discovery can be quite costly and the inability to test for all potential interactions leaving some errors undetected until used by the end user. Increasingly complex and nondeterministic aviation systems are becoming too large for these tools to check and verify. Compositional verification is a "divide and conquer" solution to addressing increasingly larger and more complex systems. A review of compositional verification research being conducted by academia, industry, and Government agencies is provided. Forty-four aviation safety risks in the Biennial NextGen Safety Issues Survey were identified that could be impacted by compositional verification and grouped into five categories: automation design; system complexity; software, flight control, or equipment failure or malfunction; new technology or operations; and verification and validation. One capability, 1 research action, 5 operational improvements, and 13 enablers within the Federal Aviation Administration Joint Planning and Development Office Integrated Work Plan that could be addressed by compositional verification were identified.

Reveley, Mary S.↗
NASA NTRS2018

Guidelines for Verification Strategies to Minimize RISK Based on Mission Environment, -Application and -Lifetime (MEAL)

There is a trend of compromising verification testing to address the cost and schedule constraints, which poses a high-risk posture for programs/projects. Current and emerging aerospace scientific and/or human exploration programs continue to pose new technological challenges. These technological challenges combined with finite budgets and truncated schedules are forcing designers, scientists, engineers, and managers to push technologies to their physical limits. In addition, budget and schedule pressures challenge how those technologies/missions are verified. A clear understanding of the different verification processes is needed to ensure the proper verification of the technology within the mission (i.e., capabilities, advantages, and limitations). The goal of verification is to prove through test, analysis, inspection, and/or demonstration that a product provides its required function while meeting the performance requirements. It is important that verification yield understanding of representative performance under worst-case conditions so that margins to failure can be evaluated for proposed applications. The capabilities, advantages, and limitations of the testing and inspection performed at each level are different, and the risk incurred by omitting a verification step depends on the level of integration as well as Mission, Environment, Application and Lifetime (MEAL). This paper focuses on verification processes. The goal of the verification process is to ensure the given avionics technology could be safely implemented on the given MEAL consistent with the program/project risk posture.

Gonzalez, Oscar↗
DOE OSTI2021

Verification of Maximal Oxygen Uptake in Active Military Personnel During Treadmill Running

Figueiredo, PS, Looney, DP, Pryor, JL, Doughty, EM, McClung, HL, Vangala, SV, Santee, WR, Beidleman, BA, and Potter, AW. Verification of maximal oxygen uptake in active military personnel during treadmill running. J Strength Cond Res 36(4): 1053–1058, 2022—It is unclear whether verification tests are required to confirm “true” maximal oxygen uptake ($\dot{V}_{o2}$max) in modern warfighter populations. Our study investigated the prevalence of $\dot{V}_{o2}$max attainment in U.S. Army soldiers performing a traditional incremental running test. In addition, we examined the utility of supramaximal verification testing as well as repeated trials for familiarization for accurate $\dot{V}_{o2}$max assessment. Sixteen U.S. Army soldiers (1 woman, 15men; age, 21±2 years; height, 1.73±0.06m; body mass, 71.6±10.1 kg) completed 2 laboratory visits, each with an incremental running test (modified Astrand protocol) and a verification test (110% maximal incremental test speed) on a motorized treadmill. We evaluated $\dot{V}_{o2}$max attainment during incremental testing by testing for the definitive $\dot{V}_{o2}$ plateau using a linear least-squares regression approach. Peak oxygen uptake ($\dot{V}_{o2}$peak) was considered statistically equivalent between tests if the 90% confidence interval around the mean difference was within 62.1 ml·kg -1 ·min -1 . Oxygen uptake plateaus were identified in 14 of 16 volunteers for visit 1 (87.5%) and all 16 volunteers for visit 2 (100%). Peak oxygen uptake was not statistically equivalent, apparent from the mean difference in $\dot{V}_{o2}$peak measures between the incremental test and verification test on visit 1 (2.3 ml·kg -1 ·min -1 , [1.3–3.2]) or visit 2 (1.1 ml·kg -1 ·min -1 [0.2–2.1]). Interestingly, $\dot{V}_{o2}$peak was equivalent, apparent from the mean difference in $\dot{V}_{o2}$peak measures between visits for the incremental tests (0.0ml·kg -1 ·min -1 [-0.8to 0.9]) but not the verification tests (-1.2 ml·kg -1 ·min -1 [-2.2 to -0.2]). Modern U.S. Army soldiers can attain $\dot{V}_{o2}$max by performing a modified Astrand treadmill running test. Additional familiarization and verification tests for confirming $\dot{V}_{o2}$max in healthy active military personnel may be unnecessary.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2020

Verification of the DIF3D Software to Support Fast Reactor Analysis

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. DIF3D is central to this system. The driver for this effort requires the 3D Cartesian, triangular-Z, and hexagonal-Z core geometry options of DIF3D be verified. Previous work identified the DIF3D features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying DIF3D’s ability to correctly translate the user’s model in to DIF3D’s preferred format, verifying that options planned for use have the desired effect, and verifying the correctness of the eigenvalue, fixed-source, forward, and adjoint solvers in DIF3D-FD and DIF3D-VARIANT. This manuscript provides the verification tasks and their results with respect to the features needed for current design activities. Since analytic solutions of the neutron diffusion and transport equations are either limited in scope or not possible, multiple tiers of problems unique to each solver and geometry type were implemented. Each of these tiers tests features independent and complementary arguments for why the separate testing of functionalities is acceptable. Finally, this separate testing was also supplemented with a high-level integral check of each the diffusion and transport capabilities and applicable geometries. To accommodate cases which an analytic solution is not feasible, MCNP6.2 was relied upon to provide a higher-order reference solution. This therefore required that the capabilities within MCNP6.2 which were relied upon for this work are also verified in this work. No MCNP discrepancies were noted in this effort. Note that the MCNP6.2 verification included in this work does not stand as a full verification of MCNP6.2, but merely verifies the features used in verifying DIF3D. The verification effort identified no issues that are debilitating or otherwise impactful to design usage of DIF3D, and thus DIF3D version 11.0, release 3012 is considered verified. The types of issues that were identified were predominantly in the areas of: unclear documentation, software bugs which were inconsequential to final results, editing options which were ignored in favor of printing more information than requested, bugs in the outputs of intermediate results, or secondary output binary file information which was not present. While not a bug, this verification report also identified that the algorithm used to evaluate the peak fast flux in a nodal transport solution can be quite unreliable due to the polynomial order used and the location of the peak within the mesh. The authors of the report therefore recommend the usage of the EvaluateFlux software (distributed with ARC) as a more robust alternative.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
NASA NTRSDate not supplied

Stochastic Verification by Analysis for Autonomous Systems Management Architecture (ASMA)

The Gateway Vehicle Systems Manager (VSM) is the top-level of a distributed, hierarchical software control system. VSM is data-driven and will make decisions related to mission, fault, resource management and vehicle control. These attributes combined with a high degree of autonomy make it susceptible to emergent behavior. In order to achieve the high level of confidence needed in this critical system, the VSM team has developed a multifaceted verification strategy employing traditional verification techniques, simulation, model checking, and runtime verification. Individual algorithms are verified using conventional testing and model checking using assume-guarantee contracts. A discrete event-based simulation approach is being developed to verify timelines. This presentation describes an enhancement to the verification approach using analysis to enhance system robustness by detecting and resolving the potential for emergent behavior. The verification by analysis employs a Software in the Loop (SITL) environment with real flight software executing on emulated processors, simulations of vehicle subsystems, flight dynamics, and human inputs. Since the possible input space and configuration data set are too large for exhaustive testing, a Monte Carlo approach is used to cover feasible scenarios, augmented with corner cases and known higher-risk scenarios. A key problem in using Monte Carlo-based system verification is evaluating test results to ensure that system behavior is correct. The presentation describes the approach the VSM team uses to monitor behavior for compliance with predetermined boundaries and to identify anomalous behavior for further analysis. This presentation describes the multi-level systems approach to verification, and the simulation-based layer that covers the feasible state space: 1. Overview of the Gateway VSM 2. Special challenges due to heterogeneous, hierarchical architecture 3. Modeling and simulation environment using flight software and system simulations 4. Developing input sets to ensure state-space coverage 5. Developing model and data configuration sets to ensure model coverage 6. Interpreting results without predetermined outcomes 7. Lessons learned and future work

Verification and Validation↗
DOE OSTI2019

Computer Modeling and Simulation: Increasing Reliability by Disentangling Verification and Validation

Verification and validation (V&V) of computer codes and models used in simulations are two aspects of the scientific practice of high importance that recently have been discussed widely by philosophers of science. While verification is predominantly associated with the correctness of the way a model is represented by a computer code or algorithm, validation more often refers to the model’s relation to the real world and its intended use. Because complex simulations are generally opaque to a practitioner, the Duhem problem can arise with verification and validation due to their entanglement; such an entanglement makes it impossible to distinguish whether a coding error or the model’s general inadequacy to its target should be blamed in the case of a failure. I argue that a clear distinction between computer modeling and simulation has to be made to disentangle verification and validation. Drawing on that distinction, I suggest to associate modeling with verification and simulation, which shares common epistemic strategies with experimentation, with validation. To explain the reasons for their entanglement in practice, I propose a Weberian ideal–typical model of modeling and simulation as roles in practice. I examine an approach to mitigate the Duhem problem for verification and validation that is generally applicable in practice and is based on differences in epistemic strategies and scopes. Based on this analysis, I suggest two strategies to increase the reliability of simulation results, namely, avoiding alterations of verified models at the validation stage as well as performing simulations of the same target system using two or more different models. In response to Winsberg’s claim that verification and validation are entangled I argue that deploying the methodology proposed in this work it is possible to mitigate inseparability of V&V in many if not all domains where modeling and simulation are used.

97 MATHEMATICS AND COMPUTING↗
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↗
DOE OSTI2022

FY2021 Improvements to the New CTH Code Verification & Validation Test Suite

Over the past few years, the CTH multiphysics hydrocode has overhauled its software quality and testing processes, implementing current best practices in software quality and building a robust V&V test suite comprised of traditional hydrocode verification problems, including ASC Tri-Lab Test Suite and Enhanced Tri-Lab Test Suite problems, as well as validation problems for some of CTH’s most frequently used equations of state, materials models, and other key capabilities. Substantial progress towards building this new test suite was made in FY19 and FY20. In FY21, the test suite has been expanded to include verification and validation tests of the Steinberg-Guinan-Lund (ST) viscoplastic model and the Johnson Cook (JFRAC) fracture model. Additionally, two new verification tests were added, covering hydrodynamics and high explosive (HE) modeling capabilities: the Kidder Gaussian density problem and the Escape of HE Products (EHEP) problem from the Tri-Lab Test Suite. This report discusses each of these test problems in detail. Verification test results are compared to analytic solutions. Validation test results are compared to experimental data. Wherever possible, convergence or mesh refinement studies are included. Additionally, while implementing the Kidder verification problem, a bug was identified that affects the use of tables to initialize pressure or density in 1D or 2D calculations. A brief discussion of the bug and its fix is included. CTH demonstrates good performance overall on the new test suite problems. Simulation results showed good agreement with analytic solutions for the Kidder problem, with convergence rates ranging between 1.8 and sub-linear, and relatively good agreement for the EHEP problem, though convergence rates for pressure and density were nearly 0. The ST and JFRAC strain rate loading verification tests show good agreement with analytic solutions. Likewise, CTH simulation results show good agreement with experimental validation data, including Taylor rod impact testing, for the materials tested. Future V&V work will focus on adding 2D and 3D versions of existing verification tests as well as adding validation tests of other frequently used capabilities such as other fracture models.

42 ENGINEERING↗
DOE OSTI2022

Verification of the DIF3D Software to Support Fast Reactor Analysis

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. DIF3D is central to this system. The driver for this effort requires the 3D Cartesian, triangular-Z, and hexagonal-Z core geometry options of DIF3D be verified. Previous work identified the DIF3D features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying DIF3D’s ability to correctly translate the user’s model in to DIF3D’s preferred format, verifying that options planned for use have the desired effect, and verifying the correctness of the eigenvalue, fixed-source, forward, and adjoint solvers in DIF3D-FD and DIF3D-VARIANT. This manuscript provides the verification tasks and their results with respect to the features needed for current design activities. Since analytic solutions of the neutron diffusion and transport equations are either limited in scope or not possible, multiple tiers of problems unique to each solver and geometry type were implemented. Each of these tiers tests features independent and complementary arguments for why the separate testing of functionalities is acceptable. Finally, this separate testing was also supplemented with a high-level integral check of each the diffusion and transport capabilities and applicable geometries. To accommodate cases which an analytic solution is not feasible, MCNP6.2 was relied upon to provide a higher-order reference solution. This therefore required that the capabilities within MCNP6.2 which were relied upon for this work are also verified in this work. No MCNP discrepancies were noted in this effort. Note that the MCNP6.2 verification included in this work does not stand as a full verification of MCNP6.2, but merely verifies the features used in verifying DIF3D. The verification effort identified no issues that are debilitating or otherwise impactful to design usage of DIF3D, and thus DIF3D version 11.0, release 3012 is considered verified. As some additional changes have been made to the ARC software since this point all versions between release 3012 and 3266 can be considered verified as version 3253 was used for all updates in this revision. The types of issues that were identified were predominantly in the areas of: unclear documentation, software bugs which were inconsequential to final results, editing options which were ignored in favor of printing more information than requested, bugs in the outputs of intermediate results, or secondary output binary file information which was not present. While not a bug, this verification report also identified that the algorithm used to evaluate the peak fast flux in a nodal transport solution can be quite unreliable due to the methodology used and the location of the peak within the mesh. The authors of the report therefore recommend the usage of the EvaluateFlux software (distributed with ARC) as a more robust alternative noting that DIF3D will properly notify the user when the peaking values it is providing are potentially incorrect.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Verification of the DIF3D Software to Support Fast Reactor Analysis (Rev. 3)

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. DIF3D is central to this system. The driver for this effort requires the 3D Cartesian, triangular-Z, and hexagonal-Z core geometry options of DIF3D be verified. Previous work identified the DIF3D features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying DIF3D’s ability to correctly translate the user’s model in to DIF3D’s preferred format, verifying that options planned for use have the desired effect, and verifying the correctness of the eigenvalue, fixed-source, forward, and adjoint solvers in DIF3D-FD and DIF3D-VARIANT. This manuscript provides the verification tasks and their results with respect to the features needed for current design activities. Since analytic solutions of the neutron diffusion and transport equations are either limited in scope or not possible, multiple tiers of problems unique to each solver and geometry type were implemented. Each of these tiers tests features independent and complementary arguments for why the separate testing of functionalities is acceptable. Finally, this separate testing was also supplemented with a high-level integral check of each the diffusion and transport capabilities and applicable geometries. To accommodate cases which an analytic solution is not feasible, MCNP6.2 was relied upon to provide a higher-order reference solution. This therefore required that the capabilities within MCNP6.2 which were relied upon for this work are also verified in this work. No MCNP discrepancies were noted in this effort. Note that the MCNP6.2 verification included in this work does not stand as a full verification of MCNP6.2, but merely verifies the features used in verifying DIF3D. The verification effort identified no issues that are debilitating or otherwise impactful to design usage of DIF3D, and thus DIF3D version 11.0, release 3012 is considered verified. As some additional changes have been made to the ARC software since this point all versions between release 3012 and 3266 can be considered verified as version 3253 was used for all updates in this revision. The types of issues that were identified were predominantly in the areas of: unclear documentation, software bugs which were inconsequential to final results, editing options which were ignored in favor of printing more information than requested, bugs in the outputs of intermediate results, or secondary output binary file information which was not present. While not a bug, this verification report also identified that the algorithm used to evaluate the peak fast flux in a nodal transport solution can be quite unreliable due to the methodology used and the location of the peak within the mesh. The authors of the report therefore recommend the usage of the EvaluateFlux software (distributed with ARC) as a more robust alternative noting that DIF3D will properly notify the user when the peaking values it is providing are potentially incorrect.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2023

Expanded verification and validation studies of hypersonic aerodynamics with multiple physics-fidelity models

Hypersonic aerothermodynamics is an important domain of modern multiphysics simulation. The Multi-Fidelity Toolkit is a simulation tool being developed at Sandia National Laboratories to predict aerodynamic properties for compressible flows from a range of physics fidelities and computational speeds. These models include the Reynolds-averaged Navier–Stokes (RANS) equations, the Euler equations with momentum-energy integral technique (MEIT), and modified Newtonian aerodynamics with flat-plate boundary layer (MNA+FPBL) equations, and they can be invoked independently or coupled with hierarchical Kriging to interpolate between high-fidelity simulations using lower-fidelity data. However, as with any new simulation capability, verification and validation are necessary to gather credibility evidence. This work describes formal code- and solution-verification activities, as well as model validation with uncertainty considerations. Code verification activities on the MNA+FPBL model build on previous work by focusing on the viscous portion of the model. Viscous quantities of interest are compared against those from an analytical solution for flat-plate, inclined-plate, and cone geometries. The code verification methodology for the MEIT model is also presented. Test setup and results of code verification tests on the laminar and turbulent models within MEIT are shown. Solution-verification activities include grid-refinement studies on simulations that model the HIFiRE-1 wind tunnel experiments. These experiments are used for validation of all model fidelities. A thorough validation comparison with prediction error and uncertainty is also presented. Three additional HIFiRE-1 experimental runs are simulated in this study, and the solution verification and validation work examines the effects of the associated parameter changes on model performance. Finally, a study is presented that compares the computational costs and fidelities from each of the different models.

42 ENGINEERING↗
DOE OSTI2025

Verification of the REBUS Software

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. REBUS is central to this system. The driver for this effort requires the Triangular-Z and hexagonal-Z core geometry options of REBUS to be verified. Previous work identified the REBUS features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying REBUS’s ability to correctly intepret the user input model, verifying that the features identified yield the intended results, and verifying the correctness of the REBUS output tables. The REBUS software verification relies heavily upon the accuracy of the embedded DIF3D software, the verification of which was completed and documented elsewhere. Given that DIF3D produces an accurate solution, the primary focus of the verification in the REBUS software is to ensure that it properly uses the DIF3D solution and that the depletion system (Bateman equations) are correctly implemented. This manuscript reiterates the verification tasks and displays results with respect to the features needed for current design activities. Analytic solutions of the Batemen equations are displayed and the results calculated with REBUS are displayed demonstrating the accuracy. Since coupled Bateman and neutron diffusion/transport solutions are extremely difficult to obtain, much of the focus is placed on how REBUS uses a given DIF3D solution assuming the accuracy of the DIF3D solution. The verification effort identified no issues that are debilitating or otherwise impactful to the design usage of REBUS, and thus REBUS version 11.0, release 3012 is considered verified. It is important to note that several outputs of REBUS are identified to be inaccurate, such as burnup in MWD/MT. Most of the relevant ones for VTR are generally accurate with 10-20% errors which is not impactful as all regular REBUS users are aware of this issue and know how to hand calculate the results. The REBUS manual further makes it clear that these values are consistent with the methodology being used by REBUS and thus the “errors” are more of an inconsistent definition with respect to what a user would expect given a definition in literature. Other issues that were identified included unclear documentation and software bugs all of which were inconsequential to the final results.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1970

Study of techniques for redundancy verification without disrupting systems, phases 1-3

The problem of verifying the operational integrity of redundant equipment and the impact of a requirement for verification on such equipment are considered. Redundant circuits are examined and the characteristics which determine adaptability to verification are identified. Mutually exclusive and exhaustive categories for verification approaches are established. The range of applicability of these techniques is defined in terms of signal characteristics and redundancy features. Verification approaches are discussed and a methodology for the design of redundancy verification is developed. A case study is presented which involves the design of a verification system for a hypothetical communications system. Design criteria for redundant equipment are presented. Recommendations for the development of technological areas pertinent to the goal of increased verification capabilities are given.

Source record↗
NASA NTRS1993

Formal verification of algorithms for critical systems

We describe our experience with formal, machine-checked verification of algorithms for critical applications, concentrating on a Byzantine fault-tolerant algorithm for synchronizing the clocks in the replicated computers of a digital flight control system. First, we explain the problems encountered in unsynchronized systems and the necessity, and criticality, of fault-tolerant synchronization. We give an overview of one such algorithm, and of the arguments for its correctness. Next, we describe a verification of the algorithm that we performed using our EHDM system for formal specification and verification. We indicate the errors we found in the published analysis of the algorithm, and other benefits that we derived from the verification. Based on our experience, we derive some key requirements for a formal specification and verification system adequate to the task of verifying algorithms of the type considered. Finally, we summarize our conclusions regarding the benefits of formal verification in this domain, and the capabilities required of verification systems in order to realize those benefits.

Rushby, John M.↗