Search NASA⌕ Search

SEARCH · Search NASA

Results for “reference language”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Space-Based Reconfigurable Software Defined Radio Test Bed Aboard International Space Station

The National Aeronautical and Space Administration (NASA) recently launched a new software defined radio research test bed to the International Space Station. The test bed, sponsored by the Space Communications and Navigation (SCaN) Office within NASA is referred to as the SCaN Testbed. The SCaN Testbed is a highly capable communications system, composed of three software defined radios, integrated into a flight system, and mounted to the truss of the International Space Station. Software defined radios offer the future promise of in-flight reconfigurability, autonomy, and eventually cognitive operation. The adoption of software defined radios offers space missions a new way to develop and operate space transceivers for communications and navigation. Reconfigurable or software defined radios with communications and navigation functions implemented in software or VHDL (Very High Speed Hardware Description Language) provide the capability to change the functionality of the radio during development or after launch. The ability to change the operating characteristics of a radio through software once deployed to space offers the flexibility to adapt to new science opportunities, recover from anomalies within the science payload or communication system, and potentially reduce development cost and risk by adapting generic space platforms to meet specific mission requirements. The software defined radios on the SCaN Testbed are each compliant to NASA's Space Telecommunications Radio System (STRS) Architecture. The STRS Architecture is an open, non-proprietary architecture that defines interfaces for the connections between radio components. It provides an operating environment to abstract the communication waveform application from the underlying platform specific hardware such as digital-to-analog converters, analog-to-digital converters, oscillators, RF attenuators, automatic gain control circuits, FPGAs, general-purpose processors, etc. and the interconnections among different radio components.

Communications↗
DOE OSTI2021

Enhancing the Useability of the IAEA's Physical Model: An Analysis of User Feedback

This study presents the results of Physical Model user interviews conducted with 12 people who have International Atomic Energy Agency (IAEA) safeguards experience. The goal of this report is to provide additional context for policy makers when prioritizing the needs of the IAEA regarding support for enhancements to the Physical Model. The interviews covered the general usability of the Physical Model, its effectiveness as a technical reference, and the scope and utility of the Physical Model's indicators and content. The key conclusions from these interviews are as follows: 1) The Physical Model is difficult to find and not well advertised. 2) The Physical Model can be difficult to use due to its format, which makes searching for information difficult, and lack of visual content. Therefore, the Physical Model should be supported in multiple formats (print, PDF, web) to maximize its usability for different stakeholders. 3) The scope of the Physical Model's content and indicators is likely sufficient, and translating indicators into other languages is unlikely to be worth the effort. 4) Despite its inefficiencies and other issues, the Physical Model in its current form is a vital (albeit under-utilized) resource for key stakeholders. 5) Despite its broad use case the Physical Model is not a catch-all tool and force-fitting the Physical Model into functions for which it has not been designed for would likely diminish its value. 6) It can be difficult to disentangle challenges related to the Physical Model and its usability from broader challenges at the Agency, such as general issues with communication and coordination. Based on these conclusions and considering the results of past studies on the Physical Model funded by NA-241, the analysis team developed a list of recommendations and associated actions for IAEA consideration. These recommendations are prioritized based on the assessed level of difficulty for the IAEA to implement a recommendation, emphasizing low hanging fruit then building to more ambitious changes to the Physical Model's format and content.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗
NASA NTRS2014

Bringing Back the Social Affordances of the Paper Memo to Aerospace Systems Engineering Work

Model-based systems engineering (MBSE) is a relatively new field that brings together the interdisciplinary study of technological components of a project (systems engineering) with a model-based ontology to express the hierarchical and behavioral relationships between the components (computational modeling). Despite the compelling promises of the benefits of MBSE, such as improved communication and productivity due to an underlying language and data model, we observed hesitation to its adoption at the NASA Jet Propulsion Laboratory. To investigate, we conducted a six-month ethnographic field investigation and needs validation with 19 systems engineers. This paper contributes our observations of a generational shift in one of JPL's core technologies. We report on a cultural misunderstanding between communities of practice that bolsters the existing technology drag. Given the high cost of failure, we springboard our observations into a design hypothesis - an intervention that blends the social affordances of the narrative-based work flow with the rich technological advantages of explicit data references and relationships of the model-based approach. We provide a design rationale, and the results of our evaluation.

design↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗
DOE OSTI2025

Interdisciplinary Approaches Improve Understanding of Cryptogenic Species: A Historical Case Study of Crayfish in Montana, USA

ABSTRACT Cryptogenic species are those that are not yet “demonstrably native or introduced” in a given area, such as crayfish in western Montana, USA. Delving into evidence from diverse fields can help clarify the status of cryptogenic species. Primary historical sources and indigenous knowledge have informed various ecological questions but are seldom used to clarify the status of cryptogenic species, especially aquatic taxa. We summarize types of evidence used to illuminate species status and offer a case study applying historical sources to cryptogenic crayfish in Montana. We searched for crayfish mentions in dictionaries of indigenous languages and primary historical documents (e.g., travel journals, newspaper accounts, early biological surveys). Early explorer accounts we examined did not mention crayfish in Montana, though they noted them in the nearby Snake River drainage of Idaho and Wyoming. The first mention of crayfish in Montana that we found was from an 1868 newspaper account, probably referencing the upper Missouri River. The species was not noted, but an 1887 article suggested signal crayfish Pacifastacus leniusculus introductions near Bozeman, where non‐native signal crayfish still persist. The earliest crayfish mention we found west of the Great Divide in Montana was from 1934 in Ninepipes and probably referred to non‐native virile crayfish ( Faxonius virilis ). Signal crayfish were not mentioned west of the Divide until a 1944 newspaper account noted their 1937 introduction to the Bitterroot River drainage. The case study demonstrates the value of historical sources in identifying the absence of species and documenting their presence or introduction during periods predating scientific data.

