Search NASA⌕ Search

SEARCH · Search NASA

Results for “version control”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

An Integrated Software Architecture for Solar Cruiser Mission Design and Navigation

Solar Cruiser is a solar sailing mission, riding as a secondary payload to the Interstellar Mapping and Acceleration Probe (IMAP) mission, expected to launch in February of 2025. The Solar Cruiser vehicle will generate thrust via a complex, low-thrust solar sail. The extreme low-thrust nature of the solar sail will leave Solar Cruiser highly sensitive to external environmental effects (such as solar radiation pressure and high-order gravitational perturbations) throughout the entirety of flight. Because of this, preliminary & operational optimization routines must be intricately tied to high-order predictive propagation models to ensure the greatest possible confidence in mission success. The Solar Cruiser Mission Design and Navigation (MDNav) team has designed a software tool suite, employing the latest in software containerization technology, to accomplish this task, allowing for seamless development across several users and operating systems. Combining JPL’s Monte toolkit with high-performance optimizers written by researchers at the University of Alabama, the proposed architecture allows for instant verification of optimized trajectories within the same development environment that the optimization takes place, removing the need for mission designers and navigators to switch between tools. The MDNav software suite itself is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile – thus avoiding unnecessary file bloating. This paper discusses the historical differences between previous iterations of the Solar Cruiser MDNav tool suite and the current iteration, planned operational interfaces of the tool with other software and subsystems, and the planned path forward in maintaining containerization services for the software throughout the lifetime of Solar Cruiser.

Containerization↗
NASA NTRSDate not supplied

An Integrated Software Architecture for Solar Cruiser Mission Design and Navigation

Solar Cruiser is a solar sailing mission, riding as a secondary payload to the Interstellar Mapping and Acceleration Probe (IMAP) mission, expected to launch in February of 2025. The Solar Cruiser vehicle will generate thrust via a complex, low-thrust solar sail. The extreme low-thrust nature of the solar sail will leave Solar Cruiser highly sensitive to external environmental effects (such as solar radiation pressure and high-order gravitational perturbations) throughout the entirety of flight. Because of this, preliminary & operational optimization routines must be intricately tied to high-order predictive propagation models to ensure the greatest possible confidence in mission success. The Solar Cruiser Mission Design and Navigation (MDNav) team has designed a software tool suite, employing the latest in software containerization technology, to accomplish this task, allowing for seamless development across several users and operating systems. Combining JPL’s Monte toolkit with University of Alabama’s high-performance optimizer, ASSET, the proposed architecture allows for instant verification of optimized trajectories within the same development environment that the optimization takes place, removing the need for mission designers and navigators to switch between tools. The MDNav software suite itself is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile – thus avoiding unnecessary file bloating. This paper discusses the historical differences between previous iterations of the Solar Cruiser MDNav tool suite and the current iteration, planned operational interfaces of the tool with other software and subsystems, and the planned path forward in maintaining containerization services for the software throughout the lifetime of Solar Cruiser.

solar cruiser↗
NASA NTRSDate not supplied

Building access and community standards for opacity data at the onset of next-generation atmosphere observations

The characterization of a diverse set of exoplanet atmosphere observations, ranging from hot gas giants to small temperate rocky worlds, will be one of the legacies of upcoming facilities such as the James Webb Space Telescope (JWST). Our understanding and interpretation of such observations will hinge on our ability to link observations with atmospheric theoretical studies that critically rely on fundamental molecular and atomic opacities. Computing such opacities is a highly non-trivial and inaccessible process which requires several terabytes of available disk space, hours of CPU time per pressure-temperature combination, and requires users to carefully aggregate line lists data from various sources, which limits access and intercomparison of opacity data in the exoplanet community. Here we present MAESTRO (Molecules and Atoms in Exoplanet Science: Tools and Resources for Opacities) an opacity database that can be accessed by the community via a web interface and python API. MAESTRO was built with community input to create a version-controlled opacity database that is easily queryable, includes informative metadata to ensure reproducibility, and exports relevant citations for inclusion in publications. Scheduled for community release in 2022, MAESTRO will prove to be an invaluable community resource in the era of JWST and beyond.

Natasha Batalha↗
NASA NTRSDate not supplied

Developing a Vision for Maturing the Heliophysics Infrastructure towards Open Science: The DIARieS Analysis Ecosystem

