Search NASA⌕ Search

SEARCH · Search NASA

Results for “software 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 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

Software Verification Toolkit (SVT): Survey on Available Software Verification Tools and Future Direction

Writing software is difficult. However, writing complex, well tested and designed, and functionally correct software is incredibly difficult. An entire field of study is devoted to the validation and verification of software to address this problem, and in this paper we analyze the landscape of currently available third party software. We have divided our analyses into three separate subsections with regards to software validation: formal methods, static analysis, and test generation. Formal verification is the most complex method in which to validate software correctness, but also the most thorough as it truly validates the mathematical validity of the source code. Static analysis generally is relegated to abstract syntax tree traversal techniques to find errors related to faulty software such as memory leaks or stack overflow issues. Automatic test generation is similar in implementation to static analysis, but pushes a bit further in verifying the boundedness of function inputs and outputs with regards to annotated or parsed criteria. The crux of this report is to analyze and describe the software tools that implement these techniques to validate and verify software. Pros and cons related to installation, utilization, and capabilities of the frameworks are described, and reproducible examples are provided with a focus on usability. The initial survey concluded that the most interesting tools of note are Z3, Isabelle/HOL, and TLA+ with regards to formal verification; and Infer, Frama-C, and SonarQube with regards to static analysis. With these tools in mind, a final conjecture is provided that describes future avenues of utilizing these tools for developing a verification framework to assist in validating existing software at Sandia National Laboratories.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2018

Argonne Reactor Code Software Verification and Validation Plan for the Versatile Test Reactor

This Argonne Reactor Code (ARC) software has taken a pivotal role in the design work of the Versatile Test Reactor. The ARC software itself consists of several independent or semiindependent pieces of software that are used in concert to carry out specific analysis and design objectives. In this report, we discuss the validation that is needed for the ARC software overall and discuss available, usable experimental data and how it relates to the VTR project. We also discuss the verification that is required for the ARC software with respect to its usage in the VTR project and give some concrete examples as to what it must accomplish. A list of goals for the verification and validation work are presented as the general procedure that will be implemented for every individual piece of software in ARC. The ARC software has been continuously developed for over 50 years and many of the features used for the VTR project have thus been rigorously tested for accuracy during that timeframe. The ARC software is presently under source code control and undergoes nightly regression testing of not only the individual pieces, but the interconnected aspects that are common to most analysis projects. Its greatest weakness, from a software verification and validation perspective, is both a lack of documentation and outdated documentation. As an example, much of the previous validation work will require contemporary effort to re-evaluate given the updated base data libraries and modifications to the software that have occurred since. This requires new documentation to be produced to support the usage of the software in the VTR project. The bulk of the ARC software is focused on steady state neutronics and TH behavior of a reactor system. In this regard, we have identified the ZPPR, FFTF, and EBR-II programs as the best candidates for sources of validation data for the VTR project. The ZPPR-15 series in the ZPPR program was chosen as it is the best representation of the VTR fuel form and reactor core layout of all of the ZPPR measurements. Additional support for it comes from the fact that most of the data has already been processed into usable ARC models for VTR validation. The FFTF and EBR-II reactors were both functional reactors that provide reactor scale measurements. FFTF is clearly a closer match to VTR and its startup measurements would be a very valuable validation basis. EBR-II has invaluable burnup related measurements that will play a key role in the ARC software validation work. Each piece of ARC software will require a report detailing the software verification. The validation work will be logically split into the results of modeling each identified experimental resource (ZPPR, EBR-II, FFTF). The intended timeline for the VTR project is to have the ARC software verified and validated by the end of fiscal year 2020. This is incumbent on sufficient funding allocated to V&V activities and no change in programmatic priorities.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2021

Software Verification and Validation Guidelines for Non-Linear Soil-Structure Interaction Analysis

