SEARCH · Engineering Papers

Results for “software differences”

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 37 records · Page 2

All sources NASA NTRS DOE OSTI

DOE OSTI2022

Computational Fluid Dynamic Modeling of Dry Cask Simulator with Crosswind

The purpose of this study is to create a STAR-CCM+ model of a Belowground Vertical Dry Cask Simulator (BVDCS) at Sandia National Laboratories (SNL) and validate the model with SNL’s experimental results. The BVDCS consists of a single boiling water reactor assembly fitted with electric heaters encompassed by a containment vessel and shell to represent a belowground spent nuclear fuel (SNF) dry storage system. Blowers are located near the inlet and outlet of the BVDCS to simulate crosswind conditions. In addition to the experimental results, the STAR-CCM+ model developed for this study is compared with a previous computational fluid dynamics (CFD) model in a different software program, which is used as a software-to-software benchmark. The experimental results provide a dataset to compare the STAR-CCM+ model results for a variety of different conditions. The main objective is to validate and improve STAR-CCM+ CFD models for spent nuclear fuel storage systems with explicitly modeled external environments and “wind driven” crossflows. These CFD models aide in the study of external particle deposition in spent nuclear fuel storage systems, which is important to predicting the significance of chloride induced stress corrosion cracking (CISCC). In addition to experimental comparison, a sensitivity analysis study is performed using the STAR-CCM+ model. The sensitivity analysis provides a quantitative assessment of the sensitivity of various parameters. This helps provide information on various parameters that are of particular importance to constructing a model representative of real life systems. The STAR-CCM+ model compared well to the experimental results showing similar responses to changes in cross wind flow, and a number of parameters are identified for model improvement.

Jensen, Ben J.↗

DOE OSTI2020

Multiphysics for nuclear energy applications using a cohesive computational framework

With the recent development of advanced numerical algorithms, software design, and low-cost high-performance computer hardware, reliance on coupled multiphysics to predict the behavior of complex physical systems is beginning to become standard practice. This is especially true in nuclear energy applications where strong nonlinear interdependencies exist between reactor physics, radiation transport, multi-scale nuclear fuels performance, thermal fluids, etc. Resolving these nonlinear dependencies requires choices in multiphysics software approaches. Two main multiphysics modeling and simulation approaches have emerged. The first is based upon "code coupling" where disparate physics codes of different software design, code languages, and spatial and temporal integration schemes are coupled together with relatively complex data passing interfaces. The second multiphysics software approach is to employ a "cohesive" framework where all physics applications are developed with a common software design, i.e., data structures, syntax, input format, integrated spatial and temporal discretization schemes, etc. In this paper we present the Multiphysics Object-Oriented Simulation Environment (MOOSE) development and runtime framework and describe the framework's cohesive modeling and simulation multiphysics approach. Then, a "cohesive-like" extension of the MOOSE framework is presented where MOOSE-based physics software applications are efficiently coupled to non-MOOSE (external) physics codes to form multiphysics applications using MOOSE's unique interface capabilities. Finally, several examples of MOOSE's cohesive and cohesive-like multiphysics applications will be demonstrated. These multiphysics demonstrations will incorporate both MOOSE-based applications and external codes, including Nek5000, RELAP-7, TRACE, BISON, and Pronghorn.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS1984

The dynamics of software development project management: An integrative systems dynamic perspective

Rather than continuing to focus on software development projects per se, the system dynamics modeling approach outlined is extended to investigate a broader set of issues pertaining to the software development organization. Rather than trace the life cycle(s) of one or more software projects, the focus is on the operations of a software development department as a continuous stream of software products are developed, placed into operation, and maintained. A number of research questions are ""ripe'' for investigating including: (1) the efficacy of different organizational structures in different software development environments, (2) personnel turnover, (3) impact of management approaches such as management by objectives, and (4) the organizational/environmental determinants of productivity.

Vandervelde, W. E.↗

NASA NTRS2010

Comparison Campaign of VLBI Data Analysis Software - First Results

During the development of the Vienna VLBI Software VieVS at the Institute of Geodesy and Geophysics at Vienna University of Technology, a special comparison setup was developed with the goal of easily finding links between deviations of results achieved with different software packages and certain parameters of the observation. The object of comparison is the computed time delay, a value calculated for each observation including all relevant models and corrections that need to be applied in geodetic VLBI analysis. Besides investigating the effects of the various models on the total delay, results of comparisons between VieVS and Occam 6.1 are shown. Using the same methods, a Comparison Campaign of VLBI data analysis software called DeDeCC is about to be launched within the IVS soon.