Kennedy, Hampton L. [USDA Forest Service, Southern↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗
NASA NTRSDate not supplied

Rapid Spacecraft Payload Development: In-Orbit Demonstration of Flight Software Reuse, Scalability, and Dependability

As space mission design trends towards shared, multi-mission platforms and high-performance onboard computing architectures, the number of spacecraft launched into operation is also steadily rising. Through ridesharing, spacecraft miniaturization, and other cost-reduction measures, the barriers to space are lowering, resulting in compounded growth in the amount of flight software being deployed. To meet the needs of both the growing quantity and evolving nature of spacecraft, flight software design must accordingly adapt to support more efficient development, solutions to computational resource-sharing, and software reusability. This paper focuses on a software payload demonstrating several core technologies that improve the state-of-the-art in these identified areas. Launched into low-earth orbit in January 2022, our software payload was conceived, designed, and delivered in a span of merely two months. It was developed on top of the NASA core Flight System (cFS) framework and the Distributed Spacecraft Autonomy (DSA) Comm cFS application, which translates cFS software bus messages across a Data Distribution Service (DDS) network. The flight software, packaged in Linux container images, was deployed as one of 18 flight applications managed through the Unibap SpaceCloud Framework. The applications were run on a Unibap iX5-102 radiation-tolerant payload computer, hosted on the D-Orbit SCV-004 spacecraft as part of an ESA-sponsored in-orbit technology test. Our payload, referred to as the DSA D-Orbit software, demonstrates the reusability of the DSA Comm app in a substantially different context and purpose as its original mission. Comm’s original design goal was to reliably distribute messages between spacecraft swarms of arbitrary size and dynamic network topology. However, we leverage this same functionality to introduce redundancy and opportunistic parallel data processing in the context of a representative onboard image processing workload. This adaptive mission architecture was enabled in part by the SpaceCloud Framework’s use of container virtualization as the payload integration interface. By using a base container image with common high-level language runtimes and libraries, we were able to rapidly design, develop, and validate our image processing application without many of the technological barriers common to flight software development. We present details the goals, approach, results, and lessons learned through this technology demonstration experiment and contextualize those observations against present and future challenges in spacecraft software development.

computer programming↗
DOE OSTI2025

SOC Microstructural Analyzer

This program was designed to analyze the 3-phase microstructure of the electrodes of a solid oxide fuel cell (SOFC) or electrolysis cell (SOEC), both referred to in combination as a solid oxide cell (SOC). It is agnostic to the exact system, so it could be repurposed to analyze any 3-phase microstructure. This tool directly analyzes segmented voxel-based data that has been segmented into phase IDs (1,2,3). The voxels will be analyzed directly for: - tortuosity factors - triple phase boundaries - 2-phase interfacial areas, using a meshed isosurface - mean diameters of each phase, using an inscribed sphere method - standard deviation of the diameters of each phase, from the same inscribed sphere data - connectivity information Comprehensive information is available in the readme file (within the zipped repository in Markdown language, and also available here as a rendered PDF). Please cite this page / DOI, as well as https://doi.org/10.1111/jace.14775, for usage.

3D microstructure↗
DOE OSTI2018

Remove Welding Residual Stress for CFETR Vacuum Vessel by Trailing Ultrasonic Impact Treatment

The China fusion engineering test reactor (CFETR) vacuum vessel is welded by narrow gap TIG (NG-TIG) welding, and the welding residual stress of the CFETR vacuum vessel can be redistributed by trailing welding ultrasonic impact treatment. In order to investigate the feasibility of the residual stress removing scheme, and to obtain the optimal trailing ultrasonic impact treatment technological parameters in the process of removing welding residual stress, a welding model that similar to vacuum vessel welding seam is established by using ABAQUS software, a NG-TIG welding heat source subroutine which is written in FORTRAN language used to simulate NG-TIG welding. According to the welding simulation results, a trailing welding ultrasonic impact treatment model is established, and the effects of the impact pin number, the impact method, the impact pin diameter and the impact frequency on welding residual stress are studied. The results show that the longitudinal residual stress in welding seam and its adjacent area and the lateral residual stress in the whole region have been obviously decreased by different trailing welding ultrasonic impact processes, and have made the tensile stress in the welding seam and its adjacent area has been changed into compressive stress, which can provide theoretical guidance and reference for actual production.

36 MATERIALS SCIENCE↗
DOE OSTI2019

2018 Annual Site Environmental Report

Los Alamos National Laboratory’s (the Laboratory’s) annual site environmental reports are prepared annually by the Laboratory’s environmental organizations, as required by U.S. Department of Energy Order 231.1B, Administrative Change 1, Environment, Safety, and Health Reporting, and Order 458.1, Administrative Change 3, Radiation Protection of the Public and the Environment. The following chapters in this report discuss our success in complying with environmental laws, regulations, and orders (Chapter 2, Compliance Summary); how we manage the Laboratory’s environmental performance (Chapter 3, Environmental Programs); how we monitor for air emissions of radioactive materials and climate conditions (Chapter 4, Air Quality); how we monitor for effects of Laboratory operations on groundwater quality (Chapter 5, Groundwater Monitoring); how we monitor the movement of chemicals and radionuclides by storm water runoff and the levels of chemicals and radionuclides in deposited sediment (Chapter 6, Watershed Quality); how we monitor for the presence, levels, and effects of chemicals and radionuclides in plants, animals, soil, and vegetation (Chapter 7, Ecosystem Health); and finally, what radionuclide dose or risk from chemical exposure members of the public may experience as a result of Laboratory operations (Chapter 8, Public Dose and Risk Assessment). This report follows plain language guidelines, as required for federal agencies by the Plain Language Act of 2010. More information about plain language can be found at http://www.plainlanguage.gov/index.cfm. You will notice we have substantially reduced the use of acronyms and abbreviations and are using active voice and personal pronouns. We hope you find this report useful. If you have suggestions for improving this report, additional questions, or want a copy of this report, please contact us at envoutreach@lanl.gov, or call the Communications Office at 505-665-7000. This report, its supplemental tables, and the 2018 Annual Site Environmental Report Summary are available at http://www.lanl.gov/environment/environmental-report.php. Note: This document has been revised since it was initially published on September 23, 2019. The revisions included corrections to figure and table references, changes in heading levels, adding blank pages where appropriate, and changes of an editorial nature.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2016

ISS Double-Gimbaled CMG Subsystem Simulation Using the Agile Development Method

This paper presents an evolutionary approach in simulating a cluster of 4 Control Moment Gyros (CMG) on the International Space Station (ISS) using a common sense approach (the agile development method) for concurrent mathematical modeling and simulation of the CMG subsystem. This simulation is part of Training systems for the 21st Century simulator which will provide training for crew members, instructors, and flight controllers. The basic idea of how the CMGs on the space station are used for its non-propulsive attitude control is briefly explained to set up the context for simulating a CMG subsystem. Next different reference frames and the detailed equations of motion (EOM) for multiple double-gimbal variable-speed control moment gyroscopes (DGVs) are presented. Fixing some of the terms in the EOM becomes the special case EOM for ISS's double-gimbaled fixed speed CMGs. CMG simulation development using the agile development method is presented in which customer's requirements and solutions evolve through iterative analysis, design, coding, unit testing and acceptance testing. At the end of the iteration a set of features implemented in that iteration are demonstrated to the flight controllers thus creating a short feedback loop and helping in creating adaptive development cycles. The unified modeling language (UML) tool is used in illustrating the user stories, class designs and sequence diagrams. This incremental development approach of mathematical modeling and simulating the CMG subsystem involved the development team and the customer early on, thus improving the quality of the working CMG system in each iteration and helping the team to accurately predict the cost, schedule and delivery of the software.

Inampudi, Ravi↗
NASA NTRS2020

Developing and Implementing a Process to Verify and Validate the NASA InSight Mission’s Instrument Command Products

The NASA InSight Mars lander is a roboticspacecraft which is investigating the interior structure of Marsthrough a series of seismological measurements andexperiments. Much of the commanding of activities performedby the instruments was done using ‘blocks’ – reusable functionswritten in Virtual Machine Language stored onboard thespacecraft– and sequences (series of commands) that werecreated by teams to operate their instruments. It was vital thatthese blocks and sequences (collectively called commandproducts) be thoroughly examined prior to onboard executionusing a comprehensive test program to reduce risk to thespacecraft and instruments and ensure smooth operations onthe surface of Mars. The Verification and Validation (V&V)process that was designed and implemented during the monthsleading up to InSight’s launch and landing successfullyuncovered a number of issues that could have causedoperational delays or impacted hardware. The process alsohelped adapt ground tools to better model onboard activities,create operational principles to avoid unintended consequencesduring flight, and generate a reference database for commandproduct use during operations. This allowed InSight to meet itssurface operations goals in the desired timeframe. This paperdescribes the development, implementation and results ofInSight’s command product V&V process, its contribution tomission success, and challenges faced.

Cloutier, Kyle↗
NASA NTRS2005

Apex Reference Manual 3.0 Beta

Apex is a toolkit for constructing software that behaves intelligently and responsively in demanding task environments. Reflecting its origin at NASA where Apex continues to be developed, current applications include: a) Providing autonomous mission management and tactical control capabilities for unmanned aerial vehicles including an autonomous surveillance helicopter and a simulation prototype of an unmanned fixed-wing aircraft to be used for wildfire mapping; b) Simulating human air traffic controllers, pilots and astronauts to help predict how people might respond to changes in equipment or procedures; and c) Predicting the precise duration and sequence of routine human behaviors based on a human-computer interaction engineering technique called CPM-GOMS. Among Apex s components are a set of implemented reasoning services, such as those for reactive planning and temporal pattern recognition; a software architecture that embeds and integrates these services and allows additional reasoning elements to be added as extensions; a formal language for specifying agent knowledge; a simulation environment to facilitate prototyping and analysis; and Sherpa, a set of tools for visualizing autonomy logic and runtime behavior. In combination, these are meant to provide a flexible and usable framework for creating, testing, and deploying intelligent agent software. Overall, our goal in developing Apex is to lower economic barriers to developing intelligent software agents. New ideas about how to extend or modify the system are evaluated in terms of their impact in reducing the time, expertise, and inventiveness required to build and maintain applications. For example, potential enhancements to the AI reasoning capabilities in the system are reviewed not only for usefulness and distinctiveness, but also for their impact on the readability and general usability of Apex s behavior representation language (PDL) and on the transparency of resulting behavior. A second central part of our approach is to iteratively refine Apex based on lessons learned from as diverse a set of applications as possible. Many applications have been developed by users outside the core development team including engineers, researchers, and students. Usability is thus a central concern for every aspect of Apex visible to a user, including PDL, Sherpa, the Apex installation process, APIs, and user documentation. Apex users vary in their areas of expertise and in their familiarity with autonomy technology. Focusing on usability, a development philosophy summarized by the project motto "Usable Autonomy," has been important part of enabling diverse users to employ Apex successfully and to provide feedback needed to guide iterative, user-centered refinement.

