Search NASA⌕ Search

SEARCH · Search NASA

Results for “software builds”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1989

Advanced information processing system: Local system services

The Advanced Information Processing System (AIPS) is a multi-computer architecture composed of hardware and software building blocks that can be configured to meet a broad range of application requirements. The hardware building blocks are fault-tolerant, general-purpose computers, fault-and damage-tolerant networks (both computer and input/output), and interfaces between the networks and the computers. The software building blocks are the major software functions: local system services, input/output, system services, inter-computer system services, and the system manager. The foundation of the local system services is an operating system with the functions required for a traditional real-time multi-tasking computer, such as task scheduling, inter-task communication, memory management, interrupt handling, and time maintenance. Resting on this foundation are the redundancy management functions necessary in a redundant computer and the status reporting functions required for an operator interface. The functional requirements, functional design and detailed specifications for all the local system services are documented.

Burkhardt, Laura↗
NASA NTRS2004

Defect measurement and analysis of JPL ground software: a case study

Ground software systems at JPL must meet high assurance standards while remaining on schedule due to relatively immovable launch dates for spacecraft that will be controlled by such systems. Toward this end, the Software Quality Improvement (SQI) project's Measurement and Benchmarking (M&B) team is collecting and analyzing defect data of JPL ground system software projects to build software defect prediction models. The aim of these models is to improve predictability with regard to software quality activities. Predictive models will quantitatively define typical trends for JPL ground systems as well as Critical Discriminators (CDs) to provide explanations for atypical deviations from the norm at JPL. CDs are software characteristics that can be estimated or foreseen early in a software project's planning. Thus, these CDs will assist in planning for the predicted degree to which software quality activities for a project are likely to deviation from the normal JPL ground system based on pasted experience across the lab.

defects↗
NASA NTRS1990

Advanced Information Processing System (AIPS)-based fault tolerant avionics architecture for launch vehicles

An avionics architecture for the advanced launch system (ALS) that uses validated hardware and software building blocks developed under the advanced information processing system program is presented. The AIPS for ALS architecture defined is preliminary, and reliability requirements can be met by the AIPS hardware and software building blocks that are built using the state-of-the-art technology available in the 1992-93 time frame. The level of detail in the architecture definition reflects the level of detail available in the ALS requirements. As the avionics requirements are refined, the architecture can also be refined and defined in greater detail with the help of analysis and simulation tools. A useful methodology is demonstrated for investigating the impact of the avionics suite to the recurring cost of the ALS. It is shown that allowing the vehicle to launch with selected detected failures can potentially reduce the recurring launch costs. A comparative analysis shows that validated fault-tolerant avionics built out of Class B parts can result in lower life-cycle-cost in comparison to simplex avionics built out of Class S parts or other redundant architectures.

Lala, Jaynarayan H.↗
DOE OSTI2012

Building Agent™ Software (BA) [SWRs 12-05 and 17-21]

Energy interfaces provide a new level of motivational information. Many studies have reported energy savings after dashboards for operators are installed, but these provide little actionable information to the occupant and the occupant cannot report individual comfort. The Building Agent™ (BA), in development at the National Renewable Energy Laboratory (NREL), provides an interface for the occupant to converse with the building control system and aims to actively engage and affect occupant behavior to achieve positive energy outcomes. Energy savings achieved via occupant behavioral changes could be as high as 25%, and could rival savings achieved by technological measures. For example, energy audits often show that more than 50% of the energy used in a building is consumed at night. Occupants leaving equipment and lighting on after they leave work is a large contributing factor. Similar savings opportunities have been identified when occupants were away from their desks 50% of the time, while most of their computers, lights, and other equipment remained powered on. Building Agent aims to create cohesion between building automation system (BAS) data, local measurements, and occupant feedback to provide visualizations, empowering occupants and building engineers to take diagnostic, proactive, energy-saving, and comfort-improving actions. The multilayer BA architecture consists of central server, measurement, and distributed application layers. The server layer aggregates global and localized measurements with occupant feedback to correlate perceived comfort with actual data throughout the building. The measurement layer complements BAS data with localized, environmental condition measurements at workstations. The application layer provides a bidirectional communications mechanism between the building and the occupants that accepts comfort feedback and provides energy performance information. The interface layer also uses three displays to influence building energy use: empathetic and personalized gauges, graphical data, and competitive rankings. Building Agent was implemented at NREL in the Research Support Facility (RSF), a LEED Platinum and Net Zero office building, which has received many awards. The constant feedback from occupants has enabled BA to better enhance the BAS data controls. Continued work is being done on BA to increase visualization of data and enhanced the user experience.

