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 55 records · Page 3

Credible practice of modeling and simulation in healthcare: ten rules from a multidisciplinary perspective

The complexities of modern biomedicine are rapidly increasing. Thus, modeling and simulation have become increasingly important as a strategy to understand and predict the trajectory of pathophysiology, disease genesis, and disease spread in support of clinical and policy decisions. In such cases, inappropriate or ill-placed trust in the model and simulation outcomes may result in negative outcomes, and hence illustrate the need to formalize the execution and communication of modeling and simulation practices. Although verification and validation have been generally accepted as significant components of a model’s credibility, they cannot be assumed to equate to a holistic credible practice, which includes activities that can impact comprehension and in-depth examination inherent in the devel-opment and reuse of the models. For the past several years, the Committee on Credible Practice of Modeling and Simulation in Healthcare, an interdisciplinary group seeded from a U.S. interagency initiative, has worked to codify best practices. Here, we provide Ten Rules for credible practice of modeling and simulation in healthcare developed from a comparative analysis by the Committee’s multidisciplinary membership, followed by a large stakeholder com-munity survey. These rules establish a unified conceptual framework for modeling and simulation design, implementation, evaluation, dissemination and usage across the modeling and simulation life-cycle. While biomedical science and clinical care domains have somewhat different requirements and expectations for credible practice, our study converged on rules that would be useful across a broad swath of model types. In brief, the rules are: (1) Define context clearly. (2) Use contextually appropriate data. (3) Evaluate within context. (4) List limitations explicitly. (5) Use version control. (6) Document appropriately. (7) Disseminate broadly. (8) Get independent reviews. (9) Test competing imple-mentations. (10) Conform to standards. Although some of these are common sense guidelines, we have found that many are often missed or misconstrued, even by seasoned practitioners. Computational models are already widely used in basic science to generate new biomedical knowledge. As they penetrate clinical care and healthcare policy, contributing to personalized and precision medicine, clinical safety will require established guidelines for the credible practice of modeling and simulation in healthcare.

Credibility↗

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, slated 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 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 suite image deployment process is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile without 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.

optimization↗

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↗

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↗

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↗

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↗

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↗

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↗

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↗

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↗

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↗

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↗

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

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

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

Advanced communications technology satellite high burst rate link evaluation terminal power control and rain fade software test plan, version 1.0

The Power Control and Rain Fade Software was developed at the NASA Lewis Research Center to support the Advanced Communications Technology Satellite High Burst Rate Link Evaluation Terminal (ACTS HBR-LET). The HBR-LET is an experimenters terminal to communicate with the ACTS for various experiments by government, university, and industry agencies. The Power Control and Rain Fade Software is one segment of the Control and Performance Monitor (C&PM) Software system of the HBR-LET. The Power Control and Rain Fade Software automatically controls the LET uplink power to compensate for signal fades. Besides power augmentation, the C&PM Software system is also responsible for instrument control during HBR-LET experiments, control of the Intermediate Frequency Switch Matrix on board the ACTS to yield a desired path through the spacecraft payload, and data display. The Power Control and Rain Fade Software User's Guide, Version 1.0 outlines the commands and procedures to install and operate the Power Control and Rain Fade Software. The Power Control and Rain Fade Software Maintenance Manual, Version 1.0 is a programmer's guide to the Power Control and Rain Fade Software. This manual details the current implementation of the software from a technical perspective. Included is an overview of the Power Control and Rain Fade Software, computer algorithms, format representations, and computer hardware configuration. The Power Control and Rain Fade Test Plan provides a step-by-step procedure to verify the operation of the software using a predetermined signal fade event. The Test Plan also provides a means to demonstrate the capability of the software.

Reinhart, Richard C.↗

Advanced Communications Technology Satellite high burst rate link evaluation terminal experiment control and monitor software maintenance manual, version 1.0

The Experiment Control and Monitor (EC&M) software was developed at NASA Lewis Research Center to support the Advanced Communications Technology Satellite (ACTS) High Burst Rate Link Evaluation Terminal (HBR-LET). The HBR-LET is an experimenter's terminal to communicate with the ACTS for various investigations by government agencies, universities, and industry. The EC&M software is one segment of the Control and Performance Monitoring (C&PM) software system of the HBR-LET. The EC&M software allows users to initialize, control, and monitor the instrumentation within the HBR-LET using a predefined sequence of commands. Besides instrument control, the C&PM software system is also responsible for computer communication between the HBR-LET and the ACTS NASA Ground Station and for uplink power control of the HBR-LET to demonstrate power augmentation during rain fade events. The EC&M Software User's Guide, Version 1.0 (NASA-CR-189160) outlines the commands required to install and operate the EC&M software. Input and output file descriptions, operator commands, and error recovery procedures are discussed in the document. The EC&M Software Maintenance Manual, Version 1.0 (NASA-CR-189161) is a programmer's guide that describes current implementation of the EC&M software from a technical perspective. An overview of the EC&M software, computer algorithms, format representation, and computer hardware configuration are included in the manual.

Reinhart, Richard C.↗