Search NASA⌕ Search

SEARCH · Search NASA

Results for “linux”

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 199 records · Page 11

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↗

Establishing Data Analysis Pipeline for Bulk ATAC-Seq Datasets

We developed an analysis pipeline for transposase-accessible chromatin sequencing (ATAC-Seq) data derived from bulk samples, which brings together publicly available R packages in addition to command-line tools designed for analysis of bulk ATAC-Seq data and can be run on any computer running a Linux-like operating system such as Ubuntu or Apple OSX.

97 MATHEMATICS AND COMPUTING↗

Precursor Analysis Report: Industroyer2 and Wiper Malware Targeting Ukrainian Energy Provider 2022

The Industroyer2 and Wiper Malware Targeting Ukrainian Energy Provider 2022 Precursor Analysis Report leverages publicly available information about the Industroyer2 cyber attack and catalogs anomalous observables for each technique employed in the attack. This analysis is based upon the methodology of the Cybersecurity for the Operational Technology Environment (CyOTE) program. An adversary attempted to cause a blackout in Ukraine in April 2022 by using the Industroyer2 malware against a regional Ukrainian energy provider. The adversary targeted eight high-voltage electrical substations and utilized the malware in tandem with disk wipers for Windows, Linux, and Solaris operating systems in an attempt to make response and recovery efforts more difficult. The adversary reused a piece of the original Industroyer malware designed to open circuit breakers and de-energize target substations. The adversary gained initial access to the victim’s enterprise network through unknown means in February 2022 and was able to perform reconnaissance, pivot to the operations network, and reside in the system for at least 51 days. This gave the adversary a detailed understanding of the environment and allowed them to customize the Industroyer2 malware to the victim’s operations network. However, defenders detected and stopped the attack before the adversary could achieve their intended impact. Had the Industroyer2 attack been successful, it could have caused a blackout for more than two million people during the early stages of Russia’s invasion of Ukraine. Researchers and analysts identified 22 unique techniques (used in a sequence of 31 steps) utilized during the attack with a total of 297 observables using MITRE ATT&CK® for Industrial Control Systems. The CyOTE program assesses observables accompanying techniques used prior to the triggering event to identify opportunities to detect malicious activity. If observables accompanying the attack techniques are perceived and investigated prior to the triggering event, earlier comprehension of malicious activity can take place. Twenty-three of the identified techniques used during the Industroyer2 cyber attack were precursors to the triggering event. Analysis identified 224 observables associated with these precursor techniques, 122 of which were assessed to have an increased likelihood of being perceived in the 51 days preceding the triggering event. The response and comprehension time could have been reduced if the observables had been identified earlier. The information gathered in this report contributes to a library of observables tied to a repository of artifacts, data sources, and technique detection references for practitioners and developers to support the comprehension of indicators of attack. Asset owners and operators can use these products if they experience similar observables or to prepare for comparable scenarios.

45 MILITARY TECHNOLOGY, WEAPONRY, AND NATIONAL DEF↗

FAST-1.2.2: A Computer Code for Thermal-Mechanical Nuclear Fuel Analysis under Steady-state and Transients

Fuel Analysis under Steady-state and Transients (FAST) is the U.S. Nuclear Regulatory Commission (NRC)’s computer code that calculates the steady-state and transient response of nuclear reactor fuel rods during long-term in-reactor burnup, anticipated operational occurrences (AOOs), design basis accidents (DBAs), and dry storage conditions. The code calculates the temperature, pressure, and deformation of a fuel rod as functions of time-dependent fuel rod power and coolant boundary conditions. The phenomena modeled by the code include heat conduction through the fuel and other materials, heat transfer from the cladding-to-coolant, cladding elastic and plastic deformation (including creep), fuel-cladding mechanical interaction, fission gas release from the fuel, rod internal pressure, void volume, and cladding oxidation. The code contains necessary material and coolant properties, as well as clad-to-coolant heat transfer correlations, for normal operation through postulated accidents and AOOs for today’s U.S.-based light water reactor (LWR) fuel designs. FAST-1.2.2 also contains preliminary materials and models for new LWR fuel concepts, such as accident tolerant fuel (ATF), and non-LWR fuel concepts such as metallic fuels for sodium fast reactors (SFRs). FAST has been developed for use on Windows and Linux operating systems. This document describes FAST-1.2.2 and is one of a series of documents on the code; the other documents detail the material properties used by FAST as well as its integral assessment to experiments and commercial data.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Graphical User Interface for a Biasing Board for the PSEC6

