Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Docker”

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 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

GES DISC Data Recipes in Jupyter Notebooks

The Earth Science Data and Information System (ESDIS) Project manages twelve Distributed Active Archive Centers (DAACs) which are geographically dispersed across the United States. The DAACs are responsible for ingesting, processing, archiving, and distributing Earth science data produced from various sources (satellites, aircraft, field measurements, etc.). In response to projections of an exponential increase in data production, there has been a recent effort to prototype various DAAC activities in the cloud computing environment. This, in turn, led to the creation of an initiative, called the Cloud Analysis Toolkit to Enable Earth Science (CATEES), to develop a Python software package in order to transition Earth science data processing to the cloud. This project, in particular, supports CATEES and has two primary goals. One, to transition data recipes created by the Goddard Earth Science Data and Information Service Center (GES DISC) into an interactive and educational environment using JupyterNotebooks. Two, to acclimate Earth scientists to cloud computing. To accomplish these goals, we create JupyterNotebooks to compartmentalize the different steps of data analysis and help users obtain and parse data from the command line. We also develop a Docker container, comprised of Jupyter Notebooks, Python dependencies, and command line tools, and configure it into an easy-to-deploy package. The end result is an end-to-end product that simulates the use case of end users working in the cloud computing environment.

discoverability↗
NASA NTRS2019

Prototyping Operational Autonomy for Space Traffic Management

Current state of the art in Space Traffic Management (STM) relies on a handful of providers for surveillance and collision prediction, and manual coordination between operators. Neither is scalable to support the expected 10x increase in spacecraft population in less than 10 years, nor does it support automated manuever planning. We present a software prototype of an STM architecture based on open Application Programming Interfaces (APIs), drawing on previous work by NASA to develop an architecture for low-altitude Unmanned Aerial System Traffic Management. The STM architecture is designed to provide structure to the interactions between spacecraft operators, various regulatory bodies, and service suppliers, while maintaining flexibility of these interactions and the ability for new market participants to enter easily. Autonomy is an indispensable part of the proposed architecture in enabling efficient data sharing, coordination between STM participants and safe flight operations. Examples of autonomy within STM include syncing multiple non-authoritative catalogs of resident space objects, or determining which spacecraft maneuvers when preventing impending conjunctions between multiple spacecraft. The STM prototype is based on modern micro-service architecture adhering to OpenAPI standards and deployed in industry standard Docker containers, facilitating easy communication between different participants or services. The system architecture is designed to facilitate adding and replacing services with minimal disruption. We have implemented some example participant services (e.g. a space situational awareness provider/SSA, a conjunction assessment supplier/CAS, an automated maneuver advisor/AMA) within the prototype. Different services, with creative algorithms folded into then, can fulfil similar functional roles within the STM architecture by flexibly connecting to it using pre-defined APIs and data models, thereby lowering the barrier to entry of new players in the STM marketplace. We demonstrate the STM prototype on a multiple conjunction scenario with multiple maneuverable spacecraft, where an example CAS and AMA can recommend optimal maneuvers to the spacecraft operators, based on a predefined reward function. Such tools can intelligently search the space of potential collision avoidance maneuvers with varying parameters like lead time and propellant usage, optimize a customized reward function, and be implemented as a scheduling service within the STM architecture. The case study shows an example of autonomous maneuver planning is possible using the API-based framework. As satellite populations and predicted conjunctions increase, an STM architecture can facilitate seamless information exchange related to collision prediction and mitigation among various service applications on different platforms and servers. The availability of such an STM network also opens up new research topics on satellite maneuver planning, scheduling and negotiation across disjoint entities.

space traffic management↗
NASA NTRS2021

Power Autonomy Research and Development Environment (PARDE) User’s Guide Version 0.1.2