Freed, Michael A.↗
NASA NTRS1975

A computerized symbolic integration technique for development of triangular and quadrilateral composite shallow-shell finite elements

Computerized symbolic integration was used in conjunction with group-theoretic techniques to obtain analytic expressions for the stiffness, geometric stiffness, consistent mass, and consistent load matrices of composite shallow shell structural elements. The elements are shear flexible and have variable curvature. A stiffness (displacement) formulation was used with the fundamental unknowns consisting of both the displacement and rotation components of the reference surface of the shell. The triangular elements have six and ten nodes; the quadrilateral elements have four and eight nodes and can have internal degrees of freedom associated with displacement modes which vanish along the edges of the element (bubble modes). The stiffness, geometric stiffness, consistent mass, and consistent load coefficients are expressed as linear combinations of integrals (over the element domain) whose integrands are products of shape functions and their derivatives. The evaluation of the elemental matrices is divided into two separate problems - determination of the coefficients in the linear combination and evaluation of the integrals. The integrals are performed symbolically by using the symbolic-and-algebraic-manipulation language MACSYMA. The efficiency of using symbolic integration in the element development is demonstrated by comparing the number of floating-point arithmetic operations required in this approach with those required by a commonly used numerical quadrature technique.

Anderson, C. M.↗
DOE OSTI2021

