Search NASA⌕ Search

SEARCH · Search NASA

Results for “shared control”

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 289 records · Page 16

Implementation Challenges for Multivariable Control: What You Did Not Learn in School

Multivariable control allows controller designs that can provide decoupled command tracking and robust performance in the presence of modeling uncertainties. Although the last two decades have seen extensive development of multivariable control theory and example applications to complex systems in software/hardware simulations, there are no production flying systems aircraft or spacecraft, that use multivariable control. This is because of the tremendous challenges associated with implementation of such multivariable control designs. Unfortunately, the curriculum in schools does not provide sufficient time to be able to provide an exposure to the students in such implementation challenges. The objective of this paper is to share the lessons learned by a practitioner of multivariable control in the process of applying some of the modern control theory to the Integrated Flight Propulsion Control (IFPC) design for an advanced Short Take-Off Vertical Landing (STOVL) aircraft simulation.

Garg, Sanjay↗

Cooperative Data Sharing: Simple Support for Clusters of SMP Nodes

Libraries like PVM and MPI send typed messages to allow for heterogeneous cluster computing. Lower-level libraries, such as GAM, provide more efficient access to communication by removing the need to copy messages between the interface and user space in some cases. still lower-level interfaces, such as UNET, get right down to the hardware level to provide maximum performance. However, these are all still interfaces for passing messages from one process to another, and have limited utility in a shared-memory environment, due primarily to the fact that message passing is just another term for copying. This drawback is made more pertinent by today's hybrid architectures (e.g. clusters of SMPs), where it is difficult to know beforehand whether two communicating processes will share memory. As a result, even portable language tools (like HPF compilers) must either map all interprocess communication, into message passing with the accompanying performance degradation in shared memory environments, or they must check each communication at run-time and implement the shared-memory case separately for efficiency. Cooperative Data Sharing (CDS) is a single user-level API which abstracts all communication between processes into the sharing and access coordination of memory regions, in a model which might be described as "distributed shared messages" or "large-grain distributed shared memory". As a result, the user programs to a simple latency-tolerant abstract communication specification which can be mapped efficiently to either a shared-memory or message-passing based run-time system, depending upon the available architecture. Unlike some distributed shared memory interfaces, the user still has complete control over the assignment of data to processors, the forwarding of data to its next likely destination, and the queuing of data until it is needed, so even the relatively high latency present in clusters can be accomodated. CDS does not require special use of an MMU, which can add overhead to some DSM systems, and does not require an SPMD programming model. unlike some message-passing interfaces, CDS allows the user to implement efficient demand-driven applications where processes must "fight" over data, and does not perform copying if processes share memory and do not attempt concurrent writes. CDS also supports heterogeneous computing, dynamic process creation, handlers, and a very simple thread-arbitration mechanism. Additional support for array subsections is currently being considered. The CDS1 API, which forms the kernel of CDS, is built primarily upon only 2 communication primitives, one process initiation primitive, and some data translation (and marshalling) routines, memory allocation routines, and priority control routines. The entire current collection of 28 routines provides enough functionality to implement most (or all) of MPI 1 and 2, which has a much larger interface consisting of hundreds of routines. still, the API is small enough to consider integrating into standard os interfaces for handling inter-process communication in a network-independent way. This approach would also help to solve many of the problems plaguing other higher-level standards such as MPI and PVM which must, in some cases, "play OS" to adequately address progress and process control issues. The CDS2 API, a higher level of interface roughly equivalent in functionality to MPI and to be built entirely upon CDS1, is still being designed. It is intended to add support for the equivalent of communicators, reduction and other collective operations, process topologies, additional support for process creation, and some automatic memory management. CDS2 will not exactly match MPI, because the copy-free semantics of communication from CDS1 will be supported. CDS2 application programs will be free to carefully also use CDS1. CDS1 has been implemented on networks of workstations running unmodified Unix-based operating systems, using UDP/IP and vendor-supplied high- performance locks. Although its inter-node performance is currently unimpressive due to rudimentary implementation technique, it even now outperforms highly-optimized MPI implementation on intra-node communication due to its support for non-copy communication. The similarity of the CDS1 architecture to that of other projects such as UNET and TRAP suggests that the inter-node performance can be increased significantly to surpass MPI or PVM, and it may be possible to migrate some of its functionality to communication controllers.