Plank, Lucia↗

DOE OSTI2023

Engineering Computational Practices (Rev. 1)

This manual will attempt to motivate the use of an automated build system for the purposes of computational science and engineering. As part of this motivation, the surrounding computational practices of version control, documen tation, compute environment management, and regression testing will also be addressed as applied to the practice of computational engineering. Specifically, this manual intends to motivate the adoption of these traditional software engineering practices for use in research and production engineering simulation projects. This manual is not the first such effort in the greater scientific computing community. In fact, the authors relied heavily on the lesson plans of the Software Carpentry, established to teach computing skills to researchers in 1998. As the intention for this manual is to lay out fundamental practices of engineering computing, it will not attempt to fully teach the underlying concepts and will instead reference the well designed lesson plans of the Software Carpentry. Where possible, this manual will explain to general computing practices and concepts and limit discussion of specific software implementations to examples or vehicles for practice in concrete application. The specific software taught by the Software Carpentry curriculum is an excellent starting point to learn the core concepts of computational engi neering. However, the authors have found that applications to engineering simulation and analysis require translation of these software development concepts into the language and workflows of computational engineers. Adopting these computational tools may require engineers to re-imagine their workflows in some combination of traditional engineer ing and software concepts. It has also been necessary to extend existing software build systems for engineering practices beyond the simple wrap ping of engineering software execution. Where necessary, examples of specific software and their method of extension to engineering simulations will be given, with reference to the User Manual for recommended practical use. Where this manual relies on specific implementation examples, it should be understood that the practicing engineer may find that different software is more amenable to their specific work. It is always the overall collection of computational practices is more important than any specific software implementation. The ability to recognize which concepts are implemented by a software package will make a practicing engineer agile to changing project needs, computing resources, numeric solvers, programming languages, and even available funding.

42 ENGINEERING↗

NASA NTRS2012

NASA Integrated Network Monitor and Control Software Architecture

The National Aeronautics and Space Administration (NASA) Space Communications and Navigation office (SCaN) has commissioned a series of trade studies to define a new architecture intended to integrate the three existing networks that it operates, the Deep Space Network (DSN), Space Network (SN), and Near Earth Network (NEN), into one integrated network that offers users a set of common, standardized, services and interfaces. The integrated monitor and control architecture utilizes common software and common operator interfaces that can be deployed at all three network elements. This software uses state-of-the-art concepts such as a pool of re-programmable equipment that acts like a configurable software radio, distributed hierarchical control, and centralized management of the whole SCaN integrated network. For this trade space study a model-based approach using SysML was adopted to describe and analyze several possible options for the integrated network monitor and control architecture. This model was used to refine the design and to drive the costing of the four different software options. This trade study modeled the three existing self standing network elements at point of departure, and then described how to integrate them using variations of new and existing monitor and control system components for the different proposed deployments under consideration. This paper will describe the trade space explored, the selected system architecture, the modeling and trade study methods, and some observations on useful approaches to implementing such model based trade space representation and analysis.

Next Generation Uplink↗

DOE OSTI2023

A new Software Training Model at Belle II

The physics output of modern experimental HEP collaborations hinges not only on the quality of its software but also on the ability of the collaborators to make the best possible use of it. With the COVID-19 pandemic making in-person training impossible, the training paradigm at Belle II was shifted from periodic workshops towards guided self-study. To that end, the study material was rebuilt from scratch as a series of modular and hands-on lessons tightly integrated with the software documentation using Sphinx. Each lesson contains multiple exercises that are supplemented with hints and complete solutions. Rather than duplicating information, students are systematically taught to work with the technical reference documentation to find the important sections for themselves. Unit tests ensure that all examples work with different software versions, and feedback buttons make it easy to submit comments for improvements.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

NASA NTRS2008

Software Archive Related Issues

With the archive opening of the major X-ray and Gamma ray missions, the school is intended to provide information on the resource available in the data archive and the public software. This talk reviews the archive content, the data format for the major active missions Chandra, XMM-Newton, Swift, RXTE, Integral and Suzaku and the available software for each of these missions. It will explain the FITS format in general and the specific layout for the most popular mission, explaining the role of keywords and how they fit in the multimission standard approach embrace by the High Energy Community. Specifically, it reviews : the difference data levels and the difference software applicable; the popular/standard method of analysis for high level products such as spectra, timing and images; the role of calibration in the multi mission approach; how to navigate the archive query databases. It will present also how the school is organized and how the information provided will be relevant to each of the afternoon science projects that will be proposed to the students and led by a project leader

