Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “executable files”

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 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

General Mission Analysis Tool (GMAT) Architectural Specification. Draft

Early in 2002, Goddard Space Flight Center (GSFC) began to identify requirements for the flight dynamics software needed to fly upcoming missions that use formations of spacecraft to collect data. These requirements ranged from low level modeling features to large scale interoperability requirements. In 2003 we began work on a system designed to meet these requirement; this system is GMAT. The General Mission Analysis Tool (GMAT) is a general purpose flight dynamics modeling tool built on open source principles. The GMAT code is written in C++, and uses modern C++ constructs extensively. GMAT can be run through either a fully functional Graphical User Interface (GUI) or as a command line program with minimal user feedback. The system is built and runs on Microsoft Windows, Linux, and Macintosh OS X platforms. The GMAT GUI is written using wxWidgets, a cross platform library of components that streamlines the development and extension of the user interface Flight dynamics modeling is performed in GMAT by building components that represent the players in the analysis problem that is being modeled. These components interact through the sequential execution of instructions, embodied in the GMAT Mission Sequence. A typical Mission Sequence will model the trajectories of a set of spacecraft evolving over time, calculating relevant parameters during this propagation, and maneuvering individual spacecraft to maintain a set of mission constraints as established by the mission analyst. All of the elements used in GMAT for mission analysis can be viewed in the GMAT GUI or through a custom scripting language. Analysis problems modeled in GMAT are saved as script files, and these files can be read into GMAT. When a script is read into the GMAT GUI, the corresponding user interface elements are constructed in the GMAT GUI. The GMAT system was developed from the ground up to run in a platform agnostic environment. The source code compiles on numerous different platforms, and is regularly exercised running on Windows, Linux and Macintosh computers by the development and analysis teams working on the project. The system can be run using either a graphical user interface, written using the open source wxWidgets framework, or from a text console. The GMAT source code was written using open source tools. GSFC has released the code using the NASA open source license.

Hughes, Steven P.↗
DOE OSTI2019

Occupancy Simulator Solver v1.0

Occupant schedules at room level are crucial information to building energy modeling which quantifies occupant-related energy efficiency technologies and controls for new building design as well as existing building retrofits to reduce energy use and GHG emissions in buildings. The Occupancy Simulator Solver is an executable software component that simulates the stochastic behavior of occupant presence and movement in a building using the Markov-chain model. Occupancy Simulator Solver is the calculation engine of the web App Occupancy Simulator, which takes high level input on occupants, spaces and events, then calls the Solver to simulate occupant movement and generate occupant schedules for each space. The generated schedules capture diversity and stochastic nature of occupant activities (e.g., in office, meetings, breaks, lunch). These schedules are stored in CSV files and can be downloaded from the App and used for building performance simulation.

Hong, Tianzhen↗
NASA NTRS2019

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗
NASA NTRSDate not supplied

Automating Maneuvers: Considerations for Collision Avoidance

As more space operators implement large constellations of spacecraft, automating orbit maintenance maneuvers becomes a key feature of their operations concept to ensure that the workload is manageable. However, the practice of performing a maneuver without sharing the plan with other nearby spacecraft causes a risk that two spacecraft will collide, not only destroying the spacecraft involved, but creating debris that will affect all other spacecraft using that orbit regime. In order to share the maneuver plan, a predicted ephemeris file containing the maneuver must be sent to a central authority to screen against predicted trajectories of all other on-orbit objects to determine where and when close approaches will occur that may need to be mitigated. Currently the screening authority used by US operators is the 19th Space Defense Squadron; screenings are performed once every 8 hours, meaning that spacecraft using automated maneuvering need to allow 16 hours to share their maneuver plan via the screening process in advance of maneuver execution in case one screening is missed and the next needs to be used. In an effort to speed up the screening process to benefit spacecraft using automated maneuvering, a prototype system for performing near-real-time screenings has been developed in support of the NASA Starling mission, a constellation of four cubesats that fly at the same altitude as the SpaceX Starlink constellation. Both of these constellations perform automated maneuvering, so without screening the planned maneuvers before execution, the two constellations would risk a collision. This paper describes the traditional conjunction assessment (CA) process, the prototype real-time CA screening capability, plans for the experiment to test the prototype, and next steps.

conjunction assessment↗
NASA NTRSDate not supplied

Automating Maneuvers: Considerations for Collision Avoidance