DiNucci, David C.↗

Development of a helicopter rotor/propulsion system dynamics analysis

A time-domain analysis of coupled engine/drive train/rotor dynamics of a twin-engine, single main rotor helicopter model has been performed. The analysis incorporates an existing helicopter model with nonlinear simulations of a helicopter turboshaft engine and its fuel controller. System dynamic behavior is studied using the resulting simulation which included representations for the two engines and their fuel controllers, drive system, main rotor, tail rotor, and aircraft rigid body motions. Time histories of engine and rotor RPM response to pilot control inputs are studied for a baseline rotor and propulsion system model. Sensitivity of rotor RPM droop to fuel controller gain changes and collective input feed-forward gain changes are studied. Torque-load-sharing between the two engines is investigated by making changes in the fuel controller feedback paths. A linear engine model is derived from the nonlinear engine simulation and used in the coupled system analysis. This four-state linear engine model is then reduced to a three-state model. The effect of this simplification on coupled system behavior is shown.

Warmbrodt, W.↗

SIM testbed 3 real-time control software

SIM System Testbed 3 (STB3) features three optical interferometers sharing a common baseline, as a dynamic representation of the SIM instrument. An artificial star feeding the interferometers is installed on a separate optics bench. All three interferometers use photons captured by avalanche photo diodes (APDs) to measure the position and quality of fringes, and additional pointing precision is achieved by fast steering mirrors (FSMs) that keep the star images centered on the beam combining optics using a CCD camera. Each interferometer uses internal metrology to measure changes in its optical pathlength. External metrology beams measure changes in the baseline vector. This system acquires and tracks white light fringes with one interferometer, while the other two acquire and track laser light fringes representing the bright guide stars that will be used by SIM. The white light source represents a dim star that cannot supply enough photons for the Science interferometer to lock onto fringes in closed-loop mode; instead it operates open-loop, using pathlength corrections fed to it from the two guide interferometers and the external metrology subsystem to reject disturbances and maintain the fringes. This tracking mode is known as Pathlength Feed Forward (PFF). The precise real-time behavior required to achieve this result is implemented by a complex set of interacting software control loops. This paper describes how these loops take advantage of the benefits of the RTC Core architecture, and how they work together to accomplish STB3's objectives.

interferometry↗

A contention-based bus-control scheme for multiprocessor systems

The authors study contention-based bus-control schemes for scheduling processors in using a bit-parallel shared bus. The protocol is designed under the requirements that each processor exhibit a random access behavior, that there be no centralized bus control in the system, and that access be granted in real time. The proposed scheme is based on splitting algorithms used in conventional contention-resolution schemes, and utilizes two-state information obtained from collision detection. Two versions of the bus-control scheme are studied. The static one resolves contentions of N requesting processors in an average of O(logW/2N) iterations, where W is the number of bits in the bit-parallel bus. An adaptive version resolves contentions in an average time that is independent of N.

Juang, Jie-Yong↗

The Integrated Mode Management Interface

