Search NASA⌕ Search

SEARCH · Search NASA

Results for “ARCHITECTURE”

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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS2019

Impacts of In-Space Assembly as Applied to Human Exploration Architectures

Human missions to Mars present several major challenges that must be overcome, including delivering multiple large mass and volume elements, keeping the crew safe and productive, meeting cost constraints, and ensuring a sustainable campaign. Traditional methods for executing human Mars missions minimize or eliminate in-space assembly (iSA), which provides a narrow range of options for addressing these challenges and limits the types of missions that can be performed. This paper discusses recent work to evaluate how the inclusion of in-space assembly in space mission architectural concepts could provide novel solutions to address these challenges by increasing operational flexibility, robustness, risk reduction, crew health and safety, and sustainability. Several assembly focus areas identified through previous work were developed and evaluated to identify high-potential iSA applications that can have meaningful impacts on the challenges facing Mars missions. Architecture trade options were developed and assessed through sensitivity analyses, resulting in identification of six iSA-based architecture solutions that could be incorporated into Mars mission architectures with moderate levels of assembly. Assembly agent and infrastructure concepts were also developed that would be necessary to enable or facilitate the iSA operations. Several observations developed through the study are presented to inform future human mission architecture and campaign developments.

Jefferies, Sharon A.↗
NASA NTRS2020

Medical Data Architecture Platform and Recommended Requirements for a Medical Data System for Exploration Missions

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically- relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions. In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗
NASA NTRS2020

Risk and Performance Assessment of Generic Mission Architectures: Showcasing the Artemis Mission

A has initiated a strong push to return face. In this work, we astronaut assess performance and risk for proposed mission architectures using a new Mission Architecture Risk Assessment (MARA) tool. The MARA tool can produce statistics about the availability of components and overall performance of the mission considering potential failures of any of its components. In a Monte Carlo approach, the tool repeats the mission simulation multiple times while a random generator lets modules fail according to their failure rates. The results provide statistically meaningful insights into the overall performance of the chosen architecture. A given mission architecture can be freely replicated in the tool, with the mission timeline and basic characteristics of employed mission modules (habitats, rovers, power generation units, etc.) specified in a configuration file. Crucially, failure rates for each module need to be known or estimated. The tool performs an event-driven simulation of the mission and accounts for random failure events. Failed modules can be repaired, which takes crew time but restores operations. In addition to tracking individual modules, MARA can assess the availability of predefined functions throughout the mission. For instance, the function of resource collection would require a rover to collect the resources, a power generation unit to charge the rover, and a resource processing module. Together, the modules that are required for a given function are called a functional group. Similarly, we can assess how much crew time is available to achieve a mission benefit (e.g. research, building a base, etc) as opposed to spending crew time on repairs. Here we employ the method on the proposed NASA Artemis mission. Artemis aims to return United States astronauts to the lunar surface by 2024. Results provide insights into mission failure probabilities, up- and downtime for individual modules and crew-time resources spent on the repair of failed modules. The tool also allows us to tweak the mission architecture in order to find setups that produce more favorable mission performance. As such, the tool can be an aid in improving the mission architect abling cost-benefit analysis for mission improvement.

Rumpf, Clemens M.↗
NASA NTRSDate not supplied

A Novel RF Architecture for Simultaneous Communication, Navigation, and Remote Sensing with Software-Defined Radio

The rapid growth of SmallSat and CubeSat missions at NASA has necessitated a re-evaluation of communication and remote-sensing architectures. Novel designs for CubeSat-sized single-board computers can now include larger Field-Programmable Gate Arrays (FPGAs) and faster System-on-Chip (SoCs) devices. These components substantially improve onboard processing capabilities so that varying subsystems no longer require an independent processor. By replacing individual Radio Frequency (RF) systems with a single software-defined radio (SDR) and processor, mission designers have greater control over reliability, performance, and efficiency. The presented architecture combines individual processing systems into a single design and establishes a modular SDR architecture capable of both remote-sensing and communication applications. This new approach based on a multi-input multi-output (MIMO) SDR features a scalable architecture optimized for Size, Weight, Power, and Cost (SWaP-C), with sufficient noise performance and phase-coherence to enable both remote-sensing and navigation applications, while providing a communication solution for simultaneous S-band and X-band transmission. This SDR design is developed around the NASA CubeSat Card Standard (CS2) that provides the required modularity through simplified backplane and interchangeable options for multiple radiation-hardened/tolerant processors. This architecture provides missions with a single platform for high-rate communication and a future platform to develop cognitive radio systems.

