Search NASA⌕ Search

SEARCH · Search NASA

Results for “libraries”

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 631 records · Page 35
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Develop a Model Component

During my internship at NASA, I was a model developer for Ground Support Equipment (GSE). The purpose of a model developer is to develop and unit test model component libraries (fluid, electrical, gas, etc.). The models are designed to simulate software for GSE (Ground Special Power, Crew Access Arm, Cryo, Fire and Leak Detection System, Environmental Control System (ECS), etc. ~.) before they are implemented into hardware. These models support verifying local control and remote software for End-Item Software Under Test (SUT). The model simulates the physical behavior (function, state, limits and 110) of each end-item and it's dependencies as defined in the Subsystem Interface Table, Software Requirements & Design Specification (SRDS), Ground Integrated Schematic (GIS), and System Mechanical Schematic.(SMS). The software of each specific model component is simulated through MATLAB's Simulink program. The intensiv~ model development life cycle is a.s follows: Identify source documents; identify model scope; update schedule; preliminary design review; develop model requirements; update model.. scope; update schedule; detailed design review; create/modify library component; implement library components reference; implement subsystem components; develop a test script; run the test script; develop users guide; send model out for peer review; the model is sent out for verific~tionlvalidation; if there is empirical data, a validation data package is generated; if there is not empirical data, a verification package is generated; the test results are then reviewed; and finally, the user. requests accreditation, and a statement of accreditation is prepared. Once each component model is reviewed and approved, they are intertwined together into one integrated model. This integrated model is then tested itself, through a test script and autotest, so that it can be concluded that all models work conjointly, for a single purpose. The component I was assigned, specifically, was a fluid component, a discrete pressure switch. The switch takes a fluid pressure input, and if the pressure is greater than a designated cutoff pressure, the switch would stop fluid flow.

Ensey, Tyler S.↗
NASA NTRS2014

Robot Task Commander with Extensible Programming Environment

A system for developing distributed robot application-level software includes a robot having an associated control module which controls motion of the robot in response to a commanded task, and a robot task commander (RTC) in networked communication with the control module over a network transport layer (NTL). The RTC includes a script engine(s) and a GUI, with a processor and a centralized library of library blocks constructed from an interpretive computer programming code and having input and output connections. The GUI provides access to a Visual Programming Language (VPL) environment and a text editor. In executing a method, the VPL is opened, a task for the robot is built from the code library blocks, and data is assigned to input and output connections identifying input and output data for each block. A task sequence(s) is sent to the control module(s) over the NTL to command execution of the task.

Hart, Stephen W↗
NASA NTRS2015

Environment Modeling Using Runtime Values for JPF-Android

Software applications are developed to be executed in a specific environment. This environment includes external native libraries to add functionality to the application and drivers to fire the application execution. For testing and verification, the environment of an application is simplified abstracted using models or stubs. Empty stubs, returning default values, are simple to generate automatically, but they do not perform well when the application expects specific return values. Symbolic execution is used to find input parameters for drivers and return values for library stubs, but it struggles to detect the values of complex objects. In this work-in-progress paper, we explore an approach to generate drivers and stubs based on values collected during runtime instead of using default values. Entry-points and methods that need to be modeled are instrumented to log their parameters and return values. The instrumented applications are then executed using a driver and instrumented libraries. The values collected during runtime are used to generate driver and stub values on- the-fly that improve coverage during verification by enabling the execution of code that previously crashed or was missed. We are implementing this approach to improve the environment model of JPF-Android, our model checking and analysis tool for Android applications.

Verification↗
NASA NTRS2007

Implementing DSpace at NASA Langley Research Center

This presentation looks at the implementation of the DSpace institutional repository system at the NASA Langley Technical Library. NASA Langley Technical Library implemented DSpace software as a replacement for the Langley Technical Report Server (LTRS). DSpace was also used to develop the Langley Technical Library Digital Repository (LTLDR). LTLDR contains archival copies of core technical reports in the aeronautics area dating back to the NACA era and other specialized collections relevant to the NASA Langley community. Extensive metadata crosswalks were created to facilitate moving data from various systems and formats to DSpace. The Dublin Core metadata screens were also customized. The OpenURL standard and Ex Libris Metalib are being used in this environment to assist our customers with either discovering full-text content or with initiating a request for the item.

Lowe, Greta↗
NASA NTRS1959

Space Probes Program Status Report

