Search NASA⌕ Search

SEARCH · Search NASA

Results for “hackathon”

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.

6 records
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Porting OVERFLOW CFD Code to GPUs: To Hackathons and Beyond!

OVERFLOW is an overset, structured computational fluid dynamics (CFD) code written in Fortran which is widely used in the government, industry, and academia. Over the last several years the OVERFLOW developers have been working to port miniapps based on computationally expensive parts of OVERFLOW to run on GPUs, primarily using OpenACC. This effort started at our first hackathon in 2019 and since then the OVERFLOW team has attended two additional hackathons (virtually). These hackathon environments have provided a great place to collaborate with others and learn from experts. These learning experiences enabled porting two miniapps to run effectively on NVIDIA GPUs using OpenACC. The first miniapp focused on motifs found in the solver itself and the final ported version runs three times fast ona single V100 compared to a 40 core, dual-socket Intel Skylake node. The speed up in this solverminiapp required multiple design changes including increasing the amount of parallelism available and the amount of work performed in each kernel. The second miniapp focused on overset MPI communication, also saw significant speedups over the CPU implementation using a CUDA-aware MPI implementation through OpenACC. This presentation will discuss our experience at the hackathons, our process of porting the miniapps to run on the GPUs, and several lessons learned throughout.

OpenACC↗
NASA NTRS2020

NASA GPU Hackathon Yields Significant Code Improvements

The NASA GPU Hackathon 2020 brought together application developers and computer experts to help get important NASA applications running effectively on graphics processing unit (GPU) nodes. Nine teams of application developers participated in this virtual event, a major impetus for teams to modernize codes of interest for NASA missions to CPU nodes containing GPU accelerators, with a focus on hands-on problem solving. The photo in Figure1 shows 30 of the more than50 participants. The HECC project and NVIDIA jointly organized the event, and HECC provided five Pleiades nodes each with 4 V100 GPUs for teams to use. The virtual event, which took place over four days from September 28–October 7, 2020, used Microsoft Teams and Slack as collaboration tools. Each team consisted of three to six members from NASA Centers and supporting organizations. The teams were paired with one to two mentors from industry, government, and academia. The experience levels of the teams ranged from being GPU novices to advanced CUDA programming experts. OpenACC and the emerging Kokkos API were used in addition to CUDA for GPU programming. During the event, which focused on accelerating AeroSciences and CFD applications, most teams achieved considerable performance improvements on both GPUs and CPUs. For example, a team with no GPU experience completed a first port of a time-critical loop to a GPU. Another team of expert CUDA programmers were able to restructure their algorithm, yielding a factor of five speed-up. And another team sped up some of their CUDA kernels by a factor of 20, which directly translated into their production code. This article highlights some of the many successes resulting from the event.

HECC↗
NASA NTRS2022

Turning Limitations into Opportunities in the Development of the Orion Medical System: Incorporation of mHealth Devices

INTRODUCTION: Selection of medical devices for the Orion medical system is a complex task which is dependent on the current state of terrestrial technology. In this work we review the interplay between NASA requirements, constraints, and opportunities for synergy during the development of the Orion medical system. METHODS: The “plan to treat” list of conditions, and subsequently the medical resource list for the Orion Artemis II lunar flyby mission was completed using semi-quantitative methods. During this process, some medical resources were excluded to comply with mass and volume limits, while other resources applicable to multiple medical requirements were prioritized for inclusion. Choices were also examined considering NASA level of care standards for the Artemis design reference missions. As a means to optimize capabilities in spite of mass and volume constraints, ideas for integration of multiple devices into a single platform were explored, including a ‘hackathon’ challenge which was conducted to generate and evaluate concepts for combining medical devices into a single app-based mobile device (ultrasound, ECG, etc.). RESULTS: The Orion team identified 128 medical conditions that we “plan to treat”, with 139 unique medical resources to address these conditions, including 5 digital diagnostic devices (ECG, otoscope, stethoscope, pulse oximeter, and blood pressure monitor). During selection of these digital devices the team noted that miniaturized medical devices often use mobile device platforms (mHealth), some displaying and transmitting data exclusively via mobile device. Of the 5 initially selected devices, all are capable of mobile connection, one which cannot function without a mobile device (ECG). Furthermore, only one of these devices connects natively to a Windows platform, which is currently the only operating system available on Orion. DISCUSSION: Significant savings in mass and volume as well as training and usability improvements can be achieved by leveraging mHealth technologies. However, the platform presents significant challenges for deployment within the Artemis Program including lack of internet connectivity, incompatible operating systems, and radiation concerns. Each of these drawbacks are surmountable with investment in the supporting vehicle architecture, which may become necessary to support the technology trends seen in commercially available medical devices today. Objective: Learn about the opportunities and challenges of leveraging mHealth devices in the development of medical capabilities for austere environments. Learn about the constraints of the NASA spaceflight environment with regards to digital medical device integration.

Douglas Ebert↗
NASA NTRSDate not supplied

Options for Offloading a 90-Ton Common Habitat from its Lander on the Surface of Mars