Advanced Avionics, Hybrid Processing, Data Process↗
NASA NTRSDate not supplied

Open Innovation for a NASA Architecture Library

NASA’s Center of Excellence for Collaborative Innovation (CoECI) uses open innovation, or “crowdsourcing”, to access the global public to find ideas, concepts, designs, or solutions that meet a previously unmet need possibly resulting in significant advances in performance. The Center of Excellence for Collaborative Innovation was launched at the request of the White House Office of Science and Technology Policy. This is both a non-traditional method of innovation and a non-traditional method of outreach to the public to involve them in space technologies and programs. It has been used often for software development and new hardware technology. In this case we applied it to innovate with systems engineering tools for creating space architectures. The challenge was sponsored by NASA Engineering and Safety Center Systems Engineering Technical Fellow as part of a program for NASA’s adoption of MBSE. It was a trial to see if there would be as much participation or quality submissions with this more specialized topic and skill. The challenge sought space architecture representations and decompositions to create a library of modeled parts in a system modeling language (SysML). Mission architects mostly start from scratch to build model elements representing the functional and physical architecture of a system in SysML. There are a few beginning libraries, but these are also local to a program or group. A common library will save system engineers a large amount of time, will allow project stakeholders to recognize common graphics and quickly understand the architecture options. The challenge was promoted internationally, especially through professional organizations and universities with a systems engineering focus. It was open for 4 months, purposefully over the winter holiday break time to allow participants extra time outside of work or school. The challenge was designed so that expertise in space hardware was not necessary but getting to play with models of space architecture could provide motivation to participate. We did not receive as many entries as other broader outreach challenges, but the ones we received were extremely thorough and high quality. Solutions came from individuals and teams, students and professional consultants from the United States and Europe. We learned a few lessons about how to engage with the public and what characteristics of a problem result in good crowdsourcing results. The outreach challenge produced several useful ideas and modeled space elements, and the group will be engaging the winners to learn more about their new approaches.

innovation↗
NASA NTRSDate not supplied

Ray Tracing Techniques for the Characterization of Lunar Communication Architectures

This paper provides an overview of the computational techniques used to characterize the viability of different lunar architectures and their ability to provide communication services to the lunar surface. This analysis was done with modern ray tracing techniques that allow for the computations to be done on Graphics Processing Unit (GPU) clusters for a high level of parallelism and severe reduction in computation time. The ray tracing computations were done with the GPU platform Compute Unified Device Architecture (CUDA) provided by NVIDIA which utilizes general-purpose computing on graphics processing units (GPGPU). This new method provides the advantage of being able to characterize a much larger portion of the lunar surface due to its computational efficiency as well as providing a more accurate representation of elevation angle limits instead of the typical and often inaccurate elevation angle mask. The Lunar surface can now be characterized with metrics such as contact time, outage time, and received data rate. With these metrics, different proposed Lunar architectures can be rapidly evaluated. This reduction in computation time not only leads to more accurate results but allows these results to be obtained in a time frame that allows for the complete characterization of the trade space. It is expected that these different architecture comparisons will lead to a conclusive determination of the optimal Lunar architecture and will allow for future Lunar missions to operate as close to real time as possible. In addition, this computation method can be used to recreate visibility figures generated by previous methods but with an increased level of accuracy.

Thomas Montano↗
NASA NTRSDate not supplied

Probabilistic Modeling of a Three-Stage Human Landing System Architecture