Seismic analysis of structures, systems, and components (SSCs), including the consideration of soil-structure interaction (SSI) effects, is an important and required step in the design and licensing of nuclear power plant SSCs important to safety. Historically, the SSI analysis of nuclear structures has been performed using equivalent linear methods. However, there has been considerable industry investment in alternative seismic design and analysis approaches to reduce the construction cost of new reactors. Toward that goal and in alignment with the Licensing Modernization Project (LMP) framework, the Nuclear Regulatory Commission (US NRC) has proposed a risk-informed, performance-based approach to seismic design that allows inelastic response in those nuclear plant structures not required for confinement. As a complementary effort, reactor designers are exploring nonlinear seismic analysis methods to optimize structural designs and reduce construction costs.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2020

Assessment of Survey Results from Advanced Reactor Industry Domain Experts on Nonlinear Soil-Structure Interaction Analysis Software Verification and Validation

The seismic load case has a significant impact on the design and cost of nuclear power plants. Given the need to substantially reduce cost, advanced reactor designers are looking to leverage numerical tools that enable seismic analysis of an integrated vessel/support/structure/soil system. Modern nonlinear analysis tools provide a solution, capturing dynamic coupling between components (including soil-structure interaction (SSI)) concurrent with nonlinear behavior in one or more parts of the system. Although these methods have a rich history of technical development and implementation, software quality assurance (SQA) following nuclear industry standards remains a significant burden for those wishing to adopt such methods for advanced reactor design and licensing. To reduce the SQA burden, this project will develop the guidance for SQA verification and validation (V&V) of coupled nonlinear SSI analysis tools, to include a test matrix of software features and test problems to support commercial grade dedication (CGD). The guidance is intended to be technology-neutral: supporting designers of all advanced reactors. To maximize the value of the project to reactor designers, the project team performed focused surveys of and interviews with advanced reactor designers. Additionally, the project surveyed members of the broader industry involved in reactor design and licensing. The aggregated industry feedback consists of written survey responses, live polling responses, focused interviews, and informal feedback provided after outreach presentations, collectively referred to as “survey results”. Herein, the survey results are reported, reviewed, and assessed to inform follow-on project activities. The survey results confirmed the familiarity of the industry with the coupled nonlinear SSI analysis. They also affirm the project need based upon the expressed intent to (1) incorporate nonlinear features and (2) pursue the coupled nonlinear SSI analysis to reduce seismic demands and construction costs. All reactor designers indicated their intent to incorporate two or more nonlinear features, and all reactor designer respondents opined that the coupled nonlinear SSI analysis would allow for the optimization of the reactor design and construction. However, the programmatic challenges, whether real or perceived, present a significant barrier to reactor designers. The barrier most commonly identified by the reactor designer population was regulatory risk, with 70% citing this as a reason not to pursue the approach. The perceived regulatory risk identified by the reactor designers underscores the importance of regulator engagement and dialogue in this project. Additionally, half of the reactor designers identified cost and lack of guidance as a deterrent. The survey results also provide insights to tailor specific aspects of the guidance document and test matrix. The project plans to prepare both a formal referenceable guidance document and a collaborative, web-based test matrix and problem set. The project will focus on more complete test problem definitions for the prioritized nonlinear features over shallower problem descriptions for a larger set of features. The nonlinearities prioritized as high based upon survey feedback include fluid-structure interaction and seismic isolation and energy dissipation devices. The nonlinearities prioritized as intermediate include nonlinear geomaterials, nonlinear concrete, nonlinear steel, and interface/contact nonlinearity. Deep embedment and the associated nonlinear phenomena are assigned the lowest priority based upon survey feedback.

42 ENGINEERING↗
DOE OSTI2018

HPC Software Verification in Action: A Case Study with Tensor Transposition

As HPC platforms get increasingly complex, the complexity of software optimized for these platforms has also increased. There is a pressing need to ensure correctness of scientific applications to enhance our confidence in the results they produce. In this paper, we focus on checking the correctness of libraries providing a small but important functionality— tensor transposition—used in computational chemistry applications. While several correctness tools have been developed and deployed, there are several practical challenges in using them to verify production HPC software. We present our experiences using two tools—CIVL and CodeThorn—in checking the correctness of two index permutation libraries.

