Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Continuous integration”

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 OSTI2023

Controls at the Fermilab PIP-II Superconducting Linac

PIP-II is an 800 MeV superconducting RF linear accelerator under development at Fermilab. As the new first stage in our accelerator chain, it will deliver high-power beam to multiple experiments simultaneously and thus drive Fermilab's particle physics program for years to come. In a pivot for Fermilab, controls for PIP-II are based on EPICS instead of ACNET, the legacy control system for accelerators at the lab. This paper discusses the status of the EPICS controls work for PIP-II. We describe the EPICS tools selected for our system and the experience of operators new to EPICS. We introduce our continuous integration / continuous development environment. We also describe some efforts at cooperation between EPICS and ACNET, or efforts to move towards a unified interface that can apply to both control systems.

43 PARTICLE ACCELERATORS↗
DOE OSTI2010

Comparison of Ambient Radon Concentrations in Air in the Northern Mojave Desert from Continuous and Integrating Instruments

As part of a program to characterize and baseline environmental parameters, ambient radon-222 (Rn) monitoring was conducted in the rural community of Amargosa Valley, NV, the closest community to Yucca Mountain. Passive integrating and continuous Rn monitoring instruments were deployed adjacent to the Community Environmental Monitoring Program (CEMP) station in Amargosa Valley. The CEMP station provided real-time ambient gamma exposure and meteorological data used to correct the integrated Rn measurements, verified the meteorological data collected by the continuous Rn monitoring instrument, and for provided instrumentation for evaluating the relationships between meteorological conditions and Rn concentrations. Hourly Rn concentrations in air measured by the continuous Rn monitoring instrument (AlphaGUARD®) were compared to the average hourly values for the integrating Rn measurements (E-PERM®) by dividing the total Rn measurements by the number of hours the instruments were deployed. The results of the comparison indicated that average hourly ambient Rn concentrations as measured by both methods ranged from 0.2 to 0.4 pico-curies per liter of air. Ambient Rn values for the AlphaGUARD exhibited diurnal variations. When Rn concentrations were compared with measurements of temperature (T), barometric pressure, and relative humidity, the correlation (inversely) was highest with T, albeit weakly.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2019

MAUS: the MICE analysis user software

The Muon Ionization Cooling Experiment (MICE) collaboration has developed the MICE Analysis User Software (MAUS) to simulate and analyze experimental data. It serves as the primary codebase for the experiment, providing for offline batch simulation and reconstruction as well as online data quality checks. The software provides both traditional particle-physics functionalities such as track reconstruction and particle identification, and accelerator physics functions, such as calculating transfer matrices and emittances. The code design is object orientated, but has a top-level structure based on the Map-Reduce model. This allows for parallelization to support live data reconstruction during data-taking operations. MAUS allows users to develop in either Python or C++ and provides APIs for both. Various software engineering practices from industry are also used to ensure correct and maintainable code, including style, unit and integration tests, continuous integration and load testing, code reviews, and distributed version control. The software framework and the simulation and reconstruction capabilities are described.

47 OTHER INSTRUMENTATION↗
DOE OSTI2023

Containerization of Phase-2 Tracker Data Acquisition and Control Framework

The CMS Experiment has started an extensive upgrade program in the context of the High-Luminosity phase of the LHC (Phase-2). In order to cope with the highly demanding High-Luminosity conditions, CMS will need a completely new inner and outer tracking detectors. On top of R&D development, a Data AcQuisition (DAQ) software is being developed along with different applications to control, monitor and validate the newly produced modules of the future tracker. As more and more developers are getting involved to maintain all those codes, an environment where software and applications can work independently of the host machine operating system is crucial. The Phase-2 Tracker group decided to make use of Docker as containerization solution for its framework. This poster describes the containerization of DAQ software/applications utilized to test and validate the Tracker modules. This includes continuous integration and continuous deployment (so-called CI/CD) and running GUI applications inside containers.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2025

Benchmark Tracking System for Performance Monitoring