Brief of Progress: A. Preparations for the 26 November launching of ABLE-4 ATLAS are proceeding as scheduled, with no problems apparent at this time. Many of the electrical tests and subsystems checks have been completed. Minor modifications have been made to the solar paddle tie-down and release mechanism, after an extensive testing program; B. Work toward the 10 December launching of ABLE-4 THOR is also progressing on schedule. Subsystem checks have been started, and mechanical fit checks have been completed; C. During the month of October, a total of 136 tests were performed on components and assemblies related to the ABLE program. These included acceptance tests, type tests, R&D tests, etc. Of this total, only three failures occurred, all of which have been corrected; D. The Space Physics Data Library, Los Angeles, California, is now in operation. Data reduction gear in the Library is in breadboard operation with completion of the installation expected by mid-November. Analysis of ABLE-3 data is progressing satisfactorily at the Library.

Source record↗
NASA NTRS2017

Methods for Identifying Ligands that Target Nucleic Acid Molecules and Nucleic Acid Structural Motifs

Disclosed are methods for identifying a nucleic acid (e.g., RNA, DNA, etc.) motif which interacts with a ligand. The method includes providing a plurality of ligands immobilized on a support, wherein each particular ligand is immobilized at a discrete location on the support; contacting the plurality of immobilized ligands with a nucleic acid motif library under conditions effective for one or more members of the nucleic acid motif library to bind with the immobilized ligands; and identifying members of the nucleic acid motif library that are bound to a particular immobilized ligand. Also disclosed are methods for selecting, from a plurality of candidate ligands, one or more ligands that have increased likelihood of binding to a nucleic acid molecule comprising a particular nucleic acid motif, as well as methods for identifying a nucleic acid which interacts with a ligand.

Disney, Matthew D.↗
NASA NTRS2018

Monitoring Astronaut Health with DNA Sequencing

In recent years microbe a plethora of microbe populations have been identified onboard the ISS (International Space Station). Approaches for real-time tracking of microbes for routine housekeeping and food/water safety monitoring will be critical for mission safety and crew health on future longer duration missions to the Moon or Mars. This work is a proof-of-concept study demonstrating an end-to-end phylogenetic identification and full genome sequencing effort of multiple microbial populations. Our methodology utilized the ISS flight-certified WetLab-2 molecular toolbox and the Biomolecule Sequencer projects for real-time end-to-end on-orbit microbial biological samples processing and molecular analysis with real time results generated utilizing only field "offline" analytic software. For this experiment we colony-cultured several ISS isolated microorganisms before generation of the pre-sequencing library via the automated VolTRAX device which enabled high library turnover with little wet-bench activity or potential future costly astronaut time. The pre-sequencing library is diluted in loading buffer and injected into the MinION sample port, drawn into the nanopore window by capillary action, and sequenced using the MinKnown. 16S and full genome alignment, nucleotide matching, gene identification, and phylogenetic sorting was accomplished utilizing the Epi2me software and the offline NCBI Blast viral, microbiome, and human somatic databases. In short, the methodologies developed herein replace the myriad of specific, often highly targeted microbiological tests used in the clinical laboratory, which would be difficult if not impossible to currently implement aboard the ISS or in deep space, with a single metagenomics test.

genomics↗
NASA NTRS2018

Methodology and Application of HPC I/O Characterization with MPIProf and IOT

Combining the strengths of MPIProf and IOT, an efficient and systematic method is devised for I/O characterization at the per-job, per-rank, per-file and per-call levels of HPC programs running on the NASA Advanced Supercomputing Center. This method is applied to answer four I/O questions in this paper. A total of 13 MPI programs and 15 cases, ranging from 24 to 5968 ranks, are analyzed to establish the I/O landscape from answers to the four questions. Four of the 13 programs use MPI I/O and the behavior of their collective writes depends on the specific implementation of the MPI library used. The SGI MPT library, the prevailing MPI library for our systems, was found to gather small writes from a large number of ranks to perform larger writes by a small subset of collective buffering ranks. The number of collective buffering ranks invoked by MPT depends on the Lustre stripe count and the number of nodes used for the run. A demonstration of varying the stripe count to achieve double-digit speedup of one program's I/O was presented. Another program, which concurrently opens private files by all ranks and could potentially create a heavy load on the Lustre servers, was identified. The ability to systematically characterize I/O for a large number of programs running on a supercomputer, seek I/O optimization opportunity and identify programs that could cause a high load and instability on the filesystems is important for pursuing exascale in a real production environment.

Characterization↗
NASA NTRS2016

MONTE Python for Deep Space Navigation

The Mission Analysis, Operations, and Navigation Toolkit Environment (MONTE) is the Jet Propulsion Laboratory’s (JPL) signature astrodynamic computing platform. It was built to support JPL’s deep space exploration program, and has been used to fly robotic spacecraft to Mars, Jupiter, Saturn, Ceres, and many solar system small bodies. At its core, MONTE consists of low-level astrodynamic libraries that are written in C++ and presented to the end user as an importable Python language module. These libraries form the basis on which Python-language applications are built for specific astrodynamic applications, such as trajectory design and optimization, orbit determination, flight path control, and more. The first half of this paper gives context to the MONTE project by outlining its history, the field of deep space navigation and where MONTE fits into the current Python landscape. The second half gives an overview of the main MONTE libraries and provides a narrative example of how it can be used for astrodynamic analysis.

