SEARCH · Engineering Papers

Results for “software development”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 181 records · Page 10

All sources NASA NTRS DOE OSTI

DOE OSTI2014

Software Quality Metrics for Geant4: An Initial Assessment - Paper 122

In the context of critical applications, such as shielding and radiation protection, ensuring the quality of simulation software they depend on is of utmost importance. The assessment of simulation software quality is crucial both to determine its adoption in experimental applications and to guarantee reproducibility of outcome over time. Geant4 is a simulation system used in a wide range of experimental applications, some of which, such as radiation protection and biomedical studies, may involve critical use cases and would especially profit from an objective assessment of the software quality. In this study, we present the first results from an ongoing analysis of Geant4 code based on established software metrics from the perspective of software engineering. The analysis evaluates the current status of the code to quantify its characteristics with respect to documented quality standards; further appraisals concern evolutions over a series of release distributions. The quantitative assessment of the software is initially focused on a subset of Geant4 packages, which play a key role in scientific applications and are representative of different software development processes. We describe the chosen software metrics that map the entities of a software system to numeric values through mathematical definitions, quantifying software attributes ranging from functionality to maintainability. To measure such metrics, we exploited a set of software metrics tools, i.e. programs that implement a set of software metrics definitions. They allow software engineers to assess a software system by extracting the required attributes from the software and providing the corresponding metric values. To correlate software metrics values in a well-defined way, we used software quality standard models, such as the ISO/IEC 9126 standard, which aggregate numerical values to aid quality analysis and assessment. With this work we aim to create a baseline for evaluating correlations between software quality embedded in the Geant4 development process and simulation observables produced by Geant4-based applications. Furthermore, we intend to highlight what metrics are most effective at evaluating radiation transport software quality. We are confident that the result will provide constructive guidance both to improve key software tools, such as Geant4, and to estimate their contribution in risk analysis concerning sensitive applications. The remainder of this paper is structured as follows. We first discuss the approach adopted to fulfil our assessment. Then, we present the setup of our experiments and the way we collected data. We provide an initial interpretation of a subset of data resulting from measurements made on the selected Geant4 packages. As the analysis is still ongoing at the time of submitting this abstract, some results will be documented in the final paper and in the conference presentation. With this work we aim to create a proper Geant4 data set for evaluating its software characteristics and identifying both strengths and weaknesses. In this initial study, we considered the geometry and processes packages, which play a major role in most simulation applications. The data analysis is in progress at the time of writing; its complexity is related to the differences among software metrics tools, to the large amount of data to be evaluated and to the pioneering character of this project. We are confident that the results will provide valuable indications for the Geant4 user community and constructive guidance to improve key Geant4 packages. Other Monte Carlo codes could profit from the methodology developed in this pilot project for similar assessments of their software quality. At the end of this study, we intend to create a baseline for evaluating correlations between software quality embedded in the Geant4 development process and simulation observables produced by Geant4-based applications. (authors)

61 RADIATION PROTECTION AND DOSIMETRY↗

DOE OSTI2020

Program Verification for Extreme-Scale Applications (Final Scientific/Technical Report)

The project seeks to develop tools and techniques to help software developers verify the correctness and accuracy of their code. The target domain is scientific software of the kind widely used and developed in the Department of Energy research community, with a particular focus on "extreme scale" programs - those that are expected to involve possibly millions of parallel threads of execution. The report covers the University of Delaware contribution to the collaborative project. The project had a number of successful outcomes, especially regarding the development and extension of the CIVL software verification framework. CIVL is a verification tool for C or Fortran programs that use MPI, OpenMP, CUDA, and/or Pthreads for parallelization. CIVL went through vast improvements and extensions, and was successfully applied to a number of challenging codes. It found a subtle bug in the Devito PDE framework. It was able to verify the functional correctness of a conjugate gradient solver using a novel probabilistic technique with vanishingly small chance of error. CIVL was used very successfully in verification competitions, and the CIVL solutions to the competition challenges were presented and published. CIVL was also used successfully by other researchers on a computational chemistry kernel.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2018

A self-referential HOWTO on release engineering

Release engineering is a fundamental part of the software development cycle: it is the point at which quality control is exercised and bug fixes are integrated. The way in which software is released also gives the end user her first experience of a software package, while in scientific computing release engineering can guarantee reproducibility. For these reasons and others, the release process is a good indicator of the maturity and organization of a development team. Software teams often do not put in place a release process at the beginning. This is unfortunate because the team does not have early and continuous execution of test suites, and it does not exercise the software in the same conditions as the end users. I describe an approach to release engineering based on the software tools developed and used by the GNU project, together with several specific proposals related to packaging and distribution. I do this in a step-by-step manner, demonstrating how this very paper is written and built using proper release engineering methods. Because many aspects of release engineering are not exercised in the building of the paper, the accompanying software repository also contains examples of software libraries.