Benchmarking is essential for high-performance software development, particularly for monitoring performance across code iterations. This project focused on enhancing the benchmarking process for Lamellar, an asynchronous runtime for High-Performance Computing (HPC) systems developed at Pacific Northwest National Laboratory. Prior to this work, benchmark results were difficult to track and compare across code versions, presenting significant challenges in identifying performance regressions and long-term trends. The primary objective was to establish a systematic, reproducible approach for measuring performance and detecting regressions following code commits. Our methodology involved three key components: standardizing benchmark outputs, implementing data versioning, and developing analysis tools. We standardized the benchmark output format to JSON Line records containing specific fields (execution time, hardware specifications, and environmental variables). To address data management challenges, we evaluated several options and eventually chose a git repository dedicated to benchmark data. We developed a suite of Python tools that processed benchmark results, enriched them with metadata, and facilitated search in the repository. The resulting system enables more efficient filtering and comparison of performance metrics across commit histories, hardware configurations, and benchmark variants through a unified query interface. Our implementation reduces computational overhead by first checking for existing results through configuration matching before initiating new benchmark runs, thereby conserving resources. The system has been validated by Lamellar developers. It organizes results by benchmark type and build configurations for efficient retrieval. Future developments include a planned Large Language Model interface for predicting benchmark performance, incorporating the criterion package for statistical analysis, which will enable automated detection of statistically significant performance changes, and integration with continuous integration pipelines. Despite these enhancements being reserved for future work, this project has successfully provided the Lamellar development team with a framework for maintaining consistent performance standards and identifying optimization opportunities across workloads and hardware environments.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2007

Determining a Method of Enabling and Disabling the Integral Torque in the SDO Science and Inertial Mode Controllers

During design of the SDO Science and Inertial mode PID controllers, the decision was made to disable the integral torque whenever system stability was in question. Three different schemes were developed to determine when to disable or enable the integral torque, and a trade study was performed to determine which scheme to implement. The trade study compared complexity of the control logic, risk of not reenabling the integral gain in time to reject steady-state error, and the amount of integral torque space used. The first scheme calculated a simplified Routh criterion to determine when to disable the integral torque. The second scheme calculates the PD part of the torque and looked to see if that torque would cause actuator saturation. If so, only the PD torque is used. If not, the integral torque is added. Finally, the third scheme compares the attitude and rate errors to limits and disables the integral torque if either of the errors is greater than the limit. Based on the trade study results, the third scheme was selected. Once it was decided when to disable the integral torque, analysis was performed to determine how to disable the integral torque and whether or not to reset the integrator once the integral torque was reenabled. Three ways to disable the integral torque were investigated: zero the input into the integrator, which causes the integral part of the PID control torque to be held constant; zero the integral torque directly but allow the integrator to continue integrating; or zero the integral torque directly and reset the integrator on integral torque reactivation. The analysis looked at complexity of the control logic, slew time plus settling time between each calibration maneuver step, and ability to reject steady-state error. Based on the results of the analysis, the decision was made to zero the input into the integrator without resetting it. Throughout the analysis, a high fidelity simulation was used to test the various implementation methods.

Vess, Melissa F.↗
DOE OSTI2021

Simple, Secure, Internet Delivery of MOOSE-based Applications

Application packaging and distribution are the final steps for delivering software to end-users; both are frequently neglected when creating scientific software. Commercial businesses rely on electronic distribution systems that have rendered disk drives obsolete. Still, national laboratories continue to rely heavily on removable media to distribute and limit access to controlled applications. With increasing concerns of unauthorized copying of sensitive applications, a modern distribution system that utilizes cryptographically secure communication and authentication protocols has been developed. This new distribution system will secure the chain of custody for nuclear software while simultaneously simplifying access to these tools. This report summarizes four primary advancements made toward the secure distribution of Nuclear Energy Advanced Modeling and Simulation (NEAMS)-developed, Multiphysics Object Oriented Simulation Environment (MOOSE)-based applications: application installation, package distribution, automated package building, and distribution of documentation. NEAMS is currently developing more than ten separate applications based on the open-source MOOSE Framework. Distribution of these applications has primarily been accomplished by distributing source code, with end-users compiling the applications themselves. This work created a mechanism where MOOSE applications can be installed in a similar way to any other software. This allows both administrators and end-users simplified access to runnable executables. With this new installation capability, it was then possible to rethink distribution. A new, secure capability for delivering MOOSE-based applications over the internet has been created. This system requires unique cryptographic tokens for authentication, greatly securing the custody chain for software. Once granted access, installation of any NEAMS code can be accomplished with these terminal commands: "conda install ncrc" "ncrc install ncrc-bison." After these two commands (and authenticating) the BISON application will be securely down- loaded from Idaho National Laboratory (INL)’s servers, installed, and ready to use. To enable this new distribution capability to be successful, the open-source Continuous Integration, Verification, Enhancement, and Testing (CIVET) Continuous Integration (CI) capability was augmented to add Continuous Delivery (CD). CD enables the automated building and packaging of MOOSE-based applications as they are modified by development teams, ensuring that our customers can obtain up-to-date versions of the software at any time. The need for instruction on how to use these applications was addressed through modifications to the MOOSE documentation system. The MooseDocs capability, which enables robust documentation of MOOSE-based applications, has been extended to allow both for the installation of documentation and the packaging of documentation with installed applications. Together, these enhancements form the core of a new, secure distribution mechanism for nuclear simulation tools. In concert with the Nuclear Computational Resource Center (NCRC), NEAMS- developed applications will now be straightforward to obtain securely.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1990