Angelini, Lorella↗

NASA NTRS2014

Using Modern Methodologies with Maintenance Software

Jet Propulsion Laboratory uses multi-mission software produced by the Mission Planning and Sequencing (MPS) team to process, simulate, translate, and package the commands that are sent to a spacecraft. MPS works under the auspices of the Multi-Mission Ground Systems and Services (MGSS). This software consists of nineteen applications that are in maintenance. The MPS software is classified as either class B (mission critical) or class C (mission important). The scheduling of tasks is difficult because mission needs must be addressed prior to performing any other tasks and those needs often spring up unexpectedly. Keeping track of the tasks that everyone is working on is also difficult because each person is working on a different software component. Recently the group adopted the Scrum methodology for planning and scheduling tasks. Scrum is one of the newer methodologies typically used in agile development. In the Scrum development environment, teams pick their tasks that are to be completed within a sprint based on priority. The team specifies the sprint length usually a month or less. Scrum is typically used for new development of one application. In the Scrum methodology there is a scrum master who is a facilitator who tries to make sure that everything moves smoothly, a product owner who represents the user(s) of the software and the team. MPS is not the traditional environment for the Scrum methodology. MPS has many software applications in maintenance, team members who are working on disparate applications, many users, and is interruptible based on mission needs, issues and requirements. In order to use scrum, the methodology needed adaptation to MPS. Scrum was chosen because it is adaptable. This paper is about the development of the process for using scrum, a new development methodology, with a team that works on disparate interruptible tasks on multiple software applications.

Scrum↗

DOE OSTI2022

TDCOSMO. IX. Systematic comparison between lens modelling software programs: time delay prediction for WGD 2038-4008

The importance of alternative methods for measuring the Hubble constant, such as time-delay cosmography, is highlighted by the recent Hubble tension. It is paramount to thoroughly investigate and rule out systematic biases in all measurement methods before we can accept new physics as the source of this tension. In this study, we perform a check for systematic biases in the lens modelling procedure of time-delay cosmography by comparing independent and blind time-delay predictions of the system WGD 2038-4008 from two teams using two different software programs: GLEE and LENSTRONOMY. The predicted time delays from the two teams incorporate the stellar kinematics of the deflector and the external convergence from line-of-sight structures. The un-blinded time-delay predictions from the two teams agree within 1.2σ, implying that once the time delay is measured the inferred Hubble constant will also be mutually consistent. However, there is a ~4σ discrepancy between the power-law model slope and external shear, which is a significant discrepancy at the level of lens models before the stellar kinematics and the external convergence are incorporated. We identify the difference in the reconstructed point spread function (PSF) to be the source of this discrepancy. When the same reconstructed PSF was used by both teams, we achieved excellent agreement, within ~0.6σ<, indicating that potential systematics stemming from source reconstruction algorithms and investigator choices are well under control. We recommend that future studies supersample the PSF as needed and marginalize over multiple algorithms or realizations for the PSF reconstruction to mitigate the systematics associated with the PSF. A future study will measure the time delays of the system WGD 2038-4008 and infer the Hubble constant based on our mass models.

79 ASTRONOMY AND ASTROPHYSICS↗

NASA NTRS1998

Effects of regenerator geometry on pulse tube refrigerator performance

This paper gives results of the cooling performance of a double-inlet pulse tube refrigerator using various regenerators. The same pulse tube was used for all the experiments and measured 4.76 mm in diameter and 46.2 mm in length. A commercial linear compressor with a swept volume of 4 cm3 was used in these experiments. The operating conditions were held constant at a mean pressure of 2.0 MPa and a frequency of 54 Hz. Using finite difference software called REGEN3.1, developed at NIST, and recent experiment results, we optimized a series of regenerators based on dimensions, materials and screen packing. The values used for calculating the thermal conduction through stacked screens by REGEN3.1 were based on recent experimental results from NIST. The regenerator tubes were designed using 316 stainless steel and titanium materials. The regenerator matrices investigated were 400-mesh and 500-mesh stainless steel screen. The valve settings for both orifices were adjusted to minimize the no-load temperature for all regenerators. A cooling capacity curve from 0 to 3 W was also determined. The performance of the pulse tube refrigerator using the different regenerators is discussed. The experimental results from the various regenerators are evaluated and compared with their corresponding numerically calculated coefficient of performance (COP) and regenerator design as determined by REGEN3.1.

NASA Discipline Life Sciences Technologies↗

NASA NTRS1994