Long, Nicholas↗
NASA NTRS2004

NASA's Swarm Missions: The Challenge of Building Autonomous Software

The days of watching a massive manned cylinder thrust spectacularly off a platform into space might rapidly become ancient history when the National Aeronautics and Space Administration (NASA) introduces its new millenium mission class. Motivated by the need to gather more data than is possible with a single spacecraft, scientists have developed a new class of missions based on the efficiency and cooperative nature of a hive culture. The missions, aptly dubbed nanoswarm will be little more than mechanized colonies cooperating in their exploration of the solar system. Each swarm mission can have hundreds or even thousands of cooperating intelligent spacecraft that work in teams. The spacecraft must operate independently for long periods both in teams and individually, as well as have autonomic properties - self-healing, -configuring, -optimizing, and -protecting- to survive the harsh space environment. One swarm mission under concept development for 2020 to 2030 is the Autonomous Nano Technology Swarm (ANTS), in which a thousand picospacecraft, each weighing less than three pounds, will work cooperatively to explore the asteroid belt. Some spacecraft will form teams to catalog asteroid properties, such as mass, density, morphology, and chemical composition, using their respective miniature scientific instruments. Others will communicate with the data gatherers and send updates to mission elements on Earth. For software and systems development, this is uncharted territory that calls for revolutionary techniques.

Truszkowski, Walt↗
NASA NTRS2003

Software for Building Models of 3D Objects via the Internet

The Virtual EDF Builder (where EDF signifies Electronic Development Fixture) is a computer program that facilitates the use of the Internet for building and displaying digital models of three-dimensional (3D) objects that ordinarily comprise assemblies of solid models created previously by use of computer-aided-design (CAD) programs. The Virtual EDF Builder resides on a Unix-based server computer. It is used in conjunction with a commercially available Web-based plug-in viewer program that runs on a client computer. The Virtual EDF Builder acts as a translator between the viewer program and a database stored on the server. The translation function includes the provision of uniform resource locator (URL) links to other Web-based computer systems and databases. The Virtual EDF builder can be used in two ways: (1) If the client computer is Unix-based, then it can assemble a model locally; the computational load is transferred from the server to the client computer. (2) Alternatively, the server can be made to build the model, in which case the server bears the computational load and the results are downloaded to the client computer or workstation upon completion.

Schramer, Tim↗
DOE OSTI2011

Software Construction and Composition Tools for Petascale Computing SCW0837 Progress Report

The majority of scientific software is distributed as source code. As the number of library dependencies and supported platforms increases, so does the complexity of describing the rules for configuring and building software. In this project, we have performed an empirical study of the magnitude of the build problem by examining the development history of two DOE-funded scientific software projects. We have developed MixDown, a meta-build tool, to simplify the task of building applications that depend on multiple third-party libraries. The results of this research indicate that the effort that scientific programmers spend takes a significant fraction of the total development effort and that the use of MixDown can significantly simplify the task of building software with multiple dependencies.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Method of Test for Evaluating Building Performance Simulation Software