In the dawn of open science and the upcoming requirements, we speak about the existing state of Heliophysics infrastructure and detail the evolution required to address capability or interconnection shortcomings. Such a daunting barrier calls for an analysis ecosystem with multi-faceted capability. We propose such an ecosystem, called DIARieS, to be built upon five conceptual pillars: Discovery, Implementation, Analysis, Reproducibility, and Sharing of results. The combination of these concepts in a single platform will enable users to more intuitively combine recent advances in technology to create ‘DIARieS’ of their workflows, which can be easily made open to others in the community. The DIARieS ecosystem will also increase our efficiency by streamlining our various workflow processes, including automatic incorporation of the impending requirements of open science. The various components of the ecosystem will simplify software installation and data implementation, including automatically generated citation lists based on the components included. Automatic containerization and version control of the ecosystem will make the custom workflows easily reproducible. Employing widget technology will ease the difficulty of producing publication and commercial quality visualizations and applying common analyses techniques. Incorporating multiple technologies will streamline the various sharing methods common in our work environments today. Overall, the totality of capabilities to be offered by this analysis ecosystem will drastically simplify the application of open science principles to our work in addition to improving our efficiency and ease of collaboration. This talk summarizes a vision of the proposed ecosystem, which is described in more detail in Ringuette et al. (2022: https://doi.org/10.1016/j.asr.2022.05.012).

infrastructure↗
NASA NTRSDate not supplied

Joint ESA-NASA Multi-Mission Algorithm and Analysis Platform (MAAP)

The scientific community is faced with a need for greatly improved data sharing, analysis, visualization and advanced collaboration based firmly on open science principles. Recent and upcoming launches of new satellite missions with more complex and voluminous data, as well as the ever more urgent need to better understand the global carbon budget and related ecological processes, provided the immediate rational for the ESA-NASA Multi-mission Algorithm and Analysis Platform (MAAP). This highly collaborative joint project of ESA and NASA established a framework between ESA and NASA to share data, science algorithms and compute resources in order to foster and accelerate scientific research conducted by ESA and NASA EO data users. Presented to the public in October 2021, the current version of MAAP provides a common cloud-based platform with computing capabilities co-located with the data, a collaborative coding and analysis environment, and a set of interoperable tools and algorithms developed to support the estimation and visualization of global above-ground biomass. Data from the Global Ecosystem Dynamics Investigation (GEDI) mission on the International Space Station and the Ice, Cloud, and Land Elevation Satellite-2 (ICESat-2) have been instrumental in the first products of MAAP including the first comprehensive map of Boreal above-ground Biomass and a current Global Biomass Harmonization Activity, but the platform is also being specifically designed to support the forthcoming ESA Biomass mission and incorporate data from the upcoming NASA-ISRO SAR (NISAR) mission. While these missions and the corresponding research which includes airborne, field, and calibration/validation data collection and analyses, provide a wealth of data and information relating to global biomass estimation, they also present data storing, processing and sharing challenges. The NISAR mission alone will produce about 80TB/day. These large data volumes present a challenge that would otherwise place accessibility limits on the scientific community and impact scientific progress. Other challenges being addressed by MAAP include: 1) Enabling researchers to easily discover, process, visualize and analyze large volumes of data from both agencies; 2) Providing a wide variety of data in the same coordinate reference frame to enable comparison, analysis, data evaluation, and data generation; 3) Providing a version-controlled science algorithm development environment that supports tools, co-located data and processing resources; and 4) Addressing intellectual property and sharing challenges related to collaborative algorithm development and sharing of data and algorithms. MAAP products can be explored on the MAAP Dashboard at https://earthdata.nasa.gov/maap-biomass or the joint platform entrance at scimaap.net. MAAP also can be accessed through individual NASA (https://maap-project.org) and ESA (https://esa-maap.org/) landing pages.

cloud computing↗
NASA NTRSDate not supplied

Developing a Vision for Maturing the Heliophysics Infrastructure towards Open Science

In the dawn of open science and the upcoming requirements, we speak about the existing state of Heliophysics infrastructure and detail the evolution required to address capability or interconnection shortcomings. Such a daunting barrier calls for an analysis ecosystem with multi-faceted capability. We propose such an ecosystem, called DIARieS, to be built upon five conceptual pillars: Discovery, Implementation, Analysis, Reproducibility, and Sharing of results. The combination of these concepts in a single platform will enable users to more intuitively combine recent advances in technology to create ‘DIARieS’ of their workflows, which can be easily made open to others in the community. The DIARieS ecosystem will also increase our efficiency by streamlining our various workflow processes, including automatic incorporation of the impending requirements of open science. The various components of the ecosystem will simplify software installation and data implementation, including automatically generated citation lists based on the components included. Automatic containerization and version control of the ecosystem will make the custom workflows easily reproducible. Employing widget technology will ease the difficulty of producing publication and commercial quality visualizations and applying common analyses techniques. Incorporating multiple technologies will streamline the various sharing methods common in our work environments today. Overall, the totality of capabilities to be offered by this analysis ecosystem will drastically simplify the application of open science principles to our work in addition to improving our efficiency and ease of collaboration.

Infrastructure↗
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

Towards Streamlining Auditing for Compliance With Requirements in Open-Source Software at NASA