Discrete integration of continuous Kalman filtering equations for time invariant second-order structural systems

A general form for the first-order representation of the continuous second-order linear structural-dynamics equations is introduced to derive a corresponding form of first-order continuous Kalman filtering equations. Time integration of the resulting equations is carried out via a set of linear multistep integration formulas. It is shown that a judicious combined selection of computational paths and the undetermined matrices introduced in the general form of the first-order linear structural systems leads to a class of second-order discrete Kalman filtering equations involving only symmetric sparse N x N solution matrices.

Park, K. C.↗
DOE OSTI2024

CI/CD Efforts for Validation, Verification and Benchmarking OpenMP Implementations

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.

Jarmusch, Aaron↗
DOE OSTI2022

ACES: Infrastructure As Code. Model Optimization and Performance Capability

Infrastructure as Code (IaC) refers to managing infrastructure (networks, physical/virtual machines, storage, and connection topology) in a descriptive model/language, rather than configuring it manually or using interactive configuration tools. Just like source code can be compiled to generate the same binary code, IaC enables generating the same environment every time it is applied. IaC is a key DevOps practice and is generally used in conjunction with continuous integration (CI) and continuous delivery (CD). In CI, all code changes are merged into a mainline branch and validated multiple times a day as developers check in their changes to the source code. In CD on the other hand, code changes are automatically packaged for a new release-to-production on a regular basis. This typically enables teams to deliver software changes much more quickly and often. Developing and managing the ACES platform using (IaC) is vital for the robust deployment and continued sustainment of this foundational computing capability. IaC and DevOps practices will help us solve many of the common challenges often encountered in developing and maintaining compute infrastructure. First, it will make the provisioning, deployment, and maintenance of the compute infrastructure across multiple environments much more efficient. Second, these processes help make the overall system much more stable by continuously testing new changes as they are introduced to the system. Third, it allows us to be much more confident of the security controls in place since they can be tested as part of the CI process and all new changes can be audited and tracked. Finally, IaC enables the ACES Platform to be adaptable to the emerging technologies due to its ability to spin up different test beds to evaluate and incorporate these technologies. This document addresses common infrastructure-management challenges, describes what happens if they are not addressed, and highlights the value of utilizing IaC to tackle them. Finally, we will provide a high-level overview of the IaC and DevOps practices being utilized by the ACES Platform team.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

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

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

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

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2016

Double Sided Si(Ge)/Sapphire/III-Nitride Hybrid Structure

One aspect of the present invention is a double sided hybrid crystal structure including a trigonal Sapphire wafer containing a (0001) C-plane and having front and rear sides. The Sapphire wafer is substantially transparent to light in the visible and infrared spectra, and also provides insulation with respect to electromagnetic radio frequency noise. A layer of crystalline Si material having a cubic diamond structure aligned with the cubic <111> direction on the (0001) C-plane and strained as rhombohedron to thereby enable continuous integration of a selected (SiGe) device onto the rear side of the Sapphire wafer. The double sided hybrid crystal structure further includes an integrated III-Nitride crystalline layer on the front side of the Sapphire wafer that enables continuous integration of a selected III-Nitride device on the front side of the Sapphire wafer.