Model checking, equivalence checking, index permut↗
DOE OSTI2021

Uncertainty Analysis and Software Verification

Uncertainty analyses are an important part of calibrations and testing. They allow researchers insight on how to reduce and mitigate errors in testing. Each device used in testing introduces error in a system, as well as other sources such as environmental conditions, electronics, analog to digital, and random errors. Each source is carefully examined to identify how much error it introduces to a system. These sources are then combined using various methods of uncertainty calculations. To verify and validate software, a manual calculation is required to ensure the software is performing as intended. Using Excel to verify the calculations, we can identify discrepancies within the software. The root of the sum of the squares uncertainty (RSS) is used to find the combined uncertainty of a device at one and two standard deviations of the mean. Calibrations on accelerometers are performed using a vibration system along with a back-toback reference accelerometer. The vibration system takes a reference point at 100Hz frequency at 10g amplitude. The sensitivities are collected at each dialed in frequency. The sensitivity of the device represents the electrical output of the UUT (mV, pC, etc.) per unit of acceleration (g). The full history of sensitivities of selected accelerometers are used to find the averaged, standard deviation, and uncertainty of the device at each frequency tested. The uncertainty calculations from excel and the software are then compared.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Software Verification of VARPOW

The VARPOW program is a post-processing utility program for DIF3D, specifically DIF3DVARIANT, and it was developed to provide interface files for the thermal analysis program DASSH. The basic methodology of VARPOW is to take the neutron and gamma flux (moments) calculated by DIF3D (or GAMSOR) and combine them with the heating (coefficient) cross sections to calculate the spatial power distributions using the DIF3DVARIANT spatial basis. VARPOW can use the output from GAMSOR (both steady state neutron and gamma flux calculations) or standard DIF3D/REBUS calculations (neutron flux only). The correct approach for defining the power distribution is to use GAMSOR as its purpose was to properly compute the gamma heating throughout the modeled domain. The power densities calculated by VARPOW are broken into fuel, cladding and coolant terms for which isotope-wise categorization is needed. VARPOW has built in options the user can select for the isotope categorization or VARPOW can import a file that details the isotope categorization. VARPOW can export the solution in the polynomial basis of DIF3D-VARIANT or the monomial basis of DIF3D-VARIANT. The purpose of this work is to verify the power distribution results calculated by VARPOW from both the GAMSOR and DIF3D input options and verify that the input and output options are consistent with the manual. Hand calculation and independent numerical calculation are used for this verification work.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Software Verification of VARPOW

The VARPOW program is a post-processing utility program for DIF3D, specifically DIF3DVARIANT, and it was developed to provide interface files for the thermal analysis program DASSH. The basic methodology of VARPOW is to take the neutron and gamma flux (moments) calculated by DIF3D (or GAMSOR) and combine them with the heating (coefficient) cross sections to calculate the spatial power distributions using the DIF3DVARIANT spatial basis. VARPOW can use the output from GAMSOR (both steady state neutron and gamma flux calculations) or standard DIF3D/REBUS calculations (neutron flux only). The correct approach for defining the power distribution is to use GAMSOR as its purpose was to properly compute the gamma heating throughout the modeled domain. The power desnities calculated by VARPOW are broken into fuel, cladding and coolant terms for which isotope-wise categorization is needed. VARPOW has built in options the user can select for the isotope categorization or VARPOW can import a file that details the isotope categorization. VARPOW can export the solution in the polynomial basis of DIF3D-VARIANT or the monomial basis of DIF3D-VARIANT. The purpose of this work is to verify the power distribution results calculated by VARPOW from both the GAMSOR and DIF3D input options and verify that the input and output options are consistent with the manual. Hand calculation and independent numerical calculation are used for this verification work.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2026

Software Verification of VARPOW