The Common Habitat is a large, long-duration habitat being explored as part of a conceptual study (not an active NASA program) that uses an SLS core stage liquid oxygen (LOX) tank as its primary structure. Measuring 8.4 meters in diameter and 15.6 meters in length, it is manufactured as a habitat and launched as such into space. It is intended for use on the Moon as part of a permanently occupied outpost, on Mars as part of an outpost that will be occupied for hundreds of days at a time, and in deep space as part of the Deep Space Exploration Vehicle where it will support crewed missions up to 1200 days in duration. A study of internal orientation and crew size resulted in a Common Habitat configuration sized for a crew of eight with a three-deck horizontal orientation. There are obvious challenges associated with the delivery of such a large habitat, which may mass as much as 90-tons when initially deployed. The Mars destination in particular imposes extreme challenges due to Martian gravity. This paper identifies initial options for the offloading of a 90-ton Common Habitat from a lander spacecraft on the surface of Mars. On Mars, the Common Habitat is part of a surface outpost where a Habitation Zone includes the Common Habitat docked to a two-chamber airlock node, up to two logistics modules, and up to two pressurized rovers. It is connected by underground conduit to a radiator farm and communications tower assembly. These elements and other surface infrastructure, including robotic systems for surface preparation, are landed prior to the Common Habitat. In the baseline Common Habitat Architecture, the Common Habitat is delivered on the third heavy cargo flight. The Habitation Zone configuration dictates that the Common Habitat needs to be offloaded from the lander. All of the docked elements require direct access to the surface and the Common Habitat must actually be placed in a trench to lower its docking ports to be level with those of the mated elements. Additionally, the habitat must be emplaced in a horizontal configuration, while for any conceivable Earth launch system it must be launched in a vertical configuration. It is true that the Common Habitat must be offloaded from its lander on both the Moon and Mars and a common offloading system must therefore work in both destinations. Mars, however, is considered the driving case for offloading in most, but not all, aspects. A four-day internal study in 2021 recommended that a modified Starship be used to land the Common Habitat on Mars and considered multiple approaches to offload the Common Habitat from the payload section and lower it to the surface. The topic was presented at a public hackathon organized by the Johnson Space Center’s Emerge Employee Resource Group. One team took on the challenge and proposed a concept in some ways similar to the previously considered jib crane. Despite the excellent innovation in the team’s work, a number of study refinements are necessary to truly establish feasibility. These and other future work needed to mature the concept are discussed in this work.

Lander Offloading↗
NASA NTRSDate not supplied

A Crew Seat for Human Exploration in Multiple Gravity Environments

This work attempts to develop a single crew seating solution that is applicable across a range of gravity environments encountered by spacecraft proposed in several conceptual spacecraft architectures. All of these spacecraft will need to provide some sort of stationary accommodation for the crew for performing various activities such as work in science laboratories, maintenance and repair facilities, medical care facilities, and spacecraft operations centers, as well as for basic habitation in crew quarters, entertainment / relaxation facilities, and crew dining facilities. Depending on the spacecraft or architecture, this stationary accommodation may be experienced continuously in microgravity, such as would be the case for the Deep Space Exploration Vehicle. Alternately, it could be in continuous lunar or Martian gravity, such as the Common Habitat base camps. It could experience fractional gravity, such as a Pressurized Rover for In-Space Missions at a Near Earth Asteroid or one of the Martian moons. It could alternate between artificial gravity and microgravity, such as the Nautilus-X. It could alternate between microgravity and lunar or Martian gravity, such as the SpaceX Starship Human Landing System or the Blue Origin Blue Moon Block 2 Human Landing System. Or it could be in continuous Earth gravity, such as ground trainer systems. Prior human spaceflight systems for stationary accommodation have been focused on microgravity applications. These systems have their own limitations and cannot be used in a gravity environment. A public crowdsourcing campaign generated dozens of ideas, which ultimately generated a Gecko Mobility Aids system for crew translation and the Multi-Gravity Crew Seat (MGCS) for stationary accommodation. The MGCS functions in gravity as a traditional terrestrial seat, performing functions of load for the overall body and forearms, as well as head and neck load relief while positioning the body within range of an intended task. In microgravity, the MGCS functions as a body restraint, securing the body against inadvertent drifting by applying a restraining pressure at the front and back of the thighs, shoulders, and back. The initial MGCS concept was developed in a NASA hackathon and was refined through a review of dozens of terrestrial seating styles. Additionally, a review of anthropometry and biomechanics data related to the neutral body posture was conducted to help inform the microgravity configuration of the MGCS. A series of CAD models were iteratively developed, with subject matter expert reviews leading to design improvements. A scale model was constructed and used with a humanoid model to demonstrate MGCS accommodation of a human-like body in both gravity and microgravity modes. Work to develop a full-scale protype of the MGCS is discussed, including design and fabrication of the headrest, arm rest, seat back, seat pan, seat base, and the conversion mechanisms. A 1-g human-in-the-loop evaluation of the prototype assessed the acceptability of performing seated activities in the MGCS, collecting data on the usability, comfort, and ease of ingress/egress. Based on the evaluation results, design modifications needed for reduced gravity testing are documented and initial work is indicated for a reduced gravity test plan.

Restraints and Mobility Aids↗