Search NASA⌕ Search

SEARCH · Search NASA

Results for “code portability”

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.

331 records · Page 19
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

CondiDiag1.0: a flexible online diagnostic tool for conditional sampling and budget analysis in the E3SM atmosphere model (EAM)

Abstract. Numerical models used in weather and climate prediction take into account a comprehensive set of atmospheric processes (i.e., phenomena) such as the resolved and unresolved fluid dynamics, radiative transfer, cloud and aerosol life cycles, and mass or energy exchanges with the Earth's surface. In order to identify model deficiencies and improve predictive skills, it is important to obtain process-level understanding of the interactions between different processes. Conditional sampling and budget analysis are powerful tools for process-oriented model evaluation, but they often require tedious ad hoc coding and large amounts of instantaneous model output, resulting in inefficient use of human and computing resources. This paper presents an online diagnostic tool that addresses this challenge by monitoring model variables in a generic manner as they evolve within the time integration cycle. The tool is convenient to use. It allows users to select sampling conditions and specify monitored variables at run time. Both the evolving values of the model variables and their increments caused by different atmospheric processes can be monitored and archived. Online calculation of vertical integrals is also supported. Multiple sampling conditions can be monitored in a single simulation in combination with unconditional sampling. The paper explains in detail the design and implementation of the tool in the Energy Exascale Earth System Model (E3SM) version 1. The usage is demonstrated through three examples: a global budget analysis of dust aerosol mass concentration, a composite analysis of sea salt emission and its dependency on surface wind speed, and a conditionally sampled relative humidity budget. The tool is expected to be easily portable to closely related atmospheric models that use the same or similar data structures and time integration methods.

58 GEOSCIENCES↗
DOE OSTI2022

WORM (Write One, Read Many)

WORM (Write One, Run Many) is an easy to use, cross platform, embedded and extensible, functional programming language designed to facilitate the creation of input-decks for computer codes that use standard ASCII text files for input. WORM makes it easy to create generic (yet, complex and powerful) reusable models. Additionally its nature allows for complex calculations and routines to be coded once and easily reused, further simplifying the creation of input decks. WORM (Write One, Run Many) is a powerful and versatile tool designed to improve the efficiency of today’s criticality safety analyst by allowing: + input decks for parametric studies to be created quickly and easily, + calculations and variables to be imbedded into any input deck, thus allowing for meaningful parameter specifications, + problems to be specified using any combination of units, and + complex mathematically defined models to be created. A very simple syntax is employed, and therefore the WORM is easy to learn. A WORM model is essentially a standard input deck with some of its numerical values replaced by WORM code. WORM code may include and evaluate the following mathematical operators and functions: addition, subtraction, multiplication, division, exponentiation, modulus, sine, cosine, tangent, arcsine, arccosine, arctangent, the natural logarithm, logarithm base 10, integer truncation, absolute value, and random number. Several common constants, e.g., pi, e, and Avogadros’s Number (both as 6.022e23 and 0.6022), are predefined in WORM. Additionally, many unit conversion factors are also predefined: millimeters, meters, inches, feet, yards, and mils to centimeters; kilograms, pounds, and ounces to grams; liters, milliliters, gallons, and fluid ounces to cubic centimeters; and angular degrees to radians. For parametric studies, WORM supports various shorthand list specifications: the explicit step size, linear interpolation, and logarithmic interpolation. The list notation sequentially assigns multiple values to a name. WORM creates an input deck for each value of the name. If multiple lists are used, WORM steps through each list individually, i.e., WORM creates input decks corresponding to each and every permutation of the list values. Additionally, a library of standard material definitions and Perl subroutines are included. Any one of these files can be incorporated into the subject model with a simple WORM read command. WORM is completely written in Perl, the Practical Extraction and Reporting Language. Perl is one of the most portable programming languages available today. As such, the WORM works on practically any computer platform.

Sartor, Raymond↗
DOE OSTI2025

Experiences with SYCL on AMD GPUs with Kokkos

