Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “computer bugs”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

The IRAS Minor Planet Survey

This report documents the program and data used to identify known asteroids observed by the Infrared Astronomical Satellite (IRAS) and to compute albedos and diameters from their IRAS fluxes. It also presents listings of the results obtained. These results supplant those in the IRAS Asteroid and Comet Survey, 1986. The present version used new and improved asteroid orbital elements for 4679 numbered asteroids and 2632 additional asteroids for which at least two-opposition elements were available as of mid-1991. It employed asteroid absolute magnitudes on the International Astronomical Union system adopted in 1991. In addition, the code was modified to increase the reliability of associating asteroids with IRAS sources and rectify several shortcomings in the final data products released in 1986. Association reliability was improved by decreasing the position difference between an IRAS source and a predicted asteroid position required for an association. The shortcomings addressed included the problem of flux overestimation for low SNR sources and the systematic difference in albedos and diameters among the three wavelength bands (12, 25, and 60 micrometers). Several minor bugs in the original code were also corrected.

Tedesco, Edward F.↗
DOE OSTI2023

Verification and Validation of the New MCNP6.3 Criticality Features

The MCNP6® code, version 6.3, has been extensively verified and validated for many applications. The use of the same default capabilities existing in the MCNP6.2 code are also used in the verification and validation (V&V) of the MCNP6.3 code. In this paper, selected new features, code enhancements, and bug fixes in the MCNP6.3 code that impact criticality safety applications are described and investigated. More specifically, the changes within the MCNP6.3 code that are studied in this work include both the new fission matrix and the Doppler broadening resonance correction (DBRC) features. For nuclear criticality safety applications, the V&V benchmark problems within the criticality, extended criticality, and Rossi-α suites are used to study the upgrades within the MCNP6.3 code. Some additional investigations into benchmarks at elevated temperatures are used to showcase the impacts of the temperature-specific capabilities.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

DRiFT - Release 1.0.0 Organic Scintillators

DRiFT (a Detector Response Function Toolkit) is LANL-developed software that postprocesses output from the extensively validated radiation transport code, MCNP [1], and generates realistic nuclear instrumentation response. DRiFT is designed to be flexible, enabling users to specify detector type and many experimental settings, as well as accommodating the addition of their own desired features. Although DRiFT development has included scintillator [2], gas [3], and semiconductor features [4], the focus of this release is on organic scintillator and associated capabilities. Organic scintillators are widely used in the areas of nuclear safeguards and nuclear non-proliferation efforts [5, 6]. DRiFT has several diagnostic and detector physics features relevant to detailed scintillator simulations including: tracking source particle information, scintillation light production, the effects of PMT quantum efficiency and gain, and digitizer settings. Users can select responses from many scintillator and PMT types supported natively by DRiFT, or add their own by following the instructions in this document. We acknowledge that DRiFT is under active development, bug reports and general questions and comments should be directed to Madison Andrews, madison@lanl.gov. This manual is divided into four parts: I) An overview of DRiFT, including how to obtain and install the executable, II) A description of the detector physics related to scintillators available, III) a description of more general DRiFT features the user may find useful, and IV) a description of the test suite and examples made available with the code release.

61 RADIATION PROTECTION AND DOSIMETRY↗
DOE OSTI2024

Hardware Fuzzing with An Emulator

Bugs in digital logic have led to some significant security vulnerabilities. Hardware bugs are particularly troublesome since they cannot be easily patched. Additionally, if the bug is in the root of trust, all trust built upon it can be vulnerable. Traditional testing either require a deep knowledge of the system, creative attack vectors and lots of human interaction. This is not scalable as there are very few engineers that can wear the hat of a designer, a verification engineer, and a cybersecurity expert. Hardware fuzzing is a relatively new research area in dynamic hardware testing. It has proven to be an effective method for discovering bugs, unexpected behaviors, and security vulnerabilities in software. While hardware fuzzing is new to the hardware domain, it has a strong track record in software testing. Fuzzing is a testing technique that randomly mutates the input data to uncover bugs or vulnerabilities in the design. It is especially good at finding corner cases that test engineers can not envision. Another advantage over other dynamic testing techniques is that, if done well, deep knowledge of the design is not required. Additionally, fuzzing scales well. If the system is set up correctly, it can run unsupervised for weeks if necessary. In this work, we propose using hardware fuzzing to improve the input vector generation for an information flow tracking tool. To get reasonable throughput of test vectors, an emulator is targeted as the execution platform. Efficient emulator execution has some specific requirements.