Unmitigated uncertainties are known to have previously led to failed development programs; in order to combat these uncertainties, risks and their impacts must be understood and handled to ensure program success. In this paper, a probabilistic methodology to handle uncertainties is demonstrated on a three-element Human Landing System (HLS) concept, which allows tracking of current best estimates of the vehicle’s performance and assessment of its robustness against uncertainties. This methodology has two key parts: first, the creation of a dynamic architecture model of a three-element HLS concept; and second, its use with surrogate modeling and range estimating techniques to capture and propagate uncertainties. The DYnamic Rocket EQuation Tool (DYREQT), a space systems synthesis and sizing framework used by NASA, was used as to model the HLS architecture. For the probabilistic analysis, uncertainties of interest within the HLS concept were enumerated and represented as parameters within the DYREQT model as inputs for vehicle stages or mission profile events. Range estimating — a probabilistic method that combines Monte Carlo sampling, focus on critical parameters, and heuristics to assess risk and opportunities — is then adapted with operational parameters as well as vehicle parameters in the DYREQT model to capture mission uncertainty alongside vehicle uncertainty. To perform the range estimation portion of this methodology, the DYREQT model was sampled using a Design of Experiments (DoE) to efficiently explore the architecture design space with respect to the set of uncertainty parameters. Then, the results were used to create surrogate models, multivariate regressions that can visualize hypercube trends in the design space, of the architecture with respect to the uncertainty parameters. Using a correlation matrix constructed for the uncertainty parameters, previously independent samples were transformed to perform a Correlated Monte Carlo on the surrogate models. This probabilistic methodology was proved to provide insight into the underlying uncertainties of the three-element HLS architecture.

Stephanie Y Zhu↗
NASA NTRSDate not supplied

Probabilistic Modeling of a Three-Stage Human Landing System Architecture

Unmitigated uncertainties are known to have previously led to failed development programs; in order to combat these uncertainties, risks and their impacts must be understood and handled to ensure program success. In this paper, a probabilistic methodology to handle uncertainties is demonstrated on a three-element Human Landing System (HLS) concept, which allows tracking of current best estimates of the vehicle’s performance and assessment of its robustness against uncertainties. This methodology has two key parts: first, the creation of a dynamic architecture model of a three-element HLS concept; and second, its use with surrogate modeling and range estimating techniques to capture and propagate uncertainties. The DYnamic Rocket EQuation Tool (DYREQT), a space systems synthesis and sizing framework used by NASA, was used as to model the HLS architecture. For the probabilistic analysis, uncertainties of interest within the HLS concept were enumerated and represented as parameters within the DYREQT model as inputs for vehicle stages or mission profile events. Range estimating — a probabilistic method that combines Monte Carlo sampling, focus on critical parameters, and heuristics to assess risk and opportunities — is then adapted with operational parameters as well as vehicle parameters in the DYREQT model to capture mission uncertainty alongside vehicle uncertainty. To perform the range estimation portion of this methodology, the DYREQT model was sampled using a Design of Experiments (DoE) to efficiently explore the architecture design space with respect to the set of uncertainty parameters. Then, the results were used to create surrogate models, multivariate regressions that can visualize hypercube trends in the design space, of the architecture with respect to the uncertainty parameters. Using a correlation matrix constructed for the uncertainty parameters, previously independent samples were transformed to perform a Correlated Monte Carlo on the surrogate models. This probabilistic methodology was proved to provide insight into the underlying uncertainties of the three-element HLS architecture.

Stephanie Y. Zhu↗
NASA NTRSDate not supplied

A Crew and Logistics Lander for the Common Habitat Architecture