Park, Yeonjoon↗
NASA NTRS2017

Method of Fabricating Double Sided Si(Ge)/Sapphire/III-Nitride Hybrid Structure

One aspect of the present invention is a double sided hybrid crystal structure including a trigonal Sapphire wafer containing a (0001) C-plane and having front and rear sides. The Sapphire wafer is substantially transparent to light in the visible and infrared spectra, and also provides insulation with respect to electromagnetic radio frequency noise. A layer of crystalline Si material having a cubic diamond structure aligned with the cubic <111> direction on the (0001) C-plane and strained as rhombohedron to thereby enable continuous integration of a selected (SiGe) device onto the rear side of the Sapphire wafer. The double sided hybrid crystal structure further includes an integrated III-Nitride crystalline layer on the front side of the Sapphire wafer that enables continuous integration of a selected III-Nitride device on the front side of the Sapphire wafer.

Park, Yeonjoon↗
DOE OSTI2025

Scaling a Podman Container Factory in the Cloud

This technical report describes an implementation of a scalable continuous integration/continuous deployment infrastructure using Microsoft Azure™ and GitLab™ resources. We utilize GitLab continuous integration podman executors to provide rootless container operations in both privileged and unprivileged modes of operation. We utilize the GitLab Fleeting plugin for Azure to manage the scaling of continuous integration execution resources. This creates a scalable, rootless, and isolate continuous integration/continuous deployment job execution infrastructure.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1986

Modification of a variational objective analysis model for new equations for pressure gradient and vertical velocity in the lower troposphere and for spatial resolution and accuracy of satellite data

Since late 1982 NASA has supported research to develop a numerical variational model for the diagnostic assimilation of conventional and space-based meteorological data. In order to analyze the model components, four variational models are defined dividing the problem naturally according to increasing complexity. The first of these variational models (MODEL I), the subject of this report, contains the two nonlinear horizontal momentum equations, the integrated continuity equation, and the hydrostatic equation. This report summarizes the results of research (1) to improve the way the large nonmeteorological parts of the pressure gradient force are partitioned between the two terms of the pressure gradient force terms of the horizontal momentum equations, (2) to generalize the integrated continuity equation to account for variable pressure thickness over elevated terrain, and (3) to introduce horizontal variation in the precision modulus weights for the observations.

Achtemeier, G. L.↗
DOE OSTI2016

SU-F-T-139: Meeting the Challenges of Quality Control in the TOPAS Monte Carlo Simulation Toolkit for Proton Therapy

Purpose: Monte Carlo particle transport simulation (MC) codes have become important tools in proton therapy and biology, both for research and practice. TOPAS is an MC toolkit serving users worldwide (213 licensed users at 95 institutions in 21 countries). It provides unprecedented ease in 4D placement of geometry components, beam sources and scoring through its user-friendly and reproducible parameter file interface. Quality control (QC) of stochastic simulation software is inherently difficult, and the versatility of TOPAS introduces additional challenges. But QC is vital as the TOPAS development team implements new features, addresses user feedback and reacts to upgrades of underlying software (i.e. Geant4). Methods: Whenever code is committed to our repository, over 50 separate module tests are automatically triggered via a continuous integration service. They check that the various module options execute successfully and that their results are statistically consistent with previous reference values. Prior to each software release, longer end-to-end tests automatically validate TOPAS against experimental data and a TOPAS benchmark. These include simulating multiple properties of spread-out Bragg peaks, validating nuclear models, and searching for differences in patient simulations. Results: Continuous integration has proven effective in catching regressions at the time they are introduced, particularly when implementing new features that involve refactoring code (e.g. multithreading and ntuple output). Code coverage statistics highlight untested portions of code and guide development of new tests. The various end-to-end tests demonstrate that TOPAS accurately describes the physics of proton therapy within clinical tolerances. Conclusion: The TOPAS QC strategy of frequent short tests and pre-release long tests has led to a more reliable tool. However, the versatility of TOPAS makes it difficult to predict how users might combine different modules, and so QC ultimately remains a partnership between the developer and the user. This work was funded by National Cancer Institute grant R01 CA 140735.

60 APPLIED LIFE SCIENCES↗