Search NASA⌕ Search

SEARCH · Search NASA

Results for “user support”

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

Better together: Elements of successful scientific software development in a distributed collaborative community

Many scientific disciplines rely on computational methods for data analysis, model generation, and prediction. Implementing these methods is often accomplished by researchers with domain expertise but without formal training in software engineering or computer science. This arrangement has led to underappreciation of sustainability and maintainability of scientific software tools developed in academic environments. Some software tools have avoided this fate, including the scientific library Rosetta. We use this software and its community as a case study to show how modern software development can be accomplished successfully, irrespective of subject area. Rosetta is one of the largest software suites for macromolecular modeling, with 3.1 million lines of code and many state-of-the-art applications. Since the mid 1990s, the software has been developed collaboratively by the RosettaCommons, a community of academics from over 60 institutions worldwide with diverse backgrounds including chemistry, biology, physiology, physics, engineering, mathematics, and computer science. Developing this software suite has provided us with more than two decades of experience in how to effectively develop advanced scientific software in a global community with hundreds of contributors. Here we illustrate the functioning of this development community by addressing technical aspects (like version control, testing, and maintenance), community-building strategies, diversity efforts, software dissemination, and user support. We demonstrate how modern computational research can thrive in a distributed collaborative community. The practices described here are independent of subject area and can be readily adopted by other software development communities

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

US Department of Energy, Office of Science High Performance Computing Facility Operational Assessment 2019 Oak Ridge Leadership Computing Facility

Oak Ridge National Laboratory's (ORNL's) Leadership Computing Facility (OLCF) continues to surpass its operational target goals: supporting users; delivering fast, reliable computational ecosystems; creating innovative solutions for high performance computing (HPC) needs; and managing risks, safety, and security associated with operating some of the most powerful computers in the world. The results can be seen in the cutting-edge science conducted by users and the praise from the research community. Calendar year (CY) 2019 was a big year as OLCF staff ran five world-class resources (the leadershipclass computers Titan and Summit, the large analysis cluster called Eos, and the massive parallel filesystems called Atlas and Alpine)) and also began power and cooling upgrades for a 2021 exascale system called Frontier. While continuing exceptional operation of Titan, Eos, and Rhea, the OLCF released the Summit supercomputer for production on January 1, 2019. Summit debuted as the most capable and efficient system in its class and has been recognized as the most powerful system in the world for its performance on both the high performance linpack (HPL) and conjugate gradient (HPCG) benchmark applications since June 2018 according to TOP500. Summit represents the culmination of a multiyear effort between the OLCF, IBM, NVIDIA, and Mellanox to deliver a system that is unmatched for modeling, simulation, data analysis, and learning. To hit the ground running with science-ready applications on day one, application teams worked closely with the OLCF through the Center for Accelerated Application Readiness (CAAR) program for years in advance of the Summit deployment. CY 2019 was filled with outstanding results and accomplishments: a very high rating from users on overall satisfaction for the sixth year in a row; a tremendous amount of core-hours delivered to researchers from two leadership-class systems; and success in delivering on the allocation split of roughly 60%, 30%, and 10% of core-hours offered for the Innovative and Novel Computational Impact on Theory and Experiment (INCITE), Advanced Scientific Computing Research Leadership Computing Challenge (ALCC), and Director's Discretionary (DD) programs, respectively (see Operational Performance section). These accomplishments, coupled with the high utilization rates (overall and capability usage), represent the fulfillment of the promise of both leadership-class machines: efficient facilitation of leadership-class computational applications. Table ES.1 presents a summary of the 2019 OLCF metric targets and the associated results. More information can be found in the Operational Performance section for each OLCF resource. The scientific accomplishments of OLCF users are a strong indication of long-term operational success, with publications this year in such notable journals and publications as Nature, Nature Physics, Nature Plants, Physical Review X, Journal of the American Physical Society, Cell, Nano Letters, and Trends in Biotechnology. Crucial domain-specific discoveries facilitated by resources at the OLCF are described in the High Performance Computing Facility Operational Assessment 2019 Oak Ridge Leadership Computing Facility (OAR) Strategic Results section. For example, researchers used Summit to pinpoint and understand the production of proteins from genetic information, including mutations and the functional expression of disease (Section 8.2).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Assessment of Modeling and Nuclear Data Needs for Active Neutron Interrogation