42 ENGINEERING↗

DOE OSTI2023

How R Developers explain their Package Choice: A Survey

Background: Contemporary software development relies heavily on reusing already implemented functionality, usually in the form of packages. Aims: We aim to shed light on developers' preferences when selecting packages in R language. Method: To do that, we create and administer a survey to over 1000 developers who have added one of two common dataframe enhancement libraries in R to their projects: data.table or tidyr. We design a questionnaire using the Social Contagion Theory (SCT) following prior work on technology adoption and ensure that key dimensions affecting developer choice are considered. Results: Of the 1085 developers we contacted, 803 completed the survey asking them to prioritize various factors known to affect developer perceptions of package quality and to provide their background. Most developers self-identified as data scientists with two to five years of work experience. We found significant differences between the preferences of developers who chose data.table and tidyr. Surprisingly, package reputation based on easy-to-see measures, such as the number of stars on GitHub, was not an important factor for either group. Conclusions: Our findings demonstrate the inherently social nature of package adoption. They can help design future studies on how different populations of developers make decisions on which software packages to use in their projects. Finally, package developers and maintainers can benefit by better understanding the prime concerns of the users of their packages.

Malviya Thakur, Addi↗

DOE OSTI2023

Best practices for documenting a scientific Python project

Documentation is a crucial component of software development that helps users with installation and usage of the software. Documentation also helps onboard new developers to a software project with contributing guidelines and API information. The INTERSECT project is an open federated hardware/software library to facilitate the development of au- tonomous laboratories. A documentation strategy using Sphinx has been utilized to help developers contribute to source code and to help users understand the INTERSECT Python interface. Docstrings as well as reStructuredText files are used by Sphinx to automatically compile HTML and PDF files which can be hosted online as API documentation and user guides. The resulting documentation website is automatically built and deployed using GitLab runners to create Docker containers with NGINX servers. The approach discussed in this paper to automatically deploy documentation for a Python project can improve the user and developer experience for many scientific projects.

Wiggins, Gavin↗

DOE OSTI2021

BeeSwarm: Enabling Parallel Scaling Performance Measurement in Continuous Integration for HPC Applications

Testing is one of the most important steps in software development–it ensures the quality of software. Continuous Integration (CI) is a widely used testing standard that can report software quality to the developer in a timely manner during development progress. Performance, especially scalability, is another key factor for High Performance Computing (HPC) applications. There are many existing profiling and performance tools for HPC applications, but none of these are integrated into CI tools. In this work, we propose BeeSwarm, an HPC container based parallel scaling performance system that can be easily applied to the current CI test environments. BeeSwarm is mainly designed for HPC application developers who need to monitor how their applications can scale on different compute resources. We demonstrate BeeSwarm using a multi-physics HPC application with Travis CI, GitLab CI and GitHub Actions while using ChameleonCloud and Google Compute Engine as the compute backends. Finally, our results show that BeeSwarm can be used for scalability and performance testing of HPC applications.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2015

SU-E-P-43: A Knowledge Based Approach to Guidelines for Software Safety

Purpose: In the fall of 2012, a survey was distributed to medical physicists across Canada. The survey asked the respondents to comment on various aspects of software development and use in their clinic. The survey revealed that most centers employ locally produced (in-house) software of some kind. The respondents also indicated an interest in having software guidelines, but cautioned that the realities of cancer clinics include variations, that preclude a simple solution. Traditional guidelines typically involve periodically repeating a set of prescribed tests with defined tolerance limits. However, applying a similar formula to software is problematic since it assumes that the users have a perfect knowledge of how and when to apply the software and that if the software operates correctly under one set of conditions it will operate correctly under all conditions Methods: In the approach presented here the personnel involved with the software are included as an integral part of the system. Activities performed to improve the safety of the software are done with both software and people in mind. A learning oriented approach is taken, following the premise that the best approach to safety is increasing the understanding of those associated with the use or development of the software. Results: The software guidance document is organized by areas of knowledge related to use and development of software. The categories include: knowledge of the underlying algorithm and its limitations; knowledge of the operation of the software, such as input values, parameters, error messages, and interpretation of output; and knowledge of the environment for the software including both data and users. Conclusion: We propose a new approach to developing guidelines which is based on acquiring knowledge-rather than performing tests. The ultimate goal is to provide robust software guidelines which will be practical and effective.

