Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Distributed File Systems”

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 307 records · Page 17
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Parallel Wavefront Analysis for a 4D Interferometer

This software provides a programming interface for automating data collection with a PhaseCam interferometer from 4D Technology, and distributing the image-processing algorithm across a cluster of general-purpose computers. Multiple instances of 4Sight (4D Technology s proprietary software) run on a networked cluster of computers. Each connects to a single server (the controller) and waits for instructions. The controller directs the interferometer to several images, then assigns each image to a different computer for processing. When the image processing is finished, the server directs one of the computers to collate and combine the processed images, saving the resulting measurement in a file on a disk. The available software captures approximately 100 images and analyzes them immediately. This software separates the capture and analysis processes, so that analysis can be done at a different time and faster by running the algorithm in parallel across several processors. The PhaseCam family of interferometers can measure an optical system in milliseconds, but it takes many seconds to process the data so that it is usable. In characterizing an adaptive optics system, like the next generation of astronomical observatories, thousands of measurements are required, and the processing time quickly becomes excessive. A programming interface distributes data processing for a PhaseCam interferometer across a Windows computing cluster. A scriptable controller program coordinates data acquisition from the interferometer, storage on networked hard disks, and parallel processing. Idle time of the interferometer is minimized. This architecture is implemented in Python and JavaScript, and may be altered to fit a customer s needs.

Rao, Shanti R.↗
NASA NTRS1992

C Language Integrated Production System, Version 5.0

CLIPS 5.0 provides cohesive software tool for handling wide variety of knowledge with support for three different programming paradigms: rule-based, object-oriented, and procedural. CLIPS 5.0 available in version for IBM Personal Computer (MSC-21916), in one for Macintosh computer (MSC-21927), and in one for DEC VAX computer (MSC-21929). Computer Software Management and Information Center (COSMIC) offers five distribution versions of CLIPS 5.0. Executable files, source code, utilities, and examples included on program medium. All distribution versions include identical source code for command-line version of CLIPS 5.0. Source code compatible with ANSI C and compilable on any computer with ANSI C compiler. Only Macintosh version of CLIPS 5.0 includes window interface.

Riley, Gary↗
DOE OSTI2024

Generation and validation of comprehensive synthetic weather histories using auto-regressive moving-average models

As energy system design moves to more complex methods of optimization including machine learning there is a significant need for more weather data than is available. One method to solve this is using synthetic data models such as the auto-regressive moving-average (ARMA) model which has been frequently utilized to create such data. This paper looks at extending the ARMA algorithm to generate solar components through the use of clearsky detrending, maintaining vector relationships and by leveraging physical relationships. The method for the creation of entirely synthetic weather data files including key weather variables for energy system analysis is presented. Furthermore, a detailed comparison of energy system simulations utilizing both real and synthetic data is made using NREL’s System Advisor Model. Whilst good agreement is made for the solar variables, and other weather variables, ARMA methods often fail to capture the standard deviation and skew of annual weather distributions. Vector-ARMA is shown to maintain correlations between variables and thus generate data sets that perform similarly in energy system design. Here, it is finally shown that the ARMA method fails to preserve day-today correlations in weather variables and thus over-predicts optimal energy storage by 21% for a residential solar application.

42 ENGINEERING↗
DOE OSTI2025

I/O in Machine Learning Applications on HPC Systems: A 360-degree Survey

Growing interest in Artificial Intelligence (AI) has resulted in a surge in demand for faster methods of Machine Learning (ML) model training and inference. This demand for speed has prompted the use of high performance computing (HPC) systems that excel in managing distributed workloads. Because data is the main fuel for AI applications, the performance of the storage and I/O subsystem of HPC systems is critical. In the past, HPC applications accessed large portions of data written by simulations or experiments or ingested data for visualizations or analysis tasks. ML workloads perform small reads spread across a large number of random files. This shift of I/O access patterns poses several challenges to modern parallel storage systems. In this paper, we survey I/O in ML applications on HPC systems, and target literature within a 6-year time window from 2019 to 2024. We define the scope of the survey, provide an overview of the common phases of ML, review available profilers and benchmarks, examine the I/O patterns encountered during offline data preparation, training, and inference, and explore I/O optimizations utilized in modern ML frameworks and proposed in recent literature. Lastly, we seek to expose research gaps that could spawn further R&D.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2015

An Upgrade of the Imaging for Hypersonic Experimental Aeroheating Testing (IHEAT) Software