This document is the primary deliverable for a scoping study proposed to DOE National Laboratory Announcement Number LAB 19-2114 in the NNSA research area. The study supports user applications employing active neutron interrogation by providing a science plan to improve the modeling capability and the nuclear data that radiation transport codes use. Users rely on the accuracy of the elastic scattering and non-elastic cross-sections spanning thermal energies to 14 MeV (and higher in some cases) for modeling the neutron transport through complex geometries of materials potentially composed of many elements. While the elastic scattering cross-section data are accepted for all commonly occurring elements, the non-elastic cross-section data and the associated emission data include reaction channels that require attention. The study focused on the non-elastic reactions that emit secondary, also known as prompt, gammas with the premise that many users would benefit from improved modeling of these reactions. Many users develop material assay technologies based upon gamma signatures from radiative capture, inelastic scattering, and reactions on low-Z isotopes emitting multiple particles, so the nuclear data gaps, modeling deficiencies, and recommendations for addressing the shortfalls were assessed for these reactions. Fission gammas were excluded from this study because there are other efforts underway to address known shortfalls. Follow-on efforts that successfully execute the recommendations will tangibly improve to the ability to model gamma signatures and backgrounds for user applications, such as controlled substance detection, oil-well logging, and space exploration.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2023

Software Quality Assurance Plan: Argonne Reactor Code Software

The Argonne Reactor Code (ARC) software package consists of 13 primary and many secondary pieces of software that are connected through interface files. The ARC software suite supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2023