60 APPLIED LIFE SCIENCES↗

DOE OSTI2017

Evaluation of the OpenCL AES Kernel using the Intel FPGA SDK for OpenCL

The OpenCL standard is an open programming model for accelerating algorithms on heterogeneous computing system. OpenCL extends the C-based programming language for developing portable codes on different platforms such as CPU, Graphics processing units (GPUs), Digital Signal Processors (DSPs) and Field Programmable Gate Arrays (FPGAs). The Intel FPGA SDK for OpenCL is a suite of tools that allows developers to abstract away the complex FPGA-based development flow for a high-level software development flow. Users can focus on the design of hardware-accelerated kernel functions in OpenCL and then direct the tools to generate the low-level FPGA implementations. The approach makes the FPGA-based development more accessible to software users as the needs for hybrid computing using CPUs and FPGAs are increasing. It can also significantly reduce the hardware development time as users can evaluate different ideas with high-level language without deep FPGA domain knowledge. In this report, we evaluate the performance of the kernel using the Intel FPGA SDK for OpenCL and Nallatech 385A FPGA board. Compared to the M506 module, the board provides more hardware resources for a larger design exploration space. The kernel performance is measured with the compute kernel throughput, an upper bound to the FPGA throughput. The report presents the experimental results in details. The Appendix lists the kernel source code.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2017

Evaluation of CHO Benchmarks on the Arria 10 FPGA using Intel FPGA SDK for OpenCL

The OpenCL standard is an open programming model for accelerating algorithms on heterogeneous computing system. OpenCL extends the C-based programming language for developing portable codes on different platforms such as CPU, Graphics processing units (GPUs), Digital Signal Processors (DSPs) and Field Programmable Gate Arrays (FPGAs). The Intel FPGA SDK for OpenCL is a suite of tools that allows developers to abstract away the complex FPGA-based development flow for a high-level software development flow. Users can focus on the design of hardware-accelerated kernel functions in OpenCL and then direct the tools to generate the low-level FPGA implementations. The approach makes the FPGA-based development more accessible to software users as the needs for hybrid computing using CPUs and FPGAs are increasing. It can also significantly reduce the hardware development time as users can evaluate different ideas with high-level language without deep FPGA domain knowledge. Benchmarking of OpenCL-based framework is an effective way for analyzing the performance of system by studying the execution of the benchmark applications. CHO is a suite of benchmark applications that provides support for OpenCL [1]. The authors presented CHO as an OpenCL port of the CHStone benchmark. Using Altera OpenCL (AOCL) compiler to synthesize the benchmark applications, they listed the resource usage and performance of each kernel that can be successfully synthesized by the compiler. In this report, we evaluate the resource usage and performance of the CHO benchmark applications using the Intel FPGA SDK for OpenCL and Nallatech 385A FPGA board that features an Arria 10 FPGA device. The focus of the report is to have a better understanding of the resource usage and performance of the kernel implementations using Arria-10 FPGA devices compared to Stratix-5 FPGA devices. In addition, we also gain knowledge about the limitations of the current compiler when it fails to synthesize a benchmark application.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2023

BUILD: Binary Understanding and Integration Logic for Dependencies (Final Report)

Increasingly diverse mission needs, the emergence of AI and cloud, and increasing hardware diversity are driving HPC software to be more complex. Modern codes are built from hundreds of small, complex components, and much of the software development process involves integrating these components rather than developing new components from scratch. The goal of the BUILD project was to ease the task of software integration for developers across LLNL’s programs. The project focused on (1) modeling software compatibility, (2) modeling ABI compatibility with binary analysis, (3) developing solver techniques to reason about compatibility, and (4) developing AI/ML models to fill gaps in our understanding of software compatibility. The project has developed several key technologies that help developers—by accelerating development workflows, removing the need for rebuilds, and enabling faster, automatic, and less error-prone code sharing. These technologies are used in LLNL codes and will be ready for the new El Capitan Exascale system in Livermore Computing. Many of these technologies have been hardened and integrated with LLNL’s Spack package manager, and they are already in use by production code teams. Results of BUILD have laid the groundwork for future advances in software integration—the ML and binary modification techniques developed in this project still need to be operationalized but have great potential to further speed up software integration.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2024

Docker Containers for MCNP ® Development