As more space operators implement large constellations of spacecraft, automating orbit maintenance maneuvers becomes a key feature of their operations concept to ensure that the workload is manageable. However, the practice of performing a maneuver without sharing the plan with other nearby spacecraft causes a risk that two spacecraft will collide, not only destroying the spacecraft involved, but creating debris that will affect all other spacecraft using that orbit regime. In order to share the maneuver plan, a predicted ephemeris file containing the maneuver must be sent to a central authority to screen against predicted trajectories of all other on-orbit objects to determine where and when close approaches will occur that may need to be mitigated. Currently the screening authority used by US operators is the 19th Space Defense Squadron; screenings are performed once every 8 hours, meaning that spacecraft using automated maneuvering need to allow 16 hours to share their maneuver plan via the screening process in advance of maneuver execution in case one screening is missed and the next needs to be used. In an effort to speed up the screening process to benefit spacecraft using automated maneuvering, a prototype system for performing near-real-time screenings has been developed in support of the NASA Starling mission, a constellation of four cubesats that fly at the same altitude as the SpaceX Starlink constellation. Both of these constellations perform automated maneuvering, so without screening the planned maneuvers before execution, the two constellations would risk a collision. This paper describes the traditional conjunction assessment (CA) process, the prototype real-time CA screening capability, plans for the experiment to test the prototype, and next steps.

conjunction assessment↗
DOE OSTI2026

TRACE Input Modernization

This work presents a Tom’s Obvious Minimal Language (TOML)-based representation of input for the US Nuclear Regulatory Commission’s TRAC/RELAP Advanced Computational Engine (TRACE) thermal hydraulics code. Implemented using the Workbench Analysis Sequence Processor (WASP), the approach maps traditional TRACE input structures to a hierarchical format composed of named parameters, typed values, and native data collections. The resulting representation preserves TRACE’s existing modeling capabilities while providing a modern, structured interface for model development and management. WASP further extends TOML through a file import directive that supports modular model composition and reusable input organization. In addition, WASP provides extended array data entry convenience with various data repeat and interpolation capabilities. Examples of the new TOML syntax are provided for major TRACE input categories, including hydraulic components, heat structures, control systems, and trip logic. The TOML representation establishes a foundation for improved validation, tooling, automation, and model maintainability while remaining compatible with existing TRACE workflows. To facilitate migration to the TOML-based input format, the TRACE executable now supports conversion of native TRACE input into an intermediate JSON representation. A Python utility subsequently transforms the JSON data into an equivalent TOML model. Lastly, the TRACE executable now supports execution using TOML-formatted input.