Code Coverage Status of ARC Code-DIF3D

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC Code DIF3D

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC Code RCT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. REBUS plays a pivotal role in the ARC system as the primary fuel cycle analysis capability for fast reactor problems. Over its 60 year history, ARC software usage with REBUS has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. The RCT code is a later addition and uses the REBUS restart files to define its input. The RCT code was built to provide pin depletion details on EBR-II models and thus many features of RCT were specifically tailored to the needs of EBR-II models. Additional approximations were invoked which are likely only valid for the EBR-II reactor and the particular fuel management that was done for it. The purpose of the present work is to identify a set of test problems for RCT and assess the code coverage for those test problems. The goal is to document what parts of the existing RCT code are touched by the set of test problems and which are not. Because no detailed verification work has been done on RCT, the existing regression testing suite was chosen for the code coverage assessment. The code coverage analysis of RCT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of RCT. The detailed coverage tables are given for each part of RCT. As will be discussed and shown, some parts of the RCT capability that are known to be used by the EBR-II analysis work are not tested by the regression testing suite. These aspects should be resolved before major source code changes are taken for the RCT software. Because REBUS and DIF3D are not subroutines of RCT, the coverage changes in both of those codes is not altered by RCT. The same is true for all of the modules of DIF3D that are used by RCT such as SYSLIB and SEGLIB.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC Code PERSENT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. PERSENT fulfills the role of generating reactivity coefficients for a given time point of a REBUS calculation usable in a point kinetics based safety analysis capability. PERSENT also provides a sensitivity coefficient capability on eigenvalue, reactivity worth, and several other key coefficients that are used in the follow-on safety analysis. Given a co-variance matrix, PERSENT can carry out the uncertainty quantification to indicate the amount of error in the reactivity coefficients derived from the errors in the cross section measurements. With continued improvement of computational resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. PERSENT is part of the ARC code system and is built around DIF3D-VARIANT and the flux solution it provides. The purpose of the present work is to identify a set of test problems for PERSENT and assess the code coverage of PERSENT for those test problems. PERSENT treats the DIF3D executable as an external executable and thus the code coverage considerations only need to focus on the PERSENT source code and only a fraction of the connected modules in the existing ARC software library. The goal is to document what parts of the existing PERSENT code are touched by the set of test problems and which are not. Because the verification work done on PERSENT was focused on the most common uses of PERSENT for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that users of PERSENT rely upon. The code coverage analysis of PERSENT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of PERSENT. The detailed coverage tables are given for each submodule of PERSENT. Most of the uncovered parts/files could be easily ignored because they are either for error message and debugging output or not needed by PERSENT today. Only a few uncovered parts of PERSENT deserve extending the verification test suite.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC code GAMSRC

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. GAMSOR serves as procedure to obtain the neutron and gamma power distribution information in the ARC code system. GAMSOR is a specially modified version of DIF3D (dif3d.x becomes dif3d_gamsor.x). After some work, it was determined that carrying out software on GAMSOR was impractical and would not fit well with commercial grade dedication. GAMSRC was written in the last decade to replace GAMSOR such that the user can rely soley upon the verified DIF3D (dif3d.x) code and GAMSRC to obtain the neutron and gamma power distribution information. GAMSRC is also fully verified and ready for commercial grade dedication. In the coming years, GAMSOR will be deprecated and GAMSRC will fully take over in the ARC code system. This document identifies the set of test problems used to assess the code coverage for GAMSRC. The goal is to document what parts of the existing GAMSRC code are touched by the set of test problems and which are not. The code coverage analysis of GAMSRC was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of GAMSRC. The code coverage tables are given for each submodule of GAMSRC. Because GAMSRC links to modules in DIF3D, some details on coverage changes to the DIF3D lined files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by GAMSRC today.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC Code DASSH-F

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DASSH-F serves as a steady state thermal hydraulic capability within the ARC system and replaces the SE2-ANL software that preceded it. This document identifies the set of test problems used to assess the code coverage for DASSH-F. The goal is to document what parts of the existing DASSH-F code are touched by the set of test problems and which are not. Because the verification work remains to be done on DASSH-F, one can assume that most of these issues will be resolved as part of that work. The code coverage analysis of DASSH-F was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DASSH-F. The code coverage tables are given for each submodule of DASSH-F. Because DASSH-F links to modules in DIF3D, some details on coverage changes to the DIF3D linked files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by DASSH-F today. Seven features of the DASSH-F code were identified to not be covered by the existing testing suite and thus additional verification test problems are suggested to fully cover these sections.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2026

Elevating SolTrace's Capabilities for the Next Generation of Concentrating Solar Analysis

SolTrace is an open-source Monte Carlo ray tracing software developed at NREL. SolTrace can characterize concentrating solar thermal (CST) collector optical performance and is CST technology agnostic. Shown in Fig. 1, SolTrace is a foundational tool in NREL's CST system and component modeling suite. SolTrace's generic surface elements can flexibly model novel collector and receiver designs to predict spatial and temporal flux distributions - critical to understand for CST component design, performance prediction, and system integration. Since its initial development, SolTrace has over 1,650 references on Google Scholar, over 9,800 downloads since 2017, and has served the CST research and development community as a benchmark of 3rd party verification. SolTrace provides users with many options for defining surface shape and boundaries. However, SolTrace provides limited documentation which can result in a steep learning curve for new users. Additionally, SolTrace lacks the computational performance required to evaluate optical performance of a CST system over the course of a year and/or iteratively over design parameters in a timely manner. To address this, we are working towards a new release of SolTrace that enables increased computational throughput by implementing ray tracing acceleration structures and enabling GPU parallelization. Additionally, we are working to improve SolTrace's usability, accessibility, and maintainability by (1) automating solar position time-dependent simulation processes, (2) creating general CST collector templates of grouped elements, (3) updating the user interface to better visualize model inputs and outputs, and (4) creating a user support network through forums, "how to" videos, and documentation.

14 SOLAR ENERGY↗
DOE OSTI2020