Calibration of the TOPEX altimeter using a GPS buoy

The use of a spar buoy equipped with a Global Positioning System (GPS) antenna to calibrate the height measurement of the TOPEX radar altimeter is described. In order to determine the height of the GPS antenna phase center above the ocean surface, the buoy was also equipped with instrumentation to measure the instantaneous location of the waterline, and tilt of the bouy from vertical. The experiment was conducted off the California coast near the Texaco offshore oil platform, Harvest, during cycle 34 of the TOPEX/POSEIDON observational period. GPS solutions were computed for the bouy position using two different software packages, K&RS and GIPSY-OASIS II. These solutions were combined with estimates of the waterline location on the bouy to yield the height of the ocean surface. The ocean surface height in an absolute coordinate system combined with knowledge of the spacecraft height from tracking data provides a computed altimeter range measurement. By comparing this computed value to the actual altimeter measurement, the altimeter bias can be calibrated. The altimeter height bias obtained with the buoy using K&RS was -14.6 +/- 4 cm, while with GIPSY-OASIS II it was -13.1 +/- 4 cm. These are 0.1 cm and 1.6 cm different from the -14.7 +/- 4 cm result obtained for this flight overflight with the tide gauge instruments located on Platform Harvest.

Born, G. H.↗

NASA NTRS1996

Group Support Systems (GSS)

Groupware is a term describing an emerging computer software technology enhancing the ability of people to work together as a group, (a software driven 'group support system'). This project originated at the beginning of 1992 and reports were issued describing the activity through May 1995. These reports stressed the need for process as well as technology. That is, while the technology represented a computer assisted method for groups to work together, the Group Support System (GSS) technology als required an understanding of the facilitation process electronic meetings demand. Even people trained in traditional facilitation techniques did not necessarily aimlessly adopt groupware techniques. The latest phase of this activity attempted to (1) improve the facilitation process by developing training support for a portable groupware computer system, and (2) to explore settings and uses for the portable groupware system using different software, such as Lotus Notes.

Hamel, Gary P.↗

DOE OSTI2021

RAVEN Theory Manual

RAVEN is a software framework able to perform parametric and stochastic analysis based on the response of complex system codes. The initial development was aimed at providing dynamic risk analysis capabilities to the thermohydraulic code RELAP-7, currently under development at Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose stochastic and uncertainty quantification platform, capable of communicating with any system code. In fact, the provided Application Programming Interfaces (APIs) allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by input files or via python interfaces. RAVEN is capable of investigating system response and explore input space using various sampling schemes such as Monte Carlo, grid, or Latin hypercube. However, RAVEN strength lies in its system feature discovery capabilities such as: constructing limit surfaces, separating regions of the input space leading to system failure, and using dynamic supervised learning techniques. The development of RAVEN started in 2012 when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework arose. RAVEN’s principal assignment is to provide the necessary software and algorithms in order to employ the concepts developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just to identify the frequency of an event potentially leading to a system failure, but the proximity (or lack thereof) to key safety-related events. Hence, the approach is interested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. peak pressure in a pipe) is exceeded under certain conditions. Most of the capabilities, implemented having RELAP-7 as a principal focus, are easily deployable to other system codes. For this reason, several side activates have been employed (e.g. RELAP5-3D, any MOOSE-based App, etc.) or are currently ongoing for coupling RAVEN with several different software. The aim of this document is to provide a set of commented examples that can help the user to become familiar with the RAVEN code usage.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2020

Scalable Data-Intensive Geocomputation: A Design for Real-Time Continental Flood Inundation Mapping

The convergence of data-intensive and extreme-scale computing enables an integrated software and data ecosystem for scientific discovery. Developments in this realm will fuel transformative research in data-driven interdisciplinary domains. Geocomputation provides computing paradigms in Geographic Information Systems (GIS) for interactive computing of geographic data, processes, models, and maps. Because GIS is data-driven, the computational scalability of a geocomputation workflow is directly related to the scale of the GIS data layers, their resolution and extent, as well as the velocity of the geo-located data streams to be processed. Unique in high user interactivity and low end-to-end latency requirements, geocomputation applications will dramatically benefit from the convergence of high-end data analytics (HDA) and high-performance computing (HPC). The application level challenge, however, is to identify and eliminate computational bottlenecks that arise along a geocomputation workflow. Indeed, poor scalability at any of the workflow components is detrimental to the entire end-to-end pipeline. Here, we study a large geocomputation use case in flood inundation mapping that handles multiple national-scale geospatial datasets and targets low end-to-end latency. We discuss benefits and challenges for harnessing both HDA and HPC for data-intensive geospatial data processing and intensive numerical modeling of geographic processes. We propose an HDA+HPC geocomputation architecture design that couples HDA (e.g., Spark)-based spatial data handling and HPC-based parallel data modeling. Key techniques for coupling HDA and HPC to bridge the two different software stacks are reviewed and discussed.

