SEARCH · Search NASA

Results for “Building codes”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 145 records · Page 8

All sources NASA NTRS DOE OSTI

NASA NTRS2004

CFD: A Castle in the Sand?

The computational simulation community is not routinely publishing independently verifiable tests to accompany new models or algorithms. A survey reveals that only 22% of new models published are accompanied by tests suitable for independently verifying the new model. As the community develops larger codes with increased functionality, and hence increased complexity in terms of the number of building block components and their interactions, it becomes prohibitively expensive for each development group to derive the appropriate tests for each component. Therefore, the computational simulation community is building its collective castle on a very shaky foundation of components with unpublished and unrepeatable verification tests. The computational simulation community needs to begin publishing component level verification tests before the tide of complexity undermines its foundation.

Kleb, Bil↗

NASA NTRS2004

CFD: A Castle in the Sand?

Kleb, William L.↗

NASA NTRS2015

Software Development: 3D Animations and Creating User Interfaces for Realistic Simulations

My fall 2015 semester was spent at the Lyndon B. Johnson Space Center working in the Integrated Graphics, Operations, and Analysis Laboratory (IGOAL). My first project was to create a video animation that could tell the story of OMICS. OMICS is a term being used in the field of biomedical science to describe the collective technologies that study biological systems, such as what makes up a cell and how it functions with other systems. In the IGOAL I used a large 23 inch Wacom monitor to draw storyboards, graphics, and line art animations. I used Blender as the 3D environment to sculpt, shape, cut or modify the several scenes and models for the video. A challenge creating this video was to take a term used in biomedical science and describe it in such a way that an 8th grade student can understand. I used a line art style because it would visually set the tone for what we thought was an educational style. In order to get a handle on the perspective and overall feel for the animation without overloading my workspace, I split up the 2 minute animation into several scenes. I used Blender's python scripting capabilities which allowed for the addition of plugins to add or modify tools. The scripts can also directly interact with the objects to create naturalistic patterns or movements. After collecting the rendered scenes, I used Blender's built-in video editing workspace to output the animation. My second project was to write software that emulates a physical system's interface. The interface was to simulate a boat, ROV, and winch system. Simulations are a time and cost effective way to test complicated data and provide training for operators without having to use expensive hardware. We created the virtual controls with 3-D Blender models and 2-D graphics, and then add functionality in C# using the Unity game engine. The Unity engine provides several essential behaviors of a simulator, such as the start and update functions. A framework for Unity, which was developed in the lab, provided a way to place the different widgets on the virtual console dock and have them resize correctly based on the window dimensions.. My task in this project was to create the controls and visualizations for the data coming in from the simulator for the boat portion of the project. I wrote a class for each control window to handle the functionality of that widget. I implemented 11 widgets that make up the ship portion of the simulator. The members of the lab were each masters of their craft and I'm glad I had the opportunity to learn from them. I learned to plan strategically so I could finish this project on time. I allotted time for storyboarding, development, and refinement. In regards to animating I learned to use modifiers like lattice, boolean and build deformers. I also learned how to animate with drivers, how to use the dope sheet, and how to use the graph editor. In coding I learned to limit the chances for bugs by privatizing functions that should be exclusive to their class. I learned how to use the GIT repository to commit, stash and pull the latest build. I learned a bit of everything because I had the chance to see the entire application development process from the artwork, to the implementation.

Gordillo, Orlando Enrique↗

NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗

NASA NTRS2014

Path Toward a Unifid Geometry for Radiation Transport