42 ENGINEERING↗
DOE OSTI2025

DIF3D-VARIANT 12.0: Updates and New Features

The DIF3D code has been a workhorse of fast reactor analysis work at Argonne National Laboratory for over 40 years. In 1995, a transport option called VARIANT was added to DIF3D to improve the flux solutions for fast reactor problems which we term DIF3D-VARIANT today. DIF3D-VARIANT performs nodal neutron transport calculations using P N or SP N theory in Cartesian and hexagonal two- and three-dimensional geometries. The limited computing capabilities of the time restricted DIF3D-VARIANT to use at most a 6 th order spatial approximation combined with a P3 flux approximation and P1 scattering kernel for a 33 group structure on most studied reactor problems. Computer capabilities have increased steadily since 1995 and today much larger space-angle-energy approximations are possible. This manuscript serves as an update to the theory section of the original DIF3D-VARIANT manual and details more than twenty years of changes made to DIF3D to make version 12 which was released on November 1 st , 2024. The primary focus of the initial work was to extend the space-angle approximations available in DIF3D-VARIANT such that the error due to transport approximations could be better understood. This work was started and completed in 2002 and marked the official version 10. Unfortunately, those higher order approximations could not be used at that time due to the memory constraints of the BPOINTER part of DIF3D (limited to 2 GB). In version 11, completed in 2012, BPOINTER was circumvented in DIF3D-VARIANT for the largest arrays by introducing a Fortran 90 module called LMA (Large Memory Array). This seamlessly replaces all of the functionality of the BPOINTER concept, but it allows 64 bit addressing for every array such that they can be larger than 2 GB. It is now common for DIF3D-VARIANT jobs to consume 50 GB of memory on modern workstations when using high order space-angle approximations and a large number of groups. Many improvements were made to version 11 from 2012 to 2022 when work to create version 12 started. For version 12, several parts of DIF3D were updated to improve performance and thread parallelism was introduced to further reduce the runtime. Numerous minor bugs were discovered in DIF3D-VARIANT as part of the process of creating the perturbation and sensitivity code PERSENT. All of these algorithmic problems were identified in the transition from version 10 to version 11 which prevented DIF3D-VARIANT from running efficiently and reliably. Firstly, the coarse mesh rebalance scheme would routinely diverge and a study detailed in this report demonstrates how it was also typically not effective. This is not a failure of the coarse mesh rebalance methodology, but a failure of its implementation in DIF3D-VARIANT for hexagonal geometries. The fission source extrapolation algorithm was also found to be unreliable on larger group structure problems, leading to divergence in some cases and a negligible improvement in performance overall. Finally, the “Omega” acceleration applied to the partial current solver routine of DIF3D-VARIANT was found to cause DIF3D-VARIANT to converge to the wrong answer. To resolve these issues, both the coarse mesh rebalance and fission source extrapolation were permanently disabled in version 11. The Tchebychev acceleration was put in as a temporary reliable alternative but it is generally inferior to coarse mesh rebalance or coarse mesh finite difference. For the Omega acceleration, the factor was restricted to guarantee that it would not cause follow-on errors in PERSENT. Due to limited funding to support maintenance and development of DIF3D in the last 10 years, no effort was spent since to resolve the outer iteration acceleration. Except for the threading work, all of the changes discussed in this manuscript refer to changes made between version 10 and version 11. Performance comparisons are done to demonstrate the improvements from version 9 to version 12. As will be demonstrated, the updated versi

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2024

IDAES-PSE 2.6.0 Release

