SEARCH · Engineering Papers
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.
ORNL Slicer 2 v0.93 BETA is the fourth BETA release of the ORNL Slicer 2 software package. It was released on 3/31/2021 to all users of v0.92, currently totaling over 100 users. This technical memo will highlight all of the new features, updates, and bug fixes released in this latest iteration of the ORNL Slicer 2.
Cyber-physical systems (CPS) are engineered systems that rely on the smooth integration of computational algorithms and physical elements. This integration presents new challenges for verifying that systems will behave as expected. The goal of this presentation is to present current challenges and potential solutions for the formal verification of cyber-physical systems. For cyber systems, formal methods refer to systematically rigorous mathematical techniques employed in the specification, development, analysis, and verification of both software and hardware systems. Recent advancements in computer science have yielded sophisticated tools specifically designed to address challenges associated with formal methods in complex systems. These tools leverage various foundational concepts such as logic, formal languages, program semantics, type systems, type theory, and automata theory. A notable achievement in the application of formal methods is the seL4 microkernel, claimed to be the first general-purpose operating-system kernel to be verified. Its proof implies the absence of bugs and guarantees that the kernel meets specifications. For physical systems, dynamic and control theory has a history of using rigorous analytic techniques to prove functional correctness. Lyapunov, optimal, classical, modern, and robust control theories all provide rigorous mathematical methods both to analyze system performance and to design controller that can be guaranteed to meet certain objectives. Recent computational techniques like level set theory and reachability analysis provide assertions that a system's state will avoid unsafe regions. Even though success has been independently achieved for cyber systems and physical systems, the integration of such systems creates new challenges. In particular, there is an obvious discrepancy between finite-state machines and infinite-state systems, resulting in different approaches for modeling and analyzing these system. While it is possible to simulate hybrid systems, this provides only a demonstration of a performance and not proof. For hybrid systems, current formal methods and system analysis approaches typically require a workarounds to work on hybrid systems like CPS. This paper will outline the state of the art and limits of current practice for formally verifying CPS and will identify possible research directions that require attention.
The ASM2000 software is based on the NetCAM3 software (currently installed at RLUOB) with the main difference being enhanced multi-CAM head support. Therefore, as the NetCAM3 software has been previously tested, the current evaluation concentrated on performance related to multi-head operation. In addition, bug fixes and improvements to prior versions of the NetCAM3 code were incorporated into the ASM2000 V2.0.0 software package.
Adding a new semiconductor detector into the detector response function toolkit (DRiFT) requires a model of the electric potential and the electric field. To get an accurate electrostatics model, the geometry of the detector should be modeled as closely to the real geometry as feasible, including the semiconductor materials, doping layers and concentrations, and contacts. Since the electric field and potential are used to calculate the induced signal, the results of the detector response functions are largely influenced by the electrostatics models. Initial electrostatics models were completed using Silvaco, however, this document provides guidance on using COMSOL Mulitphysics ® (COMSOL) to model the detectors to give users additional flexibility. Guidance on using COMSOL and its user interface are mostly left out of this document, but best practices for geometry, modeling methods, and data format/exporting are included to help users generate models that are compatible with DRiFT, prevents bugs, issues, and inaccuracies during charge collection calculations. The following summary provides an overview of the document.
We describe the accomplishments jointly achieved by Kitware and Sandia over the fiscal years 2016 through 2020 to benefit the Advanced Scientific Computed (ASC) Advanced Technology Development and Mitigation (ATDM) project. As a result of our collaboration, we have improved the Trilinos and ATDM application developer experience by decreasing the time to build, making it easier to identify and resolve build and test defects, and addressing other issues . We have also reduced the turnaround time for continuous integration (CI) results. For example, the combined improvements likely cut the wall clock time to run automated builds of Trilinos posting to CDash by approximately 6x or more in many cases. We primarily achieved these benefits by contributing changes to the Kitware CMake/CTest/CDash suite of open source software development support tools. As a result, ASC developers can now spend more time improving code and less time chasing bugs. And, without this work, one can argue that the stabilization of Trilinos for the ATDM platforms would not have been feasible which would have had a large negative impact on an important internal FY20 L1 milestone.
This document acts as a repository of knowledge for the Monte Carlo N-Particle (MCNP) transport computer code. It is maintained alongside the source code and attempts to introduce new users and re-familiarize experienced users with the theory and practices of using the MCNP code for the wide range of particle transport analyses that it is appropriate for. The latest version of the MCNP code, version 6.3.0, provides the Monte Carlo particle transport community with the latest feature developments and bug fixes in the MCNP code. The MCNP code version 6.0 and later is also known as the MCNP6 code.
This document acts as a repository of knowledge for the Monte Carlo N-Particle (MCNP) transport computer code. It is maintained alongside the source code and attempts to introduce new users and re-familiarize experienced users with the theory and practices of using the MCNP code for the wide range of particle transport analyses that it is appropriate for. The latest version of the MCNP code, version 6.3.1, provides the Monte Carlo particle transport community with the latest feature developments and bug fixes in the MCNP code. The MCNP code version 6.0 and later is also known as the MCNP6 code.
This presentation discusses the past year and the many accomplishments of the MCNP6.3 team. It states that the MCNP6.3 release is imminent and that the approved, final documents have been making their way to the website. The code executables and source are already packaged up for distribution and the new installer is being finalized and tested now, for all platforms. The package will be sent to RSICC before the end of October 2022. Additionally, the presentation discusses some things to think about as MCNP6.3 is requested and/or used. For example, many of the recent efforts have been focused on making development, updates, and distribution of the code and documents more robust and streamlined. They will be revising/updating documents more frequently than ever before and they will be exploring avenues to distribute official patches to MCNP6.3. As they explain, this allows them to be more responsive to bugs and issues that are identified. In conclusion, the application of a patch to MCNP6.3 will require having the source code.
Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. REBUS is central to this system. The driver for this effort requires the Triangular-Z and hexagonal-Z core geometry options of REBUS to be verified. Previous work identified the REBUS features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying REBUS’s ability to correctly intepret the user input model, verifying that the features identified yield the intended results, and verifying the correctness of the REBUS output tables. The REBUS software verification relies heavily upon the accuracy of the embedded DIF3D software, the verification of which was completed and documented elsewhere. Given that DIF3D produces an accurate solution, the primary focus of the verification in the REBUS software is to ensure that it properly uses the DIF3D solution and that the depletion system (Bateman equations) are correctly implemented. This manuscript reiterates the verification tasks and displays results with respect to the features needed for current design activities. Analytic solutions of the Batemen equations are displayed and the results calculated with REBUS are displayed demonstrating the accuracy. Since coupled Bateman and neutron diffusion/transport solutions are extremely difficult to obtain, much of the focus is placed on how REBUS uses a given DIF3D solution assuming the accuracy of the DIF3D solution. The verification effort identified no issues that are debilitating or otherwise impactful to the design usage of REBUS, and thus REBUS version 11.0, release 3012 is considered verified. It is important to note that several outputs of REBUS are identified to be inaccurate, such as burnup in MWD/MT. Most of the relevant ones for VTR are generally accurate with 10-20% errors which is not impactful as all regular REBUS users are aware of this issue and know how to hand calculate the results. The REBUS manual further makes it clear that these values are consistent with the methodology being used by REBUS and thus the “errors” are more of an inconsistent definition with respect to what a user would expect given a definition in literature. Other issues that were identified included unclear documentation and software bugs all of which were inconsequential to the final results.
The purpose of this document is to provide the user information about the installation of FAST-1.0.1 on their computers or servers. General information about the code and supported operating systems is described in Section 1.0.1. Self-service oriented FAST-1.0.1 software licensing steps are described in Section 2.0. An installation verification test suite is provided with FAST-1.0.1 and described in Section 3.0. A convenience script for converting FRAPCON to FAST inputs is discussed in Section 4.0. FAST-1.0.1 was developed and released under a software quality assurance program based upon NQA-1-2017. FAST-1.0.1 is the latest baseline code and the result of a bug fixes to FAST-1.0 with other software and methodology developments. The installation verification test suite contains both steady state and transient Anticipated Operation Occurrences (AOOs). Capability to model accident conditions, such as Reactivity Initiated Accidents (RIAs) and Loss Of Coolant Accidents (LOCAs), are targeted for a later release of FAST. FRAPTRAN-2.0 will continue to be used for accident conditions until the release of FAST with accident condition modeling capabilities.
TOUGHREACT V4.12 is a 3-D reactive transport code that handles to non-isothermal, multiphase/multicomponent fluid flow, heat transport, aqueous and gaseous species advection-diffusion, and equilibrium/kinetic water-gas-rock-biological reactions. TOUGHREACT V4.12 is based on TOUGHREACT V3.3, with several new features including: an option to compute activity coefficients using the Pitzer ion interaction model; implementation of ECO2N V2.0 for temperatures up to 300 C; options to simulate forward and reverse osmosis, including 2D Poiseuille flow; addition of EOS8 and revisions for EOS5 and EWASG with H2(g); addition of gas species decay, various new output formats and time step control options; many bug fixes.
This document acts as a repository of knowledge for the Monte Carlo N-Particle (MCNP) transport computer code. It is maintained alongside the source code and attempts to introduce new users and re-familiarize experienced users with the theory and practices of using the MCNP code for the wide range of particle transport analyses that it is appropriate for. The latest version of the MCNP code, version 6.3.2, provides the Monte Carlo particle transport community with the latest feature developments and bug fixes in the MCNP code. The MCNP code version 6.0 and later is also known as the MCNP6 code.
This presentation shows that the SCALE 6.3 is available from RSICC. The lecture touches on new features including the new ENDF/B-VIII.0 data including covariances. It shows that the updated parallel infrastructure enables parallel capability on Windows. Production release with maintenance until 2026 at minimum addressing Code or data bugs, Performance, Ease of installation. There is a New Government Use Agreement (GUA) for SCALE 7.0 beta access. With site licenses available for non-commercial testing and feedback, handled through ORNL technology transfer.
The following release notes reflect changes made to HBET for proposed changes to be released in July 2024. Notes are broken up into three sections: 1) Key Improvements, 2) Bug Fixes, and 3) Data Changes • Key Improvements: primary features added and changes to existing features that affect the user experience. • Bug Fixes: Issues discovered or reported that were fixed in the proposed work to be released. • Data Changes: Any work done on the databases directly or the process to calculate data for the system.
Software developers must adapt to keep up with the changing capabilities of platforms so that they can utilize the power of High-Performance Computers (HPC), including exascale systems. OpenMP, a directive-based parallel programming model, allows developers to include directives to existing C, C++, or Fortran code to allow node level parallelism without compromising performance. This paper describes our CI/CD efforts to provide easy evaluation of the support of OpenMP across different compilers using existing testsuites and benchmark suites on HPC platforms. Our main contributions include (1) the set of a Continuous Integration (CI) and Continuous Development (CD) workflow that captures bugs and provides faster feedback to compiler developers, (2) an evaluation of OpenMP (offloading) implementations supported by AMD, HPE, GNU, LLVM, and Intel, and (3) evaluation of the quality of compilers across different heterogeneous HPC platforms. With the comprehensive testing through the CI/CD workflow, we aim to provide a comprehensive understanding of the current state of OpenMP (offloading) support in different compilers and heterogeneous platforms consisting of CPUs and GPUs from NVIDIA, AMD, and Intel.
Rigorous testing methods are essential for ensuring the security and reliability of industrial controller software. Fuzzing, a technique that automatically discovers software bugs, has also proven effective in finding software vulnerabilities. Unsurprisingly, fuzzing has been applied to a wide range of platforms, including programmable logic controllers (PLCs). However, current approaches, such as coverage-guided evolutionary fuzzing implemented in the popular fuzzer American Fuzzy Lop Plus Plus (AFL++), are often inadequate for finding logical errors and bugs in PLC control logic applications. They primarily target generic programming languages like C/C++, Java, and Python, and do not consider the unique characteristics and behaviors of PLCs, which are often programmed using specialized programming languages like Structured Text (ST). Furthermore, these fuzzers are ill suited to deal with complex input structures encapsulated in ST, as they are not specifically designed to generate appropriate input sequences. This renders the application of traditional fuzzing techniques less efficient on these platforms. To address this issue, this paper presents a fuzzing framework designed explicitly for PLC software to discover logic bugs in applications written in ST specified by the IEC 61131-3 standard. The proposed framework incorporates a custom-tailored PLC runtime and a fuzzer designed for the purpose. We demonstrate its effectiveness by fuzzing a collection of ST programs that were crafted for evaluation purposes. We compare the performance against a popular fuzzer, namely, AFL++. The proposed fuzzing framework demonstrated its capabilities in our experiments, successfully detecting logic bugs in the tested PLC control logic applications written in ST. On average, it was at least 83 times faster than AFL++, and in certain cases, for example, it was more than 23,000 times faster.
This paper presents Giallar, a fully-automated verification toolkit for quantum compilers. Giallar requires no manual specifications, invariants, or proofs, and can automatically verify that a compiler pass preserves the semantics of quantum circuits. To deal with unbounded loops in quantum compilers, Giallar abstracts three loop templates, whose loop invariants can be automatically inferred. To efficiently check the equivalence of arbitrary input and output circuits that have complicated matrix semantics representation, Giallar introduces a symbolic representation for quantum circuits and a set of rewrite rules for showing the equivalence of symbolic quantum circuits. With Giallar, we implemented and verified 44 (out of 56) compiler passes in 13 versions of the Qiskit compiler, the open-source quantum compiler standard, during which three bugs were detected in and confirmed by Qiskit. Furthermore, our evaluation shows that most of Qiskit compiler passes can be automatically verified in seconds and verification imposes only a modest overhead to compilation performance.
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.