The VARPOW program is a post-processing utility program for DIF3D, specifically DIF3DVARIANT, and it was developed to provide interface files for the thermal analysis program DASSH. The basic methodology of VARPOW is to take the neutron and gamma flux (moments) calculated by DIF3D (or GAMSOR) and combine them with the heating (coefficient) cross sections to calculate the spatial power distributions using the DIF3DVARIANT spatial basis. VARPOW can use the output from GAMSOR (both steady state neutron and gamma flux calculations) or standard DIF3D/REBUS calculations (neutron flux only). The correct approach for defining the power distribution is to use GAMSOR as its purpose was to properly compute the gamma heating throughout the modeled domain. The power desnities calculated by VARPOW are broken into fuel, cladding and coolant terms for which isotope-wise categorization is needed. VARPOW has built in options the user can select for the isotope categorization or VARPOW can import a file that details the isotope categorization. VARPOW can export the solution in the polynomial basis of DIF3D-VARIANT or the monomial basis of DIF3D-VARIANT. Recently the clad neutron damage calculation capability was introduced into VARPOW, and it now allows a pathway to get distributions of clad DPA. The purpose of this work is to verify the power distribution, fast neutron flux and clad DPA results calculated by VARPOW from both the GAMSOR and DIF3D input options and verify that the input and output options are consistent with the manual. Hand calculation and independent numerical calculation are used for this verification work.