The Common Habitat Architecture is a conceptual study that explores the use of a large habitat derived from the Space Launch System (SLS) liquid oxygen tank as a core habitation element that can be used for crew missions or training in 0g, 1/6g, 3/8g, and 1g. This is not part of current NASA Artemis mission planning, but instead represents an architecture that could potentially follow after the Artemis missions and initial human Mars landings. This architecture leverages Starship-derived vehicles for crew landing on and ascent from the Moon and Mars in support of long-duration surface missions with pressurized crew transfer baselined as a nominal capability. This is not the Human Landing System variant of Starship but represents a number of modifications to enable long-duration surface missions with an eight-person crew size. A rapid brainstorming study was conducted in February of 2021, using only public data, to identify options to deliver the 90-ton Common Habitat to the surface and emplace it at the intended habitation site. This study compared three lunar lander concepts and three Mars lander concepts before ultimately selecting the SpaceX Starship as the most viable lander. The Common Habitat Architecture assumes that this Starship variant can further be modified for crew and cargo delivery, assuming that the use of a common system will lead to cost benefits. It is assumed that the Starship will expend too much propellant in landing crew and logistics to be able to launch, given the assumed absence of surface propellant production. Consequently, a separable ascent stage is used for crew ascent. The pressurized elements of this modified Starship are discussed: Starship Ascent Module, Airlock, Transfer Tunnel, Pressurized Crew Transfer Module, and Logistics Modules. For each element, a description, dimensions, rough mass estimates, core capabilities, and design features are presented. Key mechanisms and internal structures of the starship are also discussed. This will include flame diverters for the ascend module, the orbital docking hatch, Pressurized Crew Transfer Module Garage door, Starship Ascent Module fairing, flame diverter blow-out panels, Pressurized Crew Transfer Module lift system, logistics module lift system, contingency crew ascent via the logistics module lift system, internal catwalks, and structural interfaces. Concept of Operations will be discussed for both Moon and Mars. This will include in-space crew rendezvous and transfer, crewed landing, shirtsleeve crew transfer, crew departure, contingency surface operations, and final element disposition. Key differences for Mars will be discussed, such as the Martian atmosphere, dust storms, the absence of crew handover, and Deep Space Exploration Vehicle rendezvous. Contingency microgravity maintenance access will also be discussed. This work will demonstrate viable pressurized crew transfer with a Starship-based lander architecture. Forward work includes Garage lighting and camera systems, Starship Ascent Module propulsion system and docking port trades, contingency habitation trades, and mass/power equipment estimation. Finally, forward work includes developing a heavy cargo return system derived from the Crew and Logistics Starship. The goal of this system is the return of at least 10,000 kg payloads from the surfaces of the Moon and Mars.

Lunar Lander↗
NASA NTRS2024

Key Mars Architecture Decisions

As noted in the 2022 Architecture Concept Review Systems Analysis of Architecture Drivers white paper, exploration architectures are heavily influenced by the order in which driving questions are answered. Decisions in one part of the architecture will ripple through other parts of the architecture and beyond, often in ways that are not intuitively obvious.

Michelle A Rucker↗
NASA NTRSDate not supplied

The International Space Station, Optical Communications, and Delay Tolerant Networking: Towards A Solar System Internet Architecture

As Delay Tolerant Networking (DTN) matures as a software product its use cases have extended to infrastructural and architectural studies, bringing DTN closer to a widespread, operational technology. While it is known that a DTN can be configured, given complete information about a system of nodes, to provision a system with a complete network capability, what remains is to tackle practical considerations such as scalability, networking best practices, and how to establish service providers. In this paper, we document progress towards a scalable DTN architecture that was tested across multiple organizational and project boundaries; our approach was tested across nodes flying on the International Space Station (ISS) connected to a ground network. The network consists of four main network areas: the ISS, the White Sands Complex (WSC), the Mission Cloud Platform (MCP), and NASA’s Huntsville Operations Support Center (HOSC). The connections on the ground (WSC, MCP, and HOSC) are straightforward technically, but represent administrative and non-technical challenges that had to be overcome. The connection from the ISS to WSC was realized through a hybrid optical/RF means. In particular, NASA’s Integrated Laser Communications Relay Demonstration (LCRD) can form a relay from lowEarth-orbit (LEO) to the Earth, and was used in conjunction with the LCRD LEO User Modem and Amplifier Terminal (ILLUMA-T) on the ISS to form a link to one of three geographically diverse ground stations. A major goal was to achieve communications while keeping the ISS nodes unaware of ground station choices and scheduling. These disparate links were networked using High-rate DTN (HDTN), which enabled the desired architecture. The network architecture, tests, HDTN performance metrics, and general observations made are all discussed in detail, including a discussion on the successful utilization of the DTN security standard known as DTN Bundle Protocol Security (BPSec). We conclude with suggestions for next steps, and in particular focus on extending this architecture to the Near Space Network (NSN) and the upcoming LunaNet.