The PSEC6 is an application-specific integrated circuit (ASIC) designed for a readout system for a large area picosecond photodetector (LAPPD). The PSEC6 is currently in fabrication and pending testing. The testing system for the PSEC5, the previous iteration of the ASIC, required expensive and non-portable equipment, because the ASIC needs twelve adjustable reference voltages. The new testing system consists of an low-cost, open-source, cross-platform graphical user interface (GUI), a digital system, and a biasing board. The digital system is the interface between the GUI and biasing board, and can be implemented on a microcontroller or field-programmable gate array (FPGA). The biasing board contains twelve digital-to-analog converters (DACs) that are configurable via the GUI, which gives users the ability to write voltage values to all or specific DACs. The GUI was developed in C on Linux using the widget library GTK4 and cross-compiled for Windows compatibility. I2C and SPI protocols were implemented on an Adafruit Feather ESP32-S3 microcontroller to write commands to the DACs and PSEC6. A hardware implementation of the I2C protocol is in development on an FPGA. Since LAPPDs will be used by the Accelerator Neutrino Neutron Interaction Experiment (ANNIE) at Fermilab, the PSEC6 testing system in this internship project can potentially benefit future neutrino research. The project is relevant to the Department of Energy’s microelectronics mission, because the PSEC6 is an ASIC that will handle fast time signals arriving from the detector for readout. It also provided experience with building a cross-platform user interface, practicing digital design and implementation in hardware description language (HDL), and using simulations to inform new design iterations.

Guerrero, Sasha Camila [North Central Coll.]↗

White-Rabbit-Disciplined FPGA Readout for Fermilab Timing Events

Fermilab's accelerator timing links broadcast short event codes to thousands of devices at once, but the links themselves carry no absolute notion of time; that comes separately from a White Rabbit reference. This work builds the piece that ties the two together on a single board. On a Xilinx Kria KR260 (Zynq UltraScale+), the programmable logic decodes a real Fermilab TCLK link, stamps every event with an absolute White-Rabbit \{sec, ns\} UTC time, and reads the timestamped stream out over AXI4-Lite; a thin Linux process on the same die publishes each event into a Redis stream on the control network. To exercise the full chain on one board, the decoded events are re-encoded as gigabit ACLK, transmitted out an SFP+ optical port, looped back over a short fiber jumper, and decoded again on the same timeline, and are additionally mirrored as an ACLK-Lite Manchester waveform for benchtop probing. Across sustained, multi-day testing against real Fermilab TCLK, the pipeline has decoded, timestamped, and published hundreds of millions of events with practically zero loss, and folding the timestamped stream on the 60-second accelerator supercycle recovers the machine's periodic structure directly from the published data.