Codon2Vec v1.0

Background: Codon2Vec is an embedding neural network that predicts 'high' or 'low' gene expression directly from the protein-coding sequences. Embedding neural networks are commonly used for natural language processing (NLP) applications. Analogous to how an English sentence is a string of words, a gene can be thought of as a string of codons. Similar to how NLP neural networks model English sentences as a non-random sequence of words, we considered a coding sequence as a non-random non-overlapping array of codons (k-mers of length = 3). Value Proposition: - Codon2Vec achieved a high median AUC-ROC score of 83.8% when trained and applied to transcriptomic data from 300 fungal species - Unlike Codo2Vec, conventional methods predicting for expression based on codon usage rely on a priori knowledge of optimal codons or a set of reference genes. - Unlike Codon2vec, these methods do not account for the effect of codon order on gene expression. - Codon2Vec neural network bypasses the need for artisanal feature selection step that is necessary for traditional machine learning models.

Wint, Rhondene↗
NASA NTRS2004

Trajectory Specification for High-Capacity Air Traffic Control

In the current air traffic management system, the fundamental limitation on airspace capacity is the cognitive ability of human air traffic controllers to maintain safe separation with high reliability. The doubling or tripling of airspace capacity that will be needed over the next couple of decades will require that tactical separation be at least partially automated. Standardized conflict-free four-dimensional trajectory assignment will be needed to accomplish that objective. A trajectory specification format based on the Extensible Markup Language is proposed for that purpose. This format can be used to downlink a trajectory request, which can then be checked on the ground for conflicts and approved or modified, if necessary, then uplinked as the assigned trajectory. The horizontal path is specified as a series of geodetic waypoints connected by great circles, and the great-circle segments are connected by turns of specified radius. Vertical profiles for climb and descent are specified as low-order polynomial functions of along-track position, which is itself specified as a function of time. Flight technical error tolerances in the along-track, cross-track, and vertical axes define a bounding space around the reference trajectory, and conformance will guarantee the required separation for a period of time known as the conflict time horizon. An important safety benefit of this regimen is that the traffic will be able to fly free of conflicts for at least several minutes even if all ground systems and the entire communication infrastructure fail. Periodic updates in the along-track axis will adjust for errors in the predicted along-track winds.

Paielli, Russell A.↗
NASA NTRSDate not supplied

Viability of Small Dimension Crew Quarters for Surface Habitation