Containers are a revolutionary technology in software development and deployment that provides a lightweight, portable environment for ensuring consistency across multiple computing environments. In anticipation of the MCNP 6.3.1 release, two Docker container images have been released on DockerHub for general use. The MCNP source code is not included in the images, and users are still required to obtain it through RSICC. The images produced by Docker are compliant with the OCI (Open Container Initiative) standards, ensuring compatibility with other container engines such as Podman or Kubernetes’ CRI-O. Initially, the images are stored under the author’s personal space on DockerHub (docker.io/azukaitis), but they will be relocated to a dedicated MCNP group space once approved. In the future, they will also be available through the registry feature of the https://github.com/lanl/mcnp-containers project. The use of Docker provides a pre-configured environment for building and running MCNP, ensuring reproducibility of results across various host architectures. This significantly improves consistency when running MCNP on different systems. Notably, executables and installers from the Docker images have successfully passed the MCNP development branch testing suite on x86-64 architectures, including Windows, macOS, and Linux operating systems. Furthermore, testing has demonstrated compatibility with macOS Docker in emulation mode on the latest Apple Mac M2 Ultra hardware, ensuring robust support even on the latest platforms. In this document, we will provide a step-by-step guide to using the Docker images across multiple platforms. Additionally, we will present performance numbers for building and running the MCNP test suite.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2021

Serpent and MCNP Calculations of the Energy Deposition in the Transformational Challenge Reactor

This paper focuses on the calculation of the energy deposition in the Transformational Challenge Reactor by two major Monte Carlo codes: Serpent and MCNP. The first software computation relies on Kinetic Energy Released per unit Mass (KERMA) factors while the second one relies on Q-values. The results from these two independent computation methodologies are in very good agreement; however, Serpent runs much faster than MCNP (for the same computational model) and allows for a detailed energy deposition distribution from a 1-mm-side square mesh with a relative statistical error between 0.5% and 1%. This detailed energy deposition is suitable for multiphysics analyses aimed at design optimizations. In order to calculate the energy deposition, Serpent needs enhanced ACE files (distributed by the software developers). Unlike other Monte Carlo software that uses inputs based on Python or Java languages, the Serpent input syntax is very similar to that of MCNP; a Python script can convert a MCNP input to a Serpent input in seconds. For simulations not requiring the calculation of the energy deposition, Serpent can also read nuclear data from MCNP ACE files, which eventually improves the comparison of the results of the two codes.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

DOE OSTI2022

Spack-Manager

SAND2022-3282 O Spack-Manager is a lightweight wrapper for streamlining the software development and deployment cycle using Spack. Spack-Manager creates a uniform framework for developing, testing, and deploying specific software stacks for projects across multiple platforms while utilizing Spack as much as possible. It organizes Spack extensions, machine configurations, project customizations, and tools for features that are mostly project specific. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Sakievich, Philip↗

DOE OSTI2015

IDC Reengineering Phase 2 Project Scope

The Comprehensive Nuclear-Test-Ban Treaty Organization (CTBTO) operates the International Data Centre (IDC) to support treaty verification activities by Member States. The IDC collects, stores, processes, and distributes data from seismic, hydroacoustic, infrasound, and radionuclide stations. A significant component of the IDC is the seismic, hydroacoustic, and infrasound (SHI) processing system. The IDC has recognized the need to reengineer the SHI processing system and has defined a three-phase reengineering effort. IDC Reengineering Phase 1 (RP1) started in 2011 with the goal to significantly modernize SHI automatic and interactive data processing software, focusing on enhancements to individual components of the system. Reengineering Phase 2 (RP2), started in 2014, addresses the task of specifying a unified architecture for all SHI software, across processing stages, to pave the way for further software development and sustainment in the future. A key objective of RP2 is an architecture sufficient to provide a basis for a cost estimate for the development or enhancement of the software components and subsystems. This report provides a brief description of the scope of the IDC Reengineering Phase 2 project. It describes the goals and objectives of reengineering, the system definition, and the technical scope of the system.This report expands upon the “Scope for IDC Reengineering Phase 2”, July 2014, ECS-DIS-WGB-43-PTS-MATERIAL-12-ADD-1, produced by the IDC.

58 GEOSCIENCES↗

DOE OSTI2019

Mobile Device Application for Gunshot Trilateration

The New Mexico Small Business Assistance program at Sandia National Labs and Parental Values, LLC have agreed to explore commonly known principles to describe techniques in trilateration. The objective from Parental Values' standpoint is to use these commonly known principles for the purpose of their own software development by their employees. The software would be meant for mobile devices held by minors and the software would be monitored by parent(s) and/or guardians. The software would be able to notify parent(s)/guardian(s) in the event of an active shooter in a proximity close enough for the mobile devices' onboard microphones to detect a gunshot's noise. This document is meant for the employees of Parental Values to understand the commonly known principles as it applies to their intended implementation.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