Brilliant Execution of Smart Labs: Employing Best Practices to Improve Safety and Reduce Energy for Sustainable Labs: Preprint

Laboratory buildings often dominate the energy use on research campuses, consuming three to four times the energy of a typical office building. In most cases, these facilities are defined as “mission critical,” with excessive energy use as simply an unfortunate truth that cannot be avoided without compromising safety. However, case studies indicate cost savings opportunities of up to 40% in laboratories (compared to standard practices) by employing energy efficient design strategies that also improve the safety of lab spaces (Better Buildings 2018). To help stakeholders implement improvement measures, the Smart Labs Toolkit describes a proven approach to optimizing performance of laboratories and critical control environments in new or existing facilities. The Toolkit outlines distinct phases for building a successful Smart Labs program that include: Plan, Assess, Optimize, and Manage. Each phase has specific tasks, training videos, and resources to educate users, support the efforts of key stakeholders, and maximize benefits for the organization in implementing high-performance labs. The Toolkit also includes case studies from the 17 Better Buildings Smart Labs Accelerator partners, sharing lessons learned and supporting the Smart Labs approach to safe, efficient world class science. This paper reviews the technology choices for implementing Smart Labs ventilation strategies, controls, and other efficiency measures. Better Building Smart Lab Accelerator partners provide case study examples of safety and energy-savings results of using Smart Labs approaches.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
DOE OSTI2022

Portability: A Necessary Approach for Future Scientific Software

Today's world of scientific software for High Energy Physics (HEP) is powered by x86 code, while the future will be much more reliant on accelerators like GPUs and FPGAs. The portable parallelization strategies (PPS) project of the High Energy Physics Center for Computational Excellence (HEP/CCE) is investigating solutions for portability techniques that will allow the coding of an algorithm once, and the ability to execute it on a variety of hardware products from many vendors, especially including accelerators. We think without these solutions, the scientific success of our experiments and endeavors is in danger, as software development could be expert driven and costly to be able to run on available hardware infrastructure. We think the best solution for the community would be an extension to the C++ standard with a very low entry bar for users, supporting all hardware forms and vendors. We are very far from that ideal though. We argue that in the future, as a community, we need to request and work on portability solutions and strive to reach this ideal.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2022

Components of aircraft life support systems interact with each other and the user

The life support system in a tactical aircraft provides necessary supplemental oxygen to the aircrew. However, interactions among its various components may generate unexpected breathing loads. We focus here on the interactions between a regulator and breathing mask commonly used together in the U.S. Navy, the CRU-103 regulator and MBU 23/P mask, and some effects of the interactions on the user. The data reported were collected during a larger research effort examining potential physiological and cognitive effects of low regulator inlet pressures. Seventeen participants completed a series of tasks under mild exercise while breathing 40% O 2 (balance N 2 ) from an MBU-23/P mask supplied by a CRU-103 regulator with supply pressures 10, 6, 4, and 2 psig (CRU-103 specifications are for inlet pressures from 5 to 120 psig). Variables measured included flow to the mask and pressures at the regulator supply, in the hose to the mask, and in the mask. In addition to restricting inspiratory flow, low inlet pressure to the CRU-103 caused a counterintuitive overshoot in gas delivery pressure at end-inspiration, a mean increase of 1.5 cm H 2 O between the 10- and 2 psig conditions. The added pressure to the exhalation valve increased the expiratory threshold, the pressure to start expiratory flow, by approximately 2 cm H 2 O, increasing the effort needed to exhale.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2024

A graphical user interface platform to support power electronic converters and integrated systems

Power Electronic Systems have grown in size and complexity over the past years. Therefore, users require interfaces to properly configure, develop, and deploy these systems. This work presents a Graphical User Interface that dynamically adapts to the system and allows the user to control and monitor its operation. This GUI uses networked communication and open-source Python libraries to allow the user to interact with the system at its different hierarchical layers, as well as visualize the interconnection of the full system. This is demonstrated by showing the user interface applied to a megawatt class charging station that consists of various energy resources.