Alan Hylton↗
DOE OSTI2013

Effect of Macromolecular Architecture on the Morphology of Polystyrene Polyisoprene Block Copolymers

The impact of block connectivity on the morphologies of four block copolymers of varying architecture containing polystyrene (PS) and polyisoprene (PI) has been studied. The volume fraction of PS and molecular weight are held constant while varying the architecture from a linear PS-PI diblock copolymer to three different miktoarm star architectures: PS2PI, PSPI2, and PS2PI2. Morphologies of the PS2PI and PSPI2 miktoarm stars are different from those observed for the linear copolymer and dependent on the connectivity of the copolymer blocks. The change in morphology with connectivity indicates that combining two chains at a junction point leads to chain crowding, where subsequent excluded volume effects drive the change in morphology for each sample. The PS2PI2 miktoarm star exhibits the same morphology as the linear diblock but with a reduction in the size of the domains. The extent of the decrease in domain size indicates that chain stretching impacts the formation of this morphology. Experimentally observed morphologies for different chain architectures are generally consistent with three-dimensional self-consistent field theory simulations, taking into account conformational asymmetry and experimental uncertainty in the copolymer composition. Furthermore, these results generally agree with analytical theory predictions that account for architectural and conformational asymmetry.

Kumar, Rajeev↗
DOE OSTI2012

21st Century Computer Architecture

Because most technology and computer architecture innovations were (intentionally) invisible to higher layers, application and other software developers could reap the benefits of this progress without engaging in it. Higher performance has both made more computationally demanding applications feasible (e.g., virtual assistants, computer vision) and made less demanding applications easier to develop by enabling higher-level programming abstractions (e.g., scripting languages and reusable components). Improvements in computer system cost-effectiveness enabled value creation that could never have been imagined by the field's founders (e.g., distributed web search sufficiently inexpensive so as to be covered by advertising links). The wide benefits of computer performance growth are clear. Recently, Danowitz et al. apportioned computer performance growth roughly equally between technology and architecture, with architecture credited with ~80x improvement since 1985. As semiconductor technology approaches its "end-of-the-road" (see below), computer architecture will need to play an increasing role in enabling future ICT innovation. But instead of asking, "How can I make my chip run faster?," architects must now ask, "How can I enable the 21st century infrastructure, from sensors to clouds, adding value from performance to privacy, but without the benefit of near-perfect technology scaling?". The challenges are many, but with appropriate investment, opportunities abound. Underlying these opportunities is a common theme that future architecture innovations will require the engagement of and investments from innovators in other ICT layers.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

System architecture and method of processing data therein

A system architecture encoded on a non-transitory computer readable medium, the system architecture includes a first protocol. The first protocol is configured to receive a plurality of outputs from an ICS used in controlling an industrial system. The first protocol is configured to receive a plurality of inputs from a physical module. The physical module includes at least one of a component, a sensor, or the ICS. Additionally, the system architecture includes a second protocol, wherein the second protocol is configured to validate the plurality of inputs from the first protocol. Moreover, the system architectures includes a third protocol, wherein the third protocol is configured to validate the plurality of outputs from the first protocol. Further, the system architecture includes a fourth protocol, wherein the fourth protocol is configured to manage the ICS based on the second protocol and the third protocol.

Abdel-Khalik, Hany S.↗
DOE OSTI2023

Evaluating Portable Parallelization Strategies for Heterogeneous Architectures in High Energy Physics