Mode management is the processes of understanding the character and consequences of autoflight modes, planning and selecting the engagement, disengagement and transitions between modes, and anticipating automatic mode transitions made by the autoflight system itself. The state of the art is represented by the latest designs produced by each of the major airframe manufacturers, the Boeing 747-400, the Boeing 777, the McDonnell Douglas MD-11, and the Airbus A320/A340 family of airplanes. In these airplanes autoflight modes are selected by manipulating switches on the control panel. The state of the autoflight system is displayed on the flight mode annunciators. The integrated mode management interface (IMMI) is a graphical interface to autoflight mode management systems for aircraft equipped with flight management computer systems (FMCS). The interface consists of a vertical mode manager and a lateral mode manager. Autoflight modes are depicted by icons on a graphical display. Mode selection is accomplished by touching (or mousing) the appropriate icon. The IMMI provides flight crews with an integrated interface to autoflight systems for aircraft equipped with flight management computer systems (FMCS). The current version is modeled on the Boeing glass-cockpit airplanes (747-400, 757/767). It runs on the SGI Indigo workstation. A working prototype of this graphics-based crew interface to the autoflight mode management tasks of glass cockpit airplanes has been installed in the Advanced Concepts Flight Simulator of the CSSRF of NASA Ames Research Center. This IMMI replaces the devices in FMCS equipped airplanes currently known as mode control panel (Boeing), flight guidance control panel (McDonnell Douglas), and flight control unit (Airbus). It also augments the functions of the flight mode annunciators. All glass cockpit airplanes are sufficiently similar that the IMMI could be tailored to the mode management system of any modern cockpit. The IMMI does not replace the functions of the FMCS control and display unit. The purpose of the INMI is to provide flight crews with a shared medium in which they can assess the state of the autoflight system, take control actions on it, reason about its behavior, and communicate with each other about its behavior. The design is intended to increase mode awareness and provide a better interface to autoflight mode management. This report describes the IMMI, the methods that were used in designing and developing it, and the theory underlying the design and development processes.

Hutchins, Edwin↗

Airport Information Sharing Concept Architecture

The National Airspace System (NAS) Air Traffic management, control and operation depends on a timely and efficient distribution of real time information generated by stakeholders and published from a variety of sources. The Federal Aviation Administration System Wide Information Management (SWIM) is a service oriented architecture design to provide stakeholders with timely NAS information. However, there are other sources of useful information generated by stakeholders that can be included in the management of NAS operations. Airport facilities are host to most stakeholders operating in the NAS (airspace user, airport authority, ground handling, controller tower) and thus large information is generated and consumed at these facilities. The NASA Glenn Research center has been investigating an information exchange architecture framework that would enable the timely, efficient and secure gathering and distribution information generated at airport facilities. This presentation describes the framework architecture concept for the efficient information exchange of airport information.

Airports↗

The distributed virtual windtunnel

An implementation of a distributed virtual environment for the shared interactive visualization of large unsteady three-dimensional flowfields is described. Computation of the visualizations is performed on a Convex C3240 computer, and the visualization data are transferred over a high-speed network to a Silicon Graphics Iris workstation for rendering. A boom-mounted six-degree-of-freedom head-position-sensitive stereo CRT (cathode ray tube) system is used for display. A hand-position-sensitive glove controller is used for controlling various tracers for the visualization of the flow. User commands are sent to the Convex, which interprets these commands and computes the corresponding visualization. With this architecture, several users may share and cooperatively control the visualization generated by the Convex. The distributed architecture is also interesting to those using conventional screen and mouse interfaces.

Bryson, Steve↗

Uncrewed Lunar Surface Operations and Support Activities