The Direct Accelerated Geometry for Radiation Analysis and Design (DAGRAD) element of the RadWorks Project under Advanced Exploration Systems (AES) within the Space Technology Mission Directorate (STMD) of NASA will enable new designs and concepts of operation for radiation risk assessment, mitigation and protection. This element is designed to produce a solution that will allow NASA to calculate the transport of space radiation through complex computer-aided design (CAD) models using the state-of-the-art analytic and Monte Carlo radiation transport codes. Due to the inherent hazard of astronaut and spacecraft exposure to ionizing radiation in low-Earth orbit (LEO) or in deep space, risk analyses must be performed for all crew vehicles and habitats. Incorporating these analyses into the design process can minimize the mass needed solely for radiation protection. Transport of the radiation fields as they pass through shielding and body materials can be simulated using Monte Carlo techniques or described by the Boltzmann equation, which is obtained by balancing changes in particle fluxes as they traverse a small volume of material with the gains and losses caused by atomic and nuclear collisions. Deterministic codes that solve the Boltzmann transport equation, such as HZETRN [high charge and energy transport code developed by NASA Langley Research Center (LaRC)], are generally computationally faster than Monte Carlo codes such as FLUKA, GEANT4, MCNP(X) or PHITS; however, they are currently limited to transport in one dimension, which poorly represents the secondary light ion and neutron radiation fields. NASA currently uses HZETRN space radiation transport software, both because it is computationally efficient and because proven methods have been developed for using this software to analyze complex geometries. Although Monte Carlo codes describe the relevant physics in a fully three-dimensional manner, their computational costs have thus far prevented their widespread use for analysis of complex CAD models, leading to the creation and maintenance of toolkit-specific simplistic geometry models. The work presented here builds on the Direct Accelerated Geometry Monte Carlo (DAGMC) toolkit developed for use with the Monte Carlo N-Particle (MCNP) transport code. The workflow for achieving radiation transport on CAD models using MCNP and FLUKA has been demonstrated and the results of analyses on realistic spacecraft/habitats will be presented. Future work is planned that will further automate this process and enable the use of multiple radiation transport codes on identical geometry models imported from CAD. This effort will enhance the modeling tools used by NASA to accurately evaluate the astronaut space radiation risk and accurately determine the protection provided by as-designed exploration mission vehicles and habitats

Lee, Kerry↗

NASA NTRS2015

Convective Enhancement of Icing Roughness Elements in Stagnation Region Flows

To improve existing ice accretion simulation codes, more data regarding ice roughness and its effects on convective heat transfer are required. To build on existing research on this topic, this study used the Vertical Icing Studies Tunnel (VIST) at NASA Glenn Research to model realistic ice roughness in the stagnation region of a NACA 0012 airfoil. Using the VIST, a test plate representing the leading 2% chord of the airfoil was subjected to flows of 7.62 m/s (25 ft/s), 12.19 m/s (40 ft/s), and 16.76 m/s (55 ft/s). The test plate was fitted with 3 surfaces, each with a different representation of ice roughness: 1) a control surface with no ice roughness, 2) a surface with ice roughness with element height scaled by 10x and streamwise rough zone width from the stagnation point scaled by 10x, and 3) a surface with ice roughness with element height scaled by 10x and streamwise rough zone width from the stagnation point scaled by 25x. Temperature data from the tests were recorded using an infrared camera and thermocouples imbedded in the test plate. From the temperature data, a convective heat transfer coefficient map was created for each case. Additional testing was also performed to validate the VIST's flow quality. These tests included five-hole probe and hot-wire probe velocity traces to provide flow visualization and to study boundary layer formation on the various test surfaces. The knowledge gained during the experiments will help improve ice accretion codes by providing heat transfer coefficient validation data and by providing flow visualization data helping understand current and future experiments performed in the VIST.

Icing↗

NASA NTRS1986

Vector-matrix-quaternion, array and arithmetic packages: All HAL/S functions implemented in Ada

The HAL/S avionics programmers have enjoyed a variety of tools built into a language tailored to their special requirements. Ada is designed for a broader group of applications. Rather than providing built-in tools, Ada provides the elements with which users can build their own. Standard avionic packages remain to be developed. These must enable programmers to code in Ada as they have coded in HAL/S. The packages under development at JPL will provide all of the vector-matrix, array, and arithmetic functions described in the HAL/S manuals. In addition, the linear algebra package will provide all of the quaternion functions used in Shuttle steering and Galileo attitude control. Furthermore, using Ada's extensibility, many quaternion functions are being implemented as infix operations; equivalent capabilities were never implemented in HAL/S because doing so would entail modifying the compiler and expanding the language. With these packages, many HAL/S expressions will compile and execute in Ada, unchanged. Others can be converted simply by replacing the implicit HAL/S multiply operator with the Ada *. Errors will be trapped and identified. Input/output will be convenient and readable.

Klumpp, Allan R.↗

NASA NTRS1985

The Mystro system: A comprehensive translator toolkit

Mystro is a system that facilities the construction of compilers, assemblers, code generators, query interpretors, and similar programs. It provides features to encourage the use of iterative enhancement. Mystro was developed in response to the needs of NASA Langley Research Center (LaRC) and enjoys a number of advantages over similar systems. There are other programs available that can be used in building translators. These typically build parser tables, usually supply the source of a parser and parts of a lexical analyzer, but provide little or no aid for code generation. In general, only the front end of the compiler is addressed. Mystro, on the other hand, emphasizes tools for both ends of a compiler.