The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications. IDAES-PSE 2.6.0 Release Highlights Upcoming Changes IDAES will be switching to the new Pyomo solver interface in the next release. Whilst this will hopefully be a smooth transition for most users, there are a few important changes to be aware of. The new solver interface uses a different version of the IPOPT writer (“ipopt_v2”) and thus any custom configuration options you might have set for IPOPT will not carry over and will need to be reset. By default, the new Pyomo linear presolver will be activated with ipopt_v2. Whilst are working to identify any bugs in the presolver, it is possible that some edge cases will remain. IDAES will begin deploying a new set of scaling tools and APIs over the next few releases that make use of the new solver writers. The old scaling tools and APIs will remain for backward compatibility but will begin to be deprecated. New Models, Tools and Features New Intersphinx extension automatically linking Jupyter notebook examples to project documentation New end-to-end diagnostics example demonstrated on a real problem New complementarity formulation for VLE with cubic equations of state, backward compatibility for old formulation New solver interface with presolve (ipopt_v2) in support of upcoming changes to the initialization and APIs methods, with default set to ipopt to maintain backwards compatibility; this will deprecate once all examples have been updated New forecaster and parameterized bidder methods within grid integration library Updated surrogates API and examples to support Keras 3, with backwards compatibility for older formats such as TensorFlow SavedModel (TFSM) Updated costing base dictionary to include the 2023 cost year index value Updated ProcessBlock to include information on the constructing block class Updated Flowsheet Visualizer to allow visualize() method to return value and functions Bug Fixes Fixed bug in the Modular Property Framework that would cause errors when trying to use phase-based material balances with phase equilibria. Fixed bug in Modular Properties Framework that caused errors when initializing models with non-vapor-liquid phase equilibria. Fixed typos flagged by June update to crate-ci/typos and removed DMF-related exceptions Minor corrections of units of measurement handling in power plant waste/transport costing expressions, control volume material holdup expressions, and BTX property package parameters Fixed throwing >7500 numpy deprecation warnings by replacing scalar value assignment with element extraction and item iteration calls Testing and Robustness Migrated slow tests (>10s) to integration, impacting test coverage but also yielding a nearly 30% decrease in local test runtime Pinned pint to avoid issues with older supported Python versions Pinned codecov versions to avoid tokenless upload behavior with latest version Bumped extensions to version 3.4.2 to allow pointing to non-standard install location Deprecations and Removals Python 3.8 is no longer supported. The supported Python versions are 3.9 through 3.12 The Data Management Framework (DMF) is no longer supported. Importing idaes.core.dmf will cause a deprecation warning to be displayed until the next release The SOFC Keras surrogates have been removed. The current version of the SOFC surrogate model in the examples repository is a PySMO Kriging model.

AS↗
DOE OSTI2022

Binary-level Software Compatibility Tool Agreement

Application Binary Interface (ABI) compatibility is essential for system or software updates to ensure that libraries continue to function. Tools that can assess a binary or library ABI can thus be used to make predictions about compatibility, and predict downstream bugs by informing developers and users about issues. In this work, we are interested in describing a set of well-known tools for assessing ABI, and testing them in a controlled set experiments to assess tool agreement. We run 7660 smaller experiments across tools (N=30,640 total results) to evaluate not only predictions, but also each tool’s ability to provide detail about underlying issues. In this paper, along with highlighting the problem of assessing ABI compatibility and critiquing the pros and cons of currently available tools, we provide guidance to developers interested to test ABI based on our empirical results and suggestions for future work.

ABI↗
DOE OSTI2024

IDAES-PSE 2.5.0 Release