Rossel, Jacob [Fermilab; UC, Berkeley (main)] (ORC↗

Searching for the Most Harmful Field Errors in the HSR IR Superconducting Magnets

In this project, we improve beam stability for the Electron-Ion Collider. Magnetic field errors can reduce beam stability, making it essential to identify the field errors that have the greatest impact on accelerator performance. However, this is particularly challenging because beam stability depends on the complex interactions of many magnetic field errors, resulting in a high-dimensional and nonlinear optimization problem. We determine which field errors are the most influential for the large physical aperture superconducting magnet B2PF, a critical magnet in the Interaction Region (IR) in the Hadron Storage Ring (HSR). We complete and analyze nearly 30,000 simulations on the Brookhaven National Laboratory Linux Cluster by varying 18 nonlinear magnetic field errors. We evaluate beam stability using the dynamic aperture and the tune diffusion. We identify the field errors that most strongly influence beam stability and establish quantitative field error tolerances that improve accelerator performance.

43 PARTICLE ACCELERATORS↗

The Importance of Interflow to Groundwater Recharge in a Snowmelt-Dominated, Alpine Watershed, Geophysical Research Letters: Modeling and Data Package

This data package contains hydrologic modeling input and output files for the East River (ER_PRMS.zip) and Copper Creek (CC_GSFLOW.zip) for water years 1987 to 2018. These data were used to generate simulated results published in Geophysical Research Letters (Carroll et al., 2019) describing the importance of interflow in generating groundwater recharge in the upper subalpine. The East River and Copper Creek are part of the Watershed Function Scientific Focus Area (WFSFA) located in the Upper Colorado River Basin, United States. The hydrologic model uses the U.S. Geological Survey coupled groundwater and surface water flow model (GSFLOW). Input and output files are askii format, while the model executable (gsflow.exe), source code, example problems and documentation describing model files is provided at the following U.S. Geological Survey website. https://www.usgs.gov/software/coupled-ground-water-and-surface-water-flow-model-gsflow. GSFLOW executables are compiled for either Microsoft Windows or Linux operating systems.

54 ENVIRONMENTAL SCIENCES↗

OctoFAS: A Two-Level Fair Scheduler That Increases Fairness in Network-Based Key-Value Storage

We identified a fairness problem in a network-based key-value storage system using Intel Storage Performance Development Kit (SPDK) in a multitenant environment. In such an environment, each tenant’s I/O service rate is not fairly guaranteed compared to that of other tenants. To address the fairness problem, we propose OctoFAS, a two-level fair scheduler designed to improve overall throughput and fairness among tenants. The two-level scheduler of OctoFAS consists of (i) inter-core scheduling and (ii) intra-core scheduling. Through inter-core scheduling, OctoFAS addresses the load imbalance problem that is inherent in SPDK on the storage server by dynamically migrating I/O requests from overloaded cores to underloaded cores, thereby increasing overall throughput. Intra-core scheduling prioritizes handling requests from starving tenants over well-fed tenants within core-specific event queues to ensure fair I/O services among multiple tenants. OctoFAS is deployed on a Linux cluster with SPDK. Through extensive evaluations, we found that OctoFAS ensures that the total system throughput remains high and balanced, while enhancing fairness by approximately 10% compared to the baseline, when both scheduling levels operate in a hybrid fashion.

97 MATHEMATICS AND COMPUTING↗

Low Latency and High Data Rate (LLHD) Scheduler: A Multipath TCP Scheduler for Dynamic and Heterogeneous Networks

The scheduler is a crucial component of the multipath transmission control protocol (MPTCP) that dictates the path that a data packet takes. Schedulers are in charge of delivering data packets in the right order to prevent delays caused by head-of-line blocking. The modern Internet is a complicated network whose characteristics change in real-time. MPTCP schedulers are supposed to understand the real-time properties of the underlying network, such as latency, path loss, and capacity, in order to make appropriate scheduling decisions. However, the present scheduler does not take into account all of these characteristics together, resulting in lower performance. We present the low latency and high data rate (LLHD) scheduler, which successfully makes scheduling decisions based on real-time information on latency, path loss, and capacity, and achieves around 25% higher throughput and 45% lower data transmission delay than Linux’s default MPTCP scheduler.

97 MATHEMATICS AND COMPUTING↗

Singularity v1.x

Singularity is a container solution designed to facilitate mobility of compute across systems and HPC infrastructures. It does this by creating minimal containers that are defined by a specfile and files from the host system are used to build the container. The resulting container can then be launched by any Linux computer with Singularity installed regardless if the programs inside the container are present on the target system, or if they are a different version, or even incompatible versions. Singularity achieves extreme portability without sacrificing usability thus solving the need of mobility of compute. Singularity containers can be executed within a normal/standard command line process flow.

Kurtzer, Gregory↗

BM3DORNL

BM3DORNL is a high-performance, open-source library for removing streak and ring artifacts from computed-tomography (CT) data, developed for neutron imaging at Oak Ridge National Laboratory's Spallation Neutron Source (VENUS beamline) and applicable to X-ray CT as well. Ring artifacts — concentric rings in reconstructed slices caused by detector pixel-to-pixel response non-uniformities — appear as vertical streaks in the sinogram and degrade both image quality and quantitative analysis. BM3DORNL operates in the sinogram domain using an adaptation of the BM3D (block-matching and 3D collaborative filtering) algorithm (Dabov et al., 2007). It provides a dedicated streak-removal mode, a true multi-scale BM3D variant (after Mäkinen et al., 2021) that suppresses wide streaks single-scale methods miss, and an alternative Fourier–SVD method (~2.6× faster) combining FFT-based energy detection with rank-1 SVD. The computationally intensive core is implemented in Rust with parallel (Rayon) block matching, integral-image pre-screening, and optimized transforms, and is exposed through a simple Python API (with an optional GUI) so it integrates directly into existing tomography reconstruction pipelines. It processes both 2D sinograms and 3D sinogram stacks, is pip-installable for Linux and macOS, and is documented at https://bm3dornl.readthedocs.io.

Zhang, Chen [Oak Ridge National Laboratory (ORNL),↗

Design of the SLAC RCE Platform: A General Purpose ATCA Based Data Acquisition System

The SLAC RCE platform is a general purpose clustered data acquisition system implemented on a custom ATCA compliant blade, called the Cluster On Board (COB). The core of the system is the Reconfigurable Cluster Element (RCE), which is a system-on-chip design based upon the Xilinx Zynq family of FPGAs, mounted on custom COB daughter-boards. The Zynq architecture couples a dual core ARM Cortex A9 based processor with a high performance 28nm FPGA. The RCE has 12 external general purpose bi-directional high speed links, each supporting serial rates of up to 12Gbps. 8 RCE nodes are included on a COB, each with a 10Gbps connection to an on-board 24-port Ethernet switch integrated circuit. The COB is designed to be used with a standard full-mesh ATCA backplane allowing multiple RCE nodes to be tightly interconnected with minimal interconnect latency. Multiple shelves can be clustered using the front panel 10-gbps connections. The COB also supports local and inter-blade timing and trigger distribution. An experiment specific Rear Transition Module adapts the 96 high speed serial links to specific experiments and allows an experiment-specific timing and busy feedback connection. This coupling of processors with a high performance FPGA fabric in a low latency, multiple node cluster allows high speed data processing that can be easily adapted to any physics experiment. RTEMS and Linux are both ported to the module. The RCE has been used or is the baseline for several current and proposed experiments (LCLS, HPS, LSST, ATLAS-CSC, LBNE, DarkSide, ILC-SiD, etc).

43 PARTICLE ACCELERATORS↗

Stonix, Version 0.x

STONIX is a program for configuring UNIX and Linux computer operating systems. It applies configurations based on the guidance from publicly accessible resources such as: NSA Guides, DISA STIGs, the Center for Internet Security (CIS), USGCB and vendor security documentation. STONIX is written in the Python programming language using the QT4 and PyQT4 libraries to provide a GUI. The code is designed to be easily extensible and customizable.

Source record↗

shifter

Shifter enables application virtualization or containerization in large-scale HPC environments. This technology decreases the effort to port applications to or between HPC sites while increasing reproducibility and scientific productivity. Shifter works by converting application/container images to a common format, and then leverages basic Linux functionality to make that image available to batch jobs run in the HPC environment.

Jacobsen, Douglas↗

HTTPS Web Servers

This software is contains reference implementations for how to secure and harden Linux Web Servers for compliance with OMB M-15-13 compliance requirements.

Lee, Ian↗

LK Scripting Language

The LK scripting language is a simple and fast computer programming language designed for easy integration with existing software to enable automation of tasks. The LK language is used by NREL’s System Advisor Model (SAM), the SAM Software Development Kit (SDK), and SolTrace products. LK is easy extensible and adaptable to new software due to its small footprint and is designed to be statically linked into other software. It is written in standard C++, is cross-platform (Windows, Linux, and OSX), and includes optional portions that enable direct integration with graphical user interfaces written in the open source C++ wxWidgets Version 3.0+ toolkit.

Source record↗

Two-Year Operational Evaluation Of A Consumer Electronics-Based Data Acquisition System For Equipment Monitoring

Oak Ridge National Laboratory (ORNL) has performed a two-year evaluation of the performance of an in-house developed consumer electronics-based data acquisition system (DAS). The main advantage of this approach compared to conventional instrumentation grade systems is cost; instrument grade data acquisition systems average costs range from $800 to $2,000 per channel compared to a range of $200 - $400 per channel for a consumer electronics-based system. The DAS is operated as a full-time in-situ vibration monitor. The resulting data stream is streamed over the ORNL network, at an aggregate rate of approximately 2 megabytes/s, to a Linux server. The server includes the capability to implement event-triggered data stores, as well as real-time files for the implementation of continuous display monitoring of the spectra. Detailed spectral analysis is performed post event. The DAS is installed on a large industrial chiller and cooling water pump associated with ORNL’s Titan supercomputer. These mechanical systems include rotating components that operate at fundamental frequencies within the range of 30 Hz to over 3 KHz. Evaluation of the DAS data over a two-year operating period leads to the conclusion that for many industrial processes this system could form the basis for a cost effective means of obtaining operating health data in real time from rotating machinery. The deployment has also shown that the DAS technology is reliable. Furthermore, because the cost of the DAS is low, the other significant advantage of this approach is that the DAS can be deployed in a dedicated manner and operated on a full-time basis.

Wetherington Jr, G↗