Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software”

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 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

Deploying and Tracking Software with NCCS Software Provisioning

The National Center for Computational Sciences (NCCS) at Oak Ridge National Laboratory has a long history of deploying ground-breaking leadership-class supercomputers for the U.S. Department of Energy. The latest in this line of supercomputers is Frontier, the first supercomputer to break the exascale barrier (1018 floating-point operations per second) on the TOP500 list. Frontier serves a wide array of scientific domains, from traditional simulation-based workloads to newer AI and Machine Learning workloads. To best serve the NCCS user community, NCCS uses Spack to deploy a comprehensive software stack of scientific software packages, providing straightforward access to these packages through Lmod Environment Modules. Maintaining a large software stack while also including multiple new compiler releases each year is a very time-consuming task. Additionally, it is not straightforward to provide a software stack alongside existing vendor-provided software such as the HPE/Cray Programming Environment (CPE), and existing CPE, Spack, and Lmod integration does not allow for multiple versions of GPU libraries such as AMD’s ROCm to be used. To address these challenges and shortcomings, NCCS has developed the NCCS Software Provisioning tool (NSP)1, a tool for deploying and monitoring software stacks on HPC systems. NSP allows NCCS to quickly and effectively provision software stacks from the ground up using template-driven recipes and configuration files. NSP is successfully deployed on Frontier and several other NCCS clusters, enabling the NCCS software team to quickly deploy software stacks for newly-released compilers, expand current software offerings, better support GPU-based software, and monitor Lmod module usage to identify unused software packages that can be removed from the software stack. In this work, we discuss the shortcomings of the previous CPE, Spack, and Lmod usage at NCCS, provide further details on the implementation and structure of NSP, then discuss the benefits that NSP provides.

Rentschler, Asa [ORNL] (ORCID:0009000597694743)↗
DOE OSTI2025

Scientific Open-Source Software Is Less Likely to Become Abandoned Than One Might Think! Lessons from Curating a Catalog of Maintained Scientific Software

Scientific software is essential to scientific innovation and in many ways it is distinct from other types of software. Abandoned (or unmaintained), buggy, and hard to use software, a perception often associated with scientific software can hinder scientific progress, yet, in contrast to other types of software, its longevity is poorly understood. Existing data curation efforts are fragmented by science domain and/or are small in scale and lack key attributes. We use large language models to classify public software repositories in World of Code into distinct scientific domains and layers of the software stack, curating a large and diverse collection of over 18,000 scientific software projects. Using this data, we estimate survival models to understand how the domain, infrastructural layer, and other attributes of scientific software affect its longevity. We further obtain a matched sample of non-scientific software repositories and investigate the differences. We find that infrastructural layers, downstream dependencies, mentions of publications, and participants from government are associated with a longer lifespan, while newer projects with participants from academia had shorter lifespan. Against common expectations, scientific projects have a longer lifetime than matched non-scientific open-source software projects. We expect our curated attribute-rich collection to support future research on scientific software and provide insights that may help extend longevity of both scientific and other projects.