This document is a user's guide for the Power Autonomy Research and Development Environment (PARDE) software package. PARDE is a version of NASA's Autonomous Power Control (APC) software that can be used to evaluate fault management and automatic power system reconfiguration algorithms in a relevant system without having to fully develop all the supporting software. Software items included are a set of C++ class source files representing simplified fault management and reconfiguration logic, a power system simulation representing a notional architecture for NASA's Gateway vehicle, a web-based graphical user interface for running and testing the simulation and APC, a Docker-based automatic setup script for a development environment, and a user's guide.

autonomous power control↗
NASA NTRSDate not supplied

Building Collaborative Proving Grounds for R2O2R – NASA/CCMC - NOAA/Space Weather Prediction Testbed (SWPT) Partnership

In 2016 and 2019, Executive Orders were signed by the President to prepare the Nation for Space Weather Events. At the forefront of being able to achieve this goal is the necessity to accelerate and enhance R2O2R. To drive this initiative, the Space Weather R2O2R Framework, initially led by NOAA and NASA, was developed. At the very center of the framework is the Space Weather Proving Grounds effort that will allow various institutions to collaborate, share, and advance their space weather modeling and simulation capabilities. The first of these Proving Grounds is the Architecture for Collaborative Evaluation (ACE) environment shared between the Community Coordinated Modeling Center (CCMC) at NASA and the Space Weather Prediction Testbed (SWPT) at NOAA. Since 2019, the ACE environment has been set up on the AWS cloud where it utilizes AWS cloud services and Docker containerization technology.

T. Tsui↗
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 NTRS2024

Exploring New Frontiers in Space Communications: Enhancing Delay Tolerant Networking through Cloud and Containerization

The High-rate Delay Tolerant Networking (HDTN) project at NASA Glenn Research Center has developed software that enables more flexible, reliable, and efficient space internetworking by using modern computing techniques such as cloud services, microservices, network function virtualization, software defined networking, and a distributed architecture. HDTN is built upon the Bundle Protocol and related convergence layers which have been developed to mitigate the challenges of the space networking environment including long delays, asymmetric data rates, and intermittent connectivity. The HDTN implementation employs asynchronous message processing tasks which allow for non-blocking operations as well as deployment in both centralized and distributed architectures. This paper investigates deploying HDTN in a containerized approach on the NASA Goddard’s Mission Cloud Platform using Amazon Web Services Elastic Compute Cloud (EC2). Commercial cloud computing will lower operating costs, provide flexible resource allocation, and allow for interconnectivity between multiple NASA centers as well as external partners. Containerization using Docker will enable greater portability and scalability for HDTN to be deployed into a variety of environments. We discuss possible NASA missions and use-cases such as the Laser Communications Relay Demonstration (LCRD) where the services provided by HDTN (reliable transport, high-rate message processing, and store-and-forward capabilities) will be enhanced through cloud computing and containerization. In addition, we describe the HDTN architecture and possible microservice-based networking approaches that can be obtained via HDTN’s configuration capabilities. Finally, we detail the EC2 specifications needed to achieve data rates greater than 1 Gbps to support optical communication missions such as LCRD.

Blake LaFuente↗
NASA NTRS2024

DSS Security Assessment

The Discovery and Synchronization service (DSS) has implemented some reasonable technical controls that help improve security and there are very few technical findings. The use of Docker and Kubernetes helps simplify the deployment process, and the DSS uses mutual TLS (mTLS) to connect. Much of the security risk across the DSS is a factor of its nature, a distributed environment that relies on all members to secure their parts correctly. As such, the DSS team should attempt to emphasize security controls that reduce complexity for securing entities’ Cockroach DB (CRDB) instances properly and improve coordination among DSS members for things like security patching, incident response, detecting, and removing bad actors. The DSS team must recognize that operating a DSS instance securely will require a combination of technical and procedural controls. Each DSS entity must configure their instance properly and follow standard operating procedures to ensure that the DSS service is secure.

threat modeling↗
DOE OSTI2016

Sirepo for Synchrotron Radiation Workshop