Sustained human presence on the surface of the Moon and future missions to Mars require increased independence from surface crews and Earth-based mission control to operate efficiently, safely, and reliably. The time for surface crews to perform tasks will be limited. Extravehicular activities by surface personnel are burdensome and time-consuming, even when a continuous human presence on the surface occurs. Identifying and balancing human/automation roles and tasks and infusing automation and autonomy practices early in a system’s lifecycle will be essential to achieve mission objectives. Among these objectives are attaining a sustained human presence, improving performance and mission effectiveness, reducing operations and maintenance (O&M) costs, and ensuring operations that are robust to communication delays. To achieve these objectives, an operational shift toward increased automation and autonomy with less reliance on humans is needed. Uncrewed lunar surface operations and support activities occur when surface crews are not present or are independent of surface crew timeline activities requiring no surface crew oversight or intervention. These uncrewed surface opportunities can also be planned to minimize crew workload that avoids routine maintenance and support tasks, thus maximizing crew exploration time. Uncrewed preparations such as staging and prepositioning equipment and materials before the crew arrives could improve crew task efficiency. Additional opportunities exist to conduct uncrewed science, exploration, and utilization. Uncrewed surface architecture functions can include science and exploration; habitation; launch and landing support; surface communication and navigation; surface power generation and distribution; human surface mobility; lifting, handling, manipulating; excavation, construction, and site preparation; logistics management; maintenance and repair; surface resource utilization; integrated site operations and shared support services (e.g., site scheduling/prioritization, dust mitigation/contamination control, and surface safety). Early robotic lunar surface campaigns will provide information on the availability of resources, such as oxygen and water, and demonstrate surface-based technologies. After the Artemis III human lunar return mission, a series of landers will deliver surface systems, cargo, supplies, science packages, spare parts, and commodities. A balance of crewed and uncrewed surface operations will enable a sustained lunar surface presence at the South Pole of the Moon at a site that will be known as the Artemis Base Camp (ABC). It is envisioned that base camp operations on and around the Moon will then help prepare for the mission durations and activities needed to support the first human mission to Mars. Before long-duration crew missions to the base camp can occur, the necessary surface infrastructure will be pre-deployed and verified operational. Surface assets will be teleoperated and remotely managed from Earth. Additionally, robotic and short-duration crewed missions to the ABC will ensure the site’s merit to achieve long-term science objectives, availability of usable resources, and that terrain, seasonal variations, and illumination conditions are acceptable. ABC will consist of different areas where specific functions and services are rendered, including: • Launch and Landing Area • Habitation Area • Power Production Area • Resource Areas Launch and Landing Area—The launch and landing area will support associated functions for the arrival and departure of vehicles, such as crewed landing and ascent and uncrewed cargo deliveries and offloading. It will evolve from an unimproved site at the beginning of the exploration campaign to a more sustainable landing and launch area that can support repeated arrivals and departures. Initial uncrewed Lunar Terrain Vehicle (LTV) surface operations may include emplacement of navigation beacons and communication equipment, real-time video and photography of landing/liftoff events, and element repositioning, such as portable utility power (PUP) (applicable for other landed assets at other areas). Site preparations, such as surface leveling, soil compaction, and berm/path construction, may be needed for a more sustainable launch and landing area capable of accommodating vehicles that are increasingly more reusable and reduce the effects of plume surface interactions and ejecta impacts on nearby surface assets. During the ABC missions, cargo and logistics will be delivered to the lunar surface via robotic cargo landers before the crew arrives. These shipments, which can arrive in pressurized logistics carriers, will deliver the logistics necessary to support a crewed mission and include items such as food, water, equipment spares, etc. Providing the capability to retrieve, offload, and transport the logistics closer to the ABC site before the arrival of the crew will increase the overall efficiency of crew operations once they arrive. In the sustained phase of exploration, other supporting services may be needed, such as lander propellant servicing, surface power services, commodity refreshes, and additional inspection, maintenance, and repair capabilities, to sustain a cadence of extended personnel stays and cargo arrivals and departures. Habitation Area—Uncrewed support to surface habitation could involve supporting activation and pre-entry operations of the habitat while the crew is in orbit at the Gateway outpost preparing for a surface landing. Surface Habitat (SH) uncrewed operations may include bringing the cabin environment to a habitable temperature and air mix and activating other critical crew support systems. Potential crop production uncrewed tasks in the SH could also include autonomous watering and tending. Additionally, when the crew departs, the SH enters dormancy for the long period of uncrewed operation. A logistical staging area could also be collocated near the SH. If so, staging operations for crew supplies, waste re-location, and recycling operations may be opportunities for uncrewed operations. Power Production Area—The Fission Surface Power (FSP) element and its supporting distribution equipment provide power to surface elements as needed across the ABC to supplement day-to-day operations and survive lunar nights. Uncrewed support of this power system includes any initial LTV-assisted deployments of cables and other distributed equipment, associated electrical connections, and system testing and activation operations. Robotically performing some inspections, maintenance, or repair tasks on the power distribution equipment could reduce the surface crew workload. Resource Area— Uncrewed resource prospecting, mapping, and characterizing possible resource sites is likely to be time-consuming and represents an opportunity for uncrewed operations between crewed missions. Uncrewed mobile equipment operations will be needed in the extreme environments of permanently shadowed locations where resource extractions occur. As In-Situ Resource Utilization (ISRU) pilot plant operations begin, uncrewed surface support activities with available mobile and portable assets (LTV, PUP, etc.) will better support these operations. Any produced commodities can be stored at a centralized storage location for future use. Also associated with these operations is the use of mobile robotic excavators for resource acquisition and robotic/autonomous regolith processing. The waste tailings generated during excavation and regolith processing would also need to be transported and deposited at a dedicated location. Surface assets will continue operating between crew visits to maintain surface capabilities, conduct lunar surface science, technology demonstrations, and public outreach opportunities. Additionally, certain sustaining tasks that would consume valuable crew time could be performed before crew arrival, or after their departure. This capability may offer more affordable options to construct, activate, test, and maintain a broad set of surface assets. Telerobotically operated human surface mobility systems, such as the LTV and Pressurized Rover (PR), can be utilized for various tasks. Surface environmental conditions pose a distinct challenge for all these activities. Surface illumination and localized shadows are one such factor. Night-survival operations could consist of thermal management, battery pre-charging, and load shedding. Some surface systems may hibernate through the night and then awake and continue nominal operations. Uncrewed mobile assets may use a more adaptive approach to optimize their power and operations; one method is to follow the sunlight. Night-survival operations may be initiated remotely by teleoperation, automated, or accomplished by supervised autonomous operation. The ability to pre-deploy and control remote assets in orbit or on Mars before the arrival of the mission crew is a key capability that can be simulated on the moon. The base camp provides a venue where these advanced operational concepts, technologies, and autonomous methods and techniques, including the incorporation of time delays to simulate Earth-Mars latency can be replicated to help buy down future Mars mission risks. This paper will examine the evolution of uncrewed lunar surface operations and support activities. It will also discuss the lunar surface environmental conditions (thermal, lighting, terrain, topography, communications) along with the challenges they pose on uncrewed surface operations, and the performance of these activities with limited to minimal human interaction and/or teleoperation. Since lunar missions include Mars mission analogs, such investigation provides the framework for future uncrewed Mars mission support.