The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost, most environmentally sustainable solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications. IDAES-PSE 2.5.0 Release Highlights Upcoming Changes IDAES will be switching to the new Pyomo solver interface in the next release. Whilst this will hopefully be a smooth transition for most users, there are a few important changes to be aware of. The new solver interface uses a different version of the IPOPT writer (“ipopt_v2”) and thus any custom configuration options you might have set for IPOPT will not carry over and will need to be reset. By default, the new Pyomo linear presolver will be activated with ipopt_v2. Whilst are working to identify any bugs in the presolver, it is possible that some edge cases will remain. IDAES will begin deploying a new set of scaling tools and APIs over the next few releases that make use of the new solver writers. The old scaling tools and APIs will remain for backward compatibility but will begin to be deprecated. New Models, Tools and Features New diagnostics check for near-parallel variables and constraints. New diagnostics tools for identifying causes of infeasibility in models. New example for creating a custom model of a liquid-liquid extractor unit operation. Bug Fixes Fixed bug in Gibbs reactor that caused it to appear to have additional spurious degrees of freedom. Fixed bug in the Modular Property Framework that would cause errors when trying to use phase-based material balances with phase equilibria. Fixed bug in Modular Properties Framework that caused errors when initializing models with non-vapor-liquid phase equilibria. Testing and Robustness Deployed the IDAES Diagnostics Toolbox to confirm that there are no structural or numerical issues in the core model libraries. Additional robustness tests for core model, and some associated improvements in the converge tester class. Fixed a number of issues that were causing unexpected warnings to be emitted during testing. Deprecations and Removals Removed examples for RIPE tool which has not been supported for a number of releases.

AS↗
DOE OSTI2025

Asymptotic-preserving dynamical low-rank method for the stiff nonlinear Boltzmann equation

In kinetic theory, numerically solving the full Boltzmann equation is extremely expensive. This is because the Boltzmann collision operator involves a high-dimensional, nonlinear integral that must be evaluated at each spatial grid point and every time step. The challenge becomes even more pronounced in the fluid (strong collisionality) regime, where the collision operator exhibits strong stiffness, causing explicit time integrators to impose severe stability restrictions. In this paper, we propose addressing this problem through a dynamical low-rank (DLR) approximation. The resulting algorithm requires evaluating the Boltzmann collision operator only r 2 times, where r, the rank of the approximation, is much smaller than the number of spatial grid points. We propose a novel DLR integrator, called the XL integrator, which reduces the number of steps compared to the available alternatives (such as the projector splitting or basis update & Galerkin (BUG) integrator). For a class of problems including the Boltzmann collision operator which enjoys a separation property between physical and velocity space, we further propose a specialized version of the XL integrator, called the sXL integrator. This version requires solving only one differential equation to update the low-rank factors. Furthermore, the proposed low-rank schemes are asymptotic-preserving, meaning they can capture the asymptotic fluid limit in the case of strong collisionality. Our numerical experiments demonstrate the efficiency and accuracy of the proposed methods across a wide range of regimes, from non-stiff (kinetic) to stiff (fluid).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

A Verification of Flux Sensitivity Estimates Using the MCNP Tally Perturbation Tool

Nuclear data is commonly used in applications such as nuclear nonproliferation, safeguards, and criticality safety. More specifically, nuclear data is used in predictive simulation codes like the Monte-Carlo N-Particle (MCNP ® ) transport code, Serpent, and similar radiation transport codes. The improvement of nuclear data enables more precise and accurate simulations, which result in higher fidelity designs and reduced operational/procedural costs. Therefore, the improvement of nuclear data is of paramount importance across the nuclear community. Nuclear data is improved and validated through integral benchmark experiments. The design of benchmark experiments is an extensive process; therefore, these experiments are often optimized on multiple characteristics, including sensitivity to the nuclear data, during the design process. Sensitivity is a measure of how much a quantity changes due to changes in independent variables such as experimental configuration. An experimental design that has a larger sensitivity to the nuclear data of interest will have a larger impact on the accuracy and precision of the validated data. Past integral benchmark experiments have primarily used the effective multiplication factor ($k_{eff}$) as the predominant measured quantity; however, experiments designed with other quantities in mind would be able to optimize on validating different areas of the nuclear data. A primary goal of the EUCLID project is to design, constrain, and reduce compensating errors in experiments focused on quantities other than $k_{eff}$ to better validate nuclear data across the board. Currently, there is a capability in MCNP to easily calculate the sensitivity of $k_{eff}$ to specific nuclear data of numerous reactions types and isotopes (KSEN card); however, the sensitivity of other quantities must be estimated in more strenuous manners. For example, the perturbation feature (PERT card) of MCNP can be used to estimate first-order sensitivities of some response in fixed source simulations. A recent announcement revealed that the first- and second-order perturbation features in previous releases of MCNP contained a bug. It was identified that particles were being scored into the wrong energy bin. The bug is in the most recent public release (MCNP6.2); however, a patch has been added to the most up to date version (MCNP6.2.2) that has not been released publicly. A direct comparison of the PERT card results for an F4 (neutron flux averaged over a cell) tally before and after the patch are shown in figure 1. All simulations used in the sensitivity estimates in this report were performed with MCNP6.2.2. This work verifies the patched MCNP perturbation tool by comparing first order sensitivities made using the PERT card to estimates made using manual perturbation of the compact ENDF (ACE) files.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS2021