Sirepo is an open source framework for cloud computing. The graphical user interface (GUI) for Sirepo, also known as the client, executes in any HTML5 compliant web browser on any computing platform, including tablets. The client is built in JavaScript, making use of the following open source libraries: Bootstrap, which is fundamental for cross-platform web applications; AngularJS, which provides a model–view–controller (MVC) architecture and GUI components; and D3.js, which provides interactive plots and data-driven transformations. The Sirepo server is built on the following Python technologies: Flask, which is a lightweight framework for web development; Jinja, which is a secure and widely used templating language; and Werkzeug, a utility library that is compliant with the WSGI standard. We use Nginx as the HTTP server and proxy, which provides a scalable event-driven architecture. The physics codes supported by Sirepo execute inside a Docker container. One of the codes supported by Sirepo is the Synchrotron Radiation Workshop (SRW). SRW computes synchrotron radiation from relativistic electrons in arbitrary magnetic fields and propagates the radiation wavefronts through optical beamlines. SRW is open source and is primarily supported by Dr. Oleg Chubar of NSLS-II at Brookhaven National Laboratory.

Nagler, Robert↗
DOE OSTI2016

Sirepo - Warp

Sirepo is an open source framework for cloud computing. The graphical user interface (GUI) for Sirepo, also known as the client, executes in any HTML5 compliant web browser on any computing platform, including tablets. The client is built in JavaScript, making use of the following open source libraries: Bootstrap, which is fundamental for cross-platform web applications; AngularJS, which provides a model–view–controller (MVC) architecture and GUI components; and D3.js, which provides interactive plots and data-driven transformations. The Sirepo server is built on the following Python technologies: Flask, which is a lightweight framework for web development; Jin-ja, which is a secure and widely used templating language; and Werkzeug, a utility library that is compliant with the WSGI standard. We use Nginx as the HTTP server and proxy, which provides a scalable event-driven architecture. The physics codes supported by Sirepo execute inside a Docker container. One of the codes supported by Sirepo is Warp. Warp is a particle-in-cell (PIC) code de-signed to simulate high-intensity charged particle beams and plasmas in both the electrostatic and electromagnetic regimes, with a wide variety of integrated physics models and diagnostics. At pre-sent, Sirepo supports a small subset of Warp’s capabilities. Warp is open source and is part of the Berkeley Lab Accelerator Simulation Toolkit.

Nagler, Robert↗
DOE OSTI2017

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗
DOE OSTI2017

bioboxes v510

Software is now both central and essential to modern biology, yet lack of availability, difficult installations, and complex user interfaces make software hard to obtain and use. Containerisation, as exemplified by the Docker platform, has the potential to solve the problems associated with sharing software. The developers propose bioboxes: containers with standardised interfaces to make bioinformatics software interchangeable.

Barton, Michael↗
DOE OSTI2015

Sustainability and Reproducibility via Containerized Computing

Recent developments in the commercial open source community have catalysed the use of Linux containers for scalable deployment of web-based applications to the cloud. Scientific software can be containerized with dependencies, configuration files, post-processing tools and even simulation results, referred to as containerized computing. This new approach promises to significantly improve sustainability, productivity and reproducibility. In this article, we present our experiences, technology, and future plans for open source containerization of software used to model particle and radiation beams. Vagrant is central to our approach, using Docker for cloud deployment and VirtualBox virtual machines for deployment to Mac OS and Windows computers. Our technology enables seamless switching between the desktop and the cloud to simplify simulation development and execution.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Transient Efficiency, Flexibility, and Reliability Optimization of Coal-Fired Power Plants - Final Program Review