Dean, Ben↗
DOE OSTI2023

Resolving experimental biases in the interpretation of diffusion experiments with a user-friendly numerical reactive transport approach

The reactive transport code CrunchClay was used to derive effective diffusion coefficients (D e ), clay porosities (ε), and adsorption distribution coefficients (K D ) from through-diffusion data while considering accurately the influence of unavoidable experimental biases on the estimation of these diffusion parameters. These effects include the presence of filters holding the solid sample in place, the variations in concentration gradients across the diffusion cell due to sampling events, the impact of tubing/dead volumes on the estimation of diffusive fluxes and sample porosity, and the effects of O-ring-filter setups on the delivery of solutions to the clay packing. Doing so, the direct modeling of the measurements of (radio)tracer concentrations in reservoirs is more accurate than that of data converted directly into diffusive fluxes. While the above-mentioned effects have already been described individually in the literature, a consistent modeling approach addressing all these issues at the same time has never been described nor made easily available to the community. A graphical user interface, CrunchEase, was created, which supports the user by automating the creation of input files, the running of simulations, and the extraction and comparison of data and simulation results. While a classical model considering an effective diffusion coefficient, a porosity and a solid/solution distribution coefficient (D e –ε–K D ) may be implemented in any reactive transport code, the development of CrunchEase makes it easy to apply by experimentalists without a background in reactive transport modeling. CrunchEase makes it also possible to transition more easily from a D e –ε–K D modeling approach to a state-of-the-art process-based understanding modeling approach using the full capabilities of CrunchClay, which include surface complexation modeling and a multi-porosity description of the clay packing with charged diffuse layers.

58 GEOSCIENCES↗
DOE OSTI2025

OpenCSP Step-by-Step: Getting Started Guide for Windows (V.1.0)

This document provides a step-by-step tutorial on how to set up OpenCSP for both users and developers. It is meant to support novice users and does not require software engineering experience. It is a detailed extension of the OpenCSP getting started on-line documentation, found here: https://opencsp.readthedocs.io/en/main/contributing.html#getting-started. For an overview of OpenCSP overall, see the OpenCSP website: https://opencsp.sandia.gov. For details on OpenCSP components and algorithm, see the references.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

FY25 MOOSE Usability Improvements: 3D Meshing Capabilities, Initiation of Geometry Support for Monte Carlo Tools, and Enhancement of MOOSE/Workbench User Input Interactions

Usability improvements have been made to MOOSE and Workbench in FY25 to enhance usability and user workflows. Assorted enhancement have been made to MOOSE’s intrinsic meshing capabilities in order to enable more flexible and complex meshing of nuclear reactor systems, in particular for 3D applications. Mesh generators have been added to perform operations such as batch mesh generation, surface mesh generation, and creation of 3D transition layers. These mesh generation capabilities make it much easier to generate high quality non-extruded 3D meshes. Additionally, work to integrate Monte Carlo reactor physics simulations into MOOSE-based multi-physics workflows has reached another milestone with the implementation of the Constructive Solid Geometry (CSG) base framework. This framework lays the foundation for mesh generators to offer the user a generic CSG output option (as opposed to a finite element mesh). To support users, workshop on the MOOSE Reactor Module was delivered which featured hands-on examples using the NEAMS Workbench on INL’s High Performance Computing system. Recent updates to the NEAMS Workbench, WASP, and the MOOSE language server have introduced several improvements aimed at making MOOSE-based simulation setup and input management faster, more accurate, and easier to use. Key capabilities that have been added include multi-tab-stop autocompletion, visual input diagnostics, developer-directed data visualizations, upgraded ParaView integration, and Workspace-level file tracking. Together, these changes make it easier for users to build, validate, and manage complex MOOSE-based simulation models — especially those involving reusable components, included files, and datasets. The improvements are designed to save time, reduce input errors, and help users get to a successful simulation run faster, with more confidence in the results.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