Integration of an Arm Kinematics Hot Patch onboard the Curiosity Rover

NASA's Mars Science Laboratory (MSL) mission has updated the Curiosity rover's flight software multiple times since landing on Mars on August 6, 2012. The most common patching method has been a hot patch, in which running flight software is modified after being copied into RAM from its persistent storage. The latest hot patch to be installed on Curiosity fixed an issue in the robotic arm software that computes generalized inverse kinematics. Additional unit testing performed since the start of the surface mission revealed that this software can sometimes produce erroneous solutions.The cause was identified as numerical instability in a quartic root finder. When the inputs to that solver are not well conditioned, floating-point numerical issuescan cause erroneous roots to be reported. In theory, this could result in the robotic arm turret instruments being commanded to unintended positions, for example, below the terrain surface. Out of approximately 3.7 million unit test cases, 97.2\% of the position errors were below 5 mm. However, there were 16 test cases where theposition error was greater than 20 cm, and the maximum position error was 1.2 meters.The patch was uploaded to Curiosity on sol 2642 (January 11, 2020) after the solution was developed, re-implemented as a hot patch, and validated and verified using Earth-based Curiosity testbeds. A checkout test of the patch was performed on Curiosity on sol 2657, and nominal use of the patch began on sol 2658. In this paper, we describe the steps that led to integrating the arm kinematic hot patch into Curiosity's flight software, from the discovery of the bug to the nominal use of the patch in flight.

Maimone, Mark↗
DOE OSTI2023

MCNP ® Code V.6.3.0 Release Notes

The Monte Carlo N-Particle ® (MCNP ® ) code is a general-purpose, continuous-energy, generalized geometry, time-dependent, radiation transport code developed by the MCNP development team. The MCNP calculations provide predictive capabilities that can replace expensive or impossible-to perform experiments. Specific application problems include simulations of experimental diagnostics, intrinsic radiation, radiation detection and measurement, criticality safety, nuclear threat reduction and response, radiation health protection, nuclear weapons effects, and nuclear forensics. This MCNP code, version 6.3.0, follows the MCNP6.2.0 version. Since the release of MCNP6.2.0, many changes have been made to the MCNP code. These changes include new or improved features, a new build system, code enhancement and modernization, and bug fixes. The MCNP code, version 6.3.0, theory and user input information is documented in MCNP ® Code Version 6.3.0 Theory & User Manual, the build guidance for various platforms is documented in MCNP ® Code Version 6.3.0 Build Guide, and the verification and validation testing for various application benchmark test suites is documented in MCNP ® Code Version 6.3.0 Verification & Validation Testing.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
DOE OSTI2022

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

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

42 ENGINEERING↗
DOE OSTI2023

IDAES-PSE 2.3.0 Release