Mark E Lewis↗

The D3 Middleware Architecture

DARWIN is a NASA developed, Internet-based system for enabling aerospace researchers to securely and remotely access and collaborate on the analysis of aerospace vehicle design data, primarily the results of wind-tunnel testing and numeric (e.g., computational fluid-dynamics) model executions. DARWIN captures, stores and indexes data; manages derived knowledge (such as visualizations across multiple datasets); and provides an environment for designers to collaborate in the analysis of test results. DARWIN is an interesting application because it supports high-volumes of data. integrates multiple modalities of data display (e.g., images and data visualizations), and provides non-trivial access control mechanisms. DARWIN enables collaboration by allowing not only sharing visualizations of data, but also commentary about and views of data. Here we provide an overview of the architecture of D3, the third generation of DARWIN. Earlier versions of DARWIN were characterized by browser-based interfaces and a hodge-podge of server technologies: CGI scripts, applets, PERL, and so forth. But browsers proved difficult to control, and a proliferation of computational mechanisms proved inefficient and difficult to maintain. D3 substitutes a pure-Java approach for that medley: A Java client communicates (though RMI over HTTPS) with a Java-based application server. Code on the server accesses information from JDBC databases, distributed LDAP security services, and a collaborative information system. D3 is a three tier-architecture, but unlike 'E-commerce' applications, the data usage pattern suggests different strategies than traditional Enterprise Java Beans - we need to move volumes of related data together, considerable processing happens on the client, and the 'business logic' on the server-side is primarily data integration and collaboration. With D3, we are extending DARWIN to handle other data domains and to be a distributed system, where a single login allows a user transparent access to test results from multiple servers and authority domains.

Walton, Joan↗

Hybrid classical-quantum communication networks