Collins, W. R.↗

NASA NTRS1995

Cooperative solutions coupling a geometry engine and adaptive solver codes

Follow-on work has progressed in using Aero Grid and Paneling System (AGPS), a geometry and visualization system, as a dynamic real time geometry monitor, manipulator, and interrogator for other codes. In particular, AGPS has been successfully coupled with adaptive flow solvers which iterate, refining the grid in areas of interest, and continuing on to a solution. With the coupling to the geometry engine, the new grids represent the actual geometry much more accurately since they are derived directly from the geometry and do not use refits to the first-cut grids. Additional work has been done with design runs where the geometric shape is modified to achieve a desired result. Various constraints are used to point the solution in a reasonable direction which also more closely satisfies the desired results. Concepts and techniques are presented, as well as examples of sample case studies. Issues such as distributed operation of the cooperative codes versus running all codes locally and pre-calculation for performance are discussed. Future directions are considered which will build on these techniques in light of changing computer environments.

Dickens, Thomas P.↗

NASA NTRS2015

Investigation of HZETRN 2010 as a Tool for Single Event Effect Qualification of Avionics Systems - Part II

An accurate prediction of spacecraft avionics single event effect (SEE) radiation susceptibility is key to ensuring a safe and reliable vehicle. This is particularly important for long-duration deep space missions for human exploration where there is little or no chance for a quick emergency return to Earth. Monte Carlo nuclear reaction and transport codes such as FLUKA can be used to generate very accurate models of the expected in-flight radiation environment for SEE analyses. A major downside to using a Monte Carlo-based code is that the run times can be very long (on the order of days). A more popular choice for SEE calculations is the CREME96 deterministic code, which offers significantly shorter run times (on the order of seconds). However, CREME96, though fast and easy to use, has not been updated in several years and underestimates secondary particle shower effects in spacecraft structural shielding mass. Another modeling option to consider is the deterministic code HZETRN 20104, which includes updates to address secondary particle shower effects more accurately. This paper builds on previous work by Rojdev, et al. to compare the use of HZETRN 2010 against CREME96 as a tool to verify spacecraft avionics system reliability in a space flight SEE environment. This paper will discuss modifications made to HZETRN 2010 to improve its performance for calculating SEE rates and compare results with both in-flight SEE rates and other calculation methods.

Rojdev, Kristina↗

NASA NTRS1998

Development and Testing of Automatically Generated ACS Flight Software for the MAP Spacecraft

By integrating the attitude determination and control system (ACS) analysis and design, flight software development, and flight software testing processes, it is possible to improve the overall spacecraft development cycle, as well as allow for more thorough software testing. One of the ways to achieve this integration is to use code-generation tools to automatically generate components of the ACS flight software directly from a high-fidelity (HiFi) simulation. In the development of the Microwave Anisotropy Probe (MAP) spacecraft, currently underway at the NASA Goddard Space Flight Center, approximately 1/3 of the ACS flight software was automatically generated. In this paper, we will examine each phase of the ACS subsystem and flight software design life cycle: analysis, design, and testing. In the analysis phase, we scoped how much software we would automatically generate and created the initial interface. The design phase included parallel development of the HiFi simulation and the hand-coded flight software components. Everything came together in the test phase, in which the flight software was tested, using results from the HiFi simulation as one of the bases of comparison for testing. Because parts of the spacecraft HiFi simulation were converted into flight software, more care needed to be put into its development and configuration control to support both the HiFi simulation and flight software. The components of the HiFi simulation from which code was generated needed to be designed based on the fact that they would become flight software. This process involved such considerations as protecting against mathematical exceptions, using acceptable module and parameter naming conventions, and using an input/output interface compatible with the rest of the flight software. Maintaining good configuration control was an issue for the HiFi simulation and the flight software, and a way to track the two systems was devised. Finally, an integrated test approach was devised to support flight software testing at both the unit- and build-test levels using the HiFi simulation to generate data for performance verification. Another benefit of the simulation and code-generation application used on the MAP project is that it supported bringing flight software and test data into the HiFi simulation environment. It was possible to integrate parts of the hand-coded flight software into the HiFi simulation, and also possible to import flight software test data for comparison and performance verification. This capability was used to incorporate the flight software Kalman filter into the HiFi simulation. This enabled us to greatly increase the amount of testing that could be done on the filter, because we could exert a greater degree of control over the software-only simulation than over the flight software test environment. Also, since the simulation could be used to run the Kalman filter faster than real time, our testing efficiency was greatly increased. We will conclude our discussion with a summary of the lessons learned thus far using automatically- generated code for the MAP project, and the spacecraft status as we work towards our scheduled launch in the year 2000.