ANSI/ASHRAE Standard 140 Method of Test for Evaluating Building Performance Simulation Software specifies the method to test the core competency of building performance simulation (BPS) software, a broad class of software which includes building energy modeling (BEM) software. Standard 140 has been widely used by BEM software vendors to help diagnose and compare the results from the program with other modeling programs. The Standard is also referenced by codes, standards, government programs, and other incentive programs as a part of minimum requirements for qualifying BEM software. The explanatory information, summary tables and figures in this 140 User’s Manual (referred to as “this Manual”) are provided to help users in implementing various suites of tests specified in Standard 140-2023 (referred to in this manual as “Standard 140” or “the Standard”).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2018

Securing Your ICS Software with the AttackSurface Host Analyzer (AHA)

Implementing a secure development lifecycle (SDL) presents increasing challenges to software developers as they must ensure software correctly integrates both underlying operating system security features while also managing dependencies on third-party libraries or executables. There are a growing number of security functions that require a close integration between the OS security features and software builds to ensure strong protection. Furthermore, as software platforms grow in complexity, they present many opportunities for misconfigurations and inadequate defenses. This challenge is especially prevalent for industrial control systems (ICS), which oten depend on both legacy sotware platforms, or out of date operating systems. This paper presents the AttackSurface Host Analyzer (AHA) tool, which is used to assess the security of a software platform through its integration with a host operating system. The tool collects data from the various platforms running on an OS, evaluates an array of security properties, and then introduces metrics and visualizations to provide feedback on the system's attack surface based on the external interconnections and the completeness of the available security protections. The paper then explores the attack surface of a variety of industry-standard ICS platforms to provide insight into the current degree of protection enabled by them.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2020

Automated Integration of Continental-Scale Observations in Near-Real Time for Simulation and Analysis of Biosphere–Atmosphere Interactions

The National Ecological Observatory Network (NEON) is a continental-scale observatory with sites across the US collecting standardized ecological observations that will operate for multiple decades. To maximize the utility of NEON data, we envision edge computing systems that gather, calibrate, aggregate, and ingest measurements in an integrated fashion. Edge systems will employ machine learning methods to cross-calibrate, gap-fill and provision data in near-real time to the NEON Data Portal and to High Performance Computing (HPC) systems, running ensembles of Earth system models (ESMs) that assimilate the data. For the first time gridded EC data products and response functions promise to offset pervasive observational biases through evaluating, benchmarking, optimizing parameters, and training new machine learning parameterizations within ESMs all at the same model-grid scale. Leveraging open-source software for EC data analysis, we are already building software infrastructure for integration of near-real time data streams into the International Land Model Benchmarking (ILAMB) package for use by the wider research community. We will present a perspective on the design and integration of end-to-end infrastructure for data acquisition, edge computing, HPC simulation, analysis, and validation, where Artificial Intelligence (AI) approaches are used throughout the distributed workflow to improve accuracy and computational performance.

Durden, David J.↗
DOE OSTI2015

Software management for the NO ν A Experiment

The NO$\nu$A software (NO$\nu$ASoft) is written in C++, and built on the Fermilab Computing Division's art framework that uses ROOT analysis software. NO$\nu$ASoft makes use of more than 50 external software packages, is developed by more than 50 developers and is used by more than 100 physicists from over 30 universities and laboratories in 3 continents. The software builds are handled by Fermilab's custom version of Software Release Tools (SRT), a UNIX based software management system for large, collaborative projects that is used by several experiments at Fermilab. The system provides software version control with SVN configured in a client-server mode and is based on the code originally developed by the BaBar collaboration. In this paper, we present efforts towards distributing the NO$\nu$A software via the CernVM File System distributed file system. Here, we will also describe our recent work to use a CMake build system and Jenkins, the open source continuous integration system, for NOASoft.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

The ATLAS experiment software on ARM