The Imaging for Hypersonic Experimental Aeroheating Testing (IHEAT) code is used at NASA Langley Research Center to analyze global aeroheating data on wind tunnel models tested in the Langley Aerothermodynamics Laboratory. One-dimensional, semi-infinite heating data derived from IHEAT are used to design thermal protection systems to mitigate the risks due to the aeroheating loads on hypersonic vehicles, such as re-entry vehicles during descent and landing procedures. This code was originally written in the PV-WAVE programming language to analyze phosphor thermography data from the two-color, relativeintensity system developed at Langley. To increase the efficiency, functionality, and reliability of IHEAT, the code was migrated to MATLAB syntax and compiled as a stand-alone executable file labeled version 4.0. New features of IHEAT 4.0 include the options to batch process all of the data from a wind tunnel run, to map the two-dimensional heating distribution to a three-dimensional computer-aided design model of the vehicle to be viewed in Tecplot, and to extract data from a segmented line that follows an interesting feature in the data. Results from IHEAT 4.0 were compared on a pixel level to the output images from the legacy code to validate the program. The differences between the two codes were on the order of 10-5 to 10-7. IHEAT 4.0 replaces the PV-WAVE version as the production code for aeroheating experiments conducted in the hypersonic facilities at NASA Langley.

Mason, Michelle L.↗
DOE OSTI2021

Demonstrating SolarPILOT’s Python API Through Heliostat Optimal Aimpoint Strategy Use Case

SolarPILOT is a software package that generates solar field layouts and characterizes the optical performance of concentrating solar power (CSP) tower systems. SolarPILOT was developed by the National Renewable Energy Laboratory (NREL) as a stand-alone desktop application but has also been incorporated into NREL’s1 System Advisor Model (SAM) in a simplified format. Prior means for user interaction with SolarPILOT have included the application’s graphical interface, the SAM routines with limited configurability, and through a built-in scripting language called “LK.” This paper presents a new, full-featured, Python-based application programmable interface (API) for SolarPILOT, which we hereafter refer to as CoPylot. CoPylot provides access to all SolarPILOT’s capabilities to generate and characterize power tower CSP systems seamlessly through Python. Supported capabilities include (i) creating and destroying a model instance with message reporting tools; (ii) accessing and setting any SolarPILOT variable including custom land boundaries for field layouts; (iii) programmatically managing receiver and heliostat objects with varied attributes for systems with multiple receiver or heliostat types; (iv) generating, assigning, and modifying solar field layouts including the ability to set individual heliostat locations, aimpoints, soiling rates, and reflectivity levels; (v) simulating solar field performance; (vi) returning detailed results describing performance of individual heliostats, the aggregate field, and receiver flux distribution; and, (vii) exporting Python-based model instances to multiple file formats. CoPylot enables Python users to perform detailed CSP tower analysis utilizing either the Hermite expansion technique (analytical) or the SolTrace ray-tracing engine. In addition to CoPylot’s functionality, Python users have access to the over 100,000 open-source libraries to develop, analyze, optimize, and visualize power tower CSP research. This enables CSP researchers to perform analysis that was previously not possible through SolarPILOT’s existing interfaces. This paper discusses the capabilities of CoPylot and presents a use case wherein we demonstrate optimal solar field aiming strategies.

41 EE - Solar Energy Technologies Office (EE-4S)↗
DOE OSTI2025

SCALE Input and Result Files Supporting SCALE Inventory and Reactivity Analysis of the gFHR

This dataset contains input and result files of computational simulations with the SCALE code system. The simulations cover radionuclide inventory and reactivity analyses of a fluoride salt-cooled high temperature pebble-bed reactor (PB-FHR), specifically the generic FHR benchmark. Users wanting to reproduce results from this dataset are required to obtain a license to the SCALE code system for which details on the distribution can be found here: https://www.ornl.gov/scale/releases

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2025

Continuing Development of the Nuclear Data Processing Code AMPX [Poster]

The ENDF/B-VIII.1 evaluation library has seen a great growth in the thermal neutron scattering sub-library. The SCALE code system has traditionally approached CE transport by assuming that the CE library on disk represented the fully expanded cumulative probability distributions, conditional on exiting angle and marginal on exiting energy. While this is a complete description of the data, it comes at the potential cost of large amounts of on-disk storage. This approach was strained by several TSL files in ENDF/B-VIII.1, such as graphite, which contained data for a large number of Bragg edges. In the fully expanded probability distributions, this was found to be a disproportionately large fraction of the SCALE CE library.

GNDS↗
NASA NTRS1991

Requirements for a network storage service