High-energy physics (HEP) experiments have developed millions of lines of code over decades that are optimized to run on traditional x86 CPU systems. However, we are seeing a rapidly increasing fraction of floating point computing power in leadership-class computing facilities and traditional data centers coming from new accelerator architectures, such as GPUs. HEP experiments are now faced with the untenable prospect of rewriting millions of lines of x86 CPU code, for the increasingly dominant architectures found in these computational accelerators. This task is made more challenging by the architecture-specific languages and APIs promoted by manufacturers such as NVIDIA, Intel and AMD. Producing multiple, architecture-specific implementations is not a viable scenario, given the available person power and code maintenance issues. The Portable Parallelization Strategies team of the HEP Center for Computational Excellence is investigating the use of Kokkos, SYCL, OpenMP, std::execution::parallel and alpaka as potential portability solutions that promise to execute on multiple architectures from the same source code, using representative use cases from major HEP experiments, including the DUNE experiment of the Long Baseline Neutrino Facility, and the ATLAS and CMS experiments of the Large Hadron Collider. This cross-cutting evaluation of portability solutions using real applications will help inform and guide the HEP community when choosing their software and hardware suites for the next generation of experimental frameworks. We present the outcomes of our studies, including performance metrics, porting challenges, API evaluations, and build system integration.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2024

System architecture and method of processing data therein

A system architecture encoded on a non-transitory computer readable medium, the system architecture includes a first protocol. The first protocol is configured to receive a plurality of outputs from an ICS used in controlling an industrial system. The first protocol is configured to receive a plurality of inputs from a physical module. The physical module includes at least one of a component, a sensor, or the ICS. Additionally, the system architecture includes a second protocol, wherein the second protocol is configured to validate the plurality of inputs from the first protocol. Moreover, the system architectures includes a third protocol, wherein the third protocol is configured to validate the plurality of outputs from the first protocol. Further, the system architecture includes a fourth protocol, wherein the fourth protocol is configured to manage the ICS based on the second protocol and the third protocol.

Abdel-Khalik, Hany S.↗
NASA NTRS2019

Defining a Space Mission Architectural Framework: Guiding Robotic Space Mission Design and Development at NASA Goddard Spaceflight Center

Modern Systems Engineering activities for robotic science missions face increased complexity due to evolving measurement requirements, increased collaboration amongst stakeholders and increased collaboration between human and robotic systems. While NASA has employed standard process frameworks for project management and systems engineering for years, it has not yet established an architecture framework (AF) by which its mission systems are described. While an architecture framework is not a necessary component of an organization's operations, the value of a specified AF greatly enhances an organization's ability to define systems consistently and aid in communication across project and organizational boundaries. The current effort identifies an approach to establishing a Space Mission Architecture Framework (SMAF), an AF with roots in ISO 42010 (Systems and Software Engineering-Architecture Description), NASA Procedural Requirements (NPR) 7120.5 (NASA Space Flight Program and Project Management Requirements) and 7123.1B (NASA Systems Engineering Processes and Requirements). The heart of the AF lies in its viewpoints and work products, artifacts that represent a set of information from the viewpoint of a particular stakeholder. This effort articulates the needs, goals and objectives that the SMAF addresses, as well as the approach to creating the framework and establishing the various work products. A full set of work products, sufficient to satisfy the Mission System reporting requirements of NPR 7120/7123 at Key Decision Point (KDP) A is identified in this paper.

Architecture↗
DOE OSTI2019

Performance portability study for massively parallel computational fluid dynamics application on scalable heterogeneous architectures

Patient-specific hemodynamic simulations have the possibility to greatly improve both the diagnosis and treatment of a variety of vascular diseases. Portability will enable wider adoption of computational fluid dynamics (CFD) applications in the biomedical research community and targeting to platforms ideally suited to different vascular regions. Here, we introduce a case study in performance portability that assesses (1) the ease of porting an MPI application optimized for one specific architecture to new platforms using variants of hybrid MPI+X programming models; (2) performance portability seen when simulating blood flow in three different vascular regions on diverse heterogeneous architectures; (3) model-based performance prediction for future architectures; and (4) performance scaling of the hybrid MPI+X programming on parallel heterogeneous systems. We report on the lessons learned in porting HARVEY, a massively parallel CFD application, from traditional multicore CPUs to diverse heterogeneous architectures ranging from NVIDIA/AMD GPUs to Intel MICs and Altera FPGAs.

97 MATHEMATICS AND COMPUTING↗