Lefebvre, Robert A. [Oak Ridge National Laboratory↗
NASA NTRS2009

EOS MLS Level 1B Data Processing, Version 2.2

A computer program performs level- 1B processing (the term 1B is explained below) of data from observations of the limb of the Earth by the Earth Observing System (EOS) Microwave Limb Sounder (MLS), which is an instrument aboard the Aura spacecraft. This software accepts, as input, the raw EOS MLS scientific and engineering data and the Aura spacecraft ephemeris and attitude data. Its output consists of calibrated instrument radiances and associated engineering and diagnostic data. [This software is one of several computer programs, denoted product generation executives (PGEs), for processing EOS MLS data. Starting from level 0 (representing the aforementioned raw data, the PGEs and their data products are denoted by alphanumeric labels (e.g., 1B and 2) that signify the successive stages of processing.] At the time of this reporting, this software is at version 2.2 and incorporates improvements over a prior version that make the code more robust, improve calibration, provide more diagnostic outputs, improve the interface with the Level 2 PGE, and effect a 15-percent reduction in file sizes by use of data compression.

Perun, Vincent↗
NASA NTRS2011

A High-Availability, Distributed Hardware Control System Using Java

Two independent coronagraph experiments that require 24/7 availability with different optical layouts and different motion control requirements are commanded and controlled with the same Java software system executing on many geographically scattered computer systems interconnected via TCP/IP. High availability of a distributed system requires that the computers have a robust communication messaging system making the mix of TCP/IP (a robust transport), and XML (a robust message) a natural choice. XML also adds the configuration flexibility. Java then adds object-oriented paradigms, exception handling, heavily tested libraries, and many third party tools for implementation robustness. The result is a software system that provides users 24/7 access to two diverse experiments with XML files defining the differences

high-availability↗
NASA NTRS2016

Tool for Generation of MAC/GMC Representative Unit Cell for CMC/PMC Analysis

This document describes a recently developed analysis tool that enhances the resident capabilities of the Micromechanics Analysis Code with the Generalized Method of Cells (MAC/GMC) 4.0. This tool is especially useful in analyzing ceramic matrix composites (CMCs), where higher fidelity with improved accuracy of local response is needed. The tool, however, can be used for analyzing polymer matrix composites (PMCs) as well. MAC/GMC 4.0 is a composite material and laminate analysis software developed at NASA Glenn Research Center. The software package has been built around the concept of the generalized method of cells (GMC). The computer code is developed with a user friendly framework, along with a library of local inelastic, damage, and failure models. Further, application of simulated thermomechanical loading, generation of output results, and selection of architectures to represent the composite material have been automated to increase the user friendliness, as well as to make it more robust in terms of input preparation and code execution. Finally, classical lamination theory has been implemented within the software, wherein GMC is used to model the composite material response of each ply. Thus, the full range of GMC composite material capabilities is available for analysis of arbitrary laminate configurations as well. The primary focus of the current effort is to provide a graphical user interface (GUI) capability that generates a number of different user-defined repeating unit cells (RUCs). In addition, the code has provisions for generation of a MAC/GMC-compatible input text file that can be merged with any MAC/GMC input file tailored to analyze composite materials. Although the primary intention was to address the three different constituents and phases that are usually present in CMCs-namely, fibers, matrix, and interphase-it can be easily modified to address two-phase polymer matrix composite (PMC) materials where an interphase is absent. Currently, the tool capability includes generation of RUCs for square packing, hexagonal packing, and random fiber packing as well as RUCs based on actual composite micrographs. All these options have the fibers modeled as having a circular cross-sectional area. In addition, a simplified version of RUC is provided where the fibers are treated as having a square cross section and are distributed randomly. This RUC facilitates a speedy analysis using the higher fidelity version of GMC known as HFGMC. The first four mentioned options above support uniform subcell discretization. The last one has variable subcell sizes due to the primary intention of keeping the RUC size to a minimum to gain the speed ups using the higher fidelity version of MAC. The code is implemented within the MATLAB (The Mathworks, Inc., Natick, MA) developmental framework; however, a standalone application that does not need a priori MATLAB installation is also created with the aid of the MATLAB compiler.

Materials Engineering↗
NASA NTRS1992

Simultaneous real-time data collection methods

This paper describes the development of electronic test equipment which executes, supervises, and reports on various tests. This validation process uses computers to analyze test results and report conclusions. The test equipment consists of an electronics component and the data collection and reporting unit. The PC software, display screens, and real-time data-base are described. Pass-fail procedures and data replay are discussed. The OS2 operating system and Presentation Manager user interface system were used to create a highly interactive automated system. The system outputs are hardcopy printouts and MS DOS format files which may be used as input for other PC programs.

Klincsek, Thomas↗
NASA NTRS2014

Using the NASA GRC Sectored-One-Dimensional Combustor Simulation

The document is a user manual for the NASA GRC Sectored-One-Dimensional (S-1-D) Combustor Simulation. It consists of three sections. The first is a very brief outline of the mathematical and numerical background of the code along with a description of the non-dimensional variables on which it operates. The second section describes how to run the code and includes an explanation of the input file. The input file contains the parameters necessary to establish an operating point as well as the associated boundary conditions (i.e. how it is fed and terminated) of a geometrically configured combustor. It also describes the code output. The third section describes the configuration process and utilizes a specific example combustor to do so. Configuration consists of geometrically describing the combustor (section lengths, axial locations, and cross sectional areas) and locating the fuel injection point and flame region. Configuration requires modifying the source code and recompiling. As such, an executable utility is included with the code which will guide the requisite modifications and insure that they are done correctly.

Combustion Stability↗
DOE OSTI2026

Detector Interface for Streaming, Control, and Open-source integration (DISCO) v1.0.0

This suite consists of a multi-package ecosystem featuring detector emulators, EPICS areaDetector drivers, and remote server frameworks designed for the Advanced Light Source (ALS). Engineered for high-bandwidth devices—including VFCCD, Timepix3, Timepix4, and related pixel detectors—the software simulates hardware, wraps vendor SDKs into remote-callable servers, and integrates with open-source control systems. Key Capabilities: Distributed SDK Architecture: Server packages wrap hardware-specific SDKs, allowing areaDetector drivers to execute remote framework calls. This isolates proprietary libraries from the EPICS IOC, enhancing stability and enabling distributed computing across beamline networks. Device Support: Custom drivers for VFCCD, the Timepix family, and similar sensors optimize the data path from hardware control to high-speed transport. Full-Stack Emulation: Sophisticated emulator packages allow end-to-end pipeline testing and software development without requiring physical hardware or beam time. Integrated Workflows: Supports high-bandwidth streaming for real-time analysis and robust, metadata-rich file-based workflows (e.g., HDF5/NeXus). By standardizing interfaces across heterogeneous hardware, this suite reduces technical debt. It provides the ALS with a scalable, open-source solution to manage massive data rates within a unified control environment.

Mahl, Johannes [Lawrence Berkeley National Laborat↗
DOE OSTI2020

GIWAXS-SIIRkit: scattering intensity, indexing and refraction calculation toolkit for grazing-incidence wide-angle X-ray scattering of organic materials

Grazing-incidence wide-angle X-ray scattering (GIWAXS) has become an increasingly popular technique for quantitative structural characterization and comparison of thin films. For this purpose, accurate intensity normalization and peak position determination are crucial. At present, few tools exist to estimate the uncertainties of these measurements. Here, a simulation package is introduced called GIWAXS-SIIRkit , where SIIR stands for scattering intensity, indexing and refraction. Furthermore, the package contains several tools that are freely available for download and can be executed in MATLAB. The package includes three functionalities: estimation of the relative scattering intensity and the corresponding uncertainty based on experimental setup and sample dimensions; extraction and indexing of peak positions to approximate the crystal structure of organic materials starting from calibrated GIWAXS patterns; and analysis of the effects of refraction on peak positions. Additionally, each tool is based on a graphical user interface and designed to have a short learning curve. A user guide is provided with detailed usage instruction, tips for adding functionality and customization, and exemplary files.

36 MATERIALS SCIENCE↗
NASA NTRS1988

Memory protection

Accidental overwriting of files or of memory regions belonging to other programs, browsing of personal files by superusers, Trojan horses, and viruses are examples of breakdowns in workstations and personal computers that would be significantly reduced by memory protection. Memory protection is the capability of an operating system and supporting hardware to delimit segments of memory, to control whether segments can be read from or written into, and to confine accesses of a program to its segments alone. The absence of memory protection in many operating systems today is the result of a bias toward a narrow definition of performance as maximum instruction-execution rate. A broader definition, including the time to get the job done, makes clear that cost of recovery from memory interference errors reduces expected performance. The mechanisms of memory protection are well understood, powerful, efficient, and elegant. They add to performance in the broad sense without reducing instruction execution rate.

Denning, Peter J.↗
NASA NTRS2011

Automation of PCXMC and ImPACT for NASA Astronaut Medical Imaging Dose and Risk Tracking

To automate astronaut organ and effective dose calculations from occupational X-ray and computed tomography (CT) examinations incorporating PCXMC and ImPACT tools and to estimate the associated lifetime cancer risk per the National Council on Radiation Protection & Measurements (NCRP) using MATLAB(R). Methods: NASA follows guidance from the NCRP on its operational radiation safety program for astronauts. NCRP Report 142 recommends that astronauts be informed of the cancer risks from reported exposures to ionizing radiation from medical imaging. MATLAB(R) code was written to retrieve exam parameters for medical imaging procedures from a NASA database, calculate associated dose and risk, and return results to the database, using the Microsoft .NET Framework. This code interfaces with the PCXMC executable and emulates the ImPACT Excel spreadsheet to calculate organ doses from X-rays and CTs, respectively, eliminating the need to utilize the PCXMC graphical user interface (except for a few special cases) and the ImPACT spreadsheet. Results: Using MATLAB(R) code to interface with PCXMC and replicate ImPACT dose calculation allowed for rapid evaluation of multiple medical imaging exams. The user inputs the exam parameter data into the database and runs the code. Based on the imaging modality and input parameters, the organ doses are calculated. Output files are created for record, and organ doses, effective dose, and cancer risks associated with each exam are written to the database. Annual and post-flight exposure reports, which are used by the flight surgeon to brief the astronaut, are generated from the database. Conclusions: Automating PCXMC and ImPACT for evaluation of NASA astronaut medical imaging radiation procedures allowed for a traceable and rapid method for tracking projected cancer risks associated with over 12,000 exposures. This code will be used to evaluate future medical radiation exposures, and can easily be modified to accommodate changes to the risk calculation procedure.

Bahadori, Amir↗
DOE OSTI2024

Data and Scripts associated with “Lambda-PFLOTRAN: Workflow for Incorporating Organic Matter Chemistry Informed by Ultra High Resolution Mass Spectrometry into Biogeochemical Modeling.”

This data package is associated with the publication “Lambda-PFLOTRAN: Workflow for Incorporating Organic Matter Chemistry Informed by Ultra High Resolution Mass Spectrometry into Biogeochemical Modeling” submitted to Geoscientific Model Development (Muller et al., 2024). In this manuscript, organic matter chemistry and thermodynamics are directly connected to reactive transport simulators through the newly developed Lambda-PFLOTRAN (Parallel Reactive Flow and Transport model) workflow tool that succinctly incorporates organic matter chemistry data generated from Fourier transform ion cyclotron resonance mass spectrometry (FTICR-MS) into reaction networks to simulate aerobic respiration of the organic matter and the resulting biogeochemistry. Lambda-PFLOTRAN is a python-based workflow, executed through a Jupyter Notebook interface, that digests raw FTICR-MS data, develops a representative reaction network based on substrate-explicit thermodynamic modeling (also termed lambda modeling due to its key thermodynamic parameter λ used therein), and completes a biogeochemical simulation with the open source, reactive flow, and transport code PFLOTRAN. This data package contains Jupyter Notebook based workflows for two test cases for running biogeochemical simulations of organic matter oxidation identified by FTICR-MS. It contains four primary folders (workflow, data, src, and analysis), a file-level metadata file (Muller_2024_Lambda_PFLOTRAN_Manuscript_Data_Package_flmd.csv) that lists all the files contained in this data package with a short description of each, and a data dictionary (Muller_2024_Lambda_PFLOTRAN_Manuscript_Data_Package_dd.csv) file that describes the tabular column headers. The ‘workflow’ folder contains the Jupyter Notebook based workflows for running the lambda analysis, PFLOTRAN simulation, sensitivity analysis and parameter estimation. The ‘data’ folder contains the FTICR-MS data, initial conditions, and incubation data for test cases 1 and 2 in folders titled ‘WHONDRS’ and ‘Colloids’, respectively. The data folder also has a ‘Database’ folder containing a reaction network for bulk organic matter (assumed to be CH2O) and a general database for PFLOTRAN (hanford_rxn_network). The CH2O reaction network defines bulk organic matter oxidation. Biogeochemical simulations are completed for both the lambda binned organic matter and bulk organic matter reaction networks. The ‘hanford_rxn_network’ database includes information required for PFLTORAN simulations including ion size, molar mass, and charge of the aqueous species, gases, and minerals phases. The ‘src’ folder contains python source codes for performing lambda analysis, PFLOTRAN simulation, sensitivity analysis and parameter estimation. The ‘analysis’ folder contains outputs from the test cases 1 and 2 including lambda analysis, PFLOTRAN runs and the calibration results.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS1994

NAFTA literature at the International Trade Commission library

Most of the US official materials regarding NAFTA originate in the Executive Office of the President, especially the Office of the United States Trade Representative. These materials can be purchased from the U.S.G.P.O. There were also numerous Congressional hearings; many of which are probably now out of print, government agencies and the public are welcome to make copies of the ones in the collections of the ITC libraries. One of the most important sources of materials available in electronic format is the National Trade Data Base, produced by the Department of Commerce. This is a collection of at least 120 separate files containing documents relating to trade. It includes several files specifically on NAFTA, including the text of the treaty. It is available as two CD-ROM's, issued monthly, or on Internet.

Root, Elizabeth A.↗
NASA NTRS2002

The Mars Exploration Rover/Collaborative Information Portal

Astrology has long argued that the alignment of the planets governs human affairs. Science usually scoffs at this. There is, however, an important exception: sending spacecraft for planetary exploration. In late May and early June, 2003, Mars will be in position for Earth launch. Two Mars Exploration Rovers (MER) will rocket towards the red planet. The rovers will perform a series of geological and meteorological experiments, seeking to examine geological evidence for water and conditions once favorable for life. Back on earth, a small army of surface operations staff will work to keep the rovers running, sending directions for each day's operations and receiving the files encoding the outputs of the Rover's six instruments. (Mars is twenty light minutes from Earth. The rovers must be robots.) The fundamental purpose of the project is, after all, Science. Scientists have experiments they want to run. Ideally, scientists want to be immediately notified when the data products of their experiments have been received, so that they can examine their data and (collaboratively) deduce results. Mars is an unpredictable environment. We may issue commands to the rovers but there is considerable uncertainty in how the commands will be executed and whether what the rovers sense will be worthy of further pursuit. The steps of what is, to a scientist, conceptually an individual experiment may be scattered over a large number of activities. While the scientific staff has an overall strategic idea of what it would like to accomplish, activities are planned daily. The data and surprises of the previous day need to be integrated into the negotiations for the next day's activities, all synchronized to a schedule of transmission windows . Negotiations is the operative term, as different scientists want the resources to run possibly incompatible experiments. Many meetings plan each day's activities.

Walton, Joan↗