Context: NASA requires all software to meet several requirements (NPR 7150.2) depending on software criticality. The instantiation of these requirements may vary per project; however, once decided upon, projects must undergo audits to evaluate compliance with these requirements. Aim: We propose that audit effort can be reduced when requirements are realized by leveraging commonly used open-source infrastructure for version control, issue tracking and continuous integration, and the generated records are analyzed using a repository mining software tool to quantify process compliance. Method: We perform a case study in the NASA-funded Copilot project, utilizing Kaiaulu, a repository mining software tool. We define four software compliance metrics based on the Copilot’s requirements, and analyze their impact on source code quality. Results: Our work demonstrates how it is possible to leverage existing open source tools and platforms to facilitate software certification and qualification, and to streamline the auditing process required even when stringent requirements must be enforced. Conclusion: Together, both project and tool can be utilized to visualize project compliance, and metrics can be defined to more easily identify process irregularities to minimize auditing efforts. Project Repository: github.com/Copilot-Language/copilot Tool Repository: github.com/sailuh/kaiaulu

code-quality↗
NASA NTRSDate not supplied

Open-Source Data Engineering at NASA: CCMC's Approach to Managing Petabyte-Scale Heliophysics Data

The Community Coordinated Modeling Center (CCMC) at NASA Goddard Space Flight Center (GSFC) leads heliophysics research by providing open access to numerous models and their outputs. Our resources are available on-demand and continuously updated with real-time data, covering sun-earth interactions across multiple domains. These domains include coronal, heliosphere, inner and global magnetosphere, ionosphere, thermosphere, and lower atmosphere interactions. Operating in a hybrid environment, CCMC utilizes both self-owned hardware and Amazon Web Services (AWS) cloud infrastructure. Managing petabytes of data across multiple locations necessitates robust data engineering solutions. To address this challenge, CCMC has adopted industry-standard and open-source tools. We use Apache Airflow as our primary data engineering platform, Python for scripting and data processing, and GitLab for version control and CI/CD. Additionally, we employ Kubernetes for containerized services, Grafana and Prometheus for metrics and monitoring, and Terraform and Puppet for reproducible infrastructure as code. This presentation will discuss lessons learned from our data engineering experiences, platforms evaluated but found unsuitable for our scientific data requirements, and specific techniques developed to enhance data transfer speed and reliability. By using these technologies effectively, CCMC continues to advance heliophysics research through efficient data management and open-access modeling.

space weather↗
DOE OSTI2014

Git Replacement for the

GRAPE is a tool for managing software project workflows for the Git version control system. It provides a suite of tools to simplify and configure branch based development, integration with a project's testing suite, and integration with the Atlassian Stash repository hosting tool.

Robinson, P.↗
DOE OSTI2019

Conditions Databases at FNAL

Conditions databases is an important class of database applications where the database is used to record the state of a set of quantities as a function of observation time. Conditions databases are used in Hight Energy Physics to record the state of the detector apparatus during data taking, and then to use the data during the event reconstruction and analysis phases. At FNAL, we have a set of 3 different conditions database products, Minerva Conditions DB, ConDB and UConDB, which cover the whole range of the use cases presented by the FNAL experiments. These products have common features such as conditions data representation model, data version control, ability to restore the database to a previous state, scalable web service data access interface. In the paper, we will present the common features of the products, common solutions used to build them and also the differences between the products and their target use cases.

Mandrichenko, Igor V.↗
DOE OSTI2015

The application of ICASPA to critical and safe mass calculations - 14586

ICASPA, an Improved Critical and Safe Parameters Algorithm, calculates the size of a fissile body for a given value of k-effective. ICASPA uses an iterative predictor/corrector algorithm in which the MONK9A code is used to derive a precise k-effective value for a given candidate body size; auxiliary equations are then used to adjust the body size. The process is repeated until MONK9A outputs the chosen target value of k-effective. EDF Energy operates eight nuclear power stations comprising one Pressurized Water Reactor (PWR) and seven Advanced Gas-cooled Reactor (AGR) stations. At these sites, the term 'fuel route' is used to encompass all of the ex-reactor arrangements for the handling and storage of fuel. The criticality safety cases for these fuel routes are based on the use of geometrically safe arrangements for the required quantities of fuel. The allowed quantities and arrangements of fuel are safely sub-critical, even under the contingency of accidental moderator ingress. The fuel route safety cases consider all credible potential fault conditions, including events such as dropped fuel. Any such events might change the geometry of the fuel elements, but it is difficult to calculate exact k-effective values for realistic models of dropped fuel. This difficulty is overcome by the use of an alternative approach in which limiting safe masses are calculated for bounding (worst-case) rearrangements of fuel rods and moderators, using geometries similar to those covered by criticality handbook data. Where required, the resulting safe masses are used to set safety case limits and conditions. For example, some fire extinguishants, such as water and ABC dry powder, are also effective moderators. Hence, in some fuel route areas, administrative criticality controls are used to either prohibit or limit the permitted quantities of these materials. This paper describes the work that has been carried out to adopt ICASPA as the approved calculation method for these safe mass calculations. The work has been carried out within the company quality assurance requirements for nuclear safety related software. It has involved the development of a configuration controlled version of ICASPA and the local verification and validation of the resulting code. The benefits from the adoption of ICASPA are also presented. These include accuracy improvements and, because the method uses the MONK9A code for k-effective calculations, the ability to use more sophisticated models for limiting case geometries. (authors)