ODonnell, James R., Jr.↗

NASA NTRS2021

Design and Modeling of a Coded-Interleaving System in the Presence of Fading

Future deep space links are migrating towards higher frequency bands such as Ka band and optical. These links are susceptible to non linear effects (e.g. cloud coverage, atmospheric turbulence, scintillation, antenna mis-pointing, jitter, relative motion, etc.) that cause various degrees of fading loss over various time scales. We consider a channel experiencing block fading where the channel coherence time is a lot longer than the length of a codeword. As long as the fading duration is not excessive, an interleaver can be used in a coded-communication system that randomizes the fades among symbols of multiple codewords. This achieves an “averaging” effect that spreads the signal energy more evenly among the codewords, and improves the likelihood that each of them can be decoded correctly. For simplicity, we consider a block interleaver where adjacent symbols of a codeword have a fixed delay (or separation) with each other, and investigate the error-rate performance of a coded-interleaving system (with fixed and finite interleaving depth) in the presence of block fading. Unlike prior research which assumes theoretical channel coherence models, we aim to build upon our analysis using empirical spacecraft signal measurements obtained with the Deep Space Network, and to use the fundamental theories of probability and statistics (e.g. variations of Law of Large Numbers) to quantify the error-rate performance of the coded-interleaving system. We propose to utilize these results in the design of a two-dimensional coded-interleaving system for fading channels.

Sanchez-Net, Marc↗

NASA NTRS2016

RACE: Building Airspace Simulations Faster and Better with Actors

Large, distributed aerospace simulations traditionally have been the domain of customized, closed designs, using statically compiled code based on specialized messaging systems such as DDS and HLA. While this can be suitable for one-off systems or specialized in-house product lines, it increases development costs and lowers extensibility. We propose to use contemporary internet software technology to solve this problem.Our Runtime for Airspace Concept Evaluation (RACE) architecture was born out of the need to rapidly develop and evaluate what-if scenarios that involve the whole National Airspace System (NAS), live NAS data feeds such as the FAA's System Wide Information Management (SWIM) servers, and existing flight simulators. It had to run on off-the-shelf hardware, be open sourced, and support visualization components up to multiple synchronized large screen geo viewers used in situation rooms. Most of all, it had to be extensible - being a viable platform for the development of future simulation components.

Mehlitz, Peter↗

NASA NTRS1986

TAE Plus: A conceptual view of TAE in the space station era

The use of the Transportable Applications Executive (TAE) for prototyping user interfaces has been the prime force behind the new TAE research and development work. The Data Systems Technology Division at GSFC is developing prototypes of user interfaces for different functions involved in the operation, analysis and data communication of space station payloads. TAE is a valuable prototyping tool because it enables a developer to build an entire application user interface model and run it without writing a single line of application code. One force driving new development is the need to update TAE's user interface to support the latest interactive graphic device technology. The current TAE, TAE Classic, uses interface techniques designed for an 80x24 character monochrome alphanumeric terminal, but does not effectively utilize features such as windowing, graphics, color, and selection devices available on newer workstations. To meet our needs, development of a TAE Plus began in FY-86 and involves augmenting TAE with three different sets of tools: a user interface toolkit; an application toolkit; and run-time service subroutines. A phased approach is being used to develop TAE Plus. In the first phase, we have met the needs of the user community and provided some support for rapid prototyping by developing a TAE Facelift, which adds an enhanced TAE interface (with windowing, mouse interaction, pull-down menus, etc.) to a select set of graphic workstations. The TAE Facelift allows many new concepts to be tested quickly for feedback and performance. In the second phase, a fully-integrated user interface management system, TAE Plus, will be built that supports the separation of interface from application, with the concomitant ability to prototype and rapidly change interfaces. This robust functionality will support, in an integrated manner, an application's development cycle from the prototype step through to the fully operational system.

Szczur, Martha↗

NASA NTRS1988

Software tools for the integration and execution of multidisciplinary analysis programs