This program developed an advanced model-based monitoring and model-predictive control algorithms for a coal fired power plant (CFPP), and deployed these algorithms in a real-time platform to demonstrate performance benefits for transient flexibility and plant operation efficiency. More specifically, the objectives were successfully achieved through a combination of (i) developing a high-fidelity transient plant model in Apros, which was used as a high-fidelity plant simulation between $100-50\% TMCR$ where TMCR denotes the turbine maximum continuous rating, i.e., baseload, (ii) developing a very fast physics-based reduced-order model (ROM) of the plant, which ran more than $100\times$ faster than real-time, enabling its use as real-time embedded model for model-based estimation (MBE) and model predictive control (MPC) (iii) implementing a real-time MBE based on ROM using a robust unscented Kalman filter (UKF) to continuously tune the ROM to match the measurements from high-fidelity Apros plant model despite significant plant-model mismatch, and thus, obtain a Digital Twin of the plant (iv) designing and implementing a real-time MPC with dual objectives of transient plant load tracking with high ramp rates and minimizing coal consumption, i.e., improving plant efficiency in the baseload-partload operation range of $100-50\% TMCR$. Each key element above was developed and tested individually, and has been reported in corresponding Topical Reports. Finally, all the individual elements were integrated in an overall closed-loop system, that was successfully tested in desktop Simulink test harness simulations with ROM or high-fidelity model as the plant. Thereafter, the Simulink implementation was used to auto-generate C-code and deploy as real-time Docker microservice containers in Linux, and validate that they can run in real-time in the hardware-in-the loop (HIL) setup and produce the same results as in Simulink. The results of the integrated simulation tests in Simulink as well as the real-time HIL deployment are documented in this final report, showing good load tracking for load ramps at $3-4\%/min$ ramp rates, and achieving up to $5.5\%$ reduction in coal relative to baseline operation at $50\% TMCR$ load. The desktop and HIL simulations show successful performance of the overall model based estimation and control solution and achieve the key objectives of the program for flexible, efficient and reliable operation of sub-critical coal fired power plants.

20 FOSSIL-FUELED POWER PLANTS↗
DOE OSTI2023

Best practices for documenting a scientific Python project

Documentation is a crucial component of software development that helps users with installation and usage of the software. Documentation also helps onboard new developers to a software project with contributing guidelines and API information. The INTERSECT project is an open federated hardware/software library to facilitate the development of au- tonomous laboratories. A documentation strategy using Sphinx has been utilized to help developers contribute to source code and to help users understand the INTERSECT Python interface. Docstrings as well as reStructuredText files are used by Sphinx to automatically compile HTML and PDF files which can be hosted online as API documentation and user guides. The resulting documentation website is automatically built and deployed using GitLab runners to create Docker containers with NGINX servers. The approach discussed in this paper to automatically deploy documentation for a Python project can improve the user and developer experience for many scientific projects.

Wiggins, Gavin↗
DOE OSTI2025

Remote Instrumentation and Data Acquisition: An Internship Research Report

This report outlines the development and implementation of a remote data acquisition system for waveform analysis using a Rohde & Schwarz oscilloscope. The project involved capturing waveform data, and transferring it to a local machine for visualization and analysis. The core logic was developed in C++ with a focus on object oriented programming and the use of polymorphism so the main application can interact with any instrument without knowing its exact type, simplifying the overall logic and making it easier to add or swap out components without changing the rest of the codebase.. The system issues Standard Commands for Programmable Instruments (SCPI) via a socket connection and parses the oscilloscope’s ASCII waveform data. The C++ application was containerized using Docker for ease of portability, and reproducibility. Emphasis was placed on secure networking practices, error handling, and effective data capture. The report describes the technical steps taken, challenges encountered, and lessons learned, providing insight into the practical integration of hardware interfacing with remote computational environments.

Parikh, Jaymil [Fermilab]↗
DOE OSTI2025

DeepLynx Ecosystem 2025