With an increased dataset obtained during the Run 3 of the LHC at CERN and the even larger expected increase of the dataset by more than one order of magnitude for the HL-LHC, the ATLAS experiment is reaching the limits of the current data processing model in terms of traditional CPU resources based on x86_64 architectures and an extensive program for software upgrades towards the HL-LHC has been set up. The ARM architecture is becoming a competitive and energy efficient alternative. Some surveys indicate its increased presence in HPCs and commercial clouds, and some WLCG sites have expressed their interest. Chip makers are also developing their next generation solutions on ARM architectures, sometimes combining ARM and GPU processors in the same chip. Consequently it is important that the ATLAS software embraces the change and is able to successfully exploit this architecture. We report on the successful porting to ARM of the Athena software framework, which is used by ATLAS for both online and offline computing operations. Furthermore we report on the successful validation of simulation workflows running on ARM resources. For this we have set up an ATLAS Grid site using ARM compatible middleware and containers on Amazon Web Services (AWS) ARM resources. The ARM version of Athena is fully integrated in the regular software build system and distributed in the same way as other software releases. In addition, the workflows have been integrated into the HEPscore benchmark suite which is the planned WLCG wide replacement of the HepSpec06 benchmark used for Grid site pledges. In the overall porting process we have used resources on AWS, Google Cloud Platform (GCP) and CERN. A performance comparison of different architectures and resources will be discussed.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2026

Finding the missing pieces: filling gaps that impede the translation of omics data into models

High-throughput omics technologies such as DNA sequencing have made the sequencing and computational assembly of microbial genomes recovered from the environment relatively routine. Computational inference of the protein products encoded by these genomes, and the associated biochemical functions, should enable the accurate prediction and modeling of microbial metabolism, organismal interactions, and ecosystem processes. However, a lack of scalable, probabilistic protein annotation tools limits the full potential of modeling for understanding the metabolism and biogeochemical cycles of microbial communities. Our approach to improve inference of protein annotations and metabolic models relied on learning from and emulating expert manual curation, leveraging software engineering and data science best practices to scale up the throughput and accuracy of annotations and metabolic model construction, building software to objectively evaluate different annotation strategies, and more closely linking the protein annotation and metabolic model inference process. Outcomes of this research include several improved or new computational tools, including DRAM (Distilled and Refined Annotation of Metabolism) for annotating microbial genomes with protein function and metabolic traits, CAMPER (Curated Annotations for Microbial Polyphenol Enzymes and Reactions) for annotating key polyphenol metabolisms, EC-Bench for comprehensive and unbiased benchmarking of annotation tools, and several apps available via the DOE Systems Biology Knowledgebase (KBase) for building genome-scale metabolic models. We demonstrate that these tools allow us to scalably annotate and understand thousands of genomes for microbial communities from a variety of systems and test cases, including rivers, thawing permafrost, and gut microbiomes. All of these computational tools are available as open-source software, with most broadly and easily accessible to the scientific community via KBase apps.

59 BASIC BIOLOGICAL SCIENCES↗
NASA NTRS1997

The SEL Adapts to Meet Changing Times

Since 1976, the Software Engineering Laboratory (SEL) has been dedicated to understanding and improving the way in which one NASA organization, the Flight Dynamics Division (FDD) at Goddard Space Flight Center, develops, maintains, and manages complex flight dynamics systems. It has done this by developing and refining a continual process improvement approach that allows an organization such as the FDD to fine-tune its process for its particular domain. Experimental software engineering and measurement play a significant role in this approach. The SEL is a partnership of NASA Goddard, its major software contractor, Computer Sciences Corporation (CSC), and the University of Maryland's (LTM) Department of Computer Science. The FDD primarily builds software systems that provide ground-based flight dynamics support for scientific satellites. They fall into two sets: ground systems and simulators. Ground systems are midsize systems that average around 250 thousand source lines of code (KSLOC). Ground system development projects typically last 1 - 2 years. Recent systems have been rehosted to workstations from IBM mainframes, and also contain significant new subsystems written in C and C++. The simulators are smaller systems averaging around 60 KSLOC that provide the test data for the ground systems. Simulator development lasts up to 1 year. Most of the simulators have been built in Ada on workstations. The SEL is responsible for the management and continual improvement of the software engineering processes used on these FDD projects.