Zhong, Zhaopeng [Argonne National Laboratory (ANL)↗
DOE OSTI2024

Fiscal Year 2024 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued in 2024. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The SUMMAR manual was completed this fiscal year and work was started on creating manuals for SE2ANL, SE2RCT, and DASSH. Software verification work was carried out for DIF3D and REBUS in a previous program and the current fiscal year saw the completion of software verification reports for GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The goal for the next fiscal year is to complete the PERSENT software verification work and begin planning the software verification work for DASSH, SE2ANL, and SE2RCT. The code coverage reports for DIF3D and MC2-3 were completed in the previous fiscal year and the goal is to generate code coverage reports for REBUS, GAMSOR, PERSENT, and DASSH in the coming fiscal year. A considerable amount of effort was spent in the current fiscal year working on the continuous integration capability for automated regression testing in GitLab. The first version of the testing was created in the previous fiscal year and applied to DIF3D and its utility programs. That testing was extended this year to cover GAMSOR, REBUS, and PERSENT. To accomplish this, the first version of the new testing methodology had to be updated to make a single output checking methodology viable for all of the ARC software. This will result in a single document to detail the automated regression testing methodology and minor documents to detail the tolerance settings that have been applied to the output for each ARC code. The previous methodology put into place with SVN would have required a separate document for each ARC code to detail the output checking methodology and the tolerance settings for the output from each code. Because some of our industry partners are providing funds to add new capabilities to the ARC software to meet their needs, all of which must be reviewed and approved by the SQA program funded by this project, a summary of that development work is detailed in this report. Overall progress on resolving the QA gaps has been good this year with the most impactful improvement for our industry partners in capability being the creation of a threaded version of DIF3D-VARIANT that allows the DIF3D, REBUS, and GAMSOR run times to be reduced by a factor of 4-6. The most impactful QA gap that was resolved was the software verification of GAMSRC and VARPOW.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Package Testing Program Process for Validation and Verification of Software

The purpose of this document is to define the process for validation and verification (V&V) of software used to test the thermal data acquisition equipment in the Oak Ridge National Laboratory (ORNL) Package Testing Program (PTP) as part of the testing configuration(s). This process adheres to all applicable ORNL Standards Based Management System requirements and correlates with the PTP Quality Management System and the Software Quality Assurance Plan.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

SAS4A/SASSYS-1 Verification and Validation Plan for the Versatile Test Reactor

Software verification and validation (V&V) hold an important role in the safety analysis for nuclear facilities. Codes and models utilized in calculations that demonstrate the safety basis as part of a license application or authorization must demonstrate an acceptable pedigree with regard to key critical characteristics that are comprised of the functional and performance requirements of the software. This document describes the methodology for verification and validation of the SAS4A/SASSYS-1 systems-level liquid-metal safety analysis software in support of DOE authorization of the Versatile Test Reactor (VTR). The overall goal of this V&V effort is to demonstrate the suitability of SAS4A/SASSYS-1 for evaluation of safety performance and characterization of safety margins in VTR. To that end, the V&V methodology will be used to demonstrate the adequacy of the component and physical models of SAS4A/SASSYS-1 for the corresponding VTR design elements. This methodology, which has been derived as a generalized approach to the U.S. NRC’s evaluation model development and assessment process (EMDAP) of Regulatory Guide 1.203, entails four high-level activities: software requirements identification, assessment base development, determination of acceptance, and gap closure. The methodology has been generalized to be suitable for both verification and validation of the software for the VTR project. Several high-level engineering analysis quality assurance measures as well as supporting V&V methodology documentation are also described in this document to help support demonstration of software acceptance. To support initial development of the SAS4A/SASSYS-1 V&V basis, existing verification test problems and systems benchmarks are also identified and briefly described in this document.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2026

RAPIDS2: A SciDAC Institute for Computer Science, Data, and Artificial Intelligence (University of Delaware)

This report summarizes the activities, technical accomplishments, and outcomes of the RAPIDS2 Institute project at the University of Delaware (UD). The RAPIDS2 Institute was a large multi-institution project with the objective of assisting SciDAC and Office of Science application teams in the use of DOE supercomputing resources to achieve scientific breakthroughs. The UD team contributed to this effort through work on formal software verification. This thrust aims to reduce software developer time and effort, especially regarding debugging and testing, and to increase confidence in the correctness of the results computed by the software.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Verification and Validation of the PLTEMP/ANL Code for Thermal-Hydraulic Analysis of Experimental and Test Reactors (Code Version 4.3)

The document compiles in a single volume the verification and validation works done for the PLTEMP/ANL code during the years of its development and improvement. The verification of sixteen capabilities of the PLTEMP/ANL Version 4.3 code that were identified by research reactor analysts as frequently used in their thermal-hydraulic analysis are described and documented. Each chapter of the document deals with the verification or validation of a specific part of the software that calculates a specific phenomenon, e.g., channel flow calculation, coolant property calculation, heat transfer calculation, and flow instability calculation. The software verification work is usually done by comparing the code with hand calculation, Microsoft spreadsheet calculation, or Mathematica calculation. The software validation is done by comparing the code with experimental data or a widely tested code like the RELAP5 code. In addition, some PLTEMP/ANL verification works that are available in the open literature are simply referenced and not included in the document. PLTEMP/ANL has been used in conversion safety analysis reports of several US and foreign research reactors that have been licensed and converted. A list of such reactors is given.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2020

Program Verification for Extreme-Scale Applications (Final Scientific/Technical Report)

The project seeks to develop tools and techniques to help software developers verify the correctness and accuracy of their code. The target domain is scientific software of the kind widely used and developed in the Department of Energy research community, with a particular focus on "extreme scale" programs - those that are expected to involve possibly millions of parallel threads of execution. The report covers the University of Delaware contribution to the collaborative project. The project had a number of successful outcomes, especially regarding the development and extension of the CIVL software verification framework. CIVL is a verification tool for C or Fortran programs that use MPI, OpenMP, CUDA, and/or Pthreads for parallelization. CIVL went through vast improvements and extensions, and was successfully applied to a number of challenging codes. It found a subtle bug in the Devito PDE framework. It was able to verify the functional correctness of a conjugate gradient solver using a novel probabilistic technique with vanishingly small chance of error. CIVL was used very successfully in verification competitions, and the CIVL solutions to the competition challenges were presented and published. CIVL was also used successfully by other researchers on a computational chemistry kernel.

97 MATHEMATICS AND COMPUTING↗