DOE OSTI2015

Preliminary critical experiments validation of a lattice physic code LATC - 14415

Core and System Integrated Engine for design and analysis (COSINE) is an integrated nuclear engineering code package, which is being developed by State Nuclear Power Software Development Center (SNPSDC) in China. A lattice physics code named LATC is included in COSINE.LATC is a 2D, steady-state code for modeling PWR fuel. A WIMS-D 69 group micro library based on ENDF/B-VI is used and there are two transportation methods in LATC, such as two steps method (collision probability method for cell homogenization, discrete coordinate method for assembly homogenization) and one step method (MOC). The UO{sub 2} fuel assembly, which may contain guide tubes, burnable poisons such as Integral Fuel Burnable Absorbers (IFBA) / Wet Annular Burnable Absorbers (WABA)/ Pyrexes or control rods etc, can be calculated in LATC. LATC provides the required cross-section data for the core physics simulator analysis code in COSINE. In order to evaluate the quality of the LATC, a strategy of validation is researched and applied to the LATC. Firstly, a validation requirement analysis is performed, and the corresponding critical experiments are collected, and then a critical experimental matrix considering the variety of fuel enrichments, fuel pitch and water to uranium ratio is generated. Finally, a comparison of results between LATC using collision probability and discrete coordinate method and critical experiments are made to make sure that the code works well. According to the validation strategy discussed above, the preliminary validation is carried out and critical experiments are calculated according to the critical experimental matrix and results from LATC code are compared with reference results. The result shows that the calculated results agree well with critical experiments, and do not indicate any significant trends with respect to the various conditions considered. (authors)

42 ENGINEERING↗

DOE OSTI2015

On-Site Inspection RadioIsotopic Spectroscopy (Osiris) System Development

We have designed and tested hardware and software for the acquisition and analysis of high-resolution gamma-ray spectra during on-site inspections under the Comprehensive Nuclear-Test-Ban Treaty (CTBT). The On-Site Inspection RadioIsotopic Spectroscopy—Osiris—software filters the spectral data to display only radioisotopic information relevant to CTBT on-site inspections, e.g.,132I. A set of over 100 fission-product spectra was employed for Osiris testing. These spectra were measured, where possible, or generated by modeling. The synthetic test spectral compositions include non-nuclear-explosion scenarios, e.g., a severe nuclear reactor accident, and nuclear-explosion scenarios such as a vented underground nuclear test. Comparing its computer-based analyses to expert visual analyses of the test spectra, Osiris correctly identifies CTBT-relevant fission product isotopes at the 95% level or better.The Osiris gamma-ray spectrometer is a mechanically-cooled, battery-powered ORTEC Transpec-100, chosen to avoid the need for liquid nitrogen during on-site inspections. The spectrometer was used successfully during the recent 2014 CTBT Integrated Field Exercise in Jordan. The spectrometer is controlled and the spectral data analyzed by a Panasonic Toughbook notebook computer. To date, software development has been the main focus of the Osiris project. In FY2016-17, we plan to modify the Osiris hardware, integrate the Osiris software and hardware, and conduct rigorous field tests to ensure that the Osiris system will function correctly during CTBT on-site inspections. The planned development will raise Osiris to technology readiness level TRL-8; transfer the Osiris technology to a commercial manufacturer, and demonstrate Osiris to potential CTBT on-site inspectors.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2025

LLM Benchmarking with LLaMA2: Evaluating Code Development Performance Across Multiple Programming Languages

The rapid evolution of large language models (LLMs) has opened new possibilities for automating various tasks in software development. This paper evaluates the capabilities of the LLaMA 2-70B model in automating these tasks for scientific applications written in commonly used programming languages. Using representative test problems, we assess the model's capacity to generate code, documentation, and unit tests, as well as its ability to translate existing code between commonly used programming languages. Our comprehensive analysis evaluates the compilation, runtime behavior, and correctness of the generated and translated code. Additionally, we assess the quality of automatically generated code, documentation, and unit tests. Here, our results indicate that while LLaMA 2-70B frequently generates syntactically correct and functional code for simpler numerical tasks, it encounters substantial difficulties with more complex, parallelized, or distributed computations, requiring considerable manual corrections. We identify key limitations and suggest areas for future improvements to better leverage AI-driven automation in scientific computing workflows.

97 MATHEMATICS AND COMPUTING↗