Over the past several decades, the proliferation of global classical communication networks has transformed various facets of human society. Concurrently, quantum networking has emerged as a dynamic field of research, driven by its potential applications in distributed quantum computing, quantum sensor networks, and secure communications. This prompts a fundamental question: rather than constructing quantum networks from scratch, can we harness the widely available classical fiber-optic infrastructure to establish hybrid quantum–classical networks? This paper aims to provide a comprehensive review of ongoing research endeavors aimed at integrating quantum communication protocols, such as quantum key distribution, into existing lightwave networks. This approach offers the substantial advantage of reducing implementation costs by allowing classical and quantum communication protocols to share optical fibers, communication hardware, and other network control resources—arguably the most pragmatic solution in the near term. In the long run, classical communication will also reap the rewards of innovative quantum communication technologies, such as quantum memories and repeaters. Accordingly, our vision for the future of the Internet is that of heterogeneous communication networks thoughtfully designed for the seamless support of both classical and quantum communications.

Fiber-optic communication↗

STS-92 Crew Interview - Wakata

STS-92 Mission Specialist Koichi Wakata is interviewed. He answers questions about his inspiration to become an astronaut, his training, and gives details on the mission, including overviews of the ZI truss, the S-band antenna, the third pressurized mating adapter (PMA-3), the common berthing mechanism, and his part in controlling the robotic arm during the spacewalks. He shares his thoughts on Russia's contribution to the International Space Station (ISS), the role of STS-92 in preparing the ISS for its first resident crew, and the importance of ISS in the future.

Source record↗

Building a Propulsion Experiment Project Management Environment

What do you get when you cross rocket scientists with computer geeks? It is an interactive, distributed computing web of tools and services providing a more productive environment for propulsion research and development. The Rocket Engine Advancement Program 2 (REAP2) project involves researchers at several institutions collaborating on propulsion experiments and modeling. In an effort to facilitate these collaborations among researchers at different locations and with different specializations, researchers at the Information Technology and Systems Center,' University of Alabama in Huntsville, are creating a prototype web-based interactive information system in support of propulsion research. This system, to be based on experience gained in creating similar systems for NASA Earth science field experiment campaigns such as the Convection and Moisture Experiments (CAMEX), will assist in the planning and analysis of model and experiment results across REAP2 participants. The initial version of the Propulsion Experiment Project Management Environment (PExPM) consists of a controlled-access web portal facilitating the drafting and sharing of working documents and publications. Interactive tools for building and searching an annotated bibliography of publications related to REAP2 research topics have been created to help organize and maintain the results of literature searches. Also work is underway, with some initial prototypes in place, for interactive project management tools allowing project managers to schedule experiment activities, track status and report on results. This paper describes current successes, plans, and expected challenges for this project.

Keiser, Ken↗

Considerations for Isochronous Data Services for the Proximity-1 Space Link

Isochronous means "having equal time difference". The term Isochronous describes a system where the time difference between arrival and departure of data is constant. However, one can also consider degrees of "isochronicity" by measuring the consistency in the latency of a system. Deterministic systems (such as TDMA) has higher degree of isochronous property because resource assignments are static. For system that dynamically shares resources, variations in latency can still be controlled. Proximity-1 is not a deterministic protocol in the sense that it does not designate specific time slots to the transmissions of data and control messages. However, is it still sufficiently isochronous for carrying real-time traffic?

real time↗

Enhanced Multi-Modal Access to Planetary Exploration