Poor data integration and governance continue to plague complex engineering projects, resulting in missed cost, schedule, and performance targets. Departments operate in isolated systems with manual data exchange, creating fragmented information that compounds errors and leads to significant delays and cost overruns. The DeepLynx ecosystem addresses these challenges through an open-source, modular data management platform that transforms fragmented project data into an integrated digital thread. Built on a federated microservice architecture, the ecosystem comprises seven specialized tools centered around DeepLynx Nexus, a unified data catalog with hierarchical organization and graph-based navigation capabilities. The ecosystem includes: DeepLynx Stream for real-time timeseries data ingestion from industrial sources; DeepLynx Ingest for governed data uploads with formal review workflows; DeepLynx Lattice for ontology-based entity and relationship extraction; DeepLynx Run for workflow orchestration and secure AI/ML compute; DeepLynx Visualize for 3D digital twin visualization; and DeepLynx Insight for AI-assisted document analysis with traceable, grounded responses. Deployable in cloud, on-premise, or hybrid environments using containerized Docker applications and Helm charts, the DeepLynx ecosystem provides flexible infrastructure that adapts to organizational requirements. By consolidating project data into a unified data lake with role-based access controls and OAuth2 authentication, DeepLynx enables digital thread and digital twin capabilities that improve decision-making, reduce risk, and support complex engineering workflows throughout the project lifecycle.

42 - ENGINEERING↗
DOE OSTI2026

Modular Accelerator Robotics Framework Implementation For Accelerator Inspection

Accelerator tunnels, such as the ones at Fermilab, remain highly radioactive after beam shutoff due to induced radiation from the beam. This residual radiation creates a hazardous environment for manual inspection and repair of beamline components. To minimize worker radiation dose and reduce beam downtime, the AD Robotics Initiative previously built a fleet of low-cost custom mobile robots. However, the custom Python sockets server-client architecture lacked standardization, causing development delays and complicating the integration of new sensors and actuators. Here, we developed a modular system using ROS2 and Docker to standardize the teleoperation and control interfaces. This system was validated by implementing a teleoperation controller with real-time, low-latency, and high-definition video feedback. The aim of this framework is for a new feature or even a robot to be integrated into the system simply by documenting the hardware configuration. Current integration of LiDAR, Odometry, and Depth Cameras provides the foundation for Simultaneous Localization and Mapping (SLAM) tasks. Finally, future work involves integration into the accelerator control system and the attachment of a 6 degree-of-freedom robotic arm for telemanipulation.

Rayyan Khana, M. [Unlisted, US, IL] (ORCID:0009000↗
DOE OSTI2016

Structure of photosystem II and substrate binding at room temperature

Light-induced oxidation of water by photosystem II (PS II) in plants, algae and cyanobacteria has generated most of the dioxygen in the atmosphere. PS II, a membrane-bound multi-subunit pigment protein complex, couples the one-electron photochemistry at the reaction centre with the four-electron redox chemistry of water oxidation at the Mn 4 CaO 5 cluster in the oxygen-evolving complex (OEC). Under illumination, the OEC cycles through five intermediate S-states (S 0 to S 4), in which S 1 is the dark-stable state and S 3 is the last semi-stable state before O-O bond formation and O 2 evolution. A detailed understanding of the O-O bond formation mechanism remains a challenge, and will require elucidation of both the structures of the OEC in the different S-states and the binding of the two substrate waters to the catalytic site. Here we report the use of femtosecond pulses from an X-ray free electron laser (XFEL) to obtain damage-free, room temperature structures of dark-adapted (S 1), two-flash illuminated (2F; S 3 -enriched), and ammonia-bound two-flash illuminated (2F-NH 3; S 3 -enriched) PS II. Although the recent 1.95 Å resolution structure of PS II at cryogenic temperature using an XFEL provided a damage-free view of the S 1 state, measurements at room temperature are required to study the structural landscape of proteins under functional conditions, and also for in situ advancement of the S-states. To investigate the water-binding site(s), ammonia, a water analogue, has been used as a marker, as it binds to the Mn 4 CaO 5 cluster in the S 2 and S 3 states. Since the ammonia-bound OEC is active, the ammonia-binding Mn site is not a substrate water site. This approach, together with a comparison of the native dark and 2F states, is used to discriminate between proposed O-O bond formation mechanisms.

Young, Iris D.↗