The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost, most environmentally sustainable solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications.. New Features and Models • New diagnostics toolboxes and examples o Tutorial for using the DiagnosticsToolbox o Methods to identify potential evaluation errors in models o SVDToolbox for performing singular value decomposition analysis on models to identify possible degeneracies and poor scaling o DegeneracyHunter for identifying irreducible degenerate sets in models • Model for solid-liquid separation which takes two inputs (solid and liquid streams) and produces three outlets (solids, liquid entrained with solids and pure liquid) • Example of temperature swing adsorption in models_extra Deprecation Warnings • With the update to Pyomo 6.7.0, the plate heat exchanger model has begun failing tests on some CI platforms. If this is not addressed by the February release, this model may be removed due to failing tests. See #1294. Offers to help identify the cause and fix this issue are welcome. Improvements and bug fixes • Fixed oversight which precluded using Mixer and Separator models when inherent reactions were present in property package • Added reporting methods to the MSContactor model • Minor corrections in some examples where values were being fixed outside of declared variable bounds

DiagnosticsToolbox,IDAES,PSE,Process Systems Engin↗
NASA NTRS1998

Parallel 3D Multi-Stage Simulation of a Turbofan Engine

A 3D multistage simulation of each component of a modern GE Turbofan engine has been made. An axisymmetric view of this engine is presented in the document. This includes a fan, booster rig, high pressure compressor rig, high pressure turbine rig and a low pressure turbine rig. In the near future, all components will be run in a single calculation for a solution of 49 blade rows. The simulation exploits the use of parallel computations by using two levels of parallelism. Each blade row is run in parallel and each blade row grid is decomposed into several domains and run in parallel. 20 processors are used for the 4 blade row analysis. The average passage approach developed by John Adamczyk at NASA Lewis Research Center has been further developed and parallelized. This is APNASA Version A. It is a Navier-Stokes solver using a 4-stage explicit Runge-Kutta time marching scheme with variable time steps and residual smoothing for convergence acceleration. It has an implicit K-E turbulence model which uses an ADI solver to factor the matrix. Between 50 and 100 explicit time steps are solved before a blade row body force is calculated and exchanged with the other blade rows. This outer iteration has been coined a "flip." Efforts have been made to make the solver linearly scaleable with the number of blade rows. Enough flips are run (between 50 and 200) so the solution in the entire machine is not changing. The K-E equations are generally solved every other explicit time step. One of the key requirements in the development of the parallel code was to make the parallel solution exactly (bit for bit) match the serial solution. This has helped isolate many small parallel bugs and guarantee the parallelization was done correctly. The domain decomposition is done only in the axial direction since the number of points axially is much larger than the other two directions. This code uses MPI for message passing. The parallel speed up of the solver portion (no 1/0 or body force calculation) for a grid which has 227 points axially.

Turner, Mark G.↗
NASA NTRS1993

Making tomorrow's mistakes today: Evolutionary prototyping for risk reduction and shorter development time

In the early days of JPL's solar system exploration, each spacecraft mission required its own dedicated data system with all software applications written in the mainframe's native assembly language. Although these early telemetry processing systems were a triumph of engineering in their day, since that time the computer industry has advanced to the point where it is now advantageous to replace these systems with more modern technology. The Space Flight Operations Center (SFOC) Prototype group was established in 1985 as a workstation and software laboratory. The charter of the lab was to determine if it was possible to construct a multimission telemetry processing system using commercial, off-the-shelf computers that communicated via networks. The staff of the lab mirrored that of a typical skunk works operation -- a small, multi-disciplinary team with a great deal of autonomy that could get complex tasks done quickly. In an effort to determine which approaches would be useful, the prototype group experimented with all types of operating systems, inter-process communication mechanisms, network protocols, packet size parameters. Out of that pioneering work came the confidence that a multi-mission telemetry processing system could be built using high-level languages running in a heterogeneous, networked workstation environment. Experience revealed that the operating systems on all nodes should be similar (i.e., all VMS or all PC-DOS or all UNIX), and that a unique Data Transport Subsystem tool needed to be built to address the incompatibilities of network standards, byte ordering, and socket buffering. The advantages of building a telemetry processing system based on emerging industry standards were numerous: by employing these standards, we would no longer be locked into a single vendor. When new technology came to market which offered ten times the performance at one eighth the cost, it would be possible to attach the new machine to the network, re-compile the application code, and run. In addition, we would no longer be plagued with lack of manufacturer support when we encountered obscure bugs. And maybe, hopefully, the eternal elusive goal of software portability across different vendors' platforms would finally be available. Some highlights of our prototyping efforts are described.