With the recent diversification of the hardware landscape in the high-performance computing (HPC) community, performance-portability solutions are becoming more and more important. One of the most popular choices is Kokkos, which recently became a Linux Foundation project. Most of its development is supported by the US Department of Energy and the French Alternative Energies and Atomic Energy Commission. Kokkos is implemented as a C++ library with multiple backends to support CPUs as well as various GPU architectures. These backends include OpenMP, CUDA, HIP, and also SCYL. This approach enables users to leverage the preferred vendor toolchain for the respective platform (e.g. CUDA, ROCm, OneAPI). The SYCL backend is used to target Intel GPUs, in particular to support the Aurora exascale supercomputer. However, SYCL itself also offers a large degree of portability, and in fact Kokkos’ CI for SYCL has been running on NVIDIA hardware due to a lack of access to Intel GPUs. In this report, we describe our experience with using Kokkos SYCL backend on AMD GPUs targeting the Frontier supercomputer at Oak Ridge National Laboratory. The two major SYCL implementations are DPC++ and AdaptiveCpp. While the Kokkos SYCL backend has been implemented using the former, the latter was the first implementation to target AMD GPUs. We will discuss the experience with both of these SYCL implementations in terms of functionality and performance. Using Kokkos to evaluate SYCL toolchains has a number of benefits. Kokkos’ use of SYCL is fairly complex, exercising features such as graphs, relocatable device functions, atomics – including for non-arithmetic types, as well as pinned and page migratable memory allocations. Kokkos also needs to implement capabilities such as Kokkos’ hierarchical parallelism that are not a straight-forward mapping to SYCL capabilities. Furthermore, a large number of libraries and applications that represent diverse use cases are implemented in Kokkos, providing readily available test cases for a toolchain evaluation. Preliminary results show that support for AMD GPUs in DPC++ is much less mature than for NVIDIA GPUs or Intel GPUs. While the situation has improved significantly over the last year, we still encounter many runtime failures, dispatching problems, and code generation issues. With AdaptiveCpp the challenges arise even earlier in the evaluation process. Since Kokkos’ SYCL implementation is largely focused on supporting Intel GPUs, we opted to leverage SYCL extensions which are available in DPC++ but not in AdaptiveCpp. Furthermore, AdaptiveCpp appears to be less conformant with the SYCL2020 standard which Kokkos relies on. In some cases, we are able to work around the lack of feature support, in other cases we have to disable certain Kokkos capabilities to evaluate the toolchain. Our evaluation will leverage Kokkos’ unit tests to establish basic functionality and feature completeness. We then use simple benchmarks for components of a CG implementation as a measure of usability and performance of the SYCL toolchains.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

Simulation-based Design of a Shadow Shield for the MIND Backpack System

Modeling and simulation is a cost- and time-saving method to study conceptual designs of radiation detection systems. MCNP radiation transport code has been an indispensable tool in development of radiation detection systems, and the PINS systems have also utilized MCNP modeling and simulation in the system development. MCNP models of the PINS systems have been used to understand detector responses and to fill the gap in experimental data. Recently, the MIND backpack system was announced to be developed, and its prototype design was required to conduct laboratory tests and demonstrations. A shadow shield is the component to be designed by Idaho National Laboratory in order to maximize the performance of a backpack system while meeting the sponsor’s requirements. MCNP modeling and simulation was utilized to find the best specification of a shadow shield. This study was performed to down-select a shadow shield design for the MIND system. A total of 24 designs for a shadow shield were identified to build MCNP models, and their simulation results were used to prioritize each design. As a quantitative performance metric, an equation of Figure-of-Merit was introduced in the decision making analysis. In addition, the Analytic Hierarchy Process was adopted to prioritize and recommend best performing shadow shield designs.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2019

Towards Vendor and Operating System Independence of USB-based portable multi-channel analyzers

The nuclear measurements group is called on to develop portable, user friendly systems that performs at, or near, laboratory standards. These systems typically consist of a detector and a USB-based multi-channel analyzer. An ORTEC digi-Base is an example of a USB-based portable multi-channel analyzer with 14-pin photomultiplier tube base for gamma-ray spectroscopy applications with NaI(Tl) and other scintillation detectors. Operating system independence - we want to be able to develop applications that are 'future-proof' and can run on the best hardware for the job: desktop, laptop, tablet, phone, or embedded device. To do that we need our software to be operating system independent. Hardware vendor independence - to use the most appropriate equipment for the job, while still maintaining our rapid method development, we would like our software that uses this equipment to be independent of the specific vendor or model of the hardware. To do that we need a common interface to each vendor's equipment (high voltage, gain, start, stop, clear, etc.) In prior work, we were able to use an existing library to communicate with an ORTEC digi-base via Linux and Android. However the application developed did not have a user friendly front-end. Part of this work was to develop a simple user interface to control the settings of the hardware from Android. While OS independence is the final goal, another goal is standardized software for user-application development. For current purposes those standard systems are Windows 7, Windows 10, and Python 3. Our next step was to develop a common software interface between a front-end user interface and back-end hardware communication software. This was done using Python's Ctypes library. Ctypes is a foreign function library for Python. It provides C compatible data types, and allows calling functions in DLLs or shared libraries. It can be used to wrap these libraries in pure Python. Ctypes exports the cdll, and Windows windll and oledll objects, for loading dynamic link libraries. You load libraries by accessing them as attributes of these objects. cdll loads libraries which export functions using the standard cdecl calling convention. The first steps of developing the common software interface have been done. Once the software interface has been developed the next goal will be to develop hardware specific back-end software that way rapid user facing software can be developed using equipment that is 'on-hand' and once finished prototyping, the 'best' hardware can be chosen for the specific implementation.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2018