Sandia National Laboratories provides a high performance classified computer network as a core capability in support of its mission of nuclear weapons design and engineering, physical sciences research, and energy research and development. The network, locally known as the Internal Secure Network (ISN), comprises multiple distributed local area networks (LAN's) residing in New Mexico and California. The TCP/IP protocol suite is used for inter-node communications. Scientific workstations and mid-range computers, running UNIX-based operating systems, compose most LAN's. One LAN, operated by the Sandia Corporate Computing Computing Directorate, is a general purpose resource providing a supercomputer and a file server to the entire ISN. The current file server on the supercomputer LAN is an implementation of the Common File Server (CFS). Subsequent to the design of the ISN, Sandia reviewed its mass storage requirements and chose to enter into a competitive procurement to replace the existing file server with one more adaptable to a UNIX/TCP/IP environment. The requirements study for the network was the starting point for the requirements study for the new file server. The file server is called the Network Storage Service (NSS) and its requirements are described. An application or functional description of the NSS is given. The final section adds performance, capacity, and access constraints to the requirements.

Kelly, Suzanne M.↗
DOE OSTI2020

UNITY: Unified Memory and Storage Space

UNITY is a 36-month project focused on providing design and evaluate a new distributed storage paradigm that unifies the traditionally distinct application views of memory- and file-based data storage into a single scalable and resilient environment. The project is a collaboration among Oak Ridge National Laboratory (ORNL, Lead institution), Los Alamos National Labs (LANL), and Georgia Tech (GT). The main contributions of the GT team have been around development of low level systems software for best leveraging the capabilities of new types of persistent memory technologies, and for development of methods for intelligent data management across memory/storage substrates with heterogeneous components. GT contributed the Phoenix library for optimized checkpoint/restart for HPC I/O for systems with non-volatile memory (NVM), the NVStream library for NVM-specialized streaming I/O for HPC workflows, the CoMerge, Mnemo and Kleio solutions for intelligent data management on NVM-based systems. These contributions result in significant improvements in both application performance and system efficiency.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1992

Requirements for a network storage service

Sandia National Laboratories provides a high performance classified computer network as a core capability in support of its mission of nuclear weapons design and engineering, physical sciences research, and energy research and development. The network, locally known as the Internal Secure Network (ISN), was designed in 1989 and comprises multiple distributed local area networks (LAN's) residing in Albuquerque, New Mexico and Livermore, California. The TCP/IP protocol suite is used for inner-node communications. Scientific workstations and mid-range computers, running UNIX-based operating systems, compose most LAN's. One LAN, operated by the Sandia Corporate Computing Directorate, is a general purpose resource providing a supercomputer and a file server to the entire ISN. The current file server on the supercomputer LAN is an implementation of the Common File System (CFS) developed by Los Alamos National Laboratory. Subsequent to the design of the ISN, Sandia reviewed its mass storage requirements and chose to enter into a competitive procurement to replace the existing file server with one more adaptable to a UNIX/TCP/IP environment. The requirements study for the network was the starting point for the requirements study for the new file server. The file server is called the Network Storage Services (NSS) and is requirements are described in this paper. The next section gives an application or functional description of the NSS. The final section adds performance, capacity, and access constraints to the requirements.

Kelly, Suzanne M.↗
DOE OSTI2021

Ducted Assembly Steady-State Heat Transfer Software (DASSH)

The Ducted Assembly Steady-State Heat transfer software (DASSH) is being developed at Argonne National Laboratory to perform a steady-state thermal fluids calculation to determine the coolant flow and temperature distribution for a hexagonal reactor core configuration with ducted assemblies. DASSH is intended to be used in the early stages of the reactor design process when assembly components can be undefined or are undergoing considerable design changes. DASSH provides a rapid assessment of the temperature and flow distribution to allow quick characterization of the system and identification of problem areas. This document is a guide for DASSH users. It summarizes the core capabilities of DASSH and highlights differences between DASSH and SE2-ANL. Instructions for obtaining and installing DASSH are provided along with some guidelines and recommendations for newer Python users. It covers the structure of the input file, provides directions for running DASSH, describes the various output files produced by the code, and provides instructions for visualizing data. Examples demonstrating various DASSH options are included. DASSH is under active development, so it is anticipated that this guide will grow and evolve as the code is updated.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1982

Documentation for the machine-readable version of OAO 2 filter photometry of 531 stars of diverse types

A magnetic tape version of the ultraviolet photometry of 531 stars observed with the Wisconsin Experiment Package aboard the Orbiting Astronomical Observatory (OAO 2) is described. The data were obtained with medium band interference filters and were reduced to a uniform magnitude system. They represent a subset of partially reduced data currently on file at the National Space Science Data Center. The document is intended to enable users of the tape file to read and process data without problems or guesswork. For technical details concerning the observations, instrumentation limitations, and interpretation of the data the reference publication should be consulted. This document was designed for distribution with any machine-readable version of the OAO 2 photometric data.

Warren, W. H., Jr.↗
NASA NTRS1983

Documentation for the machine-readable version of the revised Catalogue of Stellar Rotational Velocities of Uesugi and Fukuda (1982)

The machine-readable catalog provides mean data on the old Slettebak system for 6472 stars. The catalog results from the review, analysis and transformation of 11460 data from 102 sources. Star identification, (major catalog number, name if the star has one, or cluster identification, etc.), a man projected rotational velocity, and a list of source references re included. The references are given in a second file included with the catalog when it is distributed on magnetic tape. The contents and/formats of the the data and reference files of the machine-readable catalog are described to enable users to read and process the data.

Warren, W. H., Jr.↗
NASA NTRS1992

A self-defining hierarchical data system

The Self-Defining Data System (SDS) is a system which allows the creation of self-defining hierarchical data structures in a form which allows the data to be moved between different machine architectures. Because the structures are self-defining they can be used for communication between independent modules in a distributed system. Unlike disk-based hierarchical data systems such as Starlink's HDS, SDS works entirely in memory and is very fast. Data structures are created and manipulated as internal dynamic structures in memory managed by SDS itself. A structure may then be exported into a caller supplied memory buffer in a defined external format. This structure can be written as a file or sent as a message to another machine. It remains static in structure until it is reimported into SDS. SDS is written in portable C and has been run on a number of different machine architectures. Structures are portable between machines with SDS looking after conversion of byte order, floating point format, and alignment. A Fortran callable version is also available for some machines.

Bailey, J.↗
NASA NTRS2007

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗
NASA NTRSDate not supplied

Ground Segment Operations Concept for the Orion Artemis-2 Optical Communications System

The ACCESS Project (formerly Space Network) will implement an optical communications ground segment to support the Orion Artemis II Optical Communications (O2O) demonstration as part of the next manned human spaceflight mission to the moon, Artemis II. O2O implements laser communication (lasercomm) technology for operational use on the Orion series of spacecraft, as a development test objective (DTO), in order to demonstrate the feasibility and operational utility of lasercomm for human spaceflight missions. O2O consists of three segments: Space Segment, Ground Segment, and Operations Segment. The Space Segment consists of the Space Terminal Element and the Orion spacecraft. The Space Terminal Element effort is managed by the GSFC Laser-Enhanced Mission Communications Navigation and Operational Services (LEMNOS) project in collaboration with MIT Lincoln Laboratory. The Ground Segment consists of an optical ground terminal (GT) at the White Sands Complex (WSC), which is being developed in collaboration with MIT Lincoln Laboratory, the Ground Segment Operations and Analysis (GSOA) element and Ground Data Element (GDE), and a second optical GT in the Optical Communications Telescope Laboratory (OCTL) at the JPL Table Mountain Facility. The Operations Segment consists of the Artemis II Mission Control Center (MCC), the Lasercomm Space Terminal Console (LSTC), and the Lasercomm Link Planning & Analysis Center (LPAC), all located at the Johnson Space Center (JSC). O2O utilizes pulse-position modulation (PPM) direct-to-earth services resulting in an 80 Mbps downlink data rate from lunar orbit. The O2O concept of operations is to provide optical services for a minimum of 1 hour per day for each day of the Artemis II mission. O2O will utilize a 10-20 Mbps uplink data rate and 40-260 Mbps downlink data rate, depending on the Artemis II mission phase. The ACCESS project will also provide a centralized mission data interface for user data distribution and storage to the MCC and perform planning and scheduling of services in coordination with the Operations Segment for the O2O Ground Segment. The O2O Ground Segment will support the following O2O mission phases: Pre-Mission Planning; Daily Operations Planning; Event Execution; and Post-Pass Reporting. O2O will be used to exchange data files between Orion and the MCC and to distribute real-time video through the optical downlink service to the MCC; which would not be possible without the high-bandwidth link that O2O will provide to Orion. In this paper, I will discuss the O2O Ground Segment development approach and how it will support these critical O2O functions: plan and schedule the contact; acquire and track the optical link; flow information bidirectionally; distribute information; and control and accommodate the system.

optical communications↗
DOE OSTI2023

Energy Equity Opportunities in Distributed Wind Hybrid Systems for Rural Loads

Distributed wind (DW) hybrid systems, or combinations of distributed energy resources with wind technologies, have the potential to provide energy equity benefits for rural loads. However, project developers and end-users do not understand these benefits well. This report outlines energy equity opportunities that result directly from DW-hybrid projects and proposes a framework that demonstrates how to consider equity in the DW-hybrid system, which can enhance existing resilience and valuation tools by incorporating a way to include equity considerations. Energy equity opportunities achievable with DW-hybrid systems for rural loads are defined by the core principles of energy justice for use in a proposed equity framework. As well, a catalog of equity resources, metrics, technology-agnostic frameworks, and best practices are linked in an attached Excel file. Electric cooperatives, technical assistance providers (including national laboratory and DOE staff), DW project developers, and technology providers can use this work to understand, evaluate, and define equitable outcomes for potential DW-hybrid projects.

17 WIND ENERGY↗