aerospace↗
NASA NTRSDate not supplied

Splashdown Visualization of Spent Stages

The state of the art for many Earth-to-orbit trajectory analysis toolsets used at NASA is somewhat dated in terms of the languages they are written in and their user interfaces. Many of these programs are written in languages like Fortran or C that are no longer considered modern in the technology industry, and are command-line based without any means of interpreting the data outputs. This presentation is meant to demonstrate a specific use case for a newly developed web app that visualizes the output data for one of these tools. Specifically, one key usage is to investigate and validate launches for notional multi-stage vehicle concepts to various non-standard high-inclination orbits. Some NASA requirements dictate that trajectories be designed such that no surviving debris lands closer than 200 nautical miles (nm) from foreign landmasses or 27 nm from the continental United States, therefore validating re-entry locations of spent stages is an integral part of the launch planning process. In addition, at programmatic levels it can prove insightful and clarifying for the decision-making process to enhance the technical results of numerical simulations with visualizations. The intent with this tool is to provide the mission analyst and program level management with an intuitive and clear grasp of key information on possible mission scenarios either departing from or arriving at Earth, and in the future, the moon or Mars as well. The software tool was developed with an agile development approach and utilizes the latest frameworks and technologies. The front end uses the React JavaScript library for making a state of the art frontend and a backend based on the Django Python framework for handling data using Python’s powerful and free scientific libraries. In addition, the CesiumJS open-source library is key for visualizing these end-to-end trajectories on a high-resolution Earth model. The presentation will demonstrate the current capability and tested use cases.

Jack Agolli↗
NASA NTRS2017

MONTE for Orbit Determination

Monte is the Jet Propulsion Laboratory’s (JPL) signature astrodynamic computing platform. Its main interface is a collection of Python-language libraries that can be used either for one-o analyses or to build high-quality software applications. Perhaps nowhere is Monte’s versatility and excellence better demonstrated than in its use for operational orbit determination (OD). Over the period from 2007 to 2016, Monte was the prime OD solution for fourteen JPL flight projects, and secondary for seven non-JPL projects. These missions span the range of Solar System destinations and operational protocols, yet each were successfully serviced by Monte’s flexible OD library. This paper reviews the missions on which Monte has been used for OD, with an eye toward pointing out the di erent ways it has been deployed to solve unique problems. It also gives an outline of the main elements of the orbit determination library and how they work together to navigate flight missions.

Martin-Mur, Tomas↗
NASA NTRSDate not supplied

Improvements to a Batch Pentadiagonal Solver on NVIDIA GPUs

This poster presents the recent work in OVERFLOW to port the batched pentadiagonal solver to NVIDIA GPUs. There are five pentadiagonal systems for each pencil in the grid but three of these systems share the same LHS. Our first simple approach for porting the pentadiagonal solver to the GPUs was to take advantage of the shared LHS by assigning three threads to the three LHS of each pencil. We demonstrated that this custom solver was 92% faster than the NVIDIA batched pentadiagonal library implementation on a V100 GPU due to the lower memory bandwidth requirements. The second approach treated each pentadiagonal system as a 2x2 block tridiagonal system and used a variant of the parallel cyclic reduction algorithm to solve the problem. One benefit of this approach is that it does not require interleaving the data between each system. We demonstrated that this algorithm is 2.18x faster than the NVIDIA library implementation for the same amount of work. If we take advantage of our shared LHS, this approach is 2.58x faster than the library implementation on a V100 GPU.

GPU Programming↗
NASA NTRSDate not supplied

Ground control points refresh for MODIS and VIIRS geolocation monitoring

The Control Point Matching (CPM) program and a set of over 1200 globally distributed ground control points (GCPs ) have been successfully used to develop more than 20 years of MODIS geolocation products. In this research, we refresh current GCP library with more than 2500 new GCPs using the latest Landsat 8 Collection 2 images. The refreshed GCPs are distributed from 56 S to 80 N latitude, with more than 2000 shoreline and 500 inland GCP chips. The size of these GCPs are extended from800*800 to 1400*1400 Landsat pixels and the CPM program correspondingly increase s t h e searching distance from 0.8 pixels to 2.5 pixels, which also extends the geolocation error measurement from +/-45 to the edge of scan at +/-55 degree in scan angle. This will allow the algorithm to catch geolocation errors that are larger than one MODIS pixel. The geolocation errors measured with the refreshed GCP library are comparable to the previous results, yet with 2-3more times of matched GCPs. The daytime Aqua ascending orbits and Terra descending orbits enable us to identify a few GCP outliers which might be due to the quality of the original Landsat images. Most importantly, the refreshed GCP library will include images from both Landsat band 4 to match with VIIRS I1, and Landsat band 6 to match with VIIRS I3. This will allow us to measure and correct on orbit band-to-band registration at both track and scan directions, which will help understanding and improving future JPSS mission’s prelaunch geometric performance.