Liu, Yan↗

DOE OSTI2024

Control And Optimization Modular Modeling Application For Nuclear Deployment

The purpose of the COMMAND code is to provide a flexible, scalable tool for use in developing, integrating, and testing the technologies necessary for achieving autonomous operations of advanced nuclear reactors. The code enables users to efficiently implement custom simulations and experiments by combining key methods from different software modules. These modules are focused on: modeling and simulation tools, such as nuclear simulation tools used for high-fidelity modeling (e.g., Reactor Excursion and Leak Analysis Program [RELAP5-3D] and Monte Carlo N-Particle [MCNP]); machine learning and optimization tools (e.g., anomaly detection and data-driven modeling techniques); advanced control in its digital, high-performance, and supervisory control forms (e.g., proportional integral derivative (PID) control and model predictive control (MPC); and integration with hardware through industrial communication protocols. To ensure flexibility and scalability, COMMAND was designed to be both modular—the software “pieces” all inherit from generic building blocks and can be combined and connected to create complicated simulations—and high performing—designed for parallel processing, enabling simulations and experiments to take advantage of multi-core computers, servers, and nodes. The code is written in the Python programming language due to the language's popularity, active community, and open-source and cross-platform nature. Maintaining consistency with other simulation tools used within the nuclear energy community, users implement simulations and experiments through text input files, which define components, parameters, connections, etc., through lines of text. Given that COMMAND is written in Python, these input files are native Python scripts, and so use the standard Python structure and formatting. This also enables users to take advantage of Python's extensive package library to develop custom capabilities for their specific use cases.

Faber, Jacob [Idaho National Laboratory (INL), Ida↗

DOE OSTI2022

Unified Language Frontend for Physic-Informed AI/ML

Artificial intelligence and machine learning (AI/ML) are becoming important tools for scientific modeling and simulation as in several other fields such as image analysis and natural language processing. ML techniques can leverage the computing power available in modern systems and reduce the human effort needed to configure experiments, interpret and visualize results, draw conclusions from huge quantities of raw data, and build surrogates for physics based models. Domain scientists in fields like fluid dynamics, microelectronics and chemistry can automate many of their most difficult and repetitive tasks or improve the design times by use of the faster ML-surrogates. However, modern ML and traditional scientific highperformance computing (HPC) tend to use completely different software ecosystems. While ML frameworks like PyTorch and TensorFlow provide Python APIs, most HPC applications and libraries are written in C++. Direct interoperability between the two languages is possible but is tedious and error-prone. In this work, we show that a compiler-based approach can bridge the gap between ML frameworks and scientific software with less developer effort and better efficiency. We use the MLIR (multi-level intermediate representation) ecosystem to compile a pre-trained convolutional neural network (CNN) in PyTorch to freestanding C++ source code in the Kokkos programming model. Kokkos is a programming model widely used in HPC to write portable, shared-memory parallel code that can natively target a variety of CPU and GPU architectures. Our compiler-generated source code can be directly integrated into any Kokkosbased application with no dependencies on Python or cross-language interfaces.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

DOE OSTI2023

Monte Carlo Analyses of the FOEHN Experiment

The FOEHN critical experiment, which has been carried out at Cadarache (France) in the reactor EOLE in the early 70s, was designed to verify RHF design analyses. This study focuses on the impact of the FOEHN experiment uncertainties on the calculation of the energy deposition. The latter has been obtained by the Monte Carlo codes Serpent and MCNP. In the calculation of the energy deposition, the first code relies on KERMA factors whereas the latter code relies on Q-values. The two Monte Carlo codes share the same geometry and material specifications. In addition to the design and experiment parameters uncertainties, nuclear data also impacts the calculation of the energy deposition. In this study, the MCNP simulations use three different nuclear data library sets: ENDF/B versions VII.0, VII.1, and VIII.0. Finally, the ksens card of MCNP, using perturbation theory, has been used to identify the cross sections and isotopes with largest impact on the effective multiplication factor. By showing that the use of different software and computational methodologies and design parameters uncertainties do not significantly impact the core power distribution, this work demonstrate the appropriateness of the tools and methods employed for the conversion of involute-plate reactors.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