The Environment for Application Software Integration and Execution (EASIE) software furnishes a methodology and a set of utility routines for design teams to use in building, maintaining, and applying CAD systems consituted by a large number of diverse, stand-alone analysis codes. EASIE uses a central data base that contains all variables required as inputs to the analysis programs that will make up the integrated system. Attention is given to the illustrative cases of three operational design systems based on EASIE.

Rowell, L. F.↗

NASA NTRS2011

The Crucial Role of Error Correlation for Uncertainty Modeling of CFD-Based Aerodynamics Increments

The Ares I ascent aerodynamics database for Design Cycle 3 (DAC-3) was built from wind-tunnel test results and CFD solutions. The wind tunnel results were used to build the baseline response surfaces for wind-tunnel Reynolds numbers at power-off conditions. The CFD solutions were used to build increments to account for Reynolds number effects. We calculate the validation errors for the primary CFD code results at wind tunnel Reynolds number power-off conditions and would like to be able to use those errors to predict the validation errors for the CFD increments. However, the validation errors are large compared to the increments. We suggest a way forward that is consistent with common practice in wind tunnel testing which is to assume that systematic errors in the measurement process and/or the environment will subtract out when increments are calculated, thus making increments more reliable with smaller uncertainty than absolute values of the aerodynamic coefficients. A similar practice has arisen for the use of CFD to generate aerodynamic database increments. The basis of this practice is the assumption of strong correlation of the systematic errors inherent in each of the results used to generate an increment. The assumption of strong correlation is the inferential link between the observed validation uncertainties at wind-tunnel Reynolds numbers and the uncertainties to be predicted for flight. In this paper, we suggest a way to estimate the correlation coefficient and demonstrate the approach using code-to-code differences that were obtained for quality control purposes during the Ares I CFD campaign. Finally, since we can expect the increments to be relatively small compared to the baseline response surface and to be typically of the order of the baseline uncertainty, we find that it is necessary to be able to show that the correlation coefficients are close to unity to avoid overinflating the overall database uncertainty with the addition of the increments.

Hemsch, Michael J.↗

NASA NTRS2013

radEq Add-On Module for CFD Solver Loci-CHEM

Loci-CHEM to be applied to flow velocities where surface radiation due to heating from compression and friction becomes significant. The module adds a radiation equilibrium boundary condition to the computational fluid dynamics (CFD) code to produce accurate results. The module expanded the upper limit for accurate CFD solutions of Loci-CHEM from Mach 4 to Mach 10 based on Space Shuttle Orbiter Re-Entry trajectories. Loci-CHEM already has a very promising architecture and performance, but absence of radiation equilibrium boundary condition limited the application of Loci-CHEM to below Mach 4. The immediate advantage of the add-on module is that it allows Loci-CHEM to work with supersonic flows up to Mach 10. This transformed Loci-CHEM from a rocket engine- heritage CFD code with general subsonic and low-supersonic applications, to an aeroheating code with hypersonic applications. The follow-on advantage of the module is that it is a building block for additional add-on modules that will solve for the heating generated at Mach numbers higher than 10.

McCloud, Peter↗

NASA NTRS2018

The CEOS Data Cube Portal: A User-Friendly, Open Source Software Solution for the Distribution, Exploration, Analysis, and Visualization of Analysis Ready Data

There is an urgent need to increase the capacity of developing countries to take part in the study and monitoring of their environments through remote sensing and space-based Earth observation technologies. The Open Data Cube (ODC) provides a mechanism for efficient storage and a powerful framework for processing and analyzing satellite data. While this is ideal for scientific research, the expansive feature space can also be daunting for end-users and decision-makers who simply require a solution which provides easy exploration, analysis, and visualization of Analysis Ready Data (ARD). Utilizing innovative web-design and a modular architecture, the Committee on Earth Observation Satellites (CEOS) has created a web-based user interface (UI) which harnesses the power of the ODC yet provides a simple and familiar user experience: the CEOS Data Cube (CDC). This paper presents an overview of the CDC architecture and the salient features of the UI. In order to provide adaptability, flexibility, scalability, and robustness, we leverage widely-adopted and well-supported technologies such as the Django web framework and the AWS Cloud platform. The fully-customizable source code of the UI is available at our public repository. Interested parties can download the source and build their own UIs. The UI empowers users by providing features that assist with streamlining data preparation, data processing, data visualization, and sub-setting ARD products in order to achieve a wide variety of Earth imaging objectives through an easy to use web interface.

User Interface↗