VIIRS↗
NASA NTRSDate not supplied

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗
NASA NTRSDate not supplied

Comparing the Electrical Modeling and Thermal Analysis Toolbox Simulation Data to Electrified Aircraft Propulsion Test Hardware Data

A model using the Electrical Modeling and Thermal Analysis Toolbox (EMTAT), a National Aeronautics and Space Administration (NASA)-developed Simulink® model block library of electrical components, was developed to mirror the Hybrid Propulsion Emulation Rig (HyPER) hardware, a laboratory focused on Electrified Aircraft Propulsion (EAP) hardware tests. The goal of the model was to demonstrate the utility of the library by comparing the accuracy of the library models to the performance of real hardware, with the primary metrics being the simulation outputs matching physical test hardware data within 5% of full scale.The objective of this paper is to present the background, setup, testing and results of this comparison. It describes some of the adjustments that were necessary to match the system hardware, as well as next steps in verification and validation. The outputs of the model were compared to the results of several tests in HyPER, and in the process captured an additional torque loss that is still being analyzed for the root cause but has been confirmed in the hardware. Across all the test series, only one key model parameter was outside the target 5% full scale matching, and nearly 70% were within 1%.

Mark E Bell↗
NASA NTRS2022

A Modular Framework for Integrating and Visualizing Telemetry for Mars 2020 Rover Mechanism Operations

The analysis of mechanism telemetry requires a wide variety of tools to quickly and effectively assess spacecraft state, capture long-term trends in system performance, and identify and track anomalous events. Such analysis often requires spacecraft telemetry to first be transformed into derived fields and aggregated statistics before operators can begin their analysis. In past missions, aspects of this process have been automated, but operators were expected to use their own tools and procedures to understand and visualize the data, which led to redundant and inconsistent tools and processes. The Mech Data Tools Python library (MDT) was developed to provide a flexible, unified tool set for operators to extract and analyze mechanism telemetry over the life of the Mars 2020 surface mission. MDT consists of a set of configurable components that implement standard interfaces for ingesting input and producing output. Components can be chained together to form a data processing pipeline. Data are ingested from several sources within the greater Mars 2020 cloud infrastructure and stored in pandas DataFrames, which allows users to leverage the data manipulation capabilities present within the widely-used pandas library. Visualization capabilities are provided through the Plotly library, which generates interactive plots for users to interpret. Following the beginning of Mars 2020 surface operations, usage of MDT has spread to all mechanism-focused subsystems and has demonstrated great utility in analyzing early surface activities. This paper describes MDT’s evolution from heritage mechanism telemetry tools, the critical architecture decisions and challenges faced over MDT’s two years of development, and current applications of MDT in support of mechanism operations.

Wolsieffer, Ben↗
NASA NTRSDate not supplied

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of trained machine-learning models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a Windows app that has been created to deploy trained machine-learning models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of machine-learning application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). Current version of the app focuses on the performance prediction of conventional turbofans. The app gets user input for a turbofan design, preprocesses the input data, and deploys trained machine-learning models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The machine-learning predictive models were built by employing supervised deep-learning algorithm to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these machine-learning models using the app shows that Aero-Engines AI is an easy-to-use and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage.

machine learning↗
NASA NTRS2023

Comparing the Electrical Modeling and Thermal Analysis Toolbox Simulation Data to Electrified Aircraft Propulsion Test Hardware Data

A model using the Electrical Modeling and Thermal Analysis Toolbox (EMTAT), a National Aeronautics and Space Administration (NASA)-developed Simulink® model block library of electrical components, was developed to mirror the Hybrid Propulsion Emulation Rig (HyPER) hardware, a laboratory focused on Electrified Aircraft Propulsion (EAP) hardware tests. The goal of the model was to demonstrate the utility of the library by comparing the accuracy of the library models to the performance of real hardware, with the primary metrics being the simulation outputs matching physical test hardware data within 5 percent of full scale. The objective of this paper is to present the background, setup, testing and results of this comparison. It describes some of the adjustments that were necessary to match the system hardware, as well as next steps in verification and validation. The outputs of the model were compared to the results of several tests in HyPER, and in the process captured an additional torque loss that is still being analyzed for the root cause but has been confirmed in the hardware. Across all the test series, only one key model parameter was outside the target 5 percent full scale matching, and nearly 70 percent were within 1 percent.

Mark E. Bell↗