Pajerski, Rose S.↗
DOE OSTI2018

Blackcomb 2: Hardware-Software Co-design for Non-Volatile Memory in Exascale Systems

Fast non-volatile memory (NVM) offers game-changing opportunities to rethink traditional system architectures; to address their energy inefficiencies; to leverage the new devices for greater performance; and to exploit the new capability of non-volatility to enhance system resilience, even in the face of larger system scale and degraded reliability of components. However, the devil is in the details, and to reap such potential benefits we must address challenges that arise when the contents of memory survive application failure, when software becomes responsible for managing the contents of CPU caches, and when memory accelerators blur the line between hardware and software. Building on the accomplishments of the Blackcomb Project, funded in 2010, we have identified, evaluated, and optimized promising NVM hardware and software technologies that are essential to provide the necessary memory capacity, performance, resilience, and energy efficiency in exascale systems.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Engineering Computational Practices (Rev. 1)

This manual will attempt to motivate the use of an automated build system for the purposes of computational science and engineering. As part of this motivation, the surrounding computational practices of version control, documen tation, compute environment management, and regression testing will also be addressed as applied to the practice of computational engineering. Specifically, this manual intends to motivate the adoption of these traditional software engineering practices for use in research and production engineering simulation projects. This manual is not the first such effort in the greater scientific computing community. In fact, the authors relied heavily on the lesson plans of the Software Carpentry, established to teach computing skills to researchers in 1998. As the intention for this manual is to lay out fundamental practices of engineering computing, it will not attempt to fully teach the underlying concepts and will instead reference the well designed lesson plans of the Software Carpentry. Where possible, this manual will explain to general computing practices and concepts and limit discussion of specific software implementations to examples or vehicles for practice in concrete application. The specific software taught by the Software Carpentry curriculum is an excellent starting point to learn the core concepts of computational engi neering. However, the authors have found that applications to engineering simulation and analysis require translation of these software development concepts into the language and workflows of computational engineers. Adopting these computational tools may require engineers to re-imagine their workflows in some combination of traditional engineer ing and software concepts. It has also been necessary to extend existing software build systems for engineering practices beyond the simple wrap ping of engineering software execution. Where necessary, examples of specific software and their method of extension to engineering simulations will be given, with reference to the User Manual for recommended practical use. Where this manual relies on specific implementation examples, it should be understood that the practicing engineer may find that different software is more amenable to their specific work. It is always the overall collection of computational practices is more important than any specific software implementation. The ability to recognize which concepts are implemented by a software package will make a practicing engineer agile to changing project needs, computing resources, numeric solvers, programming languages, and even available funding.

42 ENGINEERING↗
DOE OSTI2023

Graph-based machine learning improves just-in-time defect prediction

The increasing complexity of today’s software requires the contribution of thousands of developers. This complex collaboration structure makes developers more likely to introduce defect-prone changes that lead to software faults. Determining when these defect-prone changes are introduced has proven challenging, and using traditional machine learning (ML) methods to make these determinations seems to have reached a plateau. In this work, we build contribution graphs consisting of developers and source files to capture the nuanced complexity of changes required to build software. By leveraging these contribution graphs, our research shows the potential of using graph-based ML to improve Just-In-Time (JIT) defect prediction. We hypothesize that features extracted from the contribution graphs may be better predictors of defect-prone changes than intrinsic features derived from software characteristics. We corroborate our hypothesis using graph-based ML for classifying edges that represent defect-prone changes. This new framing of the JIT defect prediction problem leads to remarkably better results. We test our approach on 14 open-source projects and show that our best model can predict whether or not a code change will lead to a defect with an F1 score as high as 77.55% and a Matthews correlation coefficient (MCC) as high as 53.16%. This represents a 152% higher F1 score and a 3% higher MCC over the state-of-the-art JIT defect prediction. We describe limitations, open challenges, and how this method can be used for operational JIT defect prediction.

59 BASIC BIOLOGICAL SCIENCES↗