Tomorrow's Interplanetary Network (IPN) will evolve from JPL's Deep-Space Network (DSN) and provide key capabilities to future investigators, such as simplified acquisition of higher-quality science at remote sites and enriched access to these sites. These capabilities could also be used to foster public interest, e.g., by making it possible for students to explore these environments personally, eventually perhaps interacting with a virtual world whose models could be populated by data obtained continuously from the IPN. Our paper looks at JPL's approach to making this evolution happen, starting from improved communications. Evolving space protocols (e.g., today's CCSDS proximity and file-transfer protocols) will provide the underpinning of such communications in the next decades, just as today's rich web was enabled by progress in Internet Protocols starting from the early 1970's (ARPAnet research). A key architectural thrust of this effort is to deploy persistent infrastructure incrementally, using a layered service model, where later higher-layer capabilities (such as adaptive science planning) are enabled by earlier lower-layer services (such as automated routing of object-based messages). In practice, there is also a mind shift needed from an engineering culture raised on point-to-point single-function communications (command uplink, telemetry downlink), to one in which assets are only indirectly accessed, via well-defined interfaces. We are aiming to foster a 'community of access' both among space assets and the humans who control them. This enables appropriate (perhaps eventually optimized) sharing of services and resources to the greater benefit of all participants. We envision such usage to be as automated in the future as using a cell phone is today - with all the steps in creating the real-time link being automated.

interplanetary network (IPN)↗

The NASA Ames Life Sciences Data Archive: Biobanking for the Final Frontier

The NASA Ames Institutional Scientific Collection involves the Ames Life Sciences Data Archive (ALSDA) and a biospecimen repository, which are responsible for archiving information and non-human biospecimens collected from spaceflight and matching ground control experiments. The ALSDA also manages a biospecimen sharing program, performs curation and long-term storage operations, and facilitates distribution of biospecimens for research purposes via a public website (https:lsda.jsc.nasa.gov). As part of our best practices, a tissue viability testing plan has been developed for the repository, which will assess the quality of samples subjected to long-term storage. We expect that the test results will confirm usability of the samples, enable broader science community interest, and verify operational efficiency of the archives. This work will also support NASA open science initiatives and guides development of NASA directives and policy for curation of biological collections.

Biobank↗

Performance Optimization Methods for a Memory-Bound, Unstructured-Grid CFD Application on Massively Parallel GPU Platforms

Computational performance of the FUN3D unstructured-grid computational fluid dynamics (CFD) application on massively parallel GPU environments is memory-bound and highly dependent upon efficient reads from and atomic updates to the irregular cell-, edge-, and node-based data structures. In this talk, we present recent efforts into optimizing select performance-critical kernels on NVIDIA Tesla V100 and A100 GPUs and AMD CDNA MI100 GPUs. A novel use of L2 cache residency controls and asynchronous loads into on-chip shared memory are explored on the A100 GPU for the sparse iterative solver, which is dominated by mixed-precision, sparse matrix vector multiplication. Demonstrations show that these methods improve global memory bandwidth utilization by 13.5% on the A100 GPU. Several techniques are also presented that use registers and/or shared memory to facilitate array transposition and aggregation which combine to reduce the frequency and increase the cache efficiency of floating-point atomic updates to the irregular data structures. These methods are demonstrated to improve the kernel throughput by nearly 500% on select kernels on the AMD MI100 over atomic updates directly to global memory. Overall, both V100 and A100 GPUs outperformed the MI100 GPU on kernels dominated by double-precision atomic updates; however, the techniques demonstrated here reduced the performance gap and improved the MI100 performance.

GPU CPU unstructured CFD memory↗

INTERMARS: User-controlled international management system

Existing international space law as well as the best interest of all nations are consistent with the establishment of a user-based international organization, herein called INTERMARS. INTERMARS would provide access to facilities and services at a Martian base which would be of high functional potential, quality, safety, and reliability. These opportunities would be available on an open and nondiscriminatory basis to all peaceful users and investors. INTERMARS is a model organization concept tailored to provide cooperative international management of a Martian base for the benefit of its members, users, and investors. Most importantly, INTERMARS would provide such management through a sharing of both sovereignty and opportunity rather then unilateral control by any one nation or set of competing nations. Through an Assembly of Parties, a Board of Governors, a Board of Users and Investors, and a Director General, INTERMARS would meet its primary goal as it would be in the self-interest of all members, users, and investors to do so. The internal structure and philosophy of INTERMARS would provide not only for all participants to have representation in decisions affecting its activities, but also would insure effective and responsive management. Surely this is the precedent wished for, to establish for mankind at the now not-so-distant shores of the new ocean of space.

Schmitt, Harrison H.↗