Search NASA⌕ Search

SEARCH · Search NASA

Results for “GitHub”

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
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

NASA Class A Certification of Core Flight Software (cFS)

NASA Gateway program has named cFS as the software architecture for the vehicle. The core CFS team (GSFC+JSC) is tasked to develop a certifiable release of the cFS bundle, by components, as class A, safety-critical flight software. It is to be available to all Gateway software developers, including our element vendors and international partners. Its availability & usage will be as stated by the Gateway User Agreement license. In this presentation, we will describe our general certification process, and more importantly, our certification artifacts that can be re-run to certify cFS on different platforms. Our goal is to also make available these certifiable packages to the open source community, specifically for cFE, OSAL and certain cFS applications and libraries that are currently hosted on NASA github (https://github.com/nasa).

Tam M Ngo↗
NASA NTRS2020

Flare Statistics for Young Stars from a Convolutional Neural Network Analysis of TESS Data

All-sky photometric time-series missions have allowed for the monitoring of thousands of young (t(age) < 800 Myr) stars in order to understand the evolution of stellar activity. Here, we developed a convolutional neural network (CNN), stella, specifically trained to find flares in Transiting Exoplanet Survey Satellite (TESS) short-cadence data. We applied the network to 3200 young stars in order to evaluate flare rates as a function of age and spectral type. The CNN takes a few seconds to identify flares on a single light curve. We also measured rotation periods for 1500 of our targets and find that flares of all amplitudes are present across all spot phases, suggesting high spot coverage across the entire surface. Additionally, flare rates and amplitudes decrease for stars t(age) > 50 Myr across all temperatures T(eff) ≥ 4000 K, while stars from 2300 ≤ T(eff) < 4000 K show no evolution across 800 Myr. Stars of T(eff) ≤ 4000 K also show higher flare rates and amplitudes across all ages. We investigate the effects of high flare rates on photoevaporative atmospheric mass loss for young planets. In the presence of flares, planets lose 4%–7% more atmosphere over the first 1 Gyr. stella is an open-source Python toolkit hosted on GitHub and PyPI.

Adina D. Feinstein↗
NASA NTRSDate not supplied

GL4U: GeneLab for Colleges and Universities

GeneLab for Colleges and Universities (GL4U) will provide space biology-relevant training in bioinformatics to the next generation of scientists through direct and indirect approaches. The GeneLab (GL) team will host two annual data processing bootcamps, one for college-level students (direct) and one for college educators (indirect – Training of Trainers), in which participants learn to analyze space-relevant omics data hosted on GL. The first bootcamp took place in early June 2021 with about 30 SJSU undergraduate students and covered space biology-specific lectures and hands-on instruction using Jupyter Notebooks (JNs) for RNA sequence (RNAseq) data analysis. All training materials including the enclosed files listed below will be made publicly available on GitHub. RNAseq Bootcamp Lectures (attached in combined file): Introduction to NASA, Space Biology, GeneLab, and the Command Line: NASA_GL_CL_Intro_FINAL.pdf - DRAFT from initial submission NASA_SB_GL_CL_Intro_FULL.pdf - FINAL version presented during the bootcamp - only minor edits from the draft version RNAseq and Data Processing Overview: RNAseq_Overview_FINAL.pdf - DRAFT from initial submission RNAseq_Overview_FULL.pdf - FINAL version presented during the bootcamp - only minor edits from the draft version Overview of the Statistics Used for RNAseq Data Analysis: SJSU_Statistics_Intro_Lecture_FINAL.pdf - DRAFT from initial submission Statistics_Overview_FULL.pdf - FINAL version presented during the bootcamp - only minor edits from the draft version Completed JNs in HTML format (attached in combined file): Unix_Intro_JN_06-2021_completed.html R_Intro_JN_06-2021_completed.html RNAseq_fastq_to_counts_JN_06-2021_completed.html RNAseq_DGE_JN_06-2021_completed.html RNAseq Bootcamp Recordings (attached): GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_1_of_5.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_2_of_5.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_3_of_5.mp4 *There were issues with the part 4 recording so that is not available GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day1_Part_5_of_5.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day2_Part_1_of_3.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day2_Part_2_of_3.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day2_Part_3_of_3.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_1_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_2_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_3_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day3_Part_4_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_1_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_2_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_3_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day4_Part_4_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_1_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_2_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_3_of_4.mp4 GL4U_RNAseq_Bootcamp_June_2021_Pilot_Day5_Part_4_of_4.mp4

GeneLab↗
NASA NTRSDate not supplied

The Satellite Flythrough and Reconstruction Softwares at CCMC

The next-generation of model data visualization to be offered at the Community Coordinated Modeling Center (CCMC) will be based on Kamodo, an open source python package. To increase the usefulness of our services, we are also developing new capabilities based on this software, called the satellite flythrough and the reconstruction tools, to be offered both as packages for offline analysis and through an online interface (coming soon). The satellite flythrough software ‘flies’ a satellite trajectory, whether real or imaginary, through either model data hosted at CCMC or on a personal machine. This service greatly simplifies the complexity of users’ access to model data, abstracting away the time-consuming details of model data formats and interpolation. We demonstrate execution times of a few seconds to a few minutes for several example flythroughs of a trajectory stretching over a few days, depending on the parameters chosen. We also demonstrate a reconstruction tool built on top of the satellite flythrough software, for use with mission planning and model-data comparisons. This tool, based on reconstructions provided for the GDC Science and Technology Definition Team, converts multiple, simultaneous satellite flythroughs into two-dimensional reconstructions. The reconstruction tool provides a software capability for satellite constellations to determine how many satellites are needed and in what configuration to resolve the desired features in the model data. Both tools are currently available through GitHub for a selection of CCMC-hosted ITM models. Finally, we present initial results from work in progress and plans for future work, including an expansion of the reconstruction tool to provide 3D reconstruction capabilities and a line-of-sight calculation tool.

software, python↗
NASA NTRS2022

VIPRE: A Tool Aiding the Design for Entry Probe Missions

Exploring planetary atmospheres uncovers important information for how our solar system formed and evolved. While remote sensing is extensively used, some crucial observations require in-situ measurements by an atmospheric probe. Given their scientific importance, probe missions to Saturn, Uranus and Neptune are considered for the coming decades. In anticipation of future probe missions, the software tool VIPRE was developed as proof-of-concept to facilitate selection of probe entry locations. Currently, there is no analytical way to identify which interplanetary trajectory from thousands of feasible launch opportunities is optimal for a considered mission concept. The search and decision process for that solution is complex and relies on the intuition of mission designers, who focus on a subset of trajectories to make the trade space manageable. The idea of VIPRE is to (1) generate a multi-dimensional data cube showing relevant engineering and science parameters simultaneously for thousands of trajectories, and (2) visualize the data for all entry sites over the body's envelope. VIPRE lays the foundation to make the data available for browsing in a 3-D visualization to identify the best family of solutions for a given mission. The paper introduces the validated and verified core algorithms of VIPRE, published on GitHub. VIPRE serves as a basic framework to be used and extended for different purposes. The paper presents the motivation for the development and algorithms. It explains the computation and data visualization strategy, and gives a list of suggested functionalities to extend and further develop VIPRE to fully leverage its potential.

Ice Giants↗
NASA NTRSDate not supplied

Science Workflows using Kamodo

Kamodo is a powerful python software package based on data functionalization. Once a given data set is functionalized, a large variety of capabilities are easily accessible in Kamodo, including unit conversions, custom analysis via function composition, interactive publication quality visualizations, and LaTeX encoding. The entirety of capabilities available in Kamodo are easily applied to both simulated and observed data across the multiple domains of Heliophysics and even in other disciplines. This work includes a variety of science workflows using Kamodo in combination with other resources, including with other python software packages, that expand the utility of Kamodo even further. These workflows include model-data comparisons, ensemble modeling examples, satellite mission planning examples, and other applications, all of which are freely available on CCMC’s Kamodo Github page for the community to adapt to their own uses (https://github.com/nasa/Kamodo). We invite the community to use these workflows and to contribute their own to share.

software↗
NASA NTRS2022

Kamodo’s Model-Agnostic Satellite Flythrough: Lowering the Utilization Barrier for Heliophysics Model Outputs

Heliophysics model outputs are increasingly accessible, but typically are not usable by the majority of the community unless directly collaborating with the relevant model developers. Prohibitive factors include complex file output formats, cryptic metadata, unspecified and often customized coordinate systems, and non-linear coordinate grids. Some pockets of progress exist, giving interfaces to various simulation outputs, but only for a small set of outputs and typically not with open-source, freely available packages. Additionally, the increasing array of tools built upon these sporadic interfaces are typically model-specific. We present Kamodo’s model-agnostic satellite flythrough capabilities as the solution to the utilization barrier for heliophysics model outputs. Developed at the Community Coordinated Modeling Center, these flythrough capabilities are built in Python upon a network of model-agnostic interfaces developed in collaboration with model developers, providing interpolation results the community can trust. Kamodo’s flythrough capabilities present the user with a growing variety of flythrough tools based upon a rapidly expanding library of heliophysics model outputs in several domains, currently including a variety of Ionosphere-Thermosphere-Mesosphere and global magnetosphere model outputs. Each capability is designed to be easily accessible via simplistic model-agnostic syntax, with the entire package freely available in the cloud on Github. Here, we describe the tools developed, include several sample applications for common science questions, demonstrate interoperability with selected packages, and summarize ongoing developments.

Software↗
NASA NTRSDate not supplied

Science Workflows using Kamodo

Kamodo is a powerful python software package based on data functionalization. Once a given data set is functionalized, a large variety of capabilities are easily accessible in Kamodo, including unit conversions, custom analysis via function composition, interactive publication quality visualizations, and LaTeX encoding. The entirety of capabilities available in Kamodo are easily applied to both simulated and observed data across the multiple domains of Heliophysics and even in other disciplines. This work includes a variety of science workflows using Kamodo in combination with other resources, including with other python software packages, that expand the utility of Kamodo even further. These workflows include model-data comparisons, ensemble modeling examples, satellite mission planning examples, and other applications, all of which are freely available on CCMC’s Kamodo Github page for the community to adapt to their own uses (https://github.com/nasa/Kamodo). We invite the community to use these workflows and to contribute their own to share.

python↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗
NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗
NASA NTRS2023

The Community Radiative Transfer Model (CRTM): Community-Focused Collaborative Model Development Accelerating Research to Operations

The Joint Center for Satellite Data Assimilation (JCSDA) Community Radiative Transfer Model (CRTM) is a fast, 1-D radiative transfer model used in numerical weather prediction, calibration/validation, etc. across multiple federal agencies and universities. The key benefit of the CRTM is that it is a satellite simulator. It provides a highly accurate representation of satellite radiances by using the specific sensor response functions convolved with a line-by-line radiative transfer model (LBLRTM). CRTM covers the spectral ranges consistent with all present operational and most research satellites, from visible to microwave. The capability to simulate ultraviolet radiances and support space-based radar sensors is being added over the next two years in CRTM Version 3.0. In addition to simulated radiances, the CRTM also provides Jacobian outputs needed to interpret satellite observations for numerical weather prediction. The Jacobian estimates how changes in geophysical parameters affect simulated measurements from satellite sensors. Using the Jacobian in modeling and weather prediction improves the accuracy and efficiency of data analysis, leading to better weather predictions. The CRTM model's success and growth depend on community contributions and evaluation. To facilitate this, we have made the CRTM highly accessible through modular programming, clear documentation and tutorials, public domain licensing, unfettered public access via Github, and a clear path to operational implementation for innovative research. We encourage and welcome contributions from the community to help us continue to improve the CRTM.

Benjamin T Johnson↗