Friedman, Gary↗
DOE OSTI2024

IDAES-PSE 2.7.0 Release

The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications. IDAES-PSE 2.7.0 Release Highlights New features: AutoScaler and CustomScalerBase classes: Such tools are the core of the new scaling framework being implemented in IDAES. Wider adoption of scaling tools among users will result in quicker and more robust model solutions. Scaler for equilibrium reactor and saponification properties: These scaler models are examples to follow for how to use the new scaling tools. ONNX Surrogate support from Optimization & Machine Learning Toolkit (OMLT): ONNX is an open standard format to save and load ML/AI models that is widely supported by all major frameworks. This capability makes it easier for IDAES users to create surrogate models and use them without having to support each framework individually. 1D Membrane Model for CO2 Capture and Utilization: Supports ongoing efforts for modeling and optimizing polymer membrane processes for CO2 capture and conversion into formic acid. StreamScaler unit model: Unrelated to the CustomScalerBase, this unit model allows a stream’s extensive variables to be scaled by a fixed factor. This allows streams being processed by multiple units in parallel to be scaled down to unit scale and scaled back up to process scale. Bug fixes or improvements: Scaling, EoS, Diagnostics tool, Modular Properties, tests & documentation Deprecations: Old Cubic EoS

AS↗
DOE OSTI2021

Software Quality Assurance for EBR-II Fuels Irradiation and Physics Database (FIPD)

The Fuels Irradiation and Physics Database (FIPD) is an ongoing DOE project on archival of the EBR-II metal-alloy fuel irradiation experiments. As part of its use in support of license applications, the Quality Assurance Program Plan (QAPP) was drafted and endorsed by NRC in an effort to demonstrate its compliance with regulatory expectations. Software Quality Assurance (SQA) for the physics portion of FIPD is intended to qualify the calculated quantities such as fuel and cladding temperatures, neutron fluence and axially varying burnup estimates for irradiated fuel elements. This report covers the initial evaluation of SQA status of three neutron physics and thermo-fluid codes (REBUS, RCT and SE2RCT) that form the basis of calculated quantities for as-irradiated characteristics of the tested metallic fuel elements. The report also introduces an SQA plan to address the identified deficiencies. The REBUS, RCT, and SE2RCT codes are all part of the Argonne Reactor Code (ARC) code system. There is considerable knowledge and experience on REBUS and RCT but relatively less on SE2RCT. During FY2021, efforts focused on an assessment of how the data in the EBR-II Physics and Analysis DataBase (PADB) is generated with SE2RCT and used in FIPD. Additional tasks included considerations of uncertainties for power estimates in REBUS and RCT calculations and their impact on the combined RCT methodology. The RCT software usage in FIPD was assessed this year and the input/output details studied. A “requirements” document was created that identifies the key features of the RCT software being used in FIPD that need to have SQA documentation. A brief discussion on the history of RCT and its input is included in this report along with the basic SQA roadmap laid out in the requirements document. The SE2RCT software usage in FIPD is still being studied noting that there is no current manual. As part of the work done this year, two bugs were identified in the SE2RCT software which have a minor impact on the accuracy of the results it produces. No requirements document has been created, but one identified feature of SE2RCT being used that needs verification was its fuel pin temperature calculation. The work completed this year confirms that the approximations which will be included in the software verification report for SE2RCT are accurate. In addition to software quality assurance work for RCT and SE2RCT, an automated verification framework is proposed to simplify the software quality assurance process. The purpose of this framework is to streamline code verification and documentation while minimizing repetitive tasks for code developers and reviewers. The reduction of repeated input (between reference solution, software, and documentation input) throughout the SQA process reduces potential for human errors during the preparation of the supporting software quality records. The automation of the verification and documentation process proposed for this project leverages the existing verification structure already in place for the SAS4A/SASSYS-1 code.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