Malviya Thakur, Addi [ORNL] (ORCID:000000022681999↗
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

The Journal of Open Source Software (JOSS): Bringing Open-Source Software Practices to the Scholarly Publishing Community for Authors, Reviewers, Editors, and Publishers

Open-source software (OSS) is a critical component of open science, but contributions to the OSS ecosystem are systematically undervalued in the current academic system. The Journal of Open Source Software (JOSS) contributes to addressing this by providing a venue (that is itself free, diamond open access, and all open-source, built in a layered structure using widely available elements/services of the scholarly publishing ecosystem) for publishing OSS, run in the style of OSS itself. A particularly distinctive element of JOSS is that it uses open peer review in a collaborative, iterative format, unlike most publishers. Additionally, all the components of the process—from the reviews to the papers to the software that is the subject of the papers to the software that the journal runs—are open. We describe JOSS’s history and its peer review process using an editorial bot, and we present statistics gathered from JOSS’s public review history on GitHub showing an increasing number of peer reviewed papers each year. We discuss the new JOSSCast and use it as a data source to understand reasons why interviewed authors decided to publish in JOSS. JOSS’s process differs significantly from traditional journals, which has impeded JOSS’s inclusion in indexing services such as Web of Science. In turn, this discourages researchers within certain academic systems, such as Italy’s, which emphasize the importance of Web of Science and/or Scopus indexing for grant applications and promotions. JOSS is a fully diamond open-access journal with a cost of around US$\$$5 per paper for the 401 papers published in 2023. The scalability of running JOSS with volunteers and financing JOSS with grants and donations is discussed.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗
DOE OSTI2025

Status of SPCA-ANL Software Development, Software Quality Assurance, and Application (FY2025)

SPCA-ANL is a simulation tool used to perform deterministic analyses of sodium spray and pool fires. Development of the SPCA-II (Spray Pool Combustion Analysis) code began in the mid- 1980s as part of the Clinch River Breeder Reactor (CRBR) Project. At that time, development of SPCA-II, which was led by Rockwell International, was focused on treatment of large-scale sodium spray, stream, and pool fires that were anticipated to be prototypic of the steam generator building cells in CRBR. Under more recent DOE NE programmatic activities, the SPCA-II code was recovered from existing literature and underwent minor modifications to generate a stable executable. This recovered version of the code was not formally released. As part of the Versatile Test Reactor (VTR) Project in the 2010s, the SPCA-II code underwent key modifications to improve stability, address modeling deficiencies, improve consistency between the code manual and software, and address numerous bugs. At this point, SPCA-II was renamed SPCA-ANL. Given that SPCA-II served as the original basis for SPCA-ANL, both codes share an integrated history. Following termination of the VTR Project, the DOE NE Fast Reactor Program resumed support of the software with the goal of building and maintaining software infrastructure that can enable commercial-grade dedication of SPCA-ANL by an end user. Version 1.0, the first external release of SPCA-ANL, was generated in June 2024. This report summarizes the development and maintenance activities completed for SPCAANL in FY2025. This year’s work was focused on improving quality and usability of the code. The provisional Software Quality Assurance (SQA) program has been established and was used to test the procedures for infrastructure improvements, code development, bug fixes, and code releases, as described in the following sections of this report. A code Version 1.0.1 was released in FY25, as described in Chapter 4.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Do Research Software Engineers and Software Engineering Researchers Speak the Same Language?

Anecdotal evidence suggests that research software engineers (RSEs) and software engineering researchers (SERs) often use different terminologies for similar concepts, creating communication challenges. To better understand these divergences, we have started investigating how software engineering fundamentals from the SER community are interpreted within the RSE community, identifying aligned concepts, knowledge gaps, and areas for potential adaptation. In conclusion, our preliminary findings reveal opportunities for mutual learning and collaboration, and our systematic methodology for terminology mapping provides a foundation for a crowdsourced extension and validation in the future.

Kehrer, Timo [Univ. of Bern (Switzerland)] (ORCID:↗
DOE OSTI2025

Nuclear Materials Packaging, Transportation, and Systems Analysis Group Software Quality Assurance Plan: ANSYS Mechanical Finite Element Analysis Software Version 2023R1

ANSYS Inc. develops and markets engineering simulation software and services used in the aerospace, automotive, manufacturing, electronics, biomedical, energy, defense, and many other industries. ANSYS is dedicated to engineering simulation and is the world’s leading software provider. ANSYS was founded in 1970 and is headquartered in Canonsburg, Pennsylvania. ANSYS provides an engineering analysis tool combining structural, thermal, computational fluid dynamics, acoustic, and electromagnetic simulation capabilities. ANSYS has two main programs, which use the same solvers: (1) Mechanical APDL (ANSYS Design Parametric Language), a Fortran-based coding platform, and (2) ANSYS Workbench, which uses a graphical user interface to aid in finite element analysis implementation. This plan covers both APDL and Workbench. The ANSYS computer program is a large-scale, multipurpose finite element program that can be used to solve several classes of engineering analyses. The analysis capabilities of ANSYS include the ability to solve static and dynamic structural analyses, steady-state and transient heat transfer problems, mode-frequency and buckling eigenvalue problems, static or time-varying magnetic analyses, and various types of field and coupled-field applications. The program contains many special features that allow nonlinearities or secondary effects such as plasticity, large strain, hyperelasticity, creep, swelling, large deflections, contact, stress stiffening, temperature dependency, material anisotropy, and radiation to be included in the solution. As ANSYS has been developed, other special capabilities such as substructuring, submodeling, random vibration, kinetostatics, kinetodynamics, free convection fluid analysis, acoustics, magnetics, piezoelectrics, coupled-field analysis, and design optimization have been added to the program. These capabilities contribute further to making ANSYS a multipurpose analysis tool for varied engineering disciplines. The ANSYS program has been in commercial use for over 50 years and has been used extensively in the aerospace, automotive, construction, electronic, energy services, manufacturing, nuclear, plastics, oil, and steel industries. Additionally, many consulting firms and hundreds of universities have used ANSYS for analysis, research, and educational purposes. ANSYS is recognized worldwide as one of the most widely used and capable programs of its type. Ansys design analysis software is the first created within a quality system with ISO 9001 certification, the internationally accepted quality standard. Product development, testing, maintenance and support processes also meet the United States Nuclear Regulatory Commission's quality requirements, as they have for nearly four decades. The Quality Assurance Service Agreement is suitable for the customers working in the nuclear industry who need to meet specific federal regulations including 10CRF50 Appendix B and provisions of 10CFR21. ANSYS has retained its original International Organization for Standardization (ISO) 9001 accreditation certificate since1995-05-04, It’s current certificate is valid until 2027-05-29.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2026

ARCH Technology Snapshot Autonomous Robot Control Hierarchy (ARCH): A universal software system that removes the need to rebuild robotic software for every new platform or task

Robots are increasingly used to perform repetitive, hazardous, and time-sensitive tasks, improving safety and operational efficiency. However, most robotic systems remain difficult to adapt because they are tightly tied to specific hardware and require extensive reprogramming for each new configuration.

42 ENGINEERING↗
DOE OSTI2024

WETO Software Stack Best Practices

Wind energy researchers typically share one key characteristic: a passion for increasing wind energy in the global energy mix. The U.S. Department of Energy (DOE) supports this mission in a number of ways including allocating funding directly to various aspects of wind energy research through the Office of Energy Efficiency and Renewable Energy (EERE) via the Wind Energy Technologies Office (WETO). While the traditional output of research is academic publication, software development efforts are increasingly a major focus. Software tools in the research environment allow researchers to describe an idea and quickly increase the scope and scale as they study it further. As a product of research, these tools represent a direct pipeline from researcher to industry practitioners since they are the implementation of ideas described in academic publications. Given this vital role in wind energy research and commercial development, the broad research software portfolio supported by WETO must maintain a minimum level of quality to support the wind energy field in the growing transition to renewable energy. This report outlines a series o f best practices to be adopted by all WETO-supported software projects, as well as expectations that the communities interacting with these projects should have of the developers and tools themselves. Wind energy research software has a unique standing in the field of scientific software. The stakeholders are varied with a subset being: (1) DOE EERE leadership, (2) DOE WETO leadership and program managers, (3) National lab leadership, (4) Associated project principle investigators, (5) Research software engineers, (6) Wind energy researchers in academia (including graduate students, post docs, and national lab staff), (7) Industry researchers and practitioners, (8) Commercial software developers, and (9) The general public interested in wind energy. These software are typically the end-user of other generic software libraries, so the funding cycles are often tied to applied research rather than the development of the software itself. Since the developers are also wind energy researchers, these tools are typically designed in a way that closely resembles the application in which they're used. Additionally, the expertise and incentives for the developers have a high variability, and often neither are aligned with software engineering or computer science. Given the unique environment in which wind energy research software is produced and consumed, it is critical for model owners to understand the context of their software. A framework for developing this understanding is to answer the following questions of a given software project: What is it's purpose? What is its role in the field of wind energy? What is the profile of the expected users? For how long will it be relevant? What is the expected impact? These questions allow model owners to identify the appropriate methods for the design, development, and long term maintenance of their software. Additionally, the answer provide context for future planners to understand why particular decisions were made and discern the consequences of changing course. The information is aggregated from experience within WETO-supported software development groups as well as external organizations and efforts to define the craft of research software engineering. These best practices aim to make the collaborative development process efficient and effective while improving the model understanding across stakeholders. Additionally, the general adoption of a common framework for software quality ensures that the end users of WETO software can trust these tools and accurately understand the risks to workflow integration.

17 WIND ENERGY↗
DOE OSTI2024

ORNL Package Testing Program Software Quality Assurance Plan

The Oak Ridge National Laboratory (ORNL) Package Testing Program (PTP) uses commercial off-the-shelf (COTS) software in performing data collection of thermal test results for package designs that contain radioactive materials. Specifically, this software is used to collect temperature data from the furnace, packages, and ambient air to prepare and execute the thermal test specified in 10 CFR 71.73, “Thermal Test.” This software quality assurance (SQA) plan sets forth the guidelines, standards, and procedures that shall be used to provide SQA for PTP software applications. This is a living document that will be maintained for the lifecycle of the PTP program. The SQA plan follows the requirements set forth in ORNL Standards Based Management System (SBMS): Information Technology; Subject Area: Software Quality Assurance. When applicable to the requirements as described in ORNL SBMS, Software Quality Assurance, the software shall be listed in the ORNL Software Registration System (SRS). Exemptions to this SBMS are COTS and firmware that are not modified; spreadsheet applications and personal productivity tools that do not have a utility or safety application, research applications, legacy software, system software, vendor-supplied software used to interface with the vendor’s services, software used within the organization to facilitate processing or management of information, and software developed for applications not specific to the US Department of Energy (DOE).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Feature review of photovoltaic modeling software utilizing blind performance assessment

While confidence in photovoltaic (PV) modeling software has always been essential, the rapid pace of new PV plant developments makes accuracy and credibility more critical than ever. Independent assessments, particularly through blind modeling comparisons, are therefore necessary to ensure unbiased benchmarking across PV modeling software. Previous studies have been limited by a narrow range of models compared, anonymized results, or system size. This study presents results from the first-ever onymous blind modeling comparison, evaluated using both lab- and utility-scale fixed-tilt, monofacial, south-facing systems at sub-hourly time intervals. Seven commercially used PV software tools were compared: 3E SynaptiQ, PlantPredict, PVsyst, RatedPower, SAM, SolarFarmer, and Solargis Evaluate. Predictions were submitted directly by software representatives, providing unique insights into each software’s implementation and resulting prediction behavior. Notable features, including plane-of-array (POA) transposition model, module temperature model, shading model, and performance model were analyzed and compared. Four summary tables compile these features of the software, serving as a resource to help users understand the methodological differences and select the most suitable software for their applications. The software tools show deviations from mean error in annual yield up to 2.5 % in the lab-scale system, increasing to 6.0 % for the utility-scale system. These differences arise from a combination of user decisions and the inherent behavior of the software, indicating the need for continuous and rigorous validation of modeling methods using these software tools against complex, real-world systems.

14 SOLAR ENERGY↗
DOE OSTI2025

Software Validation Work With The ZPPR-15 Data

The analysis activities for fast reactors involve using many different pieces of software that are relied upon for their predictive capabilities. For this software to be considered reliable, documented proof that the predictions of the software are accurate is required. In this manuscript, the validation work that covers some of the Argonne software used in fast reactor design activities is discussed and displayed. This validation work includes neutron and gamma flux distributions, reaction rate distributions, and reactivity worth. In an ideal world, a reactor development program would have access to a comprehensive set of experimental facilities to help inform the design aspects of the reactor itself. While thermal-hydraulics experiments, and to a limited degree mechanical experiments, can be carried out today for validation needs, neutronics related experimental facilities are rather impractical because of the lack of experimental facilities. Given the desired time table for construction of new reactors, the reconstitution or creation of new neutronic experimental facilities is untenable and thus those reactor development programs must rely upon any available experimental measurements that are qualitatively similar to the design. While a methodology has been proposed to assess the similarity between the past experimental measurements and the reactor itself, that aspect is beyond the scope of this manuscript. In this manuscript, the focus is entirely placed on the analysis results for a series of experiments carried out at the ZPPR facility in Idaho in the mid-1980s. In this regard, this manuscript only shows the validation of the stated neutronics software for specific loadings of the ZPPR reactor. Because of the fuel form, its proposed enrichment, and the material content of the reactor core, the ZPPR-15 experiments were identified as potential validation data for the reactor. The ZPPR-15 experiments were intended as mockups of a 330 MWe Integral Fast Reactor program which was a follow on program to the Clinch River Breeder Reactor. In the ZPPR-15 series of experiments, measurements of the neutron spectrum, control rod worth, sodium void worth, foil reaction rate distributions, Doppler worth of heated samples, gamma dose, and axial expansion worth were all carried out and published. In many cases, these reactivity coefficients are good candidates to validate the reactivity coefficient calculation scheme used by the analysis software and included in the safety analysis activities of fast reactor development projects today. This manuscript discusses the modeling methodology and accuracy of the calculated experimental results using the LANL software MCNP and the ANL software package ARC (Argonne Reactor Codes). As will be shown, for many of the experimental measurements, the two software packages are found to be good predictive analysis tools for those experiments. In other cases, problems with the analysis methodology or underlying cross section data are exposed which indicates where predictive analysis is not as reliable. Finally, in some of the measurements the conclusion is reached that the experimental measurement cannot be reproduced with the analysis software as it is simply too difficult.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2026

Software Validation Work With The ZPPR-15 Data

The analysis activities for fast reactors involve using many different pieces of software that are relied upon for their predictive capabilities. For this software to be considered reliable, documented proof that the predictions of the software are accurate is required. In this manuscript, the validation work that covers some of the Argonne software used in fast reactor design activities is discussed and displayed. This validation work includes neutron and gamma flux distributions, reaction rate distributions, and reactivity worth. In an ideal world, a reactor development program would have access to a comprehensive set of experimental facilities to help inform the design aspects of the reactor itself. While thermal-hydraulics experiments, and to a limited degree mechanical experiments, can be carried out today for validation needs, neutronics related experimental facilities are rather impractical because of the lack of experimental facilities. Given the desired time table for construction of new reactors, the reconstitution or creation of new neutronic experimental facilities is untenable and thus those reactor development programs must rely upon any available experimental measurements that are qualitatively similar to the design. While a methodology has been proposed to assess the similarity between the past experimental measurements and the reactor itself, that aspect is beyond the scope of this manuscript. In this manuscript, the focus is entirely placed on the analysis results for a series of experiments carried out at the ZPPR facility in Idaho in the mid-1980s. In this regard, this manuscript only shows the validation of the stated neutronics software for specific loadings of the ZPPR reactor. Because of the fuel form, its proposed enrichment, and the material content of the reactor core, the ZPPR-15 experiments were identified as potential validation data for the reactor. The ZPPR-15 experiments were intended as mockups of a 330 MWe Integral Fast Reactor program which was a follow on program to the Clinch River Breeder Reactor. In the ZPPR-15 series of experiments, measurements of the neutron spectrum, control rod worth, sodium void worth, foil reaction rate distributions, Doppler worth of heated samples, gamma dose, and axial expansion worth were all carried out and published. In many cases, these reactivity coefficients are good candidates to validate the reactivity coefficient calculation scheme used by the analysis software and included in the safety analysis activities of fast reactor development projects today. This manuscript discusses the modeling methodology and accuracy of the calculated experimental results using the LANL software MCNP and the ANL software package ARC (Argonne Reactor Codes). As will be shown, for many of the experimental measurements, the two software packages are found to be good predictive analysis tools for those experiments. In other cases, problems with the analysis methodology or underlying cross section data are exposed which indicates where predictive analysis is not as reliable. Finally, in some of the measurements the conclusion is reached that the experimental measurement cannot be reproduced with the analysis software as it is simply too difficult.

Aliberti, Gerardo↗
DOE OSTI2024

Building Performance Software: Portfolio-Level Capabilities and Applications

Navigating the broad and rapidly evolving market landscape of software solutions is complex whether you are a sustainability leader, building owner, energy manager, or building engineer with energy and greenhouse gas (GHG) emissions reduction goals for a portfolio of buildings. The Department of Energy’s Better Buildings partners have noted this complexity and the associated lack of publicly available information. In response, this report reviews the ecosystem of environmental, social, and governance (ESG), energy management information systems (EMIS), and decarbonization software with the goal of orienting prospective users to current offerings. Organizations can utilize this guidance to determine the specific capabilities needed to support decarbonization efforts and procure appropriate software to streamline the GHG emissions reduction process. In this paper, we refer to “decarbonization software” as the category of software that meets an organization’s needs for decarbonization planning, implementation, and tracking. This software may have a heritage in ESG or EMIS, or it may be an entirely new product. This report offers a snapshot of today’s rapidly evolving decarbonization software capabilities, along with guidance for procuring and utilizing it that will remain relevant despite any future software changes. Exploratory research was conducted on over 100 software providers, and interviews were held with 28 of them. Note that inclusion in this report does not indicate an endorsement, nor does a product’s absence from this report indicate a lack of suitability

97 MATHEMATICS AND COMPUTING↗