During early planning for the Artemis program’s sustained phase of lunar activity, NASA planners have been held to work towards a NASA reference lunar lander concept. With this activity taking place prior to the awarding of a lander contract, NASA planners cannot assume which of several potential landers will be available. This has limited habitation team engineers to a 12-metric ton mass limit for the reference concept of the lunar Surface Habitat. Consequently, minimal approaches have been applied to many habitat systems and it is important to determine acceptable volume for crew quarters. A number of both NASA and non-NASA surface habitat concepts have proposed relatively small crew quarters due to this constraint. Consequently, there is a need to collect objective test data to confirm or refute the validity of small crew quarters. NASA-STD-3001 is looked to for guidance in its many standards but offers little to no help. While prior versions called for private habitation, the current version – Revision B – calls for “individual privacy” to “accommodate social retreat.” Proposed Revision C modifications change the language slightly to “accommodate sleep and social retreat.” This is not enough guidance to determine the size of a crew quarters or even its capabilities. Unfortunately, only a small number of US spacecraft have included crew quarters, primarily the International Space Station and the Skylab Space Station. The space shuttle orbiter sometimes flew a set of private bunks that some might consider a crew quarters. All of these are dramatically smaller than US standards for minimum jail cells. The first opportunity for NASA to test a small crew quarters in a surface habitat application has been created through the Exploration Atmospheres test series, which is evaluating human performance under reduced cabin pressures. The test is converting the 20-Foot Vacuum Chamber at Johnson Space Center into a habitat, with the lower level outfitted as an EVA test area and the upper two levels for human habitation. The test will place eight people (six test subjects and two technicians) inside the chamber for eleven days. All eight will sleep in private quarters during the test. Volume limitations in the chamber forced extremely small crew quarters, measuring approximately 2 meters in length, 0.85 meters in height, and 0.9 meters in width. The test cabin pressure of 8.2 psi and elevated oxygen also introduces significant material limitations, limiting outfitting options. Nonetheless, the crew quarters design requirements were to accommodate visual separation, auditory separation, olfactory separation, tactile separation, air flow control, lighting control, single person personal computing, physical work surface access, sleep accommodations, non-sleep rest/relaxation, meditation, stretching, two-person meetings, snacking, changing clothes, viewing appearance, video communication, and audio communication. This paper will detail the acceptability of the crew quarters as measured in the October 2021 Exploration Atmosphere test. Based on this data, the viability of the type of crew quarters used in the 20 Foot Chamber will be assessed. Design recommendations for a 30-60-day Surface Habitat crew quarters will be provided, along with recommendations for future testing.

Crew Quarters↗
DOE OSTI2023

Classification of River Catchments in the Contiguous United States: Code, Dataset, Similarity Patterns, and Resulting Classes

This dataset serves as supplementary information for the paper by Ciulla F. and Varadharajan C. A Network Approach for Multiscale Catchment Classification using Traits (see reference 1). It contains environmental and physical catchment traits, such as temperatures, precipitation, land use and human interference, from 9067 sites across the contiguous United States (CONUS). The purpose of this dataset is to provide information for a better trait-based categorization of river catchments in the CONUS using networks as an analytical tool. The traits variables match the ones present in the GAGES-II dataset and the preprocessing steps are described in the Methods section (processed_dataset.csv). Additionally we include the topologies (nodes, edges and clusters, also referred as classes) of the catchment network and traits network generated by said dataset (csv and json files). A series of tables support the information carried by the network providing more detailed descriptions of cluster components (SI1.pdf). A summary of all the plots of clusters of catchments with at least 50 nodes is provided (SI2.pdf). The characteristic traits for each cluster of catchments is presented as z-score (traits_categories_zscores_per_catchment_class.csv). The link to the hydrological behavior of clusters of catchments is displayed by boxplots, each describing a particular river discharge index (SI3.pdf). Both csv and json files can be read by common text editors but the data contained into them can be better handled using programming languages like python and database oriented libraries like pandas. Pdf files can be read by any pdf reader software.[02-23-2024] Update: The code and datasets necessary to reproduce the results of the study are available as a zipped repository (code_datasets_catchments_similarity.zip).

54 ENVIRONMENTAL SCIENCES↗