A Portable Quantitative High-Resolution Gamma System for In-Situ Waste, D and D, and Emergency Measurements - 18573

The Canberra ISOCS system has been a highly successful and technologically innovative product since its introduction about 22 years ago. The combination of field-portable HPGe detectors, flexible shield/collimator set, and accurate mathematical efficiency calibration software made in-situ gamma spectroscopy measurements very practical. Good quality in-situ measurements are economically beneficial for items that are either large or complex, in comparison to the cost, time and impracticality of extracting a sample for laboratory measurements or producing representative calibration standards. And where the item is not homogeneous [most of the time for in-situ measurement situations] an assay of a large part of the item has been shown to be more accurate than a few widely dispersed extracted samples [the normal case]. However the size, weight, cost and complexity of the full-size ISOCS system limit its usefulness in some situations. A companion device was recently introduced, and is the subject of this document. The gamma sensor is a 1 cm{sup 3} CZT detector. It is surrounded by an optional tungsten shield/collimator set with a tripod for support. The detector is powered solely by a USB connection from a laptop PC. The full power of the ISOCS efficiency calibration software can be used with this detector. This entire package is less than 15 kg, needs no cooling, and is quite rugged, in comparison to the 120 kg for ISOCS with sensitive HPGe detectors which need Liquid Nitrogen or electro-mechanical cooling. Furthermore this CZT package is about 1/3 the cost. This is a very complementary device for the many current ISOCS users, especially for quick initial evaluations or simple situations where the full energy resolution and sensitivity of the HPGe ISOCS are not needed. Operating nuclear power plants or those in the initial phases of decommissioning are prime examples. Their complex layout often precludes the deployment of the full-sized ISOCS system, whereas the CZT system can be hand-carried there and very quickly setup for a measurement. The small detector size, and therefore low efficiency, is not a disadvantage, and in many cases is an advantage due to the elevated radioactivity of the items. This can be used to assay items in tanks, spills on floors, activity on filters, waste or items in small containers, and waste in drums. In the event of an emergency, it can be quickly deployed to measure gas or liquid effluent streams, air particulate and iodine filters in the field, or even in-vivo thyroid activity. Examples of measurements at nuclear facilities are shown and discussed in further detail, along with estimated detection limits. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2019

Informative Path Planning for Mapping Radiation

This project involves making measurements of contaminated areas using portable radiation detectors and small robots. Tasks involve operating detectors and small robots, combining data acquisition for the two systems, and automating the systems. The end result is a radiation map of contamination areas. Localization of radioactive sources and mapping of contamination distribution is essential when responding to emergencies, or when dealing with cleanup efforts. Radiation maps are used for situational awareness and for establishing a safe perimeter. However, it may be hazardous or impossible for humans to safely enter the site and survey the area. Informative Path Planning (IPP) is used to design a path for a robotic sensor platform to gather the most information about the radiation distribution while operating under the set of constraints given by the dynamics of the robot and other requirements such as minimizing the overall mission time. The key challenge for IPP is the tight coupling in multiple layers of decisions: Selection of locations to visit; Allocation of sensors to those locations; Processing of information gathered. Given a robot equipped with a basic gamma detector and Lidar sensor, how can we efficiently explore an unknown environment in such a way that we can satisfy the robot's constraints while simultaneously maximizing the accuracy of the map and minimizing the total runtime? This work presents a systematic procedure for IPP and environmental mapping that: Selects the best locations at which to sample; Finds the best path for robots; Estimates the measurement value at unknown locations using a Gaussian Process regression framework. Given a set of points where radiation measurements were taken, we are utilizing a Gaussian Process Regression with a Matern kernel to reconstruct the shape of the underlying ground truth. Mapping is done via the Robot Operating System's OpenSlam Gmapping package, which creates a 2D occupancy grid map. Simulated trials were run with a radiation source placed at random locations, and allowing the robot to select and move towards 20 samples at separate locations, as well as sampling along the path while moving. The simulated sensor model assumed an efficiency of 0.3, collection time of 1 second. Various weighting schemes were tested and compared. Quantitative evaluations often favored exploitation-heavy weighting schemes where μ was emphasized, with the Root Mean Squared Error (RMSE) quickly tending towards 2, whereas qualitative comparisons would favor exploration-biased schemes with greater weight on σ. The difference comes from operators often favoring knowing the general location of a source, rather than the exact properties of a source. Weighting of the path-length π often reduced the quality of the regression as less exploration occurred, however this may be deemed a worthwhile trade-off under certain circumstances, such as with sensitive robots. Successfully developed a methodology for informative path-planning for a robot to efficiently gather information and create a map of radiation. In the future, we would like to focus on: Hardware trials with integration of the robot platform and the IPP software; More refined sensor and environmental modeling; Multiple robot platforms.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