42 ENGINEERING↗
DOE OSTI2025

Cluster Dynamics Modeling Needs for the Advanced Materials and Manufacturing Technologies Program

This milestone report aims to identify and assess the cluster dynamics (CD) modeling requirements within the Department of Energy's Office of Nuclear Energy (DOE-NE) Advanced Materials and Manufacturing Technologies (AMMT) program and to communicate these needs to the DOE-NE Nuclear Energy Advanced Modeling and Simulation (NEAMS) program. The goal is to ensure NEAMS is well-informed about the CD modeling requirements to support AMMT's mission of accelerating the development, qualification, demonstration, and deployment of advanced structural materials and manufacturing for nuclear energy applications. CD modeling is an essential tool for predicting the degradation of structural materials under irradiation, which is a key component of AMMT's accelerated qualification process. The AMMT program focuses on both additively manufactured and wrought structural alloys, such as laser powder-bed fusion 316H austenitic stainless steel, alloy 709, Haynes 244, and alloy 617. These materials require a generalized CD modeling framework to facilitate rapid model development and computational simulation. A flexible, generalized CD software, similar to the Multiphysics Object-Oriented Simulation Environment (MOOSE) finite element framework, would enable modeling of various cluster types, including defect clusters, defect-solute clusters, and multicomponent clusters, incorporating thermodynamics and kinetics parameters. Radiation effects, microstructural feature evolution, and multi-dimensional modeling are critical considerations for the CD model. The usability of the CD code should allow for easy modification and coupling with MOOSE-based simulations. Additionally, the software should adhere to Nuclear Quality Assurance-1 standards, include a testing suite for verification and validation, and be version-controlled within a national laboratory-managed Git repository. Benchmark problems are needed to assess code predictions and performance.

11 - NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
NASA NTRS1972

Atmosphere Explorer control system software (version 1.0)

The basic design is described of the Atmosphere Explorer Control System (AECS) software used in the testing, integration, and flight contol of the AE spacecraft and experiments. The software performs several vital functions, such as issuing commands to the spacecraft and experiments, receiving and processing telemetry data, and allowing for extensive data processing by experiment analysis programs. The major processing sections are: executive control section, telemetry decommutation section, command generation section, and utility section.

Villasenor, A.↗
NASA NTRS1992

Parallel fault-tolerant robot control

A shared memory multiprocessor architecture is used to develop a parallel fault-tolerant robot controller. Several versions of the robot controller are developed and compared. A robot simulation is also developed for control observation. Comparison of a serial version of the controller and a parallel version without fault tolerance showed the speedup possible with the coarse-grained parallelism currently employed. The performance degradation due to the addition of processor fault tolerance was demonstrated by comparison of these controllers with their fault-tolerant versions. Comparison of the more fault-tolerant controller with the lower-level fault-tolerant controller showed how varying the amount of redundant data affects performance. The results demonstrate the trade-off between speed performance and processor fault tolerance.

Hamilton, D. L.↗
NASA NTRS1994

Trace contaminant control simulation computer program, version 8.1

The Trace Contaminant Control Simulation computer program is a tool for assessing the performance of various process technologies for removing trace chemical contamination from a spacecraft cabin atmosphere. Included in the simulation are chemical and physical adsorption by activated charcoal, chemical adsorption by lithium hydroxide, absorption by humidity condensate, and low- and high-temperature catalytic oxidation. Means are provided for simulating regenerable as well as nonregenerable systems. The program provides an overall mass balance of chemical contaminants in a spacecraft cabin given specified generation rates. Removal rates are based on device flow rates specified by the user and calculated removal efficiencies based on cabin concentration and removal technology experimental data. Versions 1.0 through 8.0 are documented in NASA TM-108409. TM-108409 also contains a source file listing for version 8.0. Changes to version 8.0 are documented in this technical memorandum and a source file listing for the modified version, version 8.1, is provided. Detailed descriptions for the computer program subprograms are extracted from TM-108409 and modified as necessary to reflect version 8.1. Version 8.1 supersedes version 8.0. Information on a separate user's guide is available from the